There has been a fair amount of discussion regarding Ron’s thoughtful blog on SAFeTM. I want to shift the discussion from what Ron said to what we can learn. I do not intend to respond to Ron's entries directly. What I will say is that Ron is very intelligent, very experienced and truly wanting to make a positive difference in the community. He is one of my most respected thought leaders, even though I often disagree with him. But it is perhaps because I can disagree with him and yet continue the conversation that I regard him so highly. I have never seen him act in a manner that put himself before the community in the 15+ years I've known him. Not to say that he never got under my skin a few times in years past ;)
Anyway, I think the real issue on SAFe’s applicability lies with some deep assumptions many Agilist’s have. BTW: From this point on, I am talking in general, not about Ron in particular. There are four assumptions I find seem to pervade Agile thinking:
While there is evidence for all of these beliefs, I do not believe any of them are inherently true. BTW: There are several others, I just don’t have the time to consider them all now.
Management’s role is one of removing impediments from the teams. In 15 years of Agile experience I believe it is just as likely that management will be pro-Agile as teams are. However, since management often has more power than teams, when they are not pro-Agile, they are a serious impediment to its adoption. In my mind, management’s role should be one of leadership and guidance. While we want management to remove impediments, we must not think of their being an impediment.
While “Chicken and Pigs” as a story has fortunately been abandoned, it was pressured out more due to cultural pushback of people being called pigs, which in many faiths are considered unhealthy. The root of having that story in the first place is still present amongst many agilists, unfortunately.
Question: How would we act if management led Agile adoption?
Where to start? Starting at the team level is often not only not really possible, it is often detrimental. The impediments to Agile may lie elsewhere and their solutions are therefore elsewhere. We must take a holistic, systems-thinking approach. We must consider the entire value stream and any impact a pilot has on the remaining organization. Agile often fails not so much because it is rejected by management, as much as it exacerbates challenges in other parts of the organization without providing any insights for a solution.
Question: Shouldn't where to start have something to do with what our challenges are?
Estimation is bad and useless anyway. Many argue against estimation because missed estimates are often used to abuse teams. But that implies management will behave inappropriately. What if management used poor estimates as a way of getting to the root cause of our unpredictability? In any event, I believe the biggest challenge with estimation is not the unpredictability of the work, but the unpredictability of the workload the teams making the estimates have. Working on too many projects has people spend a lot of their time on wasteful work - work we did not estimate for. They do not have a steady rate of production. Taking a Lean approach and managing WIP can remove much of this unpredictability.
What’s left then is often due to technical debt. Tech debt is a serious problem. And it adversely impacts something business folks want – predictability of rate of delivery. Hence, high-lighting the challenge to unpredictable estimates can get business stakeholders understanding why tech debt has to be paid down.
Question: Why is estimation bad and what can we learn from that?
Create smaller batches by having teams work in short iterations. While this is a good approach, it is not always the most effective. Also, if management has not aligned with the teams, it often is not really achievable. Management will often not let the teams work in a real pull mode (e.g., Scrum's pulling a sprint's worth of work) because they are getting too much pressure from the business stakeholders. Using concepts like Minimal Viable Products and teaching Lean-Flow to business executives and management can take off much of this pressure. Agile often fails because of it.
We can point to the failure of Agile in these cases by saying management didn’t let teams work the right way, but the reality is management didn’t get enrolled in the importance of small batch size. Eli Goldratt, creator of Theory of Constraints, once said “Often reducing batch size is all it takes to bring a system back into control." I have seen that managing the program level by creating smaller batches being pulled by the teams to be a much more effective, realistic approach to achieving Agile.
Question: If our teams are overworked, what is the most effective, realistic way of getting their workloads to be more sane?
While debating who is right or wrong is often fun, and often seems important, it is often better to see what the assumptions are behind our arguments and look at them. Our mindsets create the context for our thoughts. I suspect many of the assumptions we’ve made in the Agile community are not correct. At least not all of the time.