In my work as a Scrum master I often find that one of the hardest things in Scrum is discipline. The strength of character to stick to the rules of Scrum is hard to come by and even the best team members sometimes fall into the scope creep trap. But why?
Here I try to explore a few reasons why this might happen and what can be done to mitigate the problems of scope creep.
Programmers are nice people
Really, almost all of the programmers I’ve met are really nice people, aside from a few quirks some of them might have, at the heart they’re really social. And there’s your problem, they are willing to help, too willing!
They know that if they just write that extra line of code, or just add this extra tiny feature they will make the client happy, and who doesn’t want that.
Solution
The solution is understanding the flaw in the thinking. While it is tempting and sounds sensible, there’s a basic flaw in the logic of being nice. By helping in the short-term you’re only creating long-term problems for that same client. By not taking the time to properly plan and review the new functionality you do not know if this is what is really needed, if it gets in the way of something else and if it should have priority at this moment.
Defined like this, in the long term:
Scope creep is the opposite of being nice, it’s being mean to the client by not being transparent.
Software is never done
Because of it’s nature, software can always be improved upon. The code can be improved, functionality can be tweaked a screen can be re-designed. There’s always something to do, and it’s so easy to do it.
It takes a lot of guts to say “I’m done” with something that is in it’s nature never done. It is hard to find a strategy to deal with this.
Solution
There are a few solutions but I think they all center around an important theme.
Make sure you know when to stop before you start
We have a lot of tools in SCRUM that help us do this, but the point is to know what you commit to before starting your work and to stick with it. It’s an extra mental step that is often forgotten (I think because people are enthusiastic to start working). Here are a few artifacts that could help:
Acceptation criteria / Value
If these are defined (and take the time to define them) try to be lazy. Think of the least amount of work you can do to make sure you create a solution that meets the acceptation criteria and delivers the value. You did not commit to doing more than that so don’t try to do more.
Test driven development
Start by creating tests that cover all functionality before you start. This may seem like more work but it saves you time in the end. Tests will have to be made at some point anyway, and if you make them from the get-go you can be sure you’re done if all test pass.
Define what you won’t do
This used to work really well when I had my own company and had to make offers to clients. I would imagine what they might ask during development and be sure to write down (in the offer) what they were. It gave me peace of mind and it was a nice way to define when I could stop working.
Everyone enjoys a challenge
This may be the hardest one. I think a job is more than doing work and getting paid. It’s about learning and personal growth and I love seeing my colleagues enjoying what they do. I think it’s great that people have fun in their work. The problem is that the fun and challenging things are not always the things that need to be done.
This is especially true for software development. Sometimes the focus on a particular problem becomes so big that developers lose sight of the goal of the issue. This is a very difficult to deal with because either the developer of the team members will have to end the fun. How do you tell someone to stop doing what they clearly enjoy? How do you stop yourself from doing something you like?
Solution
Let me start by saying that a little fun should always be allowed but it’s a very slippery slope and it’s just easier to just not enter it. It is better to shift the feeling of fun to what the client needs:
Making something that helps the client is way more exciting than creating beautiful code
It’s a bit like using drugs and being social (see this experiment for details). While having fun writing code gives you a momentary high it does not help anyone. In fact, like doing drugs, it may be a burden on the people around you (the team, the client), less time is spent on useful stuff and the agreed work might not get done.
On the other hand, try to focus on how happy you’ll make the end user. This creates purpose. What you made will help them every time they use your code instead of helping you only once and for a short time.
I have yet to meet a developer that does not want to help the client when all is said and done.
Discipline
Discipline is a word I hate and love at the same time. I want persons to think for themselves and not stick to rules for the sake o rules. If a rule has no justification and the person or organization who tries to enforce the rule cannot explain it to you: don’t follow the rule!
But this behavior has a flip side, you should be able to create your own rules and stick to them. In my opinion the best developers can take a step back from time to time and think about what they’re doing. Is this helping the client? Did I plan the work? Is this short-term thinking? Am I being selfish? It’s hard to ask these questions but it’s even hardest to change your behavior if you decide that it’s necessary, especially if you’re having fun!
This is why my final advice is to celebrate the small victories. If you tell a client that something will have to wait, be proud of yourself. After you write a unit test before writing any other code, get yourself a snack. When you tell a colleague to think about the long-term, have a cup of coffee together.
Discipline is hard to learn. It will be it’s own reward. But in the meantime, reward yourself!
Cover photo by Christian Lue on Unsplash