The term 'commitment' has a long history in Agile. The problem is, it means 'commitment to a goal', and without defining the nature of this 'goal' concept quite tightly and understanding when in fact different 'goal' concepts are being used, much misunderstanding happens.
The sense in which the term 'commitment' is used in an Agile context is 'commitment to achieving a particular business goal'. It's not a 'commitment to delivering certain deliverables in time T'.
What's the difference ? Well, this goes to the heart of what Agile is all about. If you say you can deliver X in time T, you are predicting the future, and you will never be entirely successful - frequently you will be inaccurate to some extent, because change will derail your estimates. Commitment in these terms, sometimes referred to as 'commitment to a plan', is therefore worse than pointless, since it will only lead to a false sense of certainty.
So, if we're talking about committing to a business goal, how is this a better thing ? Essentially, it's because a business goal is where you're heading, not the route you're going to take ( or how much time you will take ).
One thing that should be noted carefully here is that there can be no commitment to a goal if there is no practical way to determine if that goal has been reached. Goals need to be carefully expressed. Because commitment is deeply personal, individuals who commit to a goal must be able to understand how it will be known that the goal, which they have an ownership stake in, has been - or is being - achieved.
So here is my take on the rules of commitment for the purposes of Agile.
1. Commitment means that you personally support the goal, whatever it happens to be. Your reasons for doing so are not material here - commitment does not care about rationale or justification. It's focused on actual behaviour.
2. Commitment means that you personally will do whatever you can ( which may be defined by your role or constrained by other factors ) to help eliminate any impediments that are preventing the goal from being achieved. Every problem or item of work that lies between the current state and achievement of the goal counts as 'an impediment' in this context. If you can think of ways to speed up or simplify things by eliminating work before it is done, so much the better, this is an Agile Principle ( Principle 10 ).
3. A Commitment to a goal is not a guarantee to deliver particular functionality ( see above ) !!! A Commitment means you will use every means available to you to move towards the goal, but you are not omniscient, and the route may need to change ( meaning that the functionality, and hence work,required to achieve the goal may change ). Continually learning and adapting in pursuit of the goal is necessary, both personally and for the business.
4. Only people willing to Commit to the goal get to decide how that goal will be achieved. This is perhaps the most important - and difficult - rule of Commitments. You cannot say 'oh yes, this sounds like a good goal', fail to make any personal commitment for whatever reason, and then expect to be involved in the decisions that committed people will make. Deciding not to commit is as consequential as deciding to commit. Support in principle is not commitment.
5. Do not over - commit ! If in all likelihood you can provide little or no practical help to get the business to it's goal, don't pretend that you can. Otherwise you will just become an impediment in your own right, as people will expect your effort and support and not receive it. You are absolutely better off not committing than over committing !
Of course, there are echoes of Scrum all over this. Which is a little unfortunate, because again we need to examine the meaning of 'goal' very closely. Scrum wants each Sprint to have a 'goal'. Is this goal a 'business goal' in the sense referred to above ?
Well, it should certainly reflect the value that the team is aspiring to deliver to the business with this particular sprint. And certainly you cannot simply say 'our goal is to deliver all our story points' - that's commitment to a plan.
But it has to be recognised that a Sprint goal is specific to that sprint. It's a way of conceptualising 'what this particular sprint is all about'. In this sense it's a narrowly focused, short term goal, and perhaps it is too narrowly focused to really be a 'business goal' in the sense I've talked about above. It's purpose is to provide help for resolving both technical and planning issues that may arise during the Sprint.
There is, however, no rule that says you may only have one commitment at any one time. It's actually quite normal to have commitments to multiple goals at multiple levels of abstraction.
You may say, for example, that the business has a goal to continually improve the quality of it's product. In order to make this work, the business should make this real by identifying some metric that will be employed to measure progress in this direction. But it's perfectly reasonable to hold a commitment to this goal, whilst also committing to a sprint goal that says, for example, 'make it easier for the user to theme the interface'. As long as these goals are complementary, not contradictory, this is fine. Ensuring that this is so would be something the Scrum master should keep an eye on.
In fact, the Sprint Goal is just one of Scrum's goal types. There is also the Product Goal, which is certainly visible to developers as their final destination, although defining it is more of a concern for the Product Owner and senior management.
The concept of Level of Done is, in part, a way of translating commitments into practical tests.
The concept of the Scrum team being responsible for the 'how' of the sprint's delivery recognises the primacy of committers when deciding how to achieve a goal.
The concept of retrospective analysis is, in part, recognition that commitments to the sprint goal will not always be met, and that this should be a learning input.
The concept of team velocity is related to the importance of avoiding over-commitment.
The notion of pluripotent team members is closely linked to the idea of doing whatever you can to remove impediments.
So Scrum and commitment are tightly interwoven ideas. There is a sense in which many aspects of Scrum can be viewed as deriving from, or incorporating, Commitment based thinking.
© Mark de Roussier 2021, all rights reserved.