Employee Handbook describing Valve’s completely flat management structure. Not exactly a methodology that you could apply to a big shareholder owned corporate but a great example of how successful you can be if you hire good people and allow them to get on with their job.
In my job at westfield.com we’ve been dealing with the challenge of scaling a development team for years and are yet to get it anywhere near optimum.
This is great post on scaling a team from a company that should know all about it – Heroku.
This is a great way to think about scaling and well worth a read although I think that most of the challenges one will meet scaling a team are not answered by this post – i.e. exactly how and along what lines you break up your teams. It’s interesting to see that the way Heroku broke up their teams was along horizontal layers rather than through functional areas but this probably reflects the highly technical nature of Heroku’s business.
We are currently undertaking a team restructure and I have been convinced for some time that to minimise friction, distraction and duplication, our teams at westfield.com need to be structured based on vertical slices of business functionality; allowing teams to own certain areas and functions of the site and business.
I’ll post again with an update when the teams are restructured and the results are in..
The Simplest Thing That Works – or even better – the Simplest Possible Thing That Could Work is a simple concept and essential to understanding Agile – it’s at the heart of the inspect, adapt, iterate approach that embodies agile methodologies such as Scrum.
The problem with really simple concepts however is that people often consider they understand and have embraced the concept when in actuality they are merely paying it lip-service. An analyst or developer may listen to a business owner’s description of what they require and think “well the simplest thing that works here is the basic functionality and then we’ll put the bells and whistles on as enhancements”. Unfortunately the ‘basic functionality’ can sometimes end up being many weeks work and it may take lateral thinking and a thorough understanding of the requirements to really identify the simplest thing that works
Why is identifying the Simplest thing that works so important?
- Projects generally take longer and cost more than expected – you could run out of cash while the project is half-finished
- The development team will often fail to build what the business owner wanted
- The development team will often build what the business owner wanted only for the business owner to find out there is no demand for the product
- Invariably you find bugs or issues in production that never get caught in earlier environments. You want to find and to find these as soon as possible.
Essentially you need to get your product/app/concept/idea out ASAP so that you can target your resources toward providing value to your customers and don’t waste resources building functionality that is never used (The Standish Group found that more than 45 percent of features are never used, while another 19 percent are used rarely. In other words, typically more than half of the development effort is wasted on developing nonessential capabilities).
Eric Reiss (whom coined the term Lean Startup) gave a great anecdote on this at a conference recently where he described that after polishing his code and project for 6 months he found that there was no demand for his product: when he put it up on his highly polished website for customers to download there were no customers – no one wanted it. His quip was that he could have found that out by just putting up the website and link before he even started coding and he would have saved himself 6 months effort!
Tony Hsieh provides another great example in his book “Delivering Happiness” where he describes how the founder of Zappos set up his online store by taking photos of shoes from a local shoe store and putting them online. When orders came in he would walk down to the store, buy the shoes and send them out. He wasn’t making any money but for almost no investment he was able to establish there was demand for his product, start his company and base his next steps on experience and empirical data rather than gut feel.
The concept is crucial at the micro level as well as the macro level. Next time you pick up (or write) a story with a highly polished piece of UX attached to it providing every bell & whistle and acceptance criteria as long as your arm, ask yourself (and your product owner) Is this the Simplest Thing That Could Possibly Work? Do we even know if anybody’s going to go to this page – and if they do are they going to use the page the way we anticipate they will? Why not get the basics out there and gain some empirical data on if and how it’s being used first and iterate from there..
How to identify the Simplest Thing That Works
- Establish and consider the fundamental business need rather than what you have been asked to build
- Analyse this need and consider a pragmatic solution – how you would get to the end state if you only had 2 or 3 weeks to get it done
- Consider including manual or semi-automated processes which can be switched out with automatic steps later if the product is successful and it’s justified
- If necessary provide a feature toggle that allows the feature to be built, showcased and tested but gives the business owner the option to not release to production
- At all times stress to the business owner that you are not trying to cut scope or corners. He will still get what he wants in the same time frame but will also get the opportunity to evaluate his product much earlier
@azaza tells the story of how the English Channel was crossed on a man-powered machine by firstly solving the problem of how to iterate quickly and try thousands of differently configured aircraft. Thanks to @mootpointer for this one.
If the problem you are trying to solve involves creating a magnum opus, you are solving the wrong problem.
Definitely worth viewing this presentation from Jeff Patton. It captures the spirit of being agile outside of the constraints of frameworks like Scrum.
My favourite quote:
Your guesses about the future are probably wrong
Unusual to have the SMH with a piece on the challenges facing the Software Industry. This quote absolutely sums up the problems that the Agile community is trying to solve
The old saying of ‘measure twice and cut once’ actually works against software development because it creates this false expectation that if we spend more time planning we will spend less time changing our minds. Sometimes the way it works on paper feels wrong once put into software or what appears as mild scope creep actually results in fundamental changes under the hood. I feel that the modern digital equivalent should be ‘prototype twice, go live once’.