Increasingly, I find that ‘Agile’ is essentially a modern day metaphor for Communication. There are volumes of books on the topic. Strong evangelists and enthusiasts. Devotees to a new process. Yet, if you boil it down, it always reduces to Agile==Communication.
Earlier this week I had the privilege of attending the regular Ann Arbor Agile Groupies event. The focus was fiat deadlines lead to disaster. For two hours, we traded stories of how arbitrarily set dates led to all manner of disaster: destroying morale, missing delivery dates, being massively over budget, and/or delivery crappy software.
We should probably make sure everyone understands what a ‘fiat deadline’ is, so we’re all on the same page.
In software development (elsewhere too, just with different terms) there is a concept known as the Iron Triangle. In short, all projects (e.g. product being built) are subject to the same constraints. They are:
What you’re going to do. Specifically.
What you need in order to do it.
How long you need to finish.
The triangle is rigid and within it is Quality. Delivering a quality product demands a tight link between Scope, Time, and Resources.
Scott Ambler writes a good piece, specific to software, in The “Broken Iron Triangle” Software Development Anti-pattern http://bit.ly/Juk4OR
Having laid the foundation then, a fiat deadline, is one set without understanding the inputs required to deliver. If management declares when a project will be completed by a specific time, without knowing or understanding the corners of the respective iron triangle, they have created a fiat deadline.
You’ve Seen It Before
Many of us have seen these situations. A team is working on a new product suddenly a new deadline is set. Or, perhaps the team is halved or scrambled. Or, the deadline stays the same but a ‘bunch’ of new ‘mandatory’ features are added. The variations are infinite. The result is invariably the same though: The iron cross becomes distorted, broken, and projects become late, over budget, and failing to deliver the expected features. Quality, customer satisfaction, and profitability all suffer.
One of Agile’s key promises is for development/engineering to be more responsive to never-ending change, mitigating damage to the iron cross. (A crude overview for those new to Agile…) This is done by working as small teams, in open-space environments, breaking projects into ever-smaller chunks (sprints) of work. To make sure everyone knows what is going on, members frequently (at least daily) do ‘stand up’ meetings, tell everyone else what it is that they are doing at the moment and maybe for the next couple days.
The problems, as this week’s discussion (fiat…disaster) unveiled, even when practicing Agile, all the same disasters can—and do—keep happening. While many crises are mitigated, the magnitude of ‘disasters’ still exist.
Through all of this, the key to success ultimately lays with frequent, transparent, communication. Product Owners need to let their teams know about what’s going on outside the company, and the potential changes that may occur. Development teams need to accurately forecast their work, and make sure the product owners understand their constraints and ability to deliver. Together, everyone needs to agree, to negotiate, what the project’s scope will be.
For instance, Agile purists will decry those who do ‘checklist’ Agile. In other words, teams ‘going through the motions,’ checking things off (see, we did it), but not really living in the dream. What’s the dream: For everyone to freely communicate, to minimize or eliminate surprises, so the end deliverable matches everyone’s expectations.
In the end, the team that has more, better, transparent communication, will outperform any lesser team. Whether they practice ‘agile,’ or not.
What are your thoughts? If you’re using Agile, thinking about these issues, then you almost certainly have experiences and an opinion. Leave a comment and let everyone know what you think!