Starting off with Scrum

When you start with Scrum, do you go the whole hog and do it by the book? Or do you just do the daily stand-up and see how it goes? Are you even suited for Scrum? Finding the right balance for Scrum to be effective in the beginning can be tricky but not impossible.

‍I work with many startup teams and see them adopting Scrum, but some don’t do it wholeheartedly. They say, “Yeah, we’re doing Scrum, but…” Aha! ScrumButs! ScrumButs are the aspects of Scrum that they choose not to follow for the sake of convenience. But following only the convenient parts leads to not reaping the full benefits of Scrum. On the other hand, going the whole hog may be too hard and cause disillusionment. As the inventors of Scrum said:

“Scrum is easy to understand but hard to master.”

So what does a new team, especially a startup, do? From my experience and thinking through the fundamentals, I have arrived at the following:

• A checklist to see if you are ready for Scrum.
• A list of unacceptable ScrumButs, things that you must follow, even when starting off with Scrum.
• A list of acceptable ScrumButs, things that you may skip or tweak in the beginning days of Scrum.

But before we get into it, let’s take a quick recap of Scrum itself.

Scrum Principles

If your knowledge of Scrum is a bit rusty, it would be good to quickly brush up using my favourite Scrum resources: the Agile Manifesto, the Scrum Guide and the Scrum Primer. Essentially, Scrum works on the following principles:

• It is an iterative process. Scrum believes that it is hard for users to tell accurately what they want in a product. Instead, they like to see working software and say “Yeah, like that,” or “No, that’s not what I meant.”
• It accepts that change is inevitable. Users and business folks can — and do — change their minds. Very often, in fact. So, developers shouldn’t say, “But you said something else last week,” and refuse to change.
• Scrum is all about predictability. Other parts of the organisation rely on the team’s date commitments and it is important to not fail them. So, we may sacrifice features, but we never slip on dates.
• Scrum emphasises face-to-face discussions rather than hand-offs between teams or team members using documents. A dialogue is much more effective in communicating, it’s also more efficient than written documentation.

There are more principles, but in my experience, the above are the cornerstone of Scrum, that make it really tick.

Are you Ready for Scrum?

It’s never too late to start off on Scrum, but sometimes it can be too early. I have seen teams fail with Scrum just because they were not ready for it. Worse, bad habits set in which become too difficult to change later. Here are some things to consider before adopting Scrum:

• If your entire development team has five or fewer people, Scrum could be an overkill. You are much better off just putting your heads down and coding away.
• If your architecture has not stabilized and most of your work involves doing research, creating PoCs and making infrastructural decisions, Scrum may not work for you. It works best when 80% or more of the code being written involves no new learning of technology or tools.
• If you don’t yet have a Minimum Viable Product (MVP), you may want to re-consider implementing Scrum. It could work, but the stability of the product vision is as important as the stability of the architecture. An MVP is an indication of having reached that stability.
• Another indicator of the stability of product vision is the size of your Product Backlog. If it doesn’t contain at least 3 month’s worth of work for your team, you are probably too early to start off with Scrum.
• The Product Owner (aka Product Manager) plays a very key role in Scrum, and you should not start with Scrum until you have this role filled in.

But most importantly, as the team’s lead or manager, you will instinctively feel the need to get organized better because things are not going OK. You may be missing deadlines, you may be having too many quality issues, or you may feel out of control. These are sure signs that you may want to adopt Scrum.

But do not go in for Scrum because everyone is talking about it.

Unacceptable ScrumButs

So, you’ve decided to take the plunge and you start doing the daily stand-up. That’s probably OK. But what’s not OK is stopping at just that. There are some aspects of Scrum, when not followed, defeat its entire purpose.

Here’s the list of ScrumButs that I find unacceptable.

Team Lead + Product Owner

The Product Owner is the one who maintains the Product Backlog. Sometimes, because the backlog is maintained in a “tech” tool like Jira, the development team lead is saddled with maintaining the backlog. This is unacceptable for Scrum.

The Product Owner must be separate from the team and must take complete ownership of the backlog. He or she must live, breathe it.

It’s OK to have a part-time Product Owner who also has other responsibilities (say Sales). But they should maintain the product backlog and be fully responsible for its contents. Teach them Jira, switch to Trello, or even use a shared spreadsheet if they are not tech-savvy. But do not let the Product Owner be someone who also writes code, or manages the team.

Stretchable or Varying Sprints

At the end of a sprint when a feature is not complete, there is always the temptation to say, “Oh, this feature is almost done, can we stretch the sprint by one day?” Do not give into it. Also, some teams tend to decide the length of the sprint based on stories that they have picked up. I find that unacceptable too.

A stable sprint cycle brings a cadence to the development team’s routine. You can easily say “Every alternate Monday is the Sprint Planning meeting.” If the sprint duration varies for each sprint or is not time-boxed, you miss this cadence and you have to substitute it with sending out meeting invites and dealing with absentees.

Also, dropping features rather than extending the sprint gives a clear signal that deadlines are sacrosanct. It also puts back-pressure on the team to spend time getting their estimates more accurate.

Feature Creep

The cool thing about Scrum is that it gives what users want — flexibility, and at the same time what the development team needs — stability.

The team can say, “Leave me alone” for the sprint duration but in return, they quietly accept drastic changes between sprints. As for the users and business folks, they get to change their minds but in return, they wait for a sprint before doing this. It makes them think through their requirements because they can’t change them so easily.

