Learn Software Development » Uncategorized

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

ashish — Mon, 23 Jan 2012 19:14:41 +0000

This is a series of posts that I am writing about the dynamics of a team, and how it came to be that we started getting push back from the team about pushing them too hard, which lead to a series of introspective discussions (Pushing the team too hard) about whether we had gone too far, and what should be the next steps. In the previous post, I started writing about how the team was being pushed to be more aggressive, and this in turn was causing additional risk to projects that the team was taking up.
In this post, I will be talking about the problems that an aggressive manager was inadvertently causing to the team. Morale of the people involved is a big deal for teams that are supposed to be highly productive, and the organization needs to continue doing efforts that would make sure nothing is happening that would reduce the morale of team members. However, this can get problematic when you have a manager who can put a lot of pressure on team members to the extent that this would reduce morale and make them feel down and out.
As part of the efforts to improve the productivity of the team and make it a top performing team, the organization brought in a new manager who was reputed to turn around teams. The manager was a high energy person, and you could see that fairly fast into his introduction into the role. He would monitor implementation of projects, directly moving among the team members and had a good idea about team members who were effectively shirking work. This tactic worked pretty effectively, since it also encouraged the various team managers to monitor the performance of their team to a greater extent and ensure that anybody shirking or not working as much as required was spoken to and provided feedback.
However, there is a fine transition between being aggressive and starting to cause frustration in the team members. When people believe that they are working at a good pace and feel proud of what they have accomplished, they seek to hear good words; but when you have a person who can be aggressive, it can turn out pretty good in terms of driving the team (but this happens when the team members believe that the overall manager is actually a great driver and visionary and then neglect or ignore his hard driving efforts). However, if the team members start to feel that the manager is actually not appreciative of their work when they have put in some great effort, it can be very bad for morale.
In our case, this is what was starting to happen. The manager would push people to get work done fast, and for some time, those team members who liked doing great work were very impressed. However, when they could see that the manager was all about push, and more push, and it was hard to actually hear some words of praise from the manager, there started a wave of people expressing issues or feeling hurt after the interaction with the boss. What made it worse was that the team members would share their own stories, and this made the issue of morale even more difficult; and of course, since the team was performing at a high level, the manager was seen as a success story.
However, after this much analysis, and after the HR Department also got involved, the management prepared an exit path for the manager and decided to bring in another manager who was passionate, but who had also got a reputation for appreciating good work.

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

Why does the Scrum Velocity of a team differ from its Capacity ?

ashish — Sun, 17 Oct 2010 18:41:12 +0000

In the previous post (Sprint Capacity vs. Sprint velocity), we had tried to explain the difference between Scrum Capacity and Scrum Velocity, and even though they should theoretically be same, there are any number of reasons why they can be different and should be measured separately. In this post, we will go into more reasons as to why they are different. A lot of the reasons have to do with problems in not completing the list of tasks estimated for the Sprint, and which in turn impacts the Velocity, but there are other reasons:
1. Assumptions made during the Sprint Capacity estimation are not realistic. I know one team that took a simple calculation: Number of hours (8 per day) X Number of Days per Week (5) X Number of people available. And then they were surprised when they were off; obviously, they had not hired well, they should have got some code writing robots instead of real people. In real life, it is impossible to find people who would be productive for 8 hours a day, who would not report sick on some days, or go off on a vacation.
2. The estimations made during the task planning meeting are not correct. This can happen when the tasks are not clear, or the design work for the task is such that it is very difficult to estimate correctly (which can happen in many cases). This can also happen when the team is trying to be aggressive in terms of completing work in a given Sprint Cycle (maybe under pressure of deadlines).
3. When there are new people in the team, who typically take some time to work through the accuracy of their estimates. This can also happen if the team has recently converted to using the Scrum based methodology, and takes some time be accurate (we can also call this as the team working through their kinks)
4. When the team has not managed to complete through some tasks (with some work pending for the tasks), some of the tasks are carried through to the next Sprint. In such cases, the Sprint Points for such tasks are not calculated as part of the current Sprint and hence the velocity for the current Sprint will show a reduction in the amount of Sprint points that are calculated for the current Sprint.
5. There can be cases when the Scrum team consists of Developers and Testers, and where these 2 roles are different. Consider a case when the QE team can only test tasks once they have been delivered by the Dev team, and as a result, there are days when the QE members of the team do not have any tests, and this results in the team velocity being lower in the end.

In the next post, I will talk more about this topic.

How is the role of a Project Manager different from the role of Scrum Master

ashish — Sat, 09 Oct 2010 20:23:37 +0000

