are the core of XP. This level of change is too much for some teams to bear. Second, Scrum’s certification program has spawned scores of “Certified Scrum Trainers” (CSTs) who both teach Scrum and promote it. As a result, many in the industry have come to think that “going Agile” means “taking a CSM (Certified ScrumMaster) class and adopting Scrum.”
Challenges in the Agile World
Scrum has grown virally. Now, the challenges are showing up. One of the originators of Scrum, Ken Schwaber, said in an interview with Agile Collab that, “75% of organizations using Scrum will not succeed in getting the benefits that they hope for from it.”
There are many opinions about why this is the case. This article’s author posited several reasons including,
- Many problems facing development teams actually originate outside the team; for example, overloading teams by giving them too many projects at one time.
- Many large organizations have poor deployment methods that make it difficult to get software out the door. While Scrum may expose these impediments, they are difficult to solve and Scrum, in itself, does not give any insights on how to solve them.
- Many organizations have difficulty creating the cross-functional teams that Scrum requires to work. People with specialized skills, knowledge of legacy code or domain expertise are often required to be shared across teams, breaking the power of the Scrum model.
- Many teams that are new to Scrum have never been taught the principles of product development flow.
- While Scrum was originally designed for co-located teams, it is often necessary to use distributed teams.
Many Scrum aficionados claim that the real reason that organizations are not experiencing success with Scrum is that those organizations just don’t have the discipline or motivation necessary to solve their problems.
Regardless of the cause, the problem remains. To meet this challenge, two other Agile-related methods have sprung up: Lean Software Development and “A Virtual Kanban System for Software Engineering” (or ‘Kanban’ for short). Both of these methods directly address the problems that organizations are having with Scrum. It is why I started doing Lean over five years ago and Kanban about 3 years ago.
Lean Software Development
Lean Software Development is founded on the understanding that the principles of Lean manufacturing and product development methods can apply to software development. Of course, the practices are different but the mindset, the way of thinking, is the same.
Its origins date back to the mid-90s with an article by Bob Charette. It became popularized with by Mary and Tom Poppendieck’s books, the first one, Lean Software Development, An Agile Toolkit, being published in 2003 (Poppendieck amp; Poppendieck, 2003). Lean Software Development is based on the notions of eliminating waste (any effort that is not of value to the customer), optimizing the whole (going from “concept to cash”), delivering fast, building quality in, respecting people, improving relentlessly and deferring commitment until you know what you need to do.
A second camp, so to speak, has sprung up around the work of Don Reinertsen . Reinertsen approaches Lean on the basis of appreciating the system that people are working in, fostering the skills of the people you have in that systems, and attending to time by seeing how work flows through the system. By “flow,” he means to see where delays occur or where large queues form.
Regardless of which way you prefer to approach Lean, it is useful to provide insights into how to solve problems both inside and outside of the development organization. Its model of flow (focusing on fewer, smaller things in your development pipeline to get