VWR-Transform-Joomla-Banner

How is agile different from a more traditional 'waterfall' approach?

Agile differs from a more traditional 'waterfall' approach in a number of important ways. Agile ways of working:

  • value people and interactions over prescriptive processes and tools
  • focus on delivering a working output (project deliverables) over comprehensive documentation
  • stress end-user collaboration and feedback over contract negotiation
  • respond to change over strictly adhering to a plan.

That doesn't mean that an agile approach doesn't value processes and tools and so on, it means that it values the other aspects more.

What are the key features of an agile project?

Agile projects have:

  • a clear flatter structure
  • hands-on governance processes
  • a cross-functional, accountable team
  • robust collaboration and engagement
  • an open physical and virtual environment.

What are the benefits of an agile project?

Everyone sees the project benefits earlier. The phased delivery approach that sits at the heart of this way of working means that stakeholders are using the new products earlier than when a traditional project management approach is used.
In the case of the Victorian Water Register Transform Project, we'll deliver changes, as part of a fully functioning register, at the end of each of our five project milestones.

Agile puts the customer at the centre. Input from stakeholders during service development in the foundation stage, and regular showcases during technical development, helps the development team deliver products that reflect ongoing stakeholder feedback.

Agile adapts well to changing priorities. Development in sprints and regular showcases (demonstrations of progress) help the project team to identify and adapt to changes in stakeholder needs, technological developments and other aspects of the project environment quickly.

There is greater transparency with agile. The high levels of collaboration and focus on stakeholder participation during development and delivery means that stakeholders have a line of sight of project development. The focus on regular communication and commitment to the day's tasks that are central to the daily stand up meeting ensures operational transparency and fosters accountability in project team members.

There is the potential for fewer defects at each delivery stage. The iterative development approach and the regular and smaller test instalments ensure that issues and glitches are picked up and rectified along the way.

Risk is spread across the project. Because business and technical developments are constantly under review and being tested, errors, bugs and glitches are detected and corrected early. A more traditional approach delays much of this work until just before go-live. This means that the size of the testing and remediation is largely unknown at a project's most critical time. Later testing also has the potential to embed any bugs more deeply in the final product, that then take more effort to fix.

Finally, as agile working regularly involves stakeholders in demonstrations and feedback sessions (known as showcases), the project can identify and action user feedback early.

Agile feels unplanned and disorganised – is that true?

This is a common question. Because agile projects don't have a detailed plan spanning the lifetime of the project, stakeholders can worry that this means there is no planning at all. Agile ways of working focus on planning and organising as much as needed, when needed.

For the Victorian Water Register Project this includes:

  • staged project delivery, three stages and five milestones across the life of the project
  • detailed planning every three months against each / stage or milestone
  • once we start developing the new Victorian Water Register (or enter delivery stages) more granular planning will focus on dividing those three month periods into shorter development and delivery periods, or sprints

During the delivery stages we will also have:

  • clearly articulated deliverables for each milestone
  • defined requirements that will be translated into a list of development tasks (backlog)
  • active backlog management to ensure we:
    • have a clear estimate of the amount of work (size) in each task
    • prioritise each task based on the benefits it will deliver and the capacity of the team to take it in each sprint.

How can I be sure that an agile project delivers a good product?

This is another common question. Because agile projects don't define all the detailed project requirements up front, stakeholders worry that a poor quality product will be delivered.

In addition to the work to identify and articulate requirements set out in the response to the previous FAQ, the Victorian Water Register Transform

Project will also develop a clear 'definition of done' for each iterative development task. Done being defined as - when has the project achieved the key value to the customer of that task. This will underpin the development of the piece of technology defined in the relevant task.

How can I be sure that the outcomes of an agile project meet my needs?

This is a question that stems from agile projects not defining all the detailed project requirements up front, and so stakeholders worry that the product that is delivered won't work for them.

Because agile ways of working put the customer at the centre of the project it offers a number of opportunities in which customers are encouraged to get involved:

  • the work to develop requirements and the 'definition of done' will include internal and external stakeholder groups
  • stakeholders will be actively encouraged to join regular demonstrations of progress, or showcases. These sessions give everyone an opportunity to feedback directly to the project team on the development of the technical products in real time
  • we will also involve stakeholders in testing as widely as possible. And because testing happens during the whole project timeline, issues and bugs are picked up early. This gives the project team maximum opportunity to correct errors and address user issues.

How do I find out more about how the Victorian Water Register Transform Project is implementing agile?

We will update this section regularly, so feel free to return to this page regularly.
In the meantime, check out the videos of our May 2021 information session which goes into more detail on how we're implementing agile ways of working.

Have a burning question that won't wait?

Please send us an email at vwr.transform@delwp.vic.gov.au - we will do our very best to answer.