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.
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.
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).
There is always a dichotomy between theory and practice (or is there for most teams). One of the prime examples that I have seen in several Scrum teams is about this concept of the end product of each Sprint cycle fitting a term called being ‘potentially shippable’. During the training, and the literature, and articles all mention that at the end of each Sprint, the concept should be that you could pick up the product that has been completed, and ship it to the customer. Whoa, I can hear some scream. How can that be ? We would finally be ready to ship at the correct time of the schedule, not before. We know that we all discuss the concept of the product being apparently ready to ship at the end of a Sprint cycle, but that just means that the quality should be good; we cannot ship it as of that time. And there can be plenty of arguments given for these which seem sound – only part of the design has been completed, some important customer features not yet complete, there are still many critical defects present in the application, and so on.
So, I spoke on this to some Scrum experts, and they are unanimous on this. The concept is what you need to attain – at the end of every Sprint cycle, you should be able to take the product and ship it to your customer. As to some of the objections:
– If your product still has important defects in it at the end of the Sprint cycle, obviously the feature so included is not ready to ship, and should be dropped from the Sprint cycle and taken forward for the next Sprint
– If there is a need to ship this product to the customer ahead of the desired ship date, then obviously, it would mean that there would have been a discussion with the customer that some features would not make it, that the design so done in the less than expected time would not be complete. If the customer has an emergency, you better be ready with the product (in a specific case, the customer urgently needed the product to show to some investors who were losing patience, and the product delivery at 1/3rd of the expected schedule time (with no critical defects, but with not all the features present) did a lot to reassure the investors of the client).
– Features need to be included in Sprint cycles based on their importance, so as time progresses, the remaining features are the less important ones. If some of the more important features have been left pending while other no so important features have been incorporated, there is some problem with the prioritization of the features and the team should look at that. There may be legitimate reasons in terms of priority and order in which features can be implemented, but reviewing the process is something that should be carried out at periodic intervals.
– If your customers know that you have implemented Scrum and ask you for the product at the end of the Sprint cycle, you should not be ashamed of the product you are going to deliver to them.
Once the team gets into the habit of ensuring that the product is ship ready at the end of every Sprint Cycle, it will not be a problem and may help in streamlining of the entire process.