We've been working on a project, and it's been a bit of a whirlwind. It's a prototype, and it's a lot of feeling our way in the dark, and doing things quickly. On top of all this, we have external parties evaluating the output of the project, so we're having to quickly answer questions about what it can do and how fast it could do it. Marketing cares, sales cares, development cares, etc.
It's a lot of moving pieces and a lot of people watching.
So early on we sat down and wrote out what we had to show in about a month. Then we broke it into one week iterations (basically). The requirements we sketchy at best. Week two's schedule, for example, had two items on it: "faster ingest" and "modification/deletion support".
The risk of working like this is that different people can derive very different expectations from these vague requirements. So how do we overcome this?
Every week we set up a demo and invited everyone who was remotely involved with the project. We sent out a demo invitation that basically said, "this is your chance to see what you're going to get, and this is the time we will take feedback" (we didn't actually say, "you miss it, you lose", but we sure implied it).
And then every Wednesday we showed it. We sat in a room with the software on a projector and said, "this is what we mean by faster ingest" and showed it. We said, "here's how deletion works" and showed it. People made comments, people applauded the wins, people said, "oh! we could do X".
The benefits of this were enormous:
- It made the code showable. We got practice at not only building features but in making sure we could show those features off to an audience of various technical levels.
- It kept us honest. We couldn't say, "oh yeah, something's done" if we couldn't actually show it.
- It put the audience on the same page. There was no ambivalence about what was being produced. It was there for everyone to see, and if there was a variance in expectations it could be resolved early.
- It forced us to figure out how to demo. Some things are hard to demo. Features without a UI, or features that only show up when a system is full or has been running for a while are hard to show off. But we were going to have to figure out how to show it eventually to potential customers, etc. This demo forced us to figure out how to do it.
Next time you're moving fast, try demoing something. It's amazing how illuminating a simple demo can be. Does it take time? Absolutely. Will you get that time back later? In spades. Give it a shot.
P.S. I know this isn't a new idea, but it's a good one, so I'm all for repeating it!