Does Agile Really Work?

Author: Hilary Fitzgerald

The principle of Agile is to build something (be it an organisation, process or system) in an efficient and flexible manner, by working on a collaborative basis.  It is about being able to quickly respond to change – a great asset in today’s fast-paced society – and is partly why we see small, gutsy start-ups able to compete with large well-established brands – they can simply react to the market and deliver what it wants more quickly.

​

Evolution

​

The fundamental tenets of Agile have existed for a lot longer than the actual label; as with many efficiency-based concepts, the Manufacturing Industry was an early pioneer.

​

The Agile Manifesto was first published in 2001, and laid out the principles of Agile Development.  In the post-Y2K/dot-com bubble era, the software industry was experiencing a sea-change (including huge consolidation/lay-offs), and efficiency was an attractive proposition.  The migration towards more Object-Oriented development enabled on-the-fly changes to partially replace up-front planning and design; and the advent of automated testing tools provided new ways to capture development efforts and results.

​

Agile Development

​

Agile Development is fundamentally about making software changes in small chunks, which can be of immediate value to end-users (rather than waiting months or years for large-scale changes).  These chunks may not be a perfect solution initially, but once the user gets to play with them, it helps them refine what they really need, and then the original deliverable can be tweaked. Each Agile delivery still follows the full development lifecycle (Planning, Business Requirements, Functional/Technical Design, Coding, Unit Testing, and User Acceptance Testing) but timelines may be compressed, and documentation will usually differ from the traditional approach.

​

Experience

​

I have been personally involved in a number of agile (and non-agile) projects over the last 20 years, with varying degrees of success.  Sometimes there is truth in the saying ‘To Fail To Plan is To Plan To Fail’, when people use Agile as an excuse to skip steps in the lifecycle. 

​

Whilst Agile may work well for small, well-organised teams, there are inherent risks with stripping out the checks and controls of more traditional approaches.  Cutting corners in the development process may simply increase the burden on business users to validate changes.  This is particularly true in Regulated environments, where quality standards such as ISO9001 may apply.

​

Considerations

​

So before going down the Agile path, think about the following:

​

• Knowledge/Experience – have you got the right mix of development expertise, system knowledge and business knowledge?

• Organisational Structure/Relationships – which business areas need to be represented; does the development team have access to these areas (location/time zones); do they have capacity to provide input; do they have decision-making authority?

• Engagement/Motivation – do the team care about making this happen; are they well-organised; are they adaptable?

• Complexity/Duration – can the proposed build be broken down in an agile manner; are there genuine benefits to completing work in chunks or cannot it not be used until complete anyway (e.g.: new system build); how long would the overall development take versus the individual chunks?  For example, a data-entry system can work really well under Agile, whereas one with complex logic and data manipulation may require more up-front design.

• Governance/Regulation – what are applicable policies/regulations (both internal and external to the firm; are team members empowered to make policy decisions or must they always be escalated; can this be worked around by building rules-based system parameters which can easily be changed?

• Implementation/Longer-term Support – what is the handover strategy; how is another team going to pick up support (both operational and technical); how will the system be rolled out to the wider user population?

• Measurement – how will you ensure that the project stays on track; how will you measure successful delivery?

​​

Get it wrong, and Agile can make a project take far longer than necessary, and deliver an inferior result, causing huge frustration to all involved; however, with the right people on the right piece of development, I do believe that Agile can work well.