Aligning plans across an organization, staying up to date on progress, and then communicating that progress to stakeholders – simple, right?
Anyone who has been tasked with this responsibility across multiple teams knows there’s often pain associated with it. Once upon a time, the way that Thrillist dealt with this challenge was by entering issues from Jira Software into a spreadsheet. At the end of each day, they would have a 30-minute meeting with 21 stakeholders to discuss status and cross items off that spreadsheet.
As Mike Solomon, the Director of Program Management, shared: “It’s so much overhead to have a 30-minute meeting with every single person talking about what you did that day.” And that meeting was exactly the problem. Mike knew there had to be a better way to do things, and his search led him to Portfolio for Jira. According to Mike: “Since all the teams were already using Jira Software, it’s not like we had to maintain two different systems to report on the status of multiple teams. As long as people are updating their Jira tickets, then the plan in Portfolio for Jira is updated as well. It was better to just look at what we’re doing all in one place in Jira.”
Mike was able to kill his company’s project tracking spreadsheet and they killed their daily 30-minute meeting, as well. This returned precious time to his colleagues, to the tune of over 10 hours collectively each week.
How Thrillist implemented Portfolio for Jira
Mike Solomon shared a great talk with the Atlassian community at Summit 2016 on how Thrillist implemented Portfolio for Jira with Kanban, and the role that Portfolio played in the planning process of their business. At that time, Thrillist was using Portfolio for Jira to track work from three monolithic teams: front-end, back-end, and design who were working on things like adding video support to the Thrillist website and branding materials for their marketing team. One notable integration Thrillist configured was with their version control system so when anything happened in their code base, it would automatically update tickets in Jira Software, which in turn automatically updated their Portfolio plan. This helped ensure their plan was living and breathing and always reflected the most up-to-date information.
To learn more about Thrillist’s approach to strategic planning using Kanban and Portfolio for Jira, check out Mike’s talk at Atlassian Summit 2016.
Group Nine Media merger: 4 companies come together and select the best of their team structures and planning processes
Fast forward to late 2016 and Thrillist merged with NowThis, The Dodo, and Seeker, forming Group Nine Media. With the merger of all four media brands, Group Nine had several developers and product managers from different companies coming together to form one team. According to Mike: “What we wanted to do was to make sure that we took the best of what was working from each of the teams and put them together.” Accordingly, the three monolithic Thrillist teams split into eight cross-functional pods, each pod with UX designers, front and back-end developers, and product managers. They also moved from Kanban to Scrum, with Scrum teams getting together once every two weeks to plan, and then doing a daily video conference to adapt and plan their next 24 hours.”
Mike is now Group Nine’s Director of Program Management and responsible for running a team of several program managers. Mike’s program managers are each embedded within the pods where they do agile coaching and scrum mastering. They’re also responsible for improving the way teams work, leading sprint retrospectives and planning sessions. Mike’s team is also responsible for aligning the pods’ work to the bigger picture strategy and reporting on progress to the rest of the organization. In some ways Mike’s team is like the grease that makes that wheels of Group Nine Media turn and Portfolio for Jira has become a foundational piece of software that helps Mike’s team do their job.
How Portfolio for Jira fits into the day-to-day operations of Group Nine Media
When Group Nine has a big launch coming up, it often times requires multiple pods to contribute something. First, the pods break down their big epics into stories and estimate their work. The program management team will then look at dependencies across pods and identify how many iterations it will take in order to ship the product. As Mike describes: “While we strive to have as much autonomy as possible, it’s just not realistic to think that there’s never going to be a dependency. It’s great when we pull up a Portfolio for Jira plan, and everybody sees what other teams are working on. If there’s a story that a team can’t do because they’re waiting on another team, we can easily see when that dependent piece of work is scheduled and have a better understanding of when the team can get started on their work.
This enables teams to make trade-offs. For example, if a team knows that they will be blocked until Sprint 30 they can plan around that, have prioritization discussions with the other pod’s Product Manager or come up with a solution to resolve the dependency.” In order to get a clean read on dependencies across teams, Group Nine uses Portfolio for Jira’s dependency report.
Mike also uses Portfolio for Jira’s “capacity report,” which shows if specific pods are overbooked on a sprint-by-sprint basis. From Mike’s point of view he likes to see if there are any teams who consistently over-commit. With this knowledge he’s able to assess risk. For example, if Team A has work items that are dependent on Team B, who frequently over-commit, how likely is it that Team A will be able to start their work next sprint?
Finally, Group Nine also uses Portfolio for Jira to create a visual forecast of when all the epics will be completed. Every Monday morning, Mike gets an alert in Slack that reminds him to send the schedule report inside Portfolio to his executive team. Mike notes that his leadership team prefers to consume Portfolio for Jira reports at the epic level because they want to get into the details and get a clear sense of which pods are working on specific epics.
How Group Nine builds a Portfolio for Jira plan
Each cross-functional “pod” tracks and manages their work on a board in Jira Software. Accordingly, Group Nine brings in each of the pods’ boards to represent the work of each team. Group Nine also uses the standard issue hierarchy of initiatives, epics, and stories. For Group Nine, the initiative represents a strategic level of work. This helps bring alignment to teams that are largely autonomous because they always know how their work ties into the big picture strategy.
Top tip for getting started with Portfolio for Jira: Keep It Simple
“Even if you have a lot of teams,” Mike shares, “it would probably be good to start off with just one or two teams on your plan, so you can get a feel with how Portfolio does things.” Mike also cautions that it’s important to pick a team that does a good job of managing their backlog. “Portfolio exposes just how sloppy a backlog can get. If the team does a really good job at keeping their backlog groomed, then the Portfolio plan will be easier to understand, and look really nice. If the backlog is really a mess, then your Portfolio for Jira plan is going to be a mess. So pick your board, and just keep it small, to like one or two teams until you get comfortable with it.”
Summary
Reaping powerful benefits from Portfolio for Jira depends a lot on how teams manage their work on a day-to-day basis in Jira Software. Also, having a program management and Scrum master function embedded into each of the cross functional pods to ensure some the fundamentals are there, like estimation, is helpful. Additionally, the integration between Group Nine’s code base and Jira Software which automates status changes removes friction for maintaining a live plan in Portfolio for Jira. As Thrillist evolved into Group Nine media and the team grew, having these fundamentals in place helped the team scale its process for tracking and communicating the status of work in Portfolio for Jira, even as so much else changed, such as the structure of the company’s teams and its agile framework.