I have been part of many scrum teams in my years as a consultant and recently as an employee. In this post I will share some often made mistakes in scrum teams. They often stem from misunderstandings, organisational limitations, failure to adapt or not being fully on board. I also throw in my opinions on these items. The list is in no particular order.
1 - No definition of ready (DoR)
I have worked quite a lot with web development in my career. During refinement of stories we would often lack a design of the website. So there was really nothing to go for when we were to refine this. You may end up in the situation where you just say "oh well it will come during the sprint let's guess from previous stories and put some points of this, it is complexity after all". So you can now put it in the sprint backlog. However sometimes the design never comes, and the story is blocked throughout the entire sprint leaving you unfulfilled and you have a feeling of failing your commitment.
It could be something else than a design you were lacking, such as architectural decisions, a key decision from the business or an endpoint another team has to develop. The bottom line is that this story is not ready for final refinement and not ready for the sprint backlog. But how do you catch this? This is where the Definition of ready come in. I would argue that the definition of ready defines when something is ready for refinement. Most would say that it defines when something is ready to be put into a sprint. Here I would argue that refined stories can be put into a sprint, but sometimes stories may not even be ready for refinement - as there are too many outstanding questions.
The product owner will know from the DoR that it is not ready for refinement. Saving everyone's time.
The definition of done will let you know if something is ready to be refined or not. The development team may not even have to see the story, because the product owner will know from the DoR that it is not ready for refinement. Saving everyone's time.
The DoR is not something that you sit down and write when you start a new scrum team. But often you find that you need one after a couple of sprints. Like everything in scrum this is something you learn as you go and you can build a great DoR over time. It is a great thing to revise this during a retrospective. It is good to have in writing, but you will quickly remember it during refinement if it is used often.
2 - No definition of done (DoD)
Like the DoR most will not have a Definition of Done which is also a great tool. It identifies when a story can be moved to done. It must be obvious that a story can be moved to done when... it is done! But we may have different opinions on when something is done. Have you ever worked with someone that moved things to be done when the code was made, but untested and perhaps residing on a local machine? This is what the “Definition of Done” combats. It is a common understanding of when something is done. A definition of done may be that the code has to be unit/integration tested, checked in and deployed to some environment. Some may not complete stories before they are in production.
If you do not have a Definition of Done you may often find that stories come back from the grave (done column). Stories move from the right of your board to the left. Instead of from the right to the left.
Both the DoR and DoD can be seen as a practice to get better sprints. They may be made just to identify problems and later discarded when the problems are no longer there.
3 - Way too long daily scrum
Your daily scrum is 5 minutes right? I have been on many teams where the daily scrum goes way over 5 or even 10 minutes. It is not a problem if it happens once in a while, but having long daily scrum meetings everyday is tiresome and often a waste of precious time. But what is Daily scrum? According to Mountain Goat Software It is a daily meeting where each member of the development team answers the following questions:
- What did you do yesterday?
- What will you do today?
- Are there any impediments in your way?
These should quickly be covered by each team member. The times where I have seen Daily scrum drag out is when the team gets into solution mode or the product owner has a comment (on everything). Let us start with the first item - solution mode.
Daily scrum is not meant to solve problems but rather letting the team know what you are doing. If you had any problems yesterday or need an extra pair of eyes on something this is the forum to bring this up. But you should avoid discussing solutions as that takes up valuable time for the whole team. You should rather figure out who can help you with your problem and talk after daily scrum. Sometimes impediments will arise during the daily scrum meeting. Such as members getting distracted by other tasks than the ones in the sprint. This the Scrum Master will take note of and handle after the daily scrum (not during!).
Sometimes the team may feel that daily scrum has become "daily status".
The daily scrum meeting is not a status meeting. The meeting is for the team and not for the management. The product owner is not supposed to be there during the Scrum meeting. However most teams I have been on we have allowed the product owner to listen in. Sometimes he/she will get some time afterwards to talk, but the product owner should not be disrupting the daily scrum of the development team. This depends a lot on who you have as product owner. Some product owners are excellent at managing when they should speak up.
Sometimes the team may feel that daily scrum has become "daily status". This is not what it is supposed to be. It is a meeting meant to find impediments and figure out who needs help.
Another reason why the daily scrum may drag out is that the team is too large, more on that later.
4 - Multiple Product owners on the same team
I have actually seen this work well - but rarely. Instead of having 1 PO with one or several products on a team we had 2 or sometimes 3 product owners with different products on the team. It is not wrong for the team to have multiple products in their portfolio. But having multiple POs makes things rather interesting. If they know before planning which product is prioritised then there is little problem in having multiple POs (except for extra overhead). If they do not prioritise among them, you may end up in a situation where in each planning your PO's start arguing who gets some development time this sprint. Where all of them may leave disappointed and have to return to their stakeholders with a new plan.
Multiple product owners may also create subteams within your team. Always having 2/5 developers working for one PO and 3/5 working for the other will essentially make the team two teams in one (having 2 subteams). The reason why this team is not split into two is usually organisational (They have the same manager).
5 - Not being cross functional / each persons working on their own thing
Scrum teams should aim to be cross functional. Now what does this mean? Again I find that Mountain Goat Software has the best article on this. Cross-functional means that you do not have a team consisting of specialists or almost only specialists. Specialists means someone who can only do one thing. It may be that you have a team with a database engineer, web designer, backend developer and frontend developer. This is not a cross functional team, ast these are highly specialised people. In a cross functional team your database engineer may know about backend development as well as database development. But not the other aspects. The Backend developer may know about database and frontend development and so on. In a cross functional team people have multiple skills but are not meant to have all. Essentially there are no "Database", "backend", "Frontend" and "Designer" roles. The team members usually have multiple roles.
This is also a great way to share knowledge and learn something new. Pair programming or being two team members working on the same task is not possible if you cannot give any input to one another. Which is another great reason to aim for having cross-functional teams.
In a cross functional team people have multiple skills but are not meant to have all
Planning is also tough for teams that are not cross functional. "Our Database engineer is on vacation so we cannot do anything database wise" - leaving our backend developer with a lot of mocking to do towards the database. Pretending what he will get when his colleague gets back. There will also be a lot of "handing over" of tasks. You cannot start frontend development before you have a design. So you have a lot of dependencies in your team.
You may also end up assigning stories to developers during planning. You need to check that everyone has "enough" to do in the coming sprint. Since you cannot pick naturally from the top of the sprint backlog as most tasks are not "for you". Basically you end up micromanaging the team which can block the flow when someone with an important task calls in sick - no one else will take his/her tasks up.
Estimation and refinement is also easier if your team is cross functional. People may feel that they have to estimate something they have no idea about if they are not cross functional.
6 - Not following up on retrospective items
I was first thinking about naming this item "Not having retrospectives". You of course have to do retrospectives in order to not follow up on your retrospective items. I have never been on a scrum team where retrospectives were not held - so it was not that relevant. I believe that retrospectives are one of the most important aspects of scrum. It is an iterative improvement of the process.
I have even seen a retrospective item that was that "we need to start following up on retrospective items"... this was neglected as well
Back on topic on "Not following up on retrospective items". I have seen this many times. I have even seen a retrospective item that was "we need to start following up on retrospective items"... this was neglected as well. It is not that people do not wish to follow up on these items, it is just not part of the "sprint backlog" and often is not visible. So what do we need to do? well make action items visible! Perhaps iterate over who has an action item after some of your daily scrums - perhaps Tuesdays and Thursdays or whatever works for you. I do not think that you should view these everyday as it may take up valuable time. The scrum master should be on top of this and make sure that actions on retrospective items are followed up on.
Another approach is to print them and hang them up on a wall. I have tried this with very little success. As this tends to become part of the office decoration.
Even though you do not follow up on retrospective items, retrospectives may still leave the team with a great feeling. It is a good place to vent emotions both good and bad. It also lets everyone speak - and best of all, it improves your process.
7 - Scrum master / Product owner having more than one role
This happens A LOT, and is probably the most common on this list. It is often said and written that the Scrum master should only have one role on the team. It is also considered a fine practice that one scrum master has several teams, as long as he/she does not neglect any of them. The problem occurs when a scrum master is also a developer or has items in the sprint that he/she needs to take care of. Now which is the most important for the scrum master? To work on tasks or remove impediments for the other team members? How much of this person's time can be spent on development? Well these are some of the reasons why the scrum master should just be a Scrum master (however I have actually seen it work quite well with testers being scrum masters).
What is worse than the above is when the Scrum master and product owner roles are mixed up. The product owner represents the customer and the scrum master the team. It is rarely seen that one person can wield both hats without one of them overpowering the other. Perhaps the scrum master/product owner starts slacking on the scrum principles (retrospectives/refinement often being the first to go) or perhaps he or she does not have time to care for the customers. Meaning the forecasts, long term plan and product suffers.
However I have heard of teams where a combined Product owner and scrum master has worked.
8 - Too big teams
Have you ever been on a 8+ man scrum team? I have been on a 9 man scrum team (9 developers). This team had an awful long daily scrum. The refinements were split because having everyone do planning poker took way too long. Effectively sub teams were created in this team. Something to note is that if you have 3 people then you have 6 communication points. Everyone communicates with 2 others (32). If you have 5 team members then it's 20. 9 It's 72. This is a lot of communication and interaction points in a team. This is basically why I believe teams that are bigger than 6 people start suffering from communication overhead (without counting scrum master and product owner).
Scrum emphasises that everyone gets to say something (During daily scrum and retrospective). Having a big team creates a lot of discussion. Not only does everyone speak, most of the time people will also have a reply or wish to discuss.
9 - Products not projects
Why do we keep on talking about products in scrum? The team has a portfolio of products that the product owner - yes - owns. A product could be a website, an app or a webservice.
The big difference between having projects and products is that projects are usually done when the deadline is reached and the software is delivered. There might be some burn-in period where bugs are fixed and corrected. However the project is now "done" and the project manager can move on. The team may also get shuffled around so that they can be ready for a new project. When you have a new project you usually have a new team put together, just for that project.
Products are not done until they are dead. Projects are done when the product is delivered (or cancelled)
If you are doing scrum then the team will be very consistent. Yes people come and go put the team is not created just to do this project. The team is put together to work on it's product portfolio and together with the product owner take ownership of that. Products are not done until they are dead. Projects are done when the product is delivered (or cancelled). When you look at the timeline for projects the first version is often at the end of the timeline. For products it is somewhere in the middle as you keep working on the product after the first release. Projects can deliver iteratively as well though it is more uncommon.
When you first start developing a product there will be more work to do. But when most of the features are done and the team has few tasks or stories for this product, then the product is still owned by that team. The outcome of a project is a product, but creating teams for projects makes it harder to maintain this product afterwards - as the team will be gone.
Scrum teams thrive with products as the team and portfolio is consistent. Scrum teams have a hard time doing projects as you need to recalculate your velocity for each project (which takes several sprints). Your learnings from previous retrospectives are also up for discussion again with your new team members. Which makes the team members feel that they have to start over. Which makes it harder to become a high performing team.
10 - Believing adopting scrum will be easy
So you have taken your scrum certification and you are eager to do Scrum. It is rarely said how hard it is to correctly implement scrum, but rather it is said how it makes everything easier or fun.
As previously mentioned it requires organisational restructuring to do Scrum. You need a product owner, you need a scrum master and you need a dedicated team (no shared members between teams). If you can get these things in place you are on your way. If you cannot have this setup, you will likely struggle. You must also have some great tools - especially a board (Jira/trello are great tools for scrum). The product portfolio also has to be consistent and the team needs to rehearse and get used to the scrum disciplines. The team needs to get used to having daily scrums, demo, retrospectives, planning and refinement.
It is rarely said how hard it is to correctly implement scrum
It takes time to adopt scrum and figure out how it works for your team. Every team is different and will do things a bit differently.
Wrapping it up
Scrum is an excellent agile method when applied correctly. However it can also be a lot of process overhead if not. Often the reason that scrum fails is due to organisational restrictions. Such as not being able to get a fully allocated product owner or scrum master. I have been on teams where scrum worked very well and I have been on teams where it did not. If you have trouble with scrum you can always try another agile methodology - perhaps a less strict one. It is always a good idea to check what you are doing against the the agile manifesto. If you are violating the agile manifesto then you are likely doing something wrong. Yes the agile manifesto is extremely simple compared to most agile methodologies.
If you are violating the agile manifesto then you are likely doing something wrong
This was my list of scrum mistakes. I believe most of us have seen some of the above. If you have another opinion than mine please let me know in the comments, it's always great to have some feedback and reflect :)