8 signs your agile isn't agile
In 2001, when the Agile manifesto was written, years of trial and error had led engineers to realize that old school engineering practices could not be used to build software efficiently.
With their new method, these engineers built amazing teams transforming an entire industry.. Everyone tried to copy them with varying results
Today the whole developer world is “Agile” and the word “Agile” is used and misused for anything and everything.
Although the whole software industry believes that they are running an Agile development workflow, below is a list of red flags that indicate that a team has lost the essence of what makes Agile beautiful and efficient in the first place:
1. “QA” team
If you have a separate QA team (quality assurance), this is one of the clearest indicators that you’re not running with Agile. It’s the developers who made the software who should test it as they move forward. They should write automated tests to save time. The quality of the work should not be checked at the end of the assembly line; it should be checked every step of the way.
2. Poor communication
It might seem obvious, but building software with Agile methodologies involves swift, clear and direct communication among all company stakeholders.
3. Imposed scheduling
With the pressures of the work at hand people in charge try to impose deadlines on tasks with no or little understanding of the time necessary to achieve the required milestone. They’ve promised result to a client to obtain a contract, or to an investor for funding. Management cannot both claim to be running with Agile and impose deadlines. Management will never achieve the efficiency obtained by the parents of Agile until they understand that putting pressure on a team can only lead to slow- downs.
4. Unhappy environment
Agile was created for software engineers, and it is intended to produce an ideal environment for them. If there is no spark in your developers’ eyes, then quite possibly there is problem with the way your company applies the Agile method.
5. High engineer turnover
Another clear sign of dysfunction is when the developer team loses and regains members frequently. The developers leaving may not tell you why the’ve gone - they may say they found a great opportunity elsewhere - and perhaps they have. One might ask themselves why they were looking for work elsewhere in the first place. The best teams have almost no turnover.
6. Senior engineers coding instead of coaching
The most efficient senior engineer should not be coding most of the time. Senior engineers know that they are faster than their more junior colleagues. They would want to do it themselves because short term - it might actually allow them to arrive at their imposed deadline (see point number 3). However, the mathematical truth is one senior engineer coding super fast is worthless compared to a whole team coding fast enough. The best engineers should be Pair-programming with their more junior counterparts at least 50% of the time. That way the whole team gains speed. - and the team gains more and more autonomy from your senior engineer
7. Lack of shared knowledge
Some teams have every individual responsible for a single aspect of the codebase. Untrained managers may believe that such specializing creates efficiency, however the downside is that if anyone is missing nothing gets done. In software efficiency is a factor of code quality. If everyone works together and is constantly confronted to new readers of their code, they will constantly code more clearly. Clear readable code is much easier and efficient to modify.
8. Unflexible Role boundaries
Agile is built on the notion that software developers should be well rounded. Agile teams tend to avoid over-specializing engineering roles. This allows us to move engineering efforts to where the company needs us. As needed we can switch from front- end work, to back-end work, to dev-ops. Flexible roles also help us share knowledge to prevent or quickly resolve any bug- failure in our systems.