Matthew talks a mile a minute. I'm sitting in a room interviewing for an IT leadership role, and he's just going on about NoSQL technologies, user experiences built on top of social networks, and getting the perfect office environment to practice agile. What's more, our interview includes a couple of agile coaches, and I can't tell if he's been working with them for a while or if they're also interviewing for roles. The coaches keep steering the conversation toward scrum best practices, democratizing the development process, empowering engineers, and achieving a zen of collaboration.

What's clear is that they're sizing me up based on my reactions. So be it. I can play this game, and they're putting me through all the common agile team problem scenarios.

“How do you handle a team with a developer that's not finishing their stories?”

“What's the best way to handle product owners who ask the team to overcommit?”

“What should the team do to improve their velocity?”

To nail this interview, I have to strike a balance between listening and sharing my approaches without overwhelming them with expertise that may come across as arrogance. Plus, these guys sound like they have their shit together, although, almost to a fault. It's as if they plan to develop an agile religion inside the company.

I've run agile teams without coaches and without all this jargon around culture, mindset, or striving for happy teams. Until then, as a startup CTO, agile was a means to get to an end. It was a way to guide development teams that were never told the complete requirements, and if they were, the business requirements documents were too long for anyone to digest. And the requirements changed all the time anyway. Can you imagine scanning version seven of a twenty‐page requirements document before Microsoft Word had the track‐changes feature? Plus, we had to deploy features to users just to see what worked.

We were naturally aiming for lean software development lifecycles and low overhead so we could push features frequently. We had plenty of automation in UNIX scripts and open source sysadmin apps, but they were kludged together without standard ways of orchestrating end‐to‐end processes. Back then, we met daily, but we didn't call those meetings stand‐ups. We raised the issues that might prevent us from completing a feature on schedule but didn't have scrum masters or formal agile tools to record these issues as blocks. We constantly talked about improving our processes, our code, and our ways of working with our business leaders, but we didn't call it a retrospective meeting. It was, well, just an obvious way to get work done.

I pass the interview, and one month later, I start my new role as the vice president of technology for this business.

It's only then that I realize how freaking clueless I was about agile.

My teams and experience to that point had all been with startups and relatively small development organizations. When the IT team was big, it was because we had gotten that way through acquiring new businesses and had teams working on independent applications in different locations. In other words, I had only worked with a whole bunch of small agile teams that didn't need to collaborate, share best practices, or engineer their way through dependencies.

In my previous roles, our employees and contractors simply had to learn our development process. There wasn't a legacy waterfall mindset for anyone to latch onto as a sacred institutional cow. Yes, there was significant technical debt, but we didn't have to worry about integrating with legacy enterprise systems. Our applications were in data centers, but we managed them and convinced our system administrators to make changes and deployments when required. We tested because it was the right thing to do to ensure quality, not because there was a brand at risk or a compliance issue if we deployed shitty code.

I'm one month into this new job at an eighty‐year‐old enterprise, and the leaders want to develop their own proprietary customer‐facing web applications. I think it's crazy that they want to operate like a software startup, and I tell them as much, but they insist they need to develop an innovative way of interfacing with customers. It's before “digital transformation” is a popular buzzword, and most companies think of technology as a build‐versus‐buy decision. And back then, most large enterprises were buying technology—not building personalized customer experiences or overly tailoring workflows—because it was expensive and difficult to plan, develop, and maintain custom code.

How did I get here? Why did I pivot from startup glory and secluded environments to a messy, political, and sometimes backward enterprise role?

Bringing Agile Startup Cultures to a Large Enterprise

I loved startup life. Every day brought new challenges, and it required all of us to wear many hats and evolve our ways of working. One day I am sitting behind a screen debugging code, and the next day I am meeting customers and potential business partners. I even met the younger Elon Musk when he was at Zip2 and seeking partnerships with other media startups. I reached my fix at growing startups with mostly so‐so wins. Financially, I did fine and had some exits, but I never achieved sit‐on‐the‐beach, cash‐in‐and‐done success.

