It’s been… wow… now 15 years that the Agile Manifesto has been written. Java was 1.3 (no enum, no generic, even less lambda). We’re often tired of hearing that word – AGILE – especially when it comes from recruiters or marketers trying to convince how cool their company is. But the thing is, it’s not cool anymore. In the past few years, more and more people have announced its death, with some well-argued writings. Probably, as developers and tech-addicts, we don’t like old things. And agile is becoming old.
Of course, nobody says that everything in the manifesto must be thrown away. In Agile is Dead, Matthew Kern reports many other articles, or just claims, that Agile was dead – and notably from some of the agile manifesto founders themselves. From the arguments against agile, I want to distinguish actual arguments against the method from the observation – and I cannot disagree – that the “agile” term is over-marketized, its meaning being diluted in the crowd of the context-specific interpretations. But it shouldn’t affect in any way the pertinence of the original manifesto.
So, let’s focus on the real issues with agile. And I’m only focused on the original agile manifesto, not the other emanations, like SCRUM. I cannot pretend to have a large enough overview of how agile can be used in any company. I even doubt that anybody could do. Maybe the whole point is there: defining and promoting a methodology implies decontextualizing it, with the risk of turning ideas into dogma. To save agile from death, maybe the solution is to turn it back from dogma to just ideas that we should accept, reject or arrange for a given context. “Working software is the primary measure of progress”, they say. This is maybe the most controversial point. Companies may need (not just want, but really need) to have a clear plan about what’s going to happen. Not just vague estimations, but accurate plans. Think about a small, mid-aged company, losing market shares, losing money, on a very defensive strategy (nb: I am not talking about where I work). They can’t be satisfied with a “it’s done when it’s done” plan. Guarantees might be vital.
Now, let’s focus on my very specific case: the company where I work. We’re currently not agile, and this is in my opinion a good example to see how turning agile would benefit or not to our R&D processes. So let’s see one by one the 12 principles behind the manifesto:
Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
This sounds kind of obvious, satisfying the customer is of course an objective (although not the only one), and this is done through the delivery of valuable software. The mention of “continuous delivery” brings confidence between actors, however I would be more cautious about the necessity of earliness, I think it’s very optional. It could even be confusing or worrying for the customer. In the very first stage I think trust must be established by communication rather than by early prototyping.
Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
Like for the “measure of progress” stated above, companies may need to have plans, and stick as much as possible to this plan. The cost of changing cannot be ignored for them. It’s a privilege of few companies. From the developer standpoint, a change can be perceived very positively as well as negatively, but we’re ok, we can manage that. We can change pieces of code once, twice, etc. but not repeatedly. We never like to throw our code away, but will accept when it’s well argued. However too much instability can cause distrust of the managers and the company. I think this rule should be moderated – or is a reason for choosing not being agile.
Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
Apart from the early stages which I discussed in the first point, getting frequent feedback is important and frequent delivery is a way to achieve this, although surely not the only one. The down side is that the amount of cycles for developers also increases the amount of redundant work for other services such as QA.
Business people and developers must work together daily throughout the project.
Working together with business is fine, understanding each other is crucial. But daily? Really? Why the hell? It’s just going to create useless noise, make us losing focus on what’s important right here right now. Maybe “weekly” is fine, or even “monthly”. Wait a minute… maybe “when it’s needed” is fine, and up to the manager and/or team. This point shows a lack of trust in the developers.
Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
I think this is true even for non-agile teams. Trust is a key factor, whatever the organization is.
The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
Hmm, yes, probably. But does it means that remote working should be avoided as much as possible? Fully remote positions are impossible in agile teams? This is without doubt one of the most outdated point of the agile manifesto. 15 years ago, working remotely was kind of exceptional, but it’s now so common. Some big companies work extensively with full remote positions. They managed to elaborate theories to make it work with agile methods. It surely decreases the efficiency of communications, but I think it can be an acceptable compromise in regards to the benefits.
Working software is the primary measure of progress.
I’ve begun to discuss this above. In an ideal world ruled by developers, it would be fine. “When will you deliver that feature?”, they ask. “When it’s done”, you’d answer. I’d love to live in that world. Unfortunately I’ve never seen it. People need plans, companies need strategy. I guess some large companies are able to work that way – at least, for less important projects that could not compromise their position. Or startups having an aggressive strategy, taking risks to grow. But it wouldn’t work for every company – not the ones I know.
Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
I am not 100% sure of this. In my work we don’t have a constant pace. And I was frustrated with that in a first place: I was feeling times to times underused, bored. Then I found it has some benefits. It’s time you can spend thinking, improving your code, improving the product with very little work, taking initiatives. It’s kind of fresh air blowing in the open space, something useful to increase your creativity. But, on the other hand, there’s definitely some waste of time. It should just be under control.
Continuous attention to technical excellence and good design enhances agility.
It’s kind of tautology. It’s true whether we’re trying to be agile or not.
Simplicity – the art of maximizing the amount of work not done – is essential.
This is my credo, although I must admit this is controversial – or at least, it’s not always the best way. I tend to be more “KISS” whereas my team-mates tend to be more “design for change”, with layers and layers… I love baklava, but not in my code. We had some interesting debates in the team. There are pros and cons, and we cannot totally eliminate the “design for change” method in the sake of simplicity. When you start building a heavy application and you know it will have to extend in some ways, but you don’t know yet exactly in which ways… then, sometimes it’s good to prepare for future. Yes, there’ll be refactors because your “design for change” was not totally perfect. But those little refactors will probably be times less time-consuming than a big-scale refactor due to KISSing a little bit too much.
In my opinion, the “simplicity” rule should be followed when you build light modules, micro-services, things on which few other modules will depend. But when it comes to building some more critical module, on which many modules will depend, better to think a little bit to the future before going to the most simple implementation, unless you’re fine to build big balls of mud.
The best architectures, requirements, and designs emerge from self-organizing teams.
That’s something missing for us. Our global architecture is top-bottom designed, sometimes neglecting the ideas that could emerge from individualities. I am not saying that the developers are like bots – executors. They have their perimeter of freedom. But it’s constrained in a limited scope – like feature scope – and doesn’t encompass the most global, the most critical parts of the software design. The developers should be involved in the whole conception stages, including for the whole architecture. For the company standpoint, it maximizes the chances to see emerging the best possible solution. For the developer standpoint, it avoids frustration of being underestimated. It doesn’t mean that every single developer should attend to every meeting, that would be non-sense. Groups can be formed on a volunteering basis. But individual knowledge and ideas shouldn’t be ignored.
At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
It suggests we’ve build processes, and must sometimes adjust them, so we create a process for managing processes… wait… what? One Process To Rule Them All. Maybe we’ve gone too far.
So where does it bring us? Does “agile” still mean something if we pick elements from its manifesto à la carte? Why does everybody announce agile’s death nowadays? Actually, I don’t think that the manifesto is really outdated, apart from one or two things. Most of its ambitions are valuable, still today. The majority of the critics are on Scrum, that is, an attempt to materialize agile concepts through a variety of processes. Scrum exists because it took agile as a dogma, and built plenty of processes upon that. If the dogma turns out to be incorrect regarding some context, everything falls down. As Erik Meier says in his hilarious talk One Hacker Way, we end on speaking about code more than we code. The majority of the processes in, I think, most companies, are in place because at some point, some human mistakes were done. Processes are there to replace trust. Remember point number 5? TRUST. A good company, with talented developers, should in my opinion avoid scrum and consider agile as a non-monolithic reference.
The manifesto itself must be deconstructed to fit one’s need, given a proper context. But what is “Agile”, in the end? The manifesto does not define agile. We all want to be agile, but we don’t adhere to the whole manifesto. To me, agile in software development context is a multi-objective optimization : maximizing quality and rapidity and minimizing processes. Which is, I agree, a delicate optimization.
