8 signs your agile isn't agile

Gembani

These days in the tech industry Agile is a word that has a tendency to be used for everything / indiscriminately, as if the word itself could empower the developer, without taking into account the other very real factors involved in setting up an optimal running business. In 2001, when the Agile manifesto was launched, years of trial and error had already been built on, leading to the realization that the old school engineering methods could not be relied upon for efficient building of software. Rather, a team effort was needed, and was much more effective. Here is a list of red flags that you should look out for in your company:

1. “QA” team:

If you have a QA team (quality assurance), then that is probably 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 so that they can 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. No communication:

It might seem obvious, but building software with Agile methodologies involves clear and direct communication among and between all of stakeholders. You can, and should be happy with your work don’t forget to share!

3. Imposed scheduling:

With the pressures of the work at hand, and maybe as well due to lack of experience, there is a tendency for the person in charge (especially if not an engineer) to impose a time limit on certain tasks without understanding all of the necessary procedures that the development engineer has to work through. The development team must decide on a realistically achievable schedule and inform the person in charge, for only the team has a realistic idea of how long each task could take them.

4. Not a happy environment:

Agile was created for software engineers, and its value hierarchy 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 turnover rates:

Another clear sign of dysfunction is when the developer team loses and regains members frequently. The team of developers need to be synchronized with their work and the people around them. If they are not, the Agile engine will be driven inefficiently until it prematurely breaks down.

6. Management putting to much pressure on individuals:

This problem is caused by high levels of stress imposed by management on one of the lead engineers, due their higher experience; they are told to do more feature instead of taking the time to teach the rest of the team which would make the entire team more optimal.

7. Lack of shared knowledge:

This problem often raises its head when developers with more experience and more general awareness of what they are doing begin to over-protect their own interests, by doing all the difficult tasks themselves, and never finding the time to explain to the rest of the team how they accomplish these tasks. This type of behavior might be understandable at an oil refinery, where each individual is specialized to deal with specific hazardous tasks, then in the eco friendly, physically harmless world of software development.

8. Non fuzzy delimitation of roles.

Agile is built on the notion that software developers should be well rounded. Agile teams tend to avoid specializing engineering roles, this allows us to put effort where buisness wants us too. Some days we do front end work, some days we do back end work, some days we do dev-ops. This fuzzy delimitation of roles also helps us share knowledge so that there is no single point of failure in the system.