Spotify’s Scaling Agile at a Glance
Spotify’s whitepaper on how to structure an organisation with Agile tribes, squads, chapters and guilds has been the most inspiring and interesting idea to come out of the Agile scene in the past three years.
For anyone who has read the excellent paper we have created a one page infographic on how it all works.
Download it here.
(The hard thinking behind distilling this all down to a one pager has been done by Julie Starr)
Total Squadification – Large Scale Self-Organisation
I fundamentally believe that organisations get the best results when people can choose what they work on and who they work with. In that spirit Trade Me decided to let people self-organise into small, cross-functional teams called squads.
Up until last week we had six established squads in Wellington within two tribes and the rollout had been purposefully slow and controlled. Now we felt there was enough knowledge within the organisation to speed up the process.
I wrote in more detail about our motivation for self-organisation and experiences with a smaller scale trial in my previous post “The self-organising organisation” and if you haven’t read it yet I recommend you have a quick read. Also, this is one of my longer posts, so if you prefer to read it as a whitepaper you can download it here.
We thought the fastest and most efficient way to let people choose which squad they wanted to be in was to organise a facilitated event that would allow people to self-organise in real time. So we booked almost the entire Wellington tech department of around 70 people for a day of “squadification”.
I recently ran a “get to know your team” session to help a team with lots of new members to better understand each other’s history, motivations, likes and dislikes.
We did a number of exercises including journey lines, what do you value and team flags and we wrapped it up with postcards (insert ref to ant’s post).
We found the “what do you value” exercise particularly effective and I thought I would share the process we used.
This exercise can help to identify differences that might cause friction within the team and find ways to work out any annoying wrinkles in your team dynamic.
… let teams self-select!
At Trade Me we’re in the process of getting everyone into small, cross-functional teams that will persist over time and across projects. For this we have been deeply inspired by Spotify’s ideas and terminology of squads, chapters and tribes and their culture of autonomy, mastery and purpose.
In this post I’m going to write about how we got to a place where people work in autonomous squads and will focus on the process of self-organisation that we used to move people into squads.
Up until last week we had six established squads within two tribes and the rollout had been purposefully slow and controlled. Now we felt there was enough knowledge within the organisation to speed up the process.
… or Team Closure within a Project Closure
Projects come to an end, which means that a team that has been working closely together, may well be torn apart. This can lead to a sense of loss associated with disbanding some strong team relationships; especially if the team has reached the fourth ‘Performing’ stage of Tuckman’s model of group development.
Less often used in this model, is the fifth stage for the break up of a team; that of ‘Adjourning’. This stage is also referred to as ‘Mourning’, which is apt given the sense of loss that can be felt by team members. The Project Closure process can be very stressful to those involved, especially when it is very sudden and unplanned.
The Big Estimation Debate
There have always been, and no doubt always will be debate over estimation; the pros and cons, behaviour anti-patterns and the how and why of it all.
In this post I am not going get into that debate but I want to share with you some experiences I have had with estimation through using the average number of story points as an aid to mid-term planning.
Teams often need to understand when a release longer than a couple of sprints might be completed. Personally I don’t think it is unreasonable to ask “could you give us an indication of when you may be finished so that we can tee up all the other elements of the go-live process”. As software is after all just an element of the whole big picture.
Faced with this question, what kind of options are there?
Here are the slides for my presentation “Portfolio Kanban – Seeing the Bigger Picture”.
I had a great time at AgileWelly last night – thanks everyone for coming along and for all the lovely feedback!
Here’s the blurb for my talk:
Doing too many things at once can slow an entire organisation down. As every successful organisation will have more great ideas
Why your daily standup should be driven by a daily goal
Let’s face it, the daily standup can be a boring affair. I’m not talking about abominations with 16 people or half-hour long status reporting meetings. I’m talking about the ones that are kind of okay and adhere to the rules but nonetheless are a bit boring and lack focus and enthusiasm.
To me the point of the daily standup is not to rattle off what you did yesterday, what you’re planning to do today and if you have any blockers. The point is to decide, as a team, what each of you can do to make this an awesome and productive day that helps you get closer to building something great.
I’d like to share a technique that I have used during the past year to help teams increase focus and clarity of purpose during the day: The daily goal.
5 things that happen when you let ‘em loose …
Last Friday we had Fedex day at Trade Me. The aim of a FedEx Day is to complete something deliverable within a 24 hour period, i.e. to go from idea to a shippable product within a day. It was fun, lots of great projects saw the light of day and I enjoyed doing some hands-on work for a change.
It was a joy to see an entire organisation self-organise into small teams and work away on projects of their own choosing. We were roughly 80 people across 15 teams and worked on 15 projects that all somehow benefitted Trade Me. Everyone was highly motivated, enjoyed the experience and got shit done.
To me it was also a study in what happens when we give a group of people complete freedom to work on what they think is important, with whoever they like while using any approach they think will get the job done.
Here are some of my observations:
What is a premortem?
A premortem is a project postmortem that’s run before a project. During a postmortem people analyse and discuss what went wrong, what went well and what could be improved.
While postmortems are very useful the problem is that by the time we run them the project is usually over and not much can be done about success and failure.
A premortem allows people to think of potential future problems, roadblocks and risks before we start the project and makes it possible to come up with good ideas to prevent them from happening.
When would I run one and why?
Premortems are really useful to get people talking about the fears and concerns for the project they would otherwise keep to themselves.
There are three situations where I find premortems especially useful:
- when we start looking at developing something that feels risky (e.g. a project or feature set)
- when I sense unspoken anxiety, fears and concerns
Hi, my name is Simon and I am a Project Manager at Trade Me. Sandy kindly asked me to contribute to her blog, and I consider it a great honour. Below is my story about how we embraced Agile to inject magic into our project.
As a Project Manager I am keenly aware that most projects fail and that’s a good thing. However the part that I really want to nail is the project inception as this will majorly reduce the risk of your project failing and in some cases stop us from starting the project altogether.
The project inception is all about two things:
- Making sure as an Agile Squad that we are all on the same page before the project has even started.
- Making sure we ask all the tough questions up front.
The project inception draws out all the juice to fully fulfil those needs.
At Trade Me we used a combination of Sandy’s Mamoli’s wisdom and the approach outlined by Jonathan Rasmusson in his book, ‘The Agile Samurai”.
What are ground rules?
Ground rules are a list of behaviours and rules a squad decide are useful for working together as a team in a productive and respectful way.
A list of ground rules is an incredibly useful tool for guiding group behaviour. They are part of establishing an environment where people can bring up difficult topics and have challenging conversations. We call this discussing the “undiscussables”.
Ground rules are also often called working agreements.
Do you have an example?
Here are one team’s ground rules:
Last week Jan, Mike, Anthony and I were at Agile Australia in Sydney and had an incredibly good time. The conference turned Twitter handles into people, exposed me to TimTam slams, and taught me that Beyond Budgeting is not a boring accounting thing but a riveting management philosophy.
I presented on personal Kanban and Lynne Cazaly drew this amazing picture of my talk:
Kanban for 1 by Lynne Cazaly
I also learned about Lean UX at MYOB, that drawings can summarise anything and software for social good. I enjoyed some really great sessions and met many cool people.
Working Agile in the client-vendor context is not always an experience filled with joy and achievement. It can be daunting, frustrating, expensive and unrewarding – as much as it can be productive, useful, involving and successful.
Working with Agile with internal teams can be challenging enough, but if there’s buy-in from all parts of the organisation, it can be truly awesome to be part of a functioning Agile team. I have seen the results of our coaches working alongside teams to create smoothly functional and effective teams. Effective Agile can revolutionise your workplace – in a good way – if you let it.
However as a client, or Product Owner, even a client who knows what it is and has worked Agile before, working with an external agency has numerous challenges, particularly for smaller (3-6 week) website projects.
What does your sprint planning meeting look like?
Are you the “do it as fast as you can” efficiency hounds or the “sit and listen while the tech lead drones on” type, or are you a “real team” who fight for great designs and customer experiences?
Having watched and attended a few hundred of these meetings over the years I have seen good and bad ones. There are a few key elements that, if missed or undervalued, can lead to constant frustrations and sprint failure.
These elements are:
- Understand your project time
- Your signal to noise ratio
- Starting stories when they are not ready
- Sprint planning is not about writing tasks
- Doing too much planning
- Ignoring your velocity