Agile software development might be considered as the preferred way to develop software, especially for those using IEC-62304 processes and following the guidance of TIR45. Our experience at Team is that there are still challenges when doing Agile software development as part of an embedded, non-Agile system development.
Planning is one of those challenges (when is predicting the future not a challenge?). When planning software development, we often estimate the complexity of a backlog of required software features using arbitrary story point units. This is used with the velocity (story points per sprint) at which a team has burned through story points in the past to generate a so called burn-up chart. This gives us an estimate of the number of sprints likely to be needed to develop a software feature set (estimated as a total number of story points) at a given team velocity.
A list of all things that are needed or desired. The list may contain high level items such as desired features for a product down to low level items that a team wants to achieve, for example, problems that need to be fixed or descriptions of functionality to be implemented. Therefore, the backlog is often sub-divided into programme, product and team backlogs.
A unit of measure for expressing an estimate of the complexity of a backlog item or the overall effort that will be required to fully implement a product backlog item.
The rate at which needs or wants contained in the backlog are achieved. For a team, it is a measure of the points completed during an iteration.
Dependencies occur when a team doesn’t have everything it needs to deliver an increment of value or complete piece of work.
For many projects, there may be some flexibility in what is needed and the time required to meet these needs. Factors influencing the needs, such as business goals, may be negotiated and the resources made available varied (i.e. flexed).
This approach can also be used to explore the approximate effects of increasing velocity by adding more resource or investigating ‘what if’ scenarios around the backlog and features. Using sprint duration translates story points per sprint into time. What this simple planning tool doesn’t do is bring in dependencies from other parts of the system or external factors.
In a non-Agile development, the Gantt chart is king when it comes to planning; and it’s very good at planning dependencies. At this point, true ‘Agilists’ may throw their arms up in horror, but we have found that one way to plan for dependencies that could affect software development is to bring sprints into an overall project Gantt chart.
At the moment we unfortunately have to do this manually, but it does allow planning to make sure other system elements (for example hardware or test infrastructure) are available so as not to block or delay software development.
Similarly, we can estimate when velocity may drop due to external factors (such as holidays, hardware bring-up or system availability).
This approach can lead to another challenge. In Agile, it is sometimes possible to flex the scope of what is delivered by a software development team (having a fixed velocity) and time period (each increment of software is intended to be working code).
In a non-Agile world, plans are often made to have something available at a certain time, for example, having a prototype ready for a key meeting or for a device going into clinical trial. This typically doesn’t allow for the scope of what is to be developed to be flexed.
Taking out the option of flexing the scope of software features working at a given point in time puts more emphasis on getting the backlog estimate as accurate as possible. However, backlog features are often loosely defined early in a development and an Agile approach would look to refine the definition of these features incrementally as the development proceeds.
It is therefore advisable to factor in a greater contingency for estimation error when plans extend beyond three to four sprints in our experience. This may mean planning around a reduced set of software features needed for a key point in a project or building in contingency into the velocity of software development early in the project.
Carl heads up Team’s project management group. His role involves planning and managing the successful delivery of multi-disciplinary projects to meet the needs of our clients. Carl has over 20 years’ experience in managing product development in the scientific equipment industry.