I often think about one of my favorite opening movie scenes in Rounders, where Matt Damon's character is driving a truck, making deliveries to convenience stores. He opens the movie saying, “You don't hear much about guys who take their shot and miss, but I'll tell you what happens to 'em. They end up humping crappy jobs on graveyard shifts, trying to figure out how they came up short.”

This isn't me exactly. I definitely feel as though I've taken my shot, and this isn't a crappy job by any stretch of the imagination. But it is a job with new rules and ways of getting things done that are foreign to me. They hire me to bring a startup technology capability to this enterprise that, somewhere in their executive wisdom, decides it needs technology and data to be a core competency. They want me to get them there. Here's what I'm walking into.

Matthew leads a small group on this new customer‐facing web application, a cross between a curated content management system and a social network. It's July, and they're starting to prototype the technology architecture, user experiences, and data sources that will play important roles in the product's architecture. The team they've appointed to work on this app includes a few contract developers from one company helping with the development and a second consulting group coaching the team on agile and scrum. They are also working with several employees from the department, though not enough, and I plan to bring more onto this team so that they learn agile and the new technologies.

This small team is collocated in one corner of our office space. To foster collaboration, they proactively open up the enclosed area by removing the cubicle dividers, a feat that gets me a visit from the head of facilities for several infractions. The team's fishing around for agile tools, but they're using note cards and boards for now. We don't have a product owner yet, so Matthew is wearing a few hats, playing a part‐time innovator, agile coach, technical lead, architect, product owner, and technical recruiter.

It takes me time to understand Matthew's vision fully, but to this day, he is one of the smartest and most innovative people I've known.

The good news I see in my first month is this team is highly motivated and is proactively finding ways to identify talent, hire experts, prototype technologies, and kick off agile practices. The bad news is that I also see their upcoming institutional impediments, and it's going to be on me to bulldoze through them.

It's a job I'm not sure I know or understand. Actually, I'm freaking clueless about how to get things done in an enterprise. At startups, I was the one creating the standards and formal practices; here, they thrust them on me with little explanation as to why they exist, what's required, and when.

And sure, we had our share of politics and organizational dysfunctions in my startups. Which board member came up with the brilliant idea of keeping two CEOs as co‐CEOs after a merger “of equals”? Who thought it was smart to run television commercials weeks after launching a website on new technology platforms? What venture capitalist believed it was wise to participate in an angel round and then demand monthly financial updates from the founders?

In the end, these were all just bad decisions that I either worked around or bulldozed if I had enough will and muscle to take them on.

Here and now in an enterprise, the impediments I'm seeing are indoctrinated behaviors and corporate guidelines. I'm here to guide this agile development team to be fast and nimble, but with no formalities and planning practices, which I will guide them on. But these agile ways of working and startup mindsets are on a collision course with the enterprise's rigid business processes, slow decision‐making functions, highly formalized financial management rules, and strict technology standards. These aren't archaic, bureaucratic, or politically driven practices, but they are too slow and structured at a time when the business I work for requires faster decision‐making and execution. I have no experience successfully melding a startup mindset with these enterprise standards, and I don't want to be labeled a maverick by working around them.

The primary issue is timing. The business leaders tell me that the funding approved for this project is just for a small pilot. We must make a business case for the entire investment.

Well, what goes into making this business case, I think to myself? I find myself navigating through layers of corporate technology functions and meeting their leaders to figure it out. Because I don't have time to read through reams of outdated documentation buried in a half dozen SharePoint sites, let alone the other requirements no one bothered to document.

Here's what I learn. You must present in front of two committees: one to get approval on the architecture and a second to review the business model, project plan, and financial returns. These committees meet monthly, and there's a series of ceremonies to complete even before getting on their agendas.

Okay, so I must come up with a bunch of convincing PowerPoints. How hard can that be? I can do that.

