One of the challenges I often have when talking to industry executives about a significant enterprise agile transformation is that they are usually pretty smart! After all, to have achieved their current position, they have probably been around for a while and they have likely delivered some hundreds of millions of dollars in software products or services to the market. In so doing, they didn’t get there with blind-eyed enthusiasm for every technology wave that they have seen over the decades. They may be looking for change, they may not, but in any case they are not absolutely certain that they should be looking at this change, and at this time. After all, many of them are well aware of the technology hype>disillusion>enlightenment curve that has been around for as long as many of us can remember. Here’s my memory of such a curve.
As I said, this curve has been around a long time (one technology/sales presenter I saw back when said it had been around since the ancient Greeks, where it was called the “Curve of Pystophenese”, perhaps referring to the trough part of the curve) and it is usually a safe assumption that any new technology follows this disruptive profile.
Is that the case with agile? Must we suffer a decline in productivity before the benefits accrue? If so, that could be a hard sell because in all likelihood, we are not delivering as much as we hoped at the moment, so who can afford to take even a small step backwards before the productivity gains kick in?
Fortunately, in my personal experience, the answer to the big question is an equally big NO. However, based on my decades of experience as one of those experienced (if not jaded) executives above, this causes me to question as to whether I am potentially being blinded by my own dogma. (“let us not be baffled by our own BS”, I often remind myself.)
But indeed, it is not my personal experience that productivity goes down before it goes up. Two reasons/cases in point.
- For example, one experience that I remember well was mentoring a software project in deep trouble at a time when my agile skills were really new and untested. It was an emergency, so there was no time for intensive or even appropriate training; I just threw the team into a Scrum-like daily inspection and management cycle and insisted on the delivery of working software every two weeks. The intensity of focus parallels the Meeting Deadlines: Tiger Teams Vs Agile Project Management Practices I described in an earlier post and the results were predictable – the intensity and focus went up, multiplexing was lowered, scope was managed, defects were reduced and delivery and quality went up in just a few weeks.
- From a more abstract, best practices view, if a team instills both the Scrum like management practices above plus some improved technical practices, for example, concurrent testing (or TDD), or more simply just mandating that all stories are tested before they are demo’d and accepted, would productivity go up or down over the near term? I would posit “up” because we know that the delayed defect discovery-reset context-fix-retest cycle is one of the least efficient processes in all of software development.
These are just two reasons why productivity can go UP, not DOWN. And there are more (like reduced team member multiplexing).
Now having said that, I’m not saying that in every agile adoption instance, productivity will first absolutely go UP, rather than DOWN at first, as I suspect there other circumstances that are quite different and perhaps not every implementation applies the basic agile practices with the appropriate fidelity. But I would say that that productivity doesn’t necessarily have to go DOWN, solely because the curve of Pystophenese exists. A careful and experienced-based agile implementation should help assure the former.