Agile Principles versus Reality
Everywhere I’ve ever worked in the last few years has said they promote Agile workflow, or have one already. A common definition of Agile in reality is:
“A process where teams work in arbitrary two-week periods (‘sprints’) toward a fixed scope and unrealistic deadline.”
How do the 12 Principles of Agile manifest in many work environments? Even ones that say they’re Agile? Sometimes (often?) in some or all of these ways. Understanding this is an important first step to improving it.
1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
The highest priority is to deliver something, valuable or otherwise, that we can sell.
2. Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
Changes aren’t to the customer’s competitive advantage, but due to other demands. The lack of true Agile process means change isn’t for the customer’s competitive advantage.
3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
Rely on large deployments that kind of work with frequent fixes.
4. Business people and developers must work together daily throughout the project.
Business people will dictate to developers regularly throughout the project.
5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
Build projects around motivated individuals. Ask too much, and fail to give them support they need. Don’t trust them to get the job done.
6. The most efficient and effective method of conveying information to and within a development team is a face-to-face conversation.
One of the principles that is most often adhered to.
7. Working software is the primary measure of progress.
Satisfying a date is the primary measure of progress.
8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
Create an environment that forces regular “crunch” times. See point 7.
9. Continuous attention to technical excellence and good design enhances agility.
Don’t allow this. See point 7.
10. Simplicity — the art of maximizing the amount of work not done — is essential.
Create a large scope of work that isn’t simple, or containable. “Avoid” past failures in incremental development by adding everything and the kitchen sink from the start.
11. The best architectures, requirements and designs emerge from self organizing teams.
Don’t let teams self organize. Dictate architectures, requirements and designs.
12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
Disempower teams so they find this difficult.
Process change is difficult. It’s even more difficult if it’s claimed that the process has already changed when it hasn’t. I’ve met few leaders or organizations that don’t pay lip service to Agile. But few leaders and organizations that trust, or are allowed to trust, the process.
Whether in small organizations or large, external pressures push back against Agile process. False predictability is often preferred to the perceived ambiguity of Agile. But Agile is more predictable in the long term.
I’ve had success in gaining benefits from Agile transformation. I’ve also had failure. It’s not organizational size. IBM has trusted me to push for change. Some of the smallest companies I’ve worked for have been the most resistant.
I’ve learned I’m more successful when I temper the ideal of Agile with the reality of circumstance. It helps to admit that we’re not Agile, and that we might never be. Then we can start to learn lessons from Agile methods which help us.
Agile is a philosophy, a way of thinking. It’s sometimes much harder to change the way people think, than to change some of the things they do. That can be a more productive first step.
I call this “How to be Agile-ish”.
