Episode 231: Agile, Coffee, Tea and Trains (Free)

Play Now:

This episode is sponsored by The Agile PrepCast for The PMI-ACP® Exam:

This week I am meeting with Craig D. Wilson . Craig is an experienced and very senior project manager who has been involved in the management of many large, enterprise wide programs that also included agile project management with scrum teams.

Because of this background I asked him to meet me in a coffee shop for an interview and answer the following “simple question”, which is: How do you scale Agile to the enterprise?

While Craig does not have a silver bullet for us that solves all our problems in scaling agile to the enterprise, he does have a lot of insight that comes directly from the enterprise front. This is hands on, practical, experience-led scrum agile project management training!

Before we get started with this interview here is a warning: If you are an Agile purist - that is to say someone who feels extremely strongly about implementing Agile or Scrum “by the book” and will be easily offended if someone suggests a different approach - then please press stop now. If that sounds like you, Scrum project management might sound like a strange turn of phrase! This is not the episode for you because Craig will give us his definition of Agile, will discuss the Agile approaches that he has applied on the programs that he managed, and present ways in which he scales Agile for an enterprise initiative. And he doesn’t do it 100% by the book. Instead he mixes and matches those approaches that makes sense for his environment.

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 and welcome to Episode #231. This is The Project Management Podcast™ at www.project-management-podcast.com and I am Cornelius Fichtner. Nice to have you with us.

This week, I’m meeting with Craig Wilson. Craig is an experienced and very senior project manager who has been involved in the management of many large enterprise-wide programs that also included Agile teams.

Because of this background, I asked him to meet me in a coffee shop for an interview and answer the following, well, simple question, which is: How do you scale Agile to the enterprise?

While Craig does not have a silver bullet for us that solves all our problems in scaling Agile to the enterprise, he does have a lot of insights that comes directly from the enterprise front.

And talking about Agile: Are you planning on becoming PMI-ACP certified? Well then our sister podcast, The Agile PrepCast, is the answer. It’s a complete PMI-ACP workshop that you watch or listen to, just like you listen to this podcast right here. Please go to www.agileprepcast.com to learn more and be twice as agile for half the price you’d have to pay elsewhere.

Before we get started with the interview, here is a warning: If you are an Agile purist - that is to say someone who feels extremely strongly about implementing Agile or Scrum 100% “by the book” and will easily be offended if someone suggests a different approach - then please press stop now. That is because Craig will give us his definition of Agile, will discuss the Agile approaches that he has applied on the programs that he has managed, and present ways in which he scales Agile for an enterprise-wide initiative. And he doesn’t do it 100% by the book. Instead he mixes and matches those approaches that makes sense for the environment in which his initiatives are being implemented.

And now, all aboard the Agile train. Enjoy the interview.

Podcast Interview

Female voice: The Project Management Podcast’s feature Interview: Today with Craig D. Wilson, IT Management Consultant with Matincor Incorporated.

Cornelius Fichtner: Well hello Craig. Welcome back to The Project Management Podcast!

Craig Wilson: Good morning, Cornelius. Nice to be here.

Cornelius Fichtner: Yeah, it has been a few years, hasn’t it?

Craig Wilson: It has been, yes!

Cornelius Fichtner: Yeah! So we’re trying something completely different. We’re doing Agile over coffee here. Well, Craig has coffee. I have my tea because I haven’t had coffee in the last 25 years. We are sitting here at a little coffee shop in San Juan Capistrano, what is it called again? Hidden House Coffee. It is right next to the train tracks. We are outside. There are people around us. You’ll probably hear them in the background. And as soon as the first train arrives, we’ll quite have to stop this discussion here.

