Agile was considered to be synonymous with innovation. However, Scrum Alliance co-founder Mike Cohn earlier criticized modern Scrum for focusing too much on meeting the time goals at the expense of exploring innovative solutions:
Scrum in the mid-1990s (as I implemented it and saw it implemented back then) was all about finding innovative solutions. Teams were given a problem, and given a month (or four weeks) to solve the problem. With that much time, teams were able to try one or more potential breakthrough approaches before having to revert back to a safer, tried-and-true approach.
In today’s version of Scrum, many teams have become overly obsessed with being able to say they finished everything they thought they would. This leads those teams to start with the safe approach. Many teams never try any wild ideas that could lead to truly innovative solutions.
I believe a great deal of this is the result of the move to shorter sprints, with two weeks being the norm these days. Shorter sprints leave less time to recover if a promising but risky initial approach fails to pan out.
Cohn isn’t the only one to have reached this conclusion. Bianca Hollis and Neil Maiden, software engineering researchers from the City University of London, agreed that short durations of sprints could discourage the incubation and reflection needed for creative thinking. They wrote in their IEEE Software article:
One obvious weakness is that agile processes don’t exploit working software for creative thinking about new requirements. (...) Often the principle of simplicity—eliminating waste and reducing complexity—is taken too far. For example, Kent Beck advises agile developers to think of the simplest solution. Although this approach is often effective, unless a concerted effort is made to see the potential beyond the simplest solution, customers will settle for solutions developed in ignorance of what’s possible.
So project efficiency and team creativity are two directions along the time axis. It is all about balance. Agile projects cannot be successful in both simultaneously.
On the other hand, an empirical study recently reported by Pedro Serrador at the PMI Global Conference 2014 (to be published in the International Journal of Project Management) reveals that agile projects report better success in meeting efficiency measures (that is, cost, time and scope) but really standout in their improvement of stakeholder satisfaction. In addition he found that many agile projects spend as much time in upfront planning as waterfall projects (so called Sprint 0). It is there where many agile projects address the wider project goals and longer term requirements.
Since customer satisfaction is the first principle of agile, so it seems that the customer has the final say on whether an agile project should be more innovative or more schedule-oriented. What do you think? How do you balance between project efficiency and team creativity? Is your customer satisfied?