Report differently in Agile software development to maintain grip and control
In the software, past results do not guarantee future performance. Everyone knows examples of software developments that are stopped after so many years without results. Control mechanisms are therefore set up at every level. An important but often forgotten aspect of auditing is: how do you report when software is developed with Agile Working? Important because almost all software is developed with a form of Agile Working: Scrum, DevOps, SAFe, etc. Agile Working requires a different rhythm and different measuring instruments to maintain grip and control over software development.
What is Agile Working?
Agile Working is based on sprints, during which small pieces of software are built. At the end of the sprint, there is a presentation of the built software to the product owner. The product owner represents the business. Based on the delivered work, insights, and new requirements, agreements are made about what will be built in the upcoming sprint(s). Based on user needs (also known as user stories), the product owner gives instructions. In Agile Working, the product owner is responsible for maintaining grip and control over the product.
Dashboard van Agile meetinstrumenten
Agile Working is based on sprints, in which pieces of software are built each time. The end of the sprint is a presentation of the built software to the product owner. The product owner represents the business. Based on the work completed, insights and new wishes, it is agreed what will be built in the coming sprint(s). The product owner gives orders based on user wishes (also called user stories). With Agile working, the product owner is responsible for grip and control over the product.
Dashboard of Agile measuring instruments
Grip and control of the product owner is not a guarantee. No guarantee for a high-quality product at the right pace. For this it is important to also use Agile metrics in a dashboard. In recent years, many measuring instruments have been described in Agile working as best practices that provide insight into the Agile Working of various teams. Insight is only available when there is a clear (program) backlog. The backlog is the place where all user wishes are written down and prioritized.
Example of Agile measuring instrument: sprint focus
The illustration below shows the Sprint Focus measuring instrument:
This metric shows the focus of all teams at the sprint level. The blue bars indicate the user stories where business value has been worked on. In the first sprint, the teams still spent more than 80% of their time working on business value, but this decreases in sprints 2 and 3. The orange bar, on the other hand, grows. This indicates that the teams have started to spend more time on technical aspects of the software. This does not immediately deliver business value, but is sometimes important for efficiency in the longer term. It is important that stakeholders investigate whether it is really necessary for such a large percentage of the work to be spent on technical functionality. Working on as much business value as possible is the primary goal. Discussing the metrics of the Sprint Focus supports the conversation to gain and maintain grip and control at a cross-team level.
Grip and control through active use of the dashboard
Setting up a dashboard is a good first step, but not enough. Measuring is not necessarily knowing. Knowing is: Talking about what the figures say about the built software. Only when the product owner uses the dashboard in his discussions with stakeholders (clients, controllers, press officers, etc.), there is grip and control over software development. The sprint focus example shows that there is more to manage in Agile Working than just looking at which piece of software has been built in the past two weeks. Use this and other measuring instruments in a dashboard to have grip and control in Agile software development.
Related insights
