Agile Amped at the SAFE Summit: Tribal Unity & Scaling Human Relationships

At this year's SAFe Summit in San Antonio, Texas I caught up with SolutionsIQ’s Leslie Morse. You can check out our Agile Amped podcast here:

At Agile 2017 I  led a session at Agile called “The ART of avoiding a Train Wreck”, which offered guidance on how to better plan Agile Release Trains in Scaled Agile Framework. After which I had an opportunity to chat with Dave Prior about the session, and my book “Tribal Unity: Getting from Teams to Tribes by Creating a One Team Culture”.

In June, Pretty Agile partnered with Scaled Agile Inc. to sponsor the 9th Agile Australia conference. Included in this sponsorship arrangement was an opportunity to deliver a product demonstration to conference attendees. Given Scaled Agile Inc. are the creators of the Scaled AgileFramework and Pretty Agile are their premium implementation partner in Australia, what better “product” to demonstrate than some of Australia’s most successful SAFe implementations?

So, we gathered together executives from the Australian Tax Office, Yarra Valley Water, ANZ, Attache and Westpac to discuss their warts and all experiences with the Scaled Agile Framework. Here is what happened...

Moderator:  Today we're here with a panel; Damien Hobbin, Julianne Sykes, David Norris, Sam Kline and David Webb. Thank you very much for joining us.

They're in the trenches. They're doing SAFe. They're implementing SAFe. We all know there are lots of rumours and opinions out there. So they're going to try and help us determine fact from fiction. 

I'm going to start out with a couple of questions to the panel. Then we'll open it up to questions from the audience. First I'd like you to introduce yourselves and tell us a little bit about your SAFe journey and where you are in it.

David Webb (Westpac):  Okay I can start. My name is Dave Webb. I'm from Westpac Bank. We've been running SAFe in Westpac for about three years now. I've been involved with most of the Release Trains that we've launched along the way. I'm currently the Product Manager for our trains delivering an Enterprise DevOps platform for the group.    

David Norris (Attaché):  G'day, my name is Dave Norris. I work for a company called Attache Software. We've been around for a while doing Payroll and Accounting software.  I was first introduced to SAFe at IAG, in a large programme of work there. I joined Attache to roll SAFe out through the company, at least through the IT side of the company there. So starting from scratch and trying to get buy-in is a lot of the pain points I went through. It's succeeding. We’re about two years into our SAFe journey.

Sam Kline (ANZ):  My name is Sam. I come from ANZ. I run the Analytics and Insights team there. We're just coming up to our 12 month anniversary for our SAFe rollout. We have one, Agile Release Train. We started with about 60 people on shore. We're now about 70 people on shore and 40 people off shore in Chengdu. Plus we've got about 20 to 30 partner people running with us. So we're roughly 130, 140 people in our Release Train.   

 It's been a pretty amazing journey over that 12 months. Lots of war stories. Lots of personal learning, as we've gone through that. Both myself, our leadership team and the people actually on the Train. There's a few of them here as well.  It's been a fascinating story and a pretty amazing 12 months.

Julianne Sykes (Yarra Valley Water): My name is Julianne. I work at Yarra Valley Water. My role there is Manager Portfolio Delivery, and I'm currently the acting CIO.  Our SAFe journey is twelve  months old. We've just completed our fourth PI Planning Event. We have one train, with about 120 people. We deliver the entire ICT delivery programme for Yarra Valley Water. All of our major enterprise applications, we are enhancing and modifying and developing through SAFe and Agile.    

It's been a really good journey for us and I'm looking forward to sharing our stories with you.

Damien Hobbin (ATO):  Hi, I'm Damien Hobbin. I'm an IT executive with ATO. I head up a Digital Delivery team looking after the  some of the key retail offerings for the ATO, hopefully you've heard of some of them - ATO Online, MyTax, which I hoped you've used. If you haven't I encourage you to.  I'm also a champion and advocate of what we call Agile HQ. It's about driving enterprise agility, and  how we drive agility not just through IT but across the organisation.    

 We've been on our SAFe journey for close to three years now. I've been hands on with three Release Trains and there's at least eight in the ATO. It's been an interesting journey and quite a ride. We've got a lot of information to share with you, equally as we  also  share our learnings and ideas across Government as well.  We're seen within Government services as one of the leading adopters of Agile and SAFe in particular, so I'm here to happily answer any questions that you've got.

Moderator: It sounds like we have a little over 10 years of collective experience of SAFe in the trenches.  If you had to pick three factors that have contributed the most to the outcomes you have achieved in SAFe, what would they be?

Damien Hobbin (ATO): I think for me, PI planning. The whole concept of PI planning has been one of the highlights for us. We've seen our teams actually produce better plans. We've seen better connection with our executive stakeholders and we've actually seen greater team engagement. So that's one of the biggest highlights for us. Just to bring that sort of discipline and to bring people together.   

Product Management is another. The concept of Product Management was quite foreign to us. It's something that has really taken hold and grown. We initially struggled with the definition of it, in fact I think one of the Keynotes this morning, also touched on that.  Bringing that consistent engagement and  business view to delivery. Client centricity, that client focus, is really important for us. 

Putting agile principles into practice is probably one of the biggest things to tackle as we're a risk adverse organisation and have been known as being quite risk adverse in the past. Just applying continuous improvement, lean agile thinking practices has been quite revolutionary for us.

Julianne Sykes (YVW): Some practical things that I can give you some advice on. The Change Management and Executive support. You can't underestimate that when you're applying Agile or applying SAFe. This is actually a significant business transformation, and you need to get that buy in from the top.     

Train everybody so you have a common language. A common connection. A common dialogue. And everyone is on the same journey and committed to it.

