Agile Sprint Iterations for Waterfall Release Schedules

As many companies are now trying to "Be Agile" or "Doing Agile" we are still stuck in the Waterfall methodology and mindsets for program and project management for releasing products. The phrases of "We are now doing Agile", for example, means little if the mindset to change how they plan and develop the value for their product(s) being released is not truly Agile. There is a phrase I love and that is "Sometimes you have to go slow to go fast." This phrase, to me, says it all when companies are shifting the way they work. In short it means that sometimes you have to slow the train down to put things in place such as automation (ATTD), behavior driven development (BDD), continuous integration, doing the work as a team from start to finish top down in their sprint backlogs to reduce overall WIP, having a clear understanding of the ranked Epics from product so the team can plan their work and a clear understanding of the vision of the product and its customers.  Of course there are many more things than those listed but I find those to be the key areas when changing from Waterfall to Agile mindsets. At first it will slow the work down but over time as the team(s) stabilize they will mature and work much faster and more efficiently.   

Sadly, most believe because they are simply doing X,Y, Z Product Backlog Items in a designated timeframe (sprints) and they are conducting Scrum activities (for example) it must mean they are now "Doing Agile." The problem is that there is no vision to what they are doing for providing the best value in the releases.  In most cases nothing else is changing because they are still adhering to a Waterfall release schedule and release management tasks.  They are still trying to account for what each person is responsible for, the time it takes for them to do the work, over estimating their capacities.  There is no transparency or empowerment for the teams.  They are still dealing with top down management, very Waterfall-like mindsets in management... the list goes on and on.  But hey they are "Doing Agile" since they work in sprints and have some of the Scrum activities, right?

I'm a firm believer that when a company is going through a transformation that not just the folks doing the work for the product(s) get trained and have ongoing coaching but that the whole company from the top down layers get trained and have consistent coaching.  Otherwise, you are setting yourself up for failure and will never get to being an agilest.  Teams are no longer the individual contributors. Entire team(s) get the work done. This is a concept hard for many to grasp as they still want to know what each resource is working on, how they are spending their "hours" each day, why there are so few stories in a sprint when there is a team of say 6 people ranging from developers, QA testers and BA that could be working on a story/tasks.  So let me fast forward to my specific experience and hope this will clarify why I wanted to share this article with you.

Currently, in a Waterfall-Agile-Scrum-Kanban blended environment where releases are 100% Waterfall on a quarterly basis.  However, the work being done on the team is done in 2 week sprints.  The team has for some time now been told what stories to work in their sprints from the backlog.  Through time I have been working with the team to help build their empowerment and break down this top down management mentality coming at them.  Recently, I had a 1.5 day Program Iteration Planning workshop where I invited the team, their manager, multiple folks from Product (including Product Owner), and several other product stakeholders.  My goal was to open their minds to how we determine VALUE in what we are making and releasing.  So to start the workshop I began with a simulation activity called "Buy a Feature" and gave everyone $2250.00 in play money.  I had created poster boards and hung on the wall around the room with roughly 15 features they could choose from with their description and cost to purchase.  It was a made up product and features for the exercise with some features that were rather funny.  I instructed them that they could co-invest if they'd prefer by pooling money together but ultimately to mark which ones they wanted and hand me the money.  Next, I asked them to each explain the reasons why they purchased the features.  Only a 1/3 of the room actually purchased the most important feature which was the application infrastructure piece.  Without it you don't have an app to sell.  So moving on, the next task for them was to create 3 iterations of what they would do in their first release, 2nd and final.  They all took to the wall and began talking them over and created 3 release iterations.  At the end of the activity I had a room of people that 'GOT IT' and why we were together to begin planning out our next Q1 2019 release. 

Beginning the planning process.  First we redefined our Definition of Ready and Definition of Done and then reviewed what team agreements and policies should be created. Historically, there have been sprints where work is coming in that is not meeting a DoR which causes havoc to the sprints.  Next, I had created all of the backlog story cards based on what Product provided to me ahead of time as their top ranked epics.  Provided them with all the post its, markers, string for dependencies, colored tabs, white wall paper and tape so they could plan until their hearts were content.  First, the team started going through the stories by laying them out on the long conference room table in order but then started asking questions on whether some of the work was necessary up front if it was small and had no risk even though the epic was ranked higher than other work.  Good questions, right?!  They also started asking product about stories they didn't understand the value in for this release as they didn't have capacity for the work due to holidays, etc or just didn't see how they fit into the vision with the other ranked epics.  Again, more good analysis!  They noted with strings dependencies of stories in early sprints to later sprints, something they have never done before or even thought of until the work was upon them.  As a team they collaborated on capacity for the holiday months and dropped down their velocity points for several sprints. Also, as a team they collaborated on which stories they would do in each sprint iteration, created new stories, and HOW they would get work done which included increasing automation in each sprint iteration without being told. For the first time ever they had ranked epics for a specific timeline to do the work.  After a full day of planning the team had a full wall created of all the sprints that will make up this 'Waterfall' release schedule.  Additionally, the team pushed back on taking more than they felt they could consume but held to taking in the top 5 ranked epics so they could still release value to the customer.  "Just Enough" as they say.  I was like a proud mother in these moments! 

These are the journeys that show that when you slow things down and help folks better understand the goals you can be Agile even in Waterfall release schedules.  The above is an example of how by providing some coaching folks can see ways to be more efficient, work collaboratively as a whole team, and provide just enough value if you give them the power and knowledge.  While it isn't truly embracing the agile transformation, sometimes it is the baby steps that have to be done first to go faster later.