fb-pixel
Back to Blog

10 things that make your scrum master cry

Agile is a way of working which enables your organisation to deliver digital services with higher quality faster. In this piece we highlight some common things that make your scrum master cry. More importantly, these bad practices might easily prevent you from getting the benefits of agile.

1. Big design up front, have a proper plan and stick to it come hell or high water. This is called superb commitment, and will reward you plenty in the long run. During the project you will gain a lot of new information. This can be about market, end-users, technology, or even about your own organisation. When you design upfront you design without this information. Try to defer (design) decisions as much as possible, but not more. You still need to make the decisions instead of delaying them infinitely. Just in time will do nicely.

2. Have many people with lots of different roles. It’s easier for people when they just have to take care of their own thin slice of things, and the responsibility is nicely spread over lots of people! Fragmenting responsibility increases optimisation of parts rather than the whole. Involving more people makes the communication more tricky and prone to failure. Set up a small team, and emphasize everyone's responsibility for overall success.

3. Have strict, need-to-know basis on all information. You know, like secret agent style! This encourages the previous point, people only taking care of their own turf, and it is easier to have gatekeepers for information too! A good running lean team means an empowered team with lots of autonomy and self organisation. They will do their best to optimise their work. Not sharing information in this situation means that they lack the information to optimise their work and will generate waste.

4. It is crucial that everything is documented! We need to have a proper trail. In most organisations a paper trail is only used to play the blame game. Documentation is important, but focus on documentation which is needed after the project is over and the service is in actual use. Create documentation only when it clearly serves a purpose.

5. Have a fixed process that is used on every project, document, meeting, and essentially on everything! This way you can enable massive benefits of scale from previous successful projects. People will also feel familiar with things easily! Rigid processes have bad effect on the flexibility of your team, and can severely impair your ability to adapt to changes and find the best ways of working that suit for your team. Same things usually don’t work for everything.

6. Stick to well-established company tools. We paid so much for them, now we need to use them whether they fit or not. The team should have as much power of choice on their own ways of working. Others can point the team on what is to be done, but how it is done should always be defined by the team.

7. Developers are likely a bit stupid, better pre-chew as much as possible for them to make their life easier. This will make them more productive and happier, as they will have less demanding work, and less of it. It’s also very helpful if, instead of talking about the features using your own language, you translate it into extreme technical detail to the best of your ability, since developers aren’t able to understand normal words and would never care about the value a feature adds to the users. If developers wanted to work on simple stuff, they’d work at a meat packing station. Facing and overcoming interesting problems makes the work rewarding. When you get to decide stuff, you feel more ownership of the product, and thus motivate for greater effort. Also, talented developers are actually great at solving complex problems (provided they have access to enough information and are given enough flexibility)!

8. Don’t trust any others to do decisions themselves, because they might not know the stuff as well as you, and will just ruin everything. You can only trust yourself in this desolate wasteland, so have all the important stuff run through you. When you hire smart people at high rates, try to give them as much autonomy as possible so they can best optimise their work. The lack of delegation easily leads into you becoming a bottleneck for the process. This demotivates other people as they feel that they can’t make any decisions without taking them through you. Also nobody likes control freaks.

9. You also know your business better than the end user do, so don’t feel bad about making decisions for them too. When you create new digital services, you’re most likely creating something nobody has ever done before. This means that all information from existing services is not valid and at least needs to be verified. Agile development enables you to react to feedback, use this capability!

10. If things, for some reason, don’t go well, just add more resources for enhanced problem solving. Throwing more people and money at the problem usually solves it. Please just don’t, you’re only adding to the complexity here. First make sure you have a well oiled team. This most often means reducing noise and simplifying things. After that you can considering scaling the well working team, but not scaling first as then you’re likely scaling up the problems too. Always check with the team whether adding resources would help or only make the problems worse.

Authors

  • Janne Kiirikki
    Caring Software Developer
  • Peter Tennekes
    Agile Coach