Wonderful short video on how to be a Product Owner – should be required viewing for all PO’s and similarly essential viewing for anyone that’s trying to understand the principles of Agile. Captured in this video is the essence of Agile product development. Watch it once and if you don’t understand it all, watch it again. But most importantly, if you are a Product Owner, note the parts about working closely with the team.
My team at Westfield.com are always trying to educate the business sponsors to implement the simplest possible thing – to release the minimum viable product and generate validated learnings rather than implement gold-plated visions of what marketing folk think that people want.
Heroku’s first offering bore little resemblance to what they finally became but it allowed them to pivot and adapt: to drop the offerings that no one cared about (online code editors, no deployments) and concentrate on the stuff they did (github integration, scalability). Early releases discovered what users really wanted and mining that seam of ‘want’ resulted in exponential growth and a $212 million cash buy-out within 3 years.
We are currently coaching a new team into the ways of Agile and one of the problems we’ve encountered is getting the devs to write cards or stories using the standard Agile story formats. To Agile newbies the syntactic sugar that surrounds a story’s details often seems like a waste of time. i.e. A developer knows exactly what he means when he writes:
“Add currency code to Data Warehouse views”
and feels like he is being made to jump through hoops to turn that into:
“In order to differentiate between international sales, we need to update the data warehouse transactional views to show the currency code, so that they can report on this data.”
The reason we favour this (or the “As a [user]…” format) on agile projects is that the story describes what needs to be done and why. This means that any member of the team can understand exactly why a story has been added to the backlog and doesn’t need to get an explanation from the person that wrote the story or drill down into the acceptance criteria to discover this.
The other benefit of this format is that it forces the person writing the story to find out exactly why the requester wants that story. Indeed, in drilling down to the real requirement, the analyst may discover that the real business requirement is not what the requester is asking for at all.
Aslak Hellesoy (the creator of Cucumber) illustrates all this perfectly in the cucumber documentation where he describes the process of asking the Five Why’s to discover the underlying requirements – the why in the story.
(shamelessy copied directly from the cucumber wiki for your convenience..
[5:08pm] Luis_Byclosure: I’m having problems applying the “5 Why” rule, to the feature
“login” (imagine an application like youtube)
[5:08pm] Luis_Byclosure: how do you explain the business value of the feature “login”?
[5:09pm] Luis_Byclosure: In order to be recognized among other people, I want to login
in the application (?)
[5:09pm] Luis_Byclosure: why do I want to be recognized among other people?
[5:11pm] aslakhellesoy: Why do people have to log in?
[5:12pm] Luis_Byclosure: I dunno… why?
[5:12pm] aslakhellesoy: I’m asking you
[5:13pm] aslakhellesoy: Why have you decided login is needed?
[5:13pm] Luis_Byclosure: identify users
[5:14pm] aslakhellesoy: Why do you have to identify users?
[5:14pm] Luis_Byclosure: maybe because people like to know who is
[5:15pm] aslakhellesoy: Why would anyone want to know who’s publishing what?
[5:17pm] Luis_Byclosure: because if people feel that that content belongs
to someone, then the content is trustworthy
[5:17pm] aslakhellesoy: Why does content have to appear trustworthy?
[5:20pm] Luis_Byclosure: Trustworthy makes people interested in the content and
consequently in the website
[5:20pm] Luis_Byclosure: Why do I want to get people interested in the website?
[5:20pm] aslakhellesoy: 🙂
[5:21pm] aslakhellesoy: Are you selling something there? Or is it just for fun?
[5:21pm] Luis_Byclosure: Because more traffic means more money in ads
[5:21pm] aslakhellesoy: There you go!
[5:22pm] Luis_Byclosure: Why do I want to get more money in ads? Because I want to increase
[5:22pm] Luis_Byclosure: And this is the end, right?
[5:23pm] aslakhellesoy: In order to drive more people to the website and earn more admoney,
authors should have to login,
so that the content can be displayed with the author and appear
[5:23pm] aslakhellesoy: Does that make any sense?
[5:25pm] Luis_Byclosure: Yes, I think so
[5:26pm] aslakhellesoy: It’s easier when you have someone clueless (like me) to ask the
stupid why questions
[5:26pm] aslakhellesoy: Now I know why you want login
[5:26pm] Luis_Byclosure: but it is difficult to find the reason for everything
[5:26pm] aslakhellesoy: And if I was the customer I am in better shape to prioritise this
feature among others
[5:29pm] Luis_Byclosure: true!
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’.