Within RES Software we organize every month guild sessions. A guild session is a meeting with all the professionals who work in a certain area or people who are interested in this area. We have for example guild sessions for developers, testers and scrum masters.
Every guild organizes the sessions differently. The goal of a guild session is to exchange experiences and grow knowledge in that area. It is not an update meeting about the projects where everybody is involved in.
In the Scrum master guild every participant has to facilitate a meeting. It was my turn to organize the guild session of last month.
I decided to discuss the topic commitment. Commitment in a Scrum context. We had a great discussion and it made some people think about commitment. I would like to share the session with you and maybe you also start thinking about the word commitment.
What is commitment for you? Take a few minutes to describe the word commitment for you. Is a commitment equal to a promise? Is a commitment mandatory? Can you deviate from a commitment?
When you search in Google on the definition of commitment you will get the following definitions:
- the state or quality of being dedicated to a cause, activity, etc.
- a pledge or undertaking
- an engagement or obligation that restricts freedom of action
I think the last definition comes most close to the definition as most people use it in a Scrum environment. However, should a commitment restricts freedom of action?
For most people working with Scrum the definition is something like: “Sprint commitment means, that a team promised to finish a fixed number of stories in the next iteration.”
I assume you have some experience with Scrum or software development in general. How many of the following situations do you recognize?
- I believe estimations are always wrong. As a team you should try to get 80% of the estimations close to correct in 20% of the time. Whatever you try, you will never get estimations that are 100% accurate (besides the fact this should not be the goal). How can you ask a team to make commitment on results when we all know estimations are just an estimations and never 100% correct?
- Management, Product Owners, Stakeholders, etc tend to push teams in some organizations to commit more than they would like to commit. Which team is able to say no to the CEO when he comes in and pushes the team to take that one extra user story? We all know the CEO should not do this, we all know the team should say no, that the scrum master should step in but how many teams really say no or how many scrum masters will step in and discuss this with the CEO? I think there are many teams, especially new teams, who will do what the CEO says and commit to some more work.
- People tend to be optimistic and for some reasons developers seems to be more optimistic than other people, especially when it is related to make estimations or commitments. Additionally, there are even optimistic developer…. you guess what kind of commitments they make. The intention is good. However, they will time in time be too optimistic about their commitment.
- People get sick and they, normally, don’t inform team members when they will get ill. It will happen unexpected.
- It is a good thing that many projects and software products have perfect up to date documentation. However, it seems that sometimes assumptions made on existing documentation are incorrect. The architecture was not as it was described in the documentation, the regression test plan was not updated with the last changes in the software.
- The product owner comes back from a visit to a prospect and he needs really one extra user story to be realized in this sprint. If he is able to show this user story, the prospect will buy the product.
- High priority bugs will occur and in some situations team members will need to help out. They will be involved in a task force or have to visit the customer site to solve the problem.
To summarize the above, unexpected things can and will happen! That makes software development fun and challenging 😉 However, why do we ask a development team to make commitment when we now these unexpected things can and will happen?
In the Netherlands we always talk about the weather. You want to start a conversation, just mention the weather. The weatherman gives a forecast several times a day for the next hours, days and weeks, Why does he give a forecast and not a commitment? Too many factors that will influence the weather.
Another thing that can happen in the next iteration is that a team will take shortcuts in the quality. Management expects a team to make their commitment, so the team will make their commitment…
I am not unique, more people realize giving a commitment for an iteration is a bad thing. In the begin Scrum talked about commitment. In the current Scrum Guide commitment has been changed into forecast! The Scrum Guide states:
“During the Sprint Planning the Development team works to forecast the functionality that will be developed during the Sprint”.
The following process is described in the Scrum guide:
“After the Development Team forecasts the Product Backlog items it will deliver in the Sprint, the Scrum Team crafts a Sprint Goal. The Sprint Goal is an objective that will be met within the Sprint through the implementation of the Product Backlog, and it provide guidance to the Development Team on why it is building the Increment.”
Not a word about commitment anymore!
The product owner and management should care about predictability. It is like a long-term stock investor, they don’t care so much about fluctuations with a day, week or even month, they care about the stock performance over a quarter or a year.
A team should become a reliable partner that is able to forecast their work for several sprints. This will give the business the opportunity to make a forecast for the release. A team should be demotivated by the fact they don’t meet their commitment for one sprint.
A nice quote that I found on the Internet about this topic:
Wait, don’t forget you can the word commitment! Commitment is very important. I want teams to commit to:
- deliver an usable increment at the end of an iteration
- work and grow skills like a real craftsman
- continuously inspect and adapt
- the Agile manifesto and values
Commit should be done on behavior, not on the outcome of process.
What is your opinion about commitment?
Hmm, at my place, we have many contractors coming and going. And everyone use a different scale when doing scrum poker. And because our product involves many domains, there’s typically only 1-2 domain expert, yet the story points are always lower, cuz… majority. And our KPIs are based on number of stories completed. And when a story is pulled into a sprint, it must be delivered, no matter the cost (quality, overtime, hacks, workarounds), cuz… KPIs. And if someone finishes early, they don’t start on the next story, in fear or not completing it before the sprint ends (can’t take things out, but if you pull something in, you better finish it).
Oh, and we’re expected to beat our number of completed stories each year, lest we are measured as “below average”. And the PO and SM don’t like us discussing technical details when discussing estimates. And they love to round-robin task assignments. You know, to prevent siloing while building a complex, multi-domain, multi-technology system.
I love it when I have to bounce from building DSLs and interpreters for ETL, to diagnosing customer’s production environment on Google Cloud, then back to optimizing the financial accountant’s SQL queries, and over to figuring out why our webgl charts are rendering differently from the directx ones, and finally my QA duties, because developers are responsible for their own work, and no one has time or money for QA engineers.
I love scrum.