Scrum Process | Scrum Problems | Scrum Detail | Scrum Challenges

October 2015
« Aug    

One expert in the Scrum team – Part 2

This is a continuation of the Part 1 of this article (Expert in the Scrum team – Part 1); the topic of this series of articles is interesting and different from some of the other articles that have appeared here. When you have such a skilled expert within the team that he / she tends to over-awe every other member of the team, and this can lead to some problems in terms of stifling the enterprise and initiative of the rest of the team members. The previous post went through some of the problems that this can lead to, as well making such a person as the singular leader of the team to the detriment of the other team members.
In this post, one shall take the problem and try to resolve it in another way. One way is to talk to the person and explain the entire situation, and the problems that this can cause to the rest of the team. This may be surprising for the person or the rest of the team, since they would look at the positive aspects of the support provided by the expert, and trying to look at the problems in terms of reduced initiative by the rest of the team is not something that would be easily apparent to the team. These kind of problems are more easily discerned by somebody external to the team who can look at how the team operates, its dynamics, and look at some of the problems present in the team.
Speaking to the expert on this topic can be a difficult tactic. Many people cannot understand something like this so easily, since such a discussion would entail their attaching some amount of negative results to their work; and it would take a sensitive discussion with the expert to make them understand such a problem. However, using the amount of tact for this discussion depends on situation to situation, but the net result needs to be that the discussion of this problem needs to happen with the expert, and explanation given about how this kind of hand-holding for the rest of the team stifles their initiative, and they would not even make the errors that would happen naturally; this in turn reduces the amount of learning for the rest of the team. If all goes well, the expert would have understand the problems and the needs this places on his/her operations.
How this would work is something that again needs to vary from team dynamics to team dynamics; but the net operation is that the expert would push back against team members coming to verify something, and would push them more and more to explore problems by themselves and do some kind of initial design before coming to the expert for help. Such an approach would help to ensure that the team would also get the message and start to act more and more like an empowered Scrum team rather than going to the expert for guidance. They might make some errors during this course of action, but lessons are learned through errors (just as those are not massive errors).

One expert in the Scrum team – Part 1

You all know the situation. There is one person who sits above everybody else, and this could be a Scrum team or any other team. Everybody knows that this is the go to guy (and he or she could be for real, not somebody who thinks they are above but are just at the same level as the others), and does this lead you to an awkward position in the team? Well, yes. It can lead to an awkward position within the team. Here is this person who has apparently all the answers, or the team is so awed by this person that they don’t really take too much initiative. You might have seen this before – the team wants major technical problems (and proposed solutions) ratified by this person, they look at this person for estimates, and so on. You might think that it is good for a person to be there in the team who has such experience, but there is a price to be paid for such a beneficial act, and it can be a pretty bad problem for the team.
What problem ? Well, such a person within the team, even if the person himself / herself does not try to dominate, leads to a position within the team where nobody else wants to take initiatives. You have a situation where you have a prima donna within the team, and the rest of the team suffers in comparison. Trying to get team members to take the initiative on their own, based on their own abilities (without referring to the expert) is difficult to achieve. And for a Scrum team, it gets even more difficult. You have the concept of a Scrum team, where the team is expected to take authority and make a number of decisions on their own, and here you have a team that wants to take steps only after referring to their inhouse expert.
Another problem with having an experienced expert within the team is the problem of management and others outside the team looking to this expert to get reassurance about the project. So, from time to time, what would happen is that management would meet this expert in hallway discussions, or in the canteen, or some other common location and get into a discussion with the person about the current status of the project. This undercuts the role of the Scrum Master or the Product Owner, who would normally do any project status discussion with management; but who might find that when they talk to management, they already have some knowledge of the status and maybe some notions about the status of the project. This might be minor, but can get irritating, and saps the energy of the Scrum Master or the Product Owner.
In the next post, we will talk about what can be done in this kind of situation. It is not easy to explain the problems since most people would consider the presence of an expert to be good for the project, and pointing out such problems is not likely to lead to any positive solution.

