My Agile 2013 Experience - Day 3 of 6

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.