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.
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
12 comments
Comment by Minding the product at #mtpcon 2012 « BASIC CRAFT posted on
[...] an honour it is to have been called up to the small band of product managers at the Government Digital [...]
Comment by Ian Howe posted on
#5. Nothing beats feedback from real users
Great to see you highlighting this. All too often in the past we’ve used internal users to represent our customers. No matter how well intentioned that is, it always falls short of the insights and surprises you get when real customers get their hands on things.
At Land Registry we’ve just launched a beta of a new search tool for our house price data:
http://houseprices.landregistry.gov.uk/
We were keen to get this out to the public as soon as we could to get their feedback so for the first time we put it out as a beta rather than go through a full blown development process to get it implemented on our corporate site. We’ve been getting some interesting comments (about the beta and other things) over on our Product Innovation blog site:
http://productblog.landregistry.gov.uk/
It’d be great if readers here could take a look at both sites and let us know what you think
Comment by Steve Freeman posted on
Nice to see some progress in Government circles.
- please retire the Pigs and Chickens metaphor. It doesn't play well cross-culturally and, as some like to point out, the chicken is the one with the sustainable model.
- you need to distinguish between "perfection" and completeness. There's been too much damage done in software in Voltaire's name. I've seen companies destroyed because they underinvested in the quality of their code. The trick is to to write "just enough" high quality code.
Comment by More agile-thinkers like Roo Reynolds please | Campaign4Change posted on
[...] Reynolds’ article, Government Digital Service. Share this:TwitterLinkedInEmailStumbleUponDiggRedditLike this:LikeBe the first to like this. This entry was posted in Agile, Campaign4Change, change management, cost reduction, e-health, Government IT, health records, IT-related failures, npfit, private sector lessons for the public sector, reducing cost strategically and tagged Government Digital Service, npfit, public sector. Bookmark the permalink. ← Will coalition sign a new NPfIT deal with CSC? [...]
Comment by Angela posted on
On Lorem ipsum - and also speaking as an editor - I agree with OP. Lorem ipsum can never show you what 'it' looks like, as the content constitutes the 'it'. Lorem ipsum is the quickest route to a bad web page and I try to avoid it at all costs. I have excellent QA systems.
@ James my choice would be http://tlipsum.appspot.com/
Comment by James Kingsley (@onEnterFrame) posted on
Great article, I totally agree with #2. Regarding #4 I agree with Liz.. I think there is a time and place for Lorem ipsum although these days I tend to use something like Hipster Ipsum.
Comment by liz hitchcock posted on
Speaking as an editor, Lorem ipsum is for when you want to know what it will look like but you are not ready to input authorised text. If you tried putting in a draft version of the text this would be a problem as people might assume it was authorised and it could end up being published without being checked. Lorem ipsum tells you it is awaiting true text. People also find it useful for estimating word counts needed etc.
Comment by Richard Northover (@rich13) posted on
If "the legislation governing it had not yet made it through Parliament", I guess this meant that you had little choice but to "put some ‘placeholder’ text or data [in place] on the basis that you’ll go back and fix it later"?
If true, there might be two kinds of 'placeholder text': actual 'lorem ipsum', which I agree should be avoided, and a different kind (which is perhaps harder to avoid) where you write something that's good enough for now, but almost certainly not good enough for the finished version.
Tricky thing here is that, just as you ended up with some stray 'lorem ipsum' in there, you can end up with the known-to-be-approximate copy left in place longer than you wanted. Particularly difficult if the text has legal consequences or is similarly important.
Comment by Roo Reynolds posted on
Hi Richard.
Well, in this case the legislation in question (which is a subject for another post really...) could have affected the entire system, and the problem you talk about is true for a lot more than just getting the right copy. It helps that our initial assumptions about the most important things the product will need to do, which is to say the user needs it will need to meet, were always unlikely to change. On the other hand, one of the joys of working in an agile way is being prepared to change course as necessary, and giving the customer (in this case colleagues in another part of Cabinet Office) a chance to prioritise the most useful areas of work while specific policy implications in other areas are worked out.
I do definitely agree that there's a difference between true placeholder text/data (which is essentially filling in roughly the right number of pixels on a screen, without any real attempt at any meaning), and situations where you're putting in a first pass at some text (or even the functionality of a thing) as a first attempt to genuinely meet the need of a user. 'Lorem Ipsum' isn't going to help anyone (except someone who wants to see how n words of copy looks in this layout, which probably isn't a real user need), so a first attempt to put something useful there instead, even if it's wrong or based on an assumption, is usually going to get us to a better end result.
Comment by Gareth Rees (@_gareth) posted on
"4. Use real data"
Although I agree with the sentiment, there are definitely times where real data is not appropriate. For example, you wouldn't want to take a dump of your production database for development use when it contains private customer details and perhaps sensitive information.
We should really be using things like Faker to generate psuedo-real data so that there are no data protection issues.
Comment by Roo Reynolds posted on
Thanks Gareth. Good point; there are definitely times when realistic data beats really-real data.
Comment by David Chassels posted on
A tip for estimating (when using agile software where no coding or code generation required)
Before serious project starts there are 3 essentials
1. Agree the objectives/outcomes/goals i.e.- what are "we" trying to achieve.
2. In business language with users workout step by step who and what is required to make it happen. Encourage new ideas there are no constraints.
3. From 2 work out estimated cost. A good guide would be work out number of UIs (including reports, maintenance forms etc) needed. That number becomes the number of man days to build. If very complex like a configurator or means testing or heavy reliance on accessing legacy it may be longer - but such issues identified at this stage not later!
At this point a fixed price can be negotiated contract agreed and build starts mirroring exactly what has been agreed. First cut for feed back and change as required in say a week to show users their ideas coming to life!
See entry on solutions exchange (last day!)
http://ictinnovators1.procurement.cabinetoffice.gov.uk/Page/ViewIdeas