Episode 380: Scaled Agile (Free)

Play Now:

Studyng for your Project Management Professional (PMP)®? Put PMP training in your pocket!

Andrew Burns and Cornelius Fichtner

Agile began with the promise to make smaller project teams more able to react to ever changing customer requirements. Scrum project management teaches us how to make that happen and how to work in flexible, agile ways to deliver what the customer wants. But what if your project is big? I mean really, really big. Can we have scaled agile?

This interview about Scaling Agile with Andrew Burns, PMI-ACP, PMP, was recorded at the Project Management Institute (PMI)® Global Congress 2016 in San Diego, California. We discuss his paper and presentation Dragon Scales: 50 Teams Scrumming -- Implementing Adaptive Project Management Practices at Scale. Here is the abstract:

Product portfolios can easily scale to 50 teams or more in meeting large organizations’ needs. Large portfolios with strong foundations are derived through values-based leadership. The technique links corporate and individual values to scientific principles. Scientific principles inform us that change is constant and therefore adaptation defines good practices. Values-based leadership’s agile practices take root, thrive, and adapt at the pace of business change.

The three-hundred software engineers considered herein innovated within a portfolio of 18,000 colleagues. Their agile, adaptive product development practices continue to evolve from plan-driven provenance. Leveraging agile practices at the portfolio, program, and project level continually unleashes innovation, quality, and throughput of value. Though contextualized in terms of software product development in the 2010s with Scrum, the message of innovation through values-based adoption of scientific principles is timeless and framework unallied. Implementation of practices observant of values and principles endures as a way to deliver the best products regardless of toolset.

Agile project management is a growing domain, especially agile project management with scrum. It is possible to scale this approch, as frameworks like the Scaled Agile Framework (SAFe) show us. The role of project manager in SAFe Agile can be critical. Scrum agile project management training can help if you want to learn how to scale, but meanwhile, Andrew's interview makes a fantastic starting point to learn more about scaling scrum to fit your organization.

Click to download the white paper

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 beautiful and sunny San Diego at the PMI 2016 Global Congress and with me is Andy Burns.

Podcast Interview

Cornelius Fichtner: Hello, Andy.

Andy Burns: Hello, Cornelius.  

Cornelius Fichtner:  Good morning to you. You are going to be speaking on the title of “Dragon Scales: 50 Teams Scrumming” and we’ll get to that in just a moment. When is the presentation going to be?

Andrew Burns: It’s going to be Tuesday at 3:00

Cornelius Fichtner: Tuesday at 3:00. Any idea how many people have signed up?

Andrew Burns: I don’t. But I think there will be more fill up based on the interest on Agile. So we’ll see. I hope everyone comes early.

Cornelius Fichtner: Yeah. It’s actually a good segue, Agile because you are subtitled, “Dragon Scales: 50 Teams scrumming”. The subtitle is “Implementing Adaptive Project Management Practices at Scale”. Adaptive Project Management Practices—are we talking only Agile here, are we talking more than that?

Andrew Burns: Well I like to contextualize Agile because it’s become such a marketing term that it’s got a lot of bad connotation that goes with it and if we really look at the history of Project Management, we went from the 1970s where everything was very heavily plan-driven and I think that calling that Waterfall is actually a misnomer because it’s really plan-driven. It’s plan the plan and work the plan, execute the plan, stay on the plan. Maybe ten years after that, we began to see iterative methods developed. About 1985, the Department of Defense in the US said, let’s lock down on iterations for project plans. Let’s not do these heavily plan-driven events anymore because the Army, the Navy, all the various departments of government, they like to inspect work frequently. They know the Plan-Do-Act-Check-Work. So they wanted to have these fast iterations or what they call “Spirals” so that’s what I see as sort of the second elevation of Project Management, at least in my lifetime. The third is this Adaptive wave. When the Adaptive wave looks at Project Management and says there are some things that we do that we can’t know the answer, until we show what we’ve created to our customers and this perfectly represents product development software where I spend most of my time. Really because it’s such pure knowledge work, we need to go ahead and create something small, show it to our customers very quickly and ask them what they think of it. We need to adapt to the requirements which are not very clear. They don’t know their own requirements until they see what’s possible because it’s all new. This is the third elevation, Adaptive Project Management and I think the techniques are very different from plan-driven or what we call Waterfall. I also think they’re very different from iterative. There’s been sort of three elevations of Project Management in my view and Adaptive is the third and it’s really where Agile falls in. Agile is a very broad and mixed bag. There are dozens of methodologies and hundreds of practices literally. You can really become saturated in so many practices. So it’s really, really key to understand that to get the right tailored suit for your program or project, you need to be aware of all of the practices that are out there and be able to select just the right ones—just the right medicine for what you’re trying to do. My talk is really quite about that. It’s giving people the skills set so they can identify the practices that work and adaptive. I also have a very candid conversation about projects which –it doesn’t make sense to do Adaptive Management Techniques because Agile and Adaptive is very expensive. You’re constantly planning and re-planning and it just doesn’t make sense to invest all that time on a project that can be completely plan-driven.

