Learn Software Development » Process

Learn about Scrum – Why does Scrum fail – Dealing with teams working across differnet geographies, optimization techniques

ashish — Sun, 11 Jul 2010 07:16:44 +0000

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.

Scrum challenges – Handling cases where the same team has to work on feature development and also support of previous versions and fixing bugs – Part 2

ashish — Fri, 21 May 2010 18:25:09 +0000

In the first part of this topic (Same team working on new features and production support), we talked about the problem that is there when a Scrum team has to work on new features as well as on production support of the existing releases, its impact on morale, and how if the Scrum team does not take this support into account, then their planning and estimation will fail because the time required for this production support has not been taken into account.
In this second part of the post on the topic, we discuss more on how a Scrum team can take this effort into account and ensure that this work is properly accounted for. Going down this path will help the Scrum team to account for their time spent on both of these activities, and also inform the stakeholders of all the efforts put into these 2 different projects. The first and foremost task is for the team to determine what is the extent of effort would be to do production support. Once this effort is know, and it is greater than 10-15% of the total amount of effort available by the time, then production support needs to be accounted for separately.
One way that the teams account for and allocate time for such production support is by creating a separate backlog that is meant for production support. Both the backlogs for new features and production support are done by the team, with the Product Owner determining the extent to which the amount of effort from the team needs to be allotted to the Production Support backlog. Through this method, the team is able to review the progress in both the list of new features as well as the bugs (and other production support activities) in the Daily Scrum.
Another way is not have a separate backlog for the production support, instead there is one common backlog for both sets of activities. This makes the prioritization and allocation of tasks much more complex for the Product Owner, but also makes for better decision making and trade-off between new features and production support. This trade-off has to be explicitly made, which ensures that the proper business decision is made (rather than allocating a ratio between 2 separate backlogs, which sometimes means production issues are fixed that are less important than new features). To increase the chances that these production issues, which are deemed less interesting for the Scrum team are fixed, they are compared with new feature work that is going on, and wherever the production issue aligns with new feature work, fixing the production issue can be made as one of the criteria for marking the new feature work as done. Of course, this means that some amount of effort may be spent on a production issue that is slightly less significant, but would otherwise never get fixed on its own. An advantage of adding such bugs to the criteria ensures that these bugs will remain fixed and tested for in future versions of the software as well. And of course, there is opportunity to learn, since production issues means that the testing criteria used in the past missed something.

Scrum – what happens when the Product Owner is not fully engaged with the team

ashish — Wed, 12 May 2010 17:40:08 +0000

As a part of the Scrum process, it is essential that the Product Owner has to fully engaged with the team. On the other hand, one of the biggest problems with the failure of Scrum teams is due to a Product Owner not being fully engaged with the team, due to a multiple number of varied reasons. For the Scrum process, there is the need for a Product Owner who is able to do the high level translation of broad features into specific feature requirements, and is also able to work with the team in terms of answering many different queries from the feature team, and also being on call (to some extent) and being able to deliver the time that is needed for the feature team.
You need a Product Owner who understands the needs of the team in terms of being able to define a prioritized Product Backlog list and maintain it over the duration of the project. In addition, the Product Owner should be able to properly take some of the more vague requirements as well as some of the more specific requirements, and be able to convert them into a user stories that the Scrum team can then convert into actionable tasks. And of course, the Product Owner should also be able to answer queries and points raised by the Product team (which can take time and also mean that the Product Owner needs to be available at regular intervals to the Scrum team).
However what happens in many cases is that the Product Owner does not meet these requirements. You have a person who is skilled at being able to review current industry and competitor positions, but who is senior enough that the person is not expected to get into the kind of detail and closeness required for the Scrum team Product Owner. In many cases, the Product Owner is actually a person who has 10-15 years of experience in the industry, or more, and it is difficult for them to visualize the level of support required. On the other hand, when you have a smaller team with not too much organizational focus, it is very much possible that a more junior person, even somebody from the marketing team is moved to the position of a Product Owner (in some cases, this will work; but there is a much higher chance that the Product Owner will not be able to do a good job). When you see such a thing happening, then you know that things are going to get problematic for the future of the Scrum team and the process and need to call
it out (and some people will be a bit diffident about calling out such things; but a proper ScrumMaster needs to what is best for the project rather than face a potential risk to the success of the project). The Project Review meetings are a good forum to raise this issue, along with other issues that could cause an enhanced level of risk to the project.

Scrum Problems: When external stakeholders intervene frequently in the Scrum meetings

ashish — Sun, 25 Apr 2010 16:59:54 +0000

