When I hear, why individual companies rely on Scrum or Agile methods in general, I get dizzy. We want to get better – whatever that means, we want to get faster, we want to make fewer mistakes. If you are not fully aware of what Scrum is and what it can do for you, you might be extremely disappointed and jump onto the next hype train at some point.
After all these years, it still seems like Scrum and Agile are the hot shit, that you just must participate in, if you want to be a modern company. Please do not get me wrong: many companies have exactly the right motivation to rely on Scrum, but you would be amazed at how many have exactly the wrong motivation or actually do not even know what they want and why they want it.
And what – dear Mr Wisecrack – is the right motivation?
I will torture you a little more and calmly explain, why Scrum does not solve all problems, and why it is not always the right choice, before I get to – what I believe – the only reasons for using agile methods.
Unfortunately, I keep coming across the phenomenon, that companies do not know exactly, what to do with this agile stuff. They are doing it as best as they can, but it feels kind of weird, because it is achieving nothing and therefore feels purposeless.
It is not necessarily the case, that at some point someone comes up with the brilliant idea, that you absolutely have to do agile, because everyone is doing it. I know that this is said sometimes, but that is nonsense. No one is that stupid, even if we do not always have the highest opinion of individual people in management. Rather, it is usually the case, that someone takes a look at the development and sees, that something is not working properly. Whether this is also the case from an objective point of view, remains a completely different question, but in the perception of the observer there is room for improvement.
Maybe you think you should be faster, maybe you see a certain lack of orientation, maybe you are confronted with an exceedingly high bug count, maybe your colleagues are overwhelmed and dissatisfied and demotivated. This is where the first and most serious mistake is often made: one does not search intensively enough for the reason for the (perceived) problem, but starts straight away to find a solution.
So, you ask around, read a lot and then come across e.g. the statement, that Scrum would accelerate development. With all due respect: that is total nonsense. Scrum is not a miracle drug, that makes a developer suddenly write a few hundred lines of code more per day. Even an espresso is more effective in that regard. Scrum does not help us get faster, it helps us in choosing the right things to do. Meaning, it saves us from producing too much garbage, that nobody needs. But be warned anyway: one principle in Scrum – or Agile in general – is, that we consciously keep developing things, that we have to discard again. The intention is, that we build little things, that we throw away again and again to correct our course, instead of dumping months of work in a garbage can.
Maybe speed of development is our (perceived) problem. On closer inspection we might find, that our colleagues simply do not have the technical depth they need for the project. Meaning, that the solution to our problem is not Scrum but further training.
Another popular argument is, that working with Scrum would produce fewer errors. How is that supposed to work, please? Seriously: a tiny pinch of common sense is enough to make a big question mark appear here. If we are producing too many bugs, maybe we should think about our QA first. Scrum does not replace that, it just integrates it.
If my software is unusable, I should probably first talk to someone who knows something about user experience and usability. Software developers do not become experts in these topics simply by using Scrum.
About quality control Scrum only says, that the product owner accepts the implemented requirements as part of the review (or even before – which I would prefer in any case). How we implement a QA and integrate it into Scrum is our business. I do not need Scrum for a functioning QA. On the contrary: Scrum is of no use to me, if I do not also think about QA.
Are our colleagues dissatisfied and unhappy? Overstrained and / or overloaded? Here, too, I would like to ask you to research the reasons first. Was our planned delivery date perhaps completely unrealistic from the start? Are there some assholes sitting somewhere, who spoil everyone’s day, and that is why they are in a bad mood?
I am going to make an unpopular statement by saying, that Scrum does not save us from deadline pressure. Agility does not ship us to the island of the blissful and protects us from reality. At some point someone will come and demand results, and rightly so. Scrum saves us – if we get it right – from making promises, that we cannot keep. But if we use Scrum for a classic desktop product, for which an annual update is planned, then we still have a deadline, that we have to keep.
Scrum helps us to think in small steps. That is all. We also can work with a roadmap in Scrum, but we forget the detailed planning of things, that are far in the future, and the exact-this-scope-of-services-is-finished-exactly-on-this-date-crap. However, if we arouse false expectations in our customers and users, then that is entirely our problem, and it is self-made. Scrum does not keep us from that.
Let’s take a look at what Scrum actually is in order to be able to decide, what Scrum can do. Scrum is a tool – a framework, that we have to fill ourselves (example quality assurance), that divides our approach into small units, gives us a beat, and that strengthens our team. That’s it. There is nothing more. However, these points are the reason for a number of advantages and strengths. However, we will not be able to use them if we do not understand them.
The division into small units means, that we gain the ability to move via a control loop: Plan-Do-Check-Act (that’s quite antic stuff – I know). Every sprint is intended to be exactly that cycle coming to life. The Product Owner collects the requirements. The team implements them. The results are tested. You show them to the user and get their feedback, in a beta test, an AB test, a survey with prototypes or whatever – it does not matter. The only important thing is, that we check the hypothesis, that our requirement contains, together with the user. That is what we (also) understand by cooperation with the user or customer.
And: what we have learned on this point forms the basis for our next circle. This is the agile approach and that is exactly what ensures, that our product will get better with every iteration, if we stick to it. If we proceed in short iterations, but do not speak to the user and take their feedback into account (by the way, one of the most common mistakes with Scrum), nothing is gained.
If we want just that, and if we understand, that it is exactly that, what helps us building a better product, we have the right motivation to use Scrum. On eh other hand, when we look at the organization and think, that things should be better somehow, then we should first ask ourselves, what it is, that we are expecting, and the investigate, why this expectation is not being met.
The next important aspect is the strengthening of the team. We could limit that to the decision of the developers, how much they can implement in one single sprint, but I think it should be much more than that. We can involve the team in many more planning processes. As a result, we get more motivation, a better overview of all the interrelationships, the creative input of our team members and a few more nice things.
But empowerment can be achieved in many ways. We do not need Scrum for that. If strengthening the team is our one and only objective, there are a lot more options to choose from. That alone is no reason to use Scrum for me. It is a byproduct. The main reason and motivation for Scrum or Agile in general is the control loop, and if it is that, what you are trying to achieve, then Scrum is probably the way to go. With all other possible motivations, you first ask yourself whether this can be achieved in another way. After all, the use of Scrum is a profound change.
This all might sound, that I am trying to stop you from using Scrum. That is not the case. I just ask you to take a few things into consideration, because that might save you from regretting it later.
Core Knowledge: Scrum does not make things faster. It just helps us to live the Plan-Do-Check-Act cycle. If it is that, what you are trying to achieve, Scrum and Agile is the right thing for you. If you hve other motivations, there might be other solutions.
If you have questions left or need support in your project or your organization, let me know.
