When watching the world championship rugby you may have seen many sprints and scrums during the game. A scrum in rugby language is “a method of restarting play in rugby that involves players packing closely together with their heads down and attempting to gain possession of the ball” [ref. Wikipedia]. It sometimes takes quite some time and for a layman like me it seems not logical at all. Just pick up the ball and go for the run!
Scrum seems nowadays more related to agile development rather than to rugby. It is everywhere, it is successful and even within my company KT, the product development group learned their lessons using the agile method for developing a new range of products. Progress, not perfection is key.
Progress – does that mean “no time”?
And exactly “progress” is concerning me as it seems to be the most important criterium for decision making. “The market is asking us to react swiftly and we need to be ahead of the game” one of my clients said to me. But there was a downside to it. The development of a fix for the found root cause was not implemented and the guys responsible for root cause analyses explained to me: “why finding cause? It will not be fixed anyway”. They got demotivated! Why finding cause if it is not prioritized in the sprints? And other tasks were neglected as well, like normal maintenance. All activities in development are focussed on the sprints and being agile: being first to market with introducing new features.
By making speed the most important criterium, there is a tendency to claim that there is “no time” for other important things. Development in under pressure: how to prioritise the agile developments above the fix of root cause and regular maintenance? OK perfection might not be needed in developing new pieces of software, but perfection is needed in implementing fixes to eliminate rootcauses. And what about introducing new software and it is failing because of this hidden issue that has not been fixed? We call them lurking crocodiles, waiting there to attack you at a moment that you don’t expect it to happen.
There is no such thing as no time – we all have the same time. We make a conscious decision to prioritize one thing above another.
So who is picking up the ball?
Both parties should pick up the ball. That seems contradictory, as in rugby only one party should pick up the ball, but both should improve their tactics to become both a winner.
Those responsible for analyzing root cause should provide a clear and concise input to development. A clear description of the problem and a logically tested root cause that describes precisely the hypothesis how this cause is causing the troubles. The description increases the understanding within development and should provide a clear justification for the course of action to take.
With this precise description, development should be able to assess more precisely what it is needed to fix the issue. (rather than working on “ it is a software bug”, they will work on a pinpointed cause “while operation at speed xyz, the machine is timing out, as the limits were set too strict”).
Separated and clarified pieces of work enables them also to set the right priorities, by looking into:
- Current impact: how is it affecting the current development cycle / if we won’t fix it, will our new development still work?
- Future impact: how long can we postpone this till things go terribly wrong?
- Time frame: does it fit in the current sprint cycle, how long do we need?
If both parties put their heads together, and improve their quality and tactics of the game each of them play, it will be far better to watch and far more motivating to be engaged in.