The Solution for SAFe 4.5 in Atlassian Software

Presentation Transcript

Hello, and welcome to the presentation. Today, we’ll be covering the latest iteration of cPrime’s Atlassian SAFe Solution. This will focus on some updates from SAFe 4.0 to SAFe 4.5. We’ll talk about the different tools that we use to help support this.

My name is Brandon Huff. I’m the Vice President of Professional Services here at cPrime, and I help focus on a variety of solutions to help many of our large Fortune 500 clients. So let’s jump in.

Here, we have the Scaled Agile Framework 4.5 Big Picture. And, this is gonna focus on the full configuration that has the portfolio, large solution, program and team levels.

This gonna be the latest version of 4.5 with a couple of changes from what you may have seen in 4.0. If you aren’t familiar with the changes, let me go over some of the key concepts. But, we do encourage you to go the Scaled Agile Framework website to learn a little more about each layer and how it might fit for your organization.

If you look at what the team has put into 4.5, they’ve really taken feedback from their customers and how teams actually use it to make some iterative changes. Some of these concepts are around testing ideas more quickly. How do we use lean concepts to; make sure what we’re going to build is actually going to be the right thing for our customers and be successful?

Next, we’re gonna focus on delivering faster and this means starting to build in some DevOps concepts around continuous delivery or CICD if you’re familiar with that term. This helps to make sure, that as we create code for our customers we can actually push this out to them. And, help make sure that it’s continually improving and your customers are going to be getting the most out it once we have enough of the right features set in place.

And last up here, we have an ability to simplify governance and really review that portfolio performance and make sure we’re taking the right actions as we go. This will use another lean concept around Lean Portfolio Management. To help, make sure that we are planning appropriately and being responsible with our budgets to help make sure that we’re getting the right ROI out of these particular activities.

Now regardless of which version of SAFe you’re supporting either 4.0 or 4.5, there are some key SAFe elements that are critical to build into your solution. And, we’re gonna focus on how we support 4.5; as well as these key SAFe elements today. Now, let me go over a couple of the key SAFe concepts here. One of them is centralized planning and decentralized decision making. This is to help make sure we have some consistent and thought out planning. But, making sure that we can decentralize the decision making to the teams. Who’s gonna have more information and make the decision based on the information that they have. We also have the foundation that’s gonna be based on iterative planning and delivery. This is to make sure that we aren’t trying to go back to waterfall and plan out to far in advance. But also, accounting for some change. Because, things do change as we start building these products. And this is built into all the different ceremonies and meetings that take place.

We also have to have alignment of our requirements and traceability. Which, just makes sense. If we’re gonna build something and define it as a requirement; how do we track back at every layer inside of the SAFe framework, to make sure that we are meeting the objectives of that requirement?

Next, we have to focus on delivery of business value, not just about lines of codes but how do we make sure that we’re building the right feature set for our customers. Here we have reporting on our features and our progress. And how do we make sure that we’re doing a good job? Are we on track? How are we actually addressing problems as they come up? And making sure that we are communicating them to the team. And last, but not least of course we’re having cross team and cross organization planning. And this, requires not just an alignment of the process but also a tool that can help support that.

So, if you look at our SAFe organization and how they would accomplish these pieces. This where we start seeing that hierarchy from the framework come into play. But also, different responsibilities of each team. So at the top layer we have our epic, alright? You might have some large requirements. And, that portfolio team’s gonna be responsible for them and defining its strategy. As we come down one layer, this is one of the new layers inside of it. The large solution, and these teams are gonna focus on the product and alignment of solution capabilities.

Come one more layer down, we have our program team doing some planning and reporting of that work. Focusing on those features across them. And of course we have our delivery teams down here, doing delivery and support work. Breaking down all those features into stories. And so, this hierarchy is something we want to have reflected. Partly because it’s in SAFe, but also it aligns with how the teams need to work and how they would actually define their work going forward.

So, if we look at our Big Picture. This is how we approach SAFe in Atlassian. And so, over here on the left we have Confluence and over here on the right we have JIRA. And if we look, at this we have alignment to those different layers. We have a portfolio level, both in Confluence and in JIRA. A large solution layer, both in Confluence and in JIRA. Program layers in both, and team levels in both. And this lets us make sure that the requirements that we have as we collaborate with our team in Confluence, match up with what the teams need and how they would use them. But also, that those requirements then carry over into JIRA. So that, we always have some context back to that work and we know what we’re supposed to be working on.

