In the software development world using the Agile approach is as obvious as breathing. But do we know exactly what Agile means and if it always works as intended? Can Agile truly accord with every software development project? Let’s take a look at a short description of what Agile is and what problems it was expected to resolve.
The agility concept started in the sector of software development to address the variable nature of software products and the uncertainty and difficulty of defining requirements at the beginning stage of the project. But it should be emphasized here that Agile itself is not a methodology. It’s an approach, a kind of philosophy, which gathers values and principles leading to the delivery of good quality software development products in the VUCA world. Agile is an umbrella term for methodologies that follow the Agile Manifesto, the document that started everything. It contains 4 key values and 12 main principles which, in a nutshell, allow teams to deliver value-driven solutions to fulfill customers’ needs.
There are many different types of Agile methodologies that you can choose from when you start a software development project. The most common are Scrum, Kanban, Extreme Programming (XP), Feature-Driven Development (FDD), Dynamic Systems Development Method (DSDM), Crystal, or Lean. According to the newest state of Agile report 95% (!) of respondents say that their organization practices Agile development methods. As the report states: “Scrum is the most widely practiced Agile framework, with at least 75% of respondents practicing Scrum or a hybrid that includes Scrum.”
It’s worth mentioning here that Soldevelo as a software development company fits that global trend. For a few years, we‘ve been using Scrum in almost all our projects. The beginning was difficult, but over these years – and still to today – we’ve been doing our best to become Agile masters 🙂 We focus on the continuous learning process, starting from basics like Scrum certifications (70% of our technical staff is Scrum certified). We are in the habit of learning lessons from our mistakes and day by day – or rather sprint by sprint 😉 – increasing the effectiveness and quality of our work.
And based on our experience what can we say about using Agile in software development projects?
In theory, everything looks great and easy, but implementing Agile into practice is neither ideal nor simple. Following for instance the Scrum framework, in the Scrum Guide we can read that Scrum is simple to understand but difficult to master. And, unfortunately, that’s very true! It seems that the main reason Agile fails in software development projects is that it is used when it simply doesn’t make sense and can result in more problems than value.
It usually happens when:
- projects are small and not too complex
- from the very beginning, it is clearly known what should be delivered and any bigger changes in scope are not expected and/or not welcome
- clients and/or end-users can’t be truly engaged in the development process
The second area that usually impacts Agile processes and causes some difficulties in implementation are related to the project environment. A few key conditions have to be met to let Agile flourish and provide the value that is expected.
Agile definitely won’t work properly when:
- the team is not self-organizing and lacks professional developers
This means that a team that consists only of junior developers, who have never worked in an Agile way plus have no dev experience, even if supported by a great Agile Coach, won’t achieve great results in their project… at least at the beginning 😉
- there’s no engagement and understanding of the Agile approach among team members, especially among developers themselves
A team whose members don’t want to do anything more than coding, who don’t believe in Agile and don’t want to improve anything besides technical skills, even if called an Agile team, in truth has nothing in common with the real Agile and definitely won’t bring any hoped-for value.
- there’s a lack of developed standards of work matching the Agile approach, often connected with no training or inadequate preparation to work in an Agile way
Without appropriate preparation, there’s no way to work Agile! Simply saying “from now on we are Agile” and only being ready for change are unfortunately not enough. The training process, certifications, coaches or mentors, and change agents are a must before you start using Agile on a daily basis.
- there’s a lack of or insufficient support from company management and leaders when it comes to spreading the Agile spirit within the whole organization and among teams
Sometimes it’s just easier to pretend that the company practices Agile than truly work on changing project processes and spend time and money on training. The Agile spirit has to be noticeable everywhere in the workplace and only then can be genuinely adopted and bring value.
- the client doesn’t understand Agile, or even if they do the uncertainty of what would be delivered is an excluding factor for them to use it in their project
Even if your company, your teams, your managers, believe in Agile, and you’re perfectly prepared for it, your client might be not so convinced. In that case, forcing Agile on them is likely to have adverse effects. If the client prefers less risk, wants to plan everything beforehand, and wants to be sure at the beginning of what they’re paying for and what is going to be delivered at the end – that’s fine! Agile is not a suitable approach then, no matter how much you want it to be so 😉
The world is changing rapidly and Agile is a natural answer to these changes. But before you blindly start implementing this approach in all your projects without any preparation or thought about if it truly fits your current needs, it can end poorly. Agile is trendy, without a doubt, but it won’t resolve your problems with delivering good quality software. It’s not a wonderful remedy, which in the blink of an eye converts your team into Agile heroes, who will create an incredible solution just like that. Using Agile may change your perspective, may change your process of delivering software, may show you how to learn and improve on a daily basis. However it is intended to work under certain conditions, and only you can assess if it may help your project or make it even more difficult 😉