Stories without a net

Lately I’ve been working on a project that is envisioned as a “Proof of Concept”.  It’s a big important problem, and there is already a good direction in which to try and solve that problem.  The current solution is very large, error prone, and unable to scale.  However the team has been working isolated from all but a few folks who knew what was needed.  We had a very specific end state ( regulatory ) so there was lots of information about what it needed to do at least.

As I’ve been learning and researching the things that the product would do, I was doing it with the local team, lots of public documentation on what it had to do, and some bits and pieces of the current system.  Hearing some of the horror stories and issues gave me a lot of context for not only the problem space but what the solution needed to accomplish.

So for a little more than a month we created stories, sprinted, demoed, and iterated on the concepts and ideas we had.  It’s the first time I didn’t have customer contact or information from users for a system and it was both freeing and frustrating.  Freeing in a sense of anything is possible, just solve the problem. Frustrating from the fact that nobody was telling us if we are on the right track.

We recently did a demo for the larger business / IT team and it looks like we are on the right track.  So with that I have some suggestions if you happen to find yourself in this situation:

  1. Start with what you know.
    1. If the team already has an idea or you have something firmer than Jello, you can get started. It’ll change later.
  2. Find out what the end state is.
    1. Knowing where you need to end up is important.  You can change a lot of things along the way to that end goal but you have planned out some ideas.
  3. Show something to somebody as soon as you can
    1. Demo to the team, to the management on your side, to other interested people.  Get any feedback you can.
  4. What problem are you trying to solve
    1. I think this is key.  Don’t get bogged down in technology discussions or architecture.  What does the product need to do ( 30 sec pitch ) and how can you build a MVP to test that theory.
  5. Iterate and Learn
    1. What we’re doing isn’t final, or going to be kept. We have been learning ( new technology ), training ( new folks ), and getting setup to deliver.
    2. The things we learn will change the system, the 1st iteration will be supplanted by the 4th one.  That ‘s more than ok, that’s the best option in the end.


I’d much rather be working with our customers and working on solving their issues, and at some point we will be.  Until then, there is always something that can be done to prove your MVP.

 Safety 3rd


I like to create things, work with interesting people, and do all things agile. I have a testing background and really want to make great products that solve problems.

Posted in Uncategorized

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: