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.
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.
Doc opened by explaining that Velocity is a lagging indicator for a complex system and lagging indicators are good for monitoring trends but are poor predictors of the future. He advocated the use of standard deviation in forecasting velocity, noting: "The Business won't like this but it's the closest you can get to the truth with the data you have". Doc also warned against the use of velocity targets, "When you set a target for velocity you unintentionally introduce all sorts of problems into the system".
Doc talked to the multiple causes of variable velocity, that cannot be identified by simply looking at velocity numbers. He suggested the use of scatter diagrams to show correlation, at the same time reminding us correlation does not always equal causation. He also illustrated the value of using a cumulative flow diagram. In summary, Doc recommends measuring many things, including "Team Joy" (a leading indicator) and remember "Metrics are not for managers, metrics are for teams!
For me, this was the session of the week. The story of scaling agile at Spotify is inspiring, growing in only three years from 30 developers in one location to 400 developers across four locations and offices all over the world.
For Spotify the single most important principle to maintaining speed at scale is Autonomy. Squads, the term Spotify uses for an agile/scrum team, are autonomous. They consist of 5 to 7 engineers and no more than 10 people in total. The are cross functional, have their own mission, they own a feature across all platforms (including maintenance) and they have their own team workspace. The squad chooses which process to use - Kanban, scrum or whatever else - based on what works best for them. The team is free to select its own work and set its own office hours.
One of the challenges with this model is defining the organisational structure to support the squads without decreasing autonomy. As the organisation grew to 150 engineers they found people didn't know each other anymore, so they created a smaller context, Tribes, made up of squads with a similar mission and of no more than 100 people (based on Dunbar's number).
To help with alignment across Squads within the same Tribes Spotify uses Chapters. Chapters bring together people with similar competencies, for example testing, on a regular basis to share challenges relating to their specific area of expertise. The Chapter Lead is the line manager for the chapter members and looks after the personal development (Spotify's term for career development) of the chapter members. Guilds are used for alignment of Chapters across Tribes.
There is a great paper on this by Anders and Henrik Kniberg, 'Scaling Agile @ Spotify', which provides a much better explanation on Squads, Chapters, Tribes and Guilds. I also came across this YouTube video of Anders talking about Agile at Scale @ Spotify at London Lean Kanban Day 2013.
Dean provided an overview of the Scaled Agile Framework, its roots in lean thinking, agile development and product development flow and the new material included in v2.5. He went on to talk about the power of 'ba', showing the New Zealand All Blacks Haka video as an example, followed by a very amusing set of video clips of teams he has worked with doing their own haka. The EDW Release Train hakas did not feature in the video montage, but embarrassment was only momentarily spared.
Unbeknown to me, Dean had created a slide from my blog post, The Power of Haka. When he reached this slide in his presentation, I was pleasantly surprised and went to take a photo to send to my team, when Dean asked if "Em" was in the audience. In hindsight, I'm thinking raising my hand was a mistake. I was sitting about 15 rows back, and there is no way he would have spotted me if I had just sat still. The next thing I know, he asks me to stand up, then decides it is my story so I should speak to the slide, as he wanders through the room so I can use his lapel microphone.
Everything past that point is a bit of a blur, however, I'm pretty sure Dean wrapped up his presentation by talking to a number of case studies (including the EDW Release Train) that have had improvements in employee engagement since the introduction of SAFe.
Steve and Steve told the story of implementing continuous delivery at Rally Software to a packed room. In May 2010 the engineering team operated in 2 week sprints and eight week releases, today they run Kanban and release features "when they want". They started the process of moving to continuous delivery by understanding their existing processes and removing the manual steps. Along the way, they learned that you need to monitor everything and you must be able to trust your tests i.e. you can no longer ignore tests that regularly fail.
For more detailed information on their story check out the paper by Steve and Steve here.
My Tuesday evening was spent at Rally's Good Old Fashioned Bluegrass Fest held where I got to, very briefly, meet the newly published author, Geoff Watts (check out his book Scrum Mastery: From Good To Great Servant-Leadership). While waiting in the drinks queue, I witnessed long time twitter buddies Adam Yuret and Jean Tabaka meet "in real life", which was amusing.
During the evening I ran into Dean Leffingwell and took the opportunity to ask him to warn me next time he would like me to participate in a presentation. Looking back, I don't think I actually got him to agree, but I did at least get a thank you for helping him out, so I guess that is something! The "Bluegrass Fest" also provided an opportunity for me to catch up with guys from Boost Agile, Nathan Donaldson and Jacob Creech, who are doing great things with Agile in Shanghai.
Pretty Agile® and Tribal Unity® are registered trademarks of Pretty Agile Pty Ltd.