From Waterfall to Scrum

The purpose of this post is to share my personal experience implementing Agile and DevOps methodologies on a development department that was working on waterfall approach.

Around one year ago the organization decided to move to agile development methodologies using a DevOps approach, with the help and guidance from an external company.

At first it was not easy to change the habits acquired over several years of project and was required a re-learning process for all project stakeholders; starting by the developers, following by the business and ending by the middle management.

For me personally, it supposed to start playing the role of Product Owner being my main task to help business owners on the definition of the goals and priorities for the medium and long terms and, on the other hand, I was carrying those objectives and priorities to the DevOps team creating and maintaining a prioritized backlog of user stories to be implemented.

Another important point was the adoption of the scrum rituals, from the 15’ daily scrum meeting to the bi-weekly demo in which the team can receive direct feedback from business about the new features developed. But I think the most important one was the retrospective where the team meets once every two weeks to make self-criticism devising and testing changes on the way they work with the objective of improving their results. Is this ritual the one that guarantees the continuous improvement for the DevOps team.

On the other hand, the move to DevOps supposed to add into the team infrastructure profiles so the team was fully autonomous to work without requiring other teams to provide systems, databases or other infra or technology pieces. So now, on each DevOps squad we can find a mix of developers, systems engineers, DBAs and other profiles. It has also meant that is the same team who provides the support on 24/7, so they are really motivated to deliver tested and quality code/systems.

Now, over a year after the start of this trip from waterfall to DevOps I really think it was a great success. I would summarize the greatest benefits as:

• Every Squad in the team is empowered and autonomous enough so teams are more motivated resulting in a clear productivity increase.
• There is a very big reduction of waste in managing teams and interactions between development and operation/infrastructure teams.
• The business receives more frequently deliverables and can provide feedback more regularly.
• There is an important reduction of the waste in drafting complex functional requirements that will eventually be changed in the future. Instead, user stories occur at the last moment, dedicating the necessary time and just before the team really start working on them (just on time stories creation).

As conclusion, I will say that to move to an agile way of working is the right decision if you need to run long projects with a big chance of having changing requirements but the main point is to have the support and commitment of the management for do such kind of big cultural and organizational change.