While many organisations are pursuing an Agile agenda and defining “New Ways of Working” in order to be more competitive in an ever changing marketplace, few organisations have completed the transition to an end state. This means a lot of organisations currently find themselves operating a multi modal environment that retains some traditional portfolio, program and project management, has some teams operating in Agile like ways and possibly some front runner teams operating in Dev Ops or Continuous Delivery like structures.
Over the past six months we have been approached consistently by customers wanting help to gain better visibility of what is going on across environments using different delivery modes. Here is a summary of what we have found and our advice in solving some of the common themes.
Problem statements …. The most common problem statement we hear is ….
“Our Project Managers can not accurately see or reflect the status of Agile teams work in their project reporting.”
The obvious assumption in this statement is that some of the project scope is being delivered under a traditional project delivery model while other scope is being delivered using Agile delivery teams that may or may exist for the exclusive purpose of that project. The other assumption is that the project is operating in a hierarchical governance model where visibility / reporting is necessary. So let us look at five key steps to solving this problem.
Step 1: Understand what is a project and what is not a project. Modern delivery methods are delivering more and more change without a traditional project construct, so we cannot assume everything is a project.
Step 2: Clearly identify the Epics, Features and Stories from the Agile team(s) that are required to deliver the project outcomes. The Agile team(s) could be working for multiple projects or running a continuous delivery function, so we cannot assume that all work done by the Agile team(s) is actually required by the project in question.
Step 3: Understand how the Agile teams are planning their work. Often work is planned for near term sprints, while in more mature environments work is planned for longer lookahead periods (Program Increment). This will determine how much of a forecast a project manager can realistically expect.
Step 4: Understand what information is available from the Agile Work Management System (JIRA, Raleigh, etc) to provide insights, indicators, measures and forecasts that make sense in a project context. Ensure that all parties understand this information, what it means and how to read it.
Step 5: Give “In Context Visibility”. We try to discourage organisations from pursuing overly complex “integration” approaches to bringing progress and forecast information from Agile delivery and Traditional delivery into a combined view or statement. Often presenting both pieces of information in a single dashboard or report is sufficient to gain enough visibility to determine required next steps. Most modern reporting or dashboarding tools are able to assemble data from multiple data sources and can be done without complex integration.
The above steps assume reporting / visibility is necessary within the context of the organisation in order to drive or support effective delivery. This is not always the case, so don’t forget to ask why visibility is required, who is going to be provided information and what will they do with the information to improve delivery.
In organisations where Agile is in use across multiple teams, squads, tribes and where projects still exist, it is important to have a constant usage pattern for all tickets across all work management systems assuming one project engages with multiple teams to deliver project scope. If usage patterns are inconsistent then information provided to the project may also be inconsistent leading to misinterpretation and wasted time clearing up misunderstandings.
Visibility in multi modal environments is possible and has been achieved. If you are interested in discussing further, give us a call……