When Do You Call Scrum "Scrum"?

December 03, 2012 in Basics

6

As we all know, Agile and Scrum have become popular, and many development and maintenance projects are adopting Scrum to reap its benefits. In my organization, where we deal with multiple clients across different geographies with different organizational cultures, I have seen projects implementing Scrum in different ways. Agile projects, in general, have relatively less paperwork compared to traditional projects, for which a lot of evidence is needed to show proof of compliance. This adds incentive for teams to adopt Agile, and even the customer usually finds this fairly attractive, as there are explicit benefits (quicker delivery, greater collaboration, etc.) as well as implicit ones (doing away with the tedious process of implementing change requests, for example). While this is a win-win situation for both sides, I have seen many projects not following Scrum to its core — and yet calling themselves Scrum/Agile.

As we all know, Scrum talks about:

  • Three ceremonies (sprint planning; daily stand-ups, or DSMs; review and retrospection)
  • Three roles (product owner, ScrumMaster, team)
  • Three artifacts (product backlog, sprint backlog, burndown chart)

There is also one more aspect: sprint length. It should be between one and four weeks. You decide how long the sprint should be based on the answer to these questions:

  • How quickly you want feedback from business/product owner?
  • How long will it take for the team to deliver something useful?

The team needs to balance these two opposing factors (one that requires software to be delivered quickly and another that will delay delivery until something meaningful is available). Also, it is generally accepted — but not a rule — that sprints of more than a month are too long, and hence the team should be looking at sprint sizes of less than a month (or about four weeks).

Given all these considerations, would you deem the following teams as following Scrum or not?

  • Scenario A: Holding DSMs, sprint retrospection, three-week sprint but not rigorous on sprint review as client is available for demo only once in two to three months.
  • Scenario B: Sprint planning, DSMs, review and retrospection done. However, sprint length varies based on the functionalities that need to be delivered.
  • Scenario C: Planning, review, and retrospection done, but DSMs not followed. The client is not interested in burndowns and only checks what's delivered in sprint versus what's committed during sprint planning.
  • Scenario D: Every two-week sprint is followed by one week of impact analysis of the next set of requirements, which results in a set being picked up for delivery in the next two-week sprint.

From my perspective, the maturity of the project/team are what really decide whether you're following all the practices to the core or whether the team feels that some Scrum-specific steps can be done away with. If you have a project or team that's new to Agile, it's better to follow Scrum exactly, at least for the first few sprints. After that the team can decide which aspects of Scrum are useful and which are not. The advantages of this approach are these:

  • During the learning phase, everyone on the team gets to experience Scrum and see the pitfalls and benefits for themselves, rather than hearing them from someone else.
  • The plan to do away with some parts of Scrum is based on the team's experience rather than being one person's decision.

For a team that has already worked together and has seen the benefits of Agile/Scrum, it might make sense to sit together every once in a while (or maybe during retrospection) and decide which practices to keep and which to drop. If the team does decide to drop some features, is the resultant methodology Scrum or, as some people say, "hybrid Scrum" or "Scrum but"?

While teams can choose to follow or drop some of the Scrum practices, I would argue that to be called a Scrum team, you must be implementing at least the following practices:

  • Sprint planning: Decide what needs to be delivered in the timebox.
  • Sprint review: Showcase what has been created and get feedback from the customer/client/product owner.
  • Defined sprint duration: Every sprint must be of equal length. The whole idea of doing sprints is to get a rhythm going, and not having a fixed-duration sprint will be counterproductive. This also means that there should be no gaps between sprints, at least for a reasonable period of time.

All the other practices are, at least in my opinion, the means to achieving an end, which is good-quality software. Some are either an outcome or implicitly need to be there for the team to execute the three points listed above. For example, the team will have a set of requirements they'll work on. It may be termed a product backlog, or not. Similarly, the outcome of the sprint planning will result in identified tasks. Again, these can be put in a structured format by using a sprint backlog or left unstructured.

So while those three elements are necessary, the others can be adopted, in other software development life-cycle (SDLC) methods, as good practices. But those SDLC methods should not be termed Scrum.

