Learn Software Development » Change

Scrum – Provides you a good quick feedback on accuracy of estimates for tasks ..

ashish — Sat, 10 Dec 2011 21:24:28 +0000

One of the major dependencies for a successful project schedule is in terms of the accuracy of estimates versus the reality. In short, you want to measure the difference between the time estimate for a project (or a task inside the project), and the actual effort needed. For such a measurement, you would want to ensure that variables such as changes in feature specs or design between the estimate and the actual execution are eliminated; if your design changes between the initial estimate and when you sat down to do it, then it is very difficult to make such a measurement, or to learn something from such a measurement.
Consider the following example; a colleague of mine used to review the actual time spent on a task, and then compare it with the estimate for the same. He used to do this for multiple tasks, and where the variables (such as requirement changes, or design changes, etc) did not change too much during the time period, he would slowly start to learn which person tended to do the task earlier than the estimates given by the same person, and also the reverse. The next time he would ask these people for an estimate, he would accordingly make the relevant changes in the estimate he got, and then use the modified estimate for the final planning.
Scrum makes this review even more easier. In Scrum task tracking, the team is supposed to provide an update every day on what has been done, and which tasks will take up more time than initially planned. As a result, and especially because tasks tend to be defined in terms of hours and a few days rather than 5+ days, it becomes immediately clear as to which tasks are getting delayed. So, when you are using Scrum in your team, you will immediately start to see the variance between estimates and actual figures. Now, the development team may think that you are trying to find fault, but getting the estimates to be as close to actual figures is very important. This helps you better estimate the deliveries at the end of the Sprint, and prep the customer / product owner about what all is going to be delivered for which you want feedback. This also helps stakeholders get more confidence in the work done by the team.
Being able to see variance could also help you to figure out more research into why the estimates are getting varied; is it because the details provided by the Product Owner are not detailed enough to generate the right estimates, or is it because there are some design issues that cause more effort than people estimate. Make sure that this investigation is done.

The Elements of Scrum

The One-Page Project Manager: Communicate and Manage Any Project With a Single Sheet of Paper

Practical Software Metrics for Project Management and Process Improvement

Problem – When stakeholders disrupt the prioritized feature list of items for a Scrum team

ashish — Wed, 09 Nov 2011 19:14:50 +0000

When you start working out some of the basic assumptions of how a Scrum team is supposed to work, one of the base assumptions is that the Product Owner sets the priorities of all the features / User Stories for a Sprint. Now, depending upon business needs, this order can even be changed midway during the Sprint (should be avoided in most cases is what most of the literature says) if there are pressing needs to change the priorities. This can also be done by ending the current Sprint at the point where the decision to change the Sprint Backlog is made, and starting a new Sprint (which can be set to end at the same time as the previous length of the Sprint).
However, this becomes a problem in the case of service teams. Consider a team that prepares some kind of infrastructural work for other teams; in this case, the User Stories are derived from the needs of other teams, but controlled by a Product Manager who decides the priority for the requests coming in from other teams. This can be quite problematic, since other teams all have their own priorities, and the Product Owner can have a difficult time just trying to balance the requirements of the other teams. If the team is lucky, the requirements of the other teams can be somewhat similar, which makes the work of the Product Owner easier.
I have also see a case where the Product Owner had a really tough time, having to fend off a number of pushes from the different stakeholders that impact the work. So, the Product Owner decides the User Stories based on some inputs, and sets the Sprint Backlog for the defined interval. The team starts work.
And then the pressure starts. Another team suddenly finds that their external environment has changed, and decide that they need something fairly quickly from the infrastructure team. The team finds that the external stakeholders are applying additional pressure and the pressure in this case can rise to such an extent that the team is forced to change their User Stories midway during the Sprint. Once in a while, a team can endure this and understand this, but if this pressure and change in Sprint features keeps on happening, the team starts questioning their implementation of Scrum and will suffer reduced morale. However, it is not realistic to assume that the Product Owner can easily overcome the external stakeholder pressure.
I do not have a good solution to this one, and did not have one when the ScrumMaster of the team asked for opinions.

What to do when priority of your requirements changes in the middle of the cycle ?

ashish — Thu, 13 Oct 2011 18:15:53 +0000

