Product Management and Agile – Agile Misunderstood

Are you using Jira for software development? Do you find that agile approaches are helpful? And are you trying to tackle all projects in the company using agile and Jira? Yes? Then we’ve already found three things in common!

Ok, let’s keep going: Are you asked every week “Where do we stand now?” and “When will project XY be finished”? Do non-Jira users see “basically nothing”, no matter which Jira view you prepare? And because Jira can sometimes be complicated, are Trello, MS Office tools, etc. also used for daily work or task management? I imagine you’re nodding. And that’s another three things in common – sunk another 3-pointer. ?

Read on to find out how a misunderstanding arose between agile development and product management, and the solution we’ve found so far.

Since the 2000s, the trend has clearly been towards agile implementation of software products and Atlassian has offered Jira to support development teams with the operational implementation. Both of them have also made inroads into our company. First, we tested with Kanban and Scrum to see what suits us better, and we chose Scrum. Then, we started using Jira for agile product development. Each step took time, but we are now successfully settled with both.

The Stories of My (Product Manager) Life

Product management includes many responsibilities, and of course every company handles product management differently. But they all have one thing is common: the person making the budget, (deservedly) receives special attention. In story form, for example, I would express the resulting requirements as follows:

• As a product manager, I want to be able to show how much time is spent pursuing the strategic goals for our product/service in order to achieve those goals.
• As a product manager, I would like to have an overview of the status of development at all times and a rough timeline for the expected delivery of a package/epic/project in order to discuss with the stakeholders.
• As a product manager, I want to make the plan or roadmap understandable for everyone and make all the implications of planning and possible changes transparent, so that everyone can make the right decisions for their work.

Depending on the situation, there are certainly additional aspects in the foreground. For me, these stories express the maturity of our agile product management process quite well. The handling of stories and epics works and the sprints run just as you do with Scrum. But one last element still has potential for improvement: the bringing together of the stakeholder’s view (strategy requirements and their follow-up) and the active, agile way of working.

Can an Agile Process Recognize Appointments?

Introducing Scrum meant introducing a culture change. Moving away from waterfall planning with big concepts to small iterations with quick feedback, and new prioritizations every 2 weeks. Just how much can be done in the next sprint is decided by the team alone.

This secretly led to the perception that “things are done when they’re done.” You might even need another sprint – which keeps the team from rushing and stressing. The client does not. They simply want to know when something is done and what they’ll get. Every additional sprint tends to increase the adrenaline level.

And right in the middle of this adrenaline rush is agile product management (whether it’s product manager or product owner doesn’t matter). On the one hand, there are the benefits of agile, on the other hand, the importance of reliable planning. How do you bring this together? When it comes to product development, they both have their benefits. My experience shows that it comes down to transparency and communication.

Let’s take another look at these two perspectives. Senior management presents a strategically important topic to product management and would like to develop the product accordingly in three months. The product owner and the project team create an exciting concept that should be implemented in roughly three months. The team is always planning their sprints and is continuously improving so that everything in the sprint will get done. If you only look 2 weeks ahead, you quickly run the risk of no longer putting the effort required for a story into the overall context and will want to do too much or try to make everything perfect. And software development (often) takes longer than you originally thought. Management has the end of the three months firmly in mind, but the team is thinking about the next sprint. Where you often get shipwrecked using waterfall, can also happen in small ways with agile.

Here, progress and remaining requirements must be assessed openly and made transparent. The agile method should help to deliver a suitable product to the customer as early as possible, not create a perfect product for any target 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 the time frame.

One Topic, Two Levels

If you are in this situation, then you better connect the seemingly different worlds of the stakeholders and the people doing the work. If the team makes the following accusation to the stakeholders: “You cannot think in waterfall and work in agile at the same time!”, it can be resolved by thinking on different levels. Management must think one level above the agile approach and all must be on the same page. Product management must understand both worlds and connect them creatively.

Jira alone is not enough here. Google “keep track of everything in Jira” and you’ll find two solutions from Atlassian: Gantt presentations in Confluence and the Jira Portfolio extension. We tried using both approaches to tackle the issue, but it didn’t work. In our case, the reason is that both views are better suited to developers. And of course, we also used Excel, but in the long run, it was not the solution either.

As we tackle the issue, I will keep you updated.