Spotify at City

At this moment in time the Spotify culture is a major influence in how I am trying to shape the Agile Culture at City. I won’t go too indepth on how Spotify do it; what I want to do with this series is document what we have done at City for one project and how it actually worked or didn’t work.

SQUAD KICKOFF MEETING The very first thing we did was arrange a kick off meeting for the colleagues who were going to be part of the squad. This first of all breaks one of the key principles of Squads is that they are self forming autonomous teams; at City we aren’t big enough to do that! So we picked colleagues from the web, iOS, DBA, MI and Product team.

Being the Development Manager, I looked at myself as a coach in this situation; not rolling decisions downhill was going to be a massive thing for me in the Squad model; the team had to buy in to what they were going to do. HIPPO (Highest Paid Persons Opinion) should not be at factor here.

WHAT IS THE PROBLEM Once we were gathered, and after complaining we had no tea trolley, at a very high level we went through the problem we had to solve. The meeting wasn’t to try and solve that problem but to make sure everyone knew and understood what we were trying to achieve before we decided the first phase on how to do it. A two part product was required for this project to be deemed a success; a website and an iOS application. The concept was to allow our customers to fill in surveys and forms via both methods and also give them the ability to configure their own surveys/forms using our web site. This is a phase 1 product, with further integrations to come further on.

LETS PLAY A GAME After we all understood what we had to build, the fun began. I started the main part of the kickoff meeting by asking the team to name every single Agile method/ritual/element they could think of, and began jotting them down on the whiteboard. Tools that they would using could also be mentioned. This was something I discovered from reading kickoff meeting posts from http://nomad8.com/ which I would implore you to go away and look at.

We ended up with this as a list (which I took a picture of the board now);

Sprints Scrum Kanban Explicitly limit WIP Daily standup Retrospectives Visual workspace Measure/track velocity cycle time? lead time Planning Sprint planning On demand or on a regular basis Backlog Refinement sessions Definition of Done Forecasting product burnup charts burndown charts Demos Product Owner collaboration sit together TDD

Then, one by one, the team discussed them. First of all making sure that everyone knew what each one was… allowing the team to try and describe the topic first meant I could see how much knowledge the team actually had on the subject before chipping in. Once everyone knew what each item was… they would rule out the ones they didn’t want to do to start with… the flat out “no chance” items such as Forecasting, Estimates and Demo’s (they had nothing to demo just now). One thing we made crystal clear was this was our opening recipe for the Squad. Things change… we might be wrong… we might be missing something critical after starting so this wasn’t a nail in the coffin list.

Very quickly the team came to some core elements;

Retrospectives Standups PO Collaboration Kanban

One thing we knew was that Standups would be needed, but possibly not daily. The team decided to make these every 2nd day to start with and see how that went. After that… there was really nothing more to discuss. The team knew what elements they wanted to use to try and start the process and they also knew that none of these were set in stone and could change in the future.

The project is nearing it’s completion now, with two very very good products coming at the end of it… but was our first Squad model successful? Not really. I’ll post again next week giving the key details of what went well, what didn’t go so well and what flat out was a disaster.

If you are interested in reading more about Spotify, go here; Spotify Engineering Culture – https://labs.spotify.com/2014/03/27/spotify-engineering-culture-part-1/