At PMI we represent 500,000 members across the world, many of whom are doing purely plan-driven projects, many of whom like myself are doing things that are 100% adaptive but the thing that’s great about the organization is across that spectrum we get together and we talk about the techniques that apply and how do we pick the best practices or the good practices. Some of those techniques, I found are similar across all three tranches that I’ve described. So whether you’re in Plan-driven, whether you’re in Iterative, or whether you’re in Adaptive or Agile, understanding values, principles and practices is a key method to communicate exactly what needs to be done in each of these planning frameworks. And that’s something that I’ve talked about in this presentation as well, so I think that everybody who attends will see that one of the learning objectives is to come out of this and say: I have this mental model in this tool kit which will allow me to go ahead and look at this broad universe of techniques that have developed over the past 50 years. Frankly, with a lot of help from the Project Management Institute and assembled in a way that works for my program, use the right stuff, find the things that are exactly on point. I’m very excited to do this talk, obviously.  There’s some great learning objectives right there.

Cornelius Fichtner:  Let me start by reading the opening statement from the introduction in your paper. “Motivating several hundred software developers to adopt Agile seldom occurs based on the project managers’ legitimate reward, expert, referent or punishment power, a personal internal motivating force is required. Can you maybe expound a little bit where that introduction comes from, both from who are these several hundred software developers that we’re talking about and where are we taking them? What’s the journey we’re bringing them on?

Andrew Burns: let me say a few things here in the interest of being open and honest. I quoted the PMBOK here in terms of the project managers authorities so I could cite the PMBOK in my paper. [laughs] I felt that that was a good thing to do but also I really believe that because there are certain ways that project managers become empowered. One is the sponsor may come down and say, “You have the power of Almighty Zeus and you’re in charge of everybody”. And then there are different gradations of power, can we discuss those but truly to make people want to work, they have to be involved in developing the plan and to get people involved in developing a plan, you have to get to a more fundamental human need. You have to speak to people based on their core values. All of us share many of the same needs. I work as you’ve noticed on a very large portfolio, people in literally every continent, in every time zone and one thing that the project manager or program manager has to realize is that no matter where people are in the world, they all have the same needs. We need to speak to that and we need to speak the values before we start any other conversations.

So a little bit more about my job and some of the background for this. First off, I’d like to make a mini safe harbor statement and say that anybody that’s listening I am not here at Congress or in this podcast to try to sell anyone software. In the interest of my employment I will say, I’m also not here trying to not sell any software. Software has nothing to do with it. I am here to talk about Program Management and how to run a good program. Agile has done something really interesting and really, really valuable. It set up this sort of system where you first start talking about values and for example we might talk about openness and respect and these values help us think about, what is it that really energizes everybody on the team? And then we look at the principles of nature that are at play. One of the most common principles of nature that’s at play in any program or project is inspection and adaption will always outperform an inspected system. It just goes straight to reason if you have a project that runs for a year and you don’t inspect anything till the end, you can expect problems. If you inspect every month, of course, you’re going to do better.

Cornelius Fichtner: If you find the problem much sooner, you can fix them.

Andrew Burns: And you get opportunities. One of the core values of most Agile framework is courage. It takes courage to do these inspections because you’re going to find mistakes and mistakes are bad, yes? Mistakes are what gets us bad performance reviews. Mistakes are what makes our peers think we didn’t know what we’re doing. It comes down to being a little bit open and honest about this. Valuing these things as a corporation and as a team and as an individual and saying, “Well of course I didn’t know what I was doing”. This is Adaptive. We had no idea what product the customer really wants. They don’t know what technology we have. We don’t know exactly what their business case is. We’re trying to marry these two things to the very discreet. We’re bringing them together and we’re going to make mistakes but we’re going to make them fast and that gives us an indication that Ok, we have the courage to acknowledge this principle and now we’re going to put in practices that cause inspections to happen and when we find bad things in inspections, we’re going to congratulate people for making mistakes because they’ve made them quickly and they’ve made them within the context of this framework. This is a very, very culture shifting type idea that comes from many programs.

One of the key learning objectives of this session is let’s talk about this framework of values, principles and practices, let’s do a quick survey of all of them that are out there in Agile and then let’s go through a few exercises as a group, so that everybody can start to think like this. If you communicate a practice to a broad team, a broad global team, and you start with I want everybody to take courage. We’re going to be doing retrospectives at the end of every cycle. And in these retrospectives I want you all to stand up and say, this is what’s wrong. And I want you all to get together and fix that. I want you to do that with the knowledge that you’re protected. We’re in a safe environment, we want to hear the mistakes, we want to hear what direction you’re getting is wrong and we want to elevate this as quickly as possible. You always begin the conversation with values because practices can have different reputations in different time zones and countries and cultures. But values tend to stick and they tend to be very core. It’s a really interesting tool set and I think that everybody who attends the session on this will have an opportunity to really improve their career opportunities because they’ll be able to explain this.

Cornelius Fichtner: Have you seen the after burner keynote presentation this morning?

Above are the first few pages of the transcript. The complete transcript is available to Premium subscribers only. Please subscribe to our Premium Podcast to receive a PDF transcript.