Agile Pushing/Pulling a study

Introducing Agile methods to a team in an organization deeply rooted in waterfall ways is tough, especially when the culture is risk-averse and well-established. But you can be a catalyst for change and help your team learn to be more agile by following three simple practices.

About my learning, I learned Agile methods early on from some of the industry’s best, practioners, Trainers.  For more than 15 years, I was part of an organizations that embraced Agile values, was customer-connected, and focused on continuous learning. And then as life progressed I changed jobs. More importantly, I changed organizations.

The culture shock was intense as I went from the world I knew of embracing change, to a culture that spoke of learning and growth, but was weighted down in waterfall ways and cemented in processes averse to change. Instead of co-creating value with the customer and validating along the way, I found myself among a sea of BUFD (“Big Up-Front Design”), and the customer at the tail-end of the process.

I had my work cut out for me. I could be a fish out of water, or I could teach others to swim. I chose the latter. Otherwise, it was not just me at stake, the organization would sink in today’s highly competitive world.

But I was intimately familiar with organizational change gone bad, and I experienced many situations first-hand where the change agent fails and loses in the end. Luckily, with the guidance of a mentor, I learned that I needed to be a change leader, not a change agent, and that starting small, and building momentum is the key to success.

Early on, I it was like pushing rocks up hill. I did brown bags, I gave out copies of my book, Getting Results the Agile Way, and tried to preach the gospel of the Agile ways, but it fell on deaf ears, or, in other cases, the student wasn’t ready. But the irony was that the organizational pain was exactly the impetus that would justify going Agile. There was a lack of clarity in customer demand. People were over-worked and felt under-appreciated. Change was a constant on a daily basis, and yet people could not respond quickly enough or use the change to their advantage.

And then, I changed my approach. Rather than “push” Agile, I inspired people to “pull” it. I did so in three specific ways:

1) Ask better questions

2) Lead by example and

3) Reinforce positive behaviors.

Together, these simple practices inspired others to learn and adopt more Agile approaches in their thinking and in their actions, and this built momentum over time.

 Ask Better Questions

I started asking simple questions in the hall, to key people. The most important question I started with was: “What were our 3 Wins from last month?”

I would tee it up by saying, “We put in a lot of hours last month. Looking back, what are the actual wins we have under our belt?” It was a simple way to get leaders reflecting on how well all the hours we throw at work are leading to significant outcomes … or not.

Looking back was now the key to looking forward. I would then ask the following question: “What are our 3 Wins we want to achieve for this month?”

Soon, people started thinking in terms of outcomes for the month. It was no longer good enough to throw a bunch of time at things and accomplish a bunch of tasks, and yet have no simple stories of success, or customer victories to show for it.

I didn’t stop there though. To reinforce the idea of chunking up things and thinking in terms of incremental value, I asked simple questions in team meetings and in my 1:1 with my manager:

What were your 3 Wins for last week?

What are your 3 Wins for this week?

What are our 3 Wins we want to achieve for this year?

Questions served as the prompts to start driving better behavior, and getting people to get curious and seek better ways to find their 3 Wins. 

 Lead by Example

People learn from others and they model the behaviors they see — especially if the behaviors they see lead to results they like. The three most important behaviors I set an example for were:

Visualize the workflow on the wall

Daily standup meeting with the team

Pairing up with others to create better, faster work products

To visualize the workflow on the wall, I created a simple Kanban for the team, where people could see our backlog of work items, the current work in progress, and work we completed. I kept it very simple and used only three stages: To Do, Doing, and Done. On Mondays, in our team standup, I went around the team, and asked each person to identify their 3 Wins they wanted to achieve, write them down on a sticky, and add them to the Doing column. Instantly, everybody had a chance to show and share their focus for the week.

For daily standups, I asked the members of my immediate project team to attend a simple “Ten at Ten” meeting. The idea was to spend 10 minutes at 10:00 AM each day to help us stay in sync, deal with any changes or urgent issues, and unblock people on the team. We’d simply go around the team and state three things:

What did you get done yesterday?

What are you working on today?

Where do you need help?

This helped the team stay connected, fluid, and always making progress with focus and momentum.

On pairing, a lot of people were resistant at first, but once they experienced it in action, they latched on to it. They liked the idea that rather than get stuck on something, two people could put their heads together and blast through something faster that might otherwise be death by a 1,000 paper cuts. To get started, if we had to produce a document, I would simply open the document, and start asking questions to frame out of the key outline of the document, and start plugging in key information. Once the skeleton for the document was in good shape, we would then split off, finish things off, then pair back up to do a live review. It was fast, effective and people got to learn from each other at a faster pace than they otherwise could.

 Reinforce Positive Behaviors

This is perhaps the most important way to help a non-Agile team adopt Agile practices. People like to succeed. Catch them doing something right, and call them on it. Use learning opportunities and leadership moments to coach people, not critique them.

The most important person I focused on first was my manager, since he set the tone for others on the team. For example, his strength was focusing on tasks, but not focusing on wins. It was his growth opportunity. When he would identify his 3 Wins he wanted to achieve for the team for the week, I would be sure to tell him how it helped us focus, prioritize and know what was valued. This helped reinforce the behavior by letting him know how it shapes the team’s impact for the week.

So the point is whenever it feels like resistance, figure out the causes for concern or reasons for resistance, and use them as feedback to tune and prune the approach. It's always amazing how one approach can be so much more effective than another, and yet they both attempt to achieve the same goal. And, in my experience, adding "the fun factor" always helps.

As Gandhi said, “Be the change you wish to see in the world.” The key is to start with your immediate world and to bring others with you. The key to bringing others with you is to prompt them with the right questions, lead by example, and reinforce positive behaviors. As a project leader, skilled in the art and science of Agile practices, the world needs you now more than ever. Your success, and the success for those around you, will depend on how well you lift them and help them learn the agile way.

Along these lines, experience tells me three keys to successful change that show up time and again are:

1. Change the approach - I've seen how changing styles or approaches radically helps success

2. Change the time frame - Often, it's too much, too fast. Little wins with momentum works better.

3. Change the people - Sometimes the chemistry is off. Try another change leader. Sponsorship can make a big deal here.

The trick is to become a master of the process and evangelize to terms / jargon, but good ole organization, leadership and communications goes a long way.

And remember, sometimes a great change has the right intent, but unless somebody helps map it to specific benefits by the people impacted, it will meet a ton or resistance. Also, I find people in general sign up for change, when it's not pushed down their throat.

There is a great deal of opportunity to expand Agile into other arenas. In fact, aside from "Agile for Life", my favorite place to apply Agile approaches is to learning and education. One of the ways we improved our success is by doing an "exploration" phase, before we start "execution." During exploration, we collect user stories and system stories, and then prioritize the set with customers to validate the impact. By the time we start executing, we have a great view of what a Minimum Credible Release (MCR) or MVP (Minimum Viable Product) would be. Sure, things change during the development cycle, but this vision of the MCR keeps us grounded.