How Walmart is Going Agile with… How Many Coaches?!?

Please note that the views expressed here are my own and do not necessarily reflect those of Walmart.

Walmart Stores, Inc. is the world’s largest retailer, a Fortune 1 company, which spans 28 countries with over 60 different banners. Many in the tech world may know about Walmart.com or @WalmartLabs, significant and important arms of Walmart’s Technology organization located in the rich technical environment of California’s Silicon Valley. What many people don’t know is that the bulk of Walmart’s tech talent lives and works in the heart of Walmart country, at their headquarters in Bentonville, Arkansas.

There you can find thousands of associates working hard to support associates in the home office, stores, clubs, and distribution centers, as well as our customers. It’s been the hub of Walmart’s technical solutions for decades and has been subjected to many of the struggles and opportunities that other long-lived IT departments have faced, including the recent challenge to “Go Agile”. And they’re doing it!

With four Agile Coaches.

The Agile Coaches Group in Summer 2015 (with our corresponding Guardians of the Galaxy bobbleheads)
From left: Spencer Offenbacker (Product Manager); Mike Carey (author); Todd Kromann; Joshua Rowell; Amanda Tygart

Only Four Agile Coaches?

That’s right. Walmart’s Information Systems Division employs only four full-time Agile Coaches – all internal – to lead the transformation effort for thousands of associates. They serve not only those working in Bentonville; the Agile Coaches have traveled to Mexico, Costa Rica, the United Kingdom, and India to help with the Agile transformation efforts in those offices. As the work of transformation continues to grow, Walmart ISD's Agile Coaches will likely travel to Walmart’s other development centers around the world in the coming years.

Mike Carey (author) with two associates from Guatemala while coaching in Costa Rica

Mike Carey (author) with associates in Walmart's GTS (Global Technology Services) - Mexico office

Mike Carey (author) with more associates from Walmart's GTS (Global Technology Services) - Mexico office

Associates in our GTS (Global Technology Services) - India office participating in an Open Space event facilitated by Agile Coach Todd Kromann

Todd Kromann with an associate in our GTS (Global Technology Services) - India office

Amanda Tygart with associates from Walmart de Mexico y Centroamerica ISD

Walmart’s Agile Coaches are also not long-tenured positions. The Agile Coach role is viewed more as a sabbatical for those who have passion for Agile and have already garnered a reputation for assisting those around them with their transition to Agile. I know this well, because I used to be an Agile Coach. Todd Kromann and I were the first two Agile Coaches for Walmart ISD, a role I enjoyed for over a year and a half before leaving to take another position within the company. This helps ensure the working knowledge and skills of the Agile Coaches are relevant to the changing demands that come with an ever-shifting technological landscape.

The first two Agile Coaches for Walmart ISD - Mike Carey (author) and Todd Kromann - presenting at #Agile2014

At #Agile2014, from left: Mike Carey (author, 2nd Agile Coach); Barry Nicholson (3rd Agile Coach); Selena Hriz (Core Champion); Amanda Tygart (4th Agile Coach); Todd Kromann (1st Agile Coach); Subhendu Mishra (Core Champion)

Wait, so not only does Walmart only have four Agile Coaches for thousands of associates worldwide, they also rotate on a 1-3 year basis? How does that work?

With the help of Agile Champions.

What’s an “Agile Champion”?

In September 2014 we officially launched what we call the “Agile Champion Network”. We implemented the concept of Agile Champions for months prior to solidifying it into a useful structure, and found that the use of Agile Champions was invaluable to the Agile Coaches keeping their WIP in check. On September 26th we held an Open Space to kick things off, and a blog post was published on the 18th to help lay the foundation for what we were trying to accomplish. Below is a snippet from that blog post:

“The objective of this event is to crowd-source the collective intelligence and skill of our Associates to determine:

"What are the responsibilities of an Agile Champion?

"How do we identify existing and emerging Agile Champions?

"How can we better leverage our Agile Champions?

“As we've been preparing for this event, one of the frequently raised questions is ‘What's the difference between an Agile Coach and an Agile Champion?’

“I'll start by covering what they have in common. Both have a solid understanding of the Agile mindset, or what it means to ‘Be Agile’. Both are change agents who seek to increase value delivery and reduce waste. Both assist others seeking help with their personal or team Agile adoption.

“Now let's look at the differences.

“An Agile Champion is only expected to have a deep understanding of at least one facet of ‘Doing Agile’. Agile Coaches have a broad understanding of Agile practices, with depth of knowledge and experience in many facets.

“An Agile Champion assists others part-time; he or she is an active practitioner on an Agile team or project. Agile Coaches have experience as a practitioner (and we have organized ourselves as an Agile team), but our full-time job is to assist others.

