Why is it a concern?
It’s common in Scrum circles to refer to “Scrum-but”. This refers to teams who are doing Scrum … but skipping some aspect of it, for some reason:
- We’re doing Scrum, but retrospectives aren’t effective, so we only do them monthly.
- We’re doing Scrum, but our stakeholders are too busy to come to Sprint Reviews, so we stopped doing them.
- We’re doing Scrum, but we couldn’t get everything done in two weeks, so now we just let our Sprints run as long as they need to.
Sometimes people get upset over the term, or over the notion that if you’re going to do Scrum you should do Scrum. As if I might say “I’m doing Diet and Exercise, except that I don’t exercise”. That would be amusing, perhaps, and even true, but not useful.
The general reason why Scrum experts object to Scrum-buts is that they almost always hide an impediment which, if addressed and removed, would improve things. For example, using the examples above:
- Retrospectives are most often judged ineffective because nothing is done about the issues raised. It’s more likely that this team needs better retrospectives, not fewer.
- When interesting and important new results are being demonstrated, and when the team is responsive to stakeholder input, Sprint Reviews are exciting and productive. It’s likely that this team is working on things the stakeholder do not value, or that they are unresponsive to needed changes.
- The most important aspect of Scrum, to my mind, is to product a “done” increment of software on a regular cycle. Hitting the project deadline is typically the most important project goal. Hitting a smaller deadline every two weeks gives the team practice in how to do it. It’s likely that this team is losing out on important discoveries about what’s holding them back.
This is why Scrum experts are down on Scrum-buts: they are all too often evidence that the team is not getting the benefit they could be from Scrum. Instead of buckling down to fix problems, they are choosing to side-step them.
Let’s take a look at the key aspects of Scrum, and explore what happens if one goes ahead without them.
The Scrum Product Owner is responsible for maximizing the ROI from the project, by making the final selections of what will be done now and what will be deferred until later. The Product Owner is empowered to make all the necessary decisions, and must be a single person, though of course they can have all the help they need.
If a team does not have a single product owner, they will quite likely be getting different ideas of priority from the various sources of priority. Not all of this information can possibly be correct, and confusion will not improve results.
If the Product Owner is not responsible for results, then results are less likely to be good, and it will be less clear to everyone how to improve the situation.
If the Product Owner is not fully empowered, then there will likely be miscommunication about what needs to be done, with rework and quite possibly an inferior result.
If the team does not have a Product Owner at all, they will be uncertain what to do and unlikely to do the right thing.
Generally, businesses want a single person to be “in charge” of things. It is quite likely “better” to have the minds of the whole team working on the problem, and perhaps in some situations it’s possible to do this effectively without a dedicated responsible person.
It’s not really Scrum without a Product Owner. There are serious concerns if you don’t have one. There may be other viable alternatives. Before you go without a Product Owner, be sure you really have a better idea.
The ScrumMaster is a servant leader, helping the team to execute the Scrum process as they have agreed to do it. The ScrumMaster helps communicate the team’s situation and Scrum ideas to the team and elsewhere in the organization. The ScrumMaster is responsible for seeing that identified “impediments” are dealt with and removed.
In the throes of work, a team easily loses sight of their higher goals and aspirations. They will often slack off on their commitments, without even realizing it. The ScrumMaster keeps his or her eye on these things and helps the team remember what they’ve agreed to do. Without a ScrumMaster, this is less likely to happen.
The ScrumMaster is expected to have a stronger understanding of Scrum than any other team member is likely to have, and is responsible for helping all team members, including the Product Owner, understand and do their job. The ScrumMaster also helps see that team status, and general Scrum understanding, is communicated outside the team. Without a ScrumMaster, people may not understand Scrum as well, and therefore may not do as well as they might.
Everyone on a team is capable of coaching, and should coach in the moments where it’s appropriate. Many teams have done fine without ScrumMasters, and others will do so in the future.
It’s not Scrum without a ScrumMaster. It could still be a good process, but especially in early days, it’s risky to go forward without someone keeping an eye on things.
Scrum requires that the team delivers a product increment in every Sprint. This increment is supposed to be “done”, in the strict sense that it is good enough to give to users if desired. It will, of course, be incomplete, but what it purports to do, it must do completely, and well.
The Product Increment is the most visible possible evidence of how the whole team is doing. It embodies the decisions of the Product Owner in real, running product. As such, it gives stakeholders the most certain understanding of how things are going.
If a team cannot produce a working Product Increment at will, there is little reason to believe that they can produce one by the deadline. Visibility is decreased and confidence is eroded.
In learning to produce the Increment, the team learns what needs to be done in order for the Increment to be truly usable, and they learn to do that work efficiently and well. Without producing the Increment, they may not know, and we certainly can’t tell whether they know.
Some teams accept the idea that after they “ship” the software, there will be a period of finding problems and fixing. That rarely leaves anyone with a good taste in their mouths.
Some teams dedicate one or more “Release Sprints” to cleaning up the software, and to integrating it, often for the first time. This activity is unpredictable and generally stressful. It almost always leads to a less impressive release than desired, often later than needed.
As far as I know, there really is no good alternative to regular Product Increments, each one improving in “doneness” over the last.
Cross-functional Development Team
The third and final Scrum role is the Cross-functional Development Team. They are the people who do the work of producing the product increment. The Product Increment needs to be “done”. If done means tested, the Dev Team must test it. If it has a database, the Dev Team sets up the database. And so on.
If the Dev Team lacks some essential capability needed to produce the Increment, they are set up to fail.
If the Dev Team has a “shared resource” to perform some vital function, they will be at the mercy of other users of that resource, and their work is in jeopardy.
All the alternatives are compromises with the ideal. Each puts the product at risk, and reduces the Team’s and the Product Owner’s ability to produce the best possible result.
All known alternatives to fully staffed teams are trading off one product against another, or utilization against effectiveness. I know of no better way to staff projects than with all the capabilities they really need.
Scrum asks that the Team provide visible indications of their progress. It does not specify what these are, but demands clear vision by all stakeholders regarding how things are going. The Product Increment is of course first among these, but other displays, such as burn charts or story boards or “kanban” boards are often used.
If the business cannot see how a project is going, it will not go well for the project. Budgeting will become more difficult, trust will go down, and scrutiny, when it comes, will be harsh. Judgment will likely follow, harsh as well.
I cannot recommend that a project be other than highly transparent. To do otherwise is to lie by omission. No project that’s going well is afraid to show it; no project that’s going poorly should hide it. They should look at the truth and improve it.
Scrum says that there must be a Product Backlog of items under consideration for construction. It does not specify how comprehensive that backlog should be. It doe specify that the backlog should be ordered, and that it includes a description of the item and an estimate of its cost. Everything the team does comes from the Product Backlog.
Sometimes there is reluctance to have a backlog because “things here are so dynamic”. Too often, this is a sign of poor decision-making. Sometimes, such as in a support group, it might mean that Scrum is not a good fit for the activities of the group.
Sometimes a backlog is taken as a list of things that “must all be done”. This is rarely realistic and not a good idea. It’s not a good reason not to have a backlog, since people do prefer to have some view of the future. It is probably a good reason for a shorter, simpler, more refined backlog.
Some teams like a “kanban” approach where there are just a few “next” items displayed somewhere, and they pull them off in priority order. In the case of a fully empowered Product Owner working intimately with the team, this can be a good way to go. It may not be a good way to start, because an overview of the whole project can be of value to everyone.
Absence of a backlog means it isn’t Scrum. It might or might not be a good idea: I’d want to ask some hard questions, mostly around whether there really are priorities or whether the team is just in some kind of reaction mode all the time.
Scrum calls for the Product Increment to be build in fixed-length time boxes called “Sprints”. Sprints are typically two weeks long, though a month has been recommended historically. (Some think the name to be unfortunate, as it might suggest some kind of rush, while of course Scrum is intended for the long haul. There’s no intention on the part of the Scrum creators to imply a hurry.)
At the end of each Sprint, the team delivers and shows a Product Increment, which is expected to be in good enough order to be given to users if desired. The fixed time box provides enough of a boundary to encourage the team to choose an amount of work that can be completed in good order by the end of the period.
It’s hard to learn to be “done” by a fixed date. Sometimes teams push back, saying that “it takes as long as it takes”, and so on. It turns out that teams can always learn to be finished by the end of the time box, and this enables them to be finished by any desired deadline.
Sometimes a team “just can’t” be done on their own. This can happen when they are not fully cross-functional, so that part of their work every Sprint must be done by some agency outside the team. Needless to say, this reduces the team’s ability to complete everything, and at the same time, reduces the organization’s ability to know what’s going on.
There is one very good alternative to being “done” at the end of every Sprint, and that is to be “done” at the end of the completion of every backlog item. This implies that the system must be fully integrated after every item, and fully tested as well.
This is harder to do than being done only once per script, but can in fact be a good way to learn to be done. Often a team struggling with being done will be advised to work on only one story in the Sprint, using all their powers to get it completely done. This practice generates a lot of learning.
It is quite possible that “continuous flow”, the practice of doing just one story at a time and getting it fully done, is somewhat more effective than Scrum in the hands of a team good enough to do it. Thoughtful people disagree on this, but it’s worth considering.
It’s probably not worth considering extending the Sprint or reducing the need to be done. The desire to do this suggests that there’s something in the way that’s not being dealt with.
If you’re going to have a Sprint, at the end of which you’ll have a working Product Increment, it’s good to have a plan of what you’ll do. This enables you to look at what happened, in the light of what was intended, and learn how to improve.
Sometimes a team has no Product Owner with whom to plan. As we’ve already discussed, this can only lead to a difference between the organization’s expectations and what actually gets done. This is rarely a good thing. Lack of a Product Owner should be fixed, not used as cause for dropping planning.
Sometimes there is no agreement on what needs to be done, or things change so rapidly that the plan gets changed in mid-Sprint. Scrum actually has a ritual for this, which includes throwing away all the partially done work. This is intentionally painful, to encourage the team to figure out why they can’t even stick to a plan for a couple of weeks.
Sometimes there is great pressure to “keep your promises”, so that each Sprint Plan is taken as a do-or-die commitment by the developers. This is a very pernicious practice that will lead to sand-bagging and low quality. The way forward is to fix it, not to stop planning.
Continuous flow, discussed above, can be a good alternative to planning, in the hands of a very well-integrated team with a fully empowered Product Owner. It requires conscious focus on producing and publicizing Increments frequently, and requires higher technical skill than a planned Sprint.
Without Sprint Planning, it isn’t Scrum. There are ways that may work as well, but they are generally not ideal for inexperienced teams.
The Daily Scrum is a daily(!) meeting where the team comes together to review where they are, where they’re trying to go, and how best to work together over the coming day.
If a team doesn’t have Daily Scrums “because they take too long”, it is likely that something other than the above is going on. Frequent possibilities include that the meeting has become a report to management rather than a team coordination meeting. The right thing to do is to get the meeting productive, not delay or stop doing it.
If a team doesn’t have Daily Scrums “because they’re not useful”, it is likely that the team is not so much a team as a “crew”. In a team, people work together and coordinating their work is usually helpful. If the Daily Scrum is not productive, the right thing to do is to make it productive by fixing the underlying problems.
Some teams work so intimately together that at the end of the day, everyone already knows everything that’s going on. Their whole work day is a flurry of constant communication. Such a team might not need a Daily Scrum. That said, I’ve never seen such a team, and if I did, I’d have some questions to ask them.
It’s not really Scrum without the “Daily Scrum”. Its absence raises questions that need answering.
The Sprint Review is a meeting, at the end of every Sprint, where stakeholders come together to view the new Product Increment, and to discuss and provide feedback on what is to be done next. The meeting serves two key purposes: first, it keeps stakeholders informed of progress, in the most concrete terms possible, and second, it keeps the team and Product Owner aware of the stakeholders current interests as informed by current progress.
The most common reason for dropping the Sprint Review is that the team’s output is absent, or not interesting to stakeholders. This is an impediment to both visibility and planning, and should be fixed.
Another common reason for dropping the Review is that stakeholders aren’t interested. This is also evidence that the Increment is boring, or possibly that the project is not worth investing in. Again, the impediment should be fixed.
There’s nothing like a bit of show and tell to get everyone on the same page, and to get useful feedback. Alternatives like continuous release, and newsletters may fill in some of the gap.
Scrum and Agile have communication between stakeholders and the team as a core value. It’s not likely wise to drop this key way of visibly showing what’s going on.
In the Sprint Retrospective, the team looks back at the preceding Sprint, and their whole past, and identifies ways of improving.
Sometimes the Retrospective is dropped because “the same old things come up every time”. This is clear evidence that problems are not being addressed. It would be better to address them.
Sometimes the Retrospective is dropped because “no good ideas come up”. This could be happening because everything is perfect, but more likely there is some force at play that suppresses expression of legitimate concerns. It would be wise to provide an environment where ideas are nurtured, not crushed.
Some people will argue that a smoothly-running team is adjusting what it does all the time, and that a formal Retrospective is not needed. This might be the case, though I’ve never seen it happen. I would think that taking some time to look at the bigger picture would always be helpful.
The fundamental notion of Scrum is to “Inspect and Adapt”, namely to look at how things are going and devise ways to go better. It’s likely that you can do better than you are, and therefore it’s likely that a Retrospective would help.
In any case, if you’re not doing a Sprint Retrospective, you’re not doing Scrum.
Is “Not Doing Scrum” so bad?
Not in my opinion. There are many ways to do well, and Scrum is a good one. For some teams, it might be the best way. For some, it might not.
However, I do think that if we are to say “We’re doing Scrum”, it’s best for everyone if we’re actually doing what Scrum says, not something else. Scrum people go to a lot of trouble to be clear about what Scrum is, and what it is not, and there is great value in there being agreement about what “Doing Scrum” actually means.
So my advice is to pick whatever process you want, with Scrum as one of the candidates. And if you pick something that isn’t Scrum, my advice is not to call it Scrum.
Thanks for listening.