Can a Waterfall project be run with Agility?
I was sitting in an Agile user group meeting recently, which was facilitated by both local and ‘flown in Agile experts’, when the question was raised of how you could get two groups to work together when one is running Agile and the other has to be (or chooses to be) inherently Waterfall in its processes.
After much debate around the subject, it appeared the group was bent on (facilitated into being convinced of) the need to help transform the Waterfall organization into a purely Agile one.
Sitting in my little corner of the room listening, I raised my hand and simply asked, “Can’t an inherently Waterfall project be run with Agility?”
The room fell silent.
The facilitators started shaking their heads as if to be holding back the desire to pounce out of their chairs and proclaim ‘BLASPHEMY!’ Curiously, though, attendees thought for a moment about it and more than a few turned and said, ‘Sure, why not?’
Sure, why not?
I didn’t ask if a Waterfall project could be run ‘scrummy’. I asked if it could be run with agility. Understand the difference here. And this is where I think many teams and organizations are missing the point of the adoption of Agile as a whole.
The Agile manifesto and its 12 principles never use the word SCRUM. It uses phrases like face-to-face communication, simplicity, working software, business engagement, welcome changing requirements, motivated individuals, etc. There is no phrase in the software development world currently that makes the hairs on my neck stand up more than “AgileSCRUM”. “Oh yeah, we do AgileScrum.” Simply using that phrase tells me a ton about how your Agile adoption is probably playing out in your organization.
For the sake of argument, let’s use an example of an inherently Waterfall feeling scenario; Infrastructure projects.
Ken is the Director of Infrastructure for a $500m Healthcare firm. He watches as the application development teams begin to adopt an Agile mindset and implement Scrum processes within their teams. Ken asks that he and his teams receive the same training as the appdev folks because he sees the benefits they are enjoying. But there is one problem; his body of work is vastly different.
Ken’s teams have projects to build one step at a time as opposed to iterating and slicing. There are multiple third parties involved. Ken decides Scrum simply won’t work. But do they have to abandon the idea of agility?
Instead, Ken decides to have his teams focus on the mindset of Agile as opposed to the processes (imagine that). He encourages the team accountability and self-empowerment while giving them the support they need to be successful. Ken allows his teams to be innovative on how they are working without fear of failure. Ken encourages his team to be highly collaborative with the third parties involved in addition to internal stakeholders. Ken makes sure his team's work is highly transparent while seeking out feedback on the outcomes. They are encouraged to embrace changes and adapt quickly as needed. He asks his team to retrospect, often, to ensure they are doing things the right way, gelling as a team, and focusing on constant improvement.
Notice they may not be doing standups every day. They may not be stopping every two weeks to plan, groom a backlog, review the body of work, estimate new features, and commit to increments and sprint. But are they showing agility in a Waterfall world?
Remember, Agile is truly in the eye of the beholder. Sure, there are certain traits of ‘Agility’, but none of them include the word Scrum in their definition.
We all understand that traditionally delivered Waterfall projects discourage an Agile mindset. But wouldn’t you agree required Waterfall has a better chance to be successful if we are determined to sprinkle in a little agility as best we can?
Don’t limit your Agile, folks. You don’t have to be doing software development to have an Agile mindset and you don’t have to call a project “Agile” to have a degree of agility.