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.