From theory to practice
Agile might be too agile!
Turns out that theory and practice are the same… in theory
I created a blog!
New stories will be published in my blog: https://www.flavienbonvin.com/
Let’s be honest; I am nowhere near an expert of the Agile methodology, Scrum or any other project management technique. The only experience I have come from my lessons at the Uni and the projects I realized while studying. During those projects, I mostly used the Scrum framework and some basic tools; we even had to use Excel for our very first project!
Now that I am working (part-time) while doing my Master degree, I had the opportunity to see how the company I am working for organizes IT projects. The goal of this article is to highlight the differences between what I learned and how I used the methodology in my work.
Besides, I had the chance to spend one day during one of my lessons with Nedjma Saidani, who is an Agile coach and a Scrum trainer. She gave us a lecture on product ownership and the subsequent responsibility of the role.
Let’s focus a bit on the lesson I had with Nedjma. Since my classmates have different backgrounds, our day started with a quick explanation of what is Agile, and more specifically, the Scrum framework. She explained the roles, the manifesto, the principle, and the different meetings that occur during a sprint (and a day). It was a quick and welcome refresh for me. After that, Nedjma explained what the current state of the Agile methodology in Switzerland is, and she was clear.
Agile is a buzzword… Companies use Agile instead of understanding and adopting its mindset
Agile Is a Buzzword
Naturally, our professor did not say that without giving arguments and explaining what makes her believe that the Agile methodology is not entirely (or correctly) implemented. She argued that the companies overused the word without really understanding what it meant or that only a part of it is used.
She explained that in Switzerland, people care about 3 things while developing a product: cost, delay, and scope. I directly connected with what she said, we love having deadlines in Switzerland. It is hard for us (and me) to evolve in a situation where we know that something is coming, but we cannot be sure when exactly.
This is something we like, and old habits die hard.
That’s only while doing my Bachelor degree that I understood that a software is a living creature; I also learned to appreciate the benefits that are brought by the Agile methodology. If I explain this now is to show that I had to do IT specific studies to understand what Agile meant. It is natural for someone coming from a different industry (and different project management techniques) to feel lost when we try to sell him sprints.
I have to admit; hearing Nedjma saying that Agile is a buzzword confused me. It confirmed some of the observations I made during my job hunt and while working on the first projects in my current job. Agile is everywhere, on the job offer, during meetings with clients, in the contract and the documentation of the project. I never asked myself of what was Agile, and what it involved, I embraced it during my Bachelor and implemented things that my professors taught me.
However, after that day, I asked myself if Agile is too agile and if more rigid guideline would not be beneficial.
Agile is a mindset
Nedjma explained that most of the companies think of Agile as a project management methodology were, in reality, it is a mindset. Often companies start implementing a Kanban or a product backlog and voila: they are agile! This cannot be further from the truth; adopting the tools is only part of the process to become Agile. A business has to shift from a delay, cost, and scope to a value-oriented mindset.
As I said before, old habits die hard!
This change of attitude brings another challenge to the table, instead of focusing on the Holy Trinity (cost, delay, and scope) companies focuses on the values they are producing. Instead of trying to implement every detail of the specifications, companies start to focus on the value they are adding to their product. Working with sprints motivates every actor implicated in a project to find purpose or impact for it, it must count and deliver something new.
Of course, this does not mean that the specification sheets are useless; it is essential to have a clear vision of the product you are creating. However, the product backlog provides an easy way to see what’s the next feature to implement is.
I recognize that I never understood everything that Agile was changing when comparing it to another project management technique. During the projects I worked on in the Uni, I never thought of the value brought by the sprint, we used the product backlog to track features to implement. However, I find amazing the change that companies have to make to adopt Agile; it requires a lot of courage and trust in the coach who accompanies this transition (I guess that coaches are mandatory in this situation). I also understand why this is the hardest step of the process. We oppose resistance to the change, even for small one, so adopting a new mindset is genuinely demanding and requires many efforts.
Is Agile too agile?
Just before giving details about my current job, I want to assure you that my job is excellent, I genuinely love working in my current company. My coworkers are talented and passionate about their job. I also want to say that our clients are great, and I understand that some of them are surprised by the Agile methodology! As I wrote above, we cannot expect everybody to know about Agile. Some of our clients work in a different industry with their project management methodology, I would not allow myself to judge their techniques.
I operated on four different projects since January, and all of them were very different. I worked on a mobile application and three websites. Each of our clients called himself Agile. However, I discovered with the help of Nedjma that this statement is somewhat false. Of course, a product backlog was involved, but we never focused on it, we developed the features while following the specification without much involvement from the client.
Besides, when we make an offer to a potential new client, we never sell them sprints, we consistently sell a given number of days. I cannot blame anyone, this is frightening to buy three or four sprints instead of 30 days of, but the result is the same (in terms of days). One thing that is not the same; however is the relationship we build, the client will be more involved, and we will have more frequent feedback and discussions about what we are doing.
I think that’s while doing my bachelor degree that I experienced something that is closed of the Agile mindset. We were simply friends building a website or an application in sprints (some of them can be found on my GitHub if you are interested). The sprints were not always respected (we often underestimated our velocity; this can be explained because we did not track the time spent working), but in the end, the experience was stimulating and thrilling. I remember a discussion I had with one of my friends; I hoped to find a company that could provide the same kind of energy and vibe as the one I experienced during my projects in the Uni. It was just too fun and exciting!
Here are the benefits I saw while working as I did during my Bachelor; they can be resumed in two words:
Connection and trust.
I would feel connected with the project; we would work from one sprint to another deciding at the end of each one if the project is up to the client expectation or if more work is required. This kind of constant movement is challenging and keeps me motivated over long periods. It connects me with the project in a very different way; it is like growing together; it will become more polished up until it is mature enough for our client.
This kind involves much trust between us (the developers) and the client, without absolute trust, we cannot produce a quality product. The client must be involved in the project, and the discussion has to be open and respectful. We have to put some technological boundaries when required, and the client has to tell us when something is not right and needs attention. This kind of relationship that is built with our clients is fantastic, we are working hand in hand to make his idea a reality.
While writing this section, I feel both as a young and innocent software developer living his first projects or as a future entrepreneur who will find this kind of environment only if I create my product (with friends of course). I am also aware that this highly ideal world I am picturing might be hard or even impossible to achieve (let’s talk multi projects or support).
In the end, I think that I had the answer to my question from the beginning; the beauty of Agile is in the name. Right under my nose, literally in the name…
Agile is excellent because we evolve in a complex world, and being able to have some slack is essential. There is no one-size-fits-all project management methodology, and Agile provide this flexibility. That’s what’s Nedjma told us since building software is sophisticated, we need to have a way to make it easier both for, the developers and for the clients, and this is where Agile shines.
The beauty of Agile is in its name. Agile is great because it is agile!
What’s my Point?
This article took an unexpected direction (as usual), at the beginning I wanted to share the experience I had during my lesson with Nedjma and how I loved the way she challenged our preconceived ideas (at least for the people already familiar with Agile), and it transformed in me sharing my vision of the methodology with the little experience of mine. It also made me realize that the strength of Agile against other project management techniques is its agility.
It is great because it enabled the creation of multiple other techniques, like the creation of an ecosystem of methods, tools, and concepts gravitating around the “Agile star.” Anyone can then choose the framework that best suits them.
However, this freedom created confusion to people that are not familiarized with it, making them think that Agile is so flexible that it is possible to pick any part of it without seeing the big picture. I deplore that so many people do not fully realize what can Agile bring to their project; this would make our work and our collaboration way easier. Agile could also frighten the people that are conscious of the involvement required to perform the switch. Having to convince collaborators that might not see the benefits right away is a long process. This human factor is always hard to deal with and cannot be underestimated, feelings have to be taken into consideration to make this process as easy as possible.
Writing this article also made me realize that the methodology has a lot to offer to many people. Of course, it cannot apply to every industry and to every client that I will work with during my career, but I hope to use it as much as possible. At least as long as no other better method emerges. Because in the end, Agile is excellent because no better or easier methods exist yet.
Since I am new to this professional world, I would be more than happy to share your views on the points I made in the article. Feel free to comment below!
I want to sincerely thanks my professor Nedjma, who took the time to proofread and give feedback about my article. If you want to find out more about her, you can find her on LinkedIn or the Scrum website.
