English | EN 5 ways to get your Scrumteam gimped
Mar 13, 2014
1. ScrumMaster role without an Agile mindset.
The role of scrummaster is a very important one. Then why is it that this role still is given to people without an Agile mindset and/or experience ? Lots of times the project manager gets picked for this role. This choice is in itself an obvious one for organisations that are still transforming from a more traditional way of working. The role of a scrummaster is a managing one, so a project manager is the obvious choice, no ? Wrong! Project managers want to control how the work is done, when the work is done, and what kind of work is done within a certain timeframe. You can’t blame them; over the years he is held accountable for the outcome of the project and, therefore, he wants to manage the team. Now in scrum the whole team is responsible for the outcomes and is self-managing.
So don’t randomly pick a Scrummaster; if possible let the team be part of the selection procedure. Don’t go for the obvious project manager pick. Make sure that the person is a servant leader who knows what Agile and Scrum means. So he can coach and teach others the way of scrum within and outside the team. If you can’t find any, send people who fit in the description and have an Agile mindset to a Scrummaster training. I have done as well; it really gives you new insights and, besides that, is fun to attend to.
2. Scope is Fixed.
Wrong! Scope is not fixed. What a lot of people forget is that the big difference between scrum and traditional ways of working is the way they approach the devil‘s triangle. In scrum the scope can change. Traditionally, scope is seen as fixed. The time, cost and quality are accustomed to change. So make the team aware that Scope is flexible, and time, costs and quality aren’t.
3. Product owners can’t make decisions alone
“Hi, I am the product owner. I got great ideas on how to improve this application and have innovative new ideas that really add value, yet I have to constantly ask my superior or his manager if they have time to check that they feel the same way” is not what you want to hear as a Scrumteam. The risk is that the PO will become the bottleneck for the team. This will result in a team that will lag behind in creating new value for your organisation just because of the fact they have to wait way too long for any decisions to be made.
Make sure that people outside the team don’t make the decisions for the team. In Scrum they aren’t responsible for what is being delivered the team is. The product owner is part of that, and he should be given the needed mandate and the responsibility he deserves.
4. Team isn’t a team
Then why do I stumble upon dedicated teams within Scrumteams? One for the documentation, one for coding, and one for testing. And they work like this 1st Sprint is about creating the functional documentation, 2nd Sprint is about realizing the documented functionality, and the 3rd Sprint is about testing the documented functionality. Or they put the 3 phases in 1 in sprint. By this Testing will be done less adequately because of the time shortage you will create. And does this sound familiar ? It should because it’s waterfall put in the Scrumframework.
Teams should be multidisciplinary teams and work as one. Scrum is about teamwork, collaboration,transparency,keeping it simple, etc. So, don’t create teams within the Scrumteam.
5. Scrum team is too large
The bigger the team the better, right? You can work on more stuff to be done and in less time. Wrong! If a team gets bigger then 9 people it’s harder to communicate, collaborate, and the team loses its dynamics and will this result in less kaizen moments.
So that’s why you need competent team players who like working in multidisciplinary teams and don’t mind to work simultaneously on new functionality. The size of the teams should be around 7 Plus or Minus 2.
Overall:
Try to follow the simple rules scrum describes (https://www.scrum.org/Scrum-Guide), there aren’t much. Keep aligned with the agile-manifesto. Make sure you got a experienced Scrummaster who knows how scrum works and spots the signs of “waterscrum”. Get a Product owner that can handle the responsibility and has mandate so he can make decisions. And create a multidisciplinary team.
About the author
