“Take actions before things occur.
Manage before things get out of order.
A huge tree grows from a tiny sprout.
A nine-storey-high terrace is built from heaps of earth.
A journey of 1,000 miles begins from the first step. Lao Tzu”
I am often asked about tracking Agile initiatives. For those readers who are part of an Agile team you might ask, ‘What is the problem? We have stand-ups, information radiators, Kanban, burn-ups, co-location. We know what’s going on!’
For other readers, particularly managers and leaders, I have been speaking a foreign language and have not answered their questions: ‘The individual team knows where it is, but where are we in the increment? When will we deliver? What about those not-so-Agile bits I also have to track? What about all that information I have to provide to the project management office?’
Agile in practice
Tracking the journeys of our teams can be compared with levels of reporting. At a high level – for example, a map of the whole country – we would want to know where our teams are on the journey, how far they’ve gone, how much they’ve got to go. We would also want to see any roadblocks ahead.
The team, on the other hand, would want to see its immediate area – for example, a street map of its own city – so it can work out its route and see the detail in that area.
Successful implementations of Agile will incorporate ways to track and report at higher, consolidated levels as well as using the Agile tracking processes within teams. In this chapter, we will explore both.
7.1 Standard Agile reporting techniques
Agile initiatives often use highly visible methods for showing and reporting progress, being displayed as information radiators on team walls or using specifically designed tools. Consequently, the reporting requirements for Agile initiatives are different, and the processes around formal reporting should be reviewed as part of the introduction of Agile.
Agile approaches incorporate regular, frequent delivery of outputs that are typically produced every two to four weeks. This means that the real status is never more than two to four weeks out of date. This provides effective control, indicating that everything is on track or identifying issues early, enabling them to be dealt with before they become major problems.
In general, Agile initiatives have layered status review points covering different time periods. The key ones found in most approaches are:
- Daily – during daily stand-ups
- At timebox/sprint end – roughly every two to four weeks
- At increment/iteration/release end – within two to three months
- At project end.
There are some fairly standard techniques for status reporting in Agile and these are described below.
7.1.1 Burn-down or burn-up charts
Burn-down and burn-up charts are graphical tools for assessing progress and identifying potential issues with timescales or budget.
A burn-down chart (see Figure 7.1) shows the work left to do against the time available. The outstanding work (or backlog), expressed as units, is usually on the vertical axis, with time along the horizontal, usually measured in days. It is useful for predicting when all of the work will be completed.
Figure 7.1 Example of a burn-down chart
A burn-up chart (see Figure 7.2) is a variation of the burn-down chart where the vertical axis represents the amount of work to be done, measured in units customized to a specific project. Units can be expressed in different ways – for example, the number of tasks, estimated hours or story points. The horizontal axis represents time, usually measured in days.
7.1.2 Kanban boards
Used for demonstrating the status of backlog items during timeboxes, a Kanban board (see Figure 7.3) is a graphical representation of work and workflow. It is used to aid understanding and optimization of the flow of work. One form is to use sticky notes on a whiteboard to communicate status, progress and issues. This information can also be represented using electronic tools.
7.1.3 Daily stand-up meetings
Stand-up meetings are used for communicating daily progress and identifying risks and issues (impediments). They are called ‘stand -ups’ as they are very short (up to 15 minutes’ duration) and this is easier if people are standing up. Once they sit down they become too comfortable and meetings can take longer!
Agile in practice
Although many Agile methods require daily meetings, I have also worked on Agile projects where the frequency is more or less. In critical situations, meetings can take place twice a day, for example. Where everything is proceeding well, or there is very little change, fewer meetings may be appropriate. However, beware of cancelling meetings as the daily stand-up is a chance for everyone to step back and reflect. Problems may be occurring that are not obvious and only come to light during the meetings.
7.2 Senior stakeholder reporting
Although the Agile status tracking mechanisms are powerful indicators for the project, and work well at the team level, they may not be the best approach for status reporting to more senior levels on larger, more complex projects and programmes. There may be too much information and it might be difficult for some stakeholders to see the overall status, especially when there are many teams. The information required gets lost in the detail.
At this level, consolidated reporting is more appropriate and this will include information such as:
- An assurance that ‘must have’ requirements will be delivered on time and on budget and to inform senior stakeholders as soon as possible if that will not be the case
- Progress made towards incremental delivery deadlines, summarized and consolidated across teams
- Any issues and/or risks that may affect successful delivery.
This information can be collated by the project and programme manager roles, assisted by project management offices, from information that already exists at the team level. Tools are now available that will provide this sort of consolidation. These avoid duplication of effort and information, and could be valuable for larger organizations.
Agile in practice
Senior business stakeholders may lose interest, and confidence too, if they get too much detailed information, such as number of user stories in progress/tested/delivered. They are more interested in when something will be delivered to them, what impact it will have and whether it is on track. The release is the first point that a potential capability will be delivered. Since the time between releases is relatively short, this is probably the best level for reporting to senior stakeholders.
It is still important to know what information senior stakeholders need. In my experience, they prefer single-page, high-level status reports to lots of detail, even if consolidated. This is in line with the Agile principles of trust and empowerment. Senior stakeholders should trust initiative managers to tell them if there are problems that they should know about, so reporting becomes a mere formality. Agile implementations are a good catalyst for examining reporting requirements and ensuring reports add value; those that do not can be removed.
7.3 Trust and openness
Agile in practice
I once worked on a project to implement a sales and distribution system throughout the organization’s European offices. One of my areas was the Finnish office. I would visit, see the shiny new mainframe machine and watch the system running. Then the team would take me to the sauna and to dinner. Everything was going fine with the implementation.
Sometime later, we found that the system had never gone live, and the team switched the new computer on only when someone from head office came. The status information we received was very flawed!
Although formal reporting is useful, the real information about Agile initiatives lies with the teams. Project managers and any stakeholders (such as you) should not be scared of occasionally attending the daily stand-up meetings to get the real feel and heartbeat of the teams. As long as the principles of trust and openness are being applied, good managers will be able to determine the real status and any potential cross-team problems. Equally, the culture should be such that the teams are not intimidated by the presence of these stakeholders – they should be able to talk openly and highlight the real status and issues even when others are attending the meeting.
Agile in practice
A note of caution: If there are people attending the meetings who are not generally involved in the project and are new to the Agile processes, they may misunderstand the honesty and openness and become worried about the projects. It is important that everyone understands the process!
7.4 Hybrids
When we consider larger projects and programmes, it is likely that some aspects may be carried out in a more traditional way. There may be good reasons why an Agile approach would not make sense for these aspects; for example, there may be no complexity, nothing for users to interact with, and no value in delivering incrementally. So how can we incorporate and consolidate the tracking of both Agile and non-Agile components?
Ironically, many of traditional tracking and reporting techniques exist because of the inherent risks in traditional approaches. This is because nothing really exists until the end and we cannot test whether the solution really meets requirements.
So the answer actually lies in taking a more Agile approach towards the tracking of these more traditional areas. One approach is to plan frequent interim milestones into the sub-project. There may even be parts that can be delivered incrementally. Other Agile practices may be also possible – for example, close involvement of stakeholders during design activities and integrated testing throughout.
Agile in practice
When I was head of a portfolio management office, I investigated how consolidated status reports for portfolios of projects could be done when some were Agile and others more traditional. Often, the consolidated views are based on defined gates – for example, in Waterfall these may include start-up, investigation, analysis, development, testing and implementation. I tried to shoehorn these into Agile, but with little success. Apart from the early stages, all were happening at once. Since many forms of Agile fix incremental delivery schedules, these can be a good alternative for the bits in the middle. But this does not quite work either, as in theory you always deliver. The real measure of status is whether we are on track to deliver the minimum usable subset for the increment. This is achievable using consolidated burn-up charts or radar/spider charts (see glossary). Alternatively, at this level a simple bar chart showing the percentage done may be sufficient.