Putting the Agile Into Practice: IMP's Thoughts on the 12 Principles

All methodologies work if you are dedicated. With Agile, the focus is often on its mechanical and operational components (daily stand-ups, sprints, etc.). What frequently falls short is the implementation of its greatest doctrines. Here, we’ve analyzed “Agile’s 12 Principles” to help you decide if the Agile Method is right for your project.

Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

This idea certainly holds true for the vendor you are working with. Continuous delivery of high value software will only help you. However, from your project delivery standpoint, you must understand the true scope and testing requirements of releasing software updates and changes frequently. Can your team support that? When is a full regression test required? When is it not? Also, understand the true risk of the deliverables and how rigorous the system has been tested by the vendor – was it even tested?

Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.

This principle applies more towards the vendor producing the software. Most would find this principle hard to argue against if they want to remain competitive with the best of breed software solutions. However, it’s important to understand the criticality of the software you are implementing. For example, the implementation of a trading system is vital. You must always do a risk assessment on any requirements you submit to the vendor. Changing requirements at the last minutes usually has “delayed go-live” written all over it, and generally throws the risk meter over the scale.

Deliver working software frequently, from a couple of weeks to a couple of months, with a
preference to the shorter timescale.

It’s important that robust requirements are fully documented and vetted out early in any project. These releases are often formed in “sprints” in Agile, and a common mistake is to lose sight of the overall project plan and governing phases of the project. Even though your firm has decided to use Agile, you must make sure each sprint falls into place within the larger plan, makes sense, and has requirements documentation to support it.

Again, anyone would find it hard to argue that bug fixes and enhancements that are released sooner isn’t a great thing. The 2-3 week “Sprints” are most aligned with this principle, which forgoes robust requirements documentation. But, when you’re implementing a vendor product that is a critical system (such as an OM), it may not necessarily be the best approach where detailed requirements and traceability is an absolute must.

To access the full version of this blog with all 12 principles, click here.