"We can't solve problems by using the same kind of thinking we used when we created them." – Albert Einstein
If Agile is going to make a difference to an organization, it must accomplish two things. First, it must assist us in being driven by business needs – not the development organization. Second, it must help us with the entire value stream – not merely part of it. All too many organizations start and achieve seeming success with team centric pilot projects. Yet, many of these do not have a positive impact to the bottom line of the organization. Lean can assist Agile methods by providing a broader perspective in what needs to be looked at – both in the value stream and in how to achieve the transition itself. Thus we must turn scaling agility on its head and think about agility at scale right from the beginning with Lean-Agile.
It is often forgotten that software, by itself, is useless. Software is only of value in how it provides value to those using it. Unfortunately, we see violations of this simple principle over and over again. It can be argued that the mere separation of business from IT is an example of this. Why do we have two organizations when there is only one business? In product companies, the situation is somewhat better, but the problem is still mostly there. While Agile methods have greatly enhanced the capabilities of teams, it is time now for Lean thinking to provide insights of how to attend to the entire value stream in order to maximize the value of software development delivered. This presents us with an opportunity to reunite the business and software development organizations so our Application Lifecycle Management (ALM) can focus on value, not merely software, delivered.
For each success you hear in the Agile world, it seems there are a few others that don’t reach as high. We must learn why some Agile projects succeed while others fail. Does failure occur merely because the organization does not have the wherewithal to become Agile? Or is there something wrong with Agile methods that do not allow them to be successful under certain circumstances? I think these are important questions to delve into.
My personal story speaks to the dangers of thinking the success you had is the success others need. I formed Net Objectives in 1999 as an organization devoted to assisting developers in better design and coding methods. This was where I had the greatest experience – and success – almost 30 years as a developer, software architect and C-level of small software product and IT organizations. Being a consultant, however, gave me a different perspective. Instead of seeing only 1-2 projects a year, I now saw dozens. This enabled me to see the challenges of a large variety of organizations.
This broader perspective quickly taught us that although the drama was often with the developers and testers when the deadline loomed the real problems for many organization lay outside of this area. Over the years I’ve progressed from focusing on the development team to looking at how requirements were created to looking at the testing organization, to project management, to product portfolio management, to deployment and support. Each year seemed to extend my view of the value stream up towards the business side and down towards deployment and support – finding new challenges at each step of the way. This broad view taught me one irrefutable truth – the major blockage in your development organization can occur anywhere – and most methods, e.g., design patterns, XP, Scrum, even Kanban, only deal with part of your value stream. It also emphasized that when different parts of the value stream focus on different objectives, the value delivered to the customer is less than it could have been.
Insights From Lean
I observed this phenomenon because we kept finding teams that our previously successful methods could not help. As time went on, however, I saw that a few principles of Lean, as I learned them in a deeper way, seemed to always apply and to always provide insights into how to overcome these disparate challenges. The primary insights were:
- look to see how to shorten the cycle time (time from idea concept to customer consumption)
- be wary of improvements achieved by focusing on one area – they could adversely affect other areas – that is, one must look at optimizing the whole, not one section
- be aware that the source of