Learn Software Development » Product

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

ashish — Mon, 05 Jul 2010 09:36:28 +0000

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.

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.

How to ensure that Scrum Backlog Management is ensured, to ensure that the team is on the path of success (contd..) – Part 3

ashish — Tue, 20 Apr 2010 18:07:23 +0000

The past 2 posts have been along about how to ensure that the Backlog Management is properly done, and also to try to take measures to improve the way that the Backlog is used. In this post, we will continue our discussion on this topic.
Some more items that a Scrum team (and the ScrumMaster) need to spend some time discussion revolve around the following queries (and trust me, these are queries that you need to answer in order to ensure that you are making your feature / user story development process as efficient and complete as possible).
- Have you properly defined what done means ? Done in the case of software can be subjective sometimes, especially when you throw in the comfort level needed by the testers, and the quality and level of bugs found for the feature. To make these subjective parameters as much objective as possible, you need to specify criteria that help you determine what ‘done’ means. Review these criteria over the course of your project to verify that everybody seems comfortable with this criteria, and can be met.
- Once you have defined the criteria for ‘done’ and made sure that the team is fully aware of these criteria, the next step is to make sure that the team is actually following these criteria. There is nothing that can increase the scope for confusion in a project than when the team does not follow the criteria, or when the criteria are badly drafted. They increase the chance of more subjectivity and individuality being used to determine when a feature is actually done.
- Who all can overwrite these criteria. You all know it, when the project manager or somebody senior comes in and says that we need to get this out of the door, so let us relax the criteria this time. And wham, the team has the message that the criteria is flexible, and would you believe it, there is the feeling that maybe there could be another reason to relax the criteria (or even more so, when the team believes that they are working on a critical feature, and it will be approved even if the criteria is not being met). In some cases, you have to bow down when these deviations are being forced on you, but make sure that you are fighting them.
- Are all the logistics already in place ? Processes already defined ? When I say this, I mean that if some feature work is going to happen that needs a specific set of equipment (hardware / software / space), then those should already be available. Else, there will be perfectly valid reasons as to why the feature was delayed. Further, the lack of such planning typically ends up impacting more than one feature.
- I mentioned it in an earlier point, but need to make sure that when the process for defining a feature being complete is being written, it includes all the testing processes. As per Scrum, when a feature is done, it is of shippable quality, and one would need to ensure that all the required amount of testing cycles and bug-fixing has happened as part of the Sprint estimates.

How to determine the list of features for management approval at the start of a project when using Scrum

ashish — Sat, 03 Apr 2010 17:51:16 +0000

Consider the case of a product development company working on multiple products. If you consider one of these products, let us call it ‘Video Producer’, which is now in version 5. The development cycle of a version of the product lasts 15 months, and in the current run, the team starts the product version 5 in May 2009, to finally release near August 2010, after a period of 15 months. Now if you consider that this is a software which earns around 35% of the overall revenues of the company, and earns 35 million dollars, it is of critical importance to the company. The company CEO would want to be involved in major decisions taken during the development process of the product, and one of the most critical decisions that needs to be taken is to decide the feature set for the version 5 of the software product.
Now, the software team has had issues in the past with changing customer / market requirements during the course of the development cycle and wants to ensure that they have a process whereby they can incorporate frequent (or even infrequent, but market driven) changes into the development cycle, and make the changes they need. Using Waterfall in a previous cycle did not provide the flexibility that was required to incorporate such changes. The team had heard of processes such as Scrum, which meant that the team could handle changing market requirements on a monthly basis. And so, after some presentations and some training, the team decided to move onto using Scrum as the process.
However, once the team decided to move onto Scrum, and adopted a process whereby feature definition and estimation would happen at a monthly level (with the Sprint cycle being set to happen every month), they were faced with a new problem. Like at the start of the work on a new version, the product team had to present a list of the features that were planned for Version 5, along with competitor analysis, market situation, and earnings projection. The other stuff was fine, but it was the feature list that was a problem. To come up with an accurate analysis of the feature list that could be done in the current version, the team would need to do the following:
- Define a prioritized list of features from Product Management
- Do some brief amount of review of these features at the start of the cycle, with engineering working with Product Management and User Interface team
- Do the estimation of the work right at the beginning of the version work (rather than at the start of the every Sprint cycle)
All these steps are necessary to ensure that the team is able to present a list of features that seem realistic for the current version. This effort needs to be accurate, since the list of features would need to be blessed by Product Management and any deviations from the list during the actual development cycle would need to be justified, including to the CEO if necessary.

Scrum tools for Planning Poker – task breakdown and estimation

ashish — Wed, 24 Feb 2010 18:44:47 +0000

Planning Poker is an important part of the process of breaking down of the features as a part of Scrum. In 2 previous posts (brief description of Planning Poker, and More details of the Planning Poker process), I had explained the Planning Poker to some degree. However, I had not detailed any tools that could help in the process of Planning Poker, so here goes:
1. Planning Poker (site link). Estimates derived from Planning Poker are more accurate because of the emphasis on lively discussion and the fact that estimators are called upon by their peers to justify their estimates — factors proven to increase accuracy. Finally, Planning Poker provides a true average of individual estimates, which has been shows to lead to better results. Free.
2. Planning Poker Cards (link).
3. ScrumDesk (link). A comprehensive tool that also does Planning Poker. Pricing at this link.
3. IceScrum (link). A free tool.

And of course, if there are more tools that you use and find useful, do let me know via comments. Thanks, and please contribute.