Agile and Lean - Closer than you think
Agile and Lean - Closer than you think
Join the DZone community and get the full member experience.Join For Free
[Latest Guide] Ship faster because you know more, not because you are rushing. Get actionable insights from 7 million commits and 85,000+ software engineers, to increase your team's velocity. Brought to you in partnership with GitPrime.
Sara Peyton published a really informative blog on Lean Software development. Essentially it's a pretty detailed overview of the characteristics of Lean. The point of the blog however is to outline the differences between Agile and Lean. As Sara points out, "Agile has a different perspective from Lean and, generally, has a narrower focus".
Whilst I agree with the fact that Lean is much more broad, there are more similarities with Agile than one would expect. If we examine each of the 7 principles discussed in this blog, and relate them to Agile it's pretty obvious to me that Lean and Agile go hand in hand. Now when I speak of Agile, let me clarify what I mean.
In my world, Agile = Scrum + XP + TDD (please don't for one minute take this to mean a definition of what Agile is - that's not what I am trying to say here);
Where Scrum provides a framework for an Agile process, and XP and TDD provide the engineering rigor which you need to ensure the codebase is agile. Without an Agile codebase, you cannot even pretend to be Agile.
Taking the 7 Lean principles as depicted in the article…
Category 1: Eliminate waste
Here, Sara talk about defects, extra features, hand-offs, delays, Inventory (or partially completed work) and task switching.
One of the key principles behind Scrum is the notion of ensuring that work is fully completed at the end of each iteration. This means you have potentially shippable code at the end of every iteration. The Scrum experts refer to this as “Done”. “Done” means, coded to standards, documented, unit-tested, functionally tested, regression tested and ready to go. Sticking to the true meaning of “Done” will ensure that you have minimal to no bugs, and your code will be clean, maintainable and hopefully defect free.
The fact that the code is documented means that you're eliminating problems with handoffs. In addition, Scrum Teams are cross functional and estimating and planning is usually done as a cross functional exercise. This ensures that all team members are in sync and that handoffs between the various disciplines are smooth.
Scrum also intentionally forces teams to ruthlessly focus on the highest priority items first. This ensures that you're not working on “extra” less important features.
Lastly (not to belabor this point), Scrum strongly recommends that Team members assign themselves tasks as they become available rather than being assigned tasks, which avoids the task switching Sara speaks to in this section.
Category 2: Build quality In
Although there is no mention of Quality in the Agile manifesto all Scrum coaches, books and courses, all speak to Quality being the most important aspect of ensuring you're continuously Agile. Without unit tests, functional tests, integration tests and regression tests you can't ever be sure that your codebase is solid, clean and maintainable and that making a code change isn’t going to break things. In my opinion Quality is the number one pre-requisite of being Agile. Quality is a key aspect of being “Done”.
Category 3: Create Knowledge
Scrum more than anything is a learning process. It is specifically designed for the purpose of learning and adapting. Scrum defines a number of ceremonies to inspect and adapt. Besides the Sprint planning meeting and the daily scrum meetings to surface issues, Scrum also includes the retrospective at the end of every Sprint designed for teams to learn from their mistakes. When I did my Scrum certification with Ken Schwaber, I recall him saying that no two companies should be practicing Scrum in the exact same way. Scrum was purposely designed with "holes" so that each individual team can tailor the process to their situation. These ceromonies are all designed to help teams learn as they go and to build the Scrum process to tailored to their own specific needs.
Category 4: Defer commitment
Scrum is inherently an iterative incremental process. It is designed for teams to learn as they go along. Scrum teams typically don't do a whole lot of up-front planning. Rather, elaboration of features and planning is done at the last responsible moment just before the start of the Sprint.
Category 5: Deliver fast
Scrum is not just about Speed (refer my earlier blog post - http://blog.agilebuddy.com/2009/01/agile-is-not-just-about-speed.html), it is however all about getting the highest priority work into the hands of customers sooner and more frequently. Speed is therefore an important part of Scrum.
Category 6: Respect People
One of the core principles of Scrum is to “Value Individuals and Interactions over Processes and Tools”. This means that people are extremely important in Scrum. Scrum is all about people interacting and trusting the team to figure out how to get the job done. Scrum is built on the principles of servant leadership, which by definition means respecting and trusting individuals that they are in the best position to make the right decisions as they’re actually doing the work.
Category 7: Optimize the Whole
Scrum doesn't optimize for the whole - I agree. It is designed to deal more with the software development process. But Scrum can be used to manage other aspects of the business outside of software development and fits well with many other methodologies like Lean for example.
Based on the above, I truly the believe that Agile (Scrum + XP + TDD) is a lot closer to Lean that one would like to believe.
Written by: Jack Milunksy - COO at Brightspark and Co-founder of Agilebuddy (An Agile project management tool, built with rich collaboration features for Scrum teams). For more from Jack please visit: www.twitter.com/agilebuddy and blog.agilebuddy.com
Opinions expressed by DZone contributors are their own.