“[…] The Agile Coaches have an immense responsibility for such a small team, which is why the Agile Champions are so important. The leadership and initiative of our Agile Champions take some of the load off our backlog, allowing more people to get the assistance they need. If you are interested in taking a more active role in the adoption of both ‘Being’ and ‘Doing Agile’, please plan to attend the Agile Champion Open Space next Friday.”

Out of the Open Space, it was determined that an Agile Champion should possess the following traits or skills:

• Knowledgeable about one or more specific aspects of Being or Doing Agile and have a willingness to share that knowledge
• Credibility in the organization
• Excellent interpersonal and communication skills
• Ability to demonstrate the Walmart Culture
• Passionate, positive and enthusiastic attitude
• Commitment to continuous learning and improvement

Agile Champions opt-in to the network, where those seeking assistance can find them and reach out. Champions register with their name, the skills with which they can help others, their location, the number of hours per week they are typically available, and a few other pieces of information. Those seeking help can search by skill and further sort or filter by any of the other attributes before selecting someone to reach out to. We currently have nearly 100 Agile Champions across half a dozen locations worldwide, all willing and able to help their peers through this journey.

Walmart Coaches and Champions at #Agile2015
Standing, from left: Amanda Tygart (Agile Coach, ISD); Amber Wright (US Agile Champion); Marc Thomsen (UK Agile Champion); Jenny Swan (US Agile Champion); Robert Moores (UK Agile Champion)
Kneeling, from left: Tony Goulart (eCommerce Agile Coach); Luis Figaro (Brazil eCommerce Agile Coach); Jerry Schroeder (US Agile Champion)

Clockwise from front-left: Mike Carey (author, Agile Coach); Arturo Robles Maloof (MX Agile Champion); Joshua Rowell (Agile Coach); Jessica Collins (US Agile Champion); Barry Nicholson (former Agile Coach, Agile Tools Product Owner); Todd Kromann (Agile Coach); Amanda Tygart (Agile Coach)

A sampling of Walmart Associates (mostly Agile Coaches and Champions) and significant others from around the world at an "ISD Remotes" dinner, hosted by the internal Agile Community

The “Revolving Door” We Love

In addition to the self-service network, the Agile Coaches keep a pool of at least six Core Champions at all times to whom they frequently pass off requests for help that they know the Champions can handle. This helps the Coaches stay focused on the work that they alone have the skills or bandwidth for. Core Champions also pair with the Coaches frequently to help build up their skills and reputation. It is from this Core Champion pool that Agile Coaches are chosen (by the Agile Coaches, not management) when one leaves to take on new responsibilities.

We know this is an unorthodox approach to such a massive undertaking, but we’re doing it and it seems to be working. Since officially starting our Agile Transformation in February 2014, the amount of work being done using Agile approaches has increased from around 10% to a projected 80%+ by the end of the current fiscal year. Our associates have gone from discussing whether or not Scrum is a good idea to how we can achieve Continuous Delivery. Our internal Agile Community has grown from 514 members to almost 1500, with dozens still joining every month.

There is no question that our success would not have been possible without our Agile Champions. Not only do they relieve some of the pressure on the Agile Coaches, they have embraced self-organization and grown in their capacity as leaders and change agents. They are showing others what it means to be a Servant Leader and help those outside their traditional circles of influence. They are empowered and it shows.

The model is simple: a small central authority (the Agile Coaches) working with a large, decentralized network of part-time "volunteers" (the Agile Champions). I highly recommend it.

This post is an attempt to take the experiment and conversation that's been run inside Walmart to the outside world. I want to hear your opinions, your ideas, your critiques, your experiences. Comment on this post or reach out to me via Twitter or LinkedIn.

Life after your First Agile Project

This blog post is adapted from a workshop/presentation I recently led at the May NWA PMI Professional Development Day.​



So, you just finished your first Agile project in a Waterfall organization. Now what? Let me put my Agile Coach hat on and tell you, “It depends.” It depends on whether or not it was a positive experience and how supportive the overall organization is of this “Agile thing”. Let’s run through a few possible scenarios.

Agile Sucks

You may be one of the many people whose first exposure to Agile is a negative one. Maybe your team was uncooperative. Maybe there were too many practices that were too new for the team to successfully adopt. Maybe the organization was so un-Agile that your team got exhausted from trying to swim upstream the whole time. Or maybe your team never really became an Agile team; you were a bunch of silo’d individual contributors with Waterfall mindsets trying a new front-end to the same process you’ve always used to get the job done. Whatever the reason, all you know for sure is that Agile sucks. It simply does not work; not for you, maybe not for anyone.