Add some buffer in the sprint for fixing emergency bugs in production, but do not accept new stories half-way through the sprint, even from the CEO.

Unstructured or Stagnant Product Backlog

The Product Backlog is a key artefact in Scrum and a bad one can ruin Scrum. So, what makes a good backlog? According to the Scrum Primer, a Product Backlog must be DEEP:

• Detailed Appropriately: the topmost items on the list must be detailed and fine-grained in terms of effort estimates. The bottom section can contain vague or large items.
• Emergent: the Product Backlog should be live and dynamic. New items should be added, large items should be split into smaller ones and priorities should be re-evaluated continually. The Backlog Grooming event (aka Backlog Refinement) helps maintain the freshness of the Product Backlog. Do not skip this event.
• Estimated: every item must have an estimate, however rough it may be. This is a key input to for prioritization of the item. Estimates should be in the form of Story Points, not in terms of days or weeks.
• Prioritized: the list should be in the order of priority — items at the top are the highest priority. Note that the priority is derived from a combination of impact and effort. Low effort and high impact items are the highest priority.

Testing Sprints

Some teams have a “Testing” sprint, where no active development happens, only testing and bug fixing of work done in the previous sprints. This defeats one of the fundamental principles of Scrum — delivering a shippable product at the end of every sprint.

Similarly, I don’t encourage the Product Owner spending a lot of time writing a detailed PRD before the sprint starts. A good understanding of a story is enough for it to be taken up in a sprint. Actual detailing can happen during the sprint, with face-to-face discussions between the Product Owner and the developer.

It’s best if everyone in a team (including the Product Owner and Testers) is working on the same set of stories, preventing hand-offs and context switches.

Not time-boxing events

The Scrum Primer tells you exactly how long each event (for example, the Sprint Planning meeting) has to be. Do strictly adhere to this, and do not keep these meetings unbounded.

When I see such meetings stretch for longer than required, I can easily spot the reason — they are doing the wrong thing in the meeting. For example, a Sprint Planning meeting stretches because the high priority backlog items are not detailed or clear, and you start discussing it.

If not time-boxed, you will continue to do this in your next Sprint Planning. Time-boxing forces you to think about it, and fix the root cause — lack of Backlog Grooming.

Acceptable ScrumButs

Doing everything by the book can be overwhelming, especially if the team members are new to Scrum. Here are a few things that I’d say are OK to not go by the book or tweak a little.

No Daily Scrum

Scrum requires that the team has a daily scrum, which is a quick stand-up meeting. When the team is small (say 3–4 people) and is sitting together in the same room, I find this gets to be a bit pompous and makes the team complacent about Scrum.

As long as everyone knows what the others are doing, and are free to voice out their concerns whenever they like, it’s OK to not have a daily scrum at all. Or maybe an alternate day scrum, or an on-demand stand-up meeting just to quickly ensure no one has any roadblocks.

Optional Retrospective

Many a time you don’t have too many things to talk about in a retrospective, because more often than not, you’ll find that the only thing that went wrong was the estimation. You’ll find that a Retrospective at the end of every sprint is an overkill, and people start splitting hair about minor things.

It’s perfectly fine to do a formal Retrospective once in 3–4 sprints, especially if the team is naturally aware of what’s going wrong.

Feature Review instead of Sprint Reviews

You may find that waiting till the formal Sprint Review to demo a small feature is impeding Continuous Delivery. The objective of the Sprint Review is only to get feedback from the stakeholders, so showing a demo as soon as the feature is done is not against the principles of Scrum.

Doing many small demos and involving only the relevant people in demos, rather than an end-sprint formal review with everyone is an acceptable deviation.

Not Self-organizing

A self-organizing team is one where there is no lead or manager telling people what to do. The team members pick up stories themselves, estimate and track progress.

This is hard to pull off, especially when the experience and maturity levels of team members are very diverse. So, when starting Scrum, it’s OK for the erstwhile manager or lead to play the part of the Scrum Master, help in allocating work and also help in estimates and planning.

No Formal Progress Tracking

Scrum suggests using tools such as Burndown Charts to track progress. But this comes with the overhead of splitting Backlog items into tasks with hour estimates and also regular updates from the team member as the sprint progresses.

I find that with short sprint durations like one or two weeks, the progress is quite apparent informally. Especially when there are regular daily stand-ups, or the lead or scrum master talks to each team member individually, making a detailed task list and getting everyone to keep it up to date and accurate is not worth the effort.

Conclusion

The Scrum Guide and the Scrum Primer list down many events and artefacts as part of the Scrum methodology. But these resources do not tell you whether you are ready to transition to Scrum, and if so, which events and artefacts to start with and which others to leave as ScrumButs. I hope my post helps you make decisions regarding your own Scrum readiness and set of ScrumButs.

Remember, don’t treat these acceptable ScrumButs as permanent deviations from Scrum. For example, push every team member to contribute more and more to estimation, if not do it themselves. Encourage them to pick up their own tasks. Keep thinking of who from the team can be a good Scrum Master.

In effect, be aware that Scrum itself is iterative. You have to constantly think about eliminating the ScrumButs to reach the ideal state — Zero ScrumButs. Only then can you transform your development team into a well-oiled engine cranking out features at a good velocity.