Forget velocity, Foster creativity Harm Pauw h.pauw@devon.nl @harmpauw harmpauw
Who am I Technical Consultant @ Devon Trainer @ Scrum.org, isqi Former Software developer Passionate about making great software
Promise of Scrum You ll get more You ll get it faster
But often We re still struggling to meet deadlines It feels like we re doing something wrong It s not because don t have smart people
Focus on output We want to go faster, and velocity seems related to speed It s one of the few things we measure So we want the velocity to go up
Optimizing output Get rid of waste Interruptions Meetings Manual work
Increasing output is not going to save you There s a limit to improving efficiency Scrum isn t about efficiency, but about effectiveness If you push on velocity, you ll get story point inflation
Who s responsible for maximizing value? Product Owner Scrum Master Development team
Who s responsible for maximizing value? Product Owner Scrum Master Development team
Making tough choices Order work so that we work on the most valuable things first Choose what not to do
MVPs are often misused MVPs should be used to discover what your product needs to be all about MVPs are not a good tool to meet deadlines
Development isn t coding Coding & testing is just the production part of development There s also thinking about fit solutions for problems And this part has way more impact
Development team!= production team Development team is an innovation team They know the technical consequences of a solution best We should use their creativity to come up with fit solutions Not just to build a solution
There are always multiple solutions There s no perfect solution Choose a solution that s fit for purpose Functional and non-functional
Different solutions different sizes This difference can be a couple of orders of magnitude This is where you can make a difference as a team!
What can you do? 1. Allow for different solutions 2. Know when you need another solution 3. Create scarce 4. Learn from your experiences
➊ Allow for different solutions
Define What instead of how Good user stories are: Independent Negotiable Valuable Estimable Small Testable
Define What instead of how Good user stories are: Independent Negotiable Valuable Estimable Small Testable
Alternative solutions over trimmed down solutions Uber Public transport Carpooling
Don t let architecture suffocate creativity Create boundaries with enough freedom within Allow for new insights
Don t let UX design suffocate creativity Wait with UX design till the last responsible moment (that means in the sprint) Make UX designer part of the team
Recap Allow for different solutions Define your problem, not a solution Prefer alternative solutions over trimmed down versions of a solution Don t let architecture or UX design block creativity
➋ Know when you need another solution
When do you estimate?
Estimations are often Done once Done late in the process (sometimes during Sprint Planning) Only used for planning purposes
Use estimations as signals If it doesn t fit in the planning, start implementing a different solution If it just fits in the planning, start implementing a different solution too
But my initial estimations are inaccurate! Yes, but still accurate enough to use as signals Too big lot of risk You can still roughly check your business case
Recap Know when you need another solution Estimate early and multiple times Don t use estimations just for planning, but also as signals If you don t or just meet your planning, think about a different solution Inaccurate estimations are still usable
➌ Create scarce
Parkinson's Law "work expands so as to fill the time available for its completion
Time to Create is a requirement Time to Create is a requirement, just like any other requirement
Artificially limit time and people By creating scarce, you are forced to think about: Different solutions The added value of your product and team: Which thing don t we need to build ourselves
There s the cost of maintaining too The more you ve built, the more you have to maintain
Recap Create scarce Create scarce to Focus on your added value Limit the maintenance costs of your solution
➍ Learn from your experiences
Empirical Success isn t measured by how well we stuck to our initial plan We want to learn early and often And apply those learning in the subsequent work we do
Don t be afraid to choose a different solution once you started It s not failure, you just have new insights Be aware of the Sunk Cost fallacy
Choose solutions that are cheap to change Sunk costs play a lesser part Do it when there are a lot of uncertainties
Recap Learn from your experiences Learn early, often and apply those learnings Don t be afraid to throw things away Make solutions cheap to change
Conclusion Forget velocity - Don t just try to work harder or cut down features Foster creativity Deliver more value by choosing different solutions Get from a good production team to a great innovation team Learn and apply learnings
Take aways There s a limit to optimizing output MVPs are not a solution for meeting deadlines Alternative solutions over trimmed down version of solutions Use estimations as signals, not just for planning Create scarce for now (cost to build) and for later (cost to maintain) Changes should be cheap
Questions? Harm Pauw h.pauw@devon.nl @harmpauw harmpauw