Em is an active member of the global agile community and was invited to co-chair the Enterprise Agile track for the Agile Alliance 2014, 2015 and 2016 conferences. She is a recognised expert in Scaling Agile and frequently speaks about her experiences at conferences across the globe. Em shares her experience in agile in this blog.
In June, Context Matters 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 Context Matters 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 its 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?
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.
Chapter Leads would brief their teams prior to the event and provide guidance on the competency mix expected.
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).
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.
Thought you would be interested in hearing about how self-selection went yesterday.
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.
Firstly the opening messages set the perfect tone for the 2-days. The RTE opened the event with: "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."
Teams used foam boards for their plans instead of post-it pads so nothing would need to be stuck upon the walls.
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 sprint 1, 60% in sprint 2, 70% in sprint 3, 80% in sprint 4 and 90% in sprint 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 that is so common with new teams. For me the leadership's buy-in to this additional built in buffer (on top of stretch objectives and the IP sprint) 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 not only to understand 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, that I like to refer to as “bring out your dead”, has become a regular part of my planning context briefing for new ARTs.
RTE taking the lead on facilitation of PI Planning
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 facilitation of Scrum of Scrums, the RTE team was keen to step into their new roles and own them. It was simply awesome.
RTE leads Scrum of Scrums
The fifth highlight was an 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 capacity to deliver everything. I was so proud of the leadership team as they realised the “business as usual” (BAU) activity, 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 “Off Load your BAU” stand during the morning of day 2.
"Off load your BAU" stand at PI Planning
Another highlight from day 2 was the System Teams determination to surface the work the features 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. A group of people from the support teams that 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 both a plan and a team name, Hogwarts, fitting 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!
Over the course of the week leading up to the self self-selection, the thought of launching a new ART with no experienced Scrum Masters had been on my mind. How we would find the right people for those Scrum Master roles? I tend to choose what I read based on what is on my mind, so I had picked up my copy of +Geoff Watts's Scrum Mastery and reread a few chapters on my flights to and from Sydney that week.
I took two bright ideas away from this: (1) we had to reinforce the message at self-selection that the Scrum Master role “holds no authority", and (2) when asked to nominate a Scrum Master teams tend to know instinctively who will be the right fit. Inspired by this my first task on the day of the self-selection event was to track down the Release Train Engineers (RTEs) and suggest that rather than letting individuals self-select into the Scrum Master role we let the teams nominate their Scrum Master after the squads had been formed. They were agreeable so that became the new plan.
Now we had to get organised. Flip charts were drawn up for each squad and a Product Owner’s photo added. Everyone else's photos were laid out on a trestle table at the front of the room. By 9:15am we had almost full house, so we decided to kick off. I opened with a quick run through of the agenda for the day, followed by the lead RTE who set the scene for why they had chosen to use self-selection as the approach to forming teams. Then it was back to me to run through the logistics for the morning.
First everyone needed to collect their photo from the front of the room, or have one taken if somehow they had managed to avoid being photographed during the week! Next we heard from each of the Product Owners about their features and why people should choose their squad. One product owner was quick to offer up food and wine as an incentive to join his squad!
Then it was time for the self-selection to begin. Some people moved quickly, almost running to the squad they wanted to join. Others were more cautious. At the end of the 10 minute time box for Round 1 we were faced with a few unexpected outcomes. First, no one had remembered to brief the interns, so they formed their own team! Secondly, no one was without a home. Thirdly, adherence to the “rules” was sketchy at best.
One of the recommendations +Sandy Mamoli and Dave Mole make in Creating Great Teams is to minimise the constraints. For this self-selection we had come up with three rules: (1) do what is best for the company, (2) teams needed to be made up of 8 or 9 people and (3) each team should have a least one person from each of the functional groups. At the end of Round One we had a number of teams of 9 and some teams of 5 or 6. We also had teams that were completely lacking in some skill sets.
Round 2 was marginally better. There was some movement but also some very stubborn participants and the teams still varied greatly in size. Something just wasn’t quite right but I couldn’t put my finger on it. Each team played back to the room their overs and unders and then we took a morning tea break, during which we reminded everyone of the number one rule - do what is best for the company.
At the end of Round 3, we introduced confidence voting. Using a “fist of five” we asked each team their confidence that their team could deliver on its mission. Where squads responded with a 1 or a 2 we asked what they needed in order to increase their level of confidence. This helped the teams get far more specific about what skill sets they were missing. We also asked the RTE and the department head to vote, which helped maintain focus on the big picture and doing what is best for the company, In the final round, a couple of people were nudged by management to moved teams, in the best interests of the company and the ART. I found this uncomfortable however with the clock ticking and the rest of the Quick-Start commencing Monday, it felt like the only way we were going to get to an viable outcome. Despite the management interference, when it came to the final confidence vote all the squads voted confidence of three or above. It was a wrap.
As much as I should have been thrilled at this point, I could not shake the feeling that something was not quite right. We ended up with six squads - two teams of nine, two teams of eight, one team of seven and one team of six. Not exactly evenly matched feature teams!
The three squads without dedicated Scrum Masters nominated Scrum Masters. That was also more difficult than anticipated. One squad essentially had a volunteer so that was easy. One squad voted and the nominee said “I’m too busy!”. When they re-voted the next nominee was quite rightly concerned that he also did not have the time! The third squad nominee was about to go on extended leave. Not exactly the magic answer I had been hoping for, but we had Scrum Masters.
We closed the morning with a lightweight retrospective. While there had clearly been some challenges with the process, I think it would be fair to call the event a success.
We used the afternoon for some team kick off activities. The new teams were given an hour to come up with team names and build a Team Product Box. Over the prior few weeks the department had nominated theme for the train and then voted to decide between them. After a very close battle between Game of Thrones and trains, the train theme won out. Strangely, of all the trains I have been involved with, this is only the second time that the train has had a train theme for team names. (In this instance this choice has ended up creating some confusion as newcomers have understood each team to be its own Agile Release Train!)
The creativity of the teams with both creating their product boxes and naming their teams was inspiring. And of course it would not be a team naming ceremony it one or two names did not have to be vetoed by leadership. At the end of the hour the teams introduced themselves to the train and showcased their product boxes. The energy in the room was nothing short of amazing.
The other kick off activity for the afternoon was the creation of team charters. For this we used a variation on +Edwin Dando's How to make a social contract and build better teams. While the teams were working on their charters, the “aha" moment I had been waiting for occurred. The four offshore developers that we had thought would be joining us for the quick start had been unable to arrange travel at short notice. This meant that we were four people short but we did not adjust the constraints for the team-selection. The maximum size for a team should have been eight not nine! That was why the teams were so unbalanced. It was time to confess.
I pulled aside the RTE and filled him in on my thinking. I also expressed concerns about communication challenges the nine person teams were likely to encounter. I was keen to rebalance sooner rather than later, but when would be a good time?! After some debate about the pros and cons of making the change immediately, we decided to leave it be. Take the weekend to think it over and revisit the topic on Monday - day one of the QuickStart and SAFe for Teams training.
Once the teams finished up their team agreements, we did a quick walk through of the run sheet for next week's quick start and called it a day. One day down and five to go!
SAFe ART Team Self-Selection - YouTube
Time Lapse Video from the Self-Selection Day
Reflecting on the self-selection event there were a few lessons learned:
Don't assume everyone knows everyone
One of the things I discovered after the self-selection event, was that there were not a lot of existing relationships between the functional teams. Given they were a co-located team of teams, I had just assumed they all knew each other. Seriously I surprise myself sometimes! I have told the story of the beginnings of the EDW Agile Release Train countless times, always explaining that there were circa 100 people that had worked together for years mostly collocated over a couple of floors in the one building that did not know each other's names. Why did I think this team would be any different?!
Be crystal clear on your expectations
In Creating Great Teams+Sandy and David recommend minimising constraints. I completely agree with this - however, I would temper this advice by suggesting you also need to be clear about your expectations. If the constraints and your expectations aren't aligned you are sure to end up disappointed. In this case we wanted even matched feature teams - ideally with two people from each competency, but we didn't tell anyone that!
This did end up being resolved after Day 1 of the SAFe for Teams training, when the RTE shared our concerns regarding team size and balance with the ART. In an attempt to minimise disruption we asked the over and under size teams to stay and work through a solution, with goal being to reduce the nine person teams to eight person teams and add a person to the six and seven person teams. We asked the smaller teams to nominate the skills they were short of and then asked them to work with the nine person team that had the most people with that skills set. The intent was to find volunteers to move, which of course proved more challenging than anticipated.
It was interesting to observe the very active role the product owners who were also line managers played in this horse trading. Their sense of "ownership" over their new teams made me nervous. While not something to solve for that day I noted this as something to watch for as we moved into execution mode. After about an hour of rather emotional and uncomfortable discussion, the moves were agreed. We had fairly evenly matched feature teams - at last - but I fear the cost of the last minute changes could take some time to surface.
It was this event that crystallised for me how much the features allocated to each team had influenced the team shape. At the end of each round of the self-selection process we had asked the squads "Do you have all the skills to deliver on your mission?" What we should have asked is: "Do you have balanced representation of all the A&I skillsets?" When using self-selection for a feature team ART perhaps don't seed the teams with missions
As you already know we chose to follow +Sandy and David's guidance and seed each team with a mission. We did this by pre-allocating features to product owners and using these features as a proxy for the team mission when seeding the teams. In an effort to avoid teams being too theme centric, when it came to providing the teams temporary names for the purpose of the self-selection event we went with Product Owner names not themes. In hindsight this was an abject failure.
First, it created the impression that the product owner's owned the teams. This coupled with the fact that most of the product owners were the most senior person on their team. This created a strange power dynamic, that is taking some time to breakdown.
Secondly, people tended to choose teams based on the work anyway! This was different to the patterns that Sandy and David have observed where people tended to choose a team based on who they want to work with. The weird part of this was that teams were not going to be changed for at least 6 months but the features only represented 10 weeks worth of work. This choice set an expectation we would move people to the work instead of work to the people. This was contra to our goal of creating a world in which teams would "pull" in the work they wanted each PI.While not catastrophic this did mean we had to manage expectations as we moved into PI2.
I think if I had it over, I would try and structure the event so that the newly formed teams pulled down the features that they wanted after the self-selection event!
This was simply a miss. There were lots of good reasons why we did not communicate earlier but I do think it hurt us on the day. At a minimum I would like to have communicated the problem we were trying to solve and the constraints before the event. This provide an opportunity to flush out any flaws with the thought process and gives people more time to make considered choices.
The good news is none of these challenges had a catastrophic impact on the ART. In fact 5 months later this challenges have paled into the background as the ART has hit the ground running, with a momentum that has the whole building talking about the marked changed in the department since the 6-day quick start!
the people who will be doing the work are grouped in teams of 7+/- 2 with a Scrum Master and a Product Owner
Day 1 and 2 of the Quick-Start all the teams attend the 2-day SAFe for Teams training, sitting at team tables with their product owners. During the training they work with real features from the program backlog.
Day 3 and 4 the train holds its first PI Planning event.
Day 5 the Scrum Master and Product Owners attend role specific orientation training
And then you start sprinting!
I realise this sounds all fine and dandy if you are working with an organisation that is already Agile, but what if they are new to Agile? Can you still Quick-Start? Absolutely you can. At this point, you may be thinking I have completely lost the plot. This sounds like utter madness, I know. I thought it was madness too, until I tried it and realised it was truly amazing. It is my hope that as you make your way through this series of blogs posts on the 6-day Quick-Start you will get gain some insights as to why this approach is such a powerful way to launch an Agile Release Train.
Getting back to the point, you may have noticed the textbook Quick-Start is only five days. So where did this sixth day come from?
Well it all started with the need to form teams. I was working with an organisation that was structured in functional teams. Advanced Analytics, Campaign Innovation, Capability Development, Engagement, Strategy & Innovation, Operations, and Information Leadership. As part of reinventing themselves as an Agile Release Train they knew they needed to form cross functional teams. Over the months leading up to the ART launch they floated various models past me. The first few versions reminded me of little project teams. There was a theme, that described the type of work that the team would do, and each team had been handcrafted to have the exact right number of people with each skill set required to deliver on its theme. Saurav (the other coach I was working with) and I hated it
You see Saurav and I had worked together on both the EDW Agile Release Train and StAART. In both instances the train had initially been formed by merging a set of Agile projects and Agile project teams into an ART. At EDW we had learnt that this model tended to create a scenario where by the team's identity was synonymous with the project they were working on. The business folks who owned the project felt that they "owned" the team. While there was something nice about the close relationship between the teams and their business sponsors, it started to become awkward when priorities dictated that “their" team work on a feature that didn't come from "their" project's backlog! Despite our best efforts to prevent StAART replicating this mistake, the pattern was repeated with similar results. So when it came to this next train we were determined to fight for more generic feature teams from the outset. Teams that could and would work on the agreed priorities, regardless of which "project" or business person was sponsoring the work. In fact, what we really wanted to do was let the teams pull the work they wanted to do from the program backlog.
When I facilitated Leading SAFe training for the department’s leadership team I took the liberty of highlighting the opportunity to form interchangeable feature teams, leveraging the Spotify communities of practice model to maintain communication and collaboration within specialisations. While I was at it, I threw into the mix the concept of using +Sandy Mamoli's self-selection approach to create the teams. This is something I had always wanted to try but to date I had been unable to find a willing victim. In my view letting the people who actually do the work decide how best to organise themselves to deliver was the ultimate application of "those who do the work know the most about it". A handful of the leaders in the training group expressed an interest in this rather radical approach in which people decide for themselves which team they should be a part of, but overall the consensus was that it would not work in this organisation.
The very next week fate intervened and the entire ART launch plan was rendered null and void by the announcement of an impending organisational change. We couldn't form teams and launch the ART if we didn't know who would be in the department in eight weeks time! So we rescheduled the Quick-Start. Never one to be discouraged, I again put forward the idea of using self-selection to form teams. This time my approach was to suggest self-selection as a way to boost morale given the changing organisational landscape. I am fairly sure the department head thought I was completely delusional when I was adamant that we could trust people to make the right choices, but in the end he agreed. There was just one catch, based on my existing commitments we would need to hold the self selection event the day before the Quick-Start. And yep, you guessed it, at that moment the six-day QuickStart was born!
The three key ingredients in any ART launch are: teams, a well defined, force ranked feature level program backlog and 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.
Monday morning the teams returned to 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 learning together.
As always watching the teams competing against each other in the ball point 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 all 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. Just 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 ScrumMasters 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 found themselves 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 am liking 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? eg. SSM, Self-Selection, SAFe for Teams and PI Planning. Or 5-days with SSM and PM/PO being facilitated in the lead in to the Quick-Start? For now the jury is out but no doubt a pattern will emerge in due course.