Search this site
Why does Scrum fail – the project was not actually Scrum
Filed Under Agile, Challenge, Daily Scrum Meeting, Disadvantages, Empower, Issues, Process, Scrum | Posted on August 4, 2010
This is part of a series of posts that I am writing about, that deal with why Scrum projects can fail. It could be a variety of reasons, ranging from team resistance, to wrong policies, to bad management. In this post, I will deal with yet another reason as to why a Scrum project could fail. This is probably the most simple reason, yet can be difficult to determine. These are typically projects that are claimed to be Scrum, but are not actually Scrum. And there can be multiple such processes that the team could claim to follow, but the basic reasons for failure in a number of such cases would be that the team thought that they were doing Scrum, but were missing out on many of the core processes, which eventually led to failure. Some of these cases could be:
- The team decides to have a daily stand-up meeting, and considers that they are doing Scrum. However, they would find over a period of time that the stand-up meeting does not really lead to many advantages, and start deferring the meeting with people cribbing about the meetings appearing to be a waste of time. The reason would mostly be that the meetings were being used for status, or were not succint enough, or did not focus on the past day / present day / impediments only approach, and turned off people due to the time lost. Just meeting daily and talking about issues does not make a Daily Scrum meeting.
- One of the ways that people start to believe that they are following Scrum is when they believe that the Scrum team is empowered to take decisions, but when you get down to basics, that is fiction. To allow the team to be empowered enough to take decisions after thinking through the implications is something that is easy to state, and difficult to actually implement. In a number of cases, the managers of the various teams get involved in the decision making, and more critically, do it in such a way that the Scrum team is not actually involved. This makes the team members start doubting the actual concept of the empowerment that they were promised during training sessions.
- I have seen numerous cases, where when a team is in trouble, they start meeting daily for 10-15 minutes to gather around and discuss status, and then later call these as Scrum meetings. This is certainly not Scrum, those are typically status meetings run by some manager, and is there to ensure that the team is working according to a desired game plan, but just a short meeting daily does not make it Scrum.
- In other cases, teams cannot handle the openness that Scrum data as well as retrospective meetings entail, and start trying to limit the scope of discussion and modulate the discussion and data analysis rather than working through the data in order to figure out exactly where the team is. This can lead to significant deviations from the openness desired from a Scrum process.
Learn about Scrum – Why does Scrum fail – Dealing with a team that was hesitant, and it worked only after people actually were changed
Filed Under Challenge, Change, Daily Scrum Meeting, Scrum, Team | Posted on July 15, 2010
If you look at the title of this post, it does not mean that we convinced the people to change; it actually meant that in some cases, people were encouraged to leave for a different group, or when they decided to leave the company, they were not stopped. This seems rather drastic, but it turned out to be the right thing to do. This was another example (from thankfully not my present organization, but from a previous organization) of how Scrum gets labelled a failure in some cases even though there are other reasons for the problems.
Consider the case of a group with a number of senior and experienced people. They are used to their own way of doing things, going off to work for complicated items, being social only when they want to be, but otherwise pretty skilled people. You would not want to lose such people. At the same time, it is also true that sometimes people can be very skilled, but can lead to making or breaking of teams, and you need to get rid of people who can spread problems in the entire team. So, you had a team with many of such people, and things were working fine. However, overall, there was a realization by management and by leaders of the group that productivity was not what it should be, and predictability was something that was a problem. It seemed that even with such skilled people in the team, one would never be clear about what the current status of deliverables is, and whether the project was on the right track was difficult to measure. Replacing the project manager did not help in any way, and the introduction of new ideas did not seem to help.
So, with all the word of Scrum in the air all around us, it seemed that this was the way to go. However, we did not just jump into Scrum; the management of the team went in for training and for intensive Q & A, and worked out the changes, what are the advantages, and what would it do to the normal way of life. And it seemed like some sessions with the team, followed by Scrum training and some simulation exercises should get the team on the right path.
Initially it all seemed to be going fine, with everybody seeming to appreciate the providing of more information and access to the Product Manager, but just when it seemed to be settling in fine, the basic inertia of many members of the group seemed to have overcome whatever advantages. Cribs about the Daily Scrum meetings, jokes about daily reciting of past / present / future (the 3 basic concepts of the Daily Scrum meeting) and so on started causing problems in the team. It was fairly easy to identify the people who were starting to come unstuck, and some counselling seemed to work, but only for some time. It got fairly problematic that the regular activities of the Scrum team starting getting vitiated. Radical solutions were prescribed, and this meant the introduction of more Scrum oriented senior members from other teams, giving the message to many of the difficult folks from the existing team that they really should start working as committed team players, or they would need to start looking out. This radical therapy worked wonders, but is not really practical in many situations (you cannot easily bring in new experienced members so easily).
Learn about Scrum – Why does Scrum fail – Dealing with teams working across differnet geographies, optimization techniques
Filed Under Agile, Challenge, Features, Issues, Meeting, Problems, Process, Product Management, Product Owner, Scrum, ScrumMaster | Posted on July 11, 2010
Scrum by itself is normally not a reason for failure of projects, it is more likely that there is a process implementation issue, or a logistics issue that has caused such failures. In a series of posts, I am trying to post some of incidents and examples that I have seen where the Scrum project has gone through significant challenges, or failed. So, in previous posts, I have the following examples: Sponsors not confident, Not able to empower the team, Problems in Daily Scrum, Team not ready to move to Scrum. In this post, I take another example where there is already a challenge present in terms of cross-geographical differences, and how the intense engagement required during some of the stages caused a problem. Now, if you were to truly dissect this problem, you could see the same problem when you are doing more of a Waterfall, except that in those cases, the deeper level of customer engagement is visible in the beginning of the cycle, and is not needed to that high level as you move ahead in the cycle.
So, what the team did was to take the current mixture of Waterfall and iterative development, with the current Product Manager in another geography that was located at a different timezone with a difference of around 13 hours (basically meaning night-day or day-night). Before the team moved to using Scrum, there were a lot of discussions about going in for the Scrum model, and how it would work for the cross geography connection. One advantage was that it was only the Product Owner who was in a different geography, and so there was less of the logistics of getting the Product Owner for discussions. And this was a Product Owner who had worked with the team in the past in the waterfall based method.
And yet, after the first month or so, inspite of the worries, things were proceeding more or less on the same way that they were in terms of interactions, and all. The problems started emerging after the first Sprint, a time when in the past, the Product Owner would have started reducing the interaction in real time, not needing meetings at common times (since reviews and other evaluations could be done through an offline mode, over email). However, when using Scrum, after the first Sprint, the team again needed intense interactions with the Product Owner for the fresh set of features, and there were issues about managing the logistics, and convincing the Product Owner. One could sense that the Product Owner was making an effort, and by the time of the third Sprint, things started getting more complicated. The Product Owner would push back on the number of discussions required, and also on trying to get a common meeting time. Just setting up those meetings would take more time and effort, and this started showing on the productivity of the team (since they could sense the discomfort of the Product Owner). By the end, the product was delivered, but things had started getting tense and strained.
What could be done ? For the next time, we had long discussions with the Product Owner on the type of interactions, made some compromises regarding the number of meetings per week, pushed the team to stay late once in a while so that 1 meeting could be held at a time convenient for the Product Owner, and that did make things better.
Learn about Scrum – Why does Scrum fail – The sponsors worried about the lack of a schedule of features in the overall project, this worry extending to the end of the project: Part 2
Filed Under Challenge, Estimation, Features, Issues, Problems, Product, Product Backlog, Product Management, Product Owner, Scrum | Posted on July 5, 2010
In the first post of the article, I wrote about how senior executives need to see the list of features before approving the product development (the list of features is reviewed in terms of competitor analysis, projections of the direction where the product should be heading towards, and also whether these are features that customers would be willing to pay money for).
Going by classical Scrum approach, the Product Owner generates a Product Backlog. However, the Product Backlog is not an approximation of the list of features that will make it in the product in the defined schedule, since there has been no breakup of the features into user stories, no estimation has happened, and so on (these steps happen in a very accelerated manner in the conventional process we used at the start of the project). So, either we still do such a process at the start of the Scrum cycle, which also means that we are going in for the breakdown of the features, going in for task estimation, and so on.
However, this sort of breaks down the core advantages of Scrum. Scrum allows you to respond fast to changing market needs, which means that features are prioritized and detailed at the Sprint planning level (with a Sprint typically being for a period of 2-4 weeks). If you confirm the list of features right at the beginning, then you are not able to modify the features through the cycle. Getting this past the executives was a bit complicated, with having to take through the broad directions of the product, as well as a list of features in the Product Backlog along with a list of priority.
Now, since this was the first time that the team was implementing Scrum, and this was an important product, the executives wanted a quick summary from the Sprint review meeting at the end of every Sprint. Now, the first few Sprints were where the team was learning about the Scrum process, and it took time for us to see progress in terms of getting the Scrum process working. However, in this case, since the executives were seeing progress from the first set of Sprint planning, and did not get a detailed schedule in terms of timing of implementation of features, they were focused on seeing whether the features that were planned for each Sprint were making it. This added a high level of pressure to the team managers, and also on the Scrum team. With the first few sets of Sprints not showing the desired progress, the review sessions with the executives got more and more uncomfortable; and it was getting harder and harder to justify the use of Scrum.
By the third month, we were behind the feature implementation (as seen in the Sprint Planning meetings), and given that we did not have a Product Feature Schedule in place, there was a feeling increasing in senior management that there was some foul-up happening. At this stage, there are 2 possible options – Either we slowly start to turnaround matters, and when we are confident that things are indeed improving, start projecting a much more positive attitude to senior management; or we face so much pressure that we are forced to go back to a Standard Waterfall process. Either case is a huge setback to the process of Scrum implementation.
What can improve matters in such cases:
- Get more success stories in terms of Scrum implementation in the organization, so that the senior management can have more confidence
- When projects are so critical, then the monitoring of the projects in terms of ensuring that Scrum processes are being followed needs to be much more careful
- Do more detailed interactions with senior management in terms of laying out what Scrum is, what are steps that need to be taken, what are some of the challenges, and so on.
