Learn Software Development » Issues

What are some of the benefits that a Scrum coach brings to the Scrum team ? – Part 2

ashish — Tue, 19 Jul 2011 18:28:14 +0000

In this post, I will continue from some of the items that I discussed in the previous post (Coach and Scrum team), and continue more points on the benefits that a Scrum Coach brings to the Scrum team. So, here goes:
- When a Scrum team faces issues, the Scrum coach acts like a person with an outside view. Whether it be the Scrum Master, or the managers of the team, they all are very deeply involved with the team and may be able to see the problems in the proper perspective. On the other hand, a Scrum coach is not so deeply involved with the operations of the team, and also has the experience of multiple issues that happen in Scrum teams; these properties give the Scrum coach a unique perspective in being able to solve problems. This kind of expertise makes the Scrum coach an invaluable person to have.
- A Scrum coach is typically not subject to the same organizational structures and hierarchy that people from within the team are, and as a result, the Scrum Coach is also not likely to pull their punches when they see some problems. These can be in terms of organizational issues, interference from stakeholders, wrong policies, and so on. These may be necessary for the problem to get solved, but somebody from within the team may not have the political clout to point out the correct problem and get solutions in place.
- When a team sees that a Scrum coach is in place, it is part of the message to the team that the organization is serious about the implementation of the Scrum methodology, including finding out Scrum issues, and indeed about solving them, no matter where the problems lie (within limitations, since not every problem can be solved easily, some can be organizational issues or other such issues that are much more difficult to solve). When team members see such an environment in place, they are more likely to contribute the ideas and their views of problems that the Scrum team actually faces; this can make a huge difference to the success of the Scrum team – and some part of this can be attributed to the presence of the Scrum coach.
- A Scrum coach is a person whose main function is to learn more about how to make Scrum teams successful, who learns more about issues that can reduce the efficiency of a Scrum team or derail their progress. Having such an expert with a Scrum team greatly increases the chance that the Scrum team will be more successful.

Scrum failure – trying to get a Business Analyst to play the role of a Product Owner

ashish — Sun, 19 Jun 2011 15:34:23 +0000

One of the biggest problems in trying to do Scrum projects is when an existing team is sought to be converted to using Scrum methodology. Consider the case where the team has a Project Manager to run the project, and Business Analysts to convert the requirements into specific documentation that the developer team can use. Now, when the team wants to start doing Scrum, the Project Manager would typically become the Scrum Master (although the roles vary drastically between the Project Manager and the Scrum Master), and the Business Analyst takes on the role of the Product Owner.
However, in a couple of projects, after discussion across the organization, we found that these conversions were not so simple. Taking on the role of the Scrum Master from that of the Project Manager was a challenge of its own. The Project Manager has absolute authority over the project, and over the team members; the Project Manager works with the leads to ensure that work is broken down into different tasks and these tasks are assigned to different team members. Typically, there is a big MS Project sheet that the Project Manager tracks along with the leads and uses that like the Bible for the execution of the project. When the Project Manager starts working on the Scrum methodology as the Scrum Master, there is a perceived huge loss of authority. The tracking of the tasks is done in terms of how much effort is still pending, with many tools not even trying to track how much the project is running over the time limit (this can be very jarring for the Project Manager when they are introduced to Scrum and tracking as part of Scrum). In a couple of cases, I have found that the Project Manager found the change in role so jarring that they decided to change teams and move over to other projects which were not based on Scrum.
The bigger problems was when the Product Owner role was seen as the perfect place for the Business Analysts to do. Now, typically the Business Analysts were expected to take the client requirements and convert these into a form that the Development team can use. Now, the role of the Product Owner in Scrum is a specific role, which requires a certain amount of skills. They have the flexibility to make changes to the priorities of the features, and also to modify the scope of the features of the projects. This is typically not what a Business Analyst does, and it was strange to see the Business Analyst converted into the Product Owner trying to do these part of the roles. The team had got the training, and seen role plays and examples, and expected their Product Owner to work the same way. However, like anybody doing the role for the first time, the first few Sprints was very difficult for the Business Analyst and the required responsibilities were difficult to acquire. The team saw these issues, especially the clear inability to re-scope the work and put some amount of pressure on the Business Analyst. It was also getting realized that this pressure was reducing the credibility of the Product Owner with the team claiming that decisive actions were not being taken. Eventually the concerned Business Analyst made their way off the team, something that we tried to prevent (it is hard to get a person who is readymade for a role – in most cases, you get a person and try to fit them into a role, and it takes some time to be ready).

