Promoting Agile in a Waterfall Culture

It’s all well and good to say that you want to adopt Agile practices. But sometimes, waterfall development processes are an ingrained part of the business culture. Changing the behavior for the team – and the executives and users – takes dedicated attention and a deft hand. Here’s one anecdote from Certified Scrum Trainer Mark Levison to show you how it can be accomplished.

Here’s the setup: The development team is so new to Agile that it hasn’t even tried Scrum. John is a project manager who reports to Don, the director of product development. Don is feeling a lot of pressure to complete the current project, and is starting to put the thumb screws on John and the rest of the programming team.

Not that this scenario bears any reality to your life…?

In this instance, John and Don are meeting with Don’s boss, Shawna. Shawna is coming down on both of them like a ton of bricks. From her perspective, the problem is that she has no idea when this project will be complete. Based on past history, she expects the team to come in 50-100% over its current projection, and she complains bitterly that this isn’t acceptable.

John, who recently attended ScrumMaster Training, pipes up that he thinks Scrum can help. Shawna gives him a withering look and then proceeds to tell him how Scrum is perfect for cowboys and undisciplined teams but it doesn’t work in the real world. For example, it’s inappropriate for enterprise teams with real reporting needs, such as those that have to file Sarbanes-Oxley compliance documents. In such a world, she says, only a stage gate, waterfall model works.

Don gives John a look that makes it clear that the word Scrum should never be uttered again. The meeting ends with Don demanding clear reporting of status and overtime from the team members to get it all done.

Analysis: What went wrong?

John tried to help by jumping immediately to a solution. That suggestion might well solve the problem but Shawna isn’t ready to hear about it. We have several problems behind Shawna’s knee-jerk response:

A low trust environment

Blame and shame

Fear

It is not safe to fail. It is not even safe to fail in the small.

John and Don are better off at trying to understand the nature of Shawna’s problem instead of trying to provide an answer. Perhaps Shawna is being hammered by the Board of Directors who complain that the company keeps on failing to meet its promises. Perhaps her pressure is a response to competitors releasing new product sooner than they do. In any case, we need to understand what Shawna really cares about most.

In our scenario, Shawna is feeling pressure from the Board. They’ve made it clear that if she can’t deliver in the next quarter they will find a VP of Development who can.

Story: A happy ending

Realizing he blew it in that initial meeting, John suggests to Don that they run a couple of small experiments, to see if they can improve tracking and reporting of the development work. Don says, “What do you mean, experiment?”

John suggests: For the next 6-8 weeks, let’s try two things:

Ask the team to meet daily, with the goal of improving collaboration and visibility of work. Let’s limit the meeting to 10 minutes.

At the end of every week, let’s demonstrate what we have done, even if everything isn’t done.

At the end of the experiment, John proposes, we review the results, find out what is working, and decide if we should continue. We also look for areas to improve. In the meantime, we all commit to making this experiment work.

John asks Don explicitly if he’s willing to commit to making this work.

Meanwhile, the team knew that Don and John were in a meeting with senior management and they understood the thumbscrews were being applied to them. John gathers the team and explains the pressure they’re currently under. John says, “We’ve been threatened with overtime, but we all know that isn’t effective. Instead, I would like to run a couple of experiments to improve our collaboration and help management see what we’re already achieving.” Tentatively, the team members say they’re open to trying something new.

John tells them about the two ideas he proposed to Don. Martin (database specialist), Brad (business analyst), and Tonia (quality assurance) have questions:

How will this daily meeting help? Won’t it interrupt the flow of our day?

What is there to demonstrate at the end of the week? We only integrate monthly.

John replies, “I honestly don’t know how it will play out but I think it can only help to try.” In addition he promises that the morning meeting will never last more 10 minutes. The team agrees to give both ideas a try. (It’s just for a few weeks; it can’t hurt.)

In an attempt to engage to the team, John asks the team what time they would like to meet everyday. A short debate ensues. Brad can’t get to the office before 9:15 (child care arrangements), but Martin arrives at 7:30 most days. In the end, they conduct a vote to choose between the two major alternatives of 9:30 (earliest option for Tonia) and 11:45, when they all break for lunch anyway. They also decide to make demo time 3:30 on Friday afternoons when most people generally feel they’re at an unproductive time of the week.

