Given the current state of Agile this is a very reasonable belief for many folks to have. And, for many folks, it would be correct. But many folks are also working off of misunderstandings and old information when they judge whether Agile will work for them. Let’s at least clear some things up about Agile before we discuss where it will and won’t work. Then, we’ll open up a new question – is there another approach that incorporates some of the best of Agile methods but extends it with thinking that will enable this new method to work anywhere?
Misunderstandings of Agile
At Net Objectives we’ve been doing Lean (we’ll get to what Lean is a little later) and/or Agile methods for over 13 years. We’ve seen a lot of silly things being said about it. It is only natural that many folks have misimpressions of it through no fault of their own. First, let me list a few and simply state these are not true:
- Agile requires you to release every 2-4 weeks
- Agile says to not do up-front design
- Agile says to not look ahead for planning
- Agile says not to document anything
- Agile says teams get to do what they want
- Agile only works for software
- Agile does not have a place for management
I don’t doubt people have been told these things by people who should know better. But be assured that no one at Net Objectives believes any of these. However, these don’t mean that Agile will work everywhere.
Where Agile Doesn’t Work Well
We have seen many places it won’t. Be clear, I’m not talking about will it work at a team level – it typically will. I’m talking about taking it beyond the team and working on a project/product level that involves many teams. Here are a few:
- Large organizations that require significant collaboration between teams
- Large organizations that require consistent architectures across teams
- Organizations that have several stakeholders who decide what to work on
- Teams that require sharing a significant number of people who have special skills, domain knowledge or knowledge of legacy code
- Companies developing hardware and the embedded software that drives it
First generation Agile (a la Scrum) will have troubles in these situations because:
- It requires cross-functional teams (that is, teams that have all of the skills needed to produce the result). These are often virtually impossible to create
- It is defined on practices requiring all work be completed at regular times (every 2-4 weeks, called iterations). This causes two challenges:
- It makes it difficult to work with teams that are not Agile
- It requires many different things to happen at the same time – which can be very difficult
- It doesn’t explicitly discuss the principles on which it is based, making it difficult to adjust when needed
- It prescribes a team-level start with a follow up of spreading across teams – that is, a bottom up approach to scaling
- The requirements for starting often requires significant change to structure and roles for companies – resulting in an uncomfortable level of change to people who therefore resist it
- It does not provide enough visibility to executives or stakeholders as to how teams must work. This often results in executives continuing to interfere with the teams instead of creating an environment where they could work better.
- It does not attend to a company’s existing culture but instead requires a particular way of doing work.
There are certainly others, but these are the main ones we’ve seen. As I mentioned earlier, we’ve been doing Agile for over 13 years. We had found great success with Scrum for the first 4-5 years of us using it. But when we ran into the above situations we could not help our clients as we had been able to do before. This is when we started looking into Lean methods. Lean provides a significant number of insights, practices and principles that have enabled us to get around the limitations of first generation Agile methods. To distinguish between the two we call this new method of doing Agile within the auspices of Lean-Thinking “Lean-Agile.”
Lean in a Nutshell
First, let me describe Lean in a nutshell. I don’t want to describe Lean as it is often described – Toyota’s method of doing manufacturing and product development – because we aren’t doing manufacturing nor developing physical products. We’re either writing software that supports our services (IT) or software that supports other people’s work (software products). A better way to look at Lean is that it is based on the following mindset:
- Most errors are due to the system within which people work, not due to the people themselves (that is, if you put people in a bad system you will get bad results)
- One must take an holistic view of the problem and use the time from the concept of an idea until it is consumed as the overriding metric
- Delays in the workflow (e.g., waiting for others or being interrupted yourself because others need you) cause extra work to take place (waste)
- Working on too many things inherently causes delays (this does not mean people should only work on one thing, but rather you shouldn’t work on more than is best for them)
- In order to manage your work you must be able to see it – both the work being done and the way in which the work is done
- The focus should be on getting things done at the right time more than on keeping people busy
- Focusing on productivity only results in people working on too many things which causes delays (they aren’t available when needed causing delays for others and others aren’t available when needed causing delays for them – all of which causes extra work)
- People need to change at a pace they can sustain – large initiatives sometimes work but are often resisted by folks who just try to “outlast” the initiative
- The role of management
This mindset alone can result in significant productivity improvements because the holistic approach on time changes how people look at their challenges. However, Lean provides a significant number of insights that are particularly useful to eliminate delays and thereby eliminate the extra work they create. This extra work includes:
- Redoing requirements
- Thrashing when different teams attempt to integrate their code
- The extra time it takes to find/fix bugs because they were found late (even if before release)
- Building things that were thought to be needed but were discovered not to be needed after they were delivered
- The extra time it takes to make code changes due to complex code due to the system being larger than it should be
Why Lean-Agile Can Work While Agile May Not
Lean-Agile can work where first generation Agile methods may fail because it is based on principles that allow you to minimize the wastes previously mentioned. These principles apply everywhere, albeit they must be applied differently in different situations. Lean-Agile software development practices are now mature enough to give great guidance on how to apply them in many different situations. Most importantly, the way you transition to Lean-Agile methods is under your control. It does not require a big jump with the sometimes corresponding big resistance. It provides methods to see how work is being done and then letting people make continuous improvements over time. This leads to sustainable improvement and allows the organization to come up with solutions that will work for them.
By taking an holistic view, Lean-Agile also overcomes the problem of local-optimization that often occurs in pilots only considering team success. These early successes often work against long term success because they don’t address the true root cause of the challenges of the organization. The initial success often leads to a misunderstanding of what needs to be done. Success at the team often leads to an adoption of team based methods that will not achieve success solving cross-team challenges. Unfortunately, this early team success often slows adoption of methods that are more inclusive to management.
How to Tell if Lean-Agile Will Work For You
This article is not intended to provide the insights to eliminate most of this waste (see our Lean-Agile Software Development: Achieving Enterprise Agility for some of that). However, to see if Lean-Agile methods may work for you, ask yourself the following questions:
- Would it be helpful to lower the times your folks wait for others?
- Would it be helpful to lower the number of times your folks are interrupted by others?
- Would it be helpful to get a clear understanding of requirements before building something?
- Would it be helpful to coordinate how hardware and software developers worked together when building embedded systems
The result of these improvements is to raise productivity by lowering the amount of work that is created via delay or building things that aren’t really needed. This raises productivity, lowers cost and speeds time to market.
Where to Learn More
You can look at our Articles page or our Blogs for more information on a variety of topics.
Articles of particular interest are:
- The Business Case for Agility. We cover the five most important reasons for going Agile and how it is that understanding the whys of Agile helps you with this transition.
- An Overview of Lean-Agile Methods. Alan Shalloway. 9/10. This article provides an overview of the more popular Lean-Agile methods of the last decade, including XP, Scrum, Kanban and Lean.
- Where to Begin Your Transition to Lean-Agile. Alan Shalloway. 12/09. Too many organizations assume that the place to start their Agile transition is at the team. It often is not. This article discusses what to consider when starting a transition to Agile methods.
- Becoming Lean - The Why, What and How. Alan Shalloway. 12/10. This article presents a different way of looking at Lean Software Development - one that is independent of Lean's manufacturing heritage. It begins by presenting Lean as a collection of a body of knowledge applying Lean principles to software development. It then shows how this creates a new paradigm of management, one that does not inevitably lead to micro-management or chaos. Finally, it concludes with a discussion about how organizations can use Lean to improve their ability to learn.
- Demystifying Kanban. This article describes Kanban as a systems approach to software development that affects many different types of behaviors. It also mentions a few of the common misconceptions people have about Kanban in order to help clarify what Kanban is and is not.
Blogs of particular interest are:
For an overview of first and second generation methods, see the recording of Lean-Agile: The Next Generation of Agile from our Lean-Agile at Scale and at the Team: The Value Stream Series.
Please feel free to contact me at alshall AT netobjectives.com if you have questions or concerns about transition to Lean and or Agile methods.
CEO, Net Objectives