The more difficult issue is timing. The business leaders want a working prototype by the end of the year. The deadline is strategic because it's the best way to start building momentum within the business behind the program and to ensure funding will continue into the next year.

I start running a schedule in my head. I don't know when the executive committee finalizes budgets, but I estimate no later than November. I guess it will take at least four months to build a functioning prototype, which means we must be hardcore coding by no later than August. But it's already July, so the earliest we can get through all these committees is also in August. And that means we must develop all the materials, get on their agendas, and pass their investment criteria, otherwise we won't have signoff on the funding for the people and technology we need.

We have nothing to show at these meetings. There's no project plan, no financials, no architecture, and barely a team. But what we do have is a small group practicing agile, so I have little doubt they'll be able to build the prototype in time. What troubles me is wondering how we'll complete all these materials and estimate a multi‐month plan before the first committee meeting.

It's then that I also realize we don't have a technology architecture defined. All we have is a bunch of half‐developed diagrams and several technology vendor proposals that haven't been thoroughly reviewed. While the developers have some new technologies installed on their desktops so they can code, none of it is installed in the data center yet. From what I understand, that alone is a process that often takes months, and we can't even make that request until we get through all these committees. And these committees want to see a fully baked plan showing how we'll take the upfront investment and turn it into profit, specifically a profit with a defined internal rate of return that exceeds corporate guidelines.

Holy crap, this really is an agile bus that's picking up speed and about to collide into a slow‐moving enterprise freight train.

I go with my gut. No, we aren't going to sidestep these procedures even though my leadership team suggests it. I challenge the status quo by presenting an agile program, and it isn't anything like these committees have seen before. I share an architecture that's only a development environment and one that we plan to experiment and iterate on and improve. Because that's all we have right now, and we don't have a test, prod, and disaster recovery environment proposed even though it's required. We need to use the prototype period to iterate on the architecture. Imagine that?

No, I'm not presenting a Gantt chart with a fixed timeline and deliverable. We're starting with two‐week sprints, and we'll have a working prototype with a handful of essential functions that make up an MVP. The financials show an investment without any returns. Our key performance indicators are designed to prove the architecture, demonstrate we can succeed with agile in an enterprise, and deliver a working prototype business leaders deem a successful MVP.

I concede that once we achieve these goals, we'll come back to the committees with an update and forward‐looking plan. It's a concession I loathe because it means I'll have to prepare and go through this charade again, but there isn't a way around it.

I'm on vacation the week the final committee is meeting and elect to fly back for the day to deliver the presentation. I just can't see them greenlighting a controversial project with a new vice president presenting remotely.

I walk in with my colleagues, including Jerry, the head of the digital strategy, and Josh, our controller. Having the controller there is a requirement but bringing the business leader is my idea. Committee members are sitting around a U‐shaped table in an enormous conference room on one of the top floors in this iconic New York City skyscraper. There isn't Zoom, and the conference room doesn't even have screens in it—just a single speakerphone in the center. I'm damn happy I went with my gut and decided to fly in for this meeting.

This presentation is ten slides. We're on slide three when the door opens, and an older gentleman wearing a blue suit walks in. He sits in a row of chairs on the left side behind the committee members. I don't know him. For that matter, I don't know most of the people in the room, but I can tell they all take notice of him coming into the meeting.

Despite the bureaucracy and archaic process, it's efficient, and the presentation must be completed in twenty minutes so that they can tackle several of these in each session.

We finish delivering the presentation, and I look around the room. I see the corporate CIO and the head of enterprise architecture looking at each other and sharing a couple of nods. The corporate controller flips through the pages in front of her and looks up like she's about to say something, but her eyes veer toward the man in the blue suit, and she backs down. There are no questions, no comments, and no reactions. They thank us for the presentation, we exit the room, and I think to myself, “Wait, what the hell just happened?”

Later that day, I hear the committee accepted our proposal with a few inconsequential follow‐ups. I also learn that the man in the blue suit was the president of our segment, an executive‐level position reporting to the CEO who oversees several information and media businesses. He's a well‐respected right‐hand lieutenant to the CEO, and it's entirely out of the ordinary for him or anyone at that executive level to show up at one of these committee meetings.

