I will start by laying my cards on the table. I am not a hardcore fan of Agile methodology or Scrum. I am pretty sure SCRUM is not the universal answer for everything. That's 42, duh! I believe there will always be some projects or groups of people that are not compatible with Scrum simply due to the nature of those projects or the way the teams work. Despite this, I managed to get a lot out of this tool. It's possible when you take it as bits of advice and practices you may or may not apply in your daily routine. But make it a company-wide rule, and you are screwed.
What the Hell Is Scrum Anyway?
But what the hell is Scrum anyway? Extra meetings, story points, and ScrumMasters? Of course not. I look at it as a guide, a straight line showing you what you could do—not what you have to do. Useful when you get lost or don't know how to proceed with a big project, and you have a lot of teams that have to be organized, deliver the proper result, and, of course, on time. However, there’s nothing magical about it. It doesn’t solve all your problems just because you follow the rules by the book. Using Scrum will never make your process bulletproof. Just as you won't become the new Steve Vai just because you bought a Super Strat guitar.
Scrum is one of many ways that can help you polish the form in which you work. But only if you see the point of doing all those things Scrum tells you. The worst thing you can do is to follow those rules blindly without any clue why you are doing it. For example, you should estimate issues because you understand that this is the way you are thinking about the problem. Estimates are not there to represent how many days you are going to spend on the issue. Estimates exist to force you to think harder about the problem.
The lower the estimates are, the better you comprehend the issue you are trying to solve. The master of all goals is to get the smallest estimates possible. But how can you rate a story when the number doesn't represent days but only something like overall difficulty? Comparison. It’s easy to get together and talk about the story, but when you need to compare these stories, you will find a lot of interesting nuances that differ that one from another. Then you can say whether the difficulty is bigger, smaller, or equal. But, as I said, not according to the number of days, but due to the overall complexity.
Unfortunately, you can't take this for granted. Some stories just can't be estimated without some recon in advance. Well, in fact, they could, but the numbers would be too darn high. That’s why you need to do spikes before a story can be estimated, meaning a development team needs to run a timeboxed investigation to arrive in an agreed period of time. If your grooming suffers from a lot of confusion and uncertainty, you know you need a few of them. But who said a spike needs a week of hard work? And who stated that they couldn't be done the day after grooming? You have to do as many as are necessary to move further with the story or epic, but not too much. Also, you have to do them as quickly as possible. It's bad practice to waste a lot of time preparing a shelveset with the solution for a story you're not certain is going to be implemented. Because sometimes another part of the story can be very complicated and it will lead to postponing the whole epic to make room for another one. Your laboriously prepared code will stay in a shelveset for eternity, and you've just wasted both your time and the company’s money. But I've digressed, back to the main topic.
So why bother? Simple answer—we are using Scrum to control and maintain constant and optimal delivery. That's why we have sprints. We need to deliver the most exciting stories. And for that, we have to compare the stories based on the ratio between the impact on the market and the complexity of implementation. That's why we have story points. We also need to be prepared for those stories and discover the complexity. That's why we have grooming. We need to implement stories with the highest priority and do it as soon as possible. That's why we have planning every two weeks. And of course, we need to know how far we can get with the epics by the end of the development. That's why we count the velocity.
And yes, there's one more. Retrospective. Scrum is a tool, not some kind of mantra. You can follow the rules precisely and everything else, but it could still go south. The right time to put heads together and point out the bad stuff. Are you returning from grooming knowing nothing? The “so-called” Jon Snow syndrome? Then point it out! Do you want to postpone a sprint due to the dreadful state of the backlog? Do it! Do you want to groom the stories one by one every day in some 15-minute QA sessions with your Product Owner because a one-hour long session is just ridiculous? Say it. That's why we have the retrospective. Bend some rules, get rid of the useless stuff if it's necessary. We are not doing this just to use Scrum or pretend we are super Agile. We are doing it to deliver always the right stuff at the right time. Well, at least, that's how I think about it.
And to Conclude?
Try asking yourselves, “does everyone in the team know what to do next month?” “Am I sure we will deliver the solution in the time reserved for it?” No? Then you have a big problem with your process. Is Scrum not working for you? What are you waiting for? Bend some rules, change the process, make it work.
Remember, use your tool wisely!
What are your experiences with following Agile methodology? Are you a strict disciplinarian or a softly, softly applier? What things work well for you? What things are a disaster? We’d love to hear your stories below.
To see more about how to do development in Kentico, check out our platform.