18 October 2017

Preparation

You've probably heard of the 7Ps, Proper Prior Preparation Prevents Piss Poor Performance. What does that mean in the context of an agile team?

I often use the imperfect analogy of an automobile to describe an agile development team. Simply, the tires are the production system, the drive train is dev-ops, and the engine is the development team. The product owner/architect/tech-lead are the fuel delivery system to that team and stakeholders/business people are the gas-tank. When they all work together the car runs soothly down the track. 

Here's the thing. If the product owner and architect aren't filtering the fuel before feeding it to the team, they aren't doing all of their job. It isn't just about pumping fuel from the tank to the developers, its also about straining out the gunk that might be in the fuel as well as distributing that work somewhat evenly across the team members. That is, making sure the fuel is clean and that every cylinder gets some of it. 

I'm going to just use Product Owner as a proxy for anyone providing requirements directly to the team (Architects, Tech Leads, Engineering Leads, etc. all count as Product Owners in this scenario).

When a product owner shows up with a story, it needs to be fully digested and understood by the product owner. It needs to include answers to questions like For Whom? Why? When? and What? One essential component is of understanding that needs to be present is, what. 

What means, what does this story do or accomplish and in understanding that we need some of the How, but not in a technical sense. That is, we don't need the Product Owner to provide the algorithm or a design document, but rather, How do you do the math? 

An example; Calculate the percentage of ripe fruit on sale for a given date. Sounds simple enough, look in the inventory for all the fruit available for sale who's status is ripe on a given date and the total count of fruit available and do some math. But in real life that might not be a simple query. For example, we may only have available a total amount of fruit, ever. How do we do the math now? Do we deduct the entire historical record of fruit sold from total count of fruit to get fruit available? Then how do we determine ripe fruit? Same way? 

This space of understanding can be solved without the business getting involved. The developers are more than smart enough to figure out a way to get an answer, but it's quite possible it won't be the right one. 

So somewhere in the preparation of the card the Product Owner should have discovered this and documented it. This isn't about stealing the thunder of the brilliant developer and it isn't about providing a how; this is about communicating what is expected. That is, what ratio is the business trying to show.