As an Agile Coach, I am sincerely bummed if this was your experience. I wish I could have been there to help make sure you knew why you were adopting Agile, not just how to go through the motions. I wish I could have been your heat shield, to protect you from the Agile defeatists and remove organizational impediments for you. I wish I could have helped you through the forming and storming stages of a team into norming and performing, so that you could benefit from a team who, corny as it sounds, was greater than the sum of its parts. I wish I could have helped you learn how to continuously improve not all at once, but incrementally.

But I wasn’t there, so what will you do? I hope that you will take pause and consider the possibility that those Agile proponents can’t all be crazy. What did they do or have that you didn’t? What might you have missed? Get involved in virtual and physical Agile communities, remain open-minded, and stuff your toolbox with as many practices and approaches as you can. Study the Agile Manifesto and its principles and recognize that what it’s defining is a mindset, not a methodology. You have to be Agile before you can successfully do Agile.

Agile Recipe

Maybe you had some success with Agile – or at least you think you did – and you want to keep doing it with all your future project teams. What really happened is you ran a successful Scrum project, and you’re ecstatic that you found a working recipe that will turn any team into a high-performing team. The team followed the Scrum Guide to the letter and there’s no doubt in your mind that this is what Agile is all about. Agile is Scrum, Scrum is Agile. If you follow the exact same approach, you are confident you will have similar results with your next team. After all, this is the same company, same culture, same organization support and/or impediments. Why shouldn’t you expect the same results?

The short answer is because it’s not the same team. Even if some of the people are the same, if the make-up of the team isn’t exactly the same then it’s a different team. You’ll be starting back at the forming stage with a new backlog, maybe even a new Product Owner, and there’s no guarantee that this group of people will interpret and embrace the Scrum Guide the same way the old team did. Hopefully you learned enough about teaching, coaching, and/or facilitation from your last team that you can guide this new team through the same pitfalls in a faster, safer way. Hopefully you learned Servant Leadership skills that will help you get buy-in from the team to try this new thing. Hopefully.

Hopefully you learn by the end of this project how much more successful the project would have been if you would have kept your previous team together. There is a cost associated with breaking up a high-performing team and knocking everyone back to the forming stage. There are also reasons that you may want to incur that cost in order to reap specific benefits, but “because the project ended” is not one of those reasons.

Keep the Scrum Team

Not only did you have success with the team, the team became a family. You are now a high-performing Scrum team that knows the process and each other so well that you couldn’t dream of breaking them up. You manage to keep the team together for the next project, and you hit the ground running.

This is great, but you have to be careful. If you have decided that Scrum is the be-all end-all of Agile then, eventually, the team will begin to stagnate. Scrum ceremonies will become ritualistic instead of productive, thought-provoking team activities. Group-think may begin to crop up, and the electric feeling of respectful debate will flicker out of the team. Some team members may become too comfortable, others restless. If you don’t do something, you’ll lose everything you fought to keep.

My hope is that you learn that Agile isn’t about following a recipe. It’s about starting with a recipe and making it your own. It’s about evolving the way you cook, trying new flavors, and learning how to transition from cook to chef. Hopefully you find all the success you were looking for and more, because our successes motivate us to keep going, keep trying.

Become comfortable with mining for conflict and facilitating conflict to unearth change that will make the team better. Stay in tune with the latest ideas and do your best to keep the team in the “Learning Zone”.

Grow the Agile Team

credit: universal studios

Perhaps you’re one of the rare few who, by the end of your first Agile project, recognize already that the team should be together and should not be limited to just Scrum. Perhaps you’ve already begun incorporating aspects of Lean, Kanban, DevOps, Lean Startup, Lean Enterprise, eXtreme Programming, or any number of other Agile approaches to help your team stretch and grow. You have a vision for how amazing your team can be – a unicorn among horses – and you recognize that Agility is a journey, not a destination.

The team can only become so awesome before running into major roadblocks within the organization. The team can become locally optimized, but the benefits will be limited until the entire system is optimized. After all, this is a Waterfall organization – you can run whatever methodology you like within your team, but there’s still an overall process that must be respected.

You’ll soon find that, in order to best help the team, you have to spend less time with the team and more time fixing the environment they live in. Maybe it’s the dependent teams – adjacent teams doing similar work or component teams, such as Security, Infrastructure, or Release teams. Maybe the Operations team is pushing back, trying to drive constancy at the sake of functionality. Maybe it’s the way work is approved and projects are formed that prohibit the team from responding to customer requests and market demands as quickly as they are capable. Maybe there are leaders or others in the organization that are afraid of change and, consequently, are passively or actively sabotaging the spread of Agile.

If you are successful, you will find that organizational Agility provides orders of magnitude greater than a single Agile team. You’ll find that what the team does rarely have as great an impact on their performance as the environment in which they operate.

Tell Me Why, not How

If you're familiar with the concept of User Stories then you've likely been exposed to the concept of a User Story "script". One of the most common scripts goes something like:

