Congestion increases — in tiny, sometimes barely perceptible ways. No one thing stands out...it just gets harder and harder. Slowly.
A common response is to enforce more planning, and more control over teams. The slip must be a management issue! (5/13) #leanagile#devops
Some skilled “lifers” know their way around the code. They keep up the illusion of forward progress. Their ego is on the line. “It’s not THAT bad folks!”
New folks are lost. Onboarding takes ages. The lifers are too proud (and busy) to help. (6/13) #leanagile#devops
At this point, something bad happens. An outage. A super long delay. Something customer facing. Eyes are on engineering leadership.
“We need a MONTH to fix this! Then we’ll be back in business” (7/13) #leanagile#devops
Meanwhile, behind closed doors ...
“A month? Are you crazy? This will take a year to unravel. Why a month?”
“We’ve got to prove ourselves team. All eyes are on us...” (8/13) #leanagile#devops
You can probably tell what’s happening here. A drift into failure. Desire to please. Egos at stake. Even if someone said “at this rate, we’ll soon experience 50% drag, and non-linear increases in lead time, defects, failures” no one would believe them. (9/13) #leanagile#devops
At this stage, driven by impatience, product leadership may be scouting acquisitions, looking for silver bullets, and figuring out a plan B. “Engineering is a mess! We have to figure something out”
Once you’re over a certain point of drag, it is far too costly to work things down.
Bad leadership? Nope. I’ve seen this happen with great leaders. Bad process/systems? Nope. (12/13) #leanagile#devops
The fix? Visualize the work. Measure lead times. Blameless retrospectives. Psyc safety. An awareness of the non-linear nature of debt and drag. Listen!
And deeply challenge the notion that technical debt can be artfully managed. Maybe? Very, very hard (13/13) #leanagile#devops
• • •
Missing some Tweet in this thread? You can try to
force a refresh
- What you say, and how often you say it
- What, when, and how you celebrate
- The losses and missteps you acknowledge, and how you respond
- How you behave when the chips are down
- What you fight for at all costs
- The corners you cut
- Who you hire, promote, and compensate, and who you fire
- Who you “smoke out” until they leave the organization
- The worst behavior you accept and the best behavior you reject
- The voices you amplify, and the voices you suppress
- When you encourage conformity, and when you promote diversity
- How you handle disagreements and differences in opinion
- How and where you spend your time and money
- What gets discussed out in the open, and behind closed doors
Here’s something you see often w/ teams and #kanban
Team: “Can we move cards backwards?” (1/11)
When this happens, we’re in a pickle. In true pull-system fashion, the developer has pulled another card. Test finds an issue that demands developer’s attention. What to do? (2/11)
One solution is to say “hey dev, you can only be on two things at once...one of which is developing”. Seems reasonable...and keeps their bandwidth open to fix issues. (3/11)
Some #prodmgmt Qs for interviewer... (1/4)
- technical debt
- recent prod issues / reactive work
- direct access to customers
- attrition rate for PMs
- typical calendar / mix of activities
- last 5-10 prod decisions and outcomes
- details of decision making process
- metric you must drive to be successful
- psych safety on teams
- dedicated #ux ?
- how team missions are crafted
- autonomy over roadmap ?
- deployment pipeline, ease of collaboration
- access to product usage data (tools?)
- current “big bet” and key unknowns
- career development (conferences, training)
- incentive structure for team members
- amount of pre-committed work
- examples of PMs being reward for specific behavior
- details of approvals, sign-offs, roadmap reviews
- overall product “culture” (role of product)
Model the work, not the “workers”. With team member magnets, checklists, and markers...the bottom design can more than adequately model the work
If work ever “moves left” (e.g. QA/demo passes an item “back to dev”), then the top dsgn breaks. It is all doing.
Another classic anti-pattern is team/individual lanes and “splitting” the work. The bottom option will probably catalyze the right conversations....though the top option with string can also do the trick. (2/4) #kanban
A compromise if teams want their own card for some reason... is a hybrid board with “epics” (larger chunks of work), and all of their related cards.(3/4) #Kanban
...and you know what? Those exact same things are muttered by engineers/QA all the time.
They have nothing to do with #agile, but everything to do with paint-by-numbers approaches to “delivery”, org silos, and overly simplistic “#design then build” models. 3/n