Agile maturity and benchmarking models. I have a problem where they are used for comparison of where a team should be in their agile practices adoption; a one size fits all approach where teams must conform or they aren’t doing ‘agile right’. This approach is a fixed repeatable answer that conveniently ignores the question.
What value is a benchmark against other teams in other organisations, situations and contexts? agile is not a fixed plan of progression, nothing is that easy. We can’t distill a process of innovation, which is supported by a set of values and principles, into a rote adoption model. Continue reading →
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. Continue reading →
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.
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:
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.
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 ithere.
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”. Continue reading →
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. Continue reading →
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?
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.
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.
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.
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.
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:
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. Continue reading →
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.
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. Continue reading →
When we introduced Scrum and Kanban to our teams the most loved addition to our way of working were visual workspaces.
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.