Can Waterfall be Agile or Lean?
In 2017 I have written a lot of blog posts on Lean. I focused on the lean startup principles as designed by Eric Ries in his book The Lean Startup. However I noticed that in practice not one project is fully lean. Especially when you work for a big corporate. You have to deal with a lot of culture, legacy mentality, scattered focus and limited resources.
One of the projects I have been working on for the last 2 years is a big infrastructural project, so a typical waterfall project when you consider its length of duration.
Data was scattered in all kinds of different systems. And not one of these systems was connected with the other. Colleagues updated data in excel sheets or vendors updated these in the systems based on instructions sent through email and /or word templates.
The main challenge was to choose which system would be the point of truth. During several sessions with about internal 10 stakeholders, two of the most used systems were identified as the focal point. The CRM in which a lot of data was stored and the CMS which puts the content with its metadata on the websites.
Again it took another session before the CRM was identified as the point of truth. The point of truth simply being the entry point for all data to be added or changed or deleted. However the questions was also how to connect the CRM to our CMS.
Together with two vendors specialized in CRM and CMS, we identified that the best way to connect the systems was real time data delivery through API. However it turned out that creating APIs is costly business and since budget was tight we had to search for an alternative: real time .csv file delivery to and pickup from an ftp folder.
What can you can conclude from the above?
There were already two scope changes within two months: the point of truth for entering data and the way in which the CRM and CMs interacted. But in just a few weekly sessions the scope and scheme were clear.
Mind you, I put in the ‘just’ because with waterfall you can easily get stuck in decision-making which can take up months. So in this sense we were quite ‘agile’.
What was next?
Now it was time for development. The group of stakeholders became leaner: five people: two vendors, and three direct end users or in ‘lean terms customers’ of the CRM and CMS. We decided to have 1 weekly meeting of half an hour. First of all we did a show and tell of what had been done. Then discussion followed on: What are we doing? What are we going to do? What are the pain points we need to tackle?
This resulted in a clear overview of tasks, weekly progress in development, weekly testing with the stakeholders. Thus we started up typically agile.
And then delay on delay happened.
Why?
Because another bigger infrastructural backend project took away resources and focus.
No biggie, just something you have to deal with in big corporates, I guess.
As a result meetings became less frequent and development slowed down a lot. The big project took about 1.5 years to be finalized and also affected our project. The CRM we’d chosen as the point of truth was overhauled entirely and needed to be connected to a new backend vendor.
This meant that after 1.5 years we had to completely revisit our project. However since we had kept on developing we actually were quite up to date with the latest changes as a result of the big backend project.
September 2017 we started again with our weekly agile meetings with our lean group. We had several tests with the end-users and just before Christmas on 22 December 2017 we went live. Not with a big bang but certainly satisfied. Satisfied in the sense that the project which took 2 years actually was done in 6 months if you take away the backend project.
So a seemingly waterfall project can have agile and lean elements in it. I’d like to call it an Agile or Lean Hybrid project. This is typical for big corporates with scattered focus and limited resources and is much more common than people may think.
