Agile Zone is brought to you in partnership with:

A software professional with a passion for people excellence, process efficiency and product innovation. I like to learn ideas from other fields and blend them to see how they can benefit software development. Tathagat is a DZone MVB and is not an employee of DZone and has posted 13 posts at DZone. You can read more from them at their website. View Full User Profile

So, Does Agile Really Kill Innovation?

03.06.2013
| 2046 views |
  • submit to reddit
In continuation of my earlier blog post on ‘Does Agile Kill Innovation?’, I had a great time moderating the panel discussion at Agile India 2013 with Henrik Kniberg, Owen Rogers, Sujatha Balakrishnan, Udayan Banerjee, Praful Pillay and Sudipta Lahiri. The panel discussion was literally the last program at the end of two long days of management conference – but despite that, we had 60-70 folks throughout the session.

Agile methods, with their rather short-term focus on achieving a ‘done’ feature seem to give away an impression that the eventual goal of a sprint is delivering such a full-baked feature. However, the new-age thought process seems to be more like ‘done is better than perfect‘. Question is, does agile implicitly become the rate-limiting step for your innovation process by self-imposing a stringent and non-negotiable completion criteria that possibly can’t be met by innovation-led ‘stories’ where the discovery and experimentation is generally a long-haul process and failure is such an acceptable outcome that we want to fail early and fail often!

We had some interesting perspectives ranging from ‘agile kills innovation’ to ‘agile accelerates innovation’ to ‘it depends’. Some of the ideas that emerged out of the panel discussion were:

  • agile, and scrum in particular, seems to be well-suited to the class of problems where a reasonably well-defined product backlog exists to begin with. To that end, there is some level of agreement on ‘what’ is to be done in the stacey’s matrix. For such problems, maybe ‘20% innovation’ user stories could be designed that allow implementing features with lesser uncertainty on ‘what’ and ‘how’ and leaving the uncertain aspects to the innovation user stories. This could ensure that the sprints are not losing steam just because of taking up innovation-led tasks, and neither are those tasks suffering in the anxiety of maintaining (and improving) team’s velocity.
  • for problems that are so radically new that don’t have any notion of a product backlog to begin with, perhaps ideas from lean startup (and design thinking) make more sense where the notion of ‘velocity’ is not so pronounced as compared to the ability quickly iterate through the build-measure-learn loop in shortest amount of time, and test various hypothesis around customer discovery or MVP, or any other moving part.

Does your process let you think outside the box?

  • one attendee from the session remarked that in their organization, they give a ‘break’ in-between the sprints to take up such innovation-led tasks, and it is working for them.
  • in organizations and teams that get too obsessed with meeting predictability goals and focus on velocity, there is a risk that teams don’t attempt big bets but just chipping away at the small bets. So, that version of agile is probably not going to lead to any radical or breakthrough or disruptive innovation, but more likely suitable for incremental innovation.
  • in services companies, the essence of business value is predictability of service, and hence there is some level of disconnect with the whole notion of experimenting and failing that might impede any innovation. To that end, achieving agility could be hurting innovation. However, there are always possibilities to innovate in such customer-facing processes, and one needs to deliver proof-points and earn the charter.

These perspectives made for some good conversation, questions and counterpoints. After all, what is a good panel discussion without some arguments and controversies!

So, does your agile really kill innovation? You tell…

Published at DZone with permission of Tathagat Varma, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)