Over the years, I have participated in, listened in on and watched many discussions about Why people have problems with Scrum.
This is not another post about the WHY of Scrum in an organization (which cannot be ignored!). It is possible that the appropriate thing to do might be to avoid using Scrum if the organization does not want to use it.
This post is based on the assumption there is Willingness to do so and a Sense of Urgency. I will review some concepts based on this assumption.
Consider the following examples;
- We are doing Scrum but don't have Product Owners
- We are doing Scrum but don't have a Scrum Master
- We are doing Scrum but we don't want to do the Sprint Review
- We are doing Scrum but we don't have cross-functional teams
- We are doing Scrum but we don't want to have fixed Sprint Time-boxes
(there are of course, many more)
I will use the Sprint Review to expose some thoughts on the matter.
The Sprint Review is a fixed time at the end of the Sprint. Team members can show what they have created as a team during the previous iteration.
Some of the benefits of the Sprint Review include but are not limited to;
For the Team;
Possible Response: To deliver value to stakeholders each sprint, hard changes need to be made to the way software is created. This is the point. The goal is to adjust practices and procedures to learn how to deliver working software with a high (and reliable) delivery rate.
It is fundamental that feedback be given by stakeholders early.
Possible Response: As teams learn to work in a Scrum Timebox, they need to learn new ways of coding, testing, communicating, code check in, pairing, documenting, etc. etc. This is not easy. They will make mistakes and have problems (especially at first).
Show the teams support as their skills improve. Removing the need to show progress may only increase the amount of time until code quality improves. Let everyone share in the success as you move forward.
Once the teams finally have it, it may be hard to get a rhythm going again, especially after previous reviews did not validate that mistakes are OK. This gives a perception that reviews are only to show successes. It needs to be safe to try new things and fail.
Possible Response: To do Scrum effectively, you need cross-functional teams that have the skills necessary to finish a deliverable completely. By embracing this idea, it aids in the removal of complexity by changing the traditional mindset of large build-up needed before coding can begin.
If a team is not delivering enough during a Sprint because it is too small or does not have cross-functional team membership, Scrum will continue to be noneffective for the organization.
Even worse...When this problem eventually gets fixed, there will be no cadence and process that people are comfortable with to support the efficient exchange of information when it is really needed! The learning will have to happen when a very expensive resource (a whole team) is looking for ways to communicate, inspect and adapt and has to start training the organization about reviews.
Please note, even a small team can create havoc for the future of the project without any peer and stakeholder feedback. The size does not remove the need for the feedback.
Possible Response: This is what Scrum is supposed to do. We want to know now that what is being delivered is not the appropriate product and re-align the teams and product to what is expected.
By eliminating the vital feedback in a shared, focused setting, all the communication is moved into underground or other meetings without a clear vision by all those involved.
Some of us have been accused of "not trying to be a good team player" or "not working with Scrum to make it work in the organization".
The organization thinks Scrum is a Silver Bullet that should just work as a "tool". This is sadly, a contributing factor to this issue, but let's stay away from that discussion for now.
Scrum exposes problems. It does not fix them. Removing an event from Scrum because it shows a problem only serves to move that problem underground and hide it.
By removing the Sprint Review as intended, here is what you could end up with;
(Remember, these will all be replaced with other non-focused ways of communicating or achieving these, therefore creating a double-burden on the company. The Scrum framework itself consumes a large amount of time. Not using the Scrum events as intended is a huge form of waste).
Try this on for size next time you need to explain why something isn't working when part of Scrum is being ignored.
Then, at least everyone will be talking honestly. Instead of making up a solution; Give this a try... (say it with me)....
by Mike Caspar
The Sprint Review is a fixed time at the end of the Sprint. Team members can show what they have created as a team during the previous iteration.
Some of the benefits of the Sprint Review include but are not limited to;
For the Team;
- A sense of accomplishment and reward
- Motivation knowing that management and other teams are excited about their work
- Real feedback as to how to improve the product
- Ability to share their progress with others in the company
- An increased overall level of understanding between teams
- Shared ownership between the team and the stakeholders improve relations between teams and stakeholders
For the Product:
- Constantly evolving product based on inspecting what was completed by a group of peers and then adapting to improve the product based on that feedback
- Early removal of risks by attempts to deliver a complete slice of user functionality as early as possible and preferably every sprint.
- Attacking technical risks by focusing on the highest ROI (return on investment) items first reduces overall product risk while building "product knowledge" as those risks are mitigated.
- A true status of where the product is by demonstrating finished functionality that can be used.
For the Company
- The ability to have a focused ceremony towards the specifics of what was just created and to have a shared vision of where things might go from here.
- A Cadence or "heart beat" where people know they will have an opportunity to learn what has been created without having "fear that they missed something".
- A common place for all involved stakeholders and team members to see what teams are up to.
- The ability for team members, and stakeholders to have one place to gather all the information they need to have a true idea of where they are at.
- A forum to present obstacles the team is facing to all stakeholders in a targeted way.
- To show other impediments to the efficient delivery of complex software.
To continue our scenario;
A senior manager decides that they will "cancel the review for now" because of one of these perceived problems....
- Product being delivered or shown gives no value to stakeholders
- Product has many bugs during the demo
- Team is not showing enough functionality because it is too small or not-cross functional.
- Product is not aligned with stakeholder vision and is upsetting to them
Scrum has done exactly what it is supposed to do. It has identified obstacles to the efficient delivery of software and is expecting that you actually correct these things.
Problem: Product being delivered or shown gives no value to stakeholders
A common response: "Well, we'll just stop the review because we're not showing value each Sprint.. Let's come back to the reviews when we are ready"
Possible Response: To deliver value to stakeholders each sprint, hard changes need to be made to the way software is created. This is the point. The goal is to adjust practices and procedures to learn how to deliver working software with a high (and reliable) delivery rate.
It is fundamental that feedback be given by stakeholders early.
Problem : The product has many bugs during the demo
A common reaction: "We will have to stop the reviews until we learn how to make reliable software. We don't want to show our real progress to our stakeholders".
Possible Response: As teams learn to work in a Scrum Timebox, they need to learn new ways of coding, testing, communicating, code check in, pairing, documenting, etc. etc. This is not easy. They will make mistakes and have problems (especially at first).
Show the teams support as their skills improve. Removing the need to show progress may only increase the amount of time until code quality improves. Let everyone share in the success as you move forward.
Once the teams finally have it, it may be hard to get a rhythm going again, especially after previous reviews did not validate that mistakes are OK. This gives a perception that reviews are only to show successes. It needs to be safe to try new things and fail.
Problem: Team is not showing enough functionality because it is too small or not-cross functional.
A common reaction: "We need to cancel the Sprint Review because the team is not delivering enough functionality each Sprint to warrant a review. It is a waste of time".
Possible Response: To do Scrum effectively, you need cross-functional teams that have the skills necessary to finish a deliverable completely. By embracing this idea, it aids in the removal of complexity by changing the traditional mindset of large build-up needed before coding can begin.
If a team is not delivering enough during a Sprint because it is too small or does not have cross-functional team membership, Scrum will continue to be noneffective for the organization.
Even worse...When this problem eventually gets fixed, there will be no cadence and process that people are comfortable with to support the efficient exchange of information when it is really needed! The learning will have to happen when a very expensive resource (a whole team) is looking for ways to communicate, inspect and adapt and has to start training the organization about reviews.
Please note, even a small team can create havoc for the future of the project without any peer and stakeholder feedback. The size does not remove the need for the feedback.
Problem : Product is not aligned with stakeholder vision and is upsetting them
A common reaction:"We need to cancel the Sprint Review because the team is building the wrong things and we need to make sure that doesn`t happen. Let`s stop the review so we have time to get more appropriate stuff done".
Possible Response: This is what Scrum is supposed to do. We want to know now that what is being delivered is not the appropriate product and re-align the teams and product to what is expected.
By eliminating the vital feedback in a shared, focused setting, all the communication is moved into underground or other meetings without a clear vision by all those involved.
Some of us have been accused of "not trying to be a good team player" or "not working with Scrum to make it work in the organization".
The organization thinks Scrum is a Silver Bullet that should just work as a "tool". This is sadly, a contributing factor to this issue, but let's stay away from that discussion for now.
Scrum exposes problems. It does not fix them. Removing an event from Scrum because it shows a problem only serves to move that problem underground and hide it.
By removing the Sprint Review as intended, here is what you could end up with;
(Remember, these will all be replaced with other non-focused ways of communicating or achieving these, therefore creating a double-burden on the company. The Scrum framework itself consumes a large amount of time. Not using the Scrum events as intended is a huge form of waste).
- Team members who do not know what other team members are working on
- Stakeholders will hold meetings to find out status because of lack of knowledge
- Mistrust between Scrum Teams and Stakeholders
- A lack of heart-beat or cadence for people to become comfortable with
- An uneasy feeling for team members as they do not know if what they are creating will pass peer scrutiny and feedback at some later date
- Team members wondering if the management and stakeholders care about them or the product and a resulting lack of motivation
- A feeling of us vs. them
- A realization by team members that there is actually little support for Scrum at the management level.
- A Scrum Master who becomes ineffective as information cannot be properly transmitting using the framework
When presented with the above list of problems, some of us try to find "alternate" ways to accomplish things "to be good corporate citizens" ... What we are actually doing is adding more overhead and burden to the company. We are actually causing harm.
Whether it be to protect our jobs, lack of management understanding, lack of organization desire, etc. just give in, we often have no choice but to "give in".
I too have been in the position of "comply or get out". I have been fortunate that I keep repeating the same message again and again, and most often (not always), the appropriate people eventually see the light (or let me go).
I too have been in the position of "comply or get out". I have been fortunate that I keep repeating the same message again and again, and most often (not always), the appropriate people eventually see the light (or let me go).
The worst thing you can do is make up some "alternate" way of doing things. You are allowing the dysfunction to go underground and actually hurting the company. Yes, easier said than done, I know.
When forced into a situation that is not right, it will eventually come back to you as a problem to "solve" later. It will be in the form of "Why doesn't Scrum let stakeholders know what is going on?, or "Why are we not getting the value out of Scrum we were expecting?", or "Why do we still have to have status meetings when we are using Scrum. I thought this was supposed to go away?".
This post is not to address the "Why are we doing Scrum discussion. I have plenty of other posts about that. Here are a few if you're interested.
Scrum does not solve problems. Please do not pretend it does. Acknowledge that it helps only after the impediments it finds are removed. Consider the Scrum Code of Ethics when thinking about this.
- Transparency
- The need to explain Why
- The need for Patience and Consistency
- The need for Willingness
- Agile causes Culture change
Scrum does not solve problems. Please do not pretend it does. Acknowledge that it helps only after the impediments it finds are removed. Consider the Scrum Code of Ethics when thinking about this.
Try this on for size next time you need to explain why something isn't working when part of Scrum is being ignored.
Then, at least everyone will be talking honestly. Instead of making up a solution; Give this a try... (say it with me)....
 |
| Mike Caspar |
by Mike Caspar
Passionate About Agile
