We are used to think in steps: we decide on a destination, get in the car, put on the seatbelt, start the car and drive. Routine is driven by normality, as long as everything stays the same, we do not need to change.  This is also how Information Systems were initially designed: the waterfall method.

Even at its dawn, back in 1970, Dr. Winston Royce had remarked that this approach ‘is risky and invites failure’; It does not welcome change. This is exacerbated by a constantly changing environment. In the 80s we used to plan our driving route in advance, whereby nowadays our GPS constantly monitors traffic and weather provide the safest and fastest route. Not only is this safer during the act of driving, but it also eliminates the need for up-front planning; you just start and go.

How does going Agile solve this problem?

The Agile manifesto was created to precisely solve this issue. Its core value set that encourages collaboration, responsiveness and usable outcomes substitute the age-old step-by-step thinking. Does it always work? No. In this article we examine some of the pitfalls of agile and how to overcome them.

Agile methodologies are a set of frameworks and practices that aim to deliver value to customers in an iterative and incremental way, while adapting to changing requirements and feedback. This makes them ideal of fields where the path to an objective (or the objective itself) change regularly, such as for military applications. It achieves this by focusing on 3 ideals:

• Limiting ‘Work in Process’ by breaking large tasks into small chunks which add value on their own.
• A shortened feedback loop through the delegation of control to small teams that can plan, act and review independently.
• Encouraging continuous learning and adapting by bringing the end customer in direct contact with the team.

This way of thinking suits the software domain where we try to solve complex problems, within a rapidly changing ecosystem and with customers that struggle to formulate their requirements. So where could things go wrong?

The Pitfalls of Agile

Doing Agile without being Agile

Agile is a way of thinking, a culture with its values and principles. It provides guidelines but it does not dictate precise ways of working. A misuse of Agile is when people ‘do Agile without being Agile’, that is, when the mechanics and rituals of Agile are used as an explanation to provide a rigid framework.

Doing Agile in this way reduces the trust and alignment of the team and its stakeholders because it does not adapt to the changing requirements. Consequently, it hinders innovation, creativity and continuous improvement. Agile is first and foremost a mindset and should be thought as such; focusing on delivering value to customers through engagement, feedback and empowerment is a must to be Agile.

Neglecting Technical and Quality Aspects of Agile

Agile promises added value at a regular pace, such as at the end of a sprint. This is critical for the regular feedback loop; however it can be misinterpreted as an excuse to cut corners in order to meet deadlines.

This is not a good idea because there is little value added in reducing the quality of deliverables to stick to time; all we end up with is a pile up of technical debt that will inevitably need to be repaid in ten-fold later.

A key word in the Scrum methodology is that the deliverable is a ‘Potentially Shippable Product Increment’ (PSPI). This means that the result of a sprint must be ‘production ready’. This means a stamp of quality that is non-negotiable.

To achieve this, it is important that:

• The team has adopted a good understanding of standards and best practices especially a robust definition of ready.
• The team is resourced sufficiently to create a PSPI. That is, it has business representatives, developers, testers, and operators who can achieve this.

Believing that Agile fixes everything

Agile is not a silver bullet for everything.  Even within Agile itself there are different flavour: Scrum and Kanban to name a few. Every major undertaking needs to be carefully assessed as to which Agile methodology, if any, would fit best.

Variations in project scope and complexity, team size and skill set, and organization structure and culture impact the usability of different techniques. The requirement for continuous improvement aids is also in place to aid the team to adapt, not only to the requirements of the customers, but also to those of their work environment. Afterall, one must clean their own act before trying to clean that of others.

Deciding what is best for your circumstances.

The Agile methodology certainly has its benefits, however so too does a step wise approach like Waterfall. Throughout recent history one finds many examples of success and flops using either method, which all raise the question of ‘What if we did it differently?’

Recently on Harvard Business Review, an interesting debate was addressed about the use of a hybrid approach, creating a toolbox of the best of both worlds. This makes perfect sense when the correct context is established, when the people and the technology are used to formulate the process.

When you are commuting again thing about it, how often do you look back at your routine and feel you can improve it?