Learn Software Development » Process

Not pushing the team too hard – a fine balance that can be easy to miss – Part 2 ..

ashish — Tue, 17 Jan 2012 15:34:14 +0000

The previous post (Pushing the team, maybe too hard) detailed some of the problems that a team that was under-performing started experiencing when it decided that it would not longer under-perform and started to move up the performance chain, but in the end, the focus on productivity started taking a toll on the team members. There were a number of factors that were not considered when it started becoming a bit more clear that the team was getting fatigued.
One of the biggest factors that we had to re-consider was the notion that we would not say no to a request or a project without doing a lot of deliberation, and if there was a chance, then we would be aggressive and push for doing the project. This worked beautifully for a while, since earlier we would be conservative, and when we would do a resource and risk assessment, if there was a chance of some risk (around 20-30%), we would say no to the project. This was giving the group the title as a No saying group. So, we worked hard at this aspect. Over a period of time, when a project was proposed and we were evaluating the project, we would do a calculation of the risk, but we would also do a strong focus on seeing whether the risks could be mitigated. So, when there were risks, senior members of the team which was doing the evaluation would be encouraged to take a look at the risks, and see whether there were steps that could be taken to manage these risks, and even if this required extra effort, it would be worthwhile to take the extra effort and get these things done. In addition, an incentive was given to the team, in terms of promises of higher rewards for higher productivity, and with differentiation between team members based on the effort that they would undertake (and this was a big deal in terms of encouraging people – if many team members felt that extra effort was being recognized, you had several of them putting in an hour or two of extra effort on a daily basis in order to show that they were capable of doing more effort).
Well, all this had the desired effort. This factor about being more aggressive had an important effect on the reputation of the team, and we were being known as the team that could get work done that seemed more difficult for the other teams. But, at the same time, there was a risk in terms of what we were doing. Since we were taking more chances on the risk front, we were pushing the envelope, and this did hit us in a couple of occasions where we ended up taking last minute risks with the project, and in one case, had to get people from other groups, else the project was a goner. These cases did cause some amount of re-thinking, but not a drastic change in policy, and we continued on. So, what were some of the pointers to the fact that we were heading towards a case where we were trying to chew more than we could do ? Well, for one, we had people from other teams and from senior management asking the team management whether we knew our limits / constraints, and was our risk calculations on the right side of sanity ? These queries were coming up more recently, and these also started a re-think on the level of aggressiveness we were following.

Continued in the next part …

Outswim the Sharks: How to Quadruple Your Team’s Productivity with Kindness	How to Unleash the Collaborative Genius of Teams for Increased Engagement, Productivity, and Results	Visual Meetings: How Graphics, Sticky Notes and Idea Mapping Can Transform Group Productivity

How to define tasks for a User Story without spending a fair amount of time on these ?

ashish — Sun, 30 Oct 2011 18:56:46 +0000

We seem to find ourselves running into a fundamental problem during out Sprint planning meetings. Some of it is from our older methods, but partially it also seems to be a problem with the way we are using our Scrum processes. Consider the process before getting into Scrum. We would have a list of features defined and agreed upon by the Engineering and Product Management teams to be done in the defined product development time cycle. However, things were problematic when actually getting into the actual stage of working out the tasks for these features. Many of these features involved features that were not done before, and so it was required that these features be broken down into tasks, and the team leads were assigned to this purpose. It would take a matter of some time for the features to be actually broken down into a matter of tasks. The feature team would need to have a few meetings to discuss the feature, talk to the User Design specialist to understand the way that the feature would work, and then work out the tasks.
However, it would take more time to work out the estimates for the task, and in many cases, this was a matter of guesswork, since the work required for the tasks had never been done before; getting these estimates involved some amount of discussion. And once these estimates were in place, when the actual work was happening, these estimates did change many times (sometimes the User Design was different from the one initially considered, and in many cases, the estimates were actually different from the work that was needed to be done to complete the task). This meant that the total effort needed to complete a feature was different from the estimates; and this happened for many of the features.
Now, when we started using the Scrum process, this became an open question. For many of the major User Stories that were a translation of the major features, getting tasks broken down into the User Stories was a major effort by itself, and it was postulated by the team that earlier it would take so much time to break down the features into tasks, how would it be possible to do this during the Sprint Planning process ? It was somewhat difficult to answer this question, although we did some amount of planning on how to define User Stories in such a manner that they would be readily understandable and could be broken down into discrete tasks that could be estimated with some amount of accuracy. This took some time to actually happen, and there were many cases where the effort estimation did not match the actual effort needed for the tasks.

When executive apply pressure on the Scrum team to get a required number of features in

ashish — Wed, 15 Jun 2011 04:17:08 +0000

