I was recently invited to give a short talk at Agile Teacamp, an event where people come to learn about and share their experiences with agile software development. They're friendly and informal events held over a cup of tea in a department store cafe. I offered to share some things I've been learning and thinking about recently while doing product management at GDS.
Roo's Agile Teacamp notes
1. Pigs and chickens
There's an old saying that when making ham and eggs, chickens are involved while pigs are committed. Distant stakeholders on projects are chickens, but the customer who comes along and works with your team every day is a pig; they're committed.
On projects with external owners (where we're working with another department, for example), we'd ideally aim to have a full-time product owner from the customer side working with the team every day. In reality, that's not always possible and so on some projects I've acted as a proxy customer. In those situations, I'm aware that I don't own the product but rather act as the customer to the team day-to-day, keeping the real customer involved; they help me decide the priorities and I represent them when they're not around.
A chicken who becomes a pig over time isn't really a problem, but a pig who suddenly turns into a chicken could be a disaster.
2. Two types of developer
Marissa Mayer (ex Google product manager, now Yahoo CEO) says that there are two types of developer; people who want what they're making to be perfect before it's finished, and people who want something working today that they can improve on tomorrow. You probably want to work with the second sort of developer as much as possible.
Making something that works this week is better than something that will be perfect one day in the distant future, not least because things are bound to change before the perfect thing is ever finished. Voltaire said "the best is the enemy of the good". (Well, he said it in French, but that's a pretty good translation.)
We start with a Minimum Viable Product, asking ourselves, what's the simplest thing that could possibly work? We aim to have a working product, albeit a limited one, within a week or two. Having something you can point at and get feedback on as soon as possible is definitely better than attempting to polish something to perfection without anyone being able to tell you whether what you're making is actually what they need.
3. Estimating is hard
Merlin Mann has a great episode of his 5by5 podcast in which he talks about walking the coastline, in reference to this excellent post from Michael Wolfe, which demonstrates the way that unexpected difficulties and delays make it hard to accurately estimate development tasks. My colleague David Pattinson likes to say "I can't tell you how long it'll take to paint this room, but if I've painted the room next door then I'll have a pretty good idea."
Estimating work in absolute hours or days is notoriously difficult, but comparing relative measures of complexity makes it easier. We tend to use story points and velocity when estimating work.
It's ok for requirements to change too. In fact, they're bound to. Gathering requirements and sizing bits of work needs to happen throughout the development process. When we started one particular project, the legislation governing it had not yet made it through Parliament, so we knew from the outset that certain requirements might well change during the process.
4. Use real data
I've found that using representative (i.e. made up) data, and even Lorem Ipsum placeholder text, is often a waste of time. Why?
- it causes existing assumptions to be reinforced rather than challenged
- it lazily misses an opportunity to iron out any difficulties in getting hold of the real data
- when the placeholder is seen by early users, it can confuse them and draw their attention away from the useful stuff
You're thinking "yes,yes, of course" but watch out for it next time you're tempted to cut corners and put some 'placeholder' text or data into a project on the basis that you'll go back and fix it later. I'd challenge you to fix it now instead and use real data as much and as early as possible. I recently had a bit of Lorum Ipsum placeholder text left in a version of a product on which we were doing some user testing, causing someone to ask, very confused, "why is that bit in a foreign language?" Why, indeed.
5. Nothing beats feedback from real users
Lastly, and most important, testing products with real users is vital. We always start with user needs (generally captured as user stories) and in meeting those needs I've learned not to get too comfortable with any implementation until we've tried it with a range of real people. Best of all, it's ok to be wrong. The best way of getting closer to being right is to test real ideas with real people.
Roo Reynolds (@rooreynolds) is a product manager at GDS
