You've completed your Agile awareness training sessions for your business and technical teams and identified what waterfall processes you would like to – and/or need to – include for your Agile Pilot. Are you ready to start your first Pilot? Good! Let’s get started then.
Agile Scrum represents a fundamental shift from traditional “Waterfall” methodologies. An inherent flaw of waterfall is the assumption we know everything up front and that there will be little to no changes during the project. Even if requirements do not change the priority, timeframe, and customer may. In addition, Waterfall – due to its linear nature/flow – does not foster and encourage interactive communication and understanding between customers and delivery teams. As Agile Scrum incorporates short, fixed length repeating cycles, Scrum welcomes and supports communication, interaction and change. It allows customer teams and technical teams to improve as they go; “Do, See, Improve, Repeat”.
Traditional waterfall projects follow a set of linear steps, or gates, which hinder a team’s ability to communicate, learn and improve. These projects tend to encompass a long timeframe from start to customer review – and acceptance and production release – additional overhead (customer reviews and approval gates) are needed to update and review progress. This additional overhead impacts both the customer and delivery teams, as they have to take time to create and deliver these status updates. Often time new ideas, adjustments, and improvements to the process and customer request/product may not be easily incorporated; in turn, the product can suffer and usually achieves a lower ROI and satisfaction rating by the customer
Agile Scrum is small, repeating cycles (Sprints) which can include production deployments and/or the ability to bundle (Rack and Stack) Sprints into larger releases. While the work and deliverables can be mapped out in advance, the “magic” happens when the customer(s) and Scrum Teams work together to confirm and deliver the work as close to the actual Sprint as possible. Scrum Teams (technical and customer) benefit from the ability to “Do, See, Improve, Repeat” as they go. The product benefits by achieving a higher customer ROI and satisfaction rating.
Great Agile Scrum is just as much about what the team does not do, as it is about what it does do. In its inherent effort to eliminate waste and achieve balance, Agile Scrum focuses more on customer and team member involvement and less on milestone reviews or artifacts. This is where the work with your teams to identify and streamline some of the current waterfall processes pays off. For Agile Scrum, “Less = More”. While yes, Agile Scrum has a workflow and deliverables, Agile Scrum’s main measure of success is the on-going release of customer application updates and production deployments. As there is more alignment, transparency, and communication – and fewer meetings, overhead, and deliverables – your Agile Pilot customer and Scrum team can better focus and deliver. This focus helps reduce time, cost and risk while improving quality and ROI.
Now, back to your Agile Scrum Pilot…
Plan – For your Pilot, work with your Agile Scrum Pilot team and leadership to:
Review – Collect and review Pilot results with your Scrum Team and leadership. What went well? What could use some improvement? What should not be repeated? (I call this “The Good, The Bad, and The Ugly” report).
Tune and Repeat - Identify changes and improvements you want to make to your next Agile Scrum cycle. Then setup and run the next Pilot.
In the beginning, we’re looking to how a new Scrum Pilot is trending over time: Across their Sprints. We’re looking to see things are going well for the team and the customer, and that our output/velocity is trending in the right direction. Use your Agile Pilot as a shakeout time to confirm things are working properly, and adjust things, processes, deliverables, etc. that could be done better.
This is the 3rd of a four (4) part article on large/organizational Agile Transformations. Yes, there are many ways to approach this type of work. This is an approach I find works a majority of the time. Remember: each large Agile Transformation is unique. To be successful, each one must be adopted and configured to best support your agency. Every one is a dial, not a switch, in that while you create and work from a roadmap and a plan, you start out in small, measurable steps to help ensure alignment, transparency, trust, speed, and success for all involved.