For a Good Relationship between Management and Agile Teams
Do you know these books and articles that try to solve the eternal misunderstanding between the sexes? Why does he hear Y when she says X? Why is there so much dispute on topic Z, even though both really want the same? Such books could also be written about the relationship between agile teams and management. As a product manager at Meisterplan, I decided to tackle this task. In this blog post, I'll share my results and describe the fundamental problem of resource management (and it's a communication problem), present our solution, and show how we practically put it into action.
Euphoria Meets Everyday Life
In many ways, the introduction of agile project management resembles the beginning of a new relationship. Management and teams make big plans, and the euphoria about what you want to achieve together is great. Everyone is excited and swears eternal loyalty and sets common goals. Then, as in relationships, everyday life happens.
Management: The project has been running for 6 months now. Can it be so difficult to convert the story points into hours, just so we can get a feel for the real duration?
Agile Teams: Really? Weren't we promised the freedom to use agile, which means organizing ourselves independently and working iteratively and incrementally? Why are we constantly being watched over our shoulders?
This friction can essentially be traced back to one cause. Both sides have to deal with challenges of everyday life, which happen at different levels. Management needs to plan resources and decide when which projects should be done and what commitments can be made to customers. They need to know when something is done. This occurs at the strategic planning level.
The teams, on the other hand, face quite different challenges, which are at the implementation level. The cause of Bug 433a2X5 is still unclear. The current story is much more complicated than initially thought and probably needs an additional sprint. In addition, the stakeholders constantly have new ideas, but that's OK. That's why we work agile. It's obvious that this complicates long-term planning, right?
Clichés and Their Causes
Let's take a step back and look at the situation. Both sides usually have the goal to deliver a great product to the customer by the agreed upon deadline. The problem is that in everyday life you usually don't have meetings to make general mission statements, but to discuss what is important NOW. Management, already in the mindset of resource planning for the next projects, wants to know if certain key resources will be available as agreed at the start of the project. The product manager opens Jira and points to a burn-down graph that shows that it is increasingly unlikely that all the stories in the current sprint can be completed at the end of it. At the same time, he is having a hard time making an estimate that extends beyond the next 12 weeks. Clichés and prejudices are activated: "Management is trying to push us into the waterfall model." Or "In agile, the work will get done...someday."
It goes without saying that management has to set deadlines. Just as it goes without saying that not every story comes to a happy ending. And not every milestone is fulfilled in the waterfall model. The problem is that working in agile from the ground up is designed to accept that fact - and that's reflected in the language used as well as the tools used to show progress and predict it. Flexibility is part of the method and typical agile tools display that flexibility. This does not mean that agile teams "never finish" or "eventually finish". It just means that agile teams work with tools and methods that, while delivering excellent results at the implementation level, make it difficult to make the kind of clear statements needed at the level of strategic planning.
Let's consider another point. Agility should help deliver a suitable product to the customer as early as possible and improve it piece by piece. The point is not to create a perfect product by a specific date. The period for which a budget is made available to fund developments always has a beginning and an end. The agile approach is just the mode of working on the topic within that time frame. And management can not really care less how the teams reach their goals whether using waterfall, Scrum or any other method doesn't matter, just that they are successful. What they need is information that they can compare and use as the basis for decisions and successful resource management. Good solutions are needed for this.
Why Look Elsewhere?
When you google terms about getting an overview of Jira work or Jira resource management, you will find two solutions from Atlassian. The Gantt presentations in Confluence will turn up in the search results, and the extension Jira Portfolio addresses exactly this problem. Since we face the same challenges in our own company as other software companies, we tried to tackle the issue with both approaches, but they didn't work for us. It was neither elegant nor easy to show the developmental themes on the timeline. In our case, the reason was that both solutions offered by Atlassian are more preferred by developers. But we weren't looking for a tool that gives developers an overview. We wanted to solve the communication problem between strategic planning level and implementation level. In other words, we were looking for a tool that enables management and agile teams to communicate on roadmaps, milestones, and resource management in everyday life. Of course, we also used Excel. But we did so cautiously, and it wasn't an optimal solution. Then we found a solution from Goethe:
"Do you wish to roam farther and farther?
See the good that lies so near.
Just learn how to capture your luck,
for your luck is always there."
Meisterplan as a portfolio management tool provides the exact views that are essential to senior management, colleagues, and the project team - and it makes it easy to visualize and discuss individual projects in the context of the entire project portfolio. We just never really thought through how we can map our agile work together with our traditional projects.
The Whole Picture in Three Steps
Here is the description of how we started to map all our projects at Meisterplan using Meisterplan. These were all the steps I needed:
- I created an empty Meisterplan instance, added all our colleagues and myself as resources and users, added a field “project link” (type URL) in the settings and finished the basic configuration. We didn’t need elaborate interfaces or connectors in the first step.
- All that landed in Meisterplan was the framework data and status data on the topics. An example with Jira: I created the project “New UI 2018”. The start date was the beginning of the first sprint and the end date was the expected release date, according to the product owner. As product owner, I assigned the project manager. The status was “In progress” and the notes contained two short sentences about the current status.
- Then the link to Jira was missing. The Product Owner had put together a release in Jira, which contained all issues for the new UI 2018. I could address this directly via a link and entered this link in Meisterplan in the field “Project Link”.
That's it. Then I did this for all topics that were in conception and development. In addition to a Jira release link, epic links or Confluence links were also savedas a project link in Meisterplan, depending on where the project plan has just been edited.
This also worked wonderfully with non-developers working with other tools. Whether Trello, a PowerPoint document in Office 365 or a link to a project in our CRM system (CAS genesisWorld), there was always an link we could use. And in Meisterplan, it was always the same. A few fields were maintained: start date, end date, status, project manager, project link, and, if necessary, the notes and milestones. After only two days, I had all the topics implemented in Meisterplan!
The Results: Clarity for Everyone!
When it comes to managing our portfolio and scheduling resources, we can now focus on all topics (not just development) at once and they are easily understood. For example, I can put together a marketing topic that depends on a release, and show how the layout there has to change when it's released to another event.
We have divided the amount of all topics that we want/need to work on at Meisterplan into smaller sub-portfolios. For each of these sub-portfolios, a team at Meisterplan is responsible - both for the implementation of current topics and planning of the next few months. In this respect, it is not a top-down PPM. Everyone contributes to the plan. And most importantly, with the visualization in the Gantt chart, we have a view that shows everything and is understood by everyone at a glance. It is always clear that we are exchanging at the strategic level, and it is not about "micromanaging" the teams or imposing a different project management method on them. The point is that everyone can see their work in an overall context when needed, and coordinate with other teams and management.
As a result, the ideas and suggestions of the teams, with the requirements and wishes of the stakeholders, become a feasible plan, behind which everyone stands and with which everyone identifies.
The Next Step: Jira Link
This was a great result, but you know what it's like when a bunch of tech-savvy people use a tool more than three times. Someone always has an idea of how it could work even better and be more efficient. In our case, the result is our integration with Jira that we call the Jira Link. Of course, it's great to just have to click on the project link to get to the relevant project info in Jira, but it is even better if Meisterplan pulls the relevant information directly from Jira and clearly presents it. And that's exactly what works now. Once linked, Meisterplan now pulls all relevant information via API. These are displayed in a separate area next to the Gantt. For example, you can see at a glance which stories are feasible in the project and which exceed the deadline. In addition, you can query remaining person hours or story points and put them in relation to the allocated resources. Meisterplan then also predicts the finish date for the project and displays that in the Gantt chart. Of course, you can also manually adjust the Meisterplan estimate. In any case, you have all the information you need ready to use at the click of a mouse.
As your planning changes, you can visualize the impact directly and interactively. This promotes understanding and brings the two worlds together perfectly, which is what I call a good basis for a long-term relationship between management and agile teams.
Meisterplan offers everything I need for a transparent decision-making process. It helps me keep track of the strategic goals, and delivers appealing, understandable and clear visualization right away. Our entire team, not just product management and senior management, benefits from it. If you want to take a closer look at Meisterplan, try the tool free or 30 days. You can also access our Lean PPM™ templates to ensure that you have the right processes and meetings in place to support your project portfolio management.