Agile waterfalls and lagoons
Recently, I went on a short walk in the beautiful Yorkshire Dales in the North of England. Ingleton Falls is an 8km trek through Glens and Falls with truly stunning views.
Half way round the circular trek, we stopped to rest. Sitting on a bench looking towards one of the main Falls, I took a few lazy iPhone snaps before pressing on as the winter light faded.
Later that week, I sat on a call with a client who wants to move to a more agile development methodology for some or their SAP projects. Their initial attempts had been partially successful but there was some negative feedback and they were keen to learn from our experience in order to improve the next 'agile project'. The discussion was energetic and there were some really insightful questions asked.
Things like “How do we decide which SAP projects and changes are strong candidates for an Agile approach?” and “How can tools help us to assess the impact of removing scope from a release part way through build?”.
But one question in particular stimulated a lively discussion and it was one which I would have answered differently had I not been on my walk earlier that week.
“How do we manage delivery of Waterfall projects along side Agile projects?"
The answer was obvious. But the photograph I’d taken from the bench on my winter walk helped me articulate it better.
As you can see, the scene shows a large two-step waterfall. Then a small lagoon area, followed by a series of smaller streams flowing in parallel over the rocks.
My white-water answer just seemed to gush out.
“Big Waterfall projects can be seen as a series of Agile Sprints. You can view a project as one large waterfall or a series of shorter sprints. After all, it’s the same water whether it goes down one big dramatic waterfall or through a few less conspicuous channels. And having somewhere to store the things that you might do next means that you don’t have to throw everything down the waterfall in one bug splash."
It’s not a case of Waterfall or Agile. They’re just different ways to move things downstream.
When you do ‘agile’ you still need to do the same things - analysis, design, configuration, coding and testing. The difference with Agile is that you’re always doing these things. With Waterfall, you tend to just be doing one or two of these things in large phases. With Agile, it’s ongoing. That’s why we call it ‘continuous delivery’ because you’re always doing it - continuous development, continuous integration, continuous testing.
Because you’re working at a faster cadence, you’re better able to course correct and to change scope. With waterfall, once you commit to a large scope of release, it’s hard to change. With agile, you only ever commit to a small scope of release and leave everything else sat in the ‘lagoon’ waiting for it’s turn to burble it’s way down stream.
Ultimately through, the most useful part of the discussion focused on ‘bundling’ and ‘unbundling’. Deciding which ‘stories’ should be bundled together into a ‘release’ is key. The difference with water is that every ‘piece’ is the same. It can adapt and flow. IT changes are different - they come in different shapes and sizes and they inter-depend differently depending on how they’re bundled. Making the right ‘bundling’ decision at the start of a release and selecting scope consciously of it’s inter-relatedness is an important factor. And, knowing whether you can safely ‘unbundle’ changes from a release without affecting other changes is crucial too.
So called ‘late unbundling’ can be challenging in SAP environments because the standard SAP release management tools were built in an era when everything flowed downstream in a single, large, dramatic splash. Today’s business want change to happen more quickly. Faster time-to-market and business agility have become the new competitive battleground. And that calls for different ways of working and tools that support a modern development philosophy.
Download our ebook How to get started with Agile for SAP now.
