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.