I want to share this interesting story about Agile with you because I think there is a lot of misconception about Agile mindset, methods, frameworks and how and when to apply them.
I attended a BID phase to win a customer deal recently and had some quite interesting experiences about how to run a project and how to deploy the solution.
As an Architect it is my responsibility to make sure the solution I am designing has also methodologies built in that facilitate the successful implementation of the former.
During the planning in the BID phase we talked about the project and development methodologies to be applied. I was the one who pushed to apply Agile methods during the T&T (Transition & Transformation phase) of the project but I must admit I was utterly wrong with my opinion during that time.
Let me explain you why.
Disclaimer: I am not a Guru or even close to the entirety of Agile. I am learning Agile, DevOps, etc. for 3 years now and I am sure I still have to learn a lot. Please feel invited to share your ideas in the comment section!
What is Agile?
First we have to clarify what Agile really is.
There are basically four categories to keep in mind about Agile:
- Mindset
- Methods
- Frameworks
- Tools
This is not supposed to be a comprehensive overview but more a summary!
1. Mindset
The Agile mindset we know today probably has different origins but the most notable we know of is the Agile Manifesto (formalized 2001). The Agile Manifesto outlines 4 core values and 12 principles to follow upon when developing new software products.
Here we can see already this “mindset” is aimed at software development but having an Agile Mindset should be mandatory nowadays for everyone in the IT, because the values and principles transport way more than just a guideline for software developers.
Another Agile Mindset is probably the term DevOps. Wiki states it is a set of practices and here we start diving in already to the different views one can have on Agile. As mentioned before the Agile Manifesto contains values and practices. In my personal opinion DevOps and all its derivatives (DevSecOps…etc) are a also a mindset (maybe a more concrete one) where Agile gets applied to a certain IT process. In the case of DevOps, the mindset changes our “way of working” between Development and Operations.
Now, once you drill down from a mindset obviously you want to manifest that somehow. You will need methods, which I will address next.
What can we learn from this first part?
Agile or DevOps is not a technical “tool”, it is a way of thinking. There are of course tools out there that facilitate these mindsets.
But as always: Your mindset changes things not the tool!
2. Methods
Next up we need to talk about Methods. Once you’ve decided to adopt an Agile Mindset you surely will be looking for a method to apply it in your organization. Certainly you could come up with your own set of methods, but it is more easy to use something “of the shelf” for your first run.
Methods you probably heard about before are SCRUM and Kanban.
Kanban was there way before the Agile Manifesto was formalized but it contains already ways of working like Agile promotes it. When you follow down the rabbit hole you will also find your way to the House of Lean. Some of you may know Kanban boards which are very useful for planning, monitoring and managing your WIP (Work In Progress). Again Kanban is primarily a method and tools (Software) exist to facilitate that method.
SCRUM was also formalized before the Agile Manifesto and again you will ask yourself, why I am stating that SCRUM is a method while Wiki states it is a framework. In my working environment SCRUM is a method for us. I will try to explain this later in the “frameworks” section. Same as with every method tools exist to facilitate it.
3. Frameworks
When I think of a Framework (in IT and especially software development) I think of a construct that takes existing methods as building blocks and tailors them together to facilitate especially large scale software development projects.
One example of such a framework is SAFe (Scaled Agile Framework). SAFe incorporates SCRUM, Kanban and DevOps to name a few. SCRUM has also a derivative that addresses the challenges of large scale software development projects called Large-scale Scrum. Here we come back to my point in the methods section. To me SCRUM is a method while Large-scale SCRUM is a framework, which contains the SCRUM method.
4. Tools
The list of tools you will find online is endless. As always you can choose “best of breed” and you will also find “platforms” that are like a Swiss knife for developers and Agile project managers in one. I will not recommend any but I want to use this chapter to emphasize on some important aspects of Agile and the tools that facilitate it.
“A tool to support Agile methods alone will not bring you the expected results”
“Start with your mindset! Your mindset has the biggest impact of all.”
What I had to learn?
Agile methods and frameworks like SCRUM and SAFe are high precision targeting systems, which aim at software development in a world of uncertainty. Applying those methods/frameworks to projects with clear requirements and a clear scope, meaning almost no uncertainty, can wreak havoc among your project and staff.
“Don’t apply Agile methods/frameworks onto any project just because you think the world is Agile now so your projects must be all Agile too!”
Sometimes, even nowadays where everybody is screaming Agile from the rooftop it can be way more sensible to follow upon a Waterfall or an Iterative method instead an Agile. It really depends on your clarity on the scope and your level of certainty.
This LinkedIn article contains a good graph that guides you on how much Agile you really need.
How we finally did it!
In my case we had those clear requirements from the customer. We also have a straight forward solution with defined products of the shelf, which we only have to tailor together.
To be more concrete, the project contains an IaC (Infrastructure as Code) and a DaaS (Desktop as a Service) part. Even though we have to develop playbooks and scripts, our APIs are clear and the requested Self-Services from the customer are well defined.
In our case we chose to adapt a Waterfall method to deploy the IaC part and an Iterative approach to tackle the Self-Service-Requests one by one.
The project promotes the Agile and especially the DevOps mindset. We also use technologies like GIT repos, CI/CD pipelines and Kanban boards to facilitate our work but that is as far as we go in terms of Agile.
We don’t apply SCRUM or even SAFe. We will leverage some Extreme Programming practices but only to a certain extend.
From my own experience with customers who have been using agile methods (including SCRUM) successfully for a longer period of time, the following, sometimes negative, points stand out: 1. An attempt is made to use agile methods or SCRUM for all projects, or to replace classic project management with them . This is a big mistake! Only a mixture of both methods can contribute to the success of a project. 2. Agile / SCRUM methods cannot be used for some projects. 3. Only when the upper management understands the agile methods and is willing to support them, can agile lead to success through all project levels.
Summary: Agile methods are helpful, but can be dangerous if used incorrectly.
Thank you for sharing your thoughts on this Oliver!
Very interesting also for not IT specialists, go on, gratulation for the first report on your blog. I wish many lively exchanges. M.