You might have heard/read a lot about transformation to Agile from Waterfall (or any other) Software Development Lifecycle (SDLC). While what you are going to read below is probably nothing new, I’m sharing my perspective on things that helped us in our product transition from waterfall to agile. Some part of what you read below might not be applicable as-is for your situation, but I hope it will be an interesting read.
Before I transitioned to PM from engineering, my product used to ship every 12-18 months. Today, we are releasing new beta version of our product every week! Yes, you heard it right, every week! Now that I have your attention, you can read further on the three key factors which helped us in this significant transformation.
Deliver value to customers in small chunks more often than delivering all at once:
There is a lot of literature to prove that most software delivered is not what customers expect. So, if we deliver a big piece of software all at once, there might be a big gap between this expectation and reality. Rather, it’s better to deliver smaller versions of the software more often and get constant feedback. This will help understand how distant we are from customers expectation. This step is easier said than done.
Before we started delivering our software every week, we worked on setting the stage by building a stable infrastructure. At the minimum, you should have below things in-place:
Robust continuous delivery and continuous integration system (CI/CD) – In theory, top-of-the-tree code should be shippable at any given point in time. To achieve this, we built a robust CI/CD system.
Release vehicle and feedback system – You should have a way to release the software for customers to test and give you feedback. This need not be your actual completely supported release vehicle, this can be any platform where customers can get hands-on with your software. Also, you should make it easier for your customer to give you feedback.
User stories should be broken into smaller pieces, so developers can deliver software in small chunks. PM will prioritize these small stories and developers will only pick stories from the top of the backlog.
The next key thing that should happen for a successful transition is the cultural change in the team dynamics. You will need strong executive support that believes in this mode of software development. This transition also requires a shift in the ownership of the quality of the software. In short, the developer owns the quality (ex: test driven development), the development team that writes the code owns it forever (till the software is in use). There is no quality engineer (safety net or throwing over the wall) who tests the software after the developer is done with his code and no sustainability team to maintain the code once it is delivered to the customer. Given human tendency to resist change, the success of such a transition purely depends on the belief and sponsorship of a higher executive. Something which also helped us in such a drastic cultural change is an ‘All-in’ approach, go to the extreme end of the spectrum and slowly things will settle down somewhere in between.
The last piece that helped is to succeed is the continuous collaboration between PMs, UX designers, and engineers. We adopted the principle of user-centered design where a PM will give the functional requirements and UX has the final say on how the UI should look/behave. PM+UX+Eng will collaborate all along the journey of our SDLC, thus facilitating engineers build the software that customers really need to solve their problem.
With this, I’m going to wrap up this topic. I know I said that there will be 3 key things, but within these 3 key things, there are many more things that we have done for us to be successful. I would love to hear back from your experience on any such successful transformations and what helped you. Feel free to leave a comment on anything related to this topic, it could be your experience or your thoughts on what I said above.