Common reasons given for why Agile fails:
- Management wasn’t involved
- Teams weren’t motivated
- People didn’t follow the framework
- Agile is hard and complex
- What I never hear is – “our frameworks are insufficient for the task.”
Common reasons given for why Agile fails:
Of course not. But yet we hear people infer that incorporating a few Lean practices into Scrum makes it Lean. It doesn’t.
Waterfall is not just based on its practices, but on its mindset of being able to predict and plan out ahead. Putting an Agile practice into waterfall will likely improve things, but it doesn’t make it Agile. The reason is that waterfall =mindset + practices. The practices are done within the context of the mindset.
The two most popular Agile frameworks today suggest a preset starting method. Scrum with cross-functional teams and SAFe with Essential SAFe.
Both have the rationale that people need to start in a well-defined way and abide by it until they learn more. SAFe also promotes that consistency of practices is needed across the organization.
Business Agility sets the why and goal. Flow and Lean both provide insights on what to do and how you are doing.
Here are some challenges they help overcome:
There are two types of classroom training – one where the instructor dumps information into the students minds. The second when labs are involved so that students are mostly interacting with the instructor or doing work.
This post refers to the first type.
Classroom training is centuries old. The recent fad of adding exercises and games helps, but doesn’t change the fact that the students forget 80-90% of what they’ve learned after just a week. Training is also focused on a canned solution instead of people’s problems.
Note: This post is one of a series in the post Questions to ask about your approach.
Frameworks should provide a quick start while helping organizations continue to improve. Here are a few different approaches taken.
I. Provide a preset framework that has you do what it says until you learn to adjust (Scrum). The challenge with this is that the preset practices may not fit. This may have them lose faith in the entire transition. In addition, there is nothing in the framework that tells them how to transcend the starting practices. People may eventually feel locked in and just try new things with little guidance.
II. Provide some theory with preset practices (SAFe). This has somewhat the same challenges as I. above with the additional challenge of putting people into cognitive overload which results in few principles being remembered.
Both I & II focus on learning the framework with no training provided to transcend it.
III. Provide great detail in principles and let them figure out the practices. This does ground people in principles, but most want an answer to “what do I do?”
IV. Provide principles, a starting set of practices with options and a roadmap on how to select the practices that work for you. This gets people started on something that works for them while providing a way to improve. Yes, this is FLEX.
One of the cornerstones of Flow, Agile and the Lean Startup is quick delivery of value to customers. This reduces waste by focusing on what’s of greatest value while enabling pivoting and creating a tight bond between the organization and its customers.
We call this concept the Minimum Business Increment (MBI). The intention is to answer two questions when faced with implementing an initiative. 1:”what is of highest value that I can deliver quickest?” 2: “what besides development is necessary for the realization of this value?” MBIs lie between epics and features in size and are what calculating cost of delay (CoD) should be done on. Calculating WSJF on epics or features doesn’t make sense. Only subsets of an epic as delivered at a time, WSJF should be calculated on that. Features may not provide value on their own, so CoD is incalculable. Continue reading “Does your approach utilize the concept of smallest realizable chunk of value that can be realized?”
Many frameworks imply this agreement is to follow the framework. Others, such as Scrum, go further and insist you follow at least the immutable practices, rules, events and roles. This puts the focus on how individuals follow their role in the framework instead of how they work together.
While this may seem natural, it takes everyone’s focus off agreements between each other. It also has people follow the framework instead of seeing how they should really work together.
To be clear, I am referring to Lean’s (not SAFe’s) definition of the value stream – the set of actions that take place to add value to a customer from the initial request to delivery. The value stream begins with the initial concept, moves through various stages for one or more development teams and on through final delivery and support. You can’t define value streams – they are what is. You can, however, map them, define a “to be” value stream and you can improve them.
The opening of the Agile Manifesto is:
“We are uncovering better ways of developing software by doing it and helping others do it.”
I would assert, however, that any approach (primarily frameworks) that has fixed practices in it (e.g., Scrum, SAFe) without a method of guiding how to go beyond them (e.g., Scrum, SAFe) may be great starts but are not truly Agile. The key is also _may be_ in that predetermined practices are not universal. BTW – LKU Kanban has its shortcomings as well in not attending to the entire value stream nor attempting to get to cross-functional teams.
There is nothing wrong with this. The trap is that people stop trying to go beyond them. Continue reading “Good enough to ship is OK, even probably good. Good enough to stay, however, is not”