Insanity: doing the same thing over and over and expecting a different result. Albert Einstein
In a recent blog, Insight at SQE Better Software & Agile Development Practices, I mentioned my quick poll of 250 folks at my keynote. Respondents claimed they were having success at Agile at the team level (80%), yet virtually no one claimed having success at the enterprise level. The predominant method in use at the team level is Scrum. This does not make Scrum ineffective, of course. But my – as of yet, unanswered – question in the blog is:
Why would someone expect a team-level method to work at the enterprise level? Especially when all the evidence says that it doesn’t work, and all the theory shows that one shouldn’t expect it to?
We hear explanations that software development is complex and that people are doing Scrum wrong (aka Scrum-but). I have blogs on these topics as well: People Are Complex, Software Development Isn’t and The 5 Whys of Lean as an Answer to the But of Scrum, respectively.
The reason there are so many problems at the enterprise level is that the Agile community has sold the software industry on a good solution to the wrong problem. To be clear, the intentions are good, but the correct mindset required for the enterprise is not widespread. The problem is not how to make a team effective. This has been known for 15+ years. Scrum, XP, Kanban, FDD, Crystal; any other number of methods. The problem enterprises face is two-fold: (1), how to create a big picture of what needs to happen and (2), how to transition to that future state. Unfortunately, Scrum provides little view of either. Kanban provides a bit more and is considerably more effective at the team as well. This is why I believe Kanban has been growing in popularity. However, you still need more.
Fortunately, Lean Software Development — when redefined based on an understanding of product development flow — can provide a basis for both. See Don Reinertsen’s amazing books The Principles of Product Development Flow: Second General Lean Product Development and Managing the Design Factory. The latter book is 15 years old, yet remains ahead of its time, for considerably more information. Tom Gilb’s blogs and books also provide a wealth of information.
The question to me is not so much ”what do we do? “ as much as “why isn’t it being done?” The reason is not the technology. The reason is people want solutions, not a framework for thinking. Thinking is hard work!
I've started writing up the solution that our clients have been using successfully for the last 7+ years: The Net Objectives Lean-Agile Roadmap for Achieving Enterprise Agility.
I call this "sanity" because, until we attempt to use enterprise methods at the enterprise, we're just repeating our unsuccessful history.