I worked both, in science and as a developer. As the latter, I often worked in projects that are organised according to Scrum or similar agile management approaches. I really wonder why scientific projects are not organised according to Scrum in general. In many projects in e.g. natural sciences, engineering or related fields software developments are common, like code to analyse data and to visualise it. Usually, scientific developments work in small steps - in fact, perfect for a sprint logic.
Why are scientific projects not management as agile projects more often?
You can apply agile but let's look aspects that are hard to apply in Data Science according to TR:
- Data Science efforts are more ill-defined and thus more difficult to estimate
- Scope and requirements may change very quickly
Yes.i agree with Agile is a Science as well as Art..
without innovation agile is not full-fill.
Hey Mario Schroeder
thanks for your reply! Would you like to share this study with us?
In science (1), software development is problem-driven, and the process is one of discovery in which the software plays a supporting role and the goals can change as discovery leads to strategy changes. Science leads and software follows. Likewise in financial, legal or medical applications (2), the software fills a supporting role and has a specialized customer base but may be more market-driven than scientific applications. In commercial or retail software development (3, e.g. consumer-facing software such as that developed by Apple or Amazon), the software development effort leads and is purely market driven. For these reasons, agile development practices apply best to (3), less to (2) and least to (1).
It's also important to have scrum meetings administered by an independent 3rd party or at least by a politically-independent corporate division. Otherwise they become political and partisan, are commandeered by one or another power center and are incrementally drawn out and morph over time into lengthy sit-down meetings that consume valuable production time.
Dear David,
I absolutely agree to your points - thank you for making this clear "Problem-classification".
Now I would like to add the question: would you deem it possible to consider whole research projects - that is including the problem statement process and the adaptation of the problem statement to ongoing findings and results as agile projects?
(that is: not reduced to the software development part)
Great issue, Martin!
My question would be: Which researcher does take a pre-defined time to simply work on one single task until it is done in a way that was defined before the task?
Discussing project management in my organization we also talked about agile methods and I think they are worth considering. E.g. a research paper could be seen as a 'product' very much in the sense of agile management going through cycles until finished.
The four things that struck me when reading about agile were:
I think the main obstacles keeping researchers from working in an agile way are:
- lacking 'definitions of done' (as they are called in agile) - mostly working against deadlines,
- laissez-faire when it comes to project management (on the drawbacks see Derue et al. 2011), and
- multi-tasking (which does not really work; see APA 2006) - reading and writing and analyzing and teaching and visiting conferences and working in multiple projects ...
APA (2006): Multitasking: Switching costs (https://www.apa.org/research/action/multitask.aspx)
Derue et al. (2011): Trait and behavioral theories of leadership: An integration and meta‐analytic test of their relative validity, Personnel Psychology (64), pp.7-52 (http://php.scripts.psu.edu/faculty/s/e/seh25/DeRueNahrgangWellmanHumphrey2011.pdf)
The book I recommend is:
Layton; Ostermiller (2017): Agile Project Management for dummies, 2nd ed., Hoboken (with a cheat sheet here: https://www.dummies.com/careers/project-management/agile-project-management-for-dummies-cheat-sheet/)
- Badges
- Science topic
- Similar topics
- Geoscience
- Asia
- India