Hi there!
After the previous dissertation posts (https://diogodanielsoaresferreira.github.io/), I noticed that the agile principles were the basis of some tips that I gave. There are remarking similarities between my tips and some agile principles. However, many people still fail in getting a good experience out of the dissertation because they don't apply these principles. In this post, I will explain how the 12 Agile principles relate to the dissertation, and how to apply them to achieve a better dissertation.
For all that don't know what Agile is, here is a quick explanation.
What is agile?
The Agile Manifesto was created in January of 2001 in a meeting in a Ski Resort, in Utah, by a restrict group of software development experts, such as Bob Martin (Uncle Bob), Kent Beck and Martin Fowler. The goal was to discuss lightweight practices for software development, to allow for better and faster software development.
The agile manifesto is not a set of rules which you must strictly follow, neither a set of tools that you must use. Instead, it is a set of recommended principles that aim the collaborative development for a software project. It is based on iterative and incremental development methods, introduced many years before the Agile manifesto.
Let's go through the 12 Agile principles and I will explain how I think that they can be applied - or not - in your dissertation.
1 - Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
This principle must be broken down into parts for better understanding.
"Our highest priority is to satisfy the customer" - Who is the customer in a dissertation?
The customer is always the entity that decides if the software is as good as requested. In a dissertation, the customer is the jury. Not only your supervisor, not the whole academia, and certainly not your dissertation presentation audience. Always have this in mind when writing the dissertation. The highest priority is to satisfy the jury to have a good grade."through early and continuous delivery" - How to approach early and continuous delivery?
Early and continuous delivery in a dissertation means to deliver work at a regular pace, following a defined plan with time-bounded activities. For a student, early and continuous delivery means not to leave all the work for the last week. This avoids unexpected difficulties that delay the work, by working through them and planning them with time. Besides, it avoids the regular last-week-sprint burnout. Most importantly, it gives your supervisor an idea of how your dissertation is going long before it ends and allows to change the requirements to improve your work.-
"of valuable software" - What is valuable software?
In a dissertation there are two types of "valuable software":- the dissertation itself
- additional work (software, data analysis, study, ...)
Both of them should be approached to satisfy the jury through early and continuous delivery.
2 - Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
In a dissertation, this is a very important difference from enterprise projects. In enterprise projects, we should welcome changing requirements because the client pays for the software, and the software is designed for the client. However, most of the dissertations are individual work, and most of the requirements are defined by the student. Although the vision, scope and main goal can be defined by the supervisor, the main requirements are usually defined by the student; besides, a big advantage of the Agile processes does not happen for the dissertation. In an Agile environment, there are regular meetings between the development team and the client. In a dissertation, the client is the jury, so the meetings will be only with the supervisor. Besides, every time that the supervisor asks to change something, it can change your timings for the dissertation deliveries and presentation. So be careful with changes. If you change the requirements of your dissertation, go ahead and apply that to your work. However, if new requirements are added by the supervisor, think carefully if they make sense, and feel free to discuss with him/her his validity.
With one month left for the delivery of the dissertation, however, I would advise you not to make major changes in requirements, because your delivery can be at risk. Before that, feel free to test and try new things, and add them to your work if they are useful.
3 - Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
This principle can be adapted from "working software" to "readable pieces of your dissertation". Yes, the dissertation should be made incrementally, and although sometimes it can be hard to write consistent texts without having all the research and implementation done, leaving all the writing to the end it is usually not a good choice, because when writing you will think about new possibilities that can enhance or change your work. You can even detect flaws that you left unnoticed when implementing your work.
Because of that, you should write everything that you do. Even if later on that part can be deleted because it is out of scope, or it is not used - it doesn't matter. If you are working for your dissertation, everything that you do is important and needs to be in the document. With that, you will deliver "readable pieces of your dissertation" incrementally, and later on it will be much easier to rewrite (if needed) and organize your dissertation' chapters based on the text that you already have.
But what is frequent? What should be the time interval to deliver work? Just like in Agile, it depends on your work, of yourself and your supervisor. However, I would argue that a meeting once a week with your supervisor to show him/her what you have done is a good time interval. It gives you time to show the work that you did that week and to discuss what to do in the next one. Two-week meetings are also a reasonable choice, but more than two weeks is too much. You can get lost, do something that is not in the scope of your work, or just don't know what to do, and it will only be discussed in the next meeting. Prefer short weekly meetings to long monthly meetings.
4 - Business people and developers must work together daily throughout the project.
This principle is simple and logical: you and your supervisor must work together. Working together does not mean that your supervisor should start doing your dissertation - it just means that each one must do his job to reach the desired output. You must do your work and your supervisor must supervise you, advise you, guide you, help you when you need, give you the tools you need and stop you when you do anything wrong - not just give you the requirements and wait for what you will do.
I need to emphasize "throughout the project". Just like in the last principles, "throughout" implies a consistent work discussed in regular meetings over time.
5 - Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
I am going to split this principle into two sub-principles. Firstly, to build projects around motivated individuals is to assure that you and your supervisor have the motivation needed to do your work. Many things will go wrong - they always do - and what separates a great from a median work is your willingness to tackle the problems and to work around them. It is not expected for your work to follow a straight path, and you should explain your difficulties in the dissertation, as well as how you tackled them to achieve your goal. An unmotivated student will just avoid the difficulties and find an easy way out.
The latter part of the principle is about trust and support. Make sure your supervisor trusts you. Be totally honest with him/her, explain regularly your difficulties and don't be shy to ask anything you need. Do you need a specific GPU, a virtual machine, or anything else, just ask him/her. He/she is there to help you with anything you need that is out of your control. Don't be afraid of saying that you spent a week and you didn't understand a topic or a paper. Trust him/her to help you do your dissertation.
6 - The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
Regular face-to-face meetings are the most efficient way to adjust your work with your supervisor's expectations. Sure, e-mails and chat messages do come in handy for quick and small questions that you may have and you need the answer ASAP, but nothing beats a face-to-face conversation. Video-conferencing is another way to hold meetings, but it should not be a common way. It should only be applied when one of the intervenients is temporarily away.
7 - Working software is the primary measure of progress.
As I said above in 3, "working software" in this case can be adapted to "readable pieces of your dissertation". Yes, there are other ways to measure your progress, mainly based on your work, and they vary on a case-to-case basis. However, what will be evaluated is your dissertation, so the dissertation is the ultimate measure of progress. Start writing as soon as you start doing some work, even if the work is still not finished. Because if have a lot of work but you do not write about it, your work will not be taken into account and you will end up with a poor dissertation.
8 - Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
This principle is very important for a dissertation if you want to reach the end of your work without feeling burnout. It is very important to keep a constant pace of work. It is Ok to work more than 8 hours a day once a week, but not more than that. It is important to separate your work from your personal life for you to feel accomplished and for not getting obsessed with minor obstacles that may seem like the end of the world. Impose on yourself a 40-hour week schedule for work and follow it. If you don't do it, you may end up working tirelessly for your dissertation but with very low productivity. It will harm not only yourself but also your dissertation.
9 - Continuous attention to technical excellence and good design enhances agility.
This is something you should do not only in your dissertation but also in your future career. If you plan carefully your work and if you work with pride, it will reflect on your dissertation and presentation. Even if you do not notice, experient people in every area acknowledge and know how to differentiate between work done with pride and work just to pass the subject. Technical excellence differentiates the median from the great workers in every area - and that can be the difference between an 18 and a 20 in the dissertation.
10 - Simplicity--the art of maximizing the amount of work not done--is essential.
I love this principle. Because everyone mistakes "work with pride" with "you must do everything that you have planned for your dissertation". That's why you plan things: to prioritize what is important and to do things in importance order. If a specific feature will take two weeks to be done and it will not make much of a difference in your dissertation, then why doing it?
The Pareto Principle, also known as the 80/20 rule, says that approximately 80% of the effects come from 20% of the causes. If you pay attention to your life, this principle applies to many things. In your dissertation, 80% of what you will write will be based on 20% of the work. Besides, 80% of your grade will be based on only 20% of your dissertation. Pay attention to that and focus on what's important - identify your 80% and make them shine. If you have free time, work on parts of the other 20%, but don't waste much time with them - they are not that important.
11 - The best architectures, requirements, and designs emerge from self-organizing teams.
The dissertation is a one-person work (two with the supervisor), so it may look that this principle does not apply to the dissertation. However, you have to look at yourself as "your team". Because the work is yours more than anybody else, you will have the last word on deciding the architectures, requirements and designs, so do it wisely. Do not accept architectures that are imposed by anyone if you do not agree with them, because you are the one who will have to answer for them sooner or later. Don't be afraid of creating your own architectures or requirements if they make sense to you. Self-proposed implementations are much valuable in a dissertation and show that the student has deep knowledge about the topic.
12 - At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
You should use this principle with yourself. Sometimes we work so fast and have so many things to do that we forget of reflecting on what we did well and what we need to improve. Once a week take 10 minutes to think about what you have done in that week, what was correctly done and what can be improved. After a month of retrospectives, you will find it very useful to improve your work habits and you will be amazed when checking your performance improvement simply by thinking on what you did wrong and taking preventive measure to not happen again.
That's it, thanks for sticking by until the end.
See ya on other posts!
Latest comments (0)