In terms of it being a significant transformation is also creating a team that will help drive and implement this within your organisation. So don't underestimate the effort and the energy required to transform to Agility or into SAFe. I guess the other thing that was a success factor for us, was seek support and assistance. Great Agile coaching to support your transformation and journey and getting one of a common language and agility. That's my three.

Sam Kline (ANZ):  Similar themes, but the three things that I'd call out are; We spent three or four months really understanding what the demand coming into our team was and really reshaping that. Prioritising, kicking out stuff we shouldn't be doing. Bringing out the dead if you like, or just the BAU stuff our teams were doing that wasn't really adding value. That was a really intense process but I think that was probably fundamental to us then being able to set up the squads and protect the squads to work on the most important thing, as we implemented our Agile Release Train. That work up front to really understand our demand, force rank that list and then allocate those to the squads to deliver was probably really fundamentally important to our success.   

The second one I'd say, we didn't go half-baked . We didn’t just try this on one team and then another team. We made a commitment as a leadership team. We trained together. We then trained the whole group together and we all went through that journey really quickly.  We say we went Agile in a week, but there was a lot of work up front. All the demand work, up front first that allowed us to flip the team in a week. So it was all in.   

The third one... we now have four squads in Chengdu and they're set up as end to end squads. They are part of all the rituals that we have on-shore, through telepresence etc. We made a real commitment to setting them up for success. I'm sure that most you could identify offshoring models that don't work all that well. And we had one of those to be honest.  The commitment we've made with how we set those squads up and how we interact with them in the Release Train has been fantastic. Those squads are absolutely shooting the lights out. They're fantastic. So, that real commitment we made to setting them up was a key part of our success.

David Norris (Attaché): For me the three things are… Autonomy or depending on the nature of your role the buy-in of the leadership team is absolutely critical. It's hard to make the change. One of the speakers yesterday was saying it is difficult. Well SAFe is no different, it is difficult. You're going to have people who resist it and buck the process because they struggle with change. You have support them and push through. Without the autonomy to make the decisions or without the buy-in from leadership you're going to struggle.  

You really need to trust the model. The model works. SAFe works. You need to back the model, but to do that you need the coaching. You need the training. And maybe, contentiously, I'd say don't try to do it all at once. You have to convert the whole team into the Train straight away, but don't try to do every single Agile practise, every single part of the SAFe model on day one. You just can't. You need to take the baby steps. There's a whole lot of them. You need to do the Agile thing. You need to iterate. You need to fail. You need to learn. You need to kaizen, kaizen, kaizen. Expect a lot of small steps in the journey and get a good coach to help you through it.

David Webb (Westpac): I tend to agree. I think the training's really important. Particularly in my team we did the quick start approach for SAFe, which is two days, training, two days planning and then a day's training for the Scrum Masters and the Product Owners.  I could only recommend that as the approach that you take to get the best momentum coming out of your first planning event. So, that's something that I would call out specifically.  I think that gets you to go and do everything at once, but don't try and do it perfectly. Don't aim for perfection.

Another thing that's important is to invest in your people.  You need to make sure that you're building capacity into their sprints for innovation, so that they can do some cool stuff while they're going. A lot of that is used in build teams to start adopting devops and CI/CD.  Build capacity into the teams so they can do discovery for the next set of features that are coming through is equally important. I've seen a few teams that are very focused on delivering the features in a PI, less interested in planning for the next event. I can't tell you how important it is to allocate that capacity.   

If it's a new team, building some discounting in their capacity in the early sprints if they're new to SAFe, assume 50% discounted capacity in their first sprint. Then for their second 30%, or whatever works for you. But you need to allow the team to get some runs on the board to be successful. It's just so important.     

The final thing that I would call out is to find good Servant leader. The good thing about SAFe is you're actually getting the doers onto your train and you're pushing a lot of the management out. A lot of the overhead, a lot of the fluff. The leaders that do come in, you want them to be good servant leaders. You want them to protect the train. Protect the resources on the Train. Sometimes it's hard to find people that are good at that.

Moderator:  Let's open it up to questions from the audience

Audience Member 1:  Thanks for sharing all your stories with us. I'll just start off with a cliché of purity vs pragmatism.  We've been ... especially with SAFe version 4 we've added another layer to SAFe how do you guys deal with that? Common sense prevails or do you have to stick to the model to be successful?

Damien Hobbin (ATO):  I'm quite passionate about what you call purity. Fight the purists because that's really not what it's about. SAFe is great. It's a great framework and it provides a lot of guidance. But you've got take what works for you. You've got to use it for what context it provides in your organisation. Overlay your culture. Overlay where you know you're at. Use that.

It is a framework. It's not a rule book. If you've got purists in your organisation who are going, "that's not agile" well, I'd probably call out that is the point. It's about taking people on that journey, to working through continuous improvement and taking those steps into insight. Coming back to investing in people, how do you actually get them to move forward? So, if you've got those hard line purist going, "that's not agile" your actually not helping people go on that journey with you.

David Webb (Westpac):    It's a bit each way. You have to do a bit of both. If you want to be a purist, then you shouldn't be having off-shore teams. The reality of the world is, the operating model we have in a number of our organisations in Australia is very difficult to do that. There are some things that just don't work for organisations based on operating model, and hierarchy and structures and things like that. 

The SAFe framework, the recipe I call it, is really easy to follow. I think you should try to stick to the formula as much as you can. The more you deviate from that the more you get lost. It gives you really nice cadence. Gives structure that gives the team focus. And I think that most people who go through SAFe for Teams training and then go into planning for the first time really come out of it with a huge buzz.   

Sam Kline (ANZ):    I completely agree and as a rule I find it a balance between an organisation thinking they're special. Like, "oh no, that doesn't apply to us" and having people like Em telling us to pull our head out and actually, "No, you're not special. Follow the rules”.   

