5 Lessons Learnt from working with Agile and Waterfall project methodologies

Over many years, I have always been intrigued by leaders who promote a specific methodology or process as gospel when delivering projects designed to solve a particular business issue or problem. They typically purport to having detailed understanding and experience in all other methods but have formed a view that their way is best.

Often they defend their position by advocating a purist view. I’ve witnessed many CEOs, CIOs and company directors implement their own unique delivery models methodologies. Yet, even then what many fail to understand is that irrespective of the method – the core underlying project tasks, risks, dependencies, environmental considerations and sensitivities, tools etc all remain the same.

What I have found is that irrespective of the methodology used, success and failure do not discriminate based on delivery approach.

I’ve worked on projects that have been considered Waterfall, Agile, hybrid and generic. I’ve seen success and failure in each approach. I want to share with you some of my learnings from Agile and Waterfall approaches:

COLLABORATION & COMMUNICATION ARE KEY

SCRUM meetings are all good and fine, but what then? Projects require love, care and constant nurturing so as to ensure the teams working on a project are continually coordinated, motivated and supported. This requires a balance of communication and collaboration. Again, I have witness some project managers and PMO’s ‘over-communicating’ setting a maddening number of ‘meetings’ in an effort to artificially produce their version of collaboration.

I believe collaboration and good communication needs flexibility dynamism and open sharing and unfettered exchange of ideas where everyone contributes. It’s not about setting regular meetings, conference calls etc.

Projects are fluid so too should be the approach used to manage and coordinate teams. Good Collaboration requires stakeholder engagement, regular conversations and dialogue at both the micro and macro.

AGILE PROJECTS HAVE ‘BA’ RELATED TASKS

I realize that many do not share my personal preference for a hybrid methodology but I would oppose anyone who thinks that Agile roles do not require traditional BA related tasks. Many view the existence of BAs to add unnecessary complexity to Agile flows. I would argue that basic BA tasks are required in all projects – planning, definition of business needs, documentation, communication, requirements validation.

TECHNIQUES RARELY CHANGE

BA techniques don’t change often. Good techniques can be used in Agile or Waterfall environments. Traditional Project Management or BA techniques include: requirements gathering, analysis, prioritisation, change management, issue resolution, dependency management, risk mitigation etc. All projects require these common outputs to be created.

It’s the external factors ie. Timing, structure, format and process that may change. Certain Agile methodologies use a specific set of techniques (ie. SCRUM User Stories) but I would argue that these much the same however far less detailed and well planned out but at least provide a starting point to start from. Similarly, while I would always recommend that much of the planning and requirements gathering be conducted prior to work commencing, Agile would see requirements gathering conducted in small, easier to define ‘chunks’ – but I think you would agree that both approaches will provide outcomes.

STOP POLARISING AGILE & WATERFALL

Many think Agile and Waterfall are opposing / conflicting methods. The truth is that they are not. Agile is a mindset revolving around ‘common sense’. It sets out NOT to replace other methods but rather frame up an alternative approach to software development that balances fluidity in decision making, with rapid delivery of output (often using prototyping) to provide something feedback can be gleaned from.

Typical Pro-Agile diagram

KEEP CALM & TALK TO YOUR STAKEHOLDERS

Agile looks and feels very different from waterfall but that does not mean you need to freak out stakeholders should you wish to change your approach. Facilitation skills and confidence are the two common traits required to bring about such a change. As long as your project managers are able to work efficiently, remain focused on output and keep stakeholders engaged, the process can be adaptive.