Good. Thanks, Craig.
Craig: So you are a partner at Context Matters and you have been in the Agile space down under for a few years now. It’s a pretty interesting story how you got roped into this whole Agile space because you sort of came from a different channel, I guess.
Oh, I did.
2. So tell us about the story.
So I came to Agile from the business side, for starters. I was the business sponsor of a large program of work that was struggling to deliver and I was working in an organization that had decided that it would set targets around implementing Agile projects. When I complained about the lack of delivery on my big program, the advice I got was to go and speak to the Agile people, which is exactly what I did. We went from not delivering very much at all, to delivering just a little bit more. So I felt that Agile was good. We were heading in the right direction. But it still wasn’t the return on investment or just any fit in terms of we were spending money, but we weren’t really getting good enough outcomes for that money. The organization had a restructure and went looking for someone to take over the leadership of the delivery team. They did a national search, they didn’t find anybody and they came and tapped me on the shoulder. They said “Em, you seemed to like this Agile thing, you seem to care about this space, you should do this job”. “Yeah, I do not think I am qualified to do this job. I am a business person”. “It’ll be great. It’ll be fine. All the support you need. It is a wonderful opportunity for you, Em” “I’m thinking, you can’t find anybody else to do it, I am not sure how wonderful this opportunity is going to be, but OK.
Absolutely. I said “Ok. Fine” I can’t even work out why I said yes. I think that in the end I just felt that was the only acceptable answer to the question. So, I ended up being the business person running the technology team. I got these five or six Agile teams doing all right, I got another three teams doing something they called Agile and something most people wouldn’t call Agile and I had an outsourced offshore component as well. I had recently read Dean Leffingwell’s “Scaling Software Agility” and I really liked the idea of this Agile Release Train. So, this is kind of cool, right? Somebody hands me an IT shop. Ok, I’ll launch an Agile Release Train. So, I ended up launching Australia’s first Agile Release Train and having a lot of success with that. That was really my “trial by fire” introduction to Agile and since then that is pretty much all I have done.
It was mixed. I was a known entity because I was the business sponsor. So there were people who obviously felt an affinity to me in that respect and there were certainly plenty of people who didn’t at all think that that was a good idea or reasonable. I can remember scenarios in which I was trying to encourage my new leadership team to learn about Agile and learn about the Agile Release Train thing, because that was what we were trying to do and their response being “I have been working in technology for 20 years. I don’t need to read books about how to do my job” OK. So, there were moments. Look, I think I was very lucky. I think I worked with a really great group of people, I had some good support. Some of the team had been with me previously were able to stay, some weren’t, and I guess those who weren’t happy about it found other places to be. So, I think it could have been a lot worse. I have always said I am technical enough to be dangerous and I have always taken a lot of time to try and understand the technology piece. So, while I don’t come from a technical background, when people would have technical problems, I would just sit down with them and say “OK. Explain to me what is going wrong. Explain to me what we need to do” and therefore I guess at least I was always willing to listen which gave me that relationship.
Craig: You were one of the early Scaled Agile Framework, certainly not the first and certainly the book had been around for a while, but your work there has been a widely publicized case study which you can find on the Scaled Agile Framework site. You did some interesting things. For example, I know Dean talks about the haka that you did. Tell us a little bit about that.
Oh, my goodness. As long as you guys do not show this in New Zealand. My goodness!
Craig: There is nobody there watching.
When I went to Boulder to meet Dean and do the Scaled Agile Framework certification, he always shows a video of the All Blacks doing a haka routine. This is a high performing team in the state of Ba. In the class I was in he also had some other clients there who gave him a video of their teams doing the haka and I thought to myself ”Gee, that’s fun”. So when I got back to Australia, I said to my leadership team “You know, it would really be fun if we got everybody to do a haka”. And my guys were kind of funny. One, the resident extrovert said “Excellent idea!” and the other said “Suck!” I had a consultant who said to me “Do we have to?” “You are a consultant, dude. I want you to do a haka, you are going to do a haka. It is going to be great!” And my 2IC who says “You cannot make me do a haka on my birthday!” She was wrong! So, anyway, I gave up on my leadership team because they were really not much fun in that respect and went and found the Scrum masters and said “What do you reckon, guys?” and whether they, I don’t know, they bought in.
For whatever reason, they bought in and that next week I got up, we had an iteration kickoff event, so a Sprint kickoff event, to bring all the teams together at the beginning of every Sprint and we would do various activities and at this particular kickoff event which we called them “Unity Day” or “Unity Hour”, I said “OK, everybody. What we are going to do is you are going to take the next Sprint and you are going to come up with a team haka and then next Sprint, we are going to have a hak-off” And that is exactly what we did and I still think, looking back now of the two and a half years I spent leading that team, that has got to be one of my absolute highlights: the creativity, the vulnerability - they all got up, they all did something, the energy, the camaraderie – I can remember in the time leading up to the haka, so that Sprint, you would walk past meeting rooms and you would hear all this noise coming out and it was they were practicing their hakas for the big event. Some of Patrick Lencioni’s work talks about how teams bond by showing vulnerability and that was really what we found. They got up, they made fools of themselves and it really created a bond and that bond is not just within the team, it was across the teams and of course when we are scaling Agile, that is what we need. We need bonds across the multiple teams.
When I read the book, I was still in the business sponsor role. I had six teams, four projects and everyone was doing their own Agile thing and that is great, but in the shoes of someone who needed to understand how that all came together, it wasn’t a lot of help to me. All the teams were too individual for me to be able to get any holistic picture of how things were going. So, for me, when I read the book, I went “This is good. If we couldjust get everybody on the same cadence, and if we can get everybody planning and lining up their dependencies, then maybe we could get a little bit more delivery, essentially”. Look, at the time, it was even just reinforcement of plain, simple good practice. Let’s do Scrum! Let’s do teams of seven people plus or minus two. Let’s do all these good things. Let’s do Scrum of Scrums. It was a way to very easily move from what was a kind of dysfunctional Agile implementation to a highly functional Agile implementation. I don’t think we had any idea how successful we would be, but we were desperately looking for something and that was where we landed, although what we did with it in the end is also take a lot of ideas from a lot of other places. So, we took a lot of the principles. It was a very principles-based approach because a lot of things we couldn’t implement. So, we stuck with the principles and then applied other things as that made sense to do.
Yes, a business perspective on DevOps. I never really thought a lot about DevOps before I got tapped by Gene Kim last year to talk at his enterprise DevOps conference. And when he tapped me, I just assumed the culture side of DevOps was the conversation he wanted to have with me, because I talk about culture stuff, I write about culture stuff. Surely, that was what he wanted. You can’t imagine my surprise when I get on the phone to Gene and he says “Oh, no. We want people to talk about real life implementations and practices, not just culture stuff.” And I have gone “Oh, OK! Not a problem. I will get back to you!”
Craig: Let me just look up DevOps!
I literally googled DevOps and went “Oh, OK. This is cool. I get this. This is the CI stuff and the version control stuff” and we had quite a journey with that first Release Train. I talked about that period of bad Agile. One of the reasons I always refer to it as “bad Agile” is that it was a lot of process Agile, but not a lot of technical Agile. So, Agile, without the technical practices, for my money, it doesn’t work and I learnt that the very expensive way. So, that was the story I told at Gene’s conference and I was encouraged by the folks at Gene’s conference to submit it for this conference. So, it was a really interesting journey from the point of view that I didn’t know anything about it. I knew I needed to invest, so people would sit downand would explain things to me and I could very easily get my head around if we put continuous integration in place, it will speed up development, we have version control, we’ll have better quality code and all these sorts of things. But when we first put the team in place to create those enablers, we didn’t use the exact standards that we were implementing for our core delivery team. So, we built a bespoke automated deployment engine, without using TDD, without CI, without any of those things that we were busy putting in place for our legacy application.
So, that was hard. That was a really hard lesson. We basically did the whole journey twice because the first time we did it, we did it in a way that we had always done things, which weren’t the way we were trying to do things in the future. I think the other really interesting part of that journey for me was trying to get the technical folk who were helping us build out the CI and the automated deployment to work with the Agile teams as their customers. And yet they would be Agile, right? They would have stories and they would have stand-ups and they would have showcases and all that. But no matter what we did, we really struggled to get that proper customer relationship in place and one of the things that we ended up doing just before I left that group, they took impact mapping which we had been using with the delivery teams to bring ourselves closer to the customers. We took the impact mapping and did it with what we called the system team, the guys who own the CI and automated deployment and said to the teams “OK. If our goal is to reduce our time to deliver and what have you, what are the things we need to change? What do we need to do to enable that? What things are going to have the greatest impact on your world as a development team to make that happen”? That for me was a nice shift and a nice place to leave it to leaving it on a positive trajectory, hopefully.
Craig's full question: The other talk, which is something we have spoken about before, was called “Thawing the Frozen Middle” here at the conference. There is always this perception of, particularly in large organizations, a management structure where perhaps the people at the top and the people at the bottom are aligned but something happens in the middle. Tell us a little about your thoughts and the impetus for that particular talk you gave here.
That topic has been one that has been quite meaningful for me over the last couple of years. The first time I came to the US to attend an Agile conference, it was a very “coachy” consultancy conference and I was one of the few business people floating around. You would go to drinks or what have you and people would keep having these conversations: What do we do with management? What do we do with middle management? I was kind of surprised to find that the advice that these coaches were giving each other was things along the lines of “get rid of them” or “work around them”. That didn’t sit well with me, quite possibly, because I was a middle manager and so that might have been part of it. Later in that conference, I got involved in a fishbowl conversation with Jean Tabaka and Jim Benson and again, Jim was quite articulate about his view that managers are people too, they are just stuck in the system. Yes, that is it. Managers are people, too. And we are all stuck in the system and as much we talk about the role of leaders in Agile and Lean implementations to be servant leadership and support the teams and change the system and all of that, you can only change the system that you can change. In the end, you can’t change the entire organization. So, it became one of those topics that I am quite passionate about. I guess because in many ways I am the middle manager who went on the journey from management to Agile Coach. I think it is quite achievable and I really try to encourage coaches and consultants to tap into their empathy a bit and try and put themselves in the shoes of these people because a lot of them are living either on the receiving end of a “Go and be Agile” mandate or teams going “We want to be more Agile” and they are very, very much stuck.
There are things they can control and there is a lot of things that they can’t control and if we try to work out why it is that this frozen middle is frozen, then maybe we can unfreeze them. My view is that they need someone who is willing to listen – they can’t talk to their management, they can’t talk to their teams, so they need coaches who are willing to listen, they need a job. One of the things that happens with middle management is we send them on a two-days Agile fundamentals training – that was very much my experience – and that’s wonderful, what am I going to do with that? I know about pairing, I know about test driven development but how is that useful to me as a manager? Well, it’s not overly. So we need to start having conversations with these managers around what we expect from them and teaching them about Deming and Lean and the gemba and all of that so that they do have a role and particularly in the enterprise. In the enterprise, a lot of the role of that manager is how do you help this team of people in the bowels of the organization deal with the rest of the organization that may not be Agile. Quite commonly, I’m finding when I work with organizations, we’re the earlier adopters. It is first few Agile teams, it is the first Agile Release Train, they are just beginning to scale which means you’ve got this little, medium sized, 100-150 people, working together desperately trying to get something done in an organization that is not built to handle people working in that way. They need managers to help them navigate the organization and remove those blockers and get exemptions and whatever you need to do to make those teams successful.
Craig's full question: You mentioned empathy, you mentioned having the conversation, you mentioned some of the Lean principles – when we talk to developers, testers, people who are in the actual project team, quite often the way that we get them enthused or engaged in an Agile journey is because it is going to make their life better or that there is some goal that they will help us achieve. How do you strike that conversation with a manager? Is it the same type of thing? What are you seeing when you apply these techniques to middle management?
I always start with “What is your pain? What hurts?” Then based on what hurts, this may or may not be the answer for you. I don’t know if Agile is the answer for everything. I have yet to find a problem that it hasn’t been the answer for, but maybe it is not. So it is always good to start with “Yes, Agile is what I do. But what is your problem?” And I find that they have a problem of whatever description and you go “Well, these are the Agile things that maybe we can do to help with that.” If you find them resistant, I always just start with something really simple, what’s something that I know is likely to work. “Humor me. Just try this one thing. Let’s see if it eases a little bit of your pain” If that works, “OK. Let’s try one more thing. Let’s see if that eases a little bit of your pain” There has to be something in it for them. We are all human, right? The “what’s in it for me?” factor applies to managers, just as much as it applies to anybody else. So, it always starts with a conversation about pain – what is your pain and how can I help you with that?
9. [...]So, tell us a little bit about your thoughts in that space.
Craig's full question: So, we were both at the Agile Australia conference a few months ago and you have just recently written a post about some of the goings on there, because your organization, Context Matters, is an advocate for the Scaled Agile Frameworks, you are training in that and we have obviously spoken about your history, but as we know, the scaling debate has been something that in the Agile community has raised a number of different opinions and the like. But one of the things we saw was this whole discussion erupt, particularly through different parties and you have been looking at some of that as well as things like Spotify and making some comparisons. So, tell us a little bit about your thoughts in that space.
Agile Australia had the good fortune to have Anders Ivarsson from Spotify and Dean Leffingwell from the Scaled Agile both there this year. It is kind of funny to watch how quickly that became a conversation of people asking these guys SAFe versus Spotify. Dean was very quick to point out that Henrik Kniberg had just been at their class in Boulder doing the SAFe training. We had Anders in Dean’s introduction to Scaled Agile Framework in Sydney and there has been some good conversations going on between those guys and they were asked a question on a panel one morning “How does this work?” and they both turned and said “It is not an either/or. In fact, we are both learning from each other” That really resonated with me because when I was speaking earlier about how we did some adaptions to SAFe and the Scaled Agile Framework and the Agile Release Train concept when we first implemented that, one of the adaptions that we did wasactually take some guidance out of the Spotify framework, particularly because I went very quickly to feature teams with that first Agile Release Train and therefore we wanted a way to try and keep those specializations also connected. So we used a chapter concept from Spotify and found that really successful in creating relationships across the teams.
It also helped us with a view around how do we help create a world in which people take pride in what they do and can be craftsmen, so that whole idea of software craftsmanship. We were very keen to grow a learning community within the team. So, I used that there, I’ve used it since, I worked at another organization whereby they were set up very functionally before they went to a Release Train, again, we went for the feature team model and I needed to keep the leader at that time, she felt very attached to her current leadership team and to make a change we said “they are not your leadership team anymore, your leadership team is this group of Scrum Masters or what have you”. I mean that was just a step too far. I said “Here is this thing, this is a Spotify model and what they do with the Spotify model is the chapter leads are the line managers” So I said “Let’s keep them. Let’s use these guys and make them part of our extended leadership team and that will give you some continuity around your leadership as we start to make the change”. For me, they’ve played really, really well together. In fact, in most places, I will now go into and work on Release Trains we will talk about Spotify and particularly that “community of practice” idea. So “community of practice” is in SAFe and I have also seen in the 4.0 previews that they look like they are going to bring “community of practice” to the big picture. So again, shining a light on that area which I think is really a great move and it has been very powerful for me.
Craig's full question: A lot of people look at the Scaled Agile Framework and they see it as a methodology. There is a big diagram, there is a bunch of stuff behind there, you can read a book. What are your thoughts on that? Is Scaled Agile Framework something you have to deliver, read the book from A to Z and deliver it? Because you are talking about actually using models from other places.
One thing that is very rarely quoted, which is actually in Dean’s second book – “Agile Software Requirements”. He says your organization can and should take only what it needs from this framework, otherwise it is not the simplest thing that could possibly work. And that’s it. Dean is not precious that way, whether you use it all or you do not. He always puts it as it’s codified patterns that they have seen work in the field” For me, the advice I always give clients, if you take the Scaled Agile Framework and just implement without thinking about your context, you will fail. I can’t see any world in which you can just grab that website or grab that book and not think about it and just implement and expect it to work. In fact in many ways, when I look back at my journey, because I started with SAFe before it was called SAFe, I started with reading the books. So I had a very different learning experience about the framework. I sat down, I read a book, I did this with my team and we had conversations every week about “This is Dean’s advice and this is how his framework works and yes this makes sense for us, so let’s do it”, or actually “That is interesting, but let’s do it differently” or “That doesn’t make sense in our world”.
And we went piece by piece through it and made very conscious decisions around what we were going to do and what we weren’t going to do and when things didn’t work, again, we were very conscious around this is what we’re doing, why are we doing it and are we aligned to the principles. I think now you have got the big picture and I think people sort of feel like they can just sort of click here and there and perhaps they don’t always fully understand before they start pulling it apart. So, I don’t think you have to do it all, but I do think you have to know why you did what you did. If you don’t know why you did what you did, then to me, you didn’t actually pay enough attention before you made those calls. But absolutely, you have to adapt it to your context, because context matters, right?
contextmatters.com.au. You will pick up there all our training offerings and what is going on in our world at the moment.