An Agile mindset is critical in modern software development and everybody who thinks differently is doomed to perish. So say the fans. Critics are appalled by such zeal and sometimes a heated discussion ensues. It doesn't help that many people with little practical experience chime in.
Bertrand Meyer tries to give a balanced assessment in his 2014 book Agile! The Good, the Hype and the Ugly. For this research he read a lot and got certified as Scrum Master. Overall, he considers Agile an important step of the evolution of software engineering but not yet perfect. As he wrote in Making Sense of Agile Methods:
Agile is not a negation of what came before. It is one more brick in the patient construction of the modern software engineering edifice.
To make it short: In my opinion the book succeeds. I don't know any other such detailed yet also balanced assessment of Agile.
The content is great but the other aspects of the book are not in my opinion. It feels rough and raw like a blog post. Not polished like a book which received multiple rounds of editing and professional layouting. Yet, it is prized expensively like a textbook.
Meyer also gave a talk which summarizes the book. If you watch that you might as well skip the rest of this blog post:
The Principles
Before Meyer addresses specific agile practices, he dares to criticises the twelve principles of the Agile Manifesto: Some of the principles are not principles but practices or assertions. Some parts are redundant. Testing is missing. One assertion is even plain wrong.
This part of the book demonstrates the clear thinking of the author and how much he cares about precise definitions. It increases my confidence that other parts of the book received equivalent care. However, it also feels nitpicky to attack something so abstract. Thankfully, Meyer tries to be constructive about it: He proposes his own definition of Agile. Note that he does not assess those as good or bad yet. At this point, Meyer just tries to define Agile better than the Agile Manifesto does it. Instead of the "individuals and interactions over processes and tools" values, here are five values of Agile:
- new, reduced role for manager
- no "big upfront" steps
- iterative development
- limited, negotiated scope
- focus on quality, achieved through testing
Derived from those values are 8 principles (5 organizational and 3 technical).
Organizational principles
- Put the customer at the center
- Accept change
- Let the team self-organize
- Maintain a sustainable pace
- Produce minimal software:
- Produce minimal functionality
- Produce only the product requested
- Develop only code and tests
Technical principles
- Develop iteratively
- Produce frequent working iterations
- Freeze requirements during iterations
- Treat tests as a key resource
- Do not start any new development until all tests pass
- Test first
- Express requirements through scenarios
So far, I have not seen anybody dare to rephrase the manifesto. It is practically treated as a holy text clear of any fault.
Now for the concrete practices. After all, one must be pragmatic eventually. To end on a positive note, we start with the negative sides of Agile.
The Bad and Ugly
For some practices, there are solid arguments by now that Agile made the wrong choice. Since each of these is worth its blog post or a few pages in the book, I'll only list the point in my own words here.
- Agile should not neglect upfront steps, specifically requirements and design.
- User stories as tasks are harmful. Instead use user stories to discover requirements.
- Agile should not neglect dependencies and foundational work. Feature-based development and ignorance of dependencies are harmful.
- Agile should not reject dependency tracking tools.
- Agile should not reject traditional manager tasks.
- Agile should not reject upfront generalization.
- Do not embedded a customer in dev team.
- Avoid coaches as separate role.
- Development should not be test-(first)-driven.
- Agile should not deprecate of documents.
One message of the book is that modern software engineering should reject these practices even if some Agile coach sells them as part of the package.
The Overhyped
Some practices and principles do not deserve the emphasis they get. Either their benefit is limited or they are only useful in certain situation but not generally.
- Pair programming
- Open-space working arrangements
- Self-organizing teams
- Working at a sustainable pace
- Producing minimal functionality
- Planning game, planning poker
- Members and observers
- Collective code ownership
- Cross-functional teams
The Good
Then there are practices which are almost universally good:
- Promote refactoring
- Short daily meetings
- Team communication
- Identifying and removing impediments
- Avoid waste
The Brilliant
Finally, we reach the actual innovation of Agile. This is the progress Agile should be praised for. Some were invented before but Agile spread them widely.
- Short iterations
- Integrate continuously and have a regression test suite
- Apply the closed-window rule
- Time-box every iteration
- Have clearly defined product owners
- Delivering working software
- Use velocity and task boards
- Associate a test with every piece of functionality
Required reading for discussing Agile in detail
For everybody who seriously wants to debate the pros and cons of Agile, this book should be required reading. There is actual substance, science, and insight in this book. Sadly, most of the industry debate is a superficial discussion what "True" Agile might be. After reading this book, I don't think any blog post could add something significant to the debate.
I also recommend this book for pragmatists who wonder what is useful in Agile. It provides a good foundation what practices to use and which to dismiss.