Preparation is key to reaching your goals.

Successful and efficient planning of any sort represents the confluence of preparing the work to be planned and proper logistics. Earlier in this series on planning, we reviewed the basic logistics needed for a planning event and defined a simple checklist.  While both are important, preparing the work to be planned requires more effort.  Preparing the work for planning requires knowing the capacity of the team and grooming the work items (stories, requirements, support tickets and/or defects). (more…)

Does the raft have a peak load?

Does the raft have a peak load?

Peak load is an engineering concept that has found its way into software development and maintenance conversation.  Peak load is a spike over a specific period of time and not a sustainable level of performance. When applied to a software team, the peak load is how much additional work a team can do for a short period of time. Before we concluded with the admonition; “The idea of pushing a team to a peak load should be used judiciously.” To which Assaf Sternberg asked “Tom, how do you square this away with another thing that differentiates good software engineering from assembly line work – the ability to refactor/reengineer the solution in anticipation of future work to make the latter easier/faster/less risky? Over the long run, this should make it possible for the ‘functional point’ count per sprint to continue to rise (while these items would require less effort)”

Refactoring, also known as code refactoring, is the process changing or restructuring code to be simpler, more effective or more efficient without changing the code’s functional behavior. Refactoring can also be done to make code be more maintainable or extensible. The need to refactor can be inferred from the Agile principles of simplicity and emergent design. Refactoring is an integral part of development in most implementations of Agile.  For example, in test driven development the final step in process is to refactor both the code and design.

In order for refactoring to be effective, it needs to be planned part of work and needs to done in pursuit of an overall goal that can be tested. During sprint planning teams need to identify tasks for refactoring just as they do for other development activities.  Refactoring is just another task that requires time and uses the team’s capacity. When the team plans for refactoring, it is reflected in the team’s velocity and productivity. When a team adopts the technique of refactoring it will initially reduce their functional output, thereby reducing velocity and productivity. But, over the long run, data I have collected as an Agile coach shows that that productivity and velocity increase (about 5% year over year). When productivity goes up more functionality is delivered for less effort. Refactoring is at least partially responsible for this increase.

Refactoring is done to attain a stated goal.  For example, a team recently I worked with focus their refactoring efforts on maintainability (the team had developed standards for maintainability). Given that they had to implement, maintain and enhance the code as a team maintainability improves their overall efficiency (reflected in velocity and productivity changes over time).  The team developed the goal, then agreed on how to pursue the goal and finally agreed how they would know if they were successful.  A goal is important to ensure that team members do not act in an ad hoc manner.

How does or should refactoring impact a team’s a sustainable pace and by extension their peak load? Refactoring does not extend the day, there are same number of hours in your work day. What it does is help the team be more efficient and effective over time. Therefore refactoring increases velocity and productivity.  This is only possible if refactoring is planned as part of the teams normal activity and focused on achieving a goal.

Burn down chart

Burn down chart

I have been asked more than once about what to do with tasks that occur during a sprint that are not directly related to a committed story.  You need to first determine 1) whether the teams commit to the task, and 2) whether it is generally helpful for the team to account for the effort and burn it down.  Tasks can be categorized to help determine whether they affect capacity or need to be planned and managed at the team level.  Tasks that the team commits to performing need to be managed as part of the teams capacity while administrative tasks reduce capacity.

Administrative tasks.  Administrative tasks include vacations (planned), corporate meetings, meetings with human resources managers, non-project related training and others.  Classify any tasks that are not related to delivering project value under administrative tasks. One attribute of these types of tasks is that team members do not commit to these tasks, they are levied by the organization. The effort planned for these tasks should be deducted from the capacity of the team.  For example, in a five person team with 200 hours to spend on a project during a sprint (capacity), if one person was taking 20 hours of vacation the team’s capacity would be 180 hours.  If in addition to the vacation all five had to attend a two hour department staff meeting (even an important staff meeting), the team’s capacity would be reduced to 170 hours.  Administrative tasks can add up, deducting them from capacity makes the impact of these tasks obvious to everyone involved with the team.  Note: in organizations that have a very high administrative burden I sometime draw a line on the burn down chart that represents capacity before administrative tasks are removed. 

Project-related non-story tasks. Project-related non-story tasks are required to deliver the project value.  This category of tasks include backlog grooming, spikes and retrospectives.  There is a school of thought that the effort for these tasks should be deducted from the capacity.  Deducting the effort from capacity takes away the team’s impetus to manage the effort and the tasks. This takes away some of the team’s ability to self-organize and self-manage. The team should plan and commit to these tasks, therefore they are added to the backlog and burned down. This puts the onus on the team to complete the tasks and manage the time need to complete the tasks. As example if our team with 170 hours of capacity planned to do a 10 hour spike and have three people perform sprint grooming for an hour (total of 13 hours for both), I would expect to see cards for these tasks in the backlog and as they are completed the 13 hours would be burned down from the capacity.

Tasks that are under the control of the team need to be planned and burned against their capacity.  The acts of planning and accounting for the time provide the team with ability to plan and control the work they commit to completing.  When tasks are planned for the team that they can’t control, deducting it from the overall capacity helps the team keep from over committing to work that must be delivered.   

Commitment

Commitment

All project teams have to balance the tension between what the business wants (aspirations) and what can be delivered (capacity). The overlap is what the team can commit to delivering. There are several ways to manage this tension. The first is the tried and true method of just telling the team what it will deliver. This usually has negative consequences. The second is to work on syncing aspirations with capacity. Karl Scotland describes this as moving work to the team. A third method is to foster learning within the team, so that it grows its capacity and commit to more (and perhaps different) work. I have worked for organizations that exhibit the first type of behavior and would rather not do that again. In later years I have worked for organizations that embrace both of the later scenarios and the teams are far happier!