Shane Harrison, business focused change agent specializing in enterprise-level digital Lean Agile transformations, takes PI planning to the next level. Harrison offers tips and tricks on how to execute with a higher success rate.
He advocates for aligning PI objectives with solid plans; socialization is only successful when the teams understand the context and vision of the plan. He says, “I’m always looking for the teams to get into a state of flow…any interruption to the team disrupts the flow.”
For leadership guests at PI planning, Harrison recommends an “eyes open, ears open, mouth shut” approach – an observation exercise rather than interaction with the teams.
Accenture | SolutionsIQ’s Scott Frost hosts at the European SAFe Summit: The Hague, Netherlands.
Read the full transcript
SCOTT FROST: Welcome to another edition of Agile Amped. I’m your host Scott Frost, and we are podcasting today from the European SAFe Summit in The Hague, Netherlands. Today, my guest is Shane Harrison, and Shane is a business focused change agent. He specializes in enterprise level digital Lean Agile transformations. He’s got more than 17 years experience in this particular consulting space and lots of industries. He had a presentation today at the summit to talk about taking your PI planning to the next level. So Shane, tell us about your presentation, tell us what journey you’ve been on that’s led up to presenting here.
SHANE HARRISON: I was really, really happy to have the opportunity to talk about this topic. To me, PI planning is the most important thing in the framework in many ways. I’m an execution guy, so I’m really into the whole idea of strategy to execution. You need to be able to tie everything together, and execution happens in the ARTs, in the teams, in the PI. So I was really happy to be able to do that presentation and to take this … I would say I first started using SAFe in 2012. I launched my first ART, it would have been November, 2012, so I’ve got almost seven years of launching ARTs behind me. It was really nice to actually go out and share some of the tools and techniques that I’ve used with those ARTs, especially the tools and techniques that I use with more experienced ARTs.
The presentation today was great, as it was a much bigger audience than I expected, and they were really generous with their questions and their attention. I was really, really happy with how things went today.
SCOTT FROST: That’s awesome. Over your years, in fact, 2012, that sounds very similar to, I think we were launching our first ART at about the same time, a lot has changed in terms of not only the framework around guidance and PI planning, but also our own learnings. So tell us about some of your learnings over time, tips, tricks, all the things that you’ve learned.
SHANE HARRISON: Yeah, one of the biggest challenges today actually was to try and trim down the very long list of tips and tricks that I use to one that is deliverable in 45 minutes. The one I focused, three actually, I focused on today. One was on socialization. Luck is when preparation meets opportunity, right? I think that was Zig Ziglar, and he’s absolutely right. Socialization is all about preparation, and you’ve got to make sure that the teams really understand what they’re walking into, not just the structure of PI planning because they probably know that if they’ve done two or three, but they really need to know the change that you’re asking them to make, the context in which the change is happening. That’s the only way they can come up with a really good plan.
Today we talked about, the first topic was really about socialization and how important it is, and I tried to put it in the frame that socialization is only successful when the teams can say, “I understand what you’re looking for from me. I understand what the context is, I know and understand the vision, and I believe that I can do a plan. I can create and execute a successful plan.” I put socialization in that context, and I also added a little thing to it, which often doesn’t come up, in that you need to socialize everything in the ART, not just the features. So if you’re changing team structure, if you are changing the ART structure, ways of working, any of those things, the time to start sharing that is not in the middle of PI planning or in the early morning before you start. The time to start that is during socialization, which is typically for me, taking place or starting to take place from the middle of the previous PI, where you can see the wide frame of what you’re going to be doing and what the scope is.
That’s sort of the first topic. The other topic we talked about, we went through a couple of tweaks that I make to your planning walls, specifically designed to increase the transparency about what the teams are doing and what the state of the plan is at any particular time. It’s also designed to make the teams think about the right things at the right time. We add things like a tag on the story for risks, not just normal risks, but we split out assumptions and issues as well. We also add tags to stories on whether it’s an inbound or an outbound dependency, because an outbound dependency, of course, is the mother of all risks, and probably grandmother and great grandmother too, come to think of it. So all those things, getting the teams to think about those sorts of things and putting them on the wall actually allows you to see what the state of the plan is at any particular time during planning, and as an RTE or PM or anyone else, you can assess where they are and decide, okay, do I need to talk to them, or do I let them keep going?
What I really, really look for in planning is I’m always looking for the teams to get into a state of flow. So for me, even though I know this goes against some views, any interruption to the team disrupts that flow, and I really want them to get to a point where they’re in that state of flow, that they’re collaborating, they’re talking, they’re arguing, whatever they’re needing to do. They’re grabbing the people that they need from wherever to actually continue their planning. So if I have to interrupt them, I think that’s a disaster. There is the right time to do it, of course. If you’re doing your formal draft plan review or if you’re doing your final review, yes. But otherwise, we want them to just be accelerating away, breaking these stories down, planning them across the iteration, delivering this value.
That also leads to one of the last messages that was in the presentation, and that is PI objectives are the result of a great plan, they are not a great plan. They’re not an alternative. I looked at an ART a couple of years ago and I got brought in by the management, and they were having problems with performance. The ARTs were hitting in the 50, 60 range, which is not good. I went in and I looked at the PI objectives, and really, they could’ve been written by William Shakespeare. They were beautiful. They’re really just a delight to read. Then when I went to talk to the teams and I looked at the plans, and I thought, “Hold on, am I looking at the wrong team’s plans? Because these plans don’t represent those objectives.”
In that particular ART, the people coaching the ART had really said objectives, objectives, objectives, objectives, and they’d more or less ignored the team’s plans. So making sure you have a solid plan will give you a great PI objective and it’ll actually give you a higher success rate. I’ve had, with ARTs, and this is excluding, for some weird reason, I have a habit of not including stretch in my calculation. That’s probably not a good thing. In fact, it’s wrong according to SAFe, which they are right. I’ve seen ARTs hitting regularly in the 96 to 98% range without the stretch on top of it, so breaking the hundred percent margin pretty much every time. That’s built on really solid plans with well managed and well visualized risk.
SCOTT FROST: So within all that planning and the work that the teams are doing, do you find it difficult to get the teams to walk across the room to find the other team that they need to talk to, or do they really kind of jump at those opportunities? Because oftentimes, I find they’re not … As much pre-understanding they may have, they haven’t had time to really have much discussion with other teams, especially if they’re a newer ART. They’re still trying to figure out, well, who do I even go talk to?
SHANE HARRISON: One of the key things I do focus on in the socialization aspect is from the very early stages of socialization, which is really just a presentation that says, this is the broad area we’re going into, here is our vision for what the features are, we think these features are going to be with this team and this team and this team. Immediately, the teams have a context of where they’re going, and that is part of the discussion, both within socialization and with the PO syncs from that point on. So the POs are talking about, “Okay, what features are you going to be working on? What am I going to be working on? What do we understand?” Then the socialization at the team level sort of further accelerates that. So once you hit planning, everybody knows what their individual context is.
One of the things we actually had to do is we had to put a moratorium of going to other teams for the first two hours of planning because they were all rushing off to talk to each other. We said, “Hey, you need to give the other teams enough time to make some progress before you start rushing off and asking for all your dependencies to be committed.” One of the things we also instituted there is basically like a mini dependency backlog. So if one team has a dependency on another, what they can do is they can go and put it on the wall next to the team so the team has a list of the dependencies that needs to agree later on, and then the team can go to those straightaway.
What I wanted to avoid, well, what they wanted to avoid, because I’m really responding to them, is they wanted to avoid people just wandering in and say, “Hey, can we integrate a dependency right now? No?” Again, disrupting the flow. But we needed to make sure that there was a reasonable response. So what we said to the team is, “Okay, finish the feature you’re on. Then go to your backlog on the wall, work out where those dependencies are, make the commitment, communicate it back to the other team, and then carry on.”
SCOTT FROST: Brilliant. PI planning is often also a showcase, and you get a lot of guests, or let’s say the stakeholders that are around the edges.
SHANE HARRISON: Yeah.
SCOTT FROST: How do you deal with those extra folks coming in, and both wanting to take advantage of learning, but also wanting to maintain the flow, which I completely agree with, for the purpose of the event and who it’s really for?
SHANE HARRISON: Depending on the guest, my response is different. Some guests, like if we have a group, so I’ve been in quite a few situations where we’ve had a group of leaders from an organization who are looking at SAFe, coming in and they want to have a look at and see how it works. Normally in those cases, I will give them a chaperone. This is the person who’s going to take you around, and that person’s role is to make sure that they’re not in the wrong place at the wrong time, and they get to see what they need to see. But generally, the rule of the guest is, in terms of interaction with the team, unless it’s sort of managed by the chaperone, eyes open, ears open, mouth shut. Because we still have to come out of that planning with a solid plan, so please treat this as an observation exercise rather than an interaction.
We make sure that we have time to talk to them afterwards. I ask, get the RTEs and the STE and the other people to interact with those people while they are there, but I do try to sort of protect the teams a little bit from them. But some people, so that’s the people who need a chaperone, people who are new and will have a million questions, and the RTE, it’s usually an RTE who is chaperoning them, will be able to answer most of those. When it’s somebody that we know who is just like a normal person, like a business owner who’s there regularly, but still a guest, not actively doing the planning, they usually aren’t a problem because they have been there for awhile.
I have had a few sometimes where I have to remind them that for most of planning, your role is observational because we don’t want them to disrupt the teams in an ad hoc way. So I guide them and say, “Look, if you’re watching a team, this is great. If you see something you’re not sure about, don’t interrupt them. Go talk to the PM because the scope is coming out of the PM, and if you’re wondering why is that team working on this, that’s a perfect question. Go for it.” But go to the PM first rather than going to the teams because all of a sudden, you do that, and then the team is going, “Well, the business owner said this, but the PM said that, and which one do I do?” Yay, confusion, that’s really helpful.
SCOTT FROST: Yeah, I find having the BOs and PMs very tightly coupled during the event, walking around together, is much more helpful. We certainly want to have business owners, and really, stakeholder leadership in any way because it’s amazing how rare the teams have to interact with them. So we want to provide that opportunity.
SHANE HARRISON: Absolutely.
SCOTT FROST:: But at the same time, right? Actually, we love it when we see them building personal relationships because they make real connections, and that creates a double sort of reciprocating commitment. The more they know the people, the more they don’t overwhelm them as well, with pressure to get more done. I think they sort of see a more human, right?
SHANE HARRISON: Absolutely. I have a philosophy that’s very similar. I think we have the same way of thinking. My view is the PMs will interact with the BOs on a frequent basis. It happens all the time, and maybe with the RTEs as well, and when you’re talking about senior IT or business management, those things as well. I try to advise the RTEs and the PMs, and the POs even, get the teams in front of them. If you’re going to have a demo, if you’re going to have a workshop, you guys see these leaders all the time. Get your people out front and talking to them so they can really get a tangible relationship going. Get a developer to stand up at your PI demo and do the demo. PM, don’t do it. Get, get somebody up there because it will mean a million sort of things to the developer. They’ll just be, go, “Wow, this is so cool,” and it’s great for the stakeholders to see the real people who are actually, some people don’t like me saying this, who are actually delivering the value, the people who have the hands on the keyboards writing the code.
SCOTT FROST: Yeah. I think it’s a good option and there’s plenty of cadence and rhythm and cycles, right, to try it one way, try it another way. I always like when PMs do some of the demoing because then I get the connection that they’re aligned to what got done. But at the same time, I’m with you. I like the old Agile mindset of, those who build, do the demoing, because they’re craftsmen and they want to be recognized for being craftsmen. So it’s good, right? We need them to be able to have that experience.
SHANE HARRISON: And they learn new skills. It makes … Not makes because you’re not forcing them. They’re usually quite enthusiastic. But they develop new skills. They learn how to demo a feature rather than a story, or they did learn how to demo a series of features and they start to learn the language of the business. If you look at business to IT, they could be outnumbering us eight to one. So the thing we need to do is not to teach the business how to speak our language, we need to learn to speak theirs, and that’s at every level. That’s my opinion anyway.
SCOTT FROST: I completely agree, and I think even in this world of lots of contract labor, that’s not any different. If you’re on a dev team, you need to understand the business. It doesn’t matter what your badge says, right?
SHANE HARRISON: Absolutely. It drives me nuts when companies go, “Oh, they’re contract.” Well, who cares? They do the work.
SCOTT FROST: Yeah.
SHANE HARRISON: Where they come from is just an accident. Well, maybe not an accident, but you know what I mean.
SCOTT FROST: Yeah, they are people, they are not, what Simon Sinek, right, better smelling horses?
SHANE HARRISON: Yeah, exactly. I love that term.
SCOTT FROST: So we need them, they’re part of the system. If we’re not optimizing those relationships, then we’re not maximizing the flow of the system.
SHANE HARRISON: Absolutely, and we know that engaged people are up to 30 to 40% more productive. So really, even though you’re outsourcing them, you want them to be fully engaged, you want them to be focused on the value and the business that they’re doing the work for. Just because maybe you’ve outsourced them for whatever convenience, whether it’s a funding issue, or a headcount issue, or location issue, whatever it is, you still want them truly focused on delivering the value for your organization. That means you need to bring them on board and not treat them like they are some sort of other group. Sorry, I have a bugbear about that one. It really irritates me when companies do that.
SCOTT FROST: Yeah, I agree. Let me ask you a couple of other things because I get these questions all the time, so I’m curious of your thoughts. The first one is distributed teams, or let me just say those who can’t attend face-to-face for every planning event. What are some of the tricks and tips you would offer to those out there who are going, “Yeah, it would be great to be face-to-face every time, but in this global world of development, it just doesn’t always work.”
SHANE HARRISON: Yeah, the reality of the real world does interfere with our idealist theory from time to time, doesn’t it? Unfortunately. I differentiate between distributed teams and remote teams. The reason I differentiate is because I actually want to encourage remote teams, if I’ve got to have geographic separation rather than distribution, because then you can have a whole functioning team in an alternative location. Let’s say we’re in London and maybe we’ve got some development, and rather than having three developers in London, two in New York, and three in Pune, let’s just build the whole team in Pune with a Scrum Master and a PO. So I’d rather have a remote team.
SCOTT FROST: Yeah, completely agree.
SHANE HARRISON: That’s better. That’s better than distributed. I find I will go to distributed when the value proposition of the distributed team exceeds the opportunity to consolidate them into a location, whether it’s local or whether it’s remote. In my experience, that’s usually around very specialist roles like business architecture or functional architecture. When you’ve got a solution train with seven ARTs underneath it and you’ve got solution level architectural functions, and you’ve got an architecture team that runs across all the trains across all the ARTs, then you’ve actually got to have a distributed architecture team.
Distributed development teams, I avoid it wherever possible. I just have done side-by-side testing at two customers, and the productivity difference is quite horrifying. A lot of developers say, “No, no, no,” and then we go and do it and then they go, “Oh, oops.” It’s just that, you know, the modern world says you can be anywhere doing anything with anyone, but you actually do the comparison and you won’t like the results.
SCOTT FROST: Well, one of the things I’ve seen is, I’ll call it more of a recent trend, but what I really think it is is just we have enough years experience now with a lot of organizations that started back in 2012 and ’13 and ’14, so they’ve got their sea legs under them. Maybe they started with distributed teams, and then very soon, they moved more to the remote team concept. Then now, what we’re seeing is organizations that have a lot of remote teams within a given ART are now sort of reorganizing ARTs by location, and started saying, “Can we build these geo-located ARTs that are independent? They may have to align with other arts and other locations, but at least within our given ART, we have a lot more face to face, or 100% face to face.”
When they started those journeys, that was one of those can’t touch this, right? But now they’ve done it for long enough and they’ve optimized it elsewhere, and those are the things that are like, okay, well maybe we could. What would that look like, and which often includes supplier relationships, maybe even new Agile contracts. But it begins to, we see a lot more ARTs kind of, sort of … I like it when it’s organic and they’re the ones saying, “We should shift and we think we know how to do that.”
SHANE HARRISON: Yes, yes, yes.
SCOTT FROST: I don’t know if you see something similar but I think we see that.
SHANE HARRISON: Yeah. I find one of the things that’s sort of is a blessing and a curse is this three month to nine month launch cycle. There’s this perception that you can get an ART, or ARTs, or a solution to a target state within, like, six weeks or three months. When you’re using people who are spread all over the world, who have been in distributed teams or remote teams over that time, sometimes it takes a long time to actually rearrange the work so you have some level of consolidation. I think what I like to do is I look at an ART on a three layer or three timeframes. What are we going to do in the next PI? What do we want to do in the next three PIs? And depending on how long your PIs are, what do we want to do at the end of target state?
So we can start looking at things like, oh, well, we need to move the architecture for this application out of New York and into Romania. So how do we do that if we look on a nine month timeframe? And things like that. I think a lot of transformations miss that out to be honest, and they think, “Oh, well, we’re going to do a quick start and then we’re done.” It’s like, no, you’ve done a quick start, and now you’ve started.
SCOTT FROST: Yeah. Congratulations, you’re never done.
SHANE HARRISON: Yeah, exactly. Yes, the change, the never ending change.
SCOTT FROST: That’s right. That word continuous is kind of a key word, right?
SHANE HARRISON: But I’ve definitely seen the trend that you were talking about with where the organizations are starting to do that on their own, which is really good because you start to see them consolidating into locations, and then you don’t have these horrible starting planning at three o’clock in the morning, or staying planning until three o’clock in the morning. You look, Singapore to New York, it’s a 12 hour time difference, and a nightmare. So one of the things I usually try to do is try and get all the elements within an ART within a half a day time zone. So even though we can run PI planning longer, it’s much easier. Try an architect talking to a product manager in New York, so either the architect has just woken up, and that guy in New York is desperately wanting to go to sleep because it’s the middle of the night or whatever it happens to be, or early in the morning. Or it’s the other way around.
We are all human and we all have our own circadian rhythms, and trying to collaborate, try it. I can’t be creative at 10 o’clock at night. I’m sorry, have a great conversation with you, but don’t expect much creativity unless it’s creativity about getting off the phone so I can go to bed. You know? But when you’re talking, whether about business and we’re trying to be creative about solving a business problem, it really gets in the way. You’ve got these brilliant people who we have disabled by trying to ask them the question at the wrong time of the day, if that makes sense.
SCOTT FROST: So let me ask you, I don’t want to miss the opportunity to give you a chance to talk about FlowSphere in your group. Tell us about your organization, where you’re located, where do you like to play?
SHANE HARRISON: We are centered in Switzerland, but we also have a presence in India. The head office is in Zurich and we pretty much work with anyone in Switzerland. We’ve got Sasha, he’s the only SPCT in Switzerland at the moment. We’ve actually got three SPCT candidates in the company, if you include me. I’ll get there one day. We cover all kinds of things, but if you look at it, we’re mostly large and medium size organizations. We’re starting to do a few others, but we tend to be working in pharmaceutical, diagnostics, banks, insurance. We have done quite a lot recently with sort of the mixed mode software-hardware stuff, so I’ve really enjoyed that. I’ve been involved in some of that and it’s really quite entertaining, to say the least.
SCOTT FROST: Yeah, that’s good. All right, well, your talk was take your PI planning to the next level. Shane Harrison, I really, really thank you for taking the opportunity. It’s a really busy conference, so I really appreciate you coming by, stopping by and talking to us for a while. Thanks again everyone for listening to this edition of Agile Amped. If you learned something new, please tell a friend, tell a co-worker or a client about this podcast, and subscribe to hear more inspirational conversations. Thanks again, Shane.
SHANE HARRISON: Thanks for the opportunity. I really appreciate it.