Share on Facebook    

Article Comments

  1. Santosh Thakurdas said on 04 Dec 12 12:24:
    Good article!
  2. Jorge Bejar said on 06 Dec 12 14:24:
    Interesting topic! When a team has experience doing scrum they would decide to drop some of the core artifacts, and in some cases I would say they're still doing scrum, as you pointed out in this article. I think we can consider that a team is still doing scrum if they have good reasons to decide to stop doing any of the scrum's elements and also if they have an alternative way to achieve the goal of the scrum practice which is being discarded. For instance, if a team decides to stop doing daily meetings, they have to make sure that everyone in the team knows what's doing the rest of the team, if everyone is on the same page and having on mind the sprint goal. Also, blockers should be communicated shorty as well in every moment. This team could argue their internal communication is very tight without the need of daily meetings, and in this case I would say the team is still following scrum principles. In the other hand, if a team decides they don't want to have daily meetings because they don't really need to know what is doing the rest of the team, I would think they're not doing scrum... they're doing something else :) Last but not least, I really think retrospective meetings must be included in your list of mandatory scrum practices. I can't think in an alternative way to ensure the team is inspecting and adapting their process in an effective way.
  3. Rick Tonoli said on 10 Dec 12 06:38:
    I think the purpose of teams should not be to create a perfect process but to add maximum value, however that should be. If that means modifying the "by the book" process because it would result in improvement then why not? Who cares if it's called Scrum or agile or kanban? I think we become fixated with process and lose track of the goal, delivering value. That said I do believe that there are things that you must happen, like retrospection (to learn from our mistakes and repeat out good behaviour), some form of planning so there is at least a coordinated understanding of what we're doing, goals for each sprint, proper definitions of what is "done", good collaboration between all team members (including PO) and proper engineering practices that lead to good quality. There are more I'm sure but you get the idea. In the end I think if you're delivering measurable value of a high quality and you're continuously looking at how you can improve that should be enough.
  4. Bill Rinko-Gay said on 11 Dec 12 11:48:
    What is the point of assigning the name? Do you want to ensure you are making an accurate claim on your next job application when you say you have experience with Scrum? Are you hoping to gain all the benefits of those who have experienced this implementation of Agile principles? Are you trying to show you know how to comply with the Scrum Atlas? If your goal is not the second, then I don't think it really matters. If your goal is the second, then I'd take a long look at whether you really need to modify Scrum to achieve your goals. With all the successful experience Scrum has, if you can't succeed by implementing it as defined, you may be assigning the wrong root cause to your problem. I agree that you shouldn't feel like the identified process is a straight-jacket, but you should be careful when changing something so highly successful. It's very success is a good reason to question whether your team is really as different as you think.
  5. Srinath Chandrasekharan said on 18 Dec 12 04:37:
    Thanks everyone for your interesting thoughts. While I do agree with them, I would like add a caveat here. The organization I work in is an IT service provider. In our organization, there are multiple projects happening a the same time for different clients, in different technologies, with different type of work ( development, enhancements, maintenance etc). There are times when teams are formed to deliver projects where the experience and knowledge on Agile varies. Some of these teams are very new to the whole idea of Agile and they learn the ropes in the job. However from a senior management perspective, they need to understand how projects are performing and hence need a common scale to compare. It is in such times, that I believe that we must have some minimum common definition. As each one of you has mentioned, when teams mature, they can look at the value they are delivering to the customer instead of sticking to 'name'.
  6. Sanjit Tiwari said on 30 Dec 12 12:54:
    While Scrum preaches for less documentation. I have seen that most of the documentation work are mandated by Client, and its often part of any release entrance criteria. In this scenario, we tend to relax some of the sprint ceremonies during the last few sprints termed as hardening sprints. Apart from the last few sprints, all standard ceremonies have been really useful for the engagement I am facilitating.

Please login to comment on this article.

Author

Srinath

Srinath Chandrasekharan CSM

bio

Srinath Chandrasekharan is Certified Scrum Master and Project Management Professional. He has over 14+ years of exeperince in the IT industry. He started his career as a developer and has worked in... Link »

Tags