How to be Agile when writing your Master Thesis

Why should you read this story (always starting with why)?

• You will find out how being agile helps getting the most out of academic work.
• You will read about a concrete example from a recent master thesis, that can inspire both students and supervisors to try some agile practices.
• You will be provided with interesting pointers along the way.

Part I: From software professionals to academia

An iconic article from the history of agile from 1986. Jeff Sutherland, co-creator of Scrum, states that Scrum was directly modeled after this paper.

Manifesto for Agile Software Development turned 18 this year. Even though there are people that would visit Snowbird Ski Resort in the Wasatch mountains of Utah — where the Manifesto was crafted — as their Mecca, the movement dates way back than that. The first paragraph of Hirotaka Takeuchi and Ikujiro Nonaka’s iconic Harvard Business Review article dating January 1986 goes:

In today’s fast-paced, fiercely competitive world of commercial new product development, speed and flexibility are essential. Companies are increasingly realizing that the old, sequential approach to developing new products simply won’t get the job done.

Agile removes the heaviness of the traditional development methodologies, in order to promote quick response to changing environments.

Although the research community devoted a great deal of attention to it, agile is not a concept that is invented in the academia and then transferred to industry. It is something that primarily came from software and product professionals.

Part II: Do you need a manifesto for being agile?

Taking the manifesto concept and re-branding for another area is not a new thing: agile HR manifesto, agile marketing manifesto, agile business manifesto, beyond budgeting principles, and even beyond agile manifesto suggested by Kent Beck (one of the signatories of the original manifesto and the brain behind extreme programming) in 2011.

Obviously, enough googling will help you hitting a manifesto that is modified to fit the academic work. Here is agile research manifesto that is using exactly the same format of four value statements and twelve principles of the agile manifesto, by Xavier Amatriain.

If you are too lazy to read all principles in a new manifesto, I would recommend performing a simple diff to see the differences to the original manifesto.

I would say, one does not need a manifesto for being agile in a domain, nor abiding a manifesto automatically makes you agile.

Part III: What are the benefits of being agile in the research context?

There are certain behavior that come natural to a researcher such as being curious and having a questioning mind, in addition to certain other behavior that the publication system require such as courage to accept feedback and willingness to improve.

On top of that, there are tangible advantages of being agile. Below is an incomplete list of benefits of being agile in the research context.

• Faster time to academic market: as in the industry, if you have a good idea or a good approach, then you need to be fast in delivering that to the community by different means.
• Increased academic value: If you prioritize your work based on the value, and incrementally deliver results, you would ensure that academia and eventually the society will receive the greatest value out of your efforts.
• Reduced waste: Iterative research, short iterations, and faster feedback will reduce the risk of waste in your work.
• Better quality: Although quality can be interpreted in different ways, continuous and relentless improvement in the process and ensuring close collaboration of researchers and applying technical stakeholders will result in better quality regardless of your definition of good quality research.

Part IV: A good example from a very recent Master thesis

Mads Schnoor Hansen conducted his master thesis studies in computer science, contributing to a large project — Quality of Life — headed by associate professor Katarzyna Wac, in the University of Copenhagen. The research and development task at hand was unfamiliar to him and together with his supervisors they expected unforeseen challenges and changes along the way. Hence, being agile was necessary! They stuck to the values and principles that are common to agilists, and synthesized practices from various different development methods:

The Quality of Life technologies lab, founded and headed by Katarzyna Wac (fourth from the left), conducts research at the University of Copenhagen, University of Geneva, and Stanford University.

• Small cross-functional team: team of five, combining skills in theory and practice
• Iterative development: pulling work into iterations of two weeks — not planning everything upfront
• Virtual Kanban board: visualizing the status of work items in an iteration (they used Trello as a free solution)

A virtual board with states Backlog (not pulled into iteration), ToDo (pulled into the current iteration), Doing (work items in progress), Blocked, and Done.

• Sized work items: relative estimation for work items (they used story points and agile poker)

The team used the original (not modified) Fibonacci Sequence for relatively sizing the work items. And to do that, you do not need any fancy cards or apps, just use standard cards (ace, 2, 3, 5, 8) and overload King as 13, Joker as 21 (or infinity). From left to right: Mads Schnoor Hansen, Jamshed Gill, Vlad Manea (co-supervisor). Ece Elbeyi and Katarzyna Wac (supervisor) were also part of the team, though they are missing in the picture.

• Technical excellence: white board discussions around architecture, XP practices such as pair programming, different levels of testing

A state machine annotated with data security details.

System design.

Retrospective

One of my recent aha moments is while reading Fearless Change (authored by Linda Rising and Mary Lynn Manns) where there is a quote from Anne Frank’s diary:

How noble and good everyone could be if, every evening before falling asleep, they were to recall to their minds the events of the whole day and consider exactly what has been good and bad. Then without realizing it, you try to improve yourself at the start of each new day.

I guess I was too young to see the wisdom in the lines above, when I first read the diary. Now looking at it, I cannot formulate a better way of explaining retrospectives and continuous improvement.

When Mads and his team recall the events of the whole master thesis and consider what has been good and bad, they see a lot of benefits of being agile throughout their study. As they expected in the beginning, many things changed along the way, and they could adapt with minimum waste and maximum value.

Did you find this interesting? Then please share it with someone you know that is about to start a timeboxed academic work. Do you have questions? Then please leave a response below. Thank you for reading!