If you are new to agile and want to understand what all the buzz is about, start by separating agile project management techniques from agile software development methods. Why the distinction? We’ve always had to think about how we manage work separately from how we actually perform the work. To really understand agile, start with the nature of the work.
For example, listen to Alan Shalloway, whose firm provides training and consulting to software development organizations and who has several influential books on the subject of agile techniques. To describe agile, Alan lists the five key questions that agile attempts to answer:
- How do we deliver value quickly to our customers?
- How do we discover as early as possible what is needed?
- How can we accelerate the learning of the development team?
- How can we ensure that the software written will be able to grow and be extended effectively when new requirements are introduced?
- How do we accurately gauge the progress we’re making in our project?
Notice that only the last question is related to project management. The other questions are about requirements analysis and product design. That suggests that organizations who are adopting agile methods should look beyond the typical Scrum techniques (project management) and make sure that developers understand agile analysis, design, and development methods. As Alan’s questions indicate, this is a highly iterative, discovery oriented methodology. To make it work, you need to know how to design and build products that can be delivered incrementally.
Classic examples of project management that include pouring a house’s concrete foundation before raising the walls makes the point that certain activities must precede other activities. But these examples also are rooted in linear development methods. Software might lend itself to incremental delivery, but if you try to deliver a house incrementally, one room at a time, it wouldn’t be pretty. And it probably wouldn’t be cheap.
Which brings us back to the real agile success factors: design and development techniques. If the essence of agile is to rapidly deliver incremental value, then we have to be able to design and deliver the product, never knowing for sure which incremental delivery will be the last. I have no problem with sprints, daily stand-ups, burn-down charts, etc., but they only make sense in the context of agile development practices.
To get a sense of how differently we need to think about building software, consider the example of a car designed with interchangeable parts. You’ve got to see it to believe it. Watch a short video.
Now THAT is new. So if your organization has an agile interest, focus first on the fundamental development methods. With those under your belt, Scrum becomes intuitive and the project management pieces fall in place.