You do need to tailor it to your organisation as well. It's got to work for your team. Having someone external to come in and tell you, you know you're not special and this works at Westpac and everywhere else. In different industries and different products they deliver is really important I have to say.  It's really a fine line and one of my recommendations is that make sure you've got someone objective enough that's pragmatic enough to tell you without egos involved, where your deviate too far.

Audience Member 2: How do you approach governance and funding,? Do you fund trains rather than projects?

Julianne Sykes (YVW):  It's actually a challenge. To be honest, Yarra Valley is a Government organisation and we obviously have compliance requirements. It's actually a work in progress. Like all things Agile. We're inspecting and adapting and continuously improving to try and work it out.   How we've done it at Yarra is that we fund the Train in PIs. Every quarter, we get approval deliver a programme of work. And that has worked for us.   We've written business cases for the PI, but it is work in progress. We still do perhaps write business cases at an Epic level and we need to look at that. To see if it's still the most efficient way of doing it.  If anyone's got it nutted out, I'd like to know because I think it’s a work in progress across everybody.

David Webb (Westpac): We haven't solved it to the level I would like us to get to. I think version 4.0 brings in Value Stream and we don't really have any Value Stream up and running in Westpac yet. It's absolutely something we're looking at doing. Once you get to Value Stream, it's a much easier conversation to have.   What I can tell you is that we've been able to keep our Trains afloat. We've got stable teams. They're the things you really need to focus on the most when you're looking at Finance and how you are keeping your Trains going. That's really what we've been focusing on generally.

Damien Hobbin (ATO):  We are the Kings of Financial Year planning and twelve month planning cycles. That is our reality. But we work through Capacity Funded Release Trains. We do have the early seeds of a Value Stream. I don't think we've fully articulated what the Value Stream means but we try to live the structure that SAFe provides.  We've had the same issue around how we fund capacity over a twelve month cycle. At some point we've got to get beyond that so that we are funding value and the organisation commits to funding continuous value.    So I think for us, we had an early challenge in that we needed to demonstrate value. We had to deliver. And we had to deliver and that then created some of that momentum towards capacity funded model. We've done this three years in a row with our people and trains capacity funded.. The challenge is funding the Value Streams and continuing to refocus that.

David Norris (Attache):  I'm a little bit different to these guys, in [that] Attache only has 100 staff. We're not a big bank or a big Government institution. But we've got the same kind of problem. We need that ROI on projects. I had the freedom to approach it from reverse.  "Don't worry about any of that for now, because all productivity is going to go downhill as we start a new process. So just give us some time and let's see what happens".    As it started to stabilise and velocity stabilised I now know that it cost us an estimate of about $1900 per point. So when we estimate or size a piece of work and we multiply our points, we know roughly what it's going to cost. When we look at velocity we know approximately when it's going to land.     So we can still do full ROI on projects and features but it did take a little while, to be able to say, "Don't govern us yet. Govern us later." We couldn't have done it from day one. It would have been impossible.

Audience Member 3:  Did you come from an Agile background or was Agile new to all these teams? And why did you choose SAFe?

David Norris (Attache):  I was introduced to SAFe at IAG before I joined Attache. For me going to Attache and putting SAFe in was really hard. There are developers that had been there for 30, 35 years. One of them, he wrote the original code base in 76 and he's still there. Those people, do not want to change. They will say anything they can to get out of it. Saying, "You can't build 'C'”, “It can't be done in Agile” or “you can't just give me a little snapshot of the requirement, I need to know every little bit of code that it's going to impact so that I can actually work through and do it properly."    It’s hard. It was really hard. I was all for SAFe. And they were absolutely not. They are now, but that's just constantly pushing, pushing, pushing. Guiding, guiding, guiding.

Julianne Sykes (YVW):  At Yarra Valley Water we had one team. One Agile team. And then we scaled up to SAFe. Why did we go to SAFe?  A couple of things for me. So being a Government organisation, SAFe is a framework. And so you can draw upon the framework when you're talking to your executive about why would you scale up? Why would you go agile? Why would we go SAFe? It's about saying it's a framework. It's guiding principles we're not just making this up.

The other thing about why SAFe for me. So you can have Agile teams, but for me you can still have Agile teams operating in isolation. There's still a team. An Agile team.     What SAFe does for me at scale, it actually gives me a team of Agile teams working on cadence. Working with consistency, driving to a common mission and a goal. And the power of that, we have seen at Yarra, we have 120 people in the room, the power of the collaboration. The energy in the room is absolutely amazing. The commitment to delivery is amazing. The ability the share skills and capabilities across Squads has been one of the greatest assets of scaling.   

We've seen over our journey of four PI's, where at PI1 maybe we still had people planning still slightly in isolation. But what we see in PI4, what we see now, is someone in the Team A calling out and saying, "actually we've got a shortage of a some resource. And Team 'B' says, "we've got capacity in sprint three". So you see that sharing of skills, across the team.    

The Dependency Management again across Squads. Again there's a conversation about, we've got to deliver this in Sprint two and then we need to deliver something in Sprint four. That Dependency Management identification early on, collaboration, that's been the power of SAFe. So that's why we've gone SAFe.

David Webb (Westpac): We have had a mix. We don't all run SAFe inside Westpac. We have based our Agile Execution framework on SAFe which is a good thing for us.   Have all our teams had Agile experience? No. We have a number of Release Trains launch with nobody joining any of those teams having any Agile experience except for the Coach and a couple of seeded Scrum Masters. And they've been just as successful as teams that have had experience going in as well.

Audience Member 4: How do you define Value streams? Can you give us an example? And who's responsible for your Value Streams?

Damien Hobbin (ATO):  We do have a Value Stream Management Group in place. We do have a Value Stream that is aligned to what we call Online Services. So it's not true Business Value. But the SAFe framework gives us that ability to try and align the organisation to what they see as value. We're on an evolution there and I think we still need to work through that. 

