Kennis Blogs Scaling Business Agility in the Enterprise with SAFe, JIRA Portfolio and JIRA Software

Scaling Business Agility in the Enterprise with SAFe, JIRA Portfolio and JIRA Software

It has been almost 3 years since Sander Brienen wrote the post "Scaling Agile in the Enterprise with SAFe and JIRA Agile " and had his talk at Atlassian Summit 2013. Sander's premise to view an organisation in three levels (Portfolio, Program and Teams) and the general approach on how to plan work of his talk and blogpost are still valid. Fortunately the tooling to provide insight and overview has advanced in the past 3 years. Organisations need a new definition of success. Not the biggest organisation wins, but the organisation who gets the best fitting products to the market in the most efficient and effective way. This is a collaborative game! 

 

We believe that Agile is the best approach to play this game. If you take the right parts out of the different methodologies like SAFe, you can win it. This is a blog post about scaling Business Agility with best practices for portfolio, program and team management, supported by Atlassian tooling.  

 

Hopefully this post will enable you to rethink your organisation and do the right things at the right moment. In this post we will show how a combination of JIRA Software boards and JIRA Portfolio can be used to manage your portfolio, roadmap and help you determine which of your teams can pick up your epics and when they will be ready. This post will discuss some of the more common use cases like:

  • Managing the portfolio from idea to done
  • Roadmap planning for your portfolio epics and features with JIRA portfolio
  • Viewing progress on both the funnel and the implementation and dealing with capacity constraints
  • Creating what if scenario's for epic and feature implementation.

 

Since we will be borrowing some parts from SAFe and try to match them to JIRA, we need to point out that the hierarchy that the tool and the methodology use, both use the term Epic, but use it to mean a different level.

 

In the picture blow you see the JIRA hierarchy on the left and on the right the SAFe hierarchy terms are mentioned.

 

1

 

Portfolio Level - Seeing and managing the portfolio from idea to done

As explained by Sander, the portfolio level is the highest level in the SAFe methodology. This level is key to making sure your organisation does the right things at the right time in a sustainable way. Having the right mix between business and architectural initiatives and determining how to best use the available capacity or budget.

 

In SAFe we make use of the portfolio kanban to see and manage the whole portfolio from idea to done. How the portfolio kanban works is described on the the SAFe website (http://scaledagileframework.com/portfolio-kanban/) and they offer the following why:

 

SAFe applies a Portfolio Kanban system in this context for a number of reasons:

  • Make the strategic business initiative backlog fully visible
  • Bring structure and visibility to the analysis and decision-making that moves these initiatives into implementation
  • Provide WIP limits to ensure that the teams responsible for analysis undertake it responsibly and do not create expectations for implementation or time frames that far exceed capacity and reality
  • Help drive collaboration among the key stakeholders in the business
  • Provide a quantitative, transparent basis for economic decision-making for these, the most important business decisions

 

So how would we be able to use tooling like JIRA to do all these things that are described in the portfolio kanban?

 

The portfolio level is the highest level of planning and tracking. Per portfolio or budget-group we would recommend to visualise this with a single Portfolio team kanban board. This can be implemented in JIRA with a single project or consists of multiple JIRA projects. Most of the times a single project is a good approach. This project is used to track the initiatives JIRA. This can be business initiatives and architectural initiatives or just plain initiatives (in SAFe we would call these initiatives Epics - http://scaledagileframework.com/epic/).

 

The SAFe Portfolio Kanban has the following (cascading) workflow:

  1. Funnel – This is the capture state, where all new “big” ideas are welcome.
  2. Review – In this stage the preliminary estimates of opportunity, effort, and cost of delay are established.
  3. Analysis – This is where the more thorough work is done to establish viability, measurable benefit, development and deployment impact, and potential availability of resources. A lightweight business case is developed. The epic is approved or rejected at the end of this state.
  4. Portfolio Backlog – Epics that have made it through the portfolio Kanban with “go” approval wait in the Portfolio Backlog until capacity is available.
  5. Implementation – When capacity becomes available, epics are transitioned to the relevant Program and Value Stream Kanbans, where implementation begins. The reports described in Metrics can subsequently be used to track epics at the portfolio level.
  6. Done – The epic is done when it has met its success criteria.

 

You can visualize this workflow with a kanban board which is ideal to track progress of the portfolio items. Below are two examples how this could look like if you would do this with JIRA initiatives (or SAFe Epics) or with a bit more detail, with JIRA epics (or SAFe Features). The initiative board makes use of a single project (see the PM-keys) the epic board shows epics from multiple (JIRA) projects. Depending on the granularity of your portfolio process one of these two is the better fit for your organisation.

 

2

Initiative Portfolio Kanban example from the Teams in Space demo environment

 

3

Epic Portfolio Kanban example from the Teams in Space demo environment

 

What can help during this process is the lightweight business case template. We would recommend that you create Confluence template for this. You can then create a linked confluence page for each initiative (or epic) based upon this template. By progressing the issue thought the workflow the information on connected page will grow and by the time you reach implementation you have all the information and validations to start the implementation of the initiative.

 

Program level - Initiative breakdown and planning releases

When you reach the Approved roadmap or Portfolio backlog phase the initiatives and related epics are waiting for Implementation by the teams. This is the point in the process, where you can start thinking about planning release moments. You can create what if scenario's for epic and feature implementation and see how best to plan this based on the available teams, dependencies and their capacity. JIRA Portfolio is purposely built for this. I am not going to go into a lot of details about how you can do this in this post. In my hour webinar I discuss this in a lot more detail then I ever can in a blogpost.

 

4

 

In the above example you see how the different Epics (blue bars) are picked up by the teams (PLAT, IOS, ADR), what the different releases are (green and red lines below the Epics) and in the bottom part the Epics break down into Stories and what the estimates for the epics and stories are.

 

The goal is to provide the stakeholders, business and / or customers with the highest value first.

 

5

 

User story mapping, functional decomposition or splitting epics according to one of the nine suggestions from SAFe (http://scaledagileframework.com/epic/) can help you break down initiatives into epics and releases. So you can do the right thing at the right moment.

 

Team level - Cascade planning to team level and keep track of the bigger picture

After planned the releases, the teams start working on the initiatives and related epics.

 

Stakeholder will want to know the progress on 'their' parts. Stakeholders should be familiar with the way your teams work. The teams most likely are using scrum or kanban boards (in tooling or on whiteboards), invite stakeholders to their demos and are actively involving the valued stakeholder. On a local team level this works fine, but to have a bigger overview this will usually involve project managers or product owners creating reports. With the introduction of JIRA portfolio 2.0 (summer 2016), this can also be done in Portfolio with live plans. The live plans give you the ability to see how the progress on the previous planned releases, epics, initiatives is progressing, what dependencies there are and which ones are at risk. It gives you the bigger picture almost for free without the need for manual reports and best it tracks the actual real time progress of the teams.

 

Do you want to know more?

To see all the aspects we covered in this blogpost in action you can look at this webinar (in Dutch). It will show our best practise on how to create insight and overview for your portfolio management process and focuses on the portfolio and program level.