Roll With The Punches

June 24, 2013 Matthew Parker

You’re a product owner, and you have an idea. In your mind, it’s pure, simple, and beautiful. You want to hold onto that idea, to nurture it, cherish it. Reality, however, has other plans. You’ve got investors. You’ve got a team of hungry developers and designers licking their lips. You have to feed them your idea. So you say it. And immediately the illusion is shattered. The designers and the developers start asking questions. They force you to come up with concrete examples. You start breaking the idea down into features. One developer comes up with an edge case you hadn’t considered, forcing you to rethink your idea entirely. BAP!

You’re a designer. You’ve worked hard for the past several months to create a holistic design and a sane, coherent user experience in what has turned out to be a very challenging problem domain. And then your product owner walks in one morning and explains that the product is going in a new direction. Your entire user experience is shattered. You find yourself picking apart the workflows, trying desperately to put them back together in a way that still makes sense. KAPOW!

You’re a developer. You are proud of the application you’ve built. Your classes are well-factored. Your domain is well-modeled. Your class names make sense to even the newest person on the team. Your patterns are so well established that you can build on an existing feature by simply throwing in a new subclass. Your test suite is fast. You’re ready for anything. Except what your product owner just said. You didn’t see this coming. Your code is woefully unprepared to accommodate this new feature. You’ll have to rethink at least a dozen objects in order to implement it. ZLONK!

Building software is hard and painful, but this is what we know:

  1. Good stories make good code.

  2. Writing stories are a collaborative process between the product owner, the developers, and the designer.

  3. A story can’t implement half a feature; if you can’t put it in front of a user and get meaningful feedback, it’s not a story.

  4. Stories start with business value. If you can’t identify what value your business will get out of the story, your business has no business with it.

  5. Stories consist of concrete examples. You can’t wave your hands at computers, so don’t hand-wave your story.

  6. Talking through edge cases as a team helps the team understand what the product owner actually values.

  7. Roll with the punches. The story of your application will change. Build a team that embraces that change.

About the Author

Matthew Parker

Matt Parker is Head of Engineering for Pivotal Labs

More Content by Matthew Parker
Previous
An Architecture for Real-Time Geo-tracking with Python, Celery, RabbitMQ, and More
An Architecture for Real-Time Geo-tracking with Python, Celery, RabbitMQ, and More

An expert on GIS systems recently spoke at PyCon and outlined a scalable approach to real-time tracking and...

Next
A Rubyist Learning Go – A basic Go program
A Rubyist Learning Go – A basic Go program

Starting July 1st, I am going to have the opportunity to step outside by development comfort zone and begin...

Enter curious. Exit smarter.

Learn More