My goal for the next couple of years is to become an awesome public speaker.
And here’s why:
This is handball, and this is what I used to do. First, on a competitive level from when I was 12 and then, when I grew older, as a professional player representing Austria at the 1992 Olympic Summer Games.
Let them be in control of the way they work …
After having been though a day of letting people self-organise into squads David Mole, Trade Me’s head of projects (and my Agile partner in crime) and I are often being asked how we kicked off the new squads and how we make sure they work in a disciplined but creative way.
This is a very topical question as not only did we have 22 brand new squads on our hands all at the same time, Trade Me are also rapidly growing and new squads are frequently being formed.
It’s common among Agile teams to use some form of voting to make decisions, and that’s especially true for retrospectives where the team as a whole decides what to fix next.
Over the years I have facilitated many retrospectives and had the opportunity to vote for many things, over that time some patterns emerged.
- The Early Settler – gets to the board first and stakes their claim
- The Swing Voter – waits until the end to try and influence the system (I usually suggest that the last person to vote tidies the room at the end)
- The Mid-Table Fatalist – votes with the masses even when they don’t want to, as their real choice has too few votes to make the cut
The one pattern that really worries me is the “Fatalist”. Having to go with the masses because you can’t get enough votes triggers my “bump of trouble”, essentially something that you feel strongly about is getting missed and ignored by the “process” and voting is the only “tool” you have.
… getting more stuff done
At Trade Me we want to measure the overall health of Tech (that’s our team of 125 designers, developers, testers, BAs, and Squad Masters) to identify trends and to know if we are getting better (or worse!). We know that when we measure something it is a strong way of saying “This matters” which is why we put a lot of effort into deciding which metrics to collect.
There are lots of things that matter to us in Tech but the most important ones are:
- Get stuff out fast
- Have high quality
- Have happy clients (business people/end users)
- Have happy employees
- Build the right thing
So, you want to choose some teams? Well, you came to the right place…
Many people have asked us to share our run sheets and material for the self-selection sessions we have run during the past year. So, by popular demand here’s what we call the self-selection kit.
It contains all the materials you need to facilitate the self-selection of 70 – 120 people into teams and includes a preparation checklist, a run sheet for the day and some visuals to cut out.
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.
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 75 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 (squads) that will persist over time and across projects.
Up until last week we had six established squads and the rollout had been purposefully slow and controlled. Now we felt there was enough knowledge within the organisation to speed up the process.
The first thing to do was to define our next target condition and to agree on how to make it happen. For this we used A Toyota Improvement Theme Kata (see picture below):
… 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
Many novice teams find it difficult to strike the balance between too much and too little detail when writing user stories.
User stories often start their lives as big statements of intent with lots of unknowns and that’s okay. For something that’s not going to be developed in the near future it makes no sense to specify a lot of detail as it will probably change anyway or might never be done if priorities change. We want to avoid specifying too much detail before a story gets pulled into a sprint to avoid wasting our time.
People often ask me how Nomad8 works. To explain this I need to tell a bit about how we came about and what kind of company we want to create.
Things got started in 2007 when Brenda and I formed Nomad8 as a company for ourselves, a way to work with clients we loved on projects that tickled our fancy. We kept things fairly low key for a while. Then two years ago I was inspired by a blog post by Henrik Kniberg about how his company, Crisp, works. In fact, I found it so inspiring that I had to go to Stockholm to find out more.
And that’s what I did: I booked a ticket to the other side of the world to meet Henrik and Reza and to find out about the intricacies of the Crisp model. We had a very long and interesting conversation about how Crisp worked, how they had come up with their model and how they kept Crisp a place they loved working at. And even better, they encouraged me to build upon their ideas and offered helpful advice.
Part of this fabulous deal with Telecom and the Galaxy Note II is that I switch to the Telecom network. I’ve been with Vodafone forever, it kind of goes along with being a Mac user, a Lambretta driver, a non-mainstream kinda girl. However Vodafone recently dropped my 3Gb data limit to 256MB for no apparent reason (I suspect I’d been left with a promotion for a bit too long and then they realised) and that proved a bit hard to live with. So switch I did and it was painless and good.
My Telecom plan is cheaper than the relatively equivalent Vodafone one, with more data = WIN. The changeover process was easy – ably assisted by the nice man at the Telecom shop and Alastair from Scoop, I answered a series of questions, signed a few forms and then hey presto in an hour or so I was all switched over! No word yet from Vodafone, not a peep of protest in fact. So much for my years of custom.
When we introduced Scrum and Kanban to our teams the most loved addition to our way of working were visual workspaces.
Our shared visual workspace
We found it tremendously helpful to make our tasks visible though post-it notes, to visualise our workflow and to make sure that we didn’t do too many things at the same time. With the visual task wall, the so-called team Kanban board, everyone knew how close we were to our goals, what still needed to be done and who was working on which task.
Every other week I have a geek and gossip breakfast with fellow Agile coach Nathan from Boost New Media. Last time he told me that at Boost they had replaced the word “Scrum Master” with “Agile coach”.
It makes complete sense: The most important part of the Scrum Master role is coaching. Also, many of us have added techniques and principles from Lean, Kanban, Systems Thinking and XP to Scrum which now makes the term “Scrum Master” way too limited to describe the role.
Still, I couldn’t help feeling that someone was stepping on my toes. My knee-jerk reaction was “Well, fine if they’re Agile coaches, then what am I?”
I knew Nathan was right, still something was bugging me.