Have you heard someone saying “I tried scrum and it didn’t work. Scrum is not working at all!” I heard that many times. It is difficult to admire that it was not the methodology fault, it was your fault that everything failed. The big challenge is that there is no out of a box solution, which suits anyone. You need to go through all the way from the learning to mastery, face a lot of difficulties, overcome them, master the copying and them move to adopting the process for you – changing and improving it. So let’t discuss the problems PM can face while adopting new methodology (you know what I talking about ^_^) All these promlems are from my and my colleagues experience.
At first I thought that I should not share these problems, as they are really unpleasant mistakes. But the idea that it can help someone was stronger. I am really not so smart and was even less several years ago, but I am learning) My colleagues – PMs and friends helped to collect this list, so thank you, guys!
I can’t even choose which choose for the start – almost all of them are epics, so the are not in the severity order.
Sprints have different length
It is the first thought you can have – why not to have the sprint longer if we haven’t managed to do everything? Nooooo!! I struggled with myself when we had the first sprints and I worked out.
If you just make your sprint longer – the team becomes ok with this idea, that they don’t need to work hard – you always can move the demo) You also won’t be able to rely on your velocity statistics if the sprints have different length. How we can compare 5 SP done in 2 weeks and 7 done in 3 weeks?
Ask yourself, what is the real reason to make the sprint longer – are you afraid to show that you did nothing? Think of that from a different point of view – it is great! You finally have the starting point for your improvement process. Making your sprints the different length you are only trying to hide any issues you have. I bet your development can be good and you may have all the issues in the planning process, estimation, etc.
“What you do when you fail the sprint? We start another one!”
Planning more the team can manage
I have seen the situation when the team continued planning the N story points for the sprint not considering the fact they are failing sprint by sprint – they never managed to do that commitment! Why they continued doing that? Every time they promised their PO to “work harder”. I asked them “Why to not plan less tasks for the sprint?” They were so surprised – “How we can plan less, we won’t fit the deadline!” May be they liked the continuous stressful situation, but the idea was so simple – try to plan less next time – anyway, you are not doing all that you plan! But try to imagine how more optimistic would be the team if they succeed in completing the sprint?
Sometimes the team overestimates their capacity, because they forget that they are not working 40 hours a week – they spent some time on meetings, studying and other activities. So remind them about that next time they make the commitment.
No definition of done for the stories/Definition of done is impossible to reach
How we can reach the destination if we don’t know where we are going? How we find out that we are finally there?
Stating the Definition of done is important not only for the whole project. If you do that early it can be invaluable not only for team to get the clearly acceptance criteria but also for setting the real expectations between the team and Product owner.
Too long daily stand-up meetings
If the meeting is longer than 20 min – seems that something is wrong. The most common reason is that developers start discussing technical problems during the daily meeting.
Start with asking everyone answering the easy questions “What I did yesterday? What I going to do today? what problems do I have?” It is better is Pm avoids the “reporting to me” style and the team members are speaking easily, talking to their team mates, not the manager.
Ignoring meetings
It is good to “cut the process” for your team. To adopt it and improve. But to be able to do that you have to pass the first step – learning (see shuhari principle). Here you can do that only through copying the process. And only after that you can move to the mastery level.
You have no demo – the client does not understand what you have done. You loose the most valuable “first feedback”.
No retrospective – you have almost no chance to improve your process. Team continues facing the same issues in every sprint.
Not all the team members take part in the meetings – it is not a real team. Some of the members does not know what is happening, they are not involved in the process.
PM tries to “push” the team to adopt the new methodology
I think the previous problem can be the result of this one.
Once you can see you PM entering the room with a shining smile “We will do scrum from today!” You should know, it is not your PM entering the room, it is the apocalypse opened the door and now is going to “happen”.
I think that agile is the methodology that have come from “the bottom”, so it is against it’s nature, when it is “set” by the top management. You can spread the idea, educate your people, make them interested…But not “set”. Top management may say you that you propose the “too slow” changes plan, but the slow means stable here.
QA is involved only on the last day of the sprint
QA are the people who are easily “forgotten” in the agile process. Developers plan their work so they provide the user stories for testing the day before the end of the sprint (luckily!) – and feel that they are “done”. But the QAs do not manage to test the stories, so the team does not score any story points in the sprint. Ok, the user stories are moved to the other sprint, QAs start testing them, involve the developers in bug fixing – distract them from the user stories from that new sprint. So this time developers even don’t manage to finish their part till the end of the sprint…And so on. You finish having the “bugfixing” sprint.
It may help splitting your user stories to the smaller ones – so the developers will finish tasks earlier. Also you can limit the number of tasks in progress. It will force the developers to finish the previous task before starting the new one.
Don’t forget about the preparing your stories for development – QA should spent some time on the writing use cases, some tests before the task is ready for the developers to start working. Qa can even control the “definition of ready for the development” and move the User Stories from the “analysis” column to “ready for development”.
Too long planning meetings/stories are not prepared for planning
When the team comes to the planning – it seems that there are so many questions they have the PO to answer. Almost every story contains a lot of unknown areas. Discussions last and last. The team spends a day for planning and it exhausts everyone. Team starts hating the planning meetings. And more they hate it more they try to postpone it to the last minute.
The solution can be еthe following: perform the backlog grooming sessions. In a backlog grooming session, developers will validate or disqualify their assumptions by asking questions of the product owner. Spending 1-2 hours a week on backlog grooming you will keep the top of backlog prepared to the planning meetings and they will take you 2-3 hours and even less.
Client knows nothing about scrum and no one told him how we are going to work
Of course, your client heard something about scrum. If you ask him – he would say yes, as he doesn’t want to be the one who is not aware of the last trends. Sometimes we forget, that not everyone is working in IT and knows all our terms. Your job is to involve the client in the process, show him his role and set his expectations on how he will interact with team, how the team would report, etc. It’s a pity we rarely find the strong PO on the client’s side, so we need to find the workarounds.
The closer you would be to the client, the more you share with him – the better you would be be able to get the valuable information and feedback.
Please fill free to commit to my collection of facepalms!
@tisquirrel 
This is a great summary of the most common scrum problems – unfortunately I’ve seen most of them too!
I always try to tell people that scrum doesn’t really solve any problems, it just makes the problems you already have more visible faster. Of course it can only do that if you aren’t running around breaking the rules in order to hide the problems, which is what a lot of these problems boil down to.
Thank you.
You are so right to say that agile just makes the problems visible. It is a great tool for that. Some managers think that they can just launch scrum and then everything will work by itself)) And if something is not ok – let’s hide it, other way everybody would see I am not a good manager/scrum master 🙂
In addition I like to add: we hire “superman” to implement & we implement scrum the “BIG BANG way”.
A great summary about Scrums. It will definitely help people to know more about Scrum. Many people like me who believe that having process in place will resolve the issue, will get to know that there is much to be done, just having tool wont solve the problem.