You Can Help Waterfallers Get Agile With Good Stories
It'll be a lot easier to switch to Agile after demonstrating the power of smaller and more effective stories.
Join the DZone community and get the full member experience.Join For Free
Agile may be a set of processes you support with well-designed, modern tools, but it’s also a mindset that values the power of a good story. In Agile, you use stories to describe the software features you’re building from the end-user perspective to communicate the necessary value these things will provide.
But the reality is, some people just don’t think that way. They think everything must be big so everything must be considered. All parts are related; therefore, we must look at the whole thing and keep all parts in mind. It would be safest to design it all up front to take care of any potential issues — before we code.
To many, this sounds rational, especially in enterprise IT where you’re handling incredibly complex and mission-critical applications infused with highly sensitive customer and business PII. However, it’s not the best way to do things in an accelerating world.
What this Waterfall mindset leads to is analysis paralysis. Nothing is accomplished because everything is too big. The story is too long, too complex. We’ll never finish the book, and if we do we’ll have skimmed over most of it.
When you understand how vital agility is to the success story of your organization in a digital age, others’ denial of Agile can be frustrating. But as Seth Godin recently blogged, “Changing a mind is different than having an argument. Persuasion takes patience, skill, and insight, not force.”
Mandating agility rarely works. To help Waterfallers change their mindsets and see the benefits of Agile, you need to walk them through why changes need to be made to how they work. You have to teach them how.
You have to tell them a really good story.
Changing Mindsets with Agile Stories
In our experience, a great way to help Waterfallers learn the power of Agile is through Agile stories, starting by finding areas where everyone agrees and working out the uncertainties from there.
For example, if it is known that something must be stored in a database, like an indicator, agree on that. You might hear, “But we don’t know the layout; we don’t know when it will be stored.” That could all be true, but you know something must be stored and you can start creating an Agile story at that point.
Create a story that will lay out the storage in the database. From that discussion, you may then get agreement on what needs to be stored.
Then you might turn to the interface. What do we expect from the end user? Simply, what are the inputs and outputs? If the interface needs to be designed, that is a story. You can create stories to handle the inputs and outputs.
Going through this process, you will identify what is known and what is unknown. Things that are unknown can then be researched. Your Waterfallers will begin to realize, through this Agile thing, you are simply breaking apart their big scary project to make it better and more manageable.
And don’t stop breaking things up there. You may have a story that is right-sized, but within that, there are separate tasks. A story can be broken into tasks that can be assigned to anyone. For example, if it is a research task, someone can work out the decision logic, someone can work out the storage of the values, and someone can prototype part of the interface.
Proof of Concepts
One tactic that is conducive to breaking up work is creating a research story where the acceptance criterium is to produce a proof of concept. The team now has something tangible and a lot of the architectural concerns get fleshed out early.
You can show Waterfallers that, from this, the team can see what’s possible, and smaller units of work can be defined and developed with an established vision. In this way, you help solve a common issue where the Product Owner usually has no problem defining the “what,” but crossing the barrier to the “how” can be blurry and lead to architectural limitations going forward.
Another healthy exercise to help Waterfallers understand the power of Agile stories is to create story sub-tasks for individual pieces of work to meet the acceptance of the story — but leave these sub-tasks unassigned. The units of work are small enough where someone new would be willing to attempt the work, instead of the same resource doing so simply because they are the subject matter expert.
Why do this? This practice improves the team velocity over time because the newer members are learning, and it sparks more collaboration amongst the team. Too often teams become heavily dependent on one or two resources because they are the most experienced or talented and the throughput of the team plateaus.
Moving from Waterfall to Agile is a huge change, and we need to remember that when we ask or expect others in our organizations to come along with us. It is a different way of thinking that some will feel comfortable with right away, but others may need guidance until they gain the comfort that comes from seeing the results.
Agile stories are a great way to show the Waterfallers in your organizations how even just this one facet of the Agile methodology can generate a litany of benefits you can’t realize with a Waterfall mindset. And if you need a little more power behind your push for new business agility, read our eBook, “10 Steps to True Mainframe Agility.”
Published at DZone with permission of Patrick Ashman. See the original article here.
Opinions expressed by DZone contributors are their own.