Episode 381: Scaled Agile for The Enterprise (Free)

Play Now:

Get Project Management Professional (PMP)® exam ready by putting PMP training in your pocket!

Joy Beatty and Cornelius Fichtner

We continue our look at the topic of scaled agile that we started in the previous episode, this time by looking at "agiLE" - Agile in the Large Enterprise.

This interview about Scaling Agile with Joy Beatty, PMI-PBA was recorded at the Project Management Institute (PMI)® Global Congress 2016 in San Diego, California. We discuss her presentation and white paper Making "agiLE" Work: Agile in the Large Enterprise. If you are looking to adopt agile project management with scrum and then intend to scale it, this interview will help you understand how that can work.

Here are the abstract and final thoughts:

Abstract: Almost all large enterprises are making some transition to agile practices. There are many approaches to scale agile in the large enterprise, and we’ll give an overview of the most common scaled approaches and their limitations. This paper also discusses the most common challenges our customers’ teams are facing when scaling agile and provides suggestions to overcome those challenges.

Final Thoughts: This sounds like a daunting task—to transition to agile approaches in a large organization. However, with solid collaboration and communication, it’s absolutely doable. Teams will constantly be collaborating through elicitation, answering questions, and testing the actual product. Business analysts have a critical role to play in keeping the collaboration running smoothly, including helping to facilitate backlog grooming and elaboration, participating in planning in sprints, working with interfacing teams to identify dependencies, and serving as a product owner proxy on any teams as needed. Likewise, project and program managers can act as advisors about appropriate levels of process, help guide projects toward common goals, and ensure a focus on prioritization based on business needs. Instead of instilling a hierarchical control between PMO and product owner, in agiLE the PMO and product owner work together to achieve the objective. The real goal for agiLE teams is self-organization and creativity, while still contributing as a part of a large organization

Click to download the white paper

Scrum project management might sound like a term that doesn't fit into the 'traditional' view of Agile methods, but when you are looking to scale up your approaches, you do need to add structure. Scrum agile project management training is one way to support a team through a transition to scaled agile, and you'll learn more about agile in large enterprises in this episode with Joy, so you can make a decision about whether it is right for you.

Episode Transcript

Below are the first few pages of the transcript. The complete transcript is available to Premium subscribers only.

Podcast Introduction

Cornelius Fichtner:  Hello everyone and welcome back to the Project Management Podcast™ at www.pm-podcast.com . We are coming to you live from the 2016 PMI Global Congress in sunny Southern California. We are in San Diego in the Expo Center here in the hallways and with me is Joy Beatty. 

Podcast Interview

Cornelius Fichtner:   Hello, Joy.

Joy Beatty:   Hi. Good to see you.   

Cornelius:  Yes. Your talk is Making Agile Work: Agile in the Large Enterprise. First question, have you already delivered your presentation?

Joy:   I did, yes.

Cornelius:   How was it?

Joy:   It was great. We had a full room, a lot of excited people. I will say an interesting mix of the audience, mostly project managers and well, I was most intrigued by how many raised their hand that they are doing Agile, that they’re trying to scale it and then I asked how many have been successful? And lots of hands dropped. I would say very few actually of the organizations represented have really felt like they have conquered the large enterprise aspect of Agile.

Cornelius:   What is your personal interest in making Agile work in the large enterprise and how’s your company, C-Level involved in this?

Joy:   Maybe a little bit different than some of the other people here. Our background is actually in the business analysis space more so than project management. We have seen over the last, particularly I would say the last 8-10 years is a shift where our customers were all moving into the Agile space. And so, we’re bringing the business analysis requirements to product managers to project ownership skills to that when we work with our customers but as they try to scale Agile, we’re seeing them fail time and time and time again and so our company has really put a focus on understanding what are the different practices out there? What are the different frameworks and I think the more interesting part is, what works? What doesn’t work? Where do companies get stuck? Because I think that’s where we can actually help them get unstuck. While we do have this BA flavor to it, we’ve kind of broadened ourselves to working at Agile space even more.

Cornelius:   Yeah and we’ve actually decided even though we are going to take a look at the frameworks briefly, high-level overview, the main focus of our talk today is going to be about the implementations and what works and what doesn’t work. I’m first going to ask a relatively simple question, at least it’s going to sound simple, and I’m going to have to explain what exactly. My question is: what is Agile but it’s spelt just slightly differently because we have a lower caps agi and then followed by upper cap L and then upper cap E, so you spell Agile slightly different.

Joy:   We do. I am not sure everybody has picked up on that difference but the idea of what we’re doing here with the word Agile, we’re taking the L and the E at the end to capitalize them to stand for Large Enterprise, so somewhat just being cute about it. But let me actually address the real question there which is, what do we mean by that?” I think most people are at least now vaguely familiar with the Agile manifesto and it talks about valuing things like individuals’ interactions, collaboration with the customer, delivering working software. Those aspects are all still very much there but then I want to say, what does it mean when we overlay that with the Large Enterprise aspect of it. By Large Enterprise, I’m talking—and these are just general rules of thumb—but I’m talking about more than 500 people on an IT organization or teams of software teams, for example of a hundred people or more. It’s large and in most situations we’re usually dealing with global, which means our teams are in different locations, different time zones. There’s usually large corporate objectives from executives that get passed down through many layers that the Agile teams are still trying to deliver against and some frameworks are about all that than others. The other thing that I see when we’re talking about scaling Agile is a really diverse set of users of the systems interacting of the data that’s maybe being passed around. A lot more complexity comes out when we try to scale Agile beyond just kind of that one team working by themselves or even a couple of teams working by themselves. That’s what we mean by the title of this. It’s really taking Agile and taking it bigger.

