This is the first in a series of Blog posts focussed on how KZN Group prefer to deliver projects.

Many of our customers have heard of Agile but few truly understand how an Agile project - one which adheres as closely as possible to Scrum whilst embracing Lean - differs from the traditional “waterfall” project they may be familiar with.

In this post I’ll introduce the concept of Agile project management, to put it in context beside its traditional project management methodologies.

---

What is Agile and Scrum?

Agile is one of those often-quoted but frequently misunderstood terms in modern business practice. Agile is an umbrella encompassing several methodologies which share a common goal: to ensure projects deliver the maximum business value in a timely manner. In project management Agile has become synonymous with Scrum but also includes practices such as Kanban, Atern, and Extreme Programming to name a few. In this Blog we’ll focus on Scrum as our Agile framework of choice.

Scrum is a deceptively simple framework, focussing on a few key roles and a couple of repetitive ceremonies. The authoritative Scrum Guide is just 19 pages long. As a framework Scrum deliberately lacks detailed guidance for how to execute a project on a day-to-day basis. While this allows teams the latitude to apply Scrum to their own circumstance, for others this leaves enough rope to hang themselves, and projects become bogged down in the very agility-sapping red tape Scrum was designed to avoid.

At its core, Scrum is a collaborative process which fosters frequent and just-in-time communication at all levels. Planning is done over both long-term and short-term horizons, at a frequency which allows plans to adapt to environmental change. The outputs of the project are inspected as they are produced, providing an immediate feedback cycle which can inform those plans. The project can change tack as the team collectively learns by doing.

What Agile is not

There are many misconceptions about Agile, probably the most common being that agile projects are fast. This is an understandable mistake given the literal definition of agile is “physically or mentally nimble, deft” with synonyms rapid, energetic, quick and brisk. The agileness inferred by the title doesn’t come from speed, but rather its efficacy (“the ability to produce a desired or intended result”) and its supple, limber nature. That is, the ability to be flexible enough to deliver the right result no matter what changes occur around the project. Contrast this to traditional projects where an immutable or unchanging plan is drafted upfront which ruthlessly drives to deliver an outcome in six months’ time. Three months into the project the best outcome may look different, and an Agile project would allow you to change course to achieve that.

Some argue Agile projects allow you to “make things up as you go”. This is a misrepresentation of Agile’s “just-in-time” planning philosophy which avoids forming detailed plans too far ahead of when they’ll be executed, to ensure plans always reflect their immediate environment.

There are however aspects to a project which must be understood in great detail before the project begins:

• The business problem which must be overcome.
• The vision of a solution which addresses the business problem.
• The project’s business case, or a justification that the sum of the benefits will outweigh the sum of the costs.

This list deliberately does not include an exhaustive breakdown of the vision into detailed requirements. As with project plans, Agile avoids documenting requirements (“what” needs to be done) in too great a detail too far in advance. At KZN Group we’re fond of the boulders, rocks, and gravel analogy. At the beginning of the project its requirements need to be described as boulders; large chunks of an outcome whose purpose can be understood but is lacking in fine detail. Boulders are decomposed, broken down into rock-sized requirements by the team as they near the time to implement. By virtue of being smaller, rocks are easier to understand conceptually than boulders. In order for the team to work on a requirement it is decomposed again from rocks to gravel. This “just-in-time” approach allows a project to start work once all or most boulders have been described, and one selected as the most urgent and important, rather than waiting for all boulders to be decomposed into gravel. Since the team has not invested time decomposing a boulder until it is needed, there is less resistance to changing boulders or even rocks, should an environmental change warrant it.

There is a perception that Agile projects lack a plan, but in practice the opposite is true. As described above, the project must have a clear vision. Agile projects deliver that vision incrementally (“increasing by additions”) and iteratively (“repetitive”). In Scrum the iterations are called Sprints; a fixed period of time defined by a plan. The plan is formed at the start of each Sprint with emphasis placed on strictly adhering to the plan during the Sprint. At the end of the Sprint the outcomes are compared to the plan, and lessons learned can be factored into the plan for the next Sprint.

Finally, a myth perpetuated by many Scrum teams themselves is that a project end date is meaningless in an Agile project. This is often a symptom in projects which lack even a high level view of the project’s scope: lacking clarity of vision, or lacking comprehensive requirements even at the “boulder” level. In a project where the vision is crystal clear, where requirements are known with greater (gravel) or lesser (boulder) certainty, where the team composition and size is stable, and where the team’s throughput can or has been measured, if all of these factors are known then the project’s end date can be forecast. It needs to be accepted that changes to any of these factors will impact the delivery date.

Traditionally, project managers have referred to the “iron triangle” which constrains delivery whilst maintaining quality. Projects can deliver all features (scope) quickly (time) but not cheaply (cost). Conversely, a project’s cost can be kept to a minimum usually by sacrificing time or scope.

In an Agile project the “iron triangle” still influences its delivery. Greater emphasis is placed on fixing time and cost (resources) and allowing scope to flex. In practice this is achieved by dropping requirements from the project’s backlog, preferably deferring them to be delivered at a later date. Going one step further, Agile projects should end when sufficient business value has been delivered. Sometimes this may mean extending the project but the converse is also true; scope can be jettisoned if it adds no more value that what has already been delivered.

When does Scrum shine?

Although Agile and Scrum evolved in the world of software development, Agile evangelists will tell you that any project can be delivered using the methodology. However, it is definitely true that Scrum is best suited to projects of a certain nature:

• The project will be delivered collectively by a team which must closely collaborate.
• The project’s vision is clear, but the finer detail is not yet known or will only become known through experience.
• Those who own the vision (the “Product Owner”) can collaborate closely with the Scrum team implementing the project.
• The project’s outcome can be delivered incrementally and iteratively, and tasks do not need to be executed in a strict sequential order.
• The project exists in an environment which is dynamic and nimble, and where plans must adapt to remain relevant.

Conclusion

As I mentioned above, the Scrum framework is deceptively simple. It’s easy for teams to follow the prescribed process by rote and lose sight of the reason why each part of the process exists.

KZN Group can offer consulting services to help you get started on your Agile journey, or to fix an Agile project which has gone off the rails. Get in contact, we’re happy to help.