For teams that move from a other development methodology (such as Waterfall, Iterative, etc), the transition to moving to a Scrum based method comes with its own challenges, with one of the main challenges being the transition of roles. In the classical development methodology, the Project Manager is the person who runs the project, looking to ensure that the team is working towards its goals, and that the objectives of ensuring that the desired set of features is done (scope of the project as initially defined, is completed), within the defined cost allowed for the project, and within the desired schedule. So what happens when the team moves over to Scrum as a development methodology, and the team now has to select a ScrumMaster. The most immediate temptation is that the Project Manager takes over as the ScrumMaster; after all, this will allow the Project Manager to still drive the progress of the project and determine on a daily basis, the status of what is happening in the project.
This sounds right, but although there is no stipulation that the Project Manager cannot be the ScrumMaster, I am going to stick my neck out and recommend that the Project Manager should not be the Scrum Master, instead somebody from the team should be handling the role of the Scrum Master. Here are some differences between the role of the Scrum Master and the Project Manager:
- In Scrum, part of the role of project management (Project scheduling and tasks estimation) is distributed across the team members, with the Scrum Master there to ensure that progress is happening; this is in comparison to that of classical project management where the Project Manager is the main driver
- The Scrum meeting is not a way for the Project Manager to generate status of what is happening, it is primarily meant for the team to understand the progress that each of them is making
- The Scrum Master has a major task in terms of removing impediments that the team faces in getting their daily tasks done; something that the Project Manager would not have done at that granular level
- One of the key roles of a Scrum Master is to ensure that the team is following the Scrum principles and practices, while the classical Project Manager would have been more concerned about the schedule tracking
- The role of a Scrum Master is more of a facilitator, working with the various team members; the classical Project Manager role is more that of a driver who sets targets and others follow
- A Project Manager who has not got into the Scrum kind of way and becomes a Scrum Master is more likely to be an impediment to the team being a self-organizing responsible team, since the Scrum Master is more likely to want to lead the team and define next steps as well as targets
- The Scrum Master does not inherit the organizational roles of the Project Manager such as building the team, providing career feedback, etc; there needs to be somebody who can do this, and if the Project Manager / Scrum Master does this role as well, it makes the role of accepting the Scrum Master as a team member more difficult (you really don’t want a leader type of personality becoming a Scrum Master and seeking to rise above the team).

More information about the Product Backlog

ashish — Wed, 16 Dec 2009 20:13:44 +0000

To me, it seems like I have written several posts about the Product Backlog, but it is also true that the Product Backlog is a very important part of Scrum, and it is necessary to make sure that people understand all the details regarding what all Product Backlog is, how it is updated, when, who, and so on.
So, how is the Product Backlog used ? Well, given that the Product Backlog is supposed to be the repository of all the feature requirements and is owned by the Product Owner, it is one of the most important documents during the Sprint planning sessions. During the Sprint Planning meetings, the expected process is that the Product Owner attends the meeting accompanied by the Product Backlog, where the feature list is prioritized. The team then reviews the list, and decides the top items that they can accomplish by the end of the Sprint (and for a new item, this estimate of what they can accomplish can take some time to fine-tune; it is very much possible that the team initially could commit to too much, or too little).
In some cases, items need to get added on the Backlog through inputs from the engineering team, and these are typically architectural or design items that the Product Owner may not know about, or will have little idea; but they do need to get done, so they get added to the Product Backlog. In most cases, the prioritized items are selected, but there is some laxity if it turns out that some of the lower priority items are needed early for design purposes.

Learning about Scrum from free videos available on YouTube

ashish — Fri, 06 Nov 2009 16:53:17 +0000

Scrum is a project development methodology that is vastly different from previo us such development methodologies. It requires teams to change the way they do their processes, it requires management to understand what the process is all about, why it is different and how they have to let teams empower themselves and let them run with the process. Further, the concept of a self-energized team that runs the show and reports progress on a periodic interval (separate from the daily Scrum discussion) can be very different from the detailed status reports of Waterfall or modified Waterfall (it is technically not right to compare Waterfall and Scrum, but enough people do this, and it is accepted as a comparison).
For Scrum, it is essential that all the stakeholders (called pigs and chickens – where the pigs are the ones with a direct involvement in the day to day work, while chickens are other stakeholders such as management and customers) get some level of training. However, another important way to make more people aware that this is a great process that can work wonders for some types or projects is to see what other teams are doing, as well as to review some of the videos available on Youtube on scrum (it is free training in some self).

SCRUM in Under 10 Minutes (HD) by @hamids

Scrum Basics

Agile vs. Waterfall: A Tale of Two Teams

Scrum Masters 2 (funny)