Visibility, Focus and Progress: Key Productivity Practices for Software Teams

Software development is complicated and quite unpredictable. One big reason for this is that two software projects for the same application in the same domain but for different organisations can be significantly different from each other. This is because different organisations in the same domain may have different internal workflows, data capture requirements and communication processes. Thus, even the simplest project in well known domains require substantial analysis, research, experimentation and prototyping to understand the requirements. Once the requirements are understood, at least to a certain extent, schedules and budgets are estimated. Estimation inaccuracies, incorrect requirements and scope creep stretch projects unpredictably. Use of bleeding edge technologies to deliver a new system also adds a dimension of unpredictability.

A major challenge for the software development management is to reduce this unpredictability as much as possible so that projects are delivered in budget and on schedule. While this is not completely possible in most projects, following practices can help optimise the productivity of development teams.

Visibility

Software projects require transforming requirements to features each of which is implemented through a list of tasks. It is important to make all the features and their corresponding tasks visible along with their respective priorities and estimates. It is possible that not all features and all tasks are known from the outset. For example, agile projects proceed in iterative development stages such as sprints. Tasks for each sprint are usually finalised before the start of each sprint. Also at times, high priority tasks may emerge and these may have to be scheduled within the current sprint.

Visibility of known and emerging tasks allows them to be prioritised, their
dependencies to be determined and in some cases even dropping tasks that are duplicate or redundant. Invisibility, on other hand, increases unpredictability. Tasks which are known but are not visible to the project team or to assignees are at a risk of being overlooked and thus not accounted for in project or sprint schedules. But these have to be executed any way resulting in disruptions and delays.

Focus

Programming and other software development activities require considerable concentration on respective tasks. It is, therefore, advisable to allow each developer to work on one task from start to finish before initiating the next task. In production management terms, WiP (Work in Progress) needs to be reduced to 1. Developers need to consider tasks assigned to them as being queued and they should only have one task in progress at a given time.

Multitasking, especially in software development, is counterproductive. Task switching has overheads that can be substantial if these tasks require
analysis or other setup. Multiple tasks in progress for individual developers show project planning issues. This largely happen because of overriding priorities or task dependencies that were not ascertained in time.

Overriding priorities are largely production or customer support issues that could not be resolved by first or second line support teams and have to be escalated to the development teams. Their impact can largely be minimised by allocating in every project cycle (e.g., a sprint) a percentage of developer resource to support and BAU (business as usual) tasks. These tasks should have their task list or task board separate from the main project task board. Project resource and effort estimations should also exclude the support and BAU resources. It is important to rotate support and BAU allocations to ensure that the team shares pains and pleasures of both support and development.

Impact of dependencies between tasks can be minimised by allocating all tasks belonging to a specific feature to as small a sub-team as possible, ideally one developer. In situations where there are dependencies between features and these features are too big to be collectively assigned to one sub-team, corresponding sub-teams need to coordinate their development.

Progress

Nothing hurts software development productivity than rework especially because of bugs and faults. It is possible to work again on a feature because of changing requirements. But that work should generally be considered as new work and not rework as this is usually because of emerging facts. Conversely, bugs and faults are incorrect implementation of known requirements and cause regression.

Rework can be reduced through comprehensive testing of software artefacts independently and integrated as subsystems and system. Much of this testing can be automated. Tools also exist to visualise coverage of underlying code by the tests thus guiding developers to enhance testing. A task or a feature should never be considered complete if it does not have comprehensive test coverage.

It is important to measure and visualise progress to ensure that the project is on schedule. Proportion of features completed represents a coarsely grained progress measure. Most commonly used measure is the daily aggregate of the effort remaining in completing a development cycle (e.g. a sprint). This is plotted on burndown chart to visualise the sprint progress. Both these measures are used together in a project, the former to indicate progress of the project while the latter to indicate progress of a particular sprint.

As software effort is hard to accurately estimate, any progress reporting based on effort spent or remaining will be equally inaccurate. If tasks are suitably fine grained, a daily count of tasks remaining instead of a daily sum of effort remaining is a more accurate measure. The only challenge is ensuring that the granularity of tasks is not too fine otherwise the overheads of managing tasks is counterproductive.