It always helps to have a rabbi in your corner.

Not One Agile: Adapting an Agile Way of Working

And now we must pull it off. Develop a large‐scale customer‐facing application on new technology with a scrum process. I'm back on home ice—a hockey phrase—with obstacles and challenges that all seem surmountable. We have a smart, collocated team, working well together and finding their way through blocks. We aren't far enough along for the detractors to emerge, but I know they'll come. But today, I feel good about where this program stands and what we need to do to succeed.

I return from lunch and walk the hall toward my office, past a conference room with a door slightly open, and hear someone say it.

“That's not agile.”

Today is the first time I hear this phrase, but it comes up over and over again throughout my career as a CIO. These days, it often comes up when I lead workshops and agile center of excellence programs as StarCIO's CEO. It's tiring, but it's also something I must address when someone raises it.

Sometimes the person is really saying, “No way I'm doing that.” Other times, it's a chest‐beating, “I know agile, and I want to control the agile way of working around here.” Sometimes, there's a less forward meaning like, “I'm a certified scrum master and have certification …,” which can be a polite way of saying that they never learned what I'm sharing at one of their training sessions.

I'm instantly frustrated because I know I may have a heckler to deal with inside the group. Or maybe it's someone who needs help understanding the differences between agile ceremonies and agile ways of working. Then my initial anger subsides, and the cool, experienced Isaac takes over and realizes that he must slow down.

After getting through our approvals, we go straight back to work on developing the application but also on formalizing our agile way of working. By then, we have a small team of developers cranking out code and have a tool to track the user story backlog. We also hire a product manager to assume the product owner role, and we're trying to get him off old‐school thinking around writing long‐form requirement documents.

It's early days in our development process when I am walking down the halls and hear that first “that's not agile.” I peek into the room to see who uttered those words, and they came from one of the agile coaches working with Matthew and the team.

The phrase irks me, but I decide to let it go and let the team work it out. I turn the corner to head toward my office when I hear the product owner raising his voice and sounding frustrated. His exact words are, “You guys can go do your agile thing and convert my requirements documents to user stories.”

And now, I feel compelled to inject myself into how Matthew, the coach, and the team want to run agile. The team's success depends on introducing some of my experiences into the discussion, and I want them to look beyond some of the idealized agile principles. We are still operating in a large enterprise that has some reasonable requirements. Plus, I know I need to have strong collaboration and partnership between the business and the development team to establish an agile culture. That means the team must make some adjustments to the out‐of‐the‐box scrum.

I invite myself into the meeting, which isn't out of the ordinary, at least for our agile meetings, because we institute an open‐door policy for brainstorming sessions like this one as well as our sprint reviews.

Brainstorming sessions are for problem‐solving. We schedule two of them weekly, and there's often a battle on what's on the agenda. Sometimes it can be an implementation issue, like figuring out how to modify a schema to support a new business requirement. Other times, they are strategic, and we whiteboard different user experiences, realign people on agile teams, or break down complex requirements. Brainstorming sessions have a format for running them, and there's a requirement to invite a small and diverse group to participate in them.

When I walk into this brainstorming session, I can see that estimating and planning the next sprints of user stories is on the agenda. Our product owner, technical lead, agile coaches, and Matthew are in attendance. I listen to the debate for a while, and I hear the plight in the product owner's voice. He's happy to know what the team commits to at the start of the sprint but has no idea what comes afterward. He prioritizes the next features on the backlog, but they're not broken down by the team or estimated. He wants some visibility so that he can manage stakeholder expectations.

But the coach responds again, “That's not agile,” and wants the team to have more flexibility at the start of every sprint. The technical lead is concerned about the added time required to break down and estimate more features. Matthew seeks a compromise, where the team analyzes one feature for the product owner, but not more. I think he sides with the agile coaches but wants to resolve the conflict and figures a token analysis isn't going to take the agile team off course.