Main focus of the discussion is going to be how to scale Agile to the Enterprise. That’s sort of the idea. When we originally started talking about this, you sent me an email. At the bottom of the email, I read an interesting disclaimer that you get. Let me quote you here: “Frankly, I have limited hands-on experience with scaled Agile. I didn’t have more than a dozen Scrum teams on a single large project.” Okay, to me, a dozen Scrum teams, that’s already large. “But I have done a great deal of large scale projects and I know what works and what doesn’t.” So how do I have to read that disclaimer sort of in regards to the upcoming interview and what we’re going to talk about when it comes to scaling Agile?

Craig Wilson: Well I think in a lot of cases, what we have discovered…I told you before the interview started that my definition of Agile is that we’ve been doing software development for 70 years now and we’ve learned a lot in that time. We’ve learned what works and what doesn’t work.

For me what Agile does is it tells us the patterns of what works and what we should use and perhaps more importantly, the anti-patterns, what doesn’t work and what we should cut out.

So as I’ve done large projects over the decades, the largest one I think was 135 people, those are core team members not extended stakeholders, 135 people over it. What ended up being a 2-year program of multiple projects and project managers. I think the lessons learned out of that as we implemented iterative development, timebox development at that time we were using used cases instead of the user stories that would evolve into the requirements. The principles that we used then are the same principles we use now. It’s the communication. It’s the restricting scope, restricting the time that you’re going to take to deliver something, I think we’re doing it faster now. I’ve been on smaller programs where we have half a dozen Scrum teams. The real challenge with that across teams was doing the communication. But that communication challenge was the same as I had with larger teams in bygone eras.

Cornelius Fichtner: Let’s talk a little bit about these teams because one interesting statement you made is in regards to how to best use distributed teams, you said: You don’t want a team to be distributed but you want teams possibly to be distributed. Talk to us about that.

Craig Wilson: If you have the flexibility, trying to have a team that is doing creative work that is distributed is difficult. It’s not impossible but it’s difficult.

Cornelius Fichtner: By distributed here we mean, they’re on different continents, going to the extreme.

Craig Wilson: Yeah! People in different timezones or different locations and that sort of thing. In Agile as you’re doing requirements discovery, as you’re doing design discussions, you’re gathered around a whiteboard and remember, human communication is still largely body language. All the studies are still showing that that’s where the communication happens. When you’ve got someone who’s trying to listen in over a phone call, someone who’s got perhaps challenges with accents and timezones, it’s very hard to have that communication. Not impossible but it’s difficult.

On the other hand, if you’ve got distributed resources, people in different timezones, if you could put them into their own collocated teams and have each one of them operate as a single standalone team, their collocated working in the same office, looking at the same whiteboard at the same time, going to coffee together, the communication is greatly enhanced. And then all you need to worry about…all you need to worry about makes it sound simple…but what you need to worry about then is the interfacing of the results between the teams more than the actual detailed discussions of how something is going to be built.

Cornelius Fichtner: Okay. So let me make sure I understand this right. So we’ve gone from one team that has 5 team members on 5 continents. We now have 5 separate teams and each team is in the same location. So team A is in San Diego, team B is in London.

Craig Wilson: There was India or Russia.

Cornelius Fichtner: Team C is in New Delhi, team D in Japan, et cetera. But they’re all in the same building in the same office so that they can work more closely together.

Craig Wilson: If you have the opportunity to do that.

Cornelius Fichtner: Yes.

Craig Wilson: Not everybody does because it tends to be in the organizations where I’ve worked, you tend to have the skill sets distributed. You have developers in one place, testers in another, business analyst in another and you don’t always have that flexibility.

Cornelius Fichtner: Right.

Craig Wilson: In fact, I’ve actually personally rarely seen it. But when I’ve seen it or heard about it, it’s worked very well when you can have the team wherever that team is physically located, all the skill sets necessary to deliver that the iterative development.

Cornelius Fichtner: Okay! So now we have the 5 teams and they’re all Scrum teams, Agile teams, whatever you want to call them. They’re working on the same project. They may be physically collocated in the same corporate headquarters, they may be distributed amongst 5 continents, how do you coordinate across these 5, 6, 12 teams that are on your project?

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