CEO asks Scrum Master for cause for small increment, who is responsible
Everyone is disappointed with the small number of completed items in the first Sprint. The CEO asks the Scrum Master for an explanation on who is responsible for this. What should she reply?
A. All three roles are responsible
B. The Development Team is responsible
C. Two of the Development Team members that were sick for a number of days through the Sprint are responsible
D. Product Owner has the primary responsibility
I felt the answer is B: The Development Team is responsible, Because Scrum guide says the Dev team is solely responsible for the 'Done' increment of Product. However, this paints Dev team in bad light and may cause rebuke from Dev Team and tossing blame will hamper the productivity.
I feel the question is really badly worded, however a really a practical one. Please help.
Might the answers be as poorly composed as the question?
Some points to consider:
- If “everyone” is disappointed, might “everyone” be responsible for finding improvement?
- If the CEO is looking for an explanation, why? What particular responsibility - or accountability - might he or she have in regards to organizational change?
- How can the SM make best use of having CEO access?
I think this question is poorly phrased and there's insufficient context.
The first thing that stands out is the focus on the small number of items completed. Why does the number of items matter? The number of items isn't representative of the value or impact of those items on the various stakeholders. How much value was delivered to users? What did the team learn about or enable with respect to future work? Delivering value - to the users, to the Product Owner, to the Development Team - is where the focus needs to be, and not on the quantity of work items completed.
The problem also calls out the fact that it is the first Sprint. How long has the team worked together? How familiar are the team members with the context - the environment, the problem domain, the processes, the tools? The team may very well be in a learning phase. As a team, they could still be in a forming or norming phase and not yet highly efficient. They may also be learning more about the context in which they are working.
Even if the team is already in a performing phase and working in a familiar context, the first Sprints are always more difficult. Even with experience working together and an understanding of the context, Scrum (and, more generally, the agile methods) are applied in areas with greater amounts of uncertainty. There may simply be additional uncertainty as the team discovers an initial path forward.
This situation may be practical, but I think it's more indicative of a CEO who doesn't understand agile methods or Scrum and not something that is the responsibility of the Development Team. This should be revisited in another 2 or 3 Sprints. By this point, the team should have had the opportunity to improve. They would have developed a deeper understanding of the Product Backlog, gone through Sprint Retrospectives to improve their way of working, and begun to cut through some of the short-term uncertainty and ambiguities.
Why is the CEO worried if it was the only the first sprint? What is small number to him? As what the others mentioned above, there might be other factors to consider beside being the first sprint.
Who is responsible for maximizing the value of the product resulting from work of the Development Team ?
Where did this question come from?
I second @Curtis Slough's question because I want to warn people to avoid the site.
That question is very poorly constructed because it lacks a lot of context and it lacks the correct answer. The correct answer is
E. The Scrum Master should take the opportunity to coach the CEO on how Scrum doesn't measure number of items and measures value delivery instead.
For example...the team only completed 2 items but they were able to deliver solutions for the 2 bugs that have caused the largest number of support calls in the last 3 months. Is that bad?
Well of course, nobody knows the answer in this hypothetical scenario.
But it is possible that the team took decisions to restrict delivery in the current sprint, in order to allow faster innovation later on.
Taken to its extreme, this starts to resemble Big Design Up Front, but finding the right balance is possible, and it's a trade-off that many teams have to confront.
This becomes particularly relevant if someone is accountable for the delivery of value over both the short and long term.
Velocity becomes more consistent as a team matures together. There has got to be a learning/ramp-up/gelling period.
Scrum allows for heavy team interaction and instant connection. Sprint 1 for a new team, new product, new company is always messy.
To answer your question, the responsibility of a lackluster result is owned by the team.
Tell the CEO to calm down, support scrum, make sure the team is releasing potentially releasable software each iteration and keep your devs happy.
The worst way a Scrum Master could reply is saying the development team is responsible for this. The SM protects the team, we don't throw them under the bus.
Are your feathers comfortable? Great, I'm going to ruffle them like crazy... The party ultimately responsible in this scenario is the Scrum Master. Hold on, hold on, don't start ranting about this yet, hear me out.
The CEO has a certain expectation for Scrum and the team. Is it wrong for the CEO to have that expectation, especially given it's the first sprint? NOPE! The SM is responsible for coaching the organization to learn and adopt an Agile Mindset & Principles, as well as understanding the Scrum Framework. Clearly, the SM in this scenario has not done that. The SM didn't work with leadership or the team (considering it says "everybody is disappointed") to understand that Scrum is about delivering a valuable increment of working software, it not about delivering a bunch of backlog items. Scrum is not about quantity of backlog items but value delivered to the customer. Value is relative and does not equate to a number of backlog items. Value can be delivered in 25 backlog items or a single item.
A previous mentor of mine always said "Disappointments come when expectations aren't met", had the SM worked to ensure that expectations were set appropriately; this wouldn't be an issue and there wouldn't be any disappointments.
@Curtis Slough. Full disclosure. I will be stealing that explanation for future discussions. That was very well said.
@Daniel, do it my friend!