Chickens and Pigs Revisited
There’s been a lot of discussion on the subject of ‘chickens and pigs’ and commitment in Scrum, whether the Scrum community has a generally-agreed definition of commitment, and whether commitment is useful.
First, let’s talk about the definition of commitment, certainly a loaded word and one that is used improperly in most organizations. People commit to one another when they marry; to be faithful, and to be mutually responsible and accountable to each other. A commitment is defined, properly, as a promise to do something, not a promise to try to do something… certainly I would have found it unacceptable if my wife had promised to try to be faithful at our wedding, and likewise. Similarly, when we commit in a business situation, we are promising to do, not to try. This acknowledgement has led to the understanding that commitment is something that must be undertaken rather than imposed. To continue our marriage analogy, the people getting married have to agree to the commitment rather than having the commitment forced upon them by the other party (or a third party, perhaps with a shotgun!) if the commitment and the relationship are to have any chance of long-term viability. The same holds true in business. Lack of trust occurs when we fail to keep commitments to others, or when we fail to let people make commitments and instead force commitment upon them. The failure to deliver after a coercive commitment leads to all sorts of follow-on problems brought on by the forced commitment including low morale, low quality, increasingly ineffective communication across functional areas and leadership levels, inaccurate reporting of status, etc. The end result is an organization that continues to fail at delivering.
Next, let’s talk about who owns a commitment. Thought leaders in the Agile community recognized the issues around the dysfunctional application of commitment, and the initial solution was to let the team commit… let the people who actually have to do the work tell us what they can get done in the time allotted. This is how we work with service vendors in our private lives; no contractor would agree to remodel our kitchen without having a say on scope, schedule, and budget and would walk away if we insisted on dictating all three sides of the iron triangle regardless of his input. Why would we expect this approach to work with our software teams if it wouldn’t work with our kitchen remodeling teams? And yet, we do… because we do not understand who is responsible for commitment. This has led to one of the Ten Deadly Sins of Software Projects: confusing estimates, targets, and commitments. Estimates, or a reasoned judgment on effort, cost, and duration for work, belong to the people doing the work. In a software engineering organization, that would be the people who actually create the software… software developers and testers. Targets, or the goals of scope, schedule, and cost, belong to the people paying for the work… business stakeholders. Commitments, the promise made around what will be delivered, how long it will take, and how much it will cost, are the mutually-acceptable ‘win-win’ results resulting from negotiations between the people who do the work and the people who pay for the work that reflect a promise that the people doing the work can reasonably meet and the people paying for the work are willing to fund.
Finally, let’s discuss whether commitment is useful. Of course, it’s useful! you might say… and I would agree. How else can we hold teams accountable if we don’t get them to commit? you might continue, and this is when I would disagree. The purpose of commitment isn’t to hold people accountable… to punish them for failing. It’s to give us an idea of what the team thinks it can do… to set a baseline for comparison, and to give the team a goal to strive for. Forget Scrum for a moment. Don’t we all have a commitment that we make every day to our employer, to come in and do as much as we can, with quality, each and every day? I believe so, and teach and coach accordingly. In an organization where people are committed to doing their best each and every day, the result is that whatever can be done given the current approach will be done. Accordingly, the commitment we make in Scrum at each sprint planning meeting is a commitment by the team to the team that the team will work together on the specific items in the sprint backlog and fully believes they can implement those items to the level of quality needed to be potentially shippable by the end of the sprint. What is great about the sprint commitment is that it is necessary for Scrum’s inspect-and-adapt framework (PDCA) to function. The sprint commitment is our ‘Plan’ in PDCA, the hypothesis that we will evaluate against later: we believe that we can deliver the committed items within the confines of our sprint based upon what we know today. Now we can run the sprint as an experiment to see if our hypothesis, our belief, is justified. At the end of the sprint, we either met the commitment or we didn’t. If we did, did we really learn anything? But, if we didn’t, now we know something we didn’t know before… we know that our hypothesis was wrong. This is great information for our sprint retrospective, because now we can actually seek to understand why we thought what we did, and what we know now that, had we known it at sprint planning we would have not made the commitment. This is the start of improving our capability to deliver, this simple question: what are we going to do differently from now on based upon our learning?
That is why commitment is useful. In my opinion, that is why the ‘chickens and pigs’ concept is useful. Yes, it’s corny and dated, but it drives home the point to both team and management that the team owns the commitment, must strive to meet the commitment, and must drive for understanding and resolution when a commitment isn’t made so the same mistakes aren’t repeated endlessly. Something else to point out: ‘classic’ Scrum as described in Schwaber’s 2001 book defined the ‘Scrum team’ as the 5 to 9 developers who actually implement the software and were part of the ‘Delivery team’ (Scrum team plus PO and Scrum Master), while today’s Scrum Guide defines the ‘Scrum team’ as the ‘Development team’ (the 5 to 10 developers who actually implement the software) plus the PO and Scrum Master. Why this was done is open to speculation; I tend to believe the change was made to address dysfunctional teams that felt they could ignore POs and Scrum Masters, and to ‘create a bigger tent’ (increase the feeling of inclusiveness). I prefer the ‘classic’ definition as it clearly identifies who owns setting the commitment (the people who do the work) and excludes the PO and Scrum Master; the revised definition muddies the water, unfortunately. What about when the PO doesn’t agree and won’t accept the team’s commitment? That is a sign of dysfunction, and in my experience is better addressed by not redefining who gets to make the commitment… and is perhaps a subject for another blogpost.