In any Scrum process, the stakeholders are typically separated into being either Chicken or Pigs. This phrase refers to the fact that if you consider a chicken and a pig opening a restaurant called ‘Eggs and Ham’, the chicken just has to contribute eggs on a regular basis, without apparent harm; however, the pig has to contribute ham, and the personal involvement and stake is much higher. Similarly, in the case of Scrum, the Scrum team are called Pigs (no bad reference meant), while the external stakeholders are called Chickens. In the process of Scrum, there are constraints regarding the involvement of the external stakeholders, especially in the context of meetings such as the Daily Scrum.
The concept is that the Scrum team is an empowered team, who can make decisions about how to execute the project, with the requirements being given by the Product Owner. They are the most informed, and in many cases, you will have external stakeholders giving advice (or orders) even when they are not so well informed, something that can harm the project. Hence, in the case of Scrum, the influence of external stakeholders is sought to be limited, with them not even being allowed to speak in the Daily Scrum meeting. However, this is easier said that done. The Scrum team may have had the Scrum training, and know that they are the empowered team, ready to make decisions, but external stakeholders, especially when they are senior, may not know these rules. In some cases, ego can also come into the picture, and even if the external stakeholder knows theoretically the concept of not trying to influence the team, they may see cases such as the team’s Velocity being low, or the team struggling with dependencies, or not able to complete the desired set of features on time, and would try to use their experience to try and control how things are moving.
How do you detect when external stakeholders start getting into influencing the team ? There can be many cases where you can slowly start to figure out that something like is happening. Here are some of the ways that you can figure out that something like is happening:
- One of the biggest rules is that external stakeholders are not supposed to talk in the daily Scrum, so when you see chickens talking in the Daily Scrum, you can figure out that the biggest rule is getting broken
- When the team needs to take decisions, they are often unable to get these decisions without a process of approval. This can prevent the team from feeling that they are empowered, including even for technical decisions, where you would expect that the team would know best
- Priorities of features can be changed by external stakeholders. As per the Scrum process, the Product Owner is the one person designated as the feature driver, the one who decides the priority of features, and this is communicated through the Product Backlog, and discussed in the Sprint Planning Meetings. If it becomes apparent to the team that the chickens can change the priority of features directly, rather than through the normal Sprint Planning meeting, it becomes clear to them that the external stakeholders are the ones who are driving the process.
If the team does not get the feeling of empowerment, and they start seeing large holes in the Scrum processes they have learned, they will start considering this to be another normal process, and you start losing the advantages of the Scrum process.

How to ensure that Scrum Backlog Management is ensured, to ensure that the team is on the path of success

ashish — Tue, 13 Apr 2010 16:53:36 +0000

The success of projects where the development methodology is Scrum depends on many factors. One of the major factors controlling that governs whether the project is a success seems very obvious, but it is necessary to call this out – this factor is that of ensuring that the application development is on progress and the desired features are getting built, or you can call it ‘backlog management’, since backlog is the process used in Scrum to capture all the feature requirements and space them over a period of time (called the Sprint cycles).
Now, in Scrum, the concept is that you would define tasks to be done in every Sprint cycle, and at the end of the Sprint cycle, you take a check of whether all the desired tasks have been done. If you are doing all your tasks, then everything is fine, and you are meeting your backlog management needs. However, in a lot of Sprint cycles, you will find something or the other is not fully done, and over the period of the cycle, you will run into many instances of the following problems:
- The features don’t get totally completed, instead, there is always something or the other that was pending to be completed
- Even at the end of the Sprint Cycle, the initial set of tasks don’t really get completed
- Features that need to skip from one Sprint cycle to another because sizable portions have not been completed in the current cycle
- A feature has been marked done, and also a demo has been done at the end of the Sprint cycle, and then it is found that the feature or task needs to be re-opened since there is additional work to be done
- Dependencies between features is causing some features to be waiting for other features to be done, and till that time, these features remain open (with little clarity about when they will be marked to be started)
- Ideally, a project backlog containing the overall set of requirements is supposed to be reducing in terms of overall requirements during the time that several Sprint cycles are happening; if this is not the case, it is a serious problem
- If some or all of these conditions are found to happen during the course of the Scrum process, then there are significant problems with the implementation of the Scrum processes, specifically the issue of Backlog management.
When backlog management is an issue during a Scrum cycle, it has multiple impacts. External stakeholders start to believe that the team is not making progress, and if Scrum has been implemented recently, then part of the blame falls on the Scrum process and leads to a reduction in the support of the Scrum process by the stakeholders. Equally critically, the product owners (representing the Product Management) do not really get a comfortable feeling that feature implementation is happening and that their goal of ensuring that the product / application has enough important features at the end of the entire Product cycle is met.
How do you address this ? First of all, you need to take a cold look at your current process and determine whether your product development is facing similar issues.
How to handle such issues will be covered in the next post..