As a <who> I want <what> So that <why>

Looks simple enough, right? The problem is that most people who grew up in a non-Agile environment are not used to articulating the "why" in their requirements. They are used to capturing what it is that needs to built and how. Consequently, that's what usually end up making it into our stories, causing them to look like:

As a <who> I want <how> So that <what>

What's the difference? Let's look at an example.

Old Habits Die Hard

It's not uncommon to see a story that reads like, "As an administrator I want unique group IDs for tickets so that I can easily group tickets." On the surface it looks like a good user story. What's the "what"? The author would argue that it's "unique group IDs for tickets", but that's not the need. The need is to "easily group tickets". The author is trying to dictate how to meet that need in the user story. Those familiar with the INVEST model for user stories will recognize that this violates the "N" - Negotiable.

So we need to move the "what" into its place and establish a proper "why", which means we need to have a conversation. What valuable outcome is enabled by being able to group tickets together? Do you want static or dynamic grouping? Are the groups established by pre-established rules, or is the intent for users to group tickets however they like? Once we have our answers, we may end up with a better user story, something like, "As an administrator I want to easily group tickets so that I can sort and filter to easily find tickets of interest for a given task".

Why? Why?! WHY?!?

What have we gained by phrasing the story this way? A couple of things (at least). First, we have context for the story that will enable the team of professional problem-solvers to create the best solution for the problem within the bounds of the NFRs (Non-Functional Requirements) and FSRA (Future State Reference Architecture).

The second benefit is that we can better decompose the story. With the original wording, we would likely decompose the work into the layers of the system - creating a grouping cross-reference table structure first, then the business logic and virtual object code to associate tickets to groups, and finally the user interface layer for the administrator to actually use this functionality.

With the revised wording, we can leverage the advice from Agile Learning Labs at SmallerStories.com and split our story into smaller stories that are vertical slices through the entire system. This enables us to deliver value sooner and test our architecture as it's being built instead of all at the end.

Living in Reality

This is the most common anti-pattern that I've seen in the real world of user stories. What anti-patterns have you seen? What advice do you have for overcoming user story anti-patterns? Is this even really an anti-pattern?

Personal WIP

As my faithful subscribers (all both of you) may have noticed, I haven't posted anything in a while. Despite my commitment at the beginning of the year to blog at least weekly, I found myself recently with too much Personal WIP (Work In Progress). Let me catch you up on what's been going on.

New Baby!

We recently welcomed our third child into the world! His older brother and sister are both very excited, as you can see. He's been a joy, one that's kept us quite busy! He came in at 10 and a half pounds, which means that I spent more and more time helping at home to alleviate the burden on my already overburdened wife. This was a no-brainer - as my WIP increased, the priority went to my family.

Agile2014

Last week I had two firsts: I attended my first Agile Alliance conference and presented at my first Agile conference! I made sure that I had family and friends in place to assist my wife with our 2-week-old and flew to Orlando to co-present with fellow Agile Coach, Todd Kromann. We didn't use any slides, just a hand-written handout (available here), some index cards, markers, and tape. We played a game and had a great discussion. We even had the Dude himself, David Hussman, show up and commend us on our use of his Intellectual Property. We had a blast! Of course, in order for it to go as smoothly as it did, I had to spend some time before the baby came tweaking the handout and rehearsing the workshop.

Walmart Agile Summit

Prior to Agile2014, I participated in a 3-day Walmart Agile Summit in June. While I wasn't as involved as I'd have liked (again, that pesky WIP), I was on the core team and got to present a dry-run of my Dude's Law workshop. I got to meet Al Shalloway and Don Reinertsen, and I got to see Pat Reed and Rich Sheridan again. It was a fantastic experience made possible through the hard work and dedication of many people. I may not have had a lot of bandwidth, but I wanted to make sure I dedicated at least some of my WIP went to the Summit.

Walmart Agile Transformation

Of course, as the Agile Summit might have indicated, we're taking the Agile effort at Walmart quite seriously. I'm not going to disclose a lot of information or details - this isn't going to be a case study - but Todd and I were the first 2 Agile Coaches in Walmart's Bentonville office, and we wanted to make sure the Agile Transformation was done by invitation, not edict. We've had fantastic support from senior leadership, and the success of our Agile teams has accelerated the grassroots momentum that's been building. The Agile Summit served as gasoline to the proverbial fire, and interest in Agile began to rise sharply, even before the first day of the Summit. My time at work has been exciting, challenging, and incredibly rewarding. As much as I wanted to keep sharing my thoughts with the blogosphere, I owe my professional efforts first and foremost to my fellow Associates.

So that's what I've been up to. I can't promise I'll resume blogging on a weekly basis, but I am cautiously optimistic that I'll be posting more regularly that I have the past few months!