From Agile Program Management perspective what metrics do
you consider and how do you assemble them on a dashboard for periodic
monitoring? I am writing this post to share a set of ten essential
considerations on this topic.
- Set program level goals in such a way that the goals are measurable (SMART goals). Make sure that there are two to three important goals and focus on achieving them. As and when you accomplish a goal, you can add one more goal to this list. Align your dashboard to include a comprehensive list of parameters or metrics related to these goals.
- Besides, show project level metrics that require attention at program level. If your program consists of projects of different categories (software development, software maintenance, test automation, etc.), create a multiple views to show the state of these categories at a high-level. These need not be exactly the status report or dashboard you show at project level.
- Make sure that your dashboard is simple, visible and accessible to all stakeholders. You cannot wait to see the dashboard of your car only whenever you stop for a refreshment break! You need to see it all the time. Design a dashboard in such a way that it is visible, and accessible at regular intervals – A dashboard that gets updated daily can add more value to your program as compared to one that gets updated once or twice a month.
- Include both lag and lead measures. Velocity is a lag measure. You can measure it at the end of Sprints but you cannot control it in a Sprint that passed by. Identify lead measures related to Velocity. These are the measure or factors that impact Velocity. Make sure that your team spend lots of energy on improving these lead measures so that the corresponding lag measure can improve. Lead measures give life to your dashboard. Ignoring lead measures and focusing or showing only lag measures has very limited use or no use at all. What are your project level lead measures? What are your program level lead measures? Find answers.
- Include the right metrics. Is Velocity alone a good enough measure? Don’t we need ‘Cycle Time’? Or ‘Backlog Stability’? Or ‘# User Stories deployed in production environment’?
- Your dashboard is not a static entity. What you include in your dashboard can change from program to program. Also, it can change from one stage to the other in the same program. By ‘stage’ I mean a definite period during which the overall characteristics of a program remain the same. For example, when you begin an Agile Program, ‘Product Owner Readiness’ can be an essential parameter to include in your dashboard because this is a leading measure to improve Velocity and Cycle Time. Also, it is something that needs to be known to all stakeholders including your senior management to obtain necessary help or support in a timely manner when you are running with a very low value on this parameter.
- The dashboard you design and implement needs to tell you whether the whole program is moving towards success or failure. This is not simply the Red-Green-Amber status. This is about providing a view that shows all success critical parameters or metrics and relating them with a key message to demonstrate or authentically illustrate whether the program is winning or losing.
- Practice reuse. Attempt to reuse components across dashboards at different levels (project, program, engagement, etc.) This will optimize efforts and ensure the same level of truth across dashboards.
- Have a good mix of quantitative as well as qualitative information to reflect what is needed, what next, and whether action is happening on the ground or not.
- Do not attempt to create a ‘perfect’ dashboard to begin with. Start with a minimalist dashboard and add more to it gradually. Practice continuous improvement! A dashboard is perfect not when you don’t have anything else to add but when you don’t have anything else to remove from it!
