Make Agile About People Again

***The views expressed herein are my own and not necessarily representative of any official position, in whole or in part, held by my current employer or any of my former employers.***

If you live where I do, not far from Washington, DC, in the exurbs and suburbs in Northern Virginia, you've likely driven Interstate 66 (and I'd like to extend my condolences to you for being part of this dubious club). Often, I see a vehicle in the eastbound lanes with a plate that reads, "H8 Agile."

I giggle every time I see that plate. I don't know what drove purchasing that plate, and maybe it's not even the Agile I practice as a Scaled Agile Framework expert and Agile evangelist. For anyone who's unsure, I'm referring to responding quickly to changes in missions and markets with innovative, digitally-enabled products (paraphrasing Scaled Agile, Inc.).

There are a lot of people out there with good reason to hate Agile. I've seen some lousy Agile rollouts and almost all of them got the same thing wrong: they didn't make a project-to-product paradigm shift, and definitely not a project-to-people shift.?

These leaders want more share of a market or to tap into a new one, or they want to meet challenges posed by strategic competitors in all theaters. Whatever it is they need, they want it fast. They'd be crummy leaders if they weren't pushing. It's incumbent upon Scrum masters and Agile coaches to direct these leaders into a truly Agile mindset by coaching some simple, people-centric behaviors.

People must be the heart, the mind, and the guiding force behind all Agile implementations. Agilists leading Agile rollouts (Scrum, SAFe, etc.) must ensure the most senior management are leading with a vision in which people confidently see themselves. From the team level to the top of each portfolio, we must work daily with our customers and stakeholders to understand their needs and incorporate their feedback. Managers must decentralize decisions by trusting the product development teams to tap into their immense expertise and make the right choices.

Develop a Vision, Share it Often

Whether it's a CEO, a GG-15 in the federal government or in the senior executive service, or a product manager or owner, the customer has an idea of what they want. It's something brand new or an existing product or service delivery model that needs to be optimized. Coach leaders to share that vision far and wide. Where do they want to be in a year? In three years? In five?

Leaders must ensure development teams see themselves in that movie by showing them what's in it for them and their customers, and how they can take part in it. Always tell the teams WHY. WHY are we doing this work? WHY are we using this new Agile framework to get there? Scaled Agile, Inc., calls this consistent and constant messaging "reaching the tipping point," and organizational change management expert Dr. John Kotter calls it "creating a sense of urgency."

How do you make that happen? Get everyone together, virtually or in person, and share your vision. Make the efforts' most senior champions show up again and again, even if they must delegate proxies at lower levels of the organization to work with teams. Send that guiding coalition especially to events like a SAFe program increment planning session or Scrum's sprint planning sessions. Teams need to hear, "Here's the vision, again. Here's what you all delivered and how it's making a difference [and here's some great metrics to bolster that story]. Here's where we need to go now, and here's where that near-term goal fits into the larger picture. Thank you, thank you, thank you."

Leaders: Tell Teams What You Want. Teams: Show Leaders What You Built

Ensure leaders, customers, and other stakeholders come to demos to cheer on the teams for their great work. They must also use this time to show the teams what they don't like and offer feedback. That information will inform the next and future iterations and build a product the customers will want to use. You've heard Agility means speed, and that's true. Speed is an output, not an input. Teams can pivot faster on a smaller codebase if it's not what the customers want. If leaders never tell their people they're building the wrong thing when there was time to get back on course, customers will deliver that news when it's too late.

You'd be amazed how providing that north star, and showing up consistently to provide that guidance, makes a difference. With little participation or the wrong participation from senior stakeholders, Agile delivers very little. I've seen these leaders pop up only to yell and threaten, or to add more work without any conversations about how other commitments will be impacted. Worse yet, they come to different Agile events clearly checked out, tossing out lukewarm "OKs" and "yeahs" while engrossed in their laptop or iPhone. That attitude makes people want to work somewhere else.

People Were Hired for Their Expertise. Trust that Expertise.

When teams and their customers are talking with each other, you create an environment that's simultaneously employee- and customer-centric. Employees need generous wages and benefits, but they also need purpose and to believe they have some authority as well. It helps abate the 6 a.m. Monday feeling when you know not just what you need to do but to feel empowered to make it happen. Agilists must fight back against all efforts to appoint a project manager to hover over a Scrum team, with an integrated master schedule reigning supreme like a Dalek. The Scrum Guide says NOTHING about project managers. Trust the team members' expertise to decide how the customer's vision can be brought to life.?

Leaders at the top of each organization should still make decisions about where the company or agency needs to go, based on market research, focus groups, studies, conversations with parent agencies, etc. Funding decisions also likely rest in the hands of more senior people. But day-to-day product development activity must be entrusted to the experts hired to be experts.

Don't Misuse Tools

Another area where I've seen Agility efforts fall apart is descending into a rabbit hole with tools like Jira and Rally. These tools must be primarily a place to socialize the importance behind each requirement and tell the teams' success stories. Whatever tool you use, each requirement work item needs little more than a solidly-written user story, feature, epic, etc.; any other pertinent information to inform development, like wireframes; the definition of done/acceptance criteria; the requirement's size so teams can plan capacity properly; and its rank so the backlog is racked and stacked according to customer needs. Build dashboards that show leaders the great stuff teams are creating; they can socialize those dashboards to build excitement and get more resources. If you're a contractor, it may help you get more work.

The worst way to use a tool like Jira is micromanagement, enabling a distrustful environment. Insisting team members add comments about each user story at the end of each day (regardless of whether there was meaningful progress on that requirement), tracking how many hours are spent each day on each user story, and using the automatically generated Gantt chart as a flogging tool are a few of the ways these tools are abused to maintain command and control. A leader must not become a mere manager, one of eight jerks crowing to Peter Gibbons about TPS reports. If you have a government requirement or other mandate to track hours against a contract line item, keep using Deltek or Peoplesoft. Don't add another layer of administrivia.

When Agile fails, it rarely has anything to do with the team members building stuff. It usually has everything to do with leaders not communicating and not taking the reins. It's incumbent on Scrum masters, Agile coaches, and others to ensure we're holding true to people and interactions over processes and tools and having the courage to show these leaders how to drive. Let's not create more Agile haters.