Software Developers
Showing results for 
Search instead for 
Do you mean 

Enterprise agile : Commitment, planning and estimations

AlonZ on ‎07-21-2013 01:08 AM

Two years ago, when we worked happily and “waterfally” on our projects, we would rarely fall short on our commitments for release content. This, of course, is due to the fact that releases only came round once every two years or so… Needless to say, the gap was always huge, and it made us look for different development methodologies. This is how we began working Agile.  Now that we release new versions on a monthly basis, we often hear complaints, “how come you didn’t finish the feature? It was part of your release backlog,” or “you are falling behind on your commitment for the sprint.”

This is very frustrating for an agile team. The way I understand Agile, and the way it is described in many popular articles (like this article by Damon P.), Commitments are more forecasts than concrete plans. So the agile team is “committed” to work (hard) according to priority, and yell if something affects the plan.

So how can we reconcile the enterprise needs to set long term goals with keeping true to our agile development methodology?

I can’t say that I have a magic solution, but I will describe some of the realizations that emerged while pushing to strike the right balance.

  1. Agile development means that developers are continuously working at a heightened level of tension, unlike in long term release development.  It is true that the stress level is steadier, but we must still take this into consideration, and be more proactive in providing our team members with ways to unwind (either by attending courses or other team activities).
  2. At the end of the day, enterprise organizations will always need visibility of the longer term goals to collaborate, for example, between different projects.
  3. Pushing to achieve commitment is dangerous, not because it does not work, but precisely because it might work… Meaning, if the estimations were too optimistic and we push the team to meet them, we will end up with a low-quality product, and reduce the engagement of our developers in the agile process.

Taking the above insights into consideration, our group has made progress on two levels towards closing the gap between agile team and enterprise requirements:

  1. Sprint level. We decided to have two types of commitment in the sprint: hard and soft. 
    The hard commitment takes up roughly 80% of the team’s velocity. The team is required to put in extra effort, if needed, to achieve the items included in the hard commitment.
    The soft commitment should also be achieved, but the team can decide on the amount of effort it will invest in order to do so.
  2. Release level. The change on this level was mainly cultural. Since we started delivering new releases each month, customers have become less forceful in their demands for definite resolution times. Moreover, severe quality issues are fixed within a day or two, helping to further relieve tension.  With the customer on our side, and a better understanding between the group stakeholders, the commitment to deliver on the release plan becomes less stringent. This provides the team with a more relaxed environment to develop complete, high quality features.


Practicing Agile in an enterprise organization with traditional customers has its challenges. But by taking the right steps, you can successfully build up a relationship of trust and visibility with customers and other stakeholders. These changes can minimize the impact of enterprise demands on the team’s agile process. 

About the Author


Nov 29 - Dec 1
Discover 2016 London
Learn how to thrive in a world of digital transformation at our biggest event of the year, Discover 2016 London, November 29 - December 1.
Read more
Each Month in 2016
Software Expert Days - 2016
Join us online to talk directly with our Software experts during online Expert Days. Find information here about past, current, and upcoming Expert Da...
Read more
View all