We didn't get the organisation at the highest level to define what that Value Stream was and that's part of our learning and part of the gap that we've had. It comes back to Portfolio management. The Portfolio management cycle for us still has Waterfall processes being applied. Everything from security, enterprise testing to our funding models. So we sort of have these slow running waterfall processes up front. How do you then try and get alignment from the organisation portfolio at a Value Stream level?    

It's not perfect. We're not there. But again coming back to principles, we just try and iterate that through in how we  aligned it to our  online platform.

Audience Member 5: I just want to know some of your stories, some War stories about how you have set up frameworks to enable your people to innovate and also experiment as well? I'm just keen to understand what you guys have done to drive that agenda?

David Norris (Attaché):  So it's fairly common to do Hack days or Hack-a-thons and we're no different. We've introduced those and they work really well. But I've found something more successful, for us. I think it's because a lot of my staff struggle without direction. If there's a blank canvas, they will look at it all day. With a little bit of direction, then they seem to prosper.    

I've found that the Hack Days and Hack-a-thons are a little bit open ended. So I've changed that. Not changed that, I run those. But I also run these three day things that I call an Awesome Challenge. It's within their team. They’re  still project related themes but they're just a high level outcome. They can do whatever they want to try and achieve it. They've learnt a few lessons along the way. Like, don't cut out testing.   

I then get them in a room. They present to each other. They vote for each other and there's a winning team. So it stays within the team environment. It stays within the projects scope, largely speaking, but big goals. Three days and they really prosper far more than just having a day to go nuts and do something. So it's really worked.

Damien Hobbin (ATO): I think it's really important that you come back to Culture. You have to create that environment.  I live in a world where Delivery is relentless. Many, many partners are trying to deliver across  many segments of the Tax system. So how do you create space where it's actually okay to innovate and embed that to be part of your DNA.  I think that's where it comes back to that strong circle of leadership. For us, it’s actually connecting with our teams and saying, "it's okay. I expect you to be able to create space." Protect the team and carry overhead and capacity within the team to innovate. Because if you don't, you're just going to burn people out. You're not taking them on that journey. They've got great ideas, so how do you actually tap into that and bring that to life?  The best way to do it is to say it's okay, you've got time and space to innovate and I expect you to do that, provide executive support to make it a reality.

David Webb (Westpac):    We keep room in our IP sprint for innovation. We also give each person 10% of their capacity for innovation plus one day in the IP Sprint they get to do simple stuff. We encourage them to bring that innovation into Spring demo. I think another way address that, is to show the team you're more than happy to bring the findings from that into feature into production.

Audience Member 6: I'm interested in what are the metrics you're using to calibrate the success firstly of your Trains and then overall the success of SAFe in your organisations?

Sam Kline (ANZ):  We've got couple of different things we do. Firstly on our people end. Do our people recommend our team as a place to work? Using the internal net promotersystems/score. We base lined that back in July before we rolled out our Release Train. It was horrendous. The score was negative 48. We knew it was bad, but that was a real kick in the teeth. But that's part of why we do it, right? And it was absolutely a fair representation of where the team was at, at the time. We re-scored in November and we were at negative 35. So we had jumped 13 points in a few months. And we did it at April just gone, and we are at negative six.  So, we're not happy that we're at negative six, but the fact that we've jumped 42 points in nine months is a phenomenal trend. Upward trend, in recommending ANZ as a place to work. It's really, really pleasing the trajectory. But being a negative is not where we want to be, so we want to keep that trajectory going. So that's one thing we do from an employee satisfaction perspective.   

We did a similar with Stakeholders. So we service who knows how many, 50 different sort of teams across Australia Retail,  Australia Corporate and Commercial banking as well. So we have a good range of Stakeholders therefore we do a really broad range of work. But we can only ever do about 20% of what's being asked of us because we know how much we're oversubscribed, every 10 week period.  We've done an external NPS. It wasn't as bad as the internal one. But we haven't re-checked that yet. The informal measure is at Showcase. At the end of the 10 weeks we do a Showcase where we report back our work. The feedback from the people who actually get work prioritised, is that they love the Squads that they've worked with and the products that have been delivered at the end of it.  We do a fist of fives at the end of it. And that sort of averages out at 4 out of 5. So we know that that's trending well but we haven't got a quantitative measure on that yet.   

One of the key things we used to try and measure is capacity and how we're delivering. But that has sort of dropped away. It's a pretty amazing story. That we can actually say that we started with 338 story points on our first PI. We've now got 640 story points every 10 weeks. That's not throwing more  FTE people at it, it's just taking work out that wasn't valuable. That's setting up the teams, getting more efficient. Turning the opaque off-shore Chengdu team into Squads that were part of it. We can actually measure and track and tell that story as well. So I guess there's different metrics you can use for different parts of the story if you like.

Audience Member 7: My question is to do with choosing SAFe over the other scale Agile frameworks. Did you consider anything else? Have you experienced anything else? And I'd like to understand what criteria you use and why you chose SAFe?

David Webb (Westpac): I wasn't around when we did the assessment, but I know that we did do one. We trialed a couple. SAFe seems to be the one that teams have embraced and adopted more broadly across the organisation.

Sam Kline (ANZ): We did look at other models. Partly because we're a Data and Analytics team, so that engineering aspect ... we liked that it was a framework. We could see where we fit in it. And follow the rituals that ... some of the community support both training and websites and things, were fantastic. But probably most powerful is, we saw it in action. We went to Telstra and saw it in action. And went wow. It was a pretty amazing experience to see something like that from theory in action. That was pretty clear for us that we were going down this path and that SAFe was the one we wanted to go with.