Cornelius:   Into the large enterprise—into the LE.

Joy:   You got it.

Cornelius:   Exactly. So we mentioned, in order to get Agile into the Large Enterprise, you need some kind of a framework, a scaling approach and in your paper you talked about four of these. Can you give us a sort of a high-level overview first and then we’ll jump in to this full.

Joy:   OK, yeah. At the highest levels, and I will tell you there are many frameworks out there that are—at least people state that they are meant to scale Agile. I’m sure if we check back in a year there will be many more. I just feel like new approaches are out there. I’m not going to go through all of them by any means here—I didn’t in the presentation either. The four that I covered in the talk were Safe, the Scaled Agile Framework, the Less, which is really very similar to a scrum of scrums but just large scale scrum. Then we talked about DAD, or the Disciplined Agile Delivery and then we talked about Nexus. Those four are the ones that I covered. The way that I went about picking those four is really based on some studies out there. There’s a Gartner’s study that looked at one of the most fervently used or at least considered, for me, is in terms of scaling, so that’s how easier than on those four to discuss but then there’s lots of things out there. I think Spotify is a really interesting one that’s gaining some attention. We just need to go through each of them

Cornelius:   Yeah. Let’s take a moment to discuss them and maybe see what they’re used for today—with Safe.

Joy:   Ok. Safe is one of the most complex frameworks and where you’re going to see that deployed is somewhere where, first of all, I love it when I see there’s already some sort of Agile practices in place. It’s not that we’re brand new to Agile and that we’re trying to scale Agile. It works with any flavor of Agile. It could be scrum, it could be kanban and the ideas at these layers. At the very top level we have like a portfolio layer, like it’s divided into value streams which get divided into programs and then below that we have the individual scrum teams or Agile teams. I like this framework, I will also tell you it is complicated enough and it introduces a lot of new terminology in and it is for that reason that it is harder to adapt in an organization. The organizations that I see being successful at this are engaged in full-time coaches to help them through that process.

Cornelius:   Then we have Less

Joy:   And Less. I like Less. It’s two layers, so that’s a nice simplicity to it. It’s like a scrum of scrums. They’ve got scrum teams at the bottom and I have a second layer that engages what they call a head product owner, like a chief product owner if you’ve heard that term, where there’s a common product backlog across many teams and you have that head product owner whose job it is to decide what are we going to play in the iteration, right? And then the individual sprint teams take that, they take their chunk, they go away and they implement them in their own sprints and then it comes back together and that head product owner gets to do the final sign off on if it’s get done or not.

Cornelius:   Then we have DAD.

Joy:   Ok. DAD is much like Safe in that it can scale pretty big and I should mention that Less cannot. It’s usually less than ten teams that you’re talking about there. DAD can scale. DAD is, I think, known for two things, or two things jump out at me as being interesting: one is that they emphasize the organizational goals throughout the entire framework. So the top is setting some goals and we’re making sure at the very bottom they’re for implementing those. The other thing that strikes me about DAD is they put in emphasis on technical excellence. So you have, first of all, people who are dedicated to architecture and thinking about architecture across multiple teams across the organizations. We don’t mess that up when we go Agile. The other thing is they have these teams of specialists that can kind of fly in and solve technical challenge, or get devved up, it’s up and running in different ways. So I like that aspect of it. Again I think it works with any flavor of Agile but you really should at least try and get a solid working Agile team in place before you try and scale it.

Cornelius:   Alright. Personally I knew about Safe, Less and DAD but I have never come across Nexus before.

Joy:   Ok. Nexus is actually quite similar to Less because it’s two layers and so with that there’s a limitation how much you can scale it but –and again it works as scrum. What we find with Nexus is that it can have your individual scrum teams. That second layer is an integration team. This is great when you don’t need a lot of teams but you do have a lot of integration between your teams. You have an integration layer who’s paying attention to where all those integration points and planning for them. The biggest difference between Less and Nexus is that with a Nexus, they still have a common product backlog across the teams but they also use a common sprint backlog across the teams. Whereas in Less, each sprint team has their own sprint backlog that they’re working from and Nexus, they work off the same sprint backlog and the point of doing that is so that they ‘re well aware of whatever the team is doing because of those integrations.

Cornelius:   Makes sense, yes. Ok, so much for the four frameworks here, get those out of the way but now let’s get into the interesting bit. Let’s take a look at the scaling challenges and the suggestions that you have. So what are some of the more common challenges for large enterprises that are transforming into Agile?

Above are the first few pages of the transcript. The complete PDF transcript is available to Premium subscribers only.