Digital and Agile: the foundations

To end this course, we wanted to summarise a few key messages. 

The first is that users will do things you don’t expect. Take the example shown here. This is a desire path. The planned route using the pavement is longer. So, people take the shortcut across the grass to avoid it. To them, it's simpler and it makes sense. 

This is why crucial to take a user centred approach. It’s critical to listen to users, so that we can understand their needs. This feedback is then used to inform how we develop products and services. 

So, it’s important to choose the right approach. 

Choose Waterfall, if you have certainty, you know what’s required and things won't change. Decide the requirements up front, create a plan, then design, deliver and deploy.  

Use Agile where there is uncertainty, you are unsure of your user needs, or where things change. That’s because the whole ethos is to embrace change and adapt to new information received.  

Don't forget the values and principles. If you embrace them, you are Agile! 

When thinking about risk, in general it can be higher with Waterfall. As time progresses, risk increases. But why does this happen?  

Teams gather and analyse requirements right at the start. So planning often relies on assumptions about future needs and conditions. Particularly when looking further into the future. Any misunderstanding or missing information can have a significant impact later.  

Teams use the initial requirements for the design and build phases. So any flaws in the design or changes to the requirements mean rework. So, changes at this stage become more expensive and complex.  

Since feedback and testing happen near the end, risk increases over time. Any late discovery of issues can have a significant impact on the project's success. After deployment, major issues can lead to delays, increased costs, and user dissatisfaction. 

Whilst Agile doesn’t cut risk completely, it does mitigate it. 

Each delivery cycle begins with analysis and planning. This allows teams to make adjustments based on new information. The team then focuses on designing and building limited features in each cycle. Since cycles are short and the scope tight, it reduces the risk of extensive rework. By deploying and testing in each cycle, teams can spot issues sooner. As a result, issues are easier and cheaper to fix. Through regular user feedback, teams can align the product to meet their needs. This in turn informs their planning for the next cycle. 

Now, you can make an informed choice about the right approach for you.