What and How

When I’m not busy playing with computers, being a little evangelical about Scrum or reading a book I’m something of a petrol head. I watch F1, Superbikes and watched MotoGP until the BBC lost the rights at the end of last year…

What does this have to do with Scrum you ask?

Well… With all of the uproar about the noise in F1 (no pun intended…) since the start of the season I was wondering what could have been done differently. And thought about the “how” and “what” problem.

It’s something that our teams have certainly had to deal with, and I think that the FIA has had the same problem.

The “how” and “what” problem is how I see responsibility split across a Scrum team. The PO is responsible for the “What”: which stories are going to be picked up and in what order. This gives the Development team the goal. The development team is responsible for the “How”. Just how are these goals going to be worked into a potentially releasable increment? When these start to get mixed up bad things can happen to the value that the whole team provides, and the quality of code that the team generates.

So, back to 4 wheels. F1 has had a problem for a while now. The cars are very technologically advanced, managed to produce amazing amounts of power from relatively small engines and had enough down force to drive on the ceiling.

But… The aerodynamics were so impressive that the cars could not run within a couple of seconds of each other for long periods of time – otherwise the tyres and engines overheat, and slip streaming was a thing of the past as the cars had no grip whilst running in dirty air. After all of the cost cutting measures put in place over the last decade the spending of the teams has got to the level where the lowest teams spend as much as the top teams did when the cost cutting started. And the top teams are spending obscene amounts of money to put two cars into 19 races. And, of course, having cars that burn 150kg of fuel per car for less than 2 hours of racing was not really PC.

So the FIA did something about it – but where they should have given the teams the “what” of needed to be achieved, they gave them the “how” to do it. This means that the teams couldn’t come up with their own “how” and had their hands tied by the new rules.

So…  How would I have done it differently (and what does this have to do with software development?)

Firstly, I would try to get the goal of what I wanted across. The FIA does not need 1.6l V6 Turbo Hybrid engines (I hope, otherwise I would like to ask “why?”). That was a “how”. What they wanted was “An engine that lasts for x races, and uses no more than 100kg of fuel in a race and at a rate of no more than 100kg per hour”. This would have allowed the teams to come up with their own solutions and really moved F1 back to the technological pinnacle of motor sport.

My second PBI would be for the aerodynamics. The FIA has increasingly introduced more measures to reduce the down force – making the wings smaller, reducing the elements that teams can put on the wings etc.

The problem is that this has achieved nothing for racing. The designers have worked around the rules to produce cars that can drive on the ceiling and still cannot follow another car.

Again, they gave the teams the “how”. How about you swap this around? The goal is “make cars which can work to x% aero efficiency behind a standard model, and allow the standard model to work to x% efficiency behind the car”. Sure, testing this would be more difficult – but the racing would be so much better! No more DRS to allow drivers to overtake, no more push to overtake electric motors. Imagine cars slipstreaming around corners and the straights, pulling out to overtake before the next one.

This is overly simplified I know, but hopefully you can follow my thoughts!

Back to software development again! When a PO starts to think for the development team there is a very real danger of the development team not thinking about the problem, but just implementing the solution provided. This means that the PO may miss the best solution, and the development team may struggle to implement a solution that is less than perfect technically (as the team tries to keep within the confines of the solution provided to them).

Let developers think with the business, let them find the best solutions to problems (but this means you have to tell them your problems :p). The resulting solution will be output from the entire Scrum team with all the expertise that is contained therein, and not just one person’s view of a possible solution. You may even find that your problem isn’t actually what you thought it was and get something far outweighing what you though was possible!

Advertisements