When watching 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 that involves players packing closely together with their heads down and attempting to gain possession of the ball” [ref. Wikipedia]. It takes time for a rugby layman like me to understand this as it doesn’t seem logical. Why not just pick up the ball and go for the run!
Scrum nowadays seems more related to Agile software development than rugby. It is everywhere and is very successful. Within my company (Kepner-Tregoe (KT)) our product development group recently developed a new range of products using the agile method. Progress, not perfection is key.
Progress – does that mean “no time”?
The use of agile may be a perfect path to take for many applications. However, in my experience with certain teams and industries how “progress” being is defined is concerning, as to me, “progress” is the most important criteria for decision making. One of my clients said to me, “The market is asking us to react swiftly and we need to be ahead of the game”. But, consider the downside. The development of a fix for a “found root cause” was not implemented and those responsible for root cause analysis explained to me, “Why find cause? It will not be fixed anyway”. And, why should they find cause if it isn’t prioritized in the sprints? What’s troubling is that other tasks such as normal maintenance are also neglected. The reason why teams are directed to be have activities in development focus on sprints is to gain a competitive edge and be the first to market to introduce new features.
By making speed the most important criteria, there is a tendency to claim that there is “no time” for other important items. When development happens under pressure, how do you prioritize agile developments above root cause analysis and implementing a fix? Not to mention completing regular maintenance? I agree that perfection might not be needed in developing new pieces of software however, perfection is needed to implement a fix to eliminate root cause. How often does a new software introduction fail because hidden issues had not been investigated and corrected? We call these lurking crocodiles, waiting to attack at any moment, especially when you least expect it.
It is not an issue of having “no time” – we all have the same time. It is the priority we give to certain things that makes the difference.
So who is picking up the ball?
Both parties should. I know that seems contradictory. In a rugby match only one party can pick up the ball however, both should work to improve their tactics to become a winner.
Those responsible for root cause analysis should provide clear and concise input to development. A clear description of the problem and a logically tested root cause that precisely describes the hypothesis showing how this cause is creating trouble. This description should increase the understanding within the development team to provide clear justification for the course of action to take. With this clear description the development team can assess with better accuracy what is needed to fix the issue. For example, rather than working on “it is a software bug”, they will work on a pinpointed cause e.g. “while operating at speed xyz, the machine is timing out as the limits were set too strictly”.
Clear descriptions, or as we say here at KT, “Separated and Clarified” pieces of work also enable teams to set the right priorities, by looking into:
– What is the Current Impact?: how is it affecting the current development cycle. If we don’t fix it will our new development still work?
– What is the Future Impact: how long can we postpone this issue until things go terribly wrong?
– Time frame: does it fit in the current sprintcycle, how long do we need?
If both parties put their heads together, and improve their quality and tactics of the game each play, it will be far better to watch and far more motivating to be engaged in.