When a team is following Scrum, it means that the team decides the estimates, the number of features that are to be done per cycle (Sprint). The priority of features is as per the Product Owner, and it is the responsibility of the Product Owner to ensure that all the stakeholders are kept in the loop for which features are making it when; it should not be that the executives or senior management see the list of features being done and wonder why more important features are not being implemented early. Even if there are design considerations because of which a feature makes it into the product later, the executive or senior manager should talk to the Product Owner and not try asking the team such questions.
However, this is only one of the problems that a senior manager can do to a Scrum team. The biggest problem is when the manager makes it a habit to be part of the Daily Scrum meeting and starts showing their own priority for the number of features to be done, and the order in which the features need to be done. Typically, in Scrum, the manager may not know how the team works, or in the initial couple of Sprints, may not get a feeling that the team is doing as many features in each Sprint as possible and start pushing for more work. This is even more so when the manager has a technical bent of mind (or things that they are good technically, but is actually not); in which case, it can be seen multiple times that the manager will actually question the estimates being given by the team member or the amount of time it is being taken to actually implement the various tasks (when the team member is talking about progress in the Daily Scrum).
This kind of discussion in the Daily Scrum is not good, not for the project and not for the team members. There may be multiple reasons why the task is taking the required amount of time, or the manager / executive may not really know details of the task and is just pushing for getting features done faster. Team members may also hesitate to reply back with more details if they see that the manager is focused on getting more features done, and is not really listening to them. In addition, this leads to a reduction in morale since team members see that all this talk of an empowered team under Scrum is bunkum, not backed up by action, and as a result, feel that they are back in the Waterfall mode. They will also revert back to their normal mode whereby they just take action based on directions given to them.
In such cases, it is required that the executive / manager be given the confidence that the team will deliver, and with a high level of quality; and that the manager is not expected to get into the details of the daily task execution.

Scrum Product Owner – Clear vision vs. evolving thought and adaptability

ashish — Mon, 21 Feb 2011 04:17:39 +0000

Scrum has been setup based on some principles that seek to map how modern software projects actually are, with the biggest basic principle being the fact that business requirements keep on changing. Hence, if there is a methodology that requires you to lock all your business requirements at the beginning of the cycle, and makes it difficult (or near impossible) to change those requirements later, then it was time to evaluate how to move to a more dynamic methodology that could adapt to changing requirements; Scrum fits that definition to a much higher degree. So, Scrum mandates that requirements should be frozen only for short periods at a time, which is through the system of having defined intervals such as Sprints, where the Product Owner works to define the requirements for each Sprint, before the Sprint; explaining the requirements in the form of User Stories to the team, and evaluating the performance at the end of each Sprint. This allows starting the project, and defining the priorities of the building blocks for the project as we move ahead, building them one Sprint after another. Another advantage is that, if during the course of the project, it is found that there is changes in customer preferences or in the competitive landscape, the team can make the quick changes to handle these changes.
However, there is an increased pressure on the Product Owner due to all these changes. The Product Owner has to handle all these requirements in an appropriate priority, responding to external changes, while ensuring that the team does not feel puzzled. Also, when building some complicated design, there needs to be a plan to ensure that the basic required building blocks are built step by step in the various Sprints. Towards this purpose, the Product Owner needs to have complete clarity on what he / she wants to achieve in the project, as well as how to go about doing it. There needs to a Vision about what to build, and this Vision should be such that it can incorporate these changes in the requirements over the course of the project. I have seen Product Owners who work Sprint by Sprint, and in the end, things start to go haywire. Items that are required are not there, or the integration between different items start to fail.
The team also needs to have this Vision clarity in their head, and they will not get it until it has been imparted to them (explained in a way that makes sense) by the Product Owner. It is only when they have this overall vision that they will be able to see how the different requirements that they are implementing add up together into the desired project.

How does the Scrum team decrease the difference between Capacity and Velocity ?

ashish — Sat, 23 Oct 2010 17:12:33 +0000

In the previous post (Scrum team – Difference between Capacity and Velocity), I had talked about some of the reasons as to why the capacity of a scrum team is different from that of its velocity. In this post, I will try to explain how we can bridge this difference. Most teams do not see a case where the Velocity of the team is greater than its capacity; the problem that they typically try to solve is the case where the Velocity of the Scrum team is less than the Capacity of the Scrum team (and this becomes a significant problem when the team delivers far less than the amount of features promised at the beginning of the Sprint). So, in this post, we will try and work out some ways that the team can learn from their Sprint efforts and improve their Velocity.
- The first major factor is to ensure that the team does a retrospective at the end of every Sprint, and does it with full effort and with a desire to learn what went right and what went wrong. Which also means that the atmosphere in the team should be such that people should be able to talk about what went right and wrong in an open setting.
- Should be able to re-visit various criteria and other process through the various cycles based on feedback. Part of the emphasis on Scrum is being able to incorporate changes in requirements and other such factors; but changing processes based on feedback is much more difficult. As an example, suppose the team works out that the criteria used to judge whether a task is done needs to change, then there should be an ability to incorporate such changes in processes.
- In some cases, when a team is getting into Scrum for the first time, external stakeholders may be worried about the ability of a team to deliver, and would be measuring the output of the first Sprint. Further, the team would also be watching the Velocity at the end of the first Sprint, so it becomes even more important that the First Sprint be planned much more thoroughly to ensure that the Velocity of the First Sprint is much closer to the capacity, and the desired set of features are delivered.
- During the course of the planning, the team should sufficiently feel ownership of the processes. Teams that are successful leverage the experience of their experienced personnel, such as refining the criteria of Done, design processes, requirements, task estimating, source control; and can lead to a much higher level of efficiency. It is important that such an exercise be done to discuss processes, get improvements from the team members, and be on the lookout to even modify these if required. Such efficiencies leads to an increase in Velocity.
- Calculating metrics for time capturing and other such metrics helps in the calculating of Velocity, but this data by itself does not give the true reasoning for the impact on Velocity. It is important that when any event happens that can impact the development (and effect the Velocity), the team members capture such events and these are discussed during the Sprint retrospective. One should not jump to conclusions based on data driven Velocity, but do a more thorough discussion on the reasons that led to the feature not being done.