The next morning, before they meet for the first time, John walks around the team members’ cubes and asks what tasks they expect to work on that week. He also asks roughly how big each task is. When a team member’s tasks are longer than three days, he asks what the team member will do first and splits the task into smaller parts. Once he’s collected a list of tasks, John writes them on index cards and tapes the cards to a wall. He puts the cards in three simple columns: Not Started, In Progress, and Done.

The next day at 11:45, when the team gathers outside of John’s cube, they notice this wall of the tasks they told him about. To keep the meeting short, John proposes that they go round in a circle, answer some key questions, and then move on to the next person:

What did I do yesterday?

What will I do today?

What is slowing me down?

What do I need help on?

John encourages the team members to come up and touch the task they worked on. He also suggests that they save side conversations until the end. Finally, he starts a 10-minute timer on his phone, holds it up, and says “Start.”

The first day, they’re not even halfway through when the timer goes off, and they wonder what the point of all this is. However they’ve committed to the experiment and putting in best efforts. By the end of the week, they’re regularly finishing these meetings in less than 10 minutes. At the end of each meeting, John encourages team members to update the status of their tasks by writing on the index card or by moving it to the appropriate column.

On Friday morning, John walks round all of the cubes again and asks each team member what is complete and demonstrable. Doug has a screen that is finished but is not hooked up to any business logic, let alone the database. Ian, who is responsible for the business layer, has some business logic done according to the rules that Brad gave him, but no way to test it. Martin has started to build out the database and is making early efforts to attach it to Ian’s business logic. Unfortunately, Martin learned that Ian didn’t consider carefully enough how the business logic would work with the database. There will be some rework and Martin lays it at the feet of Ian.

In the early afternoon, John gathers the team together to demonstrate the completed work to one another and to Sue (in product management). Everyone stands up with pride, showing off the piece that’s done. Cheering is heard.

At the end, John asks, “Is there any single feature we’ve completed this week which we could demonstrate to Shawna? If not, how do we prove to her that we’re really as done as we claim?” Everyone seems a bit nervous, and the team members look at their feet. John realizes that he spoke too soon. To recover, he suggests that the team walk down the street to the pub and discuss ways of making this better over a pint.

Analysis: One week in

In a single week, John:

Established a task wall

Got team members to update the wall daily

Held a short daily team-focused meeting that is much like the daily scrum (whether or not the term is ever used)

Made team members aware of what their peers are working on

Demonstrated the work currently in progress

Discovered that rework happens when you aren’t collaborating enough (e.g. Martin’s discovery that Brad’s business logic doesn’t match the database)

Started to hold an improvement meeting (effectively a retrospective) in a pub

Moving the improvement meeting to a pub, coffee shop, or elsewhere offsite is an excellent idea, especially at the beginning of a transition. It takes the team away from the unrelenting work pressure and allows them the freedom to discuss improvements.

The team is off to a good start in a short period of time. However, we’ve not seen any real collaboration yet. That takes time; before collaboration can happen the team members need to be aware of what their peers are working on.

Most important: After one week we really still have no way of measuring how much work is really done. We have no way to report to Shawna. However, that’s a good start for a single week.

Recommended Resources

Adopting an agile development methodology is a significant undertaking. The Mendix App Platform brings all of the pieces of an application development project (development, deployment, database management, etc.) into one comprehensive platform, allowing you to show results quickly and iteratively. Mendix also gives teams a leg up with project management features made to support agile development processes. Kan-ban style task boards like the one described in this post, easy-to-use burn down charts, user story management, and an integrated feedback widget can help teams make the move to agile. Check out the Mendix App Platform or sign up for free.

About Mark Levison

Mark is an independent Certified Scrum Trainer since 2011 and Agile coach. Mark brings over 10 years of Agile experience with an emphasis on Certified ScrumMaster Training, Agile Coaching, Project Assessments, and Team Launch Workshops.
In 2009, Mark founded Agile Pain Relief with the mission of providing consulting and training for organizations seeking the benefits of Agile methods. As its principal, Mark has introduced and mentored developers, managers, and executives in organizations throughout the US and Canada on Scrum, Lean, and Agile methods through hands-on training.
Mark is active in the Agile community and participates as Agile Editor at InfoQ and writes extensively on Agile topics in his blog, Notes from a Tool User. You can find him on Twitter @mlevison and Facebook as Agile Pain Relief.

Mendix is the rapid application platform for the enterprise. We enable companies to build, integrate and deploy web and mobile applications faster and with better results, effectively driving ROI in days not months.