Happy July, dear reader. We've been combing through our log files to prepare a view on how our systems are being used by the Kiwi public. Here are our charts and commentary for the second quarter ... more
Trade Me's resident self-proclaimed agile aficionados (Sandy Mamoli and David Mole) were fortunate enough to speak at Agile2014 in Orlando recently, the biggest agile conference in the world and the only place where people stand side-by-side to compare the size and nib of their sharpies!
Aside from giving our talk on the Trade Me agile journey, we heard directly from great companies like Netflix, Spotify and Google (oh and even how the FBI use agile!) and rubbed shoulders with some of the brightest agile minds, so it would seem rude to keep everything we learned a secret, not to mention breaking all kinds of rules around transparency.
1. We want to make mistakes faster than anyone else!
"If we aren't failing then we're not innovating. We aim to make mistakes faster than anyone else" is a quote paraphrased from the Spotify CEO. They even have a 'Fail Wall' in the office so they can celebrate accordingly.
Roy Rapoport (@royrapoport) from Netflix showed a large crowd a list of the projects he'd worked on which had failed (some quite spectacularly). He asked us whether we would be happy to stand up and do the same and if not, why not? Is it because you haven't failed or made a mistake (pfft unlikely!), or because you are scared? Of course, without safety and without fear, there will be no innovation.
2. We definitely should NOT do this to our developers!
Did I say NOT? This will definitely NOT be funny and we should NOT do this!
We heard from a guy called Sam Guckenheimer, the Product Owner for Visual Studio at Microsoft and he shared this 'real life' video:
3. Do you ever fall into the 'Replica Trap'?
Jeff Gothelf (@jboogie, Author of Lean/UX) told us the true story of the Human Cannonball, a guy who works just 4 minutes a day! A pretty cushy number right? Well yeah, most of the time. You see when the Human Cannonball arrived in town they would fire a test dummy from the cannon, the dummy weighed the same as the human version and that's how they knew where to put the safety net.
That worked every day until one day they left the test dummy outside in the rain. What happens when something gets wet? It weighs more! So when they tested the dummy it flew out and as normal and that's where they placed the net. When it came to show time, the Human Cannonball sailed out of the cannon and way past the net, landing in a heap and breaking several bones in the process!
So I ask you, how often do you check your assumptions and test your environment to see what has changed before you apply the same thinking once again? Here's how I think this applies to a work scenario...
So you tried something and it worked, woo-hoo, go you! Next time you're faced with a similar problem, you're going to use the same solution again right? Be careful you don't fall into the trap of thinking that doing the same thing will work in all situations (aka The Replica Trap). You need to be conscious of the environment where you plan to apply the same solution, because if it's different you might find yourself scratching your head. If you are unsure, you can start with these three questions:
1. In what environment do these practices work best?
2. How close is your environment to that?
3. How much are you willing to change to achieve your aim?
(Thanks to Esther Derby (@EstherDerby) for those insightful questions)
4. Powerful question no. 2: What other options have you considered?
We heard from Spotify earlier in the year and were fascinated by their powerful question "What did you not like?" and how that would make you think long and hard before you answered. Another powerful question from Agile2014 was "What other options have you considered?". So next time you are presented with a solution and not a problem, simply try asking that question. It's a good sanity check and as one of the presenters said, if you haven't actively considered at least 3 options, you probably haven't understood the problem.
5. Innovate, innovate, innovate (the most common word at the conference)
So everyone wants to innovate. Does that somehow make innovation paradoxically no longer innovation? How do we get ahead of the curve, disrupt an industry and challenge the status quo?
Interestingly, whilst everyone expressed a desire to do this, very few people were able to explain how to go about it. Except Jeff Gothelf who told us that there are three main factors influencing innovative teams:
- The Anatomy of the team. This is one of co-location, dedication only to the team (not siphoned off), self-sufficiency and no bigger than a two-pizza team (6-8 people)
- How the team is tasked. This should be in the form of questions, problems to solve and outcomes to achieve (as opposed to giving them a solution to implement). In Jeff Gothelf's mind a roadmap is a dirty word unless it is filled with questions and hypotheses. Otherwise it constrains scope/time and the innovation roadmap itself can prevent innovation. If you don't believe this then try running up the nearest flight of stairs, now try that again with a rigid splint on a couple of your limbs and let me know how you get on.
- How the team works together. An ideal team works free of fear, happy to fail and work based is on competencies within the team, not defined roles.
Other than that, leave them alone and get out of their way was the message seconded by Netflix. Netflix also had a huge focus on innovation, for instance they prioritised innovation above availability, from which we can infer that they would happily (OK maybe not happily!) accept downtime as a result of being innovative. One of their core aims is to hire smart people and then get out of their way, sound like anywhere you know?
A final point on innovation was from Bjarte Bognes (of growing fame because of his work on Beyond Budgeting), who said that you can optimise for cost or innovation, but not both.
6. Making Trade Me famous on a world stage!
It would be fair to say that telling the Trade Me story on a world stage went down very well indeed. We were commended on our innovative story from such a cool company and highlighted for being new and different. Our agile work puts us ahead of a lot of bigger and more famous companies and everyone involved should pat themselves on the back. The presentation focused on self-selection whilst telling the Trade Me story along the way. Here's what a few people said (none of them are our mums and we didn't bribe anyone with beer - honestly!)
Also, our feedback was pretty good (the scale was 1-5)
Session meets expectations: 4.83
Recommend to colleague: 4.91
Presentation skills: 4.57
Command of topic: 4.83
Overall rating: 4.87
And one guy had the nicest thing to say in his feedback "I actually got other contacts from my organization to leave their other sessions to join your session... Great job! Thank you for sharing your story!". Which explains why ours was one of the only sessions to have more people in at the end, than at the beginning.
7. Can you chin the override bar?
At Netflix their clearly stated aim is to 'get out of the way' of their people, in fact they phrased it as aggressively de-centralising decision making. But sometimes as a manager you have to step in. How do you know when to do that? Well the question you should ask is: 'Does it chin my override bar?' A fascinating concept is how a manager only steps in if they can answer these questions resoundingly:
- How sure am I that I am right?
- What is the cost if I am right?
If it doesn't chin the bar, then they let people get on with it and they will either succeed or learn from their failure. There's lots of opportunity for innovation under that bar and yet they retain control. Impressive, yet simple.
8. How do you deal with fixed dates on projects?
The age old question that no-one can answer, oh wait someone just answered it! And here is what they said:
- Work out what the team needs to deliver by which date.
- Make sure the team knows this.
- Give them what they need to do that.
- Talk about what should be stopped to allow for this.
- Leave it up to the team to solve the problem.
Whilst you could argue this is an oversimplification, can you honestly say that you ticked all five boxes last time you had a date driven project?
Ever seen planning poker cards? Well here's a new set for you to use:
Estimates are controversial to say the least and we know they will be inaccurate, so why do we do them? They can serve an important purpose for the team and they help to better understand their work. You often hear people saying things like "Why is it we never finish our size 13 stories at the end of a sprint?". As long as we can clearly differentiate estimates from deadlines then the team should choose how much time they invest, how they choose to arrive at their estimates and experiment with different options (which may or may not involve these cards).
10. RIP projects
Is it time to wave bye bye to the good old fashioned project? By definition projects have a clear start and end point, yet in a world of continuous integration and never ending feedback loops that concept might be about to go out the window (or maybe it already has). If you don't know what your shiny new feature will look like when you start (which is likely) and you want to continue experimenting and tweaking your feature for the foreseeable future then where will it end? In fact does it ever end? Do you really want to say, that's it we will never tweak or improve that feature just because a project has finished?
Maybe it is time to say RIP projects and welcome to the world of continuous experiments and themes of work? Working in this way also reduces risk and speaking from experience, the worst thing to hear at the end of a long project is "Why would anyone want that?". Yet, by slicing things as thinly as possible, you can learn and change your approach before that ever happens. 'It works as designed' is a phrase that just won't cut it anymore!
Amazon deploy code to their production environment every 11.6 seconds on average, so their feedback loop and learning is almost instantaneous. Goodbye 12-month behemoth projects, hello 11-second feedback loops!
OK, I'm off to build my own personal fail wall (I wonder if I can find a wall big enough) and as a final thought...