I wait until I hear everyone's opinion before chiming in. We're in a brainstorming session, which means they start with problem statements, require a presentation of data and facts, provide time for everyone's opinions, lead to collaborative debate, and end with decisions. Now that I've stepped in, they expect me to contribute, and the team knows that I'm not shy about providing an answer.

How far to plan agile backlogs is a crucial decision for agile teams. I sense it at the time, and resolving it becomes a seed I nurture for the next decade working with other organizations adopting agile methodologies.

But today, after acknowledging everyone's opinions and thanking them for open dialog, I get straight to the point with how we need to move forward. Here's what I tell Matthew, the coaches, and the agile development team:

“I need everyone to think about planning their backlog beyond the next sprint. The business teams need some visibility over what may come after we finish the current sprint and what work we're planning for the next ones. Yes, I know that there are no guarantees, and we are likely to adjust priorities and requirements based on customer feedback, but there's a dialog we need to have with stakeholders before we can write the next set of stories.

“In this sprint, we must schedule these conversations about work that may not be developed for another couple of sprints. We're going to need to review and discuss what we're planning and get your understanding of how the features we're considering break down with some early estimates.”

I think the coach almost fell out of his chair. It was then he said one last time, “That's not agile.”

Now estimating was not a revolutionary request. James Grenning introduced planning poker back in 2002,¹ and Mike Cohn published his book on agile estimation² and planning in 2005. Truth be told, I didn't know about the book or planning poker and was just following my instincts, so I explain both what and why we needed to expand our notion of planning beyond the next sprint.

The coach explains his objection to agile estimation and planning multi‐sprint backlogs. “Agile is about giving the product owner the ability to prioritize every sprint and learn from feedback when the team demos at the sprint review. Why should we plan sprints ahead if we reprioritize the work anyway? And why would we estimate when the product owner should prioritize on business value and impact to end users?”

These are good questions, and I have spent the better part of my career answering them for many teams. The programs I offer at StarCIO help organizations adopt planning and estimation practices that I've been using at different companies for well over a decade.

My favorite objections come from groups that have tried to adopt the Scaled Agile Framework (SAFe)³ but struggled or failed. SAFe, a system for implementing agile practices at scale, is a rigorous process for establishing scrum standards across a large development organization. By large, I mean thousands of people, although I'm sure that SAFe practitioners suggest that it works in smaller organizations. I'm sure it can, but at what cost to implement all the framework's rigor?

SAFe advocates a process called Program Increment (PI)⁴ planning where organizations break for a sprint, called the Innovation and Planning Iteration,⁵ to do an increment of planning, which is typically between eight and twelve weeks⁶ in duration. This practice often includes gathering for a few days so that teams coordinate their plans and resolve dependencies.

Now that doesn't sound very agile to me. Trying to gather the best minds to flesh out all the nuances in a plan and then go back to their offices over the next several months to execute on it? That sounds, well, very waterfall to me.

I explain to the coach, as I've done many times since then, “Agile teams must be continuously planning. Every sprint, you deliver an improvement to the product, and you should also be updating the plan. To do this with an organization full of stakeholders requires the product owner and technical lead to plan several sprints ahead of the team's work. The team must partner with the product owner by helping them understand different solutions, break down features into stories, and provide estimates. These estimates help product owners better decide what to prioritize and when to reduce scope, especially when their requirements drive technical complexities.

“Only the estimating process must be efficient, and the product owner needs to understand how to use this information. I can't have product owners haggling over story points even though I know that will happen. The point is to get the right engagement with customers, end users, and stakeholders so that we work on the right things.”

I take a slug of coffee and continue.

“Now, in a startup, maybe all the development and planning can happen within the two‐week sprint. They're working on new technology with very talented engineers. They can process feedback quickly because they only have a few customers using their products in the early days. They don't have legacy technology and likely have minimal technical debt to work around. They're going to figure out how to operationalize their product later. Some may underinvest in compliance, security, and supportability of their application. That may fit their risk profile, but it doesn't work for organizations with customers, brand reputations, and applications with high usage from day one.

