Noel: Hello, this is Noel Wurst with Skytap. Today, I am speaking with Em Campbell-Pretty. Em is going to be speaking at the Agile 2014 Conference in Orlando, Florida on Monday, July 28th. Her session is titled, “The Key to the Scaled Agile Framework (SAFe): Principles Over Practices.” How are you doing today Em?
Em: I’m great. Thank you Noel.
Noel: Great. Thanks for sitting down and talking with us today. We just wanted to learn a little bit more about your session and talk about the act of scaling Agile at an enterprise level and to see what all needs to go into that decision and into that process.
At your session, you ask in the abstract if people on Agile teams have considered “leveraging SAFe, but have been scared off by its prescriptive nature.” I was curious if you wouldn’t mind going into a little bit of maybe what the SAFe really is, and what about that prescriptive nature shouldn’t frighten people perhaps as much as it may.
Em: Sure. The SAFe is a scaling methodology that was created by Dean Leffingwell off the back of a couple books he wrote, Scaling Software Agility and Agile Software Requirements. It uses a lot of lean principles to take Agile from the concept of a single team 7 +/- 2, to many teams of 7 +/- 2 — and making them work together.
The way Dean has depicted SAFe is in an artifact called “The Big Picture.” The Big Picture has lots and lots of little icons, and lots of information on it, and I think people look at that and think that it’s prescriptive. Lots of information in some people’s heads equates to prescriptive.
I think what’s important is it’s a framework. It’s a principles-based framework. Dean himself says that you shouldn’t take SAFe and apply it 100 percent exactly as written. You have to apply it to your context. It may look prescriptive, but it’s a series of principles and practices that Dean has used in multiple places, and other people have used it in multiple places, but it has always adapted to the context that it’s being used in.
Noel: That’s cool. I never really thought about the framework being made up of principles. I think people are a little bit less scared of principles than maybe too much rigidity. Again, there’s not a lot of rigid nature in Agile. It can be done in so many different ways. What I think is really interesting is that whenever I read these surveys of people’s success with Agile or their failure with Agile, the number of people who are succeeding with it it’s definitely going up year after year. I’ve always wondered for those that didn’t succeed at it, I wonder if it’s because of maybe some of that looseness where they tried something, and maybe it didn’t work, but then at the same time, maybe they don’t know that the next time they try it, they can try it in a totally different way and have it still be considered Agile.
I don’t think Agile needs more rigidity, but sometimes those principles can be difficult to implement if maybe there’s just an endless number of ways to do something.
I read on your blog recently that, and we’ll have a link to it, where you detail how your organization launched an enterprise data warehouse (EDW) release train. You offered some really great suggestions for how others can do the same. You suggest that people “Consider how your organization will support your people.”
How important is that support from outside of just the core teams, and where are some of those areas where it just absolutely has to come from to have any chance of success?
Em: For me in particular, when it comes to Agile at scale, success starts and ends with leadership. If you don’t have the right leadership with the right leadership mindset, I think you’re really going to struggle. In my particular scenario, I was in an Agile pocket in a broader, waterfall command and control organization. I suspect that’s not necessarily uncommon. If you’re going to be in that situation, then you’re going to need leadership that’s going to protect the team essentially, and protect the culture and the way of doing things.
I’d add to that, that mindset is a Deming mindset; the role of management is to improve the system of work for the people who work in it. Again, that’s how you create success. There will be lots and lots of things that aren’t working in the organization and that will require leadership with the determination to change that for the team.
Noel: Absolutely. Speaking again about needing that leadership and the lack of rigidity in Agile, you’re presenting another session, Agile 2014 with Jean Tabaka from Rally called, “Creating Agile Tribes.”
I’ve actually never heard of Agile “tribes.” I’ve only heard of “teams,” which is again, another example of how agile can be done so many different ways. In the abstract, it says that people who attend the session will get to learn things like “what is a tribe, and who creates them and what holds them together?”
You said that “The answers may actually startle those who attend”, which immediately intrigued me into why these answers would be so startling. Is it going to be a lot different from maybe the ways people have worked in the past?
Em: Jean and I got talking last year about the idea of scaling culture. We talk about scaling Agile and how do you scale cultures? People spend a lot of time talking about creating great Agile teams, and again, it’s that 7 +/- 2. When you’re beyond 7 +/- 2, and you’ve got multiple teams, it’s not just about creating this great little team. It’s about creating this great team of teams. For me, the tribe is the “team of teams” concept, and I think there are different approaches you need to take to create a tribe out of that team of teams, and perhaps just building the team cohesion at the Agile team level.
Noel: I was just thinking about the beginning of your answer there where you said “scaling culture.” I’ve actually never heard anyone talk about scaling culture. That’s fantastic. I’ve heard people talk about nurturing it, and growing it, and protecting it and all that other kind of stuff, but people don’t talk about growing it. It’s just about nurturing. People don’t talk about scaling.
Em: Yeah, I think we got talking about it actually after a session at Rally On last year. I think we were listening to one of the guys from Scaled Agile, Inc. We were listening to his talk, then after that, talking to prescriptive nature. That was the whole conversation around “yes, there is a framework there, but I think one of the keys to making this work is scaling the culture.”
Then when I was chatting with one of my teams earlier this year, I was talking to Jean about this talk. We were talking about people coming and going from our organization and about fitting in. He said to me, “Yeah, we’re kind of like a tribe”. I thought actually, “that’s really interesting.”
Noel: That is cool.
Em: Yeah. Tribes have customs and rituals and stories and legends. I don’t know, it was really a nice fit for me.
Noel: That’s going to be a great session. That’s going to be fantastic. So, going back to your blog for the last question here, in your most recent post, you go into how to get really great results on an Agile project. Not only does everyone need to care about the quality of the work, but they need to know why they’re doing their work. That’s something that I’m actually doing myself. I’m trying to get more people to write for our own blog. I realized in my first pitch, it was about telling them about how they just needed to do it. They needed to do it well.
Then in the second pitch, it was about why I needed them to do that and why we needed more voices on the blog. I feel like the first attempt, I wish I had never sent it because the second one, the response was really overwhelming. It seems like lately, and I think this is a good thing, that the reason people are doing their work or are being told they’re doing their work, is to either better the lives of, or improve, or simplify, or help the lives of their company’s customers, it’s not just to sell them something and to let them run with it. It’s to provide something that really helps them in their own lives. I think that’s really true.
I wondered if there are any other reasons that developers and testers in particular maybe should care about the work that they do, or just for maybe them to continue to do the work that they do outside of that reason.
Em: I think when I talk about the importance of “why,” I think absolutely it’s a great motivator. It’s also great for providing direction in the middle of a sprint and when you’re not sure what to do, if you know the why behind why you’re doing something it influences your decision-making. I think when it comes to motivating developers; I’m a big fan of Dan Pink’s work, Drive: The Surprising Truth about What Motivates Us. He talks about “autonomy, mastery and purpose.” I think when you create an environment where people can excel at what they do, they enjoy coming to work.
For me, people should enjoy what they do. I think it’s about creating space for innovation and creativity, creating opportunity to grow and learn, getting the opportunity to try new things. I think they’re all great things for inspiring development teams.
Noel: Absolutely. Well, thank you so much for speaking with me today. I really enjoyed it.
Em: No problem.
Noel: Again, Em Campbell-Pretty is going to be speaking at the Agile 2014 Conference in Orlando, Florida. We’ll have links here in the interview on our blog of where to register, where to find out more information about her sessions and all the great sessions that will be going on then. Thanks so much again.
Em: Thanks, Noel.