Damien Hobbin (ATO):  I wasn't around when the assessment was done. In a Government context, the bureaucracy and hierarchy is quite prevalent in how we operate. So having the framework there to help guide you and have the conversation helped, definitely. It's probably one of the best elements of SAFe.  Prior to this we've had many small Agile teams and pockets of Agility in the ATO, across our Development teams. But it's really just IT agility. How do you actually bring an entire organisation along? We need to focus on Enterprise Agility and bring the organisation along with you. It's really, really important and it’s a great framework to help have that conversation within context.

David Norris (Attaché): As I said before, we're a bit smaller than these guys, and when I first asked Mark to come in and have a look, he said we're a bit too small for it. But what I really valued in it, apart from scale by bringing on another head count, you bring on another team, which we knew we were going to have to do in time.     What was really critical for me, with less people you can't have a Front End Developer in every team. You just don't have that many Front End Developers. We can't have a Data Base Specialist in every team because we don't have that many. But then we can't have the Dedicated Systems team, because we don't have that many.  The cross team dependency, the ability to move the work between the teams, no the people to work, was key. Particularly when that's coupled into desktop software. So we can't just roll something out every hour. So all of those teams have to work to an absolute common goal. SAFe just had everything for that to happen.

Moderator:  I'm going to ask two more questions of the panel. If you knew then what you know now, what would you have done differently at the start of your journey?    And if there's some people in the audience who may be considering implementing SAFe, what one piece of advice would you give them?

David Webb (Westpac): If I knew the power of self-selecting teams and the ability that gives your team to be much more cross functional than it is. Than getting a bunch of names up on the board to get a Train launched. I would have got the guys in a room and tried to say, "this is the teams. This is the work we're doing. Go forth and work out who's going to do the work".    As we've gone on the journey in my Train, we've just seen this natural movement of resources into teams of people that are much more happy working with each other. And we're getting a lot more cross functional in the medium capacity of the team. So that's something I'd like to call out.

Sam Kline (ANZ):    I find this a difficult question to answer ask as we're on this continuous improvement path. So, we're always trying to fix things and adjust. But probably the one thing if I had my time again, is that I'd be more bold with the enabling features that we need to develop to set ourselves up to continuously serve our Stakeholders. I guess ... and that's because we've come from a bit of a history of just being order takers from all these Stakeholder teams.     Whereas, we wanted to turn this around and say, well as Data Analytics, you know how the world's going, we should be on the front foot and really driving on the demand and influence the conversation. So I'd probably be more bold in how we  put ourselves forward and what we did. So we shape the work better.

Damien Hobbin (ATO):   I think for me, start at the top. You've got to get buy in from the top. I think we've been driving a lot of this from the bottom up. We missed an opportunity to align our cultural re-invention with exactly what agility is all about.  Be generous with your colleagues. Be generous with your business. Use language that makes sense to them. Help them come on this journey. Be resilient. Keep explaining to them why, why you're on this transformation, because it's not always just about being fast, first to market. It's not just about being agile for the sake of being agile. There's so much more to it.

Julianne Sykes (YVW):  The one piece of advice that I'd give you, and I think I touched on it before and you just mentioned it then. Is find your platform within your organisation as to the Why? Why are you doing Agile? Why are you doing SAFe? What would the benefits be to your organisation. Train everyone so you have a common language. Get the executive buy-in. Because this is business transformation and if you don't have support from the top it's going to be an uphill battle. And everyone that's got the common language and understands what it is. That's my piece of advice.

David Norris (Attaché):  Get help. Get some coaching. Training is not enough. Going away and then thinking you can come back ... you can't do it overnight. So get the help, get the training, get the coaching. Expect to have to reiterate.

Moderator:    Thanks so much. Thank you to the panel, I appreciate it. Thanks for everyone listening.

Check on my musings on Agile2017 on TechBeacon - Women in Agile, "The Spotify Model" and more!

Highlights from Agile2017: Gender, diversity—and lessons from the agilists

One of the things I love about the A&I Agile Release Train is their drive to learn. Following the Re-Squadification day the train held a focused retrospective in order to understand what had gone wrong and how they could avoid a reoccurrence of a long drawn out self-selection process in the future.  The insights were fascinating. There were three main drivers of the stalemate - a belief the teams of 6 or 7 would not be effective, “feature pitching” by Scrum Masters and Product Owners and people trying to do the right thing!

The frustration with team size I put down to a combination of decisions being made behind closed doors and lack of communication. Deciding the team numbers was perceived as a logical decision that didn’t require wide consultation. In hindsight I am embarrassed I didn’t think to suggest to the RTEs that they take the suggestion to the train before communicating it. Or even better involve the train in making the decision in the first place. It was naive of us to assume the teams would not have strong opinions regarding team size. I wonder if subconsciously we feared retaliation, as despite being three PIs in there were still fierce debate across the train regarding the need for component teams. In reality we just didn’t have holistic buy in to the feature team model.

The “feature pitching” was frustrating. Based on the learnings from the first self-selection event we had tried to remove the “work” from the decision but we probably had not been explicit enough in that respect. Teams were recruiting members based on the features they intended to pull. Again, I fear communication had been our downfall.

The third cause was more interesting and somewhat unexpected. In line with Sandy and Dave’s guidance we briefed the train to consider the best interests of the company and the train in making the team selections. As the day went on, we came back to that message time and time again but it didn’t seem to make any difference. When the leadership dug into this post the event, we learnt that team members were staying put because they believed that their membership of a specific team was in the best interests of the company!

I also felt that “absentee voters” had been a challenge. In almost every case the person who was not present had given a specific instruction about what squad they wanted to be in and their proxy did not feel empowered to move them.

The opportunity to use these learning came around sooner rather than later, as the addition of some new delivery partners meant more teams on the train in PI5. Feedback from the last self-selection event indicated that the train valued the ability to do self-selection, however, they were not in a hurry to do it again! Wanting to empower the train, the leadership put it to a vote: Should the train self-select prior to PI5 or should the leadership team make the required changes and inform the teams of the outcome?