Spending time planning in current Sprint for the next Sprint

This is one of those concepts where most experts are in agreement. When a project schedule is divided into multiple Sprints, the work done for a Sprint is typically set in the initial meetings, where the team does task estimation (am not getting into details in this post) for the tasks to be done in the current Sprint, and then the team does actual work during the Sprint, with the Daily Scrum meeting being a place where the progress and work remaining is determined.
However, it is not that each Sprint is totally isolated from the other Sprints, and I hope that nobody gets this assumption. The Sprints essentially cover the entire set of requirements for the entire cycle, and when the Product Owner comes into the Sprint Planning meeting, some work has already happened in terms of refining the User Stories and breaking them down into tasks. Further, the team would have spent some time in working out design of the User Stories and tasks along with the Workflow designer, and also spent some time in doing some technical investigation to determine which of the workflow processes are more feasible technically. Further, the process of Backlog grooming also needs some time to be spent to look at the Product Backlog for future Sprints.
The bigger question that the team needs to decide is the amount of time to be spent in these activities – work which would be essentially for future Sprints. Doing such work is necessary, but takes time away from the work being done in the current Sprint, and hence the team needs to define the amount of time being spent for such activities. Allocating time for such activities ensures that the team can determine whether they are spending too much time, or whether their discussions are getting too detailed where it is not required, and so on. This may be an iterative process, since it may take some time for the refinement of these meetings.
A number of teams that I know of allocate around 10% of their time in a Sprint for meetings, discussions and work related to future Sprints. This would typically not be one meeting, but multiple discussions. These could be in terms of discussions with small sets of the Scrum teams, with the Workflow Designer, with working on the Product Backlog and so on. However, it is necessary that there be a tracking of all these meetings and discussions to ensure that not more than 10% of the total Sprint time is spent on these activities.

Getting infrastructure done in the first couple of Sprints

Just because a project is being done using the Scrum methodology does not mean that some of the regular work that needs to happen in a project will not happen. Whether you do Waterfall or Scrum, or some other Agile methodology, a lot of the initial work for the project will need to happen and needs to be planned as a part of the schedule. There are many such activities that need to happen, whether these are project design related, or infrastructure related. Some of the infrastructure related stuff include:
– Setup the servers needed for development such as the source safe, build servers, and numerous other servers and machines needed during the development process
– Setup the test process, decide the test methodology, and start the process of building up the test infrastructure (test depots, test plan / cases, test automation machines and software)
– Many other processes such as the quality standards, data analysis, etc.

There are 2 main options for all these infrastructure work, and you can guess what these can be. Either you try to build the infrastructure during the first Sprint cycle, or implement the infrastructure as and when required, which means that the work will be done during the next few Sprint cycles. There are pros and cons for both sides.
If you want to build all the infrastructure work during the first Sprint, it will mean that less feature work will be done in the first Sprint. In a number of cases, the Product Owner tolerates all this infrastructure work, but would hope that all this effort would be minimum. The worry of course is that the team will try to over-build on this infrastructure and even build stuff that would not be used. In the case of Scrum, the idea is that one should only build as much as would be needed, not try to build too much infrastructure that may or may not be used (this will help to ensure that effort is spent on building customer facing features and only as much infrastructure and design is done as is needed).
However, the contra point for this is that even with the infrastructure being minimized as much as possible, there would still be the need to build the necessary infrastructure that would be needed. And in some cases, one needs to build the infrastructure to a bit of excess since clarity starts building up as the feature work starts to happen and the discussions start to happen and the actual precise infrastructure requirements can then be frozen.
The team can decide on which process to follow for this building up of infrastructure, but only teams with experience would be able to be more accurate. Teams that are working in this area for the first time will do some building in excess, others will build lesser infrastructure than needed (which will cause its own set of problems and some limitations on the ability to do feature work as well).