One of the questions that I saw recently coming up during a recent discussion was about what happens when you need to change your requirements during the middle of a Sprint cycle. This was a team that had set Sprint cycles of 30 days duration, and normally never had an issue with any modifications required during the Sprint cycle.
Typically, the Product Owner would define the list of features that are needed, puts them into a priority (and this would include infrastructural and design tasks that are stated by the team as well), and these are entered into the Product Backlog. Then, in the planning meetings, the team would work through the prioritized items, estimate the features and tasks that are likely for the current Sprint, and come to an agreement of which are the tasks that would make it for the current Sprint. Then it is a question of tracking the tasks through the Daily Scrum meetings and taking it through till the end of the current Sprint.
The twist in the tale comes if you need to modify the items in the Sprint. For example, suppose you have a list of items ready to proceed with and midway through the Sprint, the customer comes back and states that a very important feature has suddenly cropped up (needed for some business purposes), and hence it needs to be done for the Sprint. Now, this very question was asked by a team member when a situation arose where we needed to make such a change. Given that Scrum training can depend on the person giving the training, one of the people providing the training told the team that it is possible to modify the list of features during a Sprint cycle, as long as the Product Owner provides an updated prioritization of items. So, the list of features to be done in the Sprint could be different from what was initially decided.
However, this seemed a bit odd, since all the material that I had read till now seems to indicate that once a Sprint is started, you should not modify the list of features. It is also not easy, since any change has a significant impact on the ongoing Sprint, you have not given the team a chance to do an estimation of the changes. What is more likely (as I found from many articles on the subject) was that if the matter is so urgent, then the current Sprint should be curtailed as it is. A new Sprint should be setup where the new priority of features should be setup, estimated, and if necessary, the duration of the Sprint should be curtailed so that it matches the desired delivery date of the features. However, all this will have an impact on the productivity of the team, but if the importance of the required feature is so high, then this change will need to happen.

Has Scrum just become a buzzword, and not implemented with seriousness ?

ashish — Wed, 07 Sep 2011 17:56:07 +0000

A difficult question to answer in a complete way. There is no doubt that there were a lot of initial adopters who looked at their current processes, were not satisfied with the way things were going, or with the predictability of their processes, and were impressed by what they saw in Scrum. Many of these people were passionate about learning about Scrum, and being serious about the changes that were required, and hence were able to make about dramatic changes in their effectiveness. Failures were also there, but even the failures that came in were something that people learned from, and these in turn helped people to make it a success the second time around. Such people are the real experts that you find in the field of Scrum.
What do you have now ? Now, Scrum is seen as something that people see as a buzzword (I have personally known people who heard that there was something called Scrum, who felt that their existing processes may be tweaked to make their teams even more productive, and who decided that they would go towards making their team adopt Scrum). There was no study about what was wrong with their processes, about whether they really needed a change, and so on. Many of these teams then go through Scrum training, and some of the team members were not even convinced that a change is needed (the most predictable reaction is that somebody in management has learnt a new buzzword); as a result, the team is not fully behind the change, and when the responsibility for the work comes on the team members, their is a much higher risk that the team’s effort to implement Scrum will not work (or even worse, the team will implement Scrum, but not with full spirit, and not see any major improvement in the productivity of the team). This retards the progress of Scrum in the organization as a whole.

Some of the properties to look for in a Scrum coach – Part 4

ashish — Thu, 11 Aug 2011 14:51:26 +0000

In this series of posts (previous post – Selecting a Scrum Coach – Part 3), I am giving my views on what should be some of the reasons as to why a specific Scrum coach should be selected. In this post, I will continue with a couple more points on this same topic:
- The Scrum coach you select should be the type of person who does not really beat around the bush too much, or who does not get to the point in a long roundabout way. You know the kind of person. This is a person who knows what he is talking about, but takes forever to come to the point (it could be something as simple as the person starting off in a specific case by talking about where all they have seen a similar situation, what they did about it, and so on). You need somebody who presents their experience to the Scrum team so as to inspire confidence, but when this confidence has been gained, the Scrum coach should be able to take a minimum set of steps / time to get to the desired result. Software people tend to get impatient a bit fast, and when there is a frustration over an ongoing issue which is affecting their productivity, you can quickly lose people (and their attention) if you do not get to the point quickly.
This is true even if you hire a Scrum coach based on recommendations, and based on an interview, but then find that the person fits the above negative pattern. You will quickly start to get hints from your team when something like this is happening; rolled or raised eyebrows when the Scrum coach gets into another long-winded explanation, or team members coming to you and expressing some sort of dis-satisfaction with the Scrum coach should be able to quickly get you into a mode where you would like to ensure that somebody is looking at how the Scrum coach is operating, and then decide whether the Scrum coach is suitable for you or not. Even if you have already hired the Scrum coach but the team is just not able to jell well with the Scrum coach, you should review your decision about the Scrum coach and evaluate whether a different Scrum coach needs to be hired.
- Ask the Scrum coach to explain some of their recent experience and how they are able to make a difference. You will once in a while get people who seem good, but are not able to explain how they would operate, how they would judge where the team is in terms of their Scrum implementation, and how they would make a difference. If such is the case, even if the credentials of the Scrum coach are good, you need to be careful since you would expect a Scrum coach of such experience to be able to outline how they would make a difference, what are some typical issues that they normally see, what are the areas that they really work at, and so on.