How does the role of managers change when the team starts implementing Scrum ?

ashish — Thu, 16 Jun 2011 18:29:48 +0000

This is always a tricky question, and one that I have seen emerge in the minds of managers many times. Once a team starts implementing Scrums, one of the biggest issues is about the role of managers, what they are expected to do. I have seen reactions from managers, once they start seeing the task estimation (and Planning Poker), and the Daily Scrum meeting; they start feeling that they lose control over what their team is doing. This is even more critical for them since they are held responsible for the working of the team, for ensuring that the team delivers as per expectations, and they are the ones who are pulled up if the team does not deliver as per expectations.
So, how do you beat such cases ? How do you avoid cases where the managers start feeling that their role is not clear ? Well, one of the biggest items is to get managers to understand the Scrum methodology, make sure that they are comfortable with the changes, with the new role that the team also has. So, it is required that the managers understand what their role would be in terms of the Scrum methodology:
- The managers provide all the infrastructure in terms of machines, software, good working environment, organizational issues, etc. This can be pretty critical since it is important that morale issues be addressed, and morale for a team can be impacted by a number of organizational issues. A manager in other methodologies is expected to handle such issues, and the same remains valid in Scrum.
- Coaches team in Scrum practices. There can be several issues in Scrum, such as people not being able to easily adjust to a daily meeting where they provide an update on what they have done (some people can consider it humiliating, especially when they are unable to complete items that they stated the previous day that they would). In such cases, the manager can provide a lot of support and coach the team members about how to handle such issues, keeping their morale high, and so on.
- Provides support to the Scrum Master. It is typically the manager of the team member who knows the person, knows their strengths and weaknesses. A Scrum Manager would not know the team member to that level; so when a manager goes through the meetings and sees some areas where there are conflicts, or when a team member is not behaving upto expectation, then it is the manager of the team member who can work in the background, working with the Scrum Master and the team member to resolve issues. This can be a very useful role for the manager and lead to a very high level of contribution for the project.
- Providing reviews. Typically, most managers have a high degree of experience in terms of the artifacts of the project such as the design, architecture, etc. The manager can still do reviews of these, and provide feedback to team members that can actually work to benefit the project, and also help the development of the team member.

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.

How does the Scrum team decrease the difference between Capacity and Velocity (contd..) ?

ashish — Fri, 07 Jan 2011 19:33:23 +0000

In the previous post on this topic (geographic distance between the Scrum team members), I talked about some of the problems that are faced by teams that are separate geographically, and how such distances and the issues that are caused by such distances can impact the productivity of the teams. What is needed are steps to ensure that in such situations, the teams are still able to feel connected and the issues due to the distances are minimised.
One approach is to have clearly defined time periods where team members from both teams can interact. This can be in the evening / morning, with some amount of inconvenience, but it is necessary to have such time periods for discussions. One needs to sensitize team members that with such cross-geographical distances, it is necessary that some amount of morning or evening effort would need to be involved. Before the Daily Scrum meeting, or other meetings where issues need to be discussed, team members should have prepared lists of queries and sent those by email prior to the meeting. Further, tools that make for instant communication such as instant messengers, phone messages, chat services (including group chat) should be encouraged since they increase the connectivity between the teams, creating deeper connections, and reducing the surprise element. This goes a long way in reducing any mis-communications between geographically separate teams, and we have seen this working when there have been cases of teams working across geographies.
Another approach is if it is possible to have the teams separated into separate Sprint teams that are co-located, there are a huge amount of advantages. This may require some amount of re-alignment of feature work across the teams – consider the case where team members are slowly added to the project in both geographies, and it is very much possible that feature work may happen across the geographies. In such cases, some amount of re-alignment can ensure that sub-features are done by teams located at the same geography and this will increase the efficiency of the team, leading to an increase of the Velocity of the team.