It’s been quite a while since the first time I heard about agile methodologies. At that time, it sounded strange and encouraging at the same time. It looked like it was the big solution to our problems: someone had found the silver bullet for software development. When the word started to spread out, you could speak to professionals with fundamentally different views. Some of them had never heard about them or didn’t have much interest. Some (like me) have searched a bit about the agile concept, but were at some point between scepticism and the hope of finding a new approach to solve our problems. Others (a few), correctly or not, took it as an everyday practice for their teams. And of course, there were some that liked it so much than they devoted themselves to spread the agile word and evangelize the rest of the mortals.
In this post I’ll briefly explain what the agile methodologies are. To do so, there’s no better way than writing what somehow was considered the agile Ten Commandments at the time, authored by the biggest names and called Agile Manifesto:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
One of the manifest authors were Martin Fowler. In his blog, Fowler gives two big reasons to explain the advantages of agile development over the traditional one (read Martin Fowler’s post). To my view, they are key rules to understand the agile methodology:
- Agile Development is adaptive rather than predictive
- Agile Development is people-oriented rather than process-oriented
To sum up, we could say the agile method looked for a new way of developing applications. This new way took as a basis the experience of experts who had learnt and stated that developing software by following a strict and procedural plan based on generating loads of documentation didn’t work. The main mistake was to understand software as something that can be defined and planned from the very beginning and following a plan without changes. We all know that’s not true. Therefore, the agile methods considered as a general principle that customers would never know for sure what they want until they start to see it. In response, agile development came up with solutions that left processes, tools and documentation in the background, while putting the customer in the centre of the project, embracing the change from the beginning and just aiming to build software that works as the customer needs.
Now we’ve explained what is agile, I must confess this post is precisely about the opposite: what is NOT AGILE. To do so, I’ll list the practices that I still see in some self-proclaimed agile teams (in coming posts we’ll take a close look at the practice and tell you how we apply the agile method in BeLike’s everyday):
- It’s not agile to clearly follow a classic waterfall methodology and use words like ‘user story’ or ‘sprint’ in the everyday team, when actually you’re not doing a proper and real use. You’re using concepts that don’t work properly together and may lead to confusion and a decline in the productivity of your developers.
- It’s not agile to hear once the requirements from the product owner (two or three times at most) and never see his/her face until you achieve the ‘validation’ phase. Remember, people-oriented. To be really agile the product owner must be seen as a friend and he/she has to take part in the development process.
- It’s not agile to stick to the initial plan. It does not make any sense to say you’re following an agile methodology in a project and then not to accept customer changes. The sooner you accept the customer does not know what he/she wants until he/she has it, the better for you.
- It’s not agile to show the application to the customer when it’s almost finished and in a “demo environment”.
- It’s not agile to separate the test from the development process, spending months developing to deliver a project ‘ready’ for testing.
- It’s not agile to do the 100% of the tests manually.
- It’s not agile to spend weeks doing manual tests without the development team.
- It’s not agile to not show any given functionality to the customer because is still cooking.
- It’s not agile to let the developers to spend hours working on their laptops without speaking to their colleagues (also to the customer him/herself, who’s a member of the team as well).
- It’s not agile to have a whiteboard (a physical or a logical one) with plenty of outdated post-it notes with descriptions such a “do the analysis” or “listing”.
- It’s not agile to work without a continuous integration and continuous deployment environment, at least some parts of them, where the customer could check how the application is progressing.
- It’s not agile to be strict and live in a non-stop fight with the customer/user of the application we’re developing.
- It’s not agile to spend hundreds of hours of analysis without starting the development and involving the programmers from the very beginning.
- It’s not agile to generate tons of documentation that no one reads or update, and that is not really necessary to build the application.
In short, to be or not to be agile, in my view, has much to do with the philosophy and culture shared by our team, the sensations we inspire in our clients from the moment we sign a development contract, to question ourselves, not to accept what we usually do, stop doing that document no one is going to read, stop joining meetings with the hatchet ready to fight for not changing anything from the project instead of giving the customer what he/she wants. Let’s concentrate our efforts on what really gives value to our customer and build the software he/she really needs, so that we can commit the minimum of energy to the rest of activities that add no value.
Leave a Reply