Five Reasons Why Agile is Lean
By Greg Gehrich
Lean Product Development Leader
Reposted with permission from http://www.greg-gehrich.com/2012/06/x-reasons-why-agile-is-lean.html
Agile practices are leaner than a traditional Software Development Life Cycle (SDLC). Here’s five reasons why:
- Less documentation
- Less project management
- Strong base to build on
- Early learning
- Less multitasking
The non-agile, traditional development cycle can be broken down into three major activities: Define, Design and Document.
- Define. Gather requirements from outside and inside customers.
- Design. Figure out how requirements need to be built.
- Document. Document the discovery in Define and Design steps.
- Repeat until all requirements are defined, designed and documented.
The figure above shows these three steps in a spiral pattern. It represents the continuous effort that goes into documenting the functionality that will make up features, and eventually a product. Now let’s see why agile is different.
Documentation and Project Management
In the non-agile world, project management is the necessary glue that holds together the hundreds of layers in the requirements ball, the one who keeps everyone up to speed on the ball’s progress, and the person responsible for unwinding it as the requirements are built. As the spiral layers more and more functionality onto the requirements, it becomes more dense, opaque and unwieldy, and resource intensive.
In Agile product development, there is no large ball to document or manage. The agile cycle is define-design-build for each bit of functionality. Since the functionality is limited, it’s easy to understand, and requires little documentation and management. The scrum master handles the few project management tasks that are needed to keep the small agile cycle moving along.
Base of working software
As the spiral builds new functionality with new layers, it has to work with all of the inner layers below it. As the layers grow into the hundreds, there is a lot of overhead to keep everything interacting harmoniously. Keep in mind, it’s all theoretical interaction at this point. There’s no way to test it, until the build at the very end of the process–when everything is interacting for the first time.
The agile practice is to build working software iteratively as you learn about customer needs. Issues are resolved quickly when there is a stable base of working software (because it has been customer validated) for each new build to test against. Agile efficiently tests the anticipated harmony with real-world experience.
Learning
Traditional development is designed to have learning at the front end of each function–by talking to the customer to determine their needs–and again at the very end, after all functions are built. In actual process, some learning does happen after the design-define-document layer is complete. The learning may come from additional customer conversations, insights from problem-adjacent team conversations, or just your brain working on the problem in the background. Going back and changing the requirements for an inner function incurs a heavy overhead from the theoretical interactions with all the other untested layers.
In agile, each function has learning up front, a build in the middle, and a validation at the end. Since the customer typically has working software to experience the functionality, and is saying “yes” or “no” to each one as it’s completed, it’s less likely to need revisions later on. The customer validation after each new build increases learning earlier in the process and makes the product more accurate. An accurate product gets traction faster, uses less resources and is lean.
Multitasking
The latest research on multitasking shows that while we feel productive, the opposite is true. According to a recent study by Zheng Wang, assistant professor of communication at Ohio State University, we feel productive because multitasking is emotionally satisfying.
When we use agile to build a product iteratively, the mental model we hold in our head for each sprint is much smaller than the large, traditional requirements ball. Less requirements and their interactions means less multitasking.
About The Author
Greg Gehrich is a respected Lean Product Development Leader with more than 15 years of experience managing software development and product management for various size organizations. He sits on the board and provides product advisory for startups and established businesses seeking to implement lean innovation.
He is the author of Build It Like A Startup – Lean Product Innovation. Read more from Gehrich on his blog, http://www.greg-gehrich.com/, learn more at his site http://www.lean-product-innovation.com/
