Agile/DevOps: a better path for R&D?
Imagine having to cross a crowded ice rink with lights dimmed and lots of people showing off figures. Predicting at the beginning when you will reach the other end at the very start would be nearly impossible. A better approach would be to redefine the trajectory regularly, keeping the destination in sight. This is the difference between an agile and a traditional approach to reach a goal.
- Traditional R&D: dreams vs. reality
Industrial Ph.D. story: a young student comes to do research abroad attracted by a vigorous proposal that got funding. Milestones and goals are very well detailed, and the supervisor has a strong CV in the field. Big enthusiasm at the beginning as academics meet managers from industry: they promise bright futures upon success. It is the moment of dreams. How many of those will become reality 4 years later when the thesis is submitted? The answer is very well documented in Ph.D. Comics 😊. When it comes to traditional corporate R&D, similar patterns can be observed. The 6 stages of project management [1] are a hard reality I witnessed multiple times, and I don’t think I am the only one.
- A better approach from the Open-Source community
Systematic failures indicate that changing people will not help reaching goals, changing the system will. Detailed initial plans were never supposed to work on a long term. Imagine having to walk through the darkness of Brussels central square at Christmas during the light show that gets the place packed with people looking up to art projected on the surrounding buildings. If you plan the walk from the beginning, that is the moment when you will know less about what you may or not encounter. But still, you can plan the few next steps passing through some tourists taking pictures and advance for few meters. Then plan again from there the next few steps. This is called iterative planning. When comes to software engineering, this approach would be called “agile”. Unlike the traditional “waterfall” approach[2] generally adopted by traditional R&D, the agile way of working has characterized the Open-Source community, and it has recently been formalized into methodologies such as Kanban and Scrum[3].
- Cultural change vs. new tools and roles
Why this approach is not widespread (yet) and so called “agile” teams still regularly fail?
1) The most common way to fail: assigning roles without training (Kanban board turned into a GANTT chart, time assigned to user story points…)
Imagine calling a project manager to be a DevOps engineer and giving a one-week (or shorter) training using AWS or Azure DevOps services. This improvised new management figure will simply try to adapt those tools to what he/she is used to. GANTT charts, points used as estimation of the time to spend for a task… So lack of proper training and little understanding will be a proven recipe for projects failure.
2) Bypassing some of the rules.
The scrum master is also the product owner? Members are pulled into several projects leaving some unfinished? User stories are carried from one sprint to next one instead of being redefined? Stakeholder feedback is very rare or doesn’t come at all? A good practice once you master the agile development principles is to write down a checklist of do’s and don’ts. This is a good prevention of future inconvenience do to misapplied practices.
3) Dev but not Ops
When it comes to software development the wall of confusion between development and operations is something that historically got several projects to fail. Failing per se is not a problem if your mean time to recovery (MTTR) is short. This holds true for R&D in general. That is why high-tech pilot plants can save the business of large industries.
4) Non-actionable metrics
A metric should be an indicator of what to do next. MTTR cited above is a good example. A simple product sales figure is not. A better way would be AB testing, where the product is sold with or without a modification to a pool of customer [4].
- Conclusion
The digital era is no more the future; it is the present. AI today is what was the Internet in 1996. This implies not only the use of new tools but also rethinking the strategies that bring to the development of modern tools and technologies.
References
1) The Six Stages of a Project!! | LinkedIn
2) Agile vs Waterfall — Difference Between Methodologies (guru99.com)
3) Agile, Scrum, Kanban: What Are They? | Toptal®
4) A/B Testing: How Retailers Can Optimize Their Sales With Experimentation (shopify.com)
