Avoiding Six Hidden Traps in Agile

Without getting into the reasons why that reasoning is true, it would be prudent to also understand that Agile represents an evolutionary step in a continuous search for ensuring quality software delivery with less project risk and less waste. While it is certainly a major change it is not yet the Holy Grail of methodologies, which is why new directions of thinking and innovation keep coming up to make it better. Most training courses and books on the subject naturally focus on the core principles and execution techniques of the subject, but there are certain elements of learning from the past which still hold good, and which must still be kept in mind by any software engineering manager or project management following an Agile project management methodology.

1. Don't miss the forest for the trees

Agile software development methodologies typically place a focus on the burndown of stories (also known as the implementation of requirements). Once the sprints begin, the focus then moves to the elements of each story, and to delivering working software at the end of each sprint. While this is all fine, there must still be four major decisions made prior to the start of the sprint cycles: the broad logical and technical architectural principles that will be followed, a high level project plan for integration and delivery, the major technologies that will be used, and the engineering practices that will be followed for continuous integration and change management. While it's always nice to focus on implementing exactly what the user wants at the micro level in each sprint, following the sprint plan and backlog burndown without having the roadmap that represent the output of these four decisions could well just be a recipe for disaster. The details of schedules and architectures can always change once the project is in progress, but in principle it would be strange if these just cannot be foreseen up front.

2. It's still all about people

Whatever the methodologies, tools and techniques used, the creation of software is ultimately all ultimately in the hands of people. Tools, methodologies and techniques that are used incorrectly cannot be blamed for project overruns and bad software. Agile places a great emphasis not just on teamwork, but on empowered team members. To be ideally empowered, each team member must become as complete a software professional as he or she can be. That means that people should not be siloed within their skill tags, rather they should be encouraged to learn by asking questions, by reading and experimenting, and by being allowed to make a contribution to progress in every new way that they are capable of beyond their starting competencies.

3. Documentation is valuable

When large, enterprise software is to be created, the work is often shared with large outsourced or captive software development teams that are almost like factories. Their perspective is often horizontal, ie, their focus is often on the methods of how to implement any software correctly, while often being agnostic to an understanding of the business domain. In such cases, CMMI or ISO practices are often used and these place a heavy emphasis on the production of documentation for multiple uses. When using an Agile methodology and focusing on the 'here and now' in small teams, it may seem redundant to product that documentation, but the fact is that it is valuable and required, although maybe some of it may have to be done in rethought ways. Whether the project is still ongoing or has been completed, there will always be a need to review previously written code, to know why it was made a certain way, how it works, and what it's all about in the first place.

4. Take a moment to think about design

Just as some forethought needs to be given to architecture, it is prudent (and in fact necessary) to remember to think about design decisions as well. When coding little functions and modules in isolation, there has to be some thought given to the possibilities of patterns, reusability, and to development techniques. If this isn't done, the result is very likely to manifest itself in the form of duplicated entities, bad object design, security flaws, and even performance issues (for example, due to the shortsighted selection of new database connections and hits instead of in-memory processing)

5. Keep the schedule real

Agile methods bring in their own unseen pressures because progress (or the lack of it) is always visible in charts and multi-coloured post-it notes. In every new sprint, there could be a pressure to either accommodate more than what can practically be achieved, or (worse) to allow carry over into future sprints just to make the present seem more productive. Even in very small teams there is likely to be a difference in individual skill and productivity levels and taking this into account is critical in working out schedules that work. If this particular practice is misused then one of the most basic advantages that Agile offers may be squandered.

6. The daily meeting needs the right people

The daily sprint meetings are critical because they are meant to track progress and solve problems. Sometimes the problem is a requirement for an input, a review or a decision. It is difficult to predict what new issue might arise each day, and what new decisions need to be made, and so a meeting held without the right participants, a meeting which has pending points, is as good as a day wasted in the sprint.

In conclusion, these may all seem like very basis and obvious truths, but the reality is that they are not always seen as such, nor are they even acknowledged frequently enough. The fact is that even with all the knowledge of the right Agile techniques (which are actually quite powerful), the difference between success and failure may lies simply in blending in foresight and a bit of common sense.