29 Oct
Does Agile Mean No Commitments?

As Agile methodologies become a common practice there are still different interpretations and different views on implementation approaches and styles.

One of the most frequent questions I am asked about is commitment. As planning changes to sprints and tracking changes from dates to velocity, can Agile development teams commit on scope?

Many people believe that as scope is the first to be compromised when things don’t progress as expected, the answer is no. And so, development organizations that have hard commitments, struggle to be able to manage them in Agile and keep customer confident. I heard more than once developers claim they cannot commit “as they are working Agile” and explain business (or management) that with Agile you go live with whatever you have. While very partially this is true, the most important value of Agile is business satisfaction and being able to increase it, so any other result defeats the purpose.

So how should commitments in Agile be managed?

First, as this is in many ways a state of mind, the communication to teams should be refreshed. There is nothing in the Agile Manifesto that implies commitments are off, rather there are many principles that encourage increasing business value, open communication, allowing change through the project and more, all intended to deliver valuable scope per business needs.

Second, just like in traditional methodologies, we take commitment of a reasonable, sustainable plan and then manage it closely. The easiest to track and follow is to plan feature delivery per sprint. Obviously, it will have to change through the project (again just like traditional projects), and this should be where the core Agile principles are practiced – frequent communication with the business, transparency, open communication and prioritization based on business value.

As always, commitments should be agreed on high granularity level – Features/Epics. It is during the discovery that the level of coverage is agreed based on cost/capacity/impact and business priority. The Development Manager is the one who manages this process closely and tightly with the business.  

As far as methodologies – the SAFE Agile methodology is a better enabler for “hard” commitment as Project Increments (as oppose to sprints) are longer and allow time for catch up. Even if not working with SAFE, it is recommended to plan catch up sprint/s in the project plan and allow contingency time. In most cases it will be needed.

To sum. Agile core values are not about commitments or no commitments they are about increasing business satisfaction through delivering value. Having said that, development organizations can still create a solid Agile plan and support their commitments. Like always it is about – planning, tracking, changing, negotiating and reaching the best result for all given the reality developments on the ground.

* The email will not be published on the website.