In an environment where the team now practices Agile methodology, and previously practiced Waterfall, there can be some carryover habits. Shifting culture and mindsets to Agile practices is a huge undertaking! I am not trying to sell either methodology here. I am just exploring some ideas to help with the scenario of a team moving to Agile, from Waterfall.
Focus on priority, over due dates and timelines when shifting culture
A primary focus of the Waterfall methodology is defined pieces of work in specific time frames. The intent there is that you have known project work, you know when you need to have it delivered by, thus you organize the work to meet the due dates. Where this typically goes wrong is with the understanding of the work to be done. Also with understanding how long that work will take. Quite often, 1, or both, of those items require more than was planned. This makes the project timeline inaccurate.
My resolution for this is to focus on priority. If the team works on top priority work first, they are already working on the right things. If the team is not working on top priority work, then we need to shift to the higher priority items.
Practice what you preach as a PO
Remember good practices in incremental development. Add to the product iteratively, and don’t expect it all to be completed at once. Keep work in smaller, standalone pieces, that you can work on in a sprint. As a PO, you need to help promote that approach of building out in iterations. Be careful as a software Product Owner with this one. As the PO, you want to see the completion of work, to see the results of the work. However, you have to remember that you will get there as you complete iterations of work. You likely won’t reach the goals all at once, but by working towards them over time.
Inspect and Adapt for shifting culture
Help promote good reflection on process and work. This isn’t just in the retrospective ceremonies for the team if your team utilizes these. It should happen both individually and as a team, outside of this. Within all appropriate rules, norms, and guidelines that your organization may have, you should strive to use the best tool for the job. Understand the work to be done, and try to determine how best to approach that work. This could mean adjusting tools or processes for the team, to best deliver that work.
The inspect and adapt idea is a fundamental concept in Agile software development. It is a change from Waterfall development though. Waterfall can often have very rigid processes and tools. They are deeply entrenched informal processes and can require a lot to change. As the PO, remember to bring up for the team, the idea that they are empowered to find improvement. Some of it might require others before it could be changed. That is ok, but the team has it within their ability to really bring on that change.
Remember what drives work completion for shifting culture
Your work is done when you achieve goals. Not when dates happen or time frames go by. When you complete enough of a goal, the work for that goal can all be completed. This makes building iteratively important. As sometimes you complete enough work that your goal is met, and you can stop sooner than expected. If you were working up through a due date, you would never make that realization.
Conversely, if you did not meet the goal, you must continue the work. It would again be a question of priority, but if the work is a top priority, it would continue above other work. It can be easy to get caught up in the due date conversation. As a PO, remember that you are working to meet goals. Use those goals to drive the work.
Again, I am not selling Waterfall or agile here, once an organization has selected an SDLC to use (in this scenario it is agile), I am simply trying to help with some tips to make that shift from Waterfall SDLC to agile.
Additional reading and books that helps in shifting culture away from Waterfall ideas and practices