“In this world, we'll need more time to plan to bring in the right mix of designers, engineers, architects, information security, and other experts who might weigh in on the acceptance criteria of a user story or recommend aspects of its implementation. We'll also want stakeholders to see the designs, experiences, and workflows. The last thing we want is to start coding on something only to find out that key users of the system have diverse, better, or alternative ideas that the team never heard or considered.”

To this day, I give variants of this monologue during workshops and keynotes. Agile's Manifesto⁷ provides starting principles and practices for teams to adopt. It's a loose set of guidelines that companies need to define and improve as part of their agile cultures, their agile ways of working, and what it means to have an agile mindset.

Sometimes self‐organizing teams need me to come in as the heavy enforcer. They want to self‐organize on a practice required by their team, only there may be contention around the methodologies, with their bosses, or with the team's product managers. Suppose the team starts hearing, “That's not agile,” but is trying to implement a process that makes sense for their circumstances. In that case, that's where Digital Trailblazers must step in and facilitate an agile way of working discussion.

Prioritizing Technical Debt—Because They Are Business Issues

Many years later, one of my teams is working with a product owner who slams feature after feature down their throats. They're in a race to gain adoption of a new product, and the product owner is trying to get more salespeople to push his product. He is in that Catch‐22 where the salespeople are pushing back: “If I don't have this widget, then I can't sell the product.” Eventually, the company CEO steps in and calls bullshit on this behavior. When it reaches the level where it's an excuse for poor sales performance, then you must call in the really big guns.

But until then, my team escalates a problem to me that this drive for features is creating. This team is accumulating technical debt like teenagers who are maxing out their credit cards. The product is developed on new technology and went from prototype to proof of concept to pilot and then beta in record time. Since then, they've been adding and changing things to meet product needs. Only the work is getting harder, slower, and more error prone.

I get into the weeds to better understand the issue. As a leader, you must do this, especially when you're about to define a standard way of working. People will ask why and push back. Others will escalate their concerns to their sponsors, and you'll have to defend your decisions.

I assess the code, the testing, and the deployment processes the team is currently using. I also review the features the product owner is prioritizing. When I go to discuss my thinking with him, I listen first. Why did he prioritize the features? Who's the customer or persona they're targeting? What problem or opportunity does this capability address?

It's unfair because he doesn't know what I'm after, and I'm trying to determine whether I buy into his priorities. Sell me that the features you need are customer needs and business priorities. Convince me that you listen to the team's recommendations on the implementation, including sequencing the work, addressing defects, implementing reliability improvements, and reducing technical debt.

I then ask questions to see if he understands some of the technical issues. The good news is he does. The problem is, he just doesn't care enough and believes the team should work these technical issues out on their own as they work through his priorities.

And that's where the red flag goes up. I don't say it, but that's clearly not agile. He could have debated the importance or priority with me, but instead, he suggests the team should work on technical issues in addition and separate from his priorities. And quite frankly, I don't buy into his plan.

I decide this team should dedicate 30 percent of their commitments to address technical debt. I rationalize the number based on how software companies, before the days of SaaS when they charged license and support fees, invoiced 20 percent of the license as a yearly maintenance fee. If software companies need 20 percent for support and maintenance, then surely, we as a non‐tech company can't be as efficient, so I asked for 30 percent.

Months later, I write the blog post, how to get the product owner to pay for technical debt.⁸ It's a signature piece and a foundation of the agile programs I guide organizations on today.

Why Agile? It Connects Transformation Strategy to Execution

This also isn't the only time I confront product owners who don't share enough information with their team. Teams need to understand why a priority is important to customers. What is the value that's being addressed? What's the pain point? What are the alternatives end users are taking to work around the issue? Most importantly, teams must understand and believe why the product owner prioritizes a particular feature over the others.

Agile requires trust and shared understanding. I expect the product owner shares this information with the team. It's more than an expectation; it's a requirement for success.

It's also not easy, and it is time‐consuming.

I truly believe product managers and owners have the hardest job in rolling out applications that delight customers and transform the organization. They experience huge demands on their time to talk to customers, stakeholders, and industry experts. To understand how the product is performing, they must consider market research, expert feedback, and many different reports from different systems. They must articulate the strategy and ensure they translate to precise business requirements—the who, what, and why—without overly defining the how, which should largely be left to the team to explain and defend.

By the time some product owners are ready to engage the development team on a product, a release, or a feature, they may be burned out from the time‐consuming top‐down communications. Some product owners feel the time pressure to start the development process, and some are lazy. Others don't see the value in sharing the depth of information with their development teams. They'll say, “They have their stories, they have the acceptance criteria, and I prioritized the backlog. What else do they need?”

When this happens, I'm the one who's saying, “That's not agile,” but again, to myself, because the team must learn key agile principles, especially around knowledge sharing. The product manager or owner is missing how important it is to share context, rationale, and data with their teams. Trust is built by bringing agile teams on the journey and allowing them to ask questions and gather their input. This dialog needs to happen well before product managers firm up requirements—it should be a collaborative process with the agile team technical and quality leads.

In instances when I don't see the dialog, information sharing, and collaboration happening, I'm left no choice but to specify the operating principles and best practices. Much the same way, I want the IT operations team to share data on how a product is performing in production. I also want product management to share data on how the product is working with customers. I don't want this rehearsed, and I ask these leaders to open tools or build dashboards that share the underlying data—no slides and no spreadsheets. By showing teammates how to access the underlying data, eventually, they will self‐service answers to their own questions.

Here's how I explain the operating principle to agile teams: “Let's pull up from our preconceived notions of a feature as only an end user capability. If what I am delivering can be expressed as a customer and business benefit, then it's a feature. It means features can include operational business needs, quality improvements, and compliance requirements. Security, performance, or reliability needs that improve customer experiences or reduce risks are features. Anyone can propose features to the product owner but should express them from a customer need, articulate a business value, and where possible, bring data to back up the proposal. Then, I expect the product owner to lead the discussion and finalize a balanced feature prioritization, accounting for growth, competitiveness, end user experiences, risks, costs, and other factors.”

By taking this approach with the data, I'm empowering product managers to partner with appropriate stakeholders and share the most relevant information. The operating principle is that before you prioritize features—everything from product features and operational business needs to security needs and compliance issues—key partners should be able to see relevant data to understand the customer benefit and business value. That's not to say that the data will be conclusive or perfect in articulating their story. The operating principle forces the story to get told, and whatever data are available to be shared. Now that's agile.

Here's the thing. No one ever fully understands the first time I explain these concepts. You can conceptually understand agile concepts in a class or workshop, but it's not until you step into the process and adopt specific roles that you feel the experience. That's when teams truly begin to understand agile, and that's when many become evangelists. I explain the why behind the practice and basic details but share many of the mechanics during the implementation. I answer as many questions as I can and try to find who's willing to trust me. I start with them and sometimes leave others behind. They'll catch up.

Here are key leadership lessons to take away from this chapter:

1. Drive transformation by emphasizing the why and coach on the how and what. While this lesson should apply to almost everything you do to move your business, organization, and team forward, it's critically important to drive agile practices and culture. So much of agile focuses on the ritual and tools of implementing scrum or Kanban, and even my programs from StarCIO emphasize process rigor. But people only adopt what you are trying to accomplish when they fully understand and embrace the why. To bring everyone along, they must understand from the beginning why it's important for the organization, why their participation is vital, and why you're prioritizing agile methodologies. Bringing the why to life takes effort and responsibility, especially when your teammates suggest alternative ways to accomplish your goals with an approach different from what you are trying to convince them to do. It will likely require repeatedly emphasizing why before everyone truly understands. That's why it's so important to have lieutenants who echo the message. Even more critical is that you eat your own dogfood. No one will buy into why a change is important if they don't see you embracing what you ask them to do.

   I also suggest coaching people and teams on process and culture transformation. Coaching specifically means repeating the message (i.e., the why and what) with multiple people, done in the context of the work they're doing. That's the best way to get meaningful adoption.

2. Align with your organization's principles and requirements before changing the culture. If you're working in a startup, you likely have a relatively clean slate on establishing your organization's culture and practices. Your greatest challenge is hiring people who embrace your values and have diverse thinking and experiences. You want them to challenge your thinking with new ideas but also embrace your organization's core principles.

   That's a lot harder in non‐startup organizations with established norms, cultural principles, and required practices. If you try bulldozing agile principles, practices, and culture into your organization without stating it from the existing context, you'll be labeled a maverick. You may achieve success in pockets that are willing to work outside of the organization's requirements, but you'll never get the support and backing to scale it. Institute agile practices in waves of participation because you'll lose new entrants if you break principles and rules too early.

3. Develop a shared understanding of product owner, stakeholder, and agile team responsibilities. In agile, there should be a healthy tension between the product owner and the team. Empower agile teams to commit to the work they accept for a sprint, and the product owner must trust that the team works to their full capacity. But that doesn't stop many product owners from asking and often demanding that more get done. They'll challenge estimates, push the team to increase velocity, and add to scope because their goals and responsibilities often demand it. In response, some agile teams will inflate their estimates, commit to less, or use other slowdown tactics. Some agile teams will also demonize product managers and owners, especially if the product teams report to a different organizational leader. It might help agile teams bond when they find a common scapegoat to blame for their stress, but it doesn't alleviate the underlying problem.

   Digital Trailblazers teach teammate empathy. It's time‐consuming to get product owners to understand the technical steps to build quality deliverables. It's equally challenging to get agile teams to see all the business pressures and stakeholder demands the product owners face every time they say “no” or “later” to a legitimate business need. When these tensions escalate to agile leaders, drive empathy by helping everyone sit in each other's shoes.

4. Show me the data before selling me your ideas. I start all of my keynotes with a mix of data, charts, and data‐driven insights. I select legitimate sources and hope these facts bring a data‐driven context to my audience before sharing any big ideas. I do this at board meetings and workshops as well, and it's the first principle I emphasize with stakeholders trying to influence the priority and substance of an agile backlog. This data‐driven approach, or operating principle, can infuriate some people because it adds work and discipline to their demands. My answer to this objection is, “Exactly.”

   If you have a great idea for a feature, identify data that can help give you insights on whether customers will seek this capability from your product. If you must address technical debt before working on that feature, show some data illustrating why this is a critical undertaking. You don't need comprehensive data that demonstrates causality. Rather, you're seeking evidence to set the context of the request and help discern its priority versus other business needs. In other words, if you don't have any data to back up your story, it's nothing more than an invalidated idea.

5. Reduce technical debt by making it everyone's responsibility. If we all agree that innovation, customer experience, and operational efficiencies are primary business objectives, then technical debt is the friction that slows down and can even halt our ability to plan, deliver, and experiment. In fact, it's not just technical debt that can inhibit progress. Most organizations also have built up debt in operations, data, compliance, security, and other areas. The problem is bigger than fixing these issues or getting priority, budget, and skills to make adequate investments to reduce debt. No. The bigger problem facing organizations is when there isn't holistic responsibility taken for the underlying product and operation. Believe me, I don't like to have to resort to edicts, and it's very hard to sell the why behind them or create empathy for those impacted. But I can analyze and share the data when backlogs are tracked by the type of prioritized work. I'll use that as the basis of my operating principle when teams underinvest in addressing debt. When that happens, they often fall victim when they can afford it the least, and the debt progresses into legacy systems or recurring operational incidents.

▪  ▪  ▪

If you would like more specifics on these lessons learned and best practices, please visit https://www.starcio.com/digital-trailblazer/chapter-5.