Video: How a Business Executive Led the Implentation of Agile, Lean & CI/CD

scroll-2
scroll

Tuesday

Agile Metrics: Velocity is NOT the goal  by Michael "Doc" Norton 

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!

Agile at Scale at Spotify by Joakim Sundén and Anders Ivarsson

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. 

Be Agile. Scale Up. Stay Lean … & Have More Fun! by Dean Leffingwell 

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.

Continuous delivery? Easy! Just change everything. (Well, maybe it isn't that easy) by Steve Stolt and +=Steve Neely  

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.

Tuesday Evening

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.

According to Wikipedia, the Haka “is a traditional ancestral war cry, dance or challenge... performed by a group, with vigorous movements and stamping of the feet with rhythmically shouted accompaniment.” When I attended Dean Leffingwell’s SAFe Program Consultant certification course earlier this year, he used a video of the New Zealand All Blacks performing a haka to illustrate “The Power of Ba”. “Ba” is the place teams are in when they become high performing, self-organising and energized. If you watch the video I’m sure you will agree that the spine chilling performance is the perfect illustration of what it feels like to be part of a team that has truly reached “ba”, a place where “we, the work and the knowledge are one”.

Recently, there was a reshuffle of people in our scrum teams, predicated on the need to more evenly balance skills and knowledge across the EDW Agile Release Train. This change was unsettling for the teams and I started to think about helping them find their “ba” again.  This led me to contemplate how I might convince the teams to invent and perform their own haka.

I started my campaign for a “Haka Challenge" by talking to my leadership team, who responded with "Excellent idea!", "You can't make me do the haka on my birthday!" and "Do we have to?". Not deterred by the mixed reaction I took the idea to the Scrum Masters who didn’t exactly bounce off the walls with excitement but were willing and thought it could be fun. With the Scrum Masters on board, I pitched the idea for a  “Haka Challenge” to the entire EDW Release Train, giving all the teams an iteration to prepare a haka for a “Hak-Off”.

Some teams were immediately inspired, others very reluctant but over the course of the fortnight, they all got into it. The laughter from haka planning sessions could be heard through meeting room walls and there was a quiet buzz on the floor as teams went about practising hakas while also trying to keep the content a secret.  One team's self-appointed creative director even tried to convince his team to dress up as the village people and haka to the tune of YMCA!

When the day of the Haka Challenge arrived there was an air of anticipation as the teams gathered (in a rare show of punctuality) for our iteration kick-off event (aka Unity Day). There was facepaint, skirts made of post-it note covered butchers paper and a large contingent proudly sporting their "EDW Release Train" T-shirts.

Pipeline Services, a team of PMs and System Analysts, were first up.  Lead by the broomstick carrying “Wicked Witch of the North Tower”, two pig-tailed cheerleaders and four spear-carrying warriors opened with the cheer “Pipeline Services are HOT TO GO! H-O-T-T-O-G-O!”. A  chant that is still buzzing around my head days later. 

Pipeline Services

Next up was the Green Hornet team, dressed in green rugby shirts and accompanied by one of their business stakeholders. The team’s technical lead, lead the war cry in Maori while pacing between team members. Thankful he read out the translation at the end of the performance!

Team Astrotrain’s quietly spoken scrum master was the next to take the stage, After getting his team in formation, he raised both hands in the air and lead a war cry about “spanking” Epics. (At EDW “spanked” means “done done”).  Team Maglev’s haka was inspired by the EDW architecture. They were followed by Team Jacobite, who took the time to learn an actual Haka!  

While Team Kaizen amused the troops with their disco moves and use of real cucumbers! The mornings’ antics were concluded by a most unusual haka from the System team, which included wearing honey badger masks while reenacting “More Cowbell”. 

Kaizen
System Team

The flow-on effect was like magic. I had started out wanting to help the teams with "ba" and ended up creating "ba" across the entire train, as highlighted to me in an e-mail I received from one of my scrum masters the next morning:

Since doing the Haka exercise – and aside from the fact that I lost my voice …  
Everyone across teams have been congratulatory of the other teams and their members. It has instilled a massive cross pollination of communication and engagement going on!!! 
The quieter team members from various teams across the department are having animated corridor conversations 
The level of talking and noise being generated in the different team areas has been much, much higher, even late into the night!  
Further, people are far less tense and defensive in the general discussions across the department.  People are open and honest, after having embarrassed themselves.  
Basically, the teams are showing greater interest, engagement and ‘hunger’ for what they do, and what they are about … 
How do you quantify all of this?  You don’t, but what I do know is that the teams are more galvanised, and have a much stronger sense of their own context … and being part of the greater whole; being EDW!!! 

I think the "Haka Challenge" is going to be the highlight of my time with the EDW Agile Release Train for quite some time to come

Pretty Agile® and Tribal Unity® are registered trademarks of Pretty Agile Pty Ltd.

© 2021 Pretty Agile
chevron-down