Agile or “WAgile”

I’m not even sure “WAgile” is a proper term! But it is one I use, so what do I mean by it?

WAgile (to me) implies running a project in what some might call an “Agile like” manner, meaning really it is a collection of short waterfall projects. I have heard many organisations describe short waterfall projects as Agile!

But as Agile is supposed to be an adaptable common sense / no-nonsense approach, why not run short waterfalls under an Agile banner, especially if it works for you.

I work in the Dynamics CRM space and as a result many of my engagements are short, this lends itself to Agile nicely. But often projects are actually short waterfalls. An approach that can have several inherent problems;

  • Agile favours working software over comprehensive documentation. This doesn’t mean no documentation. Typically with short waterfall projects, when trying to save time, systems documentation is normally the first thing to be cut. And by implication short waterfall projects involve saving time!
  • Quality, Agile has quality at its heart. Testing is “baked” into an Agile approach, all processes have a quality focus right from the get go. However a waterfall approach typically has testing activities confined to the final stages of a project, typically in the form of formal system and user acceptance testing. The problem is if you squash a waterfall project you therefore must squash the time for testing. Resulting in less testing which must lead to less defects fixed prior to deployment.
  • Velocity, in Agile projects the team should be self-organising and would learn its own pace. Typically this means that although the sprints are short the team doesn’t try to overstretch and therefore has a realistic chance of hitting every deadline agreed. But with waterfall the targets tend to be defined by the project manager and therefore dictated to the team. The result being that short waterfall projects are pressurised. Even when one delivers on-time the result are hard to replicate.
  • Sprint retrospectives, a common Agile practice, constantly look to enhance the processes followed by examining how the previous sprint went and making frequent adjustments. The pressurised approach to mini-waterfalls rarely gives time for this type of activity.
  • Scope, a waterfall project (however short) typically has a defined set of deliverables and a plan is created at the start to achieve the desired outcome. Yet with Agile the scope of each sprint is adjusted to fit into the regular sprint cycle. And it isn’t uncommon to adjust the scope as the sprint progresses. Agile sprints are typically short being 2 to 4 weeks long, in my experience short waterfalls tend to be slightly longer. Even so, trying to squash a ridge set of deliverables into a fixed amount of time is always going to lead to either delay or poor quality. (Or sometimes both.)
  • Change management, Agile projects embrace change whilst a waterfall project manages change. In a short projects change is likely (maybe evitable) but the reduced timescales mean there simply isn’t time to manage change effectively in the traditional waterfall way.
  • Daily “scrums” putting face to face conversations before written communication are at the heart of Agile, whereas in a waterfall project you’d expect maybe weekly team meeting. And project managers issuing written updates in the form of end stage assessment, RAG reports, risk log updates and the like. This level of governance is time consuming and often ineffective in short projects.
  • Technology, an Agile team should constantly try to make effective use of technology by striving to have technical excellence in everything they do. Each waterfall project tends to be a distinct set of activities with the project manager focused on the next milestone or delivery. Agile is a repetitive process constantly evolving, not a one off. The team therefore, with the support of their scrum master, will be constantly looking at emerging technology and how they can become more effective.

If you are running short waterfalls (maybe even calling them Agile) and ….. you feel stressed, your testing processes are a challenge, your team is unhappy, you frequently miss or move milestones and have little or no time for documentation or even basic governance. Just maybe it is time to ditch waterfall and embrace real Agile. (Plus maybe sleep better ay night!! J)

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s