18 Feb 2020

Fifth anniversary

In a world of rapid change, it is quite gratifying to note the continuing relevance of Agile IT Org Design published in 2015. As a buildup to its fifth anniversary in June 2020, I'll post snippets from the book couple of times a week on LinkedIn.

14 Feb 2020

PRONOW: Prioritize Outcomes, Not Work

Product development teams have to deal with multiple stakeholders. They each have their own set of priorities. That's natural. Reconciling these priorities into a single-threaded product backlog can be a thankless task. In theory, "cost of delay" based prioritization techniques should let us avoid "HiPPO prioritization". In practice, these techniques help only so much. How do you validate and normalize costs assigned by different stakeholders? The whole process is vulnerable to false rigor and gaming. But what if, instead of trying so hard to avoid HiPPO prioritization, we let it happen within guard rails and compensate for it with tight feedback loops? We'd end up with a much simpler prioritization process. I call it PRONOW (Prioritize Outcomes, Not Work).

Co-conspirators: Ricardo Cavalcanti, Cristiane Higashi

Outline


Step 1: A Tree of Success starts with "overall success" at the top, branches off into high-level business measures of success, and drills down all the way to metrics that can be tracked on a regular basis via production analytics, surveys, ratings, etc.

Step 2: Outcomes are defined in terms of improvements to any metric on the tree of success. Stakeholders prioritize outcomes that they expect to improve through next quarter's (or other planning period) efforts.

Step 3: Independent of step 2, product backlog owners map items in their backlog (representing demand from various stakeholders) to nodes in the tree of success.

Step 4: The output of steps 2 and 3 allow us to derive priority for backlog items. They still need to be matched against team capacity but that's just detail. Did you notice what just happened? We did not prioritize work directly. We prioritized outcomes, not work, avoiding a lot of bickering in the process.

How do we know we've prioritized the right things? By tracking actual benefits with a tight feedback loop. We've deployed it at a client with good results. If you'd like to try it, get in touch. There's a ton of detail not covered here, such as dealing with dependencies, for example.

Note: This may appear to be just another prioritization technique but its actually a framework for greater outcome-orientation across business, product, and engineering teams. Business buy-in is mandatory for successful adoption. Old habits might need to change. After effects might be long-lasting and transformational. You've been warned.

5 Feb 2018

The challenges of synchronous communication

I have been advocating for and helping clients with the use of written decision records in contentious areas of decision making. However, it is a big change for people who prefer to discuss things verbally over a meeting (face to face or over a call). They claim that it is easy to misunderstand intent over a written medium and that doing it in writing would slow things down.

The book weighed in on this topic in the chapter on communications. An excerpt:
"However, the discussions leading to these decisions are often flawed when conducted verbally. This is due to various factors:
• Glib tongues talking others down.
• Relative seniors intimidating others by tone, impatience, patronizing comments, and nonverbal cues.
• The inability of non-native speakers of English to match the articulation of native speakers. They may lack fluency, vocabulary, or panache in English. Fumbling or pausing mid-sentence for a word or a phrase makes for a weak impression.
• Lack of time to reflect and counter an argument that sounds good superficially but feels flawed intuitively.
• Lack of time to collect one’s thoughts and answer a question effectively.
• Spur-of-the-moment emotional reactions to perceived slights."
Here's a great example of someone challenging your position in a meeting (an interview, in this case). The interviewee here does a great job of keeping his cool and responding precisely and logically to various strawman arguments from the interviewer. However, it is a tough act to follow and most contentious business meetings would end-up with a sub-optimal decision because of a failure to see through flawed arguments.



Spoken arguments require us to get it right the first time in real time. It’s like directly deploying software to production with minimal testing. It may be heroic, and those who pull it off regularly may be really sharp (like the interviewee in the video), but it doesn’t make business sense as a practice. On the other hand, written arguments by their very nature force a modicum of scrutiny and reflection (i.e., testing), even when they say “Sent from my smartphone” at the end.

3 Nov 2017

Taking DevOps to the Org Chart

In order to realize the full potential of DevOps, it is insufficient to only aim for better engineering techniques and greater automation, hard as that may be in itself. One of the implications of DevOps is a merger of development and corresponding operations teams into several build-it-and-run-it teams. This calls for a re-org at the typical tech organization that supports an old-guard business. The re-org is a challenge for large tech organizations that are often split down the middle in the form of a change organization and a run organization.

This talk (closing keynote at DevOpsDays Singapore 2017) explores the challenge and describes how it being addressed at some companies.