Mind Your Prescriptions!
Leon Sabarsky
Thinking about Agile methods and prescriptions I’ve been thinking a lot of prescriptions lately (not those types of prescriptions – geesh), more specifically being highly prescriptive when it comes to recommending Agile methods for organizations. Let me share with you what’s been keeping me up at night. Having been involved with Agile and various Agile methods for over 10 years, I often find myself encountering individuals who promote their Agile flavor and often, it seems, only promote their Agile flavor no matter the organization or the environment. This gives me pause and causes me to reflect on the pros and cons of each Agile method that I’ve been exposed to and wonder. Never miss fantastic posts such as this one.
Aren’t we trusted advisors and consultants whose job it is to understand the organization and context of the environment/situation, understand/assess the organizational culture, perform a typical Agile assessment and make a recommendation regarding the type(s) of Agile methods which would best benefit and align to the organization, leveraging our vast knowledge and experience.
Are we doing that? Are we even trying to do that?
Or are we just going through the motions as we (1) perform an Agile assessment (like everyone does first), and (2) propose the Lean/Agile/XP/Other method that we are most comfortable with or have all the sales materials for?
I’m proposing that we check our method at the door (keep your ego) and mind our prescriptions.
Prescription Comparisons that resonate with me
- Iteration/Release length
One example that I can think of is Iteration/Release length. Some methodologies prescribe a specific Iteration or Release length, and if you don’t align exactly to that, the implied message is that “you’re doing it wrong”.
In Scrum, for example, according to the Scrum Guide, “Each Sprint may be considered a project with no more than a one-month horizon. Like projects, Sprints are used to accomplish something. Each Sprint has a definition of what is to be built, a design and flexible plan that will guide building it, the work, and the resultant product.
Sprints are limited to one calendar month. When a Sprint’s horizon is too long the definition of what is being built may change, complexity may rise, and risk may increase. Sprints enable predictability by ensuring inspection and adaptation of progress toward a Sprint Goal at least every calendar month. Sprints also limit risk to one calendar month of cost.”
In contrast, the Scaled Agile Framework for the enterprise (SAFe) has changed how it describes Iteration length associated to PSIs (Potentially Shippable Increments) releases over the course of its incremental methodology framework versions. In SAFe version 2.0, Iteration length was specifically 2 weeks, rolling up to a PSI release of 10 weeks (or five 2 week Iterations). Later, it seems that PSIs could be anywhere from 8 to 10 weeks. Now, I’m not so sure what SAFe is prescribing now for PSI length. Maybe it’s up to you?
Personally, I much prefer flexibility to determine the Iteration length depending on a number of organizational and industry factors. I often recommend aligning the Iteration length to the time period (under 4 weeks) that the team can deliver a product increment consistently. If a team can deliver a product increment in one week, why can’t they align their iteration length to that?
So, I appreciate working with a “do not exceed for really good reasons” Iteration length which allows me to go as low as I want. Being perspective here can have unintended consequences, like having a team “wait” to deliver value to the customer. This, to me, is not Lean or Agile thinking. Even if you are scaling and have multiple feature or component teams, waiting is still waste and a cost of delay.
- Is there such a thing as “Minimum number of practices needed” for success?
I often wonder (and I wonder if you too wonder what I wonder) that if I recommended a methodology that has 100 defined practices, and the organization only successfully implemented 99 practices, would that be a failure?
Scrum has 3 prescribed roles, 5 prescribed events, and 3 prescribed artifacts. It says that it is a “lightweight methodology that is simple to understand but difficult to master”. The Scrum Guide is a pretty small document (mine has 12 pages).
I’m actually not really sure how many prescribed roles, events, artifacts and practices SAFe has, but I’m certain that companies have gotten value by not implementing all of the prescribed practices. I took a 4 day class to get a SAFe certification and I’m certain not everyone in the class understood or actually uses Weighted Shortest Job First (WSJF) as a prioritization technique. So, are they “doing it wrong” if they don’t use WSJF?
So, I’m glad somebody (not me) finally asked the SAFe folks “what is the minimum SAFe practices which should be implemented?” Alex Yakyma and Dean Leffingwell answered with only 8 minimum SAFe practices as must-haves. http://www.scaledagileframework.com/first-things-first-essential-safe/
To me, that begs the question. If we only need to implement 8 SAFe practices to derive value or to make SAFe work well, why are the rest of practices needed? Are they even valuable? Are we just doing practices just to do them? Is there evidence that the other practices are needed and valuable? Is anyone wondering this?
Do highly prescriptive methods resonate with clients?
I think that they do with some clients and organization. Doesn’t everyone want a recipe that they can follow for success? All anyone has to do is follow the steps to the recipe and an amazing tasting cake will come out of the oven.
Does anybody really, truly believe that? I think some folks do. I don’t.
What I have seen in the industry is that clients and organizations are frequently disappointed by prescriptive method framework implementations. They really, really try to follow the all the practices. Often, they can’t or are prevented from succeeding at all of them. So, they view their failure as a lack of implementing all of the practices. Is that true? Or do they fail by forgetting to focus on delivering value to customers instead of focusing on the practices?
Wrapping up
In conclusion, I wonder if we are only focusing on “doing the practices right” versus focusing on implementing value for the customer. That keeps me up at night. In my experience, the less prescriptive you are, the more creativity you can bring to the organization and customize practices to that organization. Of course, my experience has showed me to mind my practices. How has your experience differed or has it been similar? I’d love to continue the conversation, but I’d also like to get some sleep.
Leon Sabarsky helps to foster and grow healthy agile teams for organizations large and small. He is the Principal Consultant and Owner of Healthy Agile LLC. He is a frequent speaker, collaborator and musician who is passionate about helping organizations deliver value to their customers. He has a little insomnia but is taking a prescription for that.