Agile software development
Agile can be defined in various ways; the following is one such definition:
Agile software development is an umbrella term for a set of frameworks and practices based on the values and principles expressed in the Manifesto for Agile Software Development and the 12 Principles behind it.
Some of the claimed benefits of Agile include:
- Faster delivery of working software through iterative development
- Improved adaptability, allowing teams to respond quickly to changing requirements
- Greater customer involvement and continuous feedback
- Better visibility and transparency throughout the project
- Enhanced team collaboration and communication
- Early identification of risks and issues through frequent reviews
I did not choose Agile myself; it was imposed on all of us by the company I worked for at the time. From the very beginning, I was never fond of it, and over the following decade I became increasingly aware of its problems and developed a strong dislike for it.
Overbearing, nanny-like process
I am aware that Agile can be applied in different ways and practised with varying approaches. Some argue that if Agile becomes too overbearing or inflexible, it is being implemented incorrectly. However, it often seems that any issues with Agile are dismissed, with the blame consistently placed on the people following the process rather than the methodology itself.
The company I worked for insisted on using the Agile methodology with a Scrum framework. In retrospect, I believe Scrum was the worst part. Simple, straightforward development tasks were transformed into a bizarre kind of kindergarten role-playing, complete with Scrum Masters and user stories. Every working day, people were forced to gather at 10 a.m., march into a meeting room like mindless robots, and repeat the same phrases: “Yesterday I did this…” and “Today I will do this…”, while others stood around silently, staring at the walls or the floor. This monotonous ritual continued for weeks, months, and years, for as long as anyone had the patience to remain with the company.
The Agile Manifesto
The Agile Manifesto outlines the core principles of Agile. I would like to offer my own perspective on its twelve principles.
1. Our highest priority is to satisfy the customer through the early and continuous delivery of valuable software.
The highest priority should not be customer satisfaction at the expense of everything else. This approach is misguided, because customer satisfaction does not depend solely on early software releases. There are many other crucial factors, such as usability, scalability, reliability, and support. Releasing software too early increases the likelihood of defects and design flaws, which can ultimately undermine the user experience.
The drive for early and continuous software delivery can also have a negative impact on team morale. I have personally experienced this many times when management, guided by this principle, set unrealistic deadlines and expected a constant stream of fully tested features, even when the time and resources were insufficient to deliver them.
2. Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
No, push back against this if you can. It is not an effective way to develop complex projects. The desire to please and satisfy the customer often comes at the expense of the development team. If requirements are constantly changing, this likely indicates that the requirements specification was never properly completed or that the project is inherently too experimental.
Nobody wants to work overtime or on weekends just to meet a project deadline when the customer decides to change the requirements. While Agile does not explicitly mandate such working practices, in reality, this is how many companies operate.
3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
Why rush? Are you competing to see who can type the fastest on a keyboard? It all depends on the project. Some projects can be delivered in stages, while others should not be rushed and may take many months before anything tangible can be presented to the customer. The development team should rely on their own judgement and experience to determine the optimal schedule. Just because somebody expects a feature within a week does not necessarily mean it is feasible given the current resources.
Management can sometimes develop a misguided perception that if you are not delivering working software on a weekly basis, you are somehow lazy or incompetent. The constant pressure to justify your role to the company by demonstrating measurable progress each sprint can be overwhelming. It is far more valuable to have knowledgeable and motivated software developers who are not micromanaged by individuals lacking deep technical expertise. Trust developers to do their jobs and to decide when features are ready for release.
4. Business people and developers must work together daily throughout the project.
“Must” is a strong word here. If specific business requirements need to be implemented in software, it can be helpful for developers to understand some of the underlying business practices. This is usually addressed during requirements gathering and can be a valuable interaction. However during the software development, the phrase "too many cooks spoil the broth" is also appropriate here. Software developers need to concentrate on their development tasks and have the freedom to innovate. Frequent requests and critiques from those without deep technical knowledge can often be unwelcome.
5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
Completely agree with this.
6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
This is not always the case. In fact, I personally spent many long hours in face-to-face discussions with people who refused to read documentation or who simply wanted to appear busy, organising numerous repetitive meetings without accomplishing much.
7. Working software is the primary measure of progress.
Absolutely not! People have different skills and can contribute in many ways: updating documentation, fixing bugs, providing help and training to junior developers, volunteering to administer company web or email servers, assisting with customer escalations, and more.
8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
Life is more complicated than this. Greater emphasis should be placed on people, as they naturally experience ups and downs. Maintaining a constant pace can be difficult due to various life events such as bereavement, depression, medical issues, or personal conflicts at home. Treat people fairly and give them some leeway when they need it.
Even in the absence of external pressures, when life is otherwise smooth, constant demands from so-called “efficiency experts” to work better, harder, and faster can still lead some people to develop symptoms of anxiety.
9. Continuous attention to technical excellence and good design enhances agility.
Yes people should aim for technical excellence and good design.
10. Simplicity–the art of maximizing the amount of work not done–is essential.
That sounds ideal, but in reality, developers often have to maintain legacy codebases full of cruft and complexity. It is important to be pragmatic and accept that writing messy code cannot always be avoided.
11. The best architectures, requirements, and designs emerge from self-organizing teams.
Is this a law of nature? If not, I would take it with a very large pinch of salt.
12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
It is ultimately up to the team to decide. If they do not find this activity useful, they should not be forced to carry it out at regular intervals.
Final thoughts
Personally, I feel that Agile and its Manifesto are largely overhyped. They have created a huge industry for companies to sell books and training courses. Ultimately, just as I do not need a life coach to guide me through my daily tasks, I also do not need Agile to tell me how to organise my software development tasks.
