Posts

Showing posts from October, 2017

The MVP Onion

Image
I've been in some workshops recently where confusion arose around what is MVP in practice. Its seems like there are many different interpretations of MVP and often that interpretation is determined by : 1. Risk tolerance 2. Type of feedback required Risk tolerance The ruthless MVP of a fledgling startup company might be far too precarious for a traditional financial company. They may not be able to launch a streamline MVP that doesn't satisfy compliance or regulatory standards. When these requirements become part of your "minimum" then your delivery grows beyond basic  VIABILITY. Feedback Requirements If you're launching a new product, you need feedback that tells you if customers need the product, do they want the product, will they use the product, will they like the product.  Sometimes you might be using a new technology stack or trying to build something that hasn't been built before. In this case you need system feedback . Do the minimum y

Why you need WIP limits

Image
Why is this crazy person telling me to limit my WIP? As an agile coach I often come across situations where I need to encourage teams to reduce the amount of work they have in progress .  Even though it sounds and feels counter intuitive to do less work, the fact is your team will get more DONE by doing fewer things at the same time. Activity != Progress In our scrum teams we naturally tend towards keeping everybody busy. Developers working on development tasks, testers working on testing tasks. History has skewed our mental model of what people should do at work so that we feel like we should always be busy, always processing work.  This is a good model for the mass production of widgets or the processing of mountains of paperwork BUT a bad model for the production of complex, functional, high quality software. We use user stories to represent units of complex, functional, high quality software and in scrum the game is to finish a number of these units every sp