Now if focus inside of JIRA here. Here we have different Kanban boards at the top layers here. So we can manage the work, since it’s gonna be slower moving. Now at this top layer, we have the epic issue type. And this lines up with a workflow, and we manage that in a portfolio level Kanban. As we come down to the next layer, we have our capabilities and this is gonna be new for 4.5. And, they have a slightly different Kanban workflow than what we have seen before. We’ve split up the work into exploration, implementation, and deployment.

As we come down one more layer, this where our feature resides with the program team. And they have the matching work flow for exploration, implementation, and deployment. And this is intentional, because as we grow with the full solution here. We actually, need to align our capabilities with our features and how we would actually plan them. Now coming down to the bottom layer, here we have our teams that can be using Scrum or Kanban. And they can be managing a much more simplified workflow. And they’d be focusing on stories, bugs, spikes and risks. Now some of the key things that we would focus on here is, how would we assign solutions trains and release trains? These are essentially an attribute of each of the issue types. And, how would we do cross team PI planning and delivery? Right? With a goal at the end these PI’s to be able to release on demand. Now, we won’t be focusing today on the release process. Obviously there’s a lot more to that and how your DevOps is actually set up. But we will have a future webinar on how might focus on these particular pieces.

Now if we look at all of this, we then need to focus on how we would report and track on this work. Rather than focus on individual tools, we’ll instead focus on each layer of SAFe and what the team’s needs are inside of that. So let’s start with portfolio team. This team may worried about; are they ready to start the next initiative? Are they working on the right things? Where are we in the process of delivering these initiatives? What are the investment themes we need to look at? Is there a dashboard of the important metrics we need to review? And so this team’s gonna focus on that top layer strategy to make sure that the teams are aligned in the business goals.

So, if we focus here in Confluence as we start. Here we have a portfolio space. And, we might start with a value statement. One of the things you’re trying to accomplish here with a forward looking position. And so, here’s a couple samples we can build as a template. And of course being Confluence, we can have inline comments. We can also focus on comments for the whole page. So we did want to have a comment, “Is it really SpaceX?” And, we can have these conversations inline of this entire document. It’s a very helpful way of communicating back and forth.

All right, now our teams at the portfolio level also might have a business case. And with these business cases we can share a lot of information and also use a similar sort of format. So we can create a template that helps match success criteria, in scope, out of scope, put in different diagrams and charts in here to make sure it reflects what this business case actually is. Now, what’s helpful on here is we can create issues in JIRA from Confluence. So, by simply highlighting the work that we want, we can actually create an issue in JIRA from here. And this gives you a chance to put it in whatever project you want, use, follow the right issue types that you have and create it.

And if we did do this, we would see something like this. That has the corresponding link over in JIRA. So it’s a great way of viewing this information here inside of it. Now, each business case might also have some requirements. Also, following a different template and this gives us a lot flexibility. So this whole space can start with high level concepts and break them down. We can also add any other customization that a portfolio team might need. Either road mapping, personas, anything like that; to help make that information more contextual to what the teams need to work on.

Now we if come out of Confluence, and come over into JIRA. All right, we’ll start with this portfolio dashboard. But, where the portfolio team may spend a lot of their time, is actually in a portfolio Kanban. And so here we see a sample portfolio Kanban, and this is gonna have all of our epics as they come through it. And, if we look at some of these epics, we have the ability to of course enter in summaries and descriptions, have some acceptance criteria and themes, note what stakeholders if we had them in here as well.

But, we can also do our WSJF; our Weighted Shortest Job First. And so we have this set up using power scripts to actually calculate this for us and put it on each card inside of it. So, a very helpful way to view this information as well. We also have our epic implementation, and this is where we would simply tag release trains or solutions trains here as a collection of release trains. Tag value streams if they’re using them. Any story points, start dates, end dates; those sorts of things. Also, lists objectives. Now, this is a sample way we can view this information. And as the team has these filled out, they can use their Kanban board from JIRA software to help manage that work as it comes through. Here we have a whip limit of four. Alright? We’ve exceeded this with six right now. And it’s all for us to use the WSJF here that we see; 5.2, 4.6, 3.8. Alright? As your way of actually ranking these items inside of it too. So it’s a great way for the team to get this information out. But, they may also want to plan. And this is, where we might bring in portfolio for JIRA. And so, here we can pull in information from that Kanban board. Either from a particular workflow or not.

And this gives us the ability to break down our work into the bottom layer underneath it. This is where we start introducing our capabilities. And so we’ve used portfolio for JIRA as a good place to collaboratively plan, do some “what if” calculations, also use different scenarios where we can play this out in different ways and start having different estimates among them. Now as our team works with this, they may also want to view structure. And so we use ALM work structure throughout our SAFe solution as a way to cut across the different layers and start having some visibility into either what’s set up in portfolio. Or, have extra views as it goes further down. So, here we have one for the entire ART. Alright? But what’s nice about structure is we can actually view this on a dashboard. We can view this in Confluence.

And so, we use structure as a way to customize that view and ultimately show it in a variety of different ways and a variety of different places. So what’s great about this is, if we were to open up any one of these items; we can see its relationship not only from portfolio from JIRA but also inside of structure. So we can see this inside of every issue. To get context, to see children, to see roll ups and to customize any view that we want inside of it. So a very helpful way of viewing this.

So, if we come down to the next layer is SAFe 4.5 we now have the large solution. This was previously called the value stream, and value stream still exists but more in terms of the value we’d be providing to customers. Instead, this layer is now focused on solutions and large solutions at that. So this is typically for larger enterprises that have a multitude of other features at the program layer that they need to roll up into a larger solution. And these teams are focused on alignment of that work down below, as well as many of the different product features that we need to focus on. And so, this team may focus on, what are we trying to build? What functionality are our customers need as part of that? What are the cross team dependencies? Right? What’s in our next solution demo? Do we have the right teams in place to go over the context? And what are the features we’re gonna have in the next PI? And so this can really help us identify different customer needs, prioritize in one spot, and help make sure that we have alignment both in the program vision and road map.

So if, we come over here into Confluence. You’ll notice we also have a matching large solutions space. And this space may have different road maps and pieces inside of it with a different team as part of it. But, this team’s gonna focus more on things like solution intent. Alright? What is the solution we’re trying to create? What is the matching JIRA issue? Do we have a board that this resides on? And any budget that we have, that needs to be part of that too. And we can use this to include a roadmap, different process pieces using different tools like draw.io to get diagrams and charts inside of there. And this team may also have some other requirements. Right? Also using different process flows, things that need to be completed and done as part of this. Right? They might also have some non functional requirements, alright? What are the other pieces we have to have? This where Confluence is great, for not just collecting it in one spot but also letting teams collaborate on “Do we have the right NFR’s and requirements in the right places, for this particular solution?”

Now as the teams get out of Confluence, and come over into JIRA. This team will manage that work also on a Kanban board. Now, the slight difference that you may see is; the Kanban board is actually going to be three. One board will focus on exploration, that has funnel analysis and program backlog. One of them will focus on the integration that has our program backlog, items that we’re implementing, items ready for demo, items that are ready for staging. And the last piece her is really for deployment with our DevOps teams. Which items are in staging, which one are being tested, which ones are actually being pushed to production and then finally closed. And so, we can use this as our way to ultimately split up this potentially long workflow into just the areas that we need to focus on. This way here, we have teams focused more on the planning and exploration. Actual delivery with our teams here and NPI’s in the integration side. And then in deployment with our DevOps teams here on this board.

Right, now if we look at any of the different capabilities at this layer. Alright, notice that we might have different teams that we pull in for portfolio for JIRA, different themes as well. We also have release trains and value streams here on this also. Alright, and this one we focus on a little bit more granular planning. Right? So it’s maybe a high level estimate of this capability until we break this down with our teams to be able to see it.

So here we may want to focus on how we would break down this work; and make it relevant still to not only its parents but also break it down into the features underneath it. And to do that, we may want to come look at portfolio for JIRA again. And so we can either use the same one we had before or get a more granular view to look at our capabilities and ways that we would want to create features in the middle of it. And so, this gives us a chance to roll up the work inside of it. Right? Or even have its own parent estimates and then ultimately update this as we go through. Alright? So it’s a great way to get folks in one place using managed permissions here; so people can come in, edit and ultimately create a plan across the teams here.

