Today we take on Chapter 73 of Great Big Agile, An OS for Agile Leaders by Jeff Dalton. In two  more weeks, we will begin Fixing Your Scrum: Practical Solutions to Common Scrum Problems (it is time to buy a copy). If you are wondering why we went from chapter 7 to 73, the interleaving chapters are an encyclopedic listing of 66 techniques that are useful when you are being agile. For those of you that buy the book for chapters 8 – 72, I will state a word of caution. Just adopting and doing techniques does not make you agile. Doing techniques may well be useful if you do not fall into the trap of declaring yourself agile. Just doing is never sufficient to generate the value everyone wants from being agile. If the difference between being and doing agile interests you please read, Assessments: Being or Doing.  The slight rant on the difference between doing and being is important for understanding this chapter. I read (and re-read) this chapter as two pieces.  The first part describes Jeff’s and Broadsword’s (his company) journey up to the point they decided to become agile. The background is important to understand why adopting the agile mindset and then the techniques was a natural step as the organization matured. Most organizations do not have the luxury of having all of the same pieces of the puzzle at their fingertips. Arguably most teams and organizations have to create an environment where trust and experimentation flourish. I am not sure whether it was during the first or third time I read the chapter that I built a mindmap of the attributes that Jeff identifies as being crucial for Broadsword’s agile transformation which is used as an illustration for the chapter. In addition to trust, which Jeff identifies, I would add a strong vision/goal and an acceptance of experimentation to the attributes need for any agile transformation. Those three attributes are the three most important predictors of transformation success that I see in my practice.  

The second part of the chapter maps Broadsword’s use of the Agile Performance Holarchy (APH) to map and guide their transformation. I suspect that the transformation also shaped the model (an interview question for next time Jeff Dalton is on the SPaMCAST). The layout of this portion of the chapter suggests multiple uses for the model.  The two ways I have leveraged the APH are as an appraisal tool and as an easily understood communication vehicle for scenarios, such as communities of practice.  The first is for identifying the components of your team or organization that need to change and adapt to be agile. This is a way to appraise and monitor progress.  Secondly, when performance circles and holons are combined with techniques, the result is a map that can be used to guide other teams when they encounter a new issue or their context changes. 

The APH is not a prescription or reciple but it is a tool to help as you become agile and then work to stay agile. Next week we will conclude our re-read of Great Big Agile with a few closing remarks.

Remember, buy a copy and read along. 

Previous installments:

Week 1: Re-read Logistics and Front Mattershttps://bit.ly/3mgz9P6 

Week 2: The API Is Brokenhttps://bit.ly/2JGpe7l

Week 3: Performance Circle: Leadinghttps://bit.ly/2K3poWy 

Week 4: Performance Circle: Providinghttp://bit.ly/3mNJJN7 

Week 5: Performance Circle: Envisioninghttps://bit.ly/2JEVXdt 

Week 6: Performance Circle: Craftinghttps://bit.ly/3ntsX69 

Week 7: Performance Circle: Affirminghttp://bit.ly/35OvFgC 

Week 8: Performance Circle: Teaminghttp://bit.ly/366CYk0