This was a 3 day conference on agile software development practices and case studies, run by Software Acumen who also do various other agile and UX events. It was quite small conference, but had plenty of good talks and was well run.
It had been a few years since I’d last looked into the agile community in any detail, so I was interested to see how much things had changed. It turns out there was not much new in terms of ways of working, with Scrum and Kanban remaining very popular. However, there was an acknowledgement that we’re still not getting the basics right in all cases (for example, some people are just splitting a waterfall up into sprints and calling that agile). As such, the focus was more on how to get the fundamentals right and how to get the best from your team.
I’ve picked the following talks to describe in more detail in this post:
- “Putting the ‘V’ in MVP” - Different types of MVP and when to use them
- “From Scrum to Flow with Agile Metrics” - How to predict delivery dates while using an agile approach
- “The Power of an Agile Mind-Set” - Showing how you see the world can have a profound effect on behaviour
Putting the ‘V’ in MVP - Ralf Jeffery
The term MVP (Minimum Viable Product) is frequently used these days, but often means different things to different people. A common definition is “a cut down version of the final product”, with just a couple of features implemented, but actually there are many more options.
An MVP could be:
- A simple website landing page, allowing you to gauge interest in the product
- A video demonstrating how the product would work
- A prototype created from existing components
- A prototype and SDK (e.g. Oculus rift)
- A UI, with nothing implemented behind the scenes (known as “Flintstoning”)
- And finally the usual meaning - a limited feature product
How do you decide which to use? It’s all about focusing on what will allow you to learn the most for the minimum effort. You need a clear objective/question, for example:
- Dropbox wanted to know if their product would be easy enough to use to allow it to gain traction in an already busy market, so they created a video explaining it and allowed users to sign up to register interest.
- Nutmeg wanted to know if people would trust a computer to automatically invest their savings. They created a website which gave people the impression that their investments were being managed by computer, but in reality it was done by humans. People signed up, proving that they were willing to trust a computer.
- Google wanted to know if society was ready for wearable tech, so they built a traditional minimal featured prototype for Google Glass and quickly got their answer!
Focus on the question you’re trying to answer before you start building, and use MVPs to prove that you’re building the right product for the right market.
From Scrum to Flow with Agile Metrics - Peter Pito
The most common question we hear from customers is “When will it be done?”. Some agile approaches duck the question (“It’ll be done when it’s done!”). While that is technically true, we can’t say this to the customer when there is a contract involved!
This presentation described a method which allows us to answer both “When will feature X be done?” and “How many items will be done by date Y”, both accurately and cheaply. Based on Kanban, this approach does away with individual task estimates in favour of tracking the average time a task takes to complete. Developers’ time is no longer spent estimating tasks (although you do have to make sure you break work down into roughly equal tasks).
As the project progresses, you track the average number of items currently in progress (WIP) and the average throughput (number of items completed in a given unit of time). This is then used to calculate the “Cycle Time” (WIP/Throughput) which shows the average time an item of work will take to be completed.
You can then do analysis on this data. Determining the percentiles for cycle time allows you to monitor for tasks which are taking longer than expected, and to take remedial action. This analysis allows a single page report to be produced which shows planned and forecasted dates (with confidence level for latter), and shows delta between them.
This seems like an interesting approach to me, but there’s a lot to it - far more than I could squeeze into this summary. For more information see this blog summary: http://www.ontheagilepath.net/2015/04/unleash-predictability-by-using-actionable-agile-metrics-6-key-learnings-from-daniel-s-vacantis-awesome-book.html and the speaker’s book: https://leanpub.com/actionableagilemetrics
The Power of an Agile Mind-Set - Linda Rising
This talk, the first day’s keynote, described two different mind-sets:
- “Fixed”: the belief that your intelligence is more or less fixed vs
- “Agile”: the belief that you can adapt and grow over time
Experiments have shown that which of these mindsets you adopt will have a substantial effect on behaviour and performance. For example, a class of school children were split into two groups based on this division and given a number of tests. The children all began with the same easy test and were then given the option to do more easy tests, or to try harder ones. They found that those in the “Agile” group were more likely to:
- ask to do harder tests and push themselves
- encourage and “coach” their fellow students Conversely those that were in the “Fixed” group were more likely to:
- choose easier tests to try and avoid failure
- lie about their results to try and make themselves look better
The difference between the two groups was clear, but what’s interesting is how they were split into the two groups. This was done soley by changing the way the children were praised after the first test.
One group was told “Well done, you’re really smart!”, while the other group was told “Well done, you must have tried really hard!”. The former phrase promotes the “Fixed” mind-set. Children learn that they are smart enough to do that test well, but when they come up against harder problems they assume they’ve hit their limits and give up. The second phrase reinforces the effort the children put in, promoting the “Agile” or growth mind-set.
This experiment has been repeated for adults as well, and the effect is just as powerful. The following practical advice can be drawn from this.
For children:
- praise effort, strategies and process
- ask about the work they put in
- instead of ignoring failure, teach that it’s a way to learn and improve
- Encourage others to ask their own questions, struggle and fail. For adults:
- Don’t argue with someone who’s putting themselves down, instead remind them of a time when hard work led to success and offer your support to help them carry on trying.
- Tell people about the two mind-sets /before/ they are down. Just knowing can make a difference. For you:
- Don’t be defined by status, salary, etc. Ask yourself: “Are you still learning?”
- Think of yourself as temporarily derailed when things go wrong/you are feeling down.
- Say “I’m not good at this… yet!”
Other talks
Some short summaries of a few of the other sessions during the rest of the conference:
- A case study of a website for Transport for Greater Manchester, built using the Government Digital Services user focussed design principles: https://www.gov.uk/design-principles
- One of the keynotes spoke of the importance of neurodiversity and how to ensure your hiring process is accessible to all sorts of people. The speaker has a (free) ebook on the topic: The Inclusive Collaboration Experiments (https://leanpub.com/theinclusivecollaborationexperiments)
- Enterprise anti patterns: good list of bad stuff organisations should avoid.
- Interesting list of prerequisites for “scaling agile” which, if you get right, often mean you don’t need to scale up after all.
- Mobbing was the only new term/process I came across, whereby the whole team work on a single issue (like extreme pair programming). This seems like an interesting approach, but I’d imagine it would only be a good fit for a few edge cases, not day to day work.
- A presenter also spoke about how he uses Kanban at the portfolio level to manage his company.