Now this is great for some of the planning pieces but, we would again use structure to come back and look at those relationships. Now what’s great about structure is we can use the parent link, linking functionality from portfolio for JIRA to create our views here. So it’s actually able to use that relationship, that way we have an aligned hierarchy between the two. And an ability to put this onto dashboards, and in Confluence as well. So between these tools, you notice portfolio and large solution; they may be broken down similarly but this large solution layer is going to start getting granular fairly quickly. And this is when we may start wanna focusing on one particular release train, one particular value stream, or a combination of those two.

So lets come down to the program team now. A program team is gonna focus features and ultimately what needs to be built across the different teams. And so they’re gonna focus on, what are the details of that feature and who might be working it. What about cross team dependencies and how do we handle that? How might we handle planning for a particular program increment? Alright, is there dashboard where we can view this information? What’s the progress that we have in place, and what percent is complete? Alright? Program teams worry about all of these things, and we need an ability to do some planning. As well as, do some tracking as well.

So if we come here into Confluence, this is where we can see our program layer space. And so this has a wide variety of information in it. A program dashboard, some PI objectives, here’s a sample of that. Here’s PI-1, what might be in that. Some details, iterations, teams that are part of it, links over to other JIRA issues that are in it and maybe even a structure in here. That let’s us see the relationships of those items as they’re being planned. We also might have some requirements. Right? This is where we might start viewing, either pulling in or creating from here our different requirements that the team would need to work on. Right? So, it’s a great place to pull in JIRA information into one spot, have some owners and team members identified.

Right? Now our team from here is gonna spend a lot of their time in the program layer Kanban board. And this also matches the same format that we saw at the large solution layer. So we have an exploration, right? Where we do some of our planning up front for those features. We have integration, where we do the delivery of this work across teams. And then we have deployment. Alright, and deployments gonna focus on how we actually work with our DevOps team and push these pieces out. So if we focus on the exploration side and take a look at one of the features. Here’s where we can see feature names, what teams might be working on it. Right? Release trains and value streams. Alright? Also get back to planning and this’ll look very similar to the capabilities, and that’s because our features and our solutions are ultimately gonna be tied together.

And so, we’re actually comparing them as parent and child relationships. Now we of course need a way to view this information, and the place that we would go to view that at first would be in portfolio for JIRA. Now we would want to use portfolio for JIRA to do our initial PI planning. This is where we can use not only the hierarchy that we’ve been creating and children inside of it. But also the concept of teams here to deliver this work. Alright? And this is the teams field that we saw in the features before. As well as our ability to use what they call a cross project release.

And so this actually aligns all of our different fixed versions from those projects into one. So here we have one for ART-1 and PI-1. And if we were to narrow our view down, we can see as we plan: one that started on October 30th and ends here at the of end of December. The work that we think might fit in, and we can view this at each layer as we go through. So this is why we did that planning at the portfolio and at large solutions layers. To help create this particular model. And so this helps us see not only those children inside of it but, do some planning. And this is where we can not only make parent relationships here, and create some estimates as we go through. But also, ultimately use this schedule to determine if this work will fit into this particular PI.

And here we see from a planning perspective, we have quite a few over. So we have a couple choices, as does any team in this situation. We can of course de-scope, we can add capacity to our teams to be able to deliver that work, or we can push out dates. Now of course, it’s gonna be up to each team and how they want to approach these sorts of challenges but this gives you a view into it. That leverages ultimately what teams are available and who can work on this work. The ranking inside of here, durations based on the estimates. Alright? It does of trying to create this schedule for you. So let’s say all this work did fit into one particular PI.

Well we now need a way of actually planning this. So the term we hear a lot is, a program board. And we can actually have a digital program board here inside of JIRA. And this would use Big Picture, and we would use the roadmap functionality here to pull in. Here we see in our horizontal swim lanes, would be each of the different Scrum boards your teams would be working on. And here in these columns, would actually be the shared sprints across those teams. And we’ve ultimately done, is used a shared program backlog to drag and drop our work into the sprints. To help do some collaborative planning across the teams. And so this works great. But, the key value here is really viewing our dependencies.

And so, if we do this. Notice we have some dependencies cut across the different pieces. And we may want to fix some of these items. So notice we have a red dependency here. This is one, we don’t want to begin these sprints until after we’ve fixed these dependencies. So to do so, we can simply drag and drop these items to where they need to be to account for those dependencies. We have the ability to view either correct or incorrect. Correct would be the green ones, where they’re not a problem. And incorrect would be those red ones we saw, that we would want to address. You can also draw your dependencies here. If you wanted to draw one, we can actually update the issue linking functionality and show these dependencies here. So this is a great way to show our PI’s, what sprints are inside of them, how this all might work together. Right? In one particular view.

Now, we may like this view, but we need to look at that information in a couple of different ways. So again we can use structure to actually group and split our work by PI. So here we have PI-1 and we can see the features under the capabilities here. And this lets us see the items that planned for each sprint. And let us get very specific, which what fields we may want to see. Linked issues, stakeholders, WSJF if it’s relevant. Alright? It gives us a lot of details inside of the work here. And of course our program team may want to look at a particular dashboard by PI. So here again we have that same structure, we may want some reports on theme. Alright? On statuses, on worked hours, using thing like Tempo Plano.

So this team may want a dashboard. Here we have one by PI. And this one has that structure in here, that we can actually click into and take a look at. We may want to group our work by theme and determine who the stake holders are for each of them. Look at it by status. And even look at it by hours worked, using something like Tempo Timesheets.

And finally, let’s take a look at our team level inside of SAFe. Now these delivery teams are more than just delivery, they’re often support team that are also helping out to manage the work as it comes through. And, these teams do have fairly similar needs. They need to identify cross team dependencies that are getting in the way. How they would break down that work and its context to its parent item. Do they space in the next sprint to fit work in? If so, which one? How much capacity might they have in that next sprint? Are there discussions on ways that they could collaborate together? What work has been completed? And of course, their team velocity.

Now, if we come over here into Confluence, we have a space for each particular team. So here’s the team in space home. And they might have different pages for a variety of things. One for the different team members, and what each of them does. Potentially, a calendar that shows the different sprints as well as deployment activities on top of it. Maybe, they have information on different features that are coming out and what needs to be accomplished with each of them; as well as children inside of it. They may even have guides for things like their demo’s. How are we gonna accomplish this? What environments do we need. And so the team level is a lot of variety and that’s where templates again can be very helpful to standardize usage of it.

But, these teams may spend a lot of their time over in their Scrum board or Kanban board. We’ll focus on this Scrum board here. And this is where a team can help plan their work in multiple sprints that have been brought in from Big Picture and the cross team PI planning. But, this gives our teams a chance to provide their feedback too. Alright? We’re gonna have decentralized decision making, and let our teams come in here. Change some of their relationships, make sure that their estimates are accurate, and they may also spend some of their time looking in portfolio for JIRA. To help do some of the breakdown of the work here, see what fits into a PI.

They may spend some time in Big Picture, as well. Identifying new dependencies and helping correct ones that are there. And as these teams go, they would be delivering their work just like they would normally. Dragging and dropping their work as they go through. And so these teams would be using something like structure to track its progress as well. But also, having customized dashboards. So here’s a dashboard at that team level, to view that particular Scrum team and how they’re doing. View burn downs. Look at the work by value stream. Potentially different issue types they have, resolution time. A wide variety of things can be put on these dashboards for each of the teams.

So a quick recap of what we saw today using Atlassian to support SAFe 4.5. As you saw, we used Confluence for team collaboration and templates, to collect the right information upfront and; teams can work together to make sure it is accurate and actionable for the teams. We then made sure that we represented each layer of SAFe between Confluence and JIRA so that we had context between the two. We used JIRA software to manage Kanban boards throughout the different layers, with customized issue types and fields; to collect the right information. We then used things like Big Picture“ to do our cross team PI planning. And something like Structure from ALM Works, to make sure that we can see this hierarchy and customize it a variety of ways. And view it, in Confluence as well as in dashboards. So with this again, this is just one way of solving this challenge using Atlassian. But there’s many, many ways to solve this, and this what ours teams focused on here at cPrime.

Thank you for watching today, and if you do have any questions please reach out to us at atlassian@cprime.com