- March 20, 2019
- Posted by: Web Team
- Category: Uncategorized
(The term Agile in this article refers to Agile methodologies originating from the agile manifesto, not the generic English term agile.)
Agile works great if you can break a project into a bunch of tasks which can be estimated, and are achievable given the existing skills of the team. If you are doing an exploratory innovative process where you do not know what you need to know until you explore a bit, then I suggest that the many directives given by standard Agile methodologies don’t work so well. Moreover you shouldn’t get upset that they don’t work well, because Agile wasn’t designed for innovation. The Agile Manifesto (and its follow on suggestions), was created by software developers, for software developers, to optimise software development processes, with the implicit expectation that the client has full understanding of the tasks needed to be completed. There are however some aspects of Agile which I think are useful during exploratory and R&D processes.
Background
One day the ideation team of a tech startup focused on genetic testing came across the bright idea of creating an innovative piece of software. In essence the software would analyse someone’s DNA and predict their risk to get certain diseases. It would use various analysis models from the public domain.
Excited outbursts followed this product vision: “Once we have the raw DNA why should we pay for someone else to do the analysis?” and “Most of these models are public domain!”, and (chortled by the head priest stroking his white cat maniacally), “This could be massive, massive! Billions!”
A talented data scientist was put to the task to develop the software, but after three months, she was dismissed for having achieved “not much”.
What happened? Why did “not much” happen? There were two major issues which set our plucky data scientist up for failure. The first one was telling her to develop the project in javascript, instantly removing 99% of the useful available data science tools, but that’s not relevant to the point of this article. The other major issue was that this was a largely exploratory process. There was not a list of tasks that could be popped into backlog and re-prioritised every week. It turned out most of the analysis models need lots of preprocessing, what sort of processing – was a long investigatory process itself. The target raw DNA format was very large and had to be transported back from the 3rd party doing the sequencing and then stored somewhere. So there were data requirements which influenced both the infrastructure requirements and the software requirements. The CTO (and product owner), and the CEO were continually frustrated because none of the tasks were being completed and none of the estimates were right. An MVP wasn’t going to be done in Twitter quick time (it took 2 weeks to develop the Twitter MVP apparently), and therefore wasn’t going to be worth all those foretold billions!!
Exploratory Projects
Ok so there is a little bit of exaggeration in this story, but the main point of the story is that Agile processes sometimes don’t map easily to R&D processes. In this case the CTO thought that he could apply a sort of pseudo Scrum, one of the most popular Agile methodologies, to the R&D process.
I see similar Agile misapplication with innovation projects for example with AI or Machine Learning projects. AI projects are much closer to being R&D projects compared to standard software development. Yet there is often the same expectation when doing AI projects, that is, apply Agile and success will follow.
“…early AI investments can be classified as R&D spending, and they should be regarded as innovation opportunities with potentially exponential returns.”
Zhou et al
Innovation projects focused on AI and Machine Learning are often exploratory for the simple fact that often, even with companies not new to AI, no one knows how they are going to solve particular AI challenges until they actually get to the coal face and try stuff out. Sometimes the exploratory process discovers that the objectives are unreachable and the project is cancelled, but there can still be a win in terms of the development of new valuable expertise or capability.
Agile is..
Fig 1: Agile according to Rigby, Sutherland and Takeuchi (May 2016)
Project success using Agile (in my experience, and the experience of people I talk to) depends on the fact that the team know what they need to do, have all the skills they will need, and their broad estimates of task completion times are sort of accurate. The goal of the Agile process is “working software” and “maintain a constant pace indefinitely”, (that’s straight from the Agile Manifesto), it’s not to learn or to think or to design or to research or to explore. Rigby et al say that in order for Scrum to work “incremental developments have value, and customers can use them. Work can be broken into parts and conducted in rapid, iterative cycles.”, this is obviously not the case with exploratory projects.
Agile is sometimes seen as synonymous with innovation because it’s designed to adapt to uncertainty, however it is innovation “in the small”, it is usually only able to be innovative within the confines of each task. Of course it’s not that you can’t adapt any methodology to do what you want it to, it’s more how does your chosen framework influence you because of its particular characteristics and vocal proponents. Thus in most Agile teams I’ve seen they tend to focus on quick wins, and lose interest dealing with hard to measure uncertain tasks. A project using Agile is unlikely to be adaptive enough to declare that they need to erase the whole backlog, and change the focus of the sprint (somehow) from an efficiency focus to a learning focus.
Fig 2: Hyperbolic statements about Scrum and Innovation
Agile is Bad
What specific things in Agile am I saying that one should not employ when doing exploratory work, like innovating with new technologies? When doing exploratory work you wont have much luck with:
-
Breaking down the problem into complete list of tasks. You can do this but the task list will be wrong. You will be able to pick the first few things to do, and after completing those you can figure out what to do next, which might be dump the project because it’s not achievable, or change direction, or continue to explore.
-
Trying to quantify how long it will take you to do the (wrong) task list, or tasks within that list.
-
Trying to estimate or aim for a productivity rate or velocity.
-
Trying to get working stuff at every iteration to an end customer.
-
Having all the skills necessary to complete the current task – you are going to have to explore, experiment and learn.
You can try to do all this stuff, although the last one is by definition impossible since you have chosen to do something new and exploratory, but you will fail most of the time, and it wont be failure you can learn from.
Agile is Good
However, there are some things that come along with Agile that are very useful. When I first ran into Agile (see Larman) the predominant feature that was emphasised and contrasted against waterfall methodologies were:
-
Iterations in time boxes
-
Feedback (and learning)
-
Readjustment of priorities
This process parallels human acquisition of expertise (see Ericsson et al) and I think it’s super effective with exploratory projects.
With exploratory projects instead of having tasks completed and achieving a particular task velocity we could for example focus on:
-
What did we learn?
-
What IP have we potentially created? (eg. A new model might give us a 10% outperformance)
-
What new options have we discovered that might create business value if pursued?
There are some other “good” Agile suggestions that exploratory projects can adapt, such as giving more autonomy to the development team, but most don’t originate with Agile methodologies.
Throw away the Rule Book
One of the interesting things about Agile is how angry people get at other people suggesting that using Agile methodologies maybe shouldn’t be their primary guiding mechanism in some projects. A colleague of mine Pip Loader has a perfect quote which I think fits the issue of following strict rules, frameworks and methodologies in an innovation context. Pip says “Play in the grey”, which means bend the rules, or maybe even – don’t follow them at all.
References
-
Zhou, A, Yao, Mariya, Jia, Marlene (2017), Applied Artificial Intelligence A Handbook for Business Leaders
Ericsson, K. Anders, Pool, Robert (2017), Peak: Secrets from the New Science of Expertise
Larman, Craig (2003), Agile and Iterative Development: A Manager’s Guide -
Gans, Joshua (2016), The Disruption Dilemma
-
Rigby, Darrell K., Sutherland, Jeff, Takeuchi, Hirotaka (May 2016), Embracing Agile HBR https://hbr.org/2016/05/embracing-agile
-
Rigby, Darrell K., Sutherland, Jeff, Takeuchi, Hirotaka ((April, 2016)), The Secret History of HBR Agile Innovation https://hbr.org/2016/04/the-secret-history-of-agile-innovation