The result: self-selection with a tie-breaker process was the most popular option.

In discussing this outcome with some of the leadership teams, another lesson emerged for me. We were talking about possible tie-breaker approaches. I was reiterating my position about avoiding management intervention when one of the managers pointed out to me that  is the role of leadership to support the people who do the work (as I am so fond of saying!) and therefore if the teams can’t work out how best to organise it is incumbent on leadership to help them. When it is put like that I have to say I agree. We went on to talk about what form that intervention should take, as I still felt the approach was not quite right the first time. He then went on to share with me the actions the teams had agreed following the re-squadification retrospective.

1. Chapter Leads would brief their teams prior to the event and provide guidance on the competency mix expected.
2. SMs & POs should not use the features that want to work on as a way of encouraging people to join their squad. (Feature decisions should be made by the whole squad once it is formed).
3. There should be a tie-breaker process if a stalemate occurs. The suggestion being that chapter leads for the unbalanced competencies would provide some real time coaching in the event of a stalemate.

This time A&I would run the event themselves, which was another excellent outcome, even if I do have to admit I was suffering a little bit of FOMO.

When it comes to the results, with permission, I would like to share with you the email I received post the event.

Hi Em 

Thought you would be interested in hearing about how self-selection went yesterday. 

Pre event:

• I shared a pack the day prior to S-S that included your suggested things that team members should consider when selecting squads. This pack also included a details of the squad construct we were looking for. 
• Chapter leads also spoke to their respective teams prior to S-S.
• The approach I took with my chapter was to encourage them to have a plan A and a Plan B as well as keeping an open mind on all options – “whichever squad you land in, you will be working with great people and will have learning opportunities”
• I briefed POs and SMs to be very clear that they should talk about themselves, their style/approach and generally how they go about it. I also gave very clear steer not to talk about features.

At the event

• [The Head of] did an intro – very authentic, expressed a view that he felt anxious about how it might go and acknowledged that this would be the sentiment of many. He also reinforced that it was the train that voted to do the self-selection again (which is a good thing)
• I shared overview of process – I highlighted that the retro we did following the last S-S had defined a “tie-breaker” process if we reach a stalemate on balancing the train, but also highlighted that we really wanted to only use this as a last resort and expressed my confidence that the Train should be able to solve it.
• POs&SMs did a great job of making their “pitches”
• Started with a 15 minute round – after that round we had some “unders” and “overs” – I summarised the challenge that the train needed to overcome to balance the train
• Second round was 10 minutes – Got closer, with the outcome being to only require one final move – as I was playing this back a team member volunteered to move (under no duress)
• Congratulations to team on balancing the train for PI5 and beyond

 We will pull together the retro feedback, but a couple of themes that I observed that I think really helped.

• Having a target construct really helped – in the past we have said “a minimum of x  of one skill and y of another” – this time we were definite in construct we were aiming for
• Room set up – this was more by luck rather than by design. We had a relatively small room, so I facilitated “in the round” – there were no tables or chairs, just flipcharts dotted around the outside of the room. I think this really helped with the energy and dynamic in the room and forced people to stand by the squad that they had chosen in each round. This really made facilitation relatively easy.
• The only negative was that we overlooked bringing our partners into the process – whilst they could not really select to a squad (that has been pre-determined), they could have participated in the social contract drafting etc as well as going on the journey with us

 Thanks a lot for your guidance – I think that whilst we have probably invested significantly more time up-front in planning the event this time around, we have landed in a better spot.

Three PIs after the 6-Day Quick-Start it was time to “re-squadify”. We had promised the teams during the initial self-selection event that they were not making life long commitments and that they would again have the opportunity to self-select in two or three PIs time.

Over the preceding 6 months there had been a lot of change. The original 6 squads had been reduced to 5, as result of some parental leave and secondments. We had onboard two new squads based in China. The interns had moved on to their next rotation and there had been a few leavers and joiners, as is natural with any new Agile Release Train.

Re-squaditification presented the opportunity to revisit the constraints within which the teams would form. Specifically, we decided to look at team size and the approach to Scrum Masters and Product Ownership. The two squads in China had been through a small scale self-selection day just prior to the beginning of the last PI,  so we decided not to disrupt them and leave them out of the  “re-sqaudification” this time.

When it came to team size, we wanted to avoid any nine person squads emerging from the process this time. A quick count of existing team members, new interns due to arrive imminently and current vacancies, quickly led to the conclusion that five Melbourne based feature squads would not work, we would need to return to having six feature teams. Three teams of six and three teams of seven. This meant even if all the existing Scrum Masters were to agree to continue as Scrum Masters we would be one short. Luckily the train had created a “bench” of potential Scrum Masters (SMs), that has been included in various training opportunities over the life of the train and were ready to step up when needed.

With Product Ownership, a variety of maternity leave and other role changes meant that there were no longer any Leadership Team members in Product Owner (PO) roles. From my perspective this was not a bad thing. Despite everyone’s best efforts, the POs being so much more senior than the SMs had created a weird team dynamic. Instead the POs would primarily be senior Analytics folk. The Analytics competency also had carriage of the interns, each intern was paired with a senior Analytics PO. We then designated the three teams of seven to be the ones with the interns. This time the RTEs were also determined to be more inclusive and opened up the opportunity for the two System teams to self-select as well.

With the scope and the team shape determined we now needed to decide how we would seed the teams. We definitely wanted to avoid the feature anchoring that had been so problematic last time. We decided that SM and PO pairs would be the starting point for each squad. We would then allow the newly formed squads to pull in the features that they would like to work on.  We just needed a way to pair up the SMs and POs. Then I remembered an approach I had heard about from +Mark Richards and +Andy Kelk  - SM & PO speed dating! What fun!

(While I was not onsite for the speed dating event the RTE tells me: “It was as brilliant. Lots of fun. Great energy. Everyone paired up really well and we saw some really great dynamics of these pairings come out across the PI.”)

The last piece of the puzzle was the competency mix - this time the instruction was that each team must have at least one person (excluding the SM and PO) from each competency.

As we had done previously we structured the self-selection day with the morning being the self-selection event and the afternoon being set aside for team building activities.  The day kicked off nicely, with the new department head reminding everyone why the train had chosen to use self-selection. Then each Scrum Master and Product Owner pair pitched to the train, what life on their squad would be like.  Then we reminded everyone of the constraints and got started with the self-selection workshop.

At the end of round one we had three teams of 8. So much for no team larger than 7! In Round 2 there was no movement. Round 3 was extended twice (at the team’s request) but when the time ran out we still had two teams of 8.  In round 4 another move got us to one team of 8 and one team of 5. In round 5 and 6 there was again no movement, so we decided to break for lunch, hoping some casual conversation over lunch would result in the compromises needed. We had one more round after lunch which after two 10 minute extensions did not result in any changes. So we called it a day and sent everyone home.

At this point I was feeling very average. Everyone was so frustrated. We had a particularly large room for the event as we intended to follow up the self-selection workshop with a number of team building activities. This meant that as people became uncomfortable with the tension created by the lack of movement, they would wander off to the other side of the room. During lunch various team members tried to talk me and various leadership team members into intervening and breaking the stalemate. “Don’t you have a game or something we could use?” I was loathed to intervene, it just didn’t feel like the right thing to do. Of course, a lifetime of working in leader decides environments meant that it was natural for the the team to still have moments where they want a leader to intervene and just "tell us" the answer. It was challenging and awkward for all involved.

Then a little bit of magic happened, a subset of the train stayed behind and kept talking about the problem. Facilitated by some of the more junior leaders, they worked the problem for just shy of 2 hours before landing on a solution that met the constraints! It was truly amazing.

For me reflecting back on that day, I wish I had been more prepared for the possibility of a stalemate. I kept thinking to myself that Sandy and Dave’s advice is to stop when a stalemate is reached, the problem was I couldn’t tell if we were at an impasse or not. The small moves in rounds 3 and 4 had given me hope and using the lunch break to try break the deadlock seemed sensible. Perhaps my largest mistake was allows the train to extend the last round so long. In the end it was 30 minutes and inconclusive.

While writing this post (and beating myself up) I decided to go back to Creating Great Teams to check +Sandy and Dave’s guidance on stalemates. Much to my amusement their suggested approaches are 1) stop and call it a day, 2) reduce the number of people involved to focus in on the problems or 3) add placeholders for new hires into squads short on skills. We had considered option three as part of the constraints and dismissed it as we weren’t really sure when the new train members would arrive. And of course, suggestion 1 is what we tried and suggestion 2 is what the train did. If nothing else it is nice to know there wasn’t a magic answer sitting in Sandy and Dave’s book that we quite simply failed to use!

Find out what we learnt from this expereince and what happened when the train had to decide if they wanted to do self-selection again in my next post: Learning from Re-Squadification.

Share this with your followers on Twitter

Updated 6 February 2024 to reflect SAFe 6.0 terminology.

The schedule for the two-day PI Planning event, days five and six of the 6-day quick-start, was pretty much textbook SAFe. Given I have blogged about PI Planning in the past, let’s skip the blow-by-blow description of PI Planning and focus on the highlights from this particular Agile Release Train's first PI Planning event.

Firstly, the opening messages set the perfect tone for the 2-days. The RTE opened the event: "It’s been an epic few days, and we are here now. PI Planning.  We are here, and we are doing it and it’s awesome!  Now it’s about the real work!" 

Their executive sponsor was equally as passionate: "I think it is great you guys are doing this and making the 6-day investment. I'm glad this team is embracing the change and wanting to do things differently. It’s going to be bumpy, but that’s ok. I'm excited to see what all these blank boards are going to turn into."

Not to be outdone, the department head laid down the gauntlet to the train: "How do we know we have achieved success? We will have “raving fans” across the business. We are a group of individuals, and we need to be better than the sum of our parts. Agile is a big bet. I see this as a game changer which will unlock creativity and foster innovation."

The second highlight was the approach taken to set the train up for success. With newly formed teams that are also new to agile, estimation was clearly going to be a challenge. As part of the planning context briefing, teams were advised only to plan to 50% of their capacity in Iteration 1, 60% in Iteration 2, 70% in Iteration 3, 80% in Iteration 4 and 90% in Iteration 5.  This built-in buffer provided space for the teams to learn how to work together as well as allowing for the inevitable underestimation that is so common with new teams. For me, the leadership's buy-in to this additional built-in buffer (on top of uncommitted objectives and the IP Iteration) was an indication that the leaders had begun to accept their new role as Lean-Agile leaders whose primary function was to support the people who do the work.

The third highlight was the approach taken to transitioning. Often, when a new train is launched, the organisation fails to factor in in-flight work. With this particular ART launch, we took the opportunity to understand not only what was in flight but also what ongoing, regular commitments team members had. As part of the planning context, teams were asked to start their breakouts by surfacing all their in-flight and ongoing work as stickies on the team’s PI planning board. This ritual, which I refer to as “bring out your dead”, has become a regular part of my planning context briefing for new ARTs.

My fourth highlight was the ownership the RTE team took of facilitating the event. This made a fairly stark contrast to most first-time RTEs at their first PI Planning event. So often, an ART's first PI Planning event relies heavily on external consultants for facilitation, so this made a nice change for me. From MCing the event to taking over the facilitation of Coach Sync, the RTE team was keen to step into their new roles and own them. It was simply awesome.

The fifth highlight was the outcome of the Management Review and Problem Solving session.  As is typically the case, the draft plan review had revealed that the train would not have the capacity to deliver everything. I was so proud of the leadership team as they realised the “business as usual” (BAU) activity, which surfaced as part of the “bring out your dead session”, was absorbing a lot of the team’s capacity and reducing the amount of capacity available to work on new value-adding features. The solution was a call to action for team members to bring any low-value BAU tasks to the head of the department, who would then help them with “offloading” them. This action manifested as the department head manning an “Offload your BAU” stand during the morning of day 2.

Another highlight from day 2 was the System Team's determination to surface the work the stream-aligned teams would need them to do. Recognising that the lack of dependencies received from other teams was unlikely to reflect reality, they split up and approached each team with the goal of understanding what support each team would need during the PI. The result, while still not perfect, was a far more realistic plan.

While there were clearly many highlights, the stand-out moment for me was the business value ranking of objectives by the Business Owner. This is one SAFe ceremony that I have always found challenging, but on this occasion, it was pure gold! The head of the department visited each team and discussed their PI Objectives. He was clear about the business value of what they planned and also provided guidance on what would make the objective more valuable. Secondly, each time a team had a team building-related objective, he rated it a 10. And for the teams that did not have one, he asked them to write one!

The most unexpected highlight also occurred on day 2. Some people from the support teams who had not been part of the self-selection process decided they were not in the right teams and formed a whole new squad! This certainly brings a whole new meaning to the concept of self-selecting teams! At the end of the PI Planning event, they had a plan and a team name, Hogwarts, which fit nicely with the train theme.

So there you have it. A 6-day quick-start. It was completely and utterly exhausting. But would I do it again? Absolutely. This was quite simply the best ART launch ever!

Read what happened when we "re-squadified" after three Program Increments.

Updated 6 February 2024 to reflect SAFe 6.0 terminology.

The three key ingredients in any ART launch are 1) teams, 2) a well-defined, force-ranked feature-level ART backlog and 3) the knowledge to execute in a lean and agile manner. In the case of the A&I ART, we now had teams and a backlog; we just needed the knowledge. This is where the SAFe for Teams training and the Scrum Master and Product Owner Orientation workshops came in. (Update: This particular ART Launch pre-dates the launch of the SAFe Scrum Master course, and at this time, SAFe Product Owner/Product Manager training was intended to be delivered post ART Launch).

Monday morning, the teams returned to the same venue we had used for the self-selection event to commence two days of SAFe for Teams training. I was thrilled that the organisation had taken our guidance and had gone all in for the event. Even the department head attended the entire two days.

There is something about all the teams on a train, including the leadership team, learning together with their Scrum Masters and Product Owners, that is just magical. Having spent many years convinced that training circa 100 people at once was nuts, then going through the process a number of times, I have to say I was wrong. If Harvard Professor J. Richard Hackman is to be believed, 30% of a team’s eventual performance is dependent on the initial launch of the team. Personally, I cannot think of a better way to launch a team of teams than two days of learning together.

As always, watching the teams competing against each other in the ballpoint game never fails to generate an amazing buzz, along with some great learnings about what it means for the agile release train to be united as one team.  The teams embraced the process as we walked them through breaking down their features into stories. It quickly became clear that some feature definitions were light on detail. This is all part of the learning as the train works out the balance between too much and too little pre-work for PI Planning.  At the end of the two days, we had nine newly trained agile teams ready to take on the world!

The second component of the just-in-time training is the role-specific sessions for the Scrum Masters and Product Owners. It has always puzzled me that the standard SAFe Quick-Start recommends scheduling the Scrum Master and Product Owner Orientation for day five. I've always felt like the Scrum Masters and Product Owners need role clarity prior to going into PI Planning, so I have tended to hold these classes on day three.

I also like to have the Scrum Masters and Product Owners attend both orientation sessions. I was always taught that a good Scrum Master supports their Product Owner, and I also think it is healthy for the Product Owner to understand the role of the Scrum Master. To keep things interesting, I swap backwards and forwards between the Scrum Master and Product Owner material on a lesson-by-lesson basis rather than do a solid half day on each role.

This particular Quick-Start followed the above approach. Watching the Scrum Masters and Product Owners start to bond was just amazing. As the day went on, the discussion activities became harder and harder to time box as the Scrum Masters and Product Owners engaged in passionate conversations.  While it may not be "text-book", I think SM/PO Orientation on day three works. In the words of the client: "It serves as last minute decision making and therapy session before the manic of PI planning and gives the rest of the teams' a day to wrap up anything from the old world order." The other advantage of this approach is being able to roll into iteration planning straight after PI Planning.

Of course, SAFe has evolved since I facilitated this quick-start last year. The Scrum Master and Product Owner Orientations have been decommissioned in favour of the new SAFe Scrum Master (SSM) course and the latest version of SAFe Product Manager/Product Owner (PMPO). Having just completed my first quick-start for 2017, delivering these courses in the weeks leading up to the Quick-Start, I have to say I like this approach even more. Two days of focused learning on both key roles resulted in the Release Train Engineer, Scrum Masters, Product Owners and Product Manager being very well prepared for their first PI Planning.

What does this mean for the 6-day quick-start? Well, clearly, it can't be 6-days anymore! At this point I am torn, is it now 7-day? e.g. SSM, Self-Selection, SAFe for Teams and PI Planning. Or 5 days with SSM and PM/PO being facilitated in the lead into the Quick-Start? For now, the jury is out, but no doubt a pattern will emerge in due course.

As for this 6-day Quick-Start, we are now at the end of day 4. Stay tuned for the next instalment in this series, which will cover the PI Planning event in the context of a Quick-Start.