LeadingAgile

Predictability and Adaptability Live in Tension

Wed, 14 Oct 2020 09:00:52 GMT

During Agile Transformation, stakeholders often get frustrated with the lack of long-term planning. There’s a tension between the ability to make commitments, and the ability to pivot easily.

Most executives want the best of both, but there must be trade-offs to achieve the level of predictability and adaptability each organization is going for.

CapEx and Agile Transformation w/ Justin Polk

Thu, 08 Oct 2020 10:08:11 GMT

This week in LeadingAgile’s SoundNotes, Justin Polk is here to discuss the role that capitalization plays in helping an organization adopt an Agile approach to work. When the conversation turns to Agile Transformation, it often focuses on what changes you need to introduce, where, and when. But sometimes we get so caught up in those conversations that we neglect to include one very important aspect… the money and how it is tracked. In this episode of the podcast, you’ll learn what CapEx (Capital Expenditure) is, why it matters, and why it is a fundamental concern in Agile Transformation.

Contacting Justin Polk

LeadingAgile: https://www.leadingagile.com/guides/justin-polk/
LinkedIn: https://www.linkedin.com/in/justin-polk/
Email: justin.polk@leadingagile.com

Contacting Dave Prior

If you’d like to contact Dave you can reach him at:

LeadingAgile: https://www.leadingagile.com/guides/dave-prior/
LinkedIn: https://www.linkedin.com/in/mrsungo
Twitter: https://twitter.com/mrsungo
Email: dave.prior@leadingagile.com

If you have a question you’d like to submit for an upcoming podcast, please send them to dave.prior@leadingagile.com

And if you’re interested in taking one of our upcoming Certified ScrumMaster or Certified Scrum Product Owner classes, you can find all the details at https://www.leadingagile.com/our-gear/training/

Increasing Enterprise-Level Predictability With Agile

Mon, 21 Sep 2020 12:27:33 GMT

We typically think of Agility as being nearly synonymous with adaptability, and that a change in mindset or culture to become more adaptable is the right place to begin Agile Transformation. But the truth is that one of the most common goals organizations have for Transformation is actually predictability. Why? Because it brings the organization the business results and outcomes executives want to see to make the business grow and succeed.

Yet while executives ask for predictable results and outcomes, Agilists tend to think you can’t get predictable while being Agile. But you can. And also, you should if you want to pursue organizational Agility.

Predictability is ultimately about figuring out how to make and meet commitments and do what you say you’re going to do so that the organization becomes a reliable trustworthy partner of the executives. And once you build the trust that predictability brings, it becomes far easier to prove the worth of Agile Transformation—and get more executive support for continued Transformation.

While predictability always begins at the team level, enterprise-level predictability comes with an entirely different class of problems to overcome and therefore requires an entirely different strategy to be achieved.

How Much Predictability Do We Need?

Different organizations have different needs for predictability. While some will need the most possible, others won’t need any at all. If you’re an organization that needs predictability 3-6 months out, or a year or more roadmap, this blog, and it’s accompanying position paper where we dive deeper into all of these topics, is for you.

The 3 Things You Need for Team-Level Predictability

Complete, Cross-Functional Teams

Making and meeting commitments to become predictable begins at the team level with complete, cross-functional teams. A complete cross-functional team is a group of six to eight people, give or take a few, who have everyone and everything necessary to be able to deliver a working, tested product or increment of software as described by the backlog.

Backlogs

The complete cross-functional teams need to work against a known backlog, a stack ranked list of things the teams are going to build, including user stories.

Getting to a Working, Tested Product

Once the team understands the size of the backlog and has a stable velocity, then the team can figure out how many sprints it will take to get through the backlog, or how much backlog they can do in a predetermined number of sprints. With all of these factors in place, they can then reliably make and meet commitments to produce a working, tested product.

Obstacles to Predictability

Dependencies

The reality is, not everyone starts out with a team that has everyone and everything necessary for it to deliver a working tested increment of product or software as described by the backlog. But without this, you will immediately have dependencies on your hands. If you have to depend on another team or outside resources to be able to deliver, you’re not going to be able to be predictable. Dependencies are the number one killer of Agility.

To overcome dependencies, you have to create the conditions you need in order to be predictable.

Backlog Problems

On some very typical Agile teams, the product is built and supported and the build side is predictable. Maybe user stories, estimation, release planning, and stabilizing velocity all work great. You’re mixing a determinate backlog with an indeterminate backlog, and some of the backlog is interrupt-driven.

Anytime you mix a determinate backlog with an indeterminate backlog, you’re going to have to deploy buffering strategies between the two, and while that’s possible, it can be complicated.

Predictability at Scale

The 3 Things at Scale: Structure, Governance, and Metrics

Even though this all boils down to the same 3 Things concepts from the team-level; teams, backlogs, and working tested software— as we start to scale, there are slightly different classes of problems and obstacles to predictability, so the focus of each shifts slightly.

Structure

Instead of focusing specifically on teams, at scale we must focus on the structure of the teams we have, and the way multiple teams relate to one another.

Governance

Instead of backlogs, at scale we focus on governance: the flow of work across the organization which supports our ability to accomplish business goals over time.

Metrics

While we produce working tested increments of software, at scale we add a focus on measuring value across multiple teams using metrics.

Team Level Agility is Insufficient for Enterprise Level Agility

Most organizations are projectized, and approve dollars for projects, and then deploy people into projects and form teams made by slicing people and teams into little bits to make them fit into the project metaphor to execute on a project. Those teams end up having a lot of dependencies. And dependencies kill Agility.

What if instead, we broke the project into pieces to be able to send those components to the right team to do the parts they are best suited for? Typically, we then end up with teams that have way too much on their plate, and teams that have very little to do and are starved.

This is a tricky situation because it’s not a problem of prioritization, or dependency management, or even a making- and- meeting- commitments problem. It is that you will simply never get high enough in the queue to get the attention of the constrained teams that are producing all the work that has the highest business value.

This is why we have to go back and create balance at the Portfolio level. To be predictable across the enterprise, what you need is an ability to look at the portfolio of work that’s coming in organizationally and make some guesses and assumptions and establish constraints that assert that the organization, based on the predictable, reliable delivery and performance capacity of individual Scrum teams, can start making bets about what the organization is capable of delivering.

Closing Thoughts

A predictable Agile enterprise demands predictable teams or else nothing else works.

You can be predictable and perfect at the team level and the organization can see no predictability and value at the enterprise level because you didn’t create structures to make sure the system is being fed in a way that funnels through properly.

Predictability is important and builds trust, both within the organization and for executives. Executives want it and they’re willing to pay for it. And once you show them how Agile is solving the problems they want to solve, like predictability, and the things you need to do to get it, you can make a strong case for Transformation.

Leveraging Agile to Improve Quality

Thu, 17 Sep 2020 14:18:24 GMT

In a fixed-time, fixed-cost, fixed-scope environment, time and cost estimates are often wrong and the pressure to deliver and get things into market faster intensifies. When this happens, the delivery teams need an outlet and quality is usually the first thing to go because, in a world of fixed constraints, it’s the one thing that the delivery teams can control.

Quality is the lever that gets pulled when your organization is operating in an unsustainable way.

Many a company has hypothesized that Agile methodologies would help them solve their quality issues. They thought that if they could just improve team-level communication or get better alignment across multiple delivery teams that they would begin to see improvements.

Many a company have also quickly realized that Scrum and SAFe turned out to be insufficient. No amount of daily standup meetings or big room planning was going to solve their quality issues, so they assumed that either they did something wrong—or that Agile doesn’t work at all.

Paving the Way for Quality with Agile

The problem is that, at scale, in multi-team, dependency-riddled organizations the performance of the individual teams is almost irrelevant—which is why when Agile methodologies are relegated to a team-level activity, it almost never works.

It’s not until we leverage larger, vertical slices of the organization and begin integrating the work the teams are doing with an upward intentionality that we begin to see real improvement in quality.

But this takes a certain set of conditions. It takes 3 Things:

Teams
Backlogs
Working Tested Product

Basically you need to create an environment where you have a well-articulated backlog that flows into a team that consists of six to eight people that have everything they need to deliver a working tested increment of product—an increment of product that actually works and is valuable to the business.

The Impact of Agile on the System of Delivery

So, what we’re looking for are cross-functional teams, clear backlog, good acceptance criteria, work broken down as small as possible, so that we can integrate the Dev Teams and QA Teams as we go and create feedback loops throughout the life of the Sprint.

When you have the developers, QA people, and the PO all collaborating on the acceptance criteria and getting to a clear definition of done, you can begin to imagine a world where the teams are cycling through building test cases, coding, validating, and fixing defects more quickly and getting to done faster.

Then we can walk into the Sprint Review with a high degree of confidence that the product is going to work, that it’s suitable to its intended purpose, that it meets the acceptance criteria, and that the PO will sign off on it.

Without the 3 Things, you can’t have super-clear acceptance criteria.

This means you can’t get to a solid definition of done.

The inability to get to a definition of done means that the teams won’t know what they’re going to go and test against so that they can get to a demo and understand when they’re done-done at the end of every Sprint.

Scaling Agile to Improve Quality

One of the biggest things that impact an organization’s ability to move fast—to be Agile—is having the ability to make changes without the risk of breaking anything in the system of delivery. The only way you can create the safety for the organization and the teams to move fast is by connecting execution to strategy through super-intentional upfront planning and tight decomposition between the various layers of governance.

Most large organizations are dealing with multi-layered governance models that look something like a delivery tier on the bottom, a portfolio tier at the top, and a program/product tier in the middle.

Each tier is focused on its own type of quality assurance. The delivery tier focuses on things like craftsmanship, unit testing, TDD, etc. The program/product tier is focused heavily on does the product meet the acceptance criteria, does it have bugs, or defects—things like that. And the portfolio tier is focused on things like will this product be embraced by the market? Will people use it? Will people pay for it?

So, in a multi-tier, multi-team Agile environment, the idea is that Epics will move through the portfolio queue in three to six-month batches. These are the things the business actually cares about—investment initiatives that have dollars attached to them and are expected to get a return.

Epics get decomposed into Features for the program/product tier and those Features have acceptance criteria of their own. The Features get decomposed into User Stories for the delivery tier, and those have their own definition of done.

Having this level of intentionality around creating smaller batches of tightly aligned value streams not only enables your organization to move fast, but it also improves the quality of the system and the product, too. The downward decomposition and upward integration of work, with tighter feedback loops between the layers of governance, creates an inherent quality within the system of delivery itself.

But it all starts with the 3 Things. After all, the key to enterprise Agility is really solid, well-executed team-level Agility. Pair that with enhanced execution at the higher levels of the organization and the sky is the limit.

Remote Work and PSTIR w/ Jeff Howey

Thu, 17 Sep 2020 10:14:43 GMT

At the beginning of the pandemic, LeadingAgile published a white paper called Maintaining Momentum in a Remote Agile World. This episode of SoundNotes is a follow up to that whitepaper. In this interview, Jeff Howey and Dave Prior reflect on what they’ve learned about successful remote interaction since the whitepaper was released, how those lessons can impact a system of Transformation and remote collaboration at scale.

During the interview, Jeff also explains PSTIR, which stands for Prepare, Socialize, Tailor, Implement, and Reinforce; and how PSTIR has become a critical part of the LeadingAgile approach.

If you have a question you’d like to submit for an upcoming podcast, please send them to dave.prior@leadingagile.com

Cultivating the Kind of Culture Employees Crave

Tue, 01 Sep 2020 10:28:16 GMT

As the Chief Cultural Officer, of LeadingAgile, I view myself as an advocate for our employees. I’m super passionate about creating a working environment that is supportive, nurturing, inclusive, and respectful of all employees. Not just the ones that work here, but anyone who might one day work here, too.

As you might expect, I spend a lot of time thinking about our culture and how I can contribute to its evolution and continuous improvement. A few days ago, someone asked me what it was like to work at LeadingAgile and it got me to thinking…If I had 1,500 words or less to entice someone to work here, what would I tell them?

That question led me to write this post. So, in 1500 words, I thought I’d take a closer look at what it takes to cultivate a great culture and explore some of the steps we’ve taken as a company to foster an outstanding working environment for our employees.

Before I dive in, I’d like to share LeadingAgile’s hypothesis on culture with you.

1500 words start…now.

Our Cultural Hypothesis

LeadingAgile’s hypothesis is that successful organizations are built on a solid foundation of intentionally built systems. Our consultants preach this to our clients all the time.

Many organizations think that if they just say and do all the right things that a vibrant culture will emerge over time. Other companies believe that they can indoctrinate people into their culture by simply putting them though training, workshops, and onboarding programs.

Practices are important and they absolutely contribute to a company’s culture. But the practices alone don’t breed a better work environment. And it’s hard to change the hearts and minds of your employees through training, workshops, and programs if the systems around those things don’t reinforce the messaging.

So, if you want to build a vibrant, joyful, and fulfilling culture, you have to develop the systems that will support it and drive the behaviors and shared beliefs you want your company—and more importantly, the people within it—to adopt. Then you add the right practices. Once all that stuff is in place, the culture you crave will be a fast follow.

But make no mistake. every company has its own unique culture—no two are alike. And that means that the systems you build will have to be different too. Figuring out which systems to invest in is the hard part.

Defining Culture

So, what is culture anyway?

Essentially culture is the vibe and feel of an organization. It’s the first impression that’s derived from the practices and “rituals” of the work community. It sets the tone for the interactions that take place between team members and it heavily influences the values of the workplace. In turn, it heavily influences how employees feel about the company. You could say that culture is the company’s subconscious.

To go even further, you could say that it’s the measurable expression of a variety of different elements fusing together to create how an environment is experienced by others. It’s the shared assumptions, values, and beliefs which dictate how we behave.

Having a strong and thriving culture is all about understanding and ensuring that your company’s “why” is being consistently demonstrated in everything the company does. That means that leadership behaviors, team member relationships, activities, and communication are all reflective of the company’s current principles and values.

“Culture is what we do + how we do it + why we do what we do.”

We believe that culture is the common set of observable behaviors and underlying narratives and beliefs that shape how LeadingAgile personnel work and interact day to day.

Defining LeadingAgile’s Culture

This is how we define our culture:

We strive to live up to our core values: honesty, transparency, and committed to staying on message and remaining results focused.

We always aspire to apply these values within our company and community, as well as to each and every one of our client interactions.

We take pride in being fearless, adaptive, sustainable, and egalitarian, and we admire attributes like integrity, respect, teamwork, and passion for continued learning.

We are a company that’s principled in our beliefs and believe in walking the walk at all times.

10 years ago, before my tenure at LeadingAgile began, when the company was first getting started, it was much easier to cultivate this kind of culture. As a small organization, LeadingAgile was able to have natural transparency and connection through personal relationships and 1:1 interaction.

Our core values, principles, and desired character attributes were cultivated through an innate closed-loop accountability system that had no choice but to exist.

But, as we grow larger and more distributed, we knew we had to become more deliberate about fostering these connections and creating more channels within the organization to reinforce our core values and principles, or risk losing the culture we’d grown accustom to. Even worse, we’d run the risk of letting our new and legacy employees get lost in the noise.

We knew we’d have to intentionally put some systems into place to keep our culture alive.

Executing on Our Cultural Hypothesis

The need for intentionally built systems is something that small growing companies will face as they hit certain inflection points. In my experience working with small growing consultancies, I have seen these changes start to appear at 50, 100, and then 200 employees. And LeadingAgile was no different.

Like clockwork, we saw that at around 50 people, culture, connection, and community started to break down. So, we implemented the idea of small groups. In the beginning, we called them tribes. Today, we call them Pods. Basically, a Pod is a small cross-section of employees with a leader who’s dedicated to mentor and advocate for their pod and provide opportunities for career progression. The Pods meet on an agreed-upon cadence, and everyone in each Pod knows that they can reach out to other Pod members for questions, help, and a friendly voice.

We knew early on that building these small working groups was going to be crucial to creating the feeling of connectivity and camaraderie that’s important to any workplace, but especially in one that’s remotely distributed like ours.

But working groups, made up of mostly peers wasn’t going to be enough. We knew that for our employees to feel like they were a part of something bigger, if they were going to truly internalize our “why” that we were going to have to create transparency and give them access to the executives and pull back the curtain on what other Pods were up to, our company strategy, and the business goals we’re trying to accomplish.

So, three times a week, we have an optional Operations & Intelligence (O&I) call. This is where the entire staff is invited to come and get a glimpse into all of our accounts and the work that we’re doing for our clients. Which is an awesome opportunity to stoke conversation so that we can learn from one another and spark ideas for how we can take what we learn and apply it to solutions for our clients.

Pod leaders will give Pod updates, executives will often present a thematic company strategy and introduce larger, company-wide initiatives. Also, once a month, we look under the engine, and talk about the company’s financial health and discuss opportunities for employees to make a financial impact, not just on the company, but on their paychecks. We also will often discuss sales, marketing, and talent acquisition opportunities.

Basically, the O&I call is the ultimate window into the company.

In addition to the company-wide O&I calls, we also have monthly 1:1s built into the system. Each Pod Leader meets with every member of their Pod, once a month, to discuss how each individual is doing and to give guidance on how to navigate the organization and their career path within it. This is our way of giving a voice to every employee who wants to be heard and an influential ear who’s ready and willing to listen.

But, Wait. There’s More…

I whole-heartedly believe that the Pod structure, O&I calls, and executive sponsorship is crucial to cultivating and maintaining our culture. But, that’s only half of it.

At the end of the day, the number one indicator of happiness in the workplace is whether or not you have a best friend at work. Having coworkers that you actually enjoy being around is what differentiates a place you like going to work versus a place you love going to work.

So, another aspect of our culture that we highly encourage is the creation of a wide range of avenues that will foster and maintain connection and comradery. We deliberately build time into our schedules so that our employees can do things like go to conferences (or speak at them), spin up a book club, invest time into one of our many communities of practice, or join us for one of our virtual happy hours.

In addition to allotting time to do some of these micro-team activities, we’ve also invested a large amount of time, money, and effort into building an infrastructure to support our employees. We invest in communication tools like Slack and Zoom so that we can all stay connected when it’s convenient. We’ve built a world-class Ops team that acts as a concierge for every consultant to make life easier when it comes to travel, expenses, and payroll & benefits questions. We even have an Executive Career Coach on retainer to help foster and promote professional growth and an open-door policy with all our executives—including the CEO.

Parting Thoughts

To me, that means ensuring that our culture is easily recognized and demonstrated from the very first touchpoint all the way until the day comes that one of our team members pursues other opportunities.

Like I said before, I spend a lot of time thinking about our culture and how I can contribute to its evolution and continuous improvement. I understand that culture isn’t just about first impressions and saying the right things. It’s about reinforcing the desired organizational behaviors by making sure that our values and principles are reflected by leadership and the systems we create.

Whether it’s the talent acquisition and onboarding programs, the way we put intentionality around connection points where our team members can share, participate, and grow or the commitment we have to honesty, transparency, and respect…

LeadingAgile is dedicated to ensuring that you feel connected to our “why” and making sure that we have the systems in place that will enable you to navigate a rewarding and fulfilling career with us.

For those of you who were counting, I went over by 143 words.

Leveraging Agile to Get Predictable

Wed, 19 Aug 2020 13:50:08 GMT

Agile isn’t ever really about Agile. It’s about creating business outcomes.

In our Business Drivers of Agility webinar series hosted by LeadingAgile CEO, Mike Cottmeyer, Mike dives deep into six key business drivers to uncover how Agile can enable organizations to connect these drivers to better business outcomes.

In this first webinar, we start with predictability. Even though we tend to think of Agility as nearly synonymous with adaptability, one of the most common goals we see organizations have for Transformation is actually predictability.

The good news is that many aspects of Transformation are definable and repeatable, so they can be predictable. In this webinar, we discuss how to create more predictability so we can meet our commitments to customers, and build trust with everyone from internal stakeholders, to customers, to our entire market.

Check out the predictability webinar, and then click below to access the next five webinars that cover the five additional business drivers on-demand, including: Quality, Cost Savings, Early ROI, Product Fit, and Innovation.

Transcript

So, what’s kind of interesting is over the last webinar series and this webinar series, what we’re really doing is we’re really kind of going back to basics. And so last time, we talked about things like balancing capacity and demand and dealing with issues of trust and trustworthiness, the idea of dealing with things you know versus things you don’t know and the idea of encapsulation versus orchestration. We talked through that.

Tim, is going to drop a link for you guys later on if you guys weren’t part of that webinar series, because I think we’re going to reference some of it. But the idea there was is let’s go ahead and let’s start exploring some of the really foundational things of what makes Agile work, what makes it work at scale, what are we really trying to accomplish, right, that kind of stuff. And so, what I thought we would do is kind of continue along that theme here for the next six weeks and talk about some of the drivers that cause us to want to adopt Agile.

And one of the things that I think is interesting is a lot of my message over the last 10 years, 15 years, maybe even, there’s been a little bit of a reaction to some of the things that I hear us talk about and prioritize in our community. And I think a lot of us sometimes we get enamored with the idea of things like having an Agile culture, or having an Agile mindset, or the kind of work environment that Agile creates for us. And all of that stuff is absolutely true. And we want to create great environments for great people to work and to be able to show up and to do their best for the company that they work for.

But a lot of times, the where we’re at now, I mean, it’s just interesting, we’re like 20 years in almost to post signing the Agile Manifesto. And the guys that sign that thing, they changed the world. They did a great job of getting the message out Scrum and the Scrum certification did a great job of getting the message out. We’re starting to see HBR articles written more than one. I think there’s two or three of them that are been written in the last couple years. And not only like the CIOs are interested but the CEOs are interested, and the finance people are interested in the product, people are interested in the market, there’s a lot of stuff that’s interested.

And so generally kind of what would happen is we have this kind of hypothesis, and we said, if… wrong from pen here, right? So, if we do Agile, right, we’re going to get business results, okay? That was kind of the hypothesis. And then we said, “Okay, well, what does that really mean?” Does it mean that we change the culture, right? Does it mean that we start Doing Scrum, right? Like if we show up and we do sprints and daily standups and everything, are we going to get the business results that we want? Well, the answer is, most things, it depends.

If you’re a small team, right, if you’re literally a company of six to eight people, right, there’s probably like a ton of business benefit that you would get from planning and Scrum cases. There’s probably a lot of business benefit you would get of adopting an adaptive kind of culture. But what we’ve learned viscerally over the last 10 years is when you go into particularly large, complicated organizations, just the adoption of these practices or the adoption of those mindsets doesn’t really drive the business results that we want, because we know, right, because a lot of us, I imagine if you’re here on this call, are working in these large organizations. And there’s just a lot of stuff that’s just kind of fundamentally broken.

And so, from how we do governance and how we do project planning and how we do organizational structure, all those kinds of things, right, so there’s this big hop. And a lot of times I reference, there’s a cartoon, I should actually have it on the ready because I talk about it all the time. Two scientists sitting at the board and it’s like a bunch of math over here and a bunch of math over here and there’s like this cloud in the middle that says, then a miracle happens. And one scientist says to the other in a caption, I think you need to be more specific in step two. It’s kind of like we start with this idea that if we do these things, were going to get these business results and it doesn’t always kind of play out that way, okay?

And so, this is how we get from Agile to the business results is really the step two in my argument, right? It’s how do we do it? And so our whole model and everything that I’ve been talking about for a long time is about how do you move an organization from where it is to become the kind of organization that can take advantage of these drivers, right? So that’s where we got into last time, right?

So we talked about things like how do you balance capacity and demand at the team level versus the program at portfolio level, and issues of encapsulation and orchestration and dependencies, and things like that. Because those are the things that fundamentally get in the way how we govern, right, how we deal with cross cutting concerns. Those are the things that get in the way of making Scrum not work in a lot of organizations. So these things can be very difficult to try to overcome.

And so that’s where we started. The six things that we’re going to cover, and there’s probably more as I was actually noodling on kind of an outline for what I wanted to go over, is we’ve learned… I’ll go through the six that we’re going to cover and then maybe we can [inaudible 00:05:52] and go a little bit more. But what we’re going to talk about today is the idea of predictability, okay? And so, predictability is really all about figuring out how to make and meet commitments and how to do what you say you’re going to do. So we’ll go deep into this one today.

What we’re going to do next week is we’re going to talk about quality, right? How does Agile lead to better quality, not just accepting for the fact that it does, but like literally, what are the mechanics of Agile and how do the Agile practices lead to quality?

Early return on investment, okay? So we talked about being able to put products in front of customers and to be able to get feedback but a big driver behind that is we want to put products in front of customers earlier that we can sell so that the organization can start receiving money for those and fund further development because it’s a pretty expensive proposition to do three to four years of development, excuse me, or even a year and a half of development or, gosh, even at this point, six months of development without getting any validation or revenue out of that.

So we’re going to talk about what aspects of an Agile enterprise or Agile is going to lead to early return of investment. And then the fun one, this is going to be the one I’m probably going to dance around a little bit, is a lot of times what we’re looking for is cost savings. And so, cost savings is difficult because most organizations are really, really overloaded. And so there’s 10 times more work to do than the organization can actually do.

So, really difficult to come in and say, yeah, Agile is going to help me lower costs so you end up starting to have a conversation around throughput and highest value and deploying resources, people and dollars and things like that, into the most valuable things, right? So we dance around cost savings a little bit. Those are my original four. These are the first ones that I was talking about probably eight or 10 years ago.

And then we kind of evolved a little bit and we started talking about things like innovation, right, because that’s a big thing that people want, right? So how do I take this legacy organization and make it more innovative, right, the ability to disrupt markets or maybe even cannibalize our existing business, right? So there’s some patterns of Agile and Agile scale that either lead towards innovation or getting away of innovation, so we’re going to talk about that.

The idea of product fit. Are we building the right thing that our market wants to buy, how do we know, right, that kind of a thing? And then what’s really fascinating as we’ve gone deeper into this Elevate Agile conversation that Tim talked about a little bit earlier, and we’re really talking to executives about what they care about, we start to get into things, what I might call, strategic alignment, right?

How do we deploy the organization in a way that maximizes our ability to advance our strategic objectives? Agile has something to say about that. It’s not about just what features that I put into the product but it’s about what capabilities that I develop organizationally and where do I invest dollars so that I can realize these big market shifting kinds of goals, right.

And then the last one, I was thinking about a little bit, I’m kind of looking at my notes so we’re talking about strategic alignment. This might be a thing, I haven’t thought about this this clearly, but I almost want the words, I want to use like investment optimization. So, a lot of times, it’s like we have a really good idea of what we want to do but it really comes down to what’s the MVP of that? What’s the smallest thing that we can do that’s going to realize the value so we make the smallest investment possible to maximize the return on investment in the marketplace?

So I’m going to put something like value optimization here, okay. So, can’t seem to spell in front of you guys today. So these two are going to be kind of out of scope. But what we’re going to hit is, we’re going to hit predictability, quality, early return investment, cost savings, innovation, and product fit. Today, we’re going to start with predictability. And one of the things that I think about a lot, right, and this is something people ask me quite a bit. They don’t ask me the question anymore like how do I get my executives interested in doing Agile because that was like a seven, eight year ago question.

It’s relevant for some people some of the time but it’s not the predominant question. The predominant question is how do I get my execs to spend money on this or how do I get my execs to fully participate in the transformation? How do I get my execs to really care and invest time and energy and to show up and all those kinds of things? And generally the answer is I encourage people to talk about the things that the executives actually care about and what keeps them up at night.

And so sometimes I’ll put this idea of predictability into the idea of, you think about your CEO, right, and your CEO or CIO or whoever is making promises to market. They’re telling their customers what the organization is capable of doing. And they’re counting on the fact that all of the planning processes, all the project management, or all the Agile or all whatever, is going to help them make promises, okay? And they care about that because when executives make commitments to market and then the delivery organization doesn’t deliver against those commitments, then the CEO is effectively kind of lied to market, right?

And maybe not intentionally obviously, but it’s they haven’t delivered. That is a personal thing, right? People don’t like to be in a situation where they make promises and they can’t keep it. So, from a very human perspective, what we want to do is we want to put our executives in a position where the organization is a reliable, trustworthy partner that the executives can say with reasonable certainty, this is what we are capable of providing and this is when we are capable of providing it, okay? And so that idea of predictability is what I’m talking about.

And so, again, if you were at the first couple of talks that we did, the last series of talks, there’s inevitably going to be a recurrence of themes. So what I think we’re going to end up doing over the next six weeks is talk about some common themes that, if you followed my stuff that I hit over and over, but we’re going to put a different lens on them, okay? So the first lens or the first set of foundational things that we’re going to talk about when it comes to predictability is the idea of the three things, teams, backlogs, working tested software.

And so, if you think about a predictable Agile team, a team that can make and meet commitments, that’s going to be able to do what it says it’s going to do, right? The first thing that that team needs is it needs clarity on the backlog. Okay? And that means, in some form or fashion, we need to have a stack rank list of things that we are going to build, okay, product backlog, maybe user stories. And now, remember, that my focus is super narrow right now. I’m not talking about enterprise agility. I’m not talking about elevating the conversation. I’m talking about team level agility.

So the fundamental building block, right, team level agility. How do we get a team to be able to make and meet commitments, right? So, the teams make and meet commitments by having a stack rank list of user stories, right? We typically want to have those stories estimated, right? We want to be able to bring them into sprint planning and have a conversation around them. The team gets clarity on what they’re being asked to build. They understand the acceptance criteria. And they’re able to say, “Yup, this is reasonably what I think we can pull off,” right?

And then we want the team to have the ability to be accountable, right. So we’re going to put a team here, right? What is a team? Why would I use the word accountable, right? Well, because a team in Agile, as described by Scrum in the Scrum guide, is when they say five plus or minus two, I usually like to use six to eight kind of in the same ballpark. And it’s a group of people that have everything and everyone necessary to be able to deliver a working tested increment of software or whatever product that you’re building, okay?

So, since we’re typically in the software space, six to eight people have everything and everyone necessary to build a working tested increment of software as described by the backlog, okay? If that team has everything and everyone necessary to be able to deliver that working tested increment, Scrum should work as described. They pull a chunk off the backlog. They go through sprint planning, maybe they decompose the work. They pull it in, they swarm together through the life of the sprint. They deliver it, they review it with the product owner, product owner says yes, and then they get to claim the points, right?

And, again, there’s other ways to skin a cat, right? But you get the idea, right? That’s one way, right? So, a team that can establish a stable velocity against the, I can’t write today, against a known backlog can start to say, “Okay, cool,” right? We know what we can produce every sprint. Why is acceptance criteria or definition of done or deployability or even so far as to extend it out to like we actually have deployed it with customer? Why is that important? Because when we get to a point where we have a really clear definition of done, I never know how to draw a software. Sometimes I want to draw it like as a box but that gets kind of crazy, right? But you guys get the idea, right, software.

So database table, right? That kind of thing. It’s a screen. So the idea is that we produce this working tested increment. And the reason why the acceptance criteria is so important is because if we are clear on what this backlog item is, and we have an idea of its relative size, we pull it into a complete cross functional team that has everything and everyone necessary to be able to deliver that set of user stories.

And we validate that it met the acceptance criteria and it satisfied the definition of done, which means that there’s no like shadow backlog emerging over here, that basically is all the things that we really didn’t get done that are going to be necessary to deploy, right, defects, technical debt, unrealized features, right? All the little different cruft that kind of accumulates as you’re building stuff, right?

If we don’t do that and we’re actually done then the math of Agile work is at the team level, right? So we know the size of the backlog. We know the velocity, velocity of a team, and then we can start to derive how many sprints it will take to get through the backlog or how much backlog we can do in a predetermined number of sprints, right? So that gives us the ability to reliably make and meet commitments at the team level. Now, think about how this actually works in practice quite often, okay?

Product owners not quite present or the product owners delegated to a BA. The BA doesn’t really have the authority to decide. And the backlog just kind of starts out indeterminate, okay? If I don’t know the size of the backlog, I can’t get to the point where I know how much that backlog I’m going to be able to do or how many sprints it’s going to take. Let’s think of another pattern, right, that happens quite often, okay, is the product owner is not partly present at all, slides in for the sprint planning meeting, and kind of just rattle some things off just like a sprint at a time, okay?

In that particular case, even if they write perfectly clear backlog items, we have no visibility into the rest of this, okay? Now, different organizations have different needs for predictability, right? In my organization, LeadingAgile, I have a software development team, I have zero need for predictability, like zero need for predictability. We are building an internal tool. It’s totally a proof of concept. We use it as an enabler of our consulting teams and we have absolutely no commitments to market. And as long as we’re investing to learn, my life is good, as long as we’re making reasonable progress, my life is good, I continue to make those investments in that team.

Really different from somebody who needs to have a feature set ready for a tradeshow in market in a quarter, really different than somebody who has a mature customer base and who needs to be able to publish a roadmap, right, so that their enterprise class customers can begin planning for different integrations with them overtime, right? And so, a lot of organizations don’t need to know exactly where they’re going to be but they have to have a pretty good idea where they’re going to be.

Or let’s say you’re bidding on a fixed price contract for the government or something and you’re going to be locked into fixed time, fixed costs, fixed scope, you need even more predictability, right, more ability to figure out how to make tradeoffs within constraints, and all that kind of stuff. So different organizations have different needs for predictability. So, if you’re an organization that doesn’t need any predictability, this is probably a wrong talk for you, right? If you’re an organization that needs three to six months out, this is valid strategy. If you’re an organization that needs a year or a year and a half roadmap, that’s the next level up in the conversation, right?

So, predictability can be all over the place. What I find sometimes, right, and this is where we get sideways with our executives, is that the executives want predictability. And as Agilists, we approach it with like a very lean startup mindset and we go, this is Agile, you don’t get predictability, right? That is a surefire way to get excused out the door if you’re a consultant and it’s a surefire way to get marginalized if you’re an internal employee.

If the organization wants predictability and is asking for predictability and has enabled you as a team of Agile coaches to provide predictability, you may say, “We’re Agile, you need to change your need for predictability.” Like, “Okay, right cool.” If you want to fight that fight, fight it, but that’s a very low probability win for you, okay?

So generally, the strategy is meet the organization where it is, this gets in the whole transformation strategy, meet the organization where it is, help it become predictable using Agile tools and techniques, and then figure out how to help it reduce batch size and make decisions more rapidly, right? So we’ll get into that when we talk about some of the early return on investment stuff, okay?

Well, let’s get back to our story, right? So, let’s think about some of the anti-patterns. So, the product owner comes in, backlog is not very well defined, team doesn’t know how to plan for it, can’t stabilize velocity, build software, starts accumulating this cruft on the backside of stuff that doesn’t really work, breaks our predictability, okay, just breaks it, right? Or alternatively, let’s say everything is right but the product owner comes in at the last minute and gives us a sprint at a time.

Like my work in some environments would work for me, right, in LeadingAgile, my software team, but it would not work for an organization that’s trying to hit a tradeshow in a couple months, right, because we don’t know we’re it going to get. Or is trying to deliver on something that they promised the customer, it’s not going to work that way, right? So we have to put a lot of effort into grooming that backlog further out so that we can establish predictability.

What gets in the way of teams being able to be predictable, right? So I kind of went through great lengths to say the team is a group of six to eight people that has everything and everyone necessary to be able to deliver a working tested increment of software, okay? So, what if I don’t have everyone and everything necessary? In some form of fashion, that means I have a dependency. So when I have dependencies between my team and somebody else’s team, or my team and somebody else’s resource pool, then I am dependent upon them to be able to do what they say they’re going to do so that I can make and meet commitments and establish stable velocity.

So, one of the big hallmarks that we try to go for when adopting Agile is to pull the team together in such a way, to design the team in such a way that the team has everything and everyone necessary so that it can establish stable velocity. And hopefully that velocity is stable overtime, right? There’s obviously variation and things like that but if you can get kind of a good rolling average, that’s probably good enough, enables you to make tradeoffs, right? But dependencies get in the way, external resources, technical dependencies or all kinds of different dependencies, get in the way of being able to establish a stable velocity.

If you can’t establish a stable velocity, you can’t be predictable. Now, here’s a really common thing, right? So people say, “But my team, we’re like the typical Agile team,” right? So we build the product and we support the product so we can predict the build side of a product, right? Maybe we’re great at doing user stories and estimation and kind of release planning level stuff. We’re really great stabilizing velocity, we have a complete cross functional team, but part of our backlog is interrupt driven.

That’s an interesting problem, right? Because anytime that you are mixing, what I call a determinant backlog with an indeterminate backlog, right, then you have to basically deploy buffering strategies, right, so that gets complicated. And so a lot of times, what the team will do is if the break/fix work is kind of predictable, right, it kind of comes in an even flow and you have good relationship with product owners, you just buffer some time, right? I’ve seen teams run Scrum for their product development and then throttle work in process via the like a Kanban queue that they kind of run on the side.

I’ve seen teams rotate team members out of a team or put somebody like in responsible, like he’s responsible for triage. Back when I was at VersionOne, this guy, he’s still there, I guess CollabNet now, a guy named John. And he was like the support guy and so they would assign one developer to John every sprint, they called it being on the John that sprint, I thought that was kind of funny. And so that one guy on the John, but that was their strategy for triaging and having one person on the team kind of separate to deal with most of the break/fix stuff.

Now, if you’re in a situation where you’re like your software is so chaotic and you’re dealing with tons of break/fix stuff and it’s just totally indeterminate, just a crazy wave, that becomes a different problem. Because now, you’re just not going to be able to make and meet commitments. So now you’re not talking about like, how do I do Scrum, right, to be able to be predictable? You’re like, how do I stabilize my codebase, right? How do I stabilize my product so that I’m not in this situation, or you have a bigger class of problem than just figuring out how to do Scrum or form teams or something like that, right?

And I’ve been in teams in those situations as well, right? Very difficult to be successful when you’re dealing with those kinds of constraints. So, a lot of my mental model isn’t to say, how do you do Scrum in the face of impossible circumstances to become predictable? Like a lot of my mental model is, this is what’s absolutely required to be predictable, you have to create the conditions for the group to be predictable.

Because you just won’t be predictable otherwise, right, unless you create the conditions for predictability. And that is known backlog, whatever planning horizon is appropriate, a stable cross functional team with few if any dependencies, and then the ability to get to a definition of done, right?

And that definition of done in effect is no defects, potentially shippable, right, different contexts are different, right? So it’s like I love you to have any production every two weeks but that’s not realistic in a lot of context, right, ERP and different things that have longer app release cycles, right? But basically, the principle though is to get it to a place where you’re not dealing with this indeterminate backlog on the backside, right? Okay, cool.

So we’re about halfway through. I always wonder whether I’m going to be able to fill up the whole hour talking about these little micro topics, but it’s inevitable, right? Because some of these principles, and I also feel like a lot of times I’m repeating myself because it’s like we’ve been talking about these ideas for so long but I still, Tim reminds me all the time based upon search traffic and the things that people are engaged with, these are still like really, really common problems. And what I’m trying to do is I, and again, even though they’re common problems, the solutions are nontrivial.

But, again, the mindset you guys have to come with is if you want Agile to work and you want it to deliver this particular business driver, this predictability, the ability for the CEO, CIO to make and meet commitments, these are the conditions that you have to create, right? So now, when you start to scale up this conversation a little bit, and we’ve often talked about it like this, right? So we’ll say, I call it the three things, right? So we talked about teams, backlogs, working tested software.

And I wish I would have rolled it off my tongue the first time as backlogs teams working tested software because then it would be congruent with how I typically draw it, but it just wasn’t to be, right? So there’ll be probably a forever incongruence between that, right? So, teams, backlogs, working tested software. As you start to think about scale and being predictable in the large, okay, now we’re dealing with what we call structure, right, which is the way that multiple teams relate to each other. Backlogs becomes governance. And working tested software and today it’s probably still working tested software but what I talked about is metrics, right? How do we measure value across multiple teams?

And it all boils down to the same fundamental concepts. But now as we start to scale, we have a slightly different class a problem. We have more of like a Theory of Constraints problem. We have bottleneck problems in the system. Now, if you go back to some of the early thinkers around this, and I don’t even know if you consider these guys early because everybody’s still out and about and doing things. But I go to some of the early Schwaber stuff on scale, some of the [inaudible 00:30:58], Craig Warman stuff around Scaling Scrum and what’s kind of emerged in the Large Scale Scrum framework now.

Those methodologies, I think, are really spot on, right? And I think they brought a lot of wisdom into our community. The challenge is I think it kind of hand wave over the fact that most organizations, at least initially, are products, or excuse me, projectized organizations, right? They approve dollars in project tranches, right? And they have a lot of dependencies and a lot of misalignment within the organization. And so, the way I look at a lot of those models is if you are a well-formed organization, and you don’t have a lot of dependencies, and you are doing team or business capability or value stream-based funding, then I think those methodologies are spot on.

But what do you do in a system where you have, what I would call, uneven investment at the team level, right? The reason why people want to move people around and not form the right kinds of teams and not build the right kinds of backlogs is because they want to deploy resources, people, I apologize if that offends anybody but it’s kind of ingrained in me from 30 years as a project manager, right? If you want to deploy people into projects, right, then what you end up having to do is you have to slice people and slice teams into little bits to be able to get them to fit right into the project metaphor.

The flip, this is a big, it’s really a high level strategic thing that maybe we’ll talk about towards the end of the series. But it’s like one of the big things that we’re trying to get a lot of our large transformation customers to do is to, after they’ve established this Agile enterprise, really get the governance to stop thinking about funding projects as an investment vehicle but funding products. And products can be a lot of things, right? It can be a business capability, it can be a value stream, it can be a subcomponent. There’s lots of different platform strategies and different things like that. But the idea is that you’re funding teams, right? You’re not funding projects.

This goes back 20 years in Agile. It’s like what we want to do is we want to bring projects to teams, not bring teams to project’s right. So it’s a flip of that mental mindset that’s still particularly relevant. But when you’re in transition, right, or when you’re in an unbalanced, non-team funded environment, what you end up with is something like this, right? You end up with multiple teams, right? So let’s say you’ve done everything right, okay? So now we’re on an established baseline, right? Everybody has perfectly formed backlogs. Everybody has groups of six to eight that have everything and everyone necessary to be able to deliver working tested increment of product, and every team is able to produce a working tested increment at the end of the sprint, right?

So, now we’re talking about perfect execution at the team level, right? So, this is why it’s so hard. So Tim was talking about our Elevate Agile conferences coming up. We ran a pilot of it effectively last year. And, I mean, we had some really, really cool speakers, we had clients like guys who are like, VP, Senior VP, enterprise architecture, right, all this kind of stuff, totally get this idea of scaling and governance and like how do I do this, I’ve worked with them for a long time. But it’s like, what’s super hard about is everybody wants to start at the team level because that’s the building block, right? If you don’t get this team level stuff right, it’s really hard to do the higher level stuff right?

But here’s the problem. This is why we’re doing this Elevate Agile thing. It’s like, as soon as you start talking about the team, you lose the business, right? So I’m kind of talking to you guys as kind of insiders on this to understand the problem. Team level agility is absolutely team level predictability to make sure we’re really anchored in in this context. Team level predictability is absolutely essential for enterprise level predictability. You’ve got to get the backlog straight, you got to get the teams formed, you got to get the dependencies broken, you got to get each individual team the ability to produce working tested increment at the end of the sprint, okay?

But team level agility is insufficient for enterprise level agility. Let’s talk about why, right? Because at some point, you have this thing called a project that gets funded on high, right, some governance structure, some group of executives is approving a tranche of dollars. I don’t use the word tranche a lot and I’ve used it like three times in this call, so I don’t know I have to evaluate my vocabulary here. This tranche of dollars is associated with the project because projects are often the thing we think about to achieve business outcomes, right?

And so, the mental model is, is the business brings this initiative to the table, I want to do this in the software stack. I’m going to ask for dollars because the idea is I’m going to get more dollars on the backside, right? And, inherently, what ends up happening, right, is that we take people out of these teams and we assign these human beings up here, right, and we go, we send them to do that. Well, let’s say we had this layer in place and we kind of fix the structure and we got agreement that we weren’t going to bust up teams to go deliver projects. But now we’re going to bust up the project to be able to send the components to the team, okay?

And so, what would that look like, right? So you’d have some key, I like to call these epics. I think of projects as like epics. I know some people think epics is lower level like just bigger stories, but I tend to think of epics as something that has a value to the business, right? So I’m going to use my word, right? So, we take our epics and we break them down into features, right? And then those features get assigned to users or they get broken down into user stories.

Let’s say this particular epic, right, was really heavy, I’m going to switch to different color here, was really heavy on team one. That’s supposed to be a T, it looks like a crazy Y, right? It’s really heavy on team two, has some work for team three, right? And no works for team 4, no works for team three and team five, right? So, what we find a lot of times is we break up work this way that we end up with, we end up with teams that have way more to do than they can do and we have teams that have very little to do, right, so what are they going to do, right?

And so you start to say, “Well, let’s figure out what’s the next thing,” right? Well, what if the next epic, right, that’s the highest business value, it just further exacerbates the problem, right. So we have people, we have teams deployed into these capabilities that are necessary and then we have starved teams. A lot of times what happens, one of two things happens, right? This is what’s fascinating. We go figure out, so we go through and we go through like the stack rank list of all the initiatives and it’s only the 20th initiative, right, that requires teams three and teams five, okay? But the 20th initiative also requires a little bit from team one, a little bit from team two and a little bit from team four.

So we say, okay, we want to get teams three and five busy so we load up their backlogs. But here’s the reality, this little itty bit of work down here never gets done, right? So all this work that teams three and teams five are dealing with… That’s interesting, we got almost like an ink spot on my screen there. They’re never going to realize business value, right? So it’s not like a prioritization problem. It’s not a dependency management problem. It’s not a commitment problem. It’s a you were never going to be high enough in the queue to get the attention of these constrained teams, right. It’s just not going to, right?

So the strategies that we tend to try to employ are things like balancing at the portfolio level and making investment decisions that are aware of the capacity of each of these teams, right? So if we could have a high level hypothesis at the portfolio level that basically says, look, we have constrained capacity on these high value teams, we have tons of capacity on the lower level teams, and what we have to do is we have to balance our portfolio to make sure that we’re not overloading the high value teams and we’re not assigning work. And I say low value teams but teams that are working on things that are not the highest priority or strategically aligned with the organization, right?

And so, what tends to happen and… see if I can do this again here so that I can move out of the way. This is where kind of these multilayered portfolio strategies kind of came in. So, you want to have, what I usually represent, is a Kanban-based governance model, right, up here at the top, right, that is pulling epics and effectively small projects, hopefully two to three months, right, because we want to batch size limit work in process, all that kind of stuff, right? You can even do things like gate one, gate two, gate three, gate four because there’s usually a Kanban-based type flow there, right?

Those things get kind of translated into a middle layer which I haven’t done this in a while but, provocatively, I put like analysis design, build, test, deploy kind of waterfall there. I have a funny story. One time I wrote this up in a blog post, probably pushing 10 years ago, I might have been at VersionOne at the time. And I provocatively titled that Kanban as just waterfall small batches. And David Anderson, the guy who invented Kanban, he tweeted or texted me, I can’t remember at the time. And he’s like, I want to be pissed at you when I read the title, but when I read your article, it was actually dead on, right?

Because it’s not a waterfall, right? It’s not big batch, it’s not big handoffs and things like that. But you can effectively take a feature and run it through an analysis, design, build, test, deploy Kanban without changing the organization structure at all. And just the smaller batches and limiting work in process in the different metrics will actually make workflow through the system more effectively. So, I think about epics is being decomposed into features, right? And then the result of the analysis and design comes down to your Scrum teams, right, and user stories.

So, let’s look at predictability at kind of a more global scale, right? To be predictable across the enterprise, what you need is you need an ability to look at the portfolio of work that’s coming in organizationally and make some hypotheses, right, make some guesses, make some assumptions, establish some constraints, that basically assert that the organization down here, right, based upon the predictable delivery and performance of those individual Scrum teams, right, because they become reliable delivery capacity now, right, based upon their predictable reliable delivery capacity, we can start making some bets about what the organization is capable of delivering.

So we align the portfolio level to the execution ability of lower level teams. But we know it’s not going to be perfect, right, because there’s going to be variation. There’s going to inevitably be cross-cutting concerns on things that we don’t anticipate. That’s where this middle tier comes up, right? So, this middle tier is going through kind of rolling wave planning, right, taking the highest value epics, decomposing them into features, right, decomposing them in a way that they’re scoped to be able to live within the higher level of constraint. And then decomposing those user stories out of the features and assigning them to the teams with the product owners, and basically making like feeding the system.

Dean Stevens called this, Feeding the Agile Beast, right? So it’s how do you feed the teams and align with strategy, right? So you have like a working group, like it’s decomposing work in real time based upon the capacity of the teams so that the teams are getting the right things, such that as they build it and it gets validated, there’s a steady flow of features coming out the backside. And as these features get delivered, there’s a steady flow of epics coming up this side, right? Very tactical, very mechanical explanation of the way a multitier architecture works.

But in the context of being predictable, there’s a couple of things at play, right? So, a predictable Agile enterprise absolutely demands predictable teams or else nothing else works, right, this doesn’t work, right. So that’s where we get into all the other things we are talking about over here in screen, right? All the things we talked about here, all of those rules still apply, but now we’re dealing with the conversation at scale. So now, we have a predictable substrate of Agile teams, we have to make sure that we are feeding those teams ready backlog. All those same rules apply, right, three to four to five sprints out, however many you need for a rolling wave.

And then to be able to make tradeoffs in those backlogs to balance where the constraints are across the teams. And then as those features are being delivered, we’re making tradeoffs at the feature level to make sure that we’re delivering the epic at the highest level. So let me tell you one of the things that I’ve kind of historically disagreed with, with Dean and the whole SAFe thing. And I’ve disagreed with him to his face. So if he happens to watch this or I doubt he’s on the call, but if he sees this at some point, I don’t think there’s anything that would throw him off in how I’m thinking about this.

One of the things that I think SAFe hasn’t done a particularly good job at, is talking about the architecture of the teams such that we create stable, reliable teams at this level. Now, don’t get me wrong. It’s absolutely implied. If you go back to your original Scrum material, absolutely implied. But in practice, I think, a lot of folks are not sitting on this as a fundamental building block, right? It’s like the encapsulation, orchestration, trust versus trustworthiness conversation we’re having a few weeks ago, right? So you absolutely sit on this.

The other thing that I think is a bit of a fallacy is that when you wrap this with PI planning, right, so we all get together with you big room for two days, right, two days, right, maybe to review kind of a thing. What’s implied if you’re running this in a Kanban is that there’s a limiting of a work in process and there’s a flow and a prioritization and a sequencing. So we might do a dependency map, right, in this level of planning, right. But the problem is, is that, again, in practice, it’s hard for me to distinguish what’s prescribed versus what’s intend versus what’s practiced sometimes, because a lot of it changes. But the idea is it’s almost like we’re all going to get together. We’re all going to do this two-day planning and then it’s kind of free for all. And then we come back here on the backside and [inaudible 00:48:13].

I think there’s kind of like two challenges with that, is I don’t think there’s enough feedback in here and I also don’t think that two days is enough to get everybody on the same page. I understand why we want to do it and I understand why it feels good, okay? But at a minimum, what I would want to do is I would want to have a background thread coming and this is what I advise SAFe teams on quite a bit because I want a background process running that basically says is that we are going to walk in to this meeting. And we are going to have every team with the dependency aware, backlog, groomed when I walk in.

And I would want to understand where most of those dependencies were in the system. And I would want to front load the dependency work earlier in the release. So that the things that are dependencies for other teams get resolved and dealt with early so that as I move later into the release, I have less worry about the nature of those dependencies or a late breaking dependency causing me problems, okay? But by the time you do that, in my opinion, right, my understanding which is probably less than perfect, is that you’ve kind of broken this framework to some degree and you’ve created a bit more of this framework.

So, often in early stage transformations, predictability is like the number one goal for us especially in an organization because a big part of the reason why you need to get predictable first, aside from the goal that organizations want you to be predictable, right, and that’s what the CEO cares about, that’s what they’re willing to fund and pay for. One of the things they’re willing to fund and pay for is it being predictable also builds trust with the organization. So we come and say, “Hey, we’re going to do Agile, it’s going to solve all your problems,” and then it’s chaos, right, it erodes trust.

If we can come in and start to use Scrum and Agile and Kanban and these metrics and methods and stabilize the system and get it really predictable right out of the gate, even in the presence of dependencies and teams that aren’t perfectly formed, we build a lot of trust with the organization. So, a lot of times, what we end up doing is we end up doing something like creating a working group at this level, I’ve called these things product owner teams in the past. And a big part of their job, maybe not a full time job, they’re not like a real Scrum team, they’re more like a Kanban team. Their job is to breakdown work and to validate completion in a continuous pattern.

And so, I like the idea of continuous backlog grooming, right, by a separate group of people that is punctuated with release plan. So, what that might look like in practice is I’ve got a team that’s continuously decomposing kind of through this analysis and design phase. And there’s like a little batch here in the Kanban where I’m queuing up a release worth of work. At the point that I have a release worth of work ready, all dependency aware, cross-cutting concern aware, load balance, all that stuff, right? Then I would bring it to a team during a two-day planning session and let them work out the fine-grained details.

All the work would be sequenced in the release so that the scary high dependency stuff is done early, the lower risk stuff is done late. That’s just good strategy to begin with. And then I reduce the risk. And so the release ends up being this build phase, but we’re probably going to loop between build and test, right, that would make sense, right? And then we get to the end of the release and we do a deploy, something like that, okay?

So, just real simple. We’re kind of run out of time here. And I’ll ask Tim if we have any questions. But like the two things, right, are at the team level, teams, backlogs, working tested of software, right? Absolutely a precondition for any sense of enterprise agility is to get team level agility right. And then once you get team level agility right, it’s really about balancing the portfolio and the decomposition processes to make sure that we’re exploiting the capacity of the delivery organization in a way that maximizes its ability to create flow.

And so if we have our portfolio items broken down into small pieces, and we have this group that’s breaking the portfolio things into program level features at a regular cadence, even if we’re cuing it up in a safe like world, right, we’re batching up releases and then we’re going into like a big room, big release planning, totally fine, right? I just prescribed something that’s before and after that, right? It’s okay, right? I call it safe plus sometimes, right, because in the presence of dependencies and more complicated environments, sometimes you need a little bit more, cool, right?

But these processes up here are what is going to basically establish flow at the enterprise level and, again, exploiting the flow at the team model. And if these two aspects of the system are not working in tandem, we don’t actually get the predictability that we want. And then I’ll just kind of put a dot on it and we’ll call it done here. But it’s like you can be predictable and perfect at your Scrum team level and the organization sees no predictability and value at the enterprise level because you didn’t build the structures in place to make sure that the system was getting fed in a way they basically kind of funneled everything through from an early release perspective, okay?

So predictability, super important. It builds trust, executives want it, they’re willing to pay for it. If you guys can show them how Agile is solving that problem for them, right, and the things that they need to do, you make a really strong case for transformation, okay. And so, hopefully, that’s what you guys got out of this.

Tim, any questions that would be kind of a quick hit before we wrap?

Yeah. I think you touched on this probably a bit but somebody asked about, it’s a dependency related question. They said, what if my team is doing Scrum and dependent on other teams who are waterfall?

Yeah. Well, that’s a tough thing, right? So, that’s a more advanced organizational design question, right? But you have to realize that when you take something that’s really fast, right, design to be really fast, and you mix it with something that’s really slow, right, you’re going to end up somewhere in between. Okay. We see this a lot, right?

So we’ve had historically a lot of financial services customers, a lot of manufacturing customers and pharmaceuticals right now. But like in financial services, that’s kind of where I grew up was, you would end up like big mainframe stuff that’s kind of doing waterfall or you’d have like clients, integration partners that were waterfall, you need to have this really cool front-end team, right?

And so what you tend to try to do is to get the waterfall teams to work in slightly smaller batches, maybe it’s like three, four months’ batches instead of 18-month batches, so you try to compress them a little bit. And you also try to get them to publish roadmaps because waterfalls never like perfectly waterfall. There’s usually some increment in iteration in there. And then what you end up with doing is that the Agile teams end up going fast within that but then there’s sync points along the way, right?

There’s some strategy around that but there’s just no world in which if you’re building an integrated product with Agile teams and waterfall teams that you’re going to get the release performance and the predictability and everything that you would have if you had a full blown Agile organization. It just not going to happen, right? Again, fast stuff and slow stuff. It’s a little bit like where I talked about is like predictable stuff and unpredictable stuff is going to, you’re going to end up someplace in the middle, is what it comes down to.

Awesome. Well, thanks, guys. I appreciate everybody who joined us. And we’ll see you next week.

Trust vs. Trustworthiness w/ Yaton Bowens

Thu, 13 Aug 2020 09:59:37 GMT

This week in SoundNotes, LeadingAgile Managing Consultant Yaton Bowens joins Dave to talk about the role that trust plays in Agile Transformation. Building on Mike Cottmeyers’ Trust vs. Trustworthiness webinar, Yaton and Dave dig into some of the trust gaps that management and the Development Teams have to cross for an Agile Transformation to take root in an organization.

Without a track record to demonstrate trustworthiness, how can management trust that the team will deliver? And how can the team trust that management will allow them to get the work done? To make things even more complicated, many organizations have not been designed with systems that support trust and trustworthiness.

We’ll delve into the answers to these questions and more this week.

Links from the Podcast

Mike Cottmeyer’s Trust vs. Trustworthiness Webinar

Contacting Yaton Bowens

Web: https://www.leadingagile.com/guides/yaton-bowens/
LinkedIn: https://www.linkedin.com/in/yaton-bowens-06478a1/
Email: yaton.bowens@leadingagile.com

Contacting Dave Prior

If you’d like to contact Dave you can reach him at:

LeadingAgile: https://www.leadingagile.com/guides/dave-prior/
LinkedIn: https://www.linkedin.com/in/mrsungo
Twitter: https://twitter.com/mrsungo
Email: dave.prior@leadingagile.com

If you have a question you’d like to submit for an upcoming podcast, please send them to dave.prior@leadingagile.com

When Being Nice Isn’t Enough w/ Rich Dammkoehler and Joel Norman

Thu, 16 Jul 2020 14:48:05 GMT

Creating a space where people can feel safe working together, developing products, and growing and learning as a team is important. But sometimes, in an effort to be polite, we end up being less open and honest than we probably intend to be. So the question becomes, how can you create an environment that is safe, collaborative, creative, open, respectful, and inclusive where people are still enabled to be direct and offer critical feedback when necessary?

In this episode of SoundNotes, LeadingAgile’s Rich Dammkoehler and Joel Norman join Dave to discuss what to do when being nice isn’t enough. They talk about how this can happen, the impact it can have, how they address it, and what you can do to start creating an environment where being supportive, creating safety, and collaborating also means being honest and direct with your feedback.

LeadingAgile · When Being Nice Isn’t Enough w/ Rich Dammkoehler and Joel Norman

Rich and Joel on Twitch

https://www.twitch.tv/leadingagile

Contacting Rich

Web: https://www.leadingagile.com/guides/rich-dammkoehler/
LinkedIn: https://www.linkedin.com/in/richdammkoehler/
Twitter: net_zer0
Email: rich.dammkoehler@leadingagile.com

Contacting Joel

Web: https://www.leadingagile.com/guides/joel-norman/
LinkedIn: https://www.linkedin.com/in/joel-norman-469a42163/
Email: joel.norman@leadingagile.com

Contacting Dave Prior

If you’d like to contact Dave you can reach him at:

LeadingAgile: https://www.leadingagile.com/guides/dave-prior/
LinkedIn: https://www.linkedin.com/in/mrsungo
Twitter: https://twitter.com/mrsungo
Email: dave.prior@leadingagile.com

If you have a question you’d like to submit for an upcoming podcast, please send them to dave.prior@leadingagile.com

Using Earned Value with Agile w/ Justin Polk

Thu, 09 Jul 2020 18:47:53 GMT

This week is all about Earned Value and Justin Polk is back, spending time with Dave to discuss how Earned Value tools can be applied in an Agile Transformation. Dave and Justin will explore what types of work you might want to consider using Earned Value for, how Earned Value can help, and who might find the path to Agile just a little more possible when you show them how Earned Value metrics can be applied on an Agile Team.

Links

If you are new to Earned Value, here are a few links to help you get started:

Contacting Justin Polk

LeadingAgile: https://www.leadingagile.com/guides/justin-polk/
LinkedIn: https://www.linkedin.com/in/justin-polk/
Email: justin.polk@leadingagile.com

Contacting Dave Prior

If you’d like to contact Dave you can reach him at:

LeadingAgile: https://www.leadingagile.com/guides/dave-prior/
LinkedIn: https://www.linkedin.com/in/mrsungo
Twitter: https://twitter.com/mrsungo
Email: dave.prior@leadingagile.com

If you have a question you’d like to submit for an upcoming podcast, please send them to dave.prior@leadingagile.com

Getting Hired in Agile w/ Priya Sethuraman

Thu, 25 Jun 2020 10:00:21 GMT

Once you reach the point where you’re ready to pursue a job in Agile, the next hurdle you’ll often face is, “How?” Convincing someone to give you a job as a ScrumMaster or a Product Owner can be tough if you have no experience. And even if you do have experience, that doesn’t necessarily make it easier. The Pandemic has put a lot of people back into the applicant pool, and the competition is fierce.

In this week’s SoundNotes, LeadingAgile’s Director of Talent Acquisition Priya Sethuraman spends time with Dave talking about what to do if you are looking for a job in Agile. Priya and Dave discuss different approaches you can take, ways to prepare yourself to succeed in the interview, and how to begin working on getting experience and building your network even if you are completely new to the space.

Contacting Priya Sethuraman

Web: https://www.leadingagile.com/guides/priya-sethuraman/
Email: priya@leadingagile.com
LinkedIn: https://www.linkedin.com/in/priyasethuraman/

Contacting Dave Prior

If you’d like to contact Dave you can reach him at:

LeadingAgile: https://www.leadingagile.com/guides/dave-prior/
LinkedIn: https://www.linkedin.com/in/mrsungo
Twitter: https://twitter.com/mrsungo
Email: dave.prior@leadingagile.com

If you have a question you’d like to submit for an upcoming podcast, please send them to dave.prior@leadingagile.com

Selecting and Running Agile Pilots w/ Justin Polk

Thu, 18 Jun 2020 10:10:36 GMT

Many organizations begin their journey toward becoming Agile by selecting a few initial teams or projects that are set up to test out how Agile will impact the organization and its ability to deliver work. LeadingAgile Senior Consultant Justin Polk joins Dave this week to discuss how to select and run an Agile pilot.

In this episode, you’ll learn about some of the risks and challenges that come with pilots, why LeadingAgile takes a more holistic approach to piloting by selecting an entire vertical slice of the organization to work with, and how to begin having conversations about selecting the right part of your organization to serve as a pilot in your company’s Agile Transformation.

Contacting Justin Polk

LeadingAgile: https://www.leadingagile.com/guides/justin-polk/
LinkedIn: https://www.linkedin.com/in/justin-polk/
Email: justin.polk@leadingagile.com

Contacting Dave Prior

If you’d like to contact Dave you can reach him at:

LeadingAgile: https://www.leadingagile.com/guides/dave-prior/
LinkedIn: https://www.linkedin.com/in/mrsungo
Twitter: https://twitter.com/mrsungo
Email: dave.prior@leadingagile.com

If you have a question you’d like to submit for an upcoming podcast, please send them to dave.prior@leadingagile.com

Unveiling the Agile Operating Model

Tue, 09 Jun 2020 09:16:41 GMT

New strategies or dramatic shifts in existing strategies require an examination of an organization’s operating model. Agile is a new business paradigm, but few established companies understand what needs to change to make their business Agile. Most think it is about speed and flexibility. They forget about efficiency and resiliency, key fundamentals without which companies fail to achieve their desired speed. Companies that master the balance between these characteristics are more successful at transforming into Agile organizations.

What does this balanced next-generation operating model look like? Let’s examine the three core elements of the operating model – organization (resources and structure), governance (decision-making model), and processes (steps to get things done).

Organization

Agile organizations separate the traditional structure from the way work is delivered. Traditional organizational charts include reporting relationships that encompass where the work gets done, who manages the work, and who is responsible for performance management. Historically, these were all aligned.

As we move into an Agile world, the organizational structure and delivery need to be separated. The organizational structure will still specify an employee’s “homeroom” and assigns him/her a manager who is still responsible for rewards, coaching, and performance conversations – this provides clarity and stability. However, the day-to-day work is done in dynamic Agile teams that are cross-functional, and have a set of responsibilities and deliverables for each member of the team. These teams exist for the duration of the product lifecycle or service delivery lifecycle and are then dissolved and reassembled in a different form based on the customer and market needs.

Governance

There are three levels of decision making in a typical Agile governance model:

Strategic decisions focused on market positioning that determines which capabilities the organization wants to develop to successfully compete
The Investment Tier decisions made by a cross-functional group of organizational leads based on economic trade-offs of pursuing certain capabilities/service offerings
The execution level decisions delegated to individuals or working teams

What is efficient is the structure of the governance committees and the transparency into the individuals/groups who make the decisions. The need for nimbleness in the Agile governance model is focused in the Investment Tier. The ability to dynamically assemble the right cross-functional team to make the Investment Tier decisions requires commitment from the whole organization to making these decisions quickly with all the right leaders having a voice in the decision making. You can read more about the Agile decision-making model in my previous blog post – Achieving Decision-Making Excellence Through an Operating Model Transformation.

Processes

Process is an operating model element where standardization is key to efficiency and speed. For the core processes, e.g., Amazon’s supply chain, the sequence of steps, ownership, handoffs, and decision rights are clearly defined and understood, allowing the company to measure current throughput and estimate future expectations. Variability across business units in these core processes make the level of harmonization needed for Agile delivery impossible, making standardization essential. Flexibility comes in with process improvement, especially in areas where cross-functional input or handoffs occur.

Conclusion

The move to an Agile model requires the stable underpinnings of primary organizational alignment, a transparent governance model, and standardized, measurable processes. This backbone allows for the flexibility needed to assemble dynamic teams, make quick, cross-functional decisions, and redesign processes for efficiency. The critical element to enable this Agile operating model is a clear strategy and priorities for the organization and the mindsets and behaviors to also shift the organizational culture.

Teaching OKRs to Executives w/ Andrew Young

Thu, 04 Jun 2020 09:25:28 GMT

This week in LeadingAgile’s SoundNotes, we’re focusing on Objectives and Key Results. Andrew Young joins Dave to talk about this history of OKRs, why they have become such an important part of how we track and measure performance, why they matter to Executives, and why teaching Executives about OKRs requires a very specific approach.

Want more on OKRs?

Contacting Andrew Young

LeadingAgile: https://www.leadingagile.com/guides/andrew-young/
LinkedIn: https://www.linkedin.com/in/atyoung/
Twitter: https://twitter.com/exclamation101
Email: andrew.young@leadingagile.com

Contacting Dave Prior

If you’d like to contact Dave you can reach him at:

LeadingAgile: https://www.leadingagile.com/guides/dave-prior/
LinkedIn: https://www.linkedin.com/in/mrsungo
Twitter: https://twitter.com/mrsungo
Email: dave.prior@leadingagile.com

If you have a question you’d like to submit for an upcoming podcast, please send them to dave.prior@leadingagile.com

When the Team Says, "We Don’t Need to Plan.”

Tue, 02 Jun 2020 10:17:25 GMT

When a team does not keep rigor, discipline, and quality in making the work-ready, it doesn’t just impact that team – it impacts all the dependent teams and ultimately the return on investment. *The team names have been changed to protect the learning, but the learning needs to be shared.

The mobile team is a nimble team. Why wouldn’t they be? They’re running with full continuous deployment and the latest technology, so they get to brag – they are Agile, right? In fact, they built their entire backend in Node.JS microservices—a technology no one else in the organization uses. They aren’t like the other teams in other product lines.

Occasionally the team is reminded of this when they have to interact with the other team’s burden with monolithic software that’s older than the newest member of the mobile team. But the mobile team is able to push through this by jumping the line – their Vice President has influence, she’s a rising star.

The team is so confident in their practices, they decided they don’t need to plan anymore. In fact, they sent the scrum master to release planning with some gibberish features and continued to code – because in their mindset, planning isn’t coding, and coding is what experimenting requires. Hasn’t everyone read the Lean Startup?

When the Product Owner arrived with a high-value feature for marketing initiative with a date, the team was proud to pivot and work on that feature. The team normally doesn’t commit to dates, but this time overconfidence allowed them to assure marketing that this was possible and encouraged the marketing team to build the campaign and buy the ad space.

With an impending set of features, the team made a unanimous decision to run like a start-up, and they willingly worked late into the night. This set of features was much larger than any other features that had been previously experienced – but in the team’s mind, it would be the same. It was decided to plan a week at a time and flow it through the Kanban. Having rarely planned previously, these conversations were ad-hoc and chaotic, and that fact reminded the team why they didn’t plan.

At the first week of planning, they realized the need to access the critical data feed for the monolith, but not being sure what it was – they punted it to the next planning period to discuss. It was forecasted, it could be figured out on the fly, so it was punted two more planning meetings.

In the fourth and last perceived period of planning, the contract from the monolithic system was finalized. The information from a specific green screen would need to be accessible via a REST call. The conclusion was that it had to be simple, it was just an API endpoint. Something that could be done in Node.JS in a few hours. In anticipation, the contract was stubbed out the endpoint for testing – all that had to be done was for the monolithic team to write one simple REST call. The team pushed the entire codebase to production, toggled off of course, and verified it worked. They were ready to launch, an entire month before the marketing push.

All that remained was asking the monolithic team to write a simple API. They’d be done in a few days, and they’d all be proud of this work. Because they had nothing else to do, as a team – they climbed the starts up to the monolith team space and spoke with monolith Product Owner laying out the contract. The Product Owner understood the ask—it was clear—and then stated, “Unfortunately, it would be ready in 6 months, if made a priority”.

This is when the shouting began. The mobile team Product Owner started to explain how important this feature was, the campaign, the media buy, and how the entire team had worked heroically on the work, and this wasn’t going to stop them.

The Product Owner of the monolith responded with empathy, but stated – “We’re integrating into a new ERP system, and that work is the highest priority, it’s on the CIO’s bonus plan. Plus, we are tightly coupled with the vendor, and they release once a quarter. The next quarter of work was tied up with ERP migration, and the next opportunity is six months away, and any work the mobile team needs to be completed must flow through governance to ensure it aligns to the global strategy.”

The mobile team left in anger. The marketing initiative would not be scrubbed. All of those extra hours heroically working into the night. Nothing will stop the marketing features.

Like normal, this should be escalated to the Vice President who can fix anything, she has influence. Oddly, the team was excited to tell their Vice President with influence about what the outdated monolith team did to them, and the company. Surely, she’d be able to fix it, she had done this before, why would now be different? The team decided to swing by the director’s office.

The mobile team Product Owner said, “Once again – the other teams are too slow to keep us with us, and we can’t do these awesome things that are important to the organization.” The Vice President responded wanting to help, took the details, and committed to the team that this would be resolved after her one-on-one with the CIO that afternoon. One small detail that was absent from the conversation with the type of work: the ERP.

In the one-on-one, the VP brought up the challenge with the high priority marketing features. Clearly, understanding the importance of the work, the CIO asked what could be done do to help? The VP asked, “Can you prioritize this work with the monolith team so that we can meet the date?” The CIO responded, “The monolith team that’s working on the ERP transition, that I committed delivering the COO and CFO last year?” The VP replied quietly, “Yes”. The CIO responded with, “Now I need to call the CMO.”

The rest of the details of this story are not important, but the learning is. The System of Delivery will only move as fast as your slowest dependency, and you should plan 2x-3x on your horizon to mitigate and schedule out of those. The governance model must be used to set priorities across product lines to prevent this waste. And if those dependencies become an organizational bottleneck – subjugate to it and remediate it.

Simply Having Agile Teams Does Not Make an Agile Organization w/ Dragos Dumitriu

Thu, 28 May 2020 09:40:40 GMT

Getting a few teams up and running using Scrum, Kanban or some other form of Agile is great. But that doesn’t necessarily mean your organization has become Agile.

This week in SoundNotes, Dragos Dumitriu joins Dave for a conversation about the difference between spinning up a few teams and truly achieving business Agility. During the conversation Dragos shares details on some of the common patterns, he sees when organizations begin moving towards an Agile approach, things to watch out for, and some of the conversations you need to be having internally if business agility is something your organization has set its sights on.

LeadingAgile · Simply Having Agile Teams Does Not Make an Agile Organization w/ Dragos Dumitriu

Contacting Dragos

Web: https://www.leadingagile.com/guides/dragos-dumitriu/
LinkedIn: https://www.linkedin.com/in/dragosd/
Twitter: https://twitter.com/thewaitlifter
Email: dragos@leadingagile.com

Contacting Dave

Email: dave.prior@leadingagile.com
LeadingAgile: http://www.leadingagile.com/guides/dave-prior/
LinkedIn: https://www.linkedin.com/in/mrsungo/
Twitter: http://twitter.com/mrsungo
Personal blog: http://drunkenpm.net

We Need Reviews

If you like this podcast, we’d be very grateful for reviews or feedback in iTunes. It will help us create more visibility for this podcast so that we can reach more people. Click here to leave us a review or post feedback.

Feedback/Questions

If you have comments on the podcast or have questions for the LeadingAgile coaches that you’d like to have addressed in a future episode of LeadingAgile’s SoundNotes, you can reach Dave at dave.prior@leadingagile.com

LeadingAgile CSM and CSPO Classes

For information on LeadingAgile’s upcoming public CSM and CSPO classes, please go to: http://www.leadingagile.com/our-gear/training/

Use the discount code: LA_Podcast to receive a 15% discount on the class.

Agile Infrastructure Transformation and TBM

Tue, 26 May 2020 10:27:29 GMT

When I first thought of writing this article, I struggled with how best to talk to these perceived different approaches. Questions of how does Agile apply to infrastructure and what does TBM have to do with Agile were in my mind. A simple google search reveals just a slim number of articles and these are mainly based on the theory of how these concepts come together vs. real-life learnings.

Let’s start with some basics. What is TBM? I have had exposure to TBM in a past organization and the driver and my perception was that it was about IT Towers to assess costs and consumption related to infrastructure spend so that the organization could leverage benchmarks and “defend” our costs. My experience is that in a TBM implementation that is driven by a CTO or even a CIO in a defense mode (“Why are your costs so high?”) is a more than common approach, but falls short of the value and intent of TBM.

TBM is a model and taxonomy that at its most basic level does understand and map costs and consumption. But the intent is to elevate the discussion with the business related to value and trade-offs as you understand what is driving costs. So instead of having a defensive conversation with a CFO on why something costs so much, we are having a discussion related to what is needed and then can understand the costs related to supporting those business needs. TBM also seeks to link the long-term support costs beyond a project since once a project is done there are ongoing run costs that are part of the TCO of a product.

The TBM Taxonomy

One example I experienced around the value of Total Cost of Ownership. A prior CTO gave an excellent explanation of what it looks like to truly understand TCO. At the time, I was leading a group that was responsible for Application Portfolio Management and assessing risk, value, and cost for all of our applications in the company. The CTO told me he wouldn’t be surprised if we found applications with low value and high costs that we needed to retire or replace. He related an extreme example where a company had an application that had been in place for several years and was put in place for parking lot reserved space management for the company. Over time it became used for only the executives in the company. After a detailed TCO analysis they found that they were spending over $1M per year on this application in TCO (costs to manage, support, and run the application). Having this information enabled a conversation on options – one of which was to hire a person to manually run the function. See where this is going? A shift to a product focus.

Product Focus

As we look at recent thinking around Agile, there are more and more articles on a shift from Project to Product, flow of work, and value-streams. This is where TBM and Agile align. It starts with the need to fully understand a value-stream for a service or product from a customer (internal or external) and how we encapsulate the people needed to deliver on that need. Understanding the costs and consumption of that service so that we make sure we work on the highest value work is part of the role of a traditional product manager and aligned to TBM. A TBM model and related tool will assist in that cost and consumption transparency so that those discussions can be informed with data.

Agile in Infrastructure

As I work with more organizations, I realize that many have made great progress with Agile in software development areas. I spent quite a bit of time with part of a large infrastructure and ops group (over 2000 people and $1B of spend) in re-educating them in how the fundamentals of Agile applied to them as well. Many large, bureaucratic companies suffer from being too slow, perceived as too expensive, not transparent, and can’t make the changes needed to improve.

Challenges such as Conway’s Law get in the way of optimizing the end-to-end value stream. Conway’s Law showed through research and experiments that “Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization’s communication structure. “ — Melvin E. Conway.

Applied to a Lean-Agile approach and internal processes, the results are seen in many organizations today. Take for example getting a group of people that all have a role in a process and get them in the room to optimize the process. If you have 10 different groups represented, you will likely have a ten-step process – where each of the 10 steps has been individually improved. This is because no one wants to opt-out, they risk feeling like they are not important, or that their job function related to that process is waste that can be eliminated. If you start with a value stream aligned structure with one leader of the end to end process it is much more likely you will have an optimized end-to-end process.

Visual of Conway’s Law

Many companies spend money to automate and create VMs or IaaC as an example, but the software teams are still frustrated, and the business areas don’t see the benefits of these investments. As an example, the company will have automated the build of a server, but the end-to-end process is still not optimized. When we apply Agile in Infrastructure, we start with a view of who the customer is, and then look at the flow through the system and what we need to encapsulate to reduce these silos and dependencies.

I was once asked by a CIO to explain why it took so long to get a server when we had automated the solution. We had spent money on software and people to be able to provision an environment and claimed credit for reducing the time from days to minutes. However, the software team’s experience was related to the end-to-end results, not just this part of the process. The end-to-end piece included approvals, firewall changes, funding, financial management. and other steps. I told the CIO that my team needed a production environment and had value-stream mapped what happened. I told her that the end-to-end process involved us submitting 22 different request tickets which generated 30 tasks went to 12 different teams to get all of the pieces in place for a usable server environment. This process took over 90 days for something that took less than an hour of work because of all the hand-offs and wait states between the different teams. The managers of these teams had optimized their siloed part of the process, but no one in the organization owned this end to end process for the customer.

End to End Processes

Where Agile for Infrastructure and TBM Align

Agile for Infrastructure and TBM align several ways. Agile is all about maximizing the value delivered for the organization and being able to adapt to change. TBM enables visibility to that value, costs, and consumptions so that portfolio-level decisions are enabled. It also aligns costs from IT Towers up to these services that are needed to support the organization. Agile provides the System of Delivery that supports the value decisions enabled by TBM and aligns the structure to reduce silos and dependencies to increase efficiencies by reducing waste.

So where do we start, and how can we solve for these challenges?

The key is that we leverage the principles that enable Agile to work, which we call The 3 Things: teams, backlogs, and working tested software/product.
We design an organizational structure to reduce dependencies. We make sure that we better align to our customers to create a fast feedback loop.
We collapse silos and create cross-functional teams We shift more work to planned work as we get closer to the customer and get out from behind ticketing systems.
We truly understand costs, consumption, and performance so that we can make data-driven decisions to accelerate business outcomes.

Teams, Backlogs, and Working Tested Software

In one organization where we applied our approach, we first addressed the structure and consolidated some of the silos and enabled cross-functional teams. These new teams now had the key skills to perform the fulfillment of providing a server and were each aligned to a portion of the organization to create a better and closer feedback loop vs. trying the serve the entire organization. We couldn’t completely collapse everyone into one team as there was a balance needed. But we were able to remove many of the silos. By collapsing these silos and streamlining the processes, we were able to reduce many of the hand-offs and wait states. Over time we can get more lead time on the customer needs and shift more of the work to planned work. The result of these changes was a more than 50% reduction in cycle time, simplification of the process to the customer (fewer steps, tickets, etc), and cost savings from reduction in the number of people needed to deliver the same volume of work.

Achieve Decision-Making Excellence within an Agile Operating Model

Mon, 18 May 2020 12:30:44 GMT

Our clients who are newly transitioning into the cyber-physical and/or software-focused space, often struggle to set up an ecosystem that will allow them to not only make efficient decisions, but also effective ones. Organizing for success is a critical part of LeadingAgile’s Define the End State activity, wherein we help our clients determine the right operational model (product-centric or capability centric) and which sets of teams, called Expeditions, need to be sequenced based on business impact in their respective progress toward what we call Basecamps 1 through 5. During the pilot Expedition, the progress made by the sets of teams towards their desired Basecamp (across the delivery, product/program, and portfolio tiers), often exposes the challenges in the Investment Tier.

The Investment Tier within the LeadingAgile model acts as the translation engine between strategy and execution, and this governance model allows executives to achieve “decision-making excellence.” What do we mean by this?

Strategy focuses on market positioning – determining which capabilities the organization wants to develop to successfully compete and what offerings need to be developed to take up the capability gap. Aligned to those set of clearly sequenced longer-term (horizon varies depending on the organization and associated industry) strategic priorities, are short-term priorities that require investment decisions. This translation of strategy into execution falls under the purview of what LeadingAgile refers to as the Investment Tier.

The Investment Tier includes a cross-functional group of organizational leaders who are responsible for decision-making across the economic trade-offs of pursuing certain capabilities and their associated service offerings. Part of the challenge that organizations face, is not being clear about the types of decisions they are making, and how an effective Agile Transformation model can help them in this regard.

Decisions that are high-risk, and which either shape the future of the organization or require orchestration across multiple, interconnected groups, can be made effectively and efficiently through the support of a robust governance model, which is rooted in the creation of organizational alignment first (long-term strategic priorities), followed by decision-making. Decisions made at the Investment Tier include areas such as new product launches or operations and sales planning, requiring input from a wide range of functional groups and the orchestration required to bring these groups together to provide input at the right time.

The stability of long-term priorities and clarity of decisions made in the Investment Tier allows organizations to manage the execution priorities (delivery, product/program and portfolio tiers) as a “backlog” of decisions that are delegated to the individuals or working teams.

The key to this model is having clear accountability at different levels of decision making and making a majority of the decisions at the individual or working teams, with a clear escalation path to Investment Tier and Strategic decisions. When bad decisions are made, rather than re-examining the decision-making structure, reinforce the structure and accountability. This is also where learning and feedback loops can be leveraged to course-correct as needed and in order to decrease the perpetuation of new initiatives that detract from the focus required to execute. This decision-making model is only effective when all levels across the organization reflect the company’s strategy and priorities.

Training vs Transformation

Thu, 14 May 2020 11:05:51 GMT

Training is a vital piece of today’s business climate. It’s typically at the forefront of conversations around development or growth, but what is the correlation or connection between training and actual business transformation? The assumption has been that if my employees only had the knowledge, they would produce different outcomes. While training is an undoubtedly valuable piece of creating large, organizational change, the outcomes that our organizations produce are highly intertwined with a number of factors on which training has very little impact.

In this episode of SoundNotes, LeadingAgile Training Consultant, Nathan Hummel joins Dave to discuss the role training plays in organizational change, how it impacts Agile transformation, and, what else, beyond training, an organization will need to see true lasting change.

Contacting Nathan

Web: https://www.leadingagile.com/guides/nathan-hummel/
LinkedIn: https://www.linkedin.com/in/nathan-hummel/
Email: Nathan.hummel@leadingagile.com

Contacting Dave

Email: dave.prior@leadingagile.com
LeadingAgile: http://www.leadingagile.com/guides/dave-prior/
LinkedIn: https://www.linkedin.com/in/mrsungo/
Twitter: http://twitter.com/mrsungo
Personal blog: http://drunkenpm.net

We Need Reviews

Feedback/Questions

LeadingAgile CSM and CSPO Classes

For information on LeadingAgile’s upcoming public CSM and CSPO classes, please go to: http://www.leadingagile.com/our-gear/training/

Use the discount code: LA_Podcast to receive a 15% discount on the class.

From Order Taker to Opportunity Maker…IT’s Digital Transition for Driving the Business

Tue, 12 May 2020 10:13:32 GMT

Here are some fun facts:

The first company founded to provide software products and services was Computer Usage Company in 1955.
Professions such as Medicine, Law, Beauty, Teaching, Transportation, Security, Accounting, Engineering, and Project Management all have one thing in common; certifications and internal governance.

Almost shocking to think about how much younger the IT profession is in comparison to the other professions. Even more mind-bending is to pause for a moment and reflect on how much technology has advanced in such a relatively short time frame.

Think of all the breakthrough advancements in just the last 20 years in the medicine, transportation, accounting, and engineering professions. It’s absolutely astounding.

Now, think really hard and attempt to discover if any of those advancements were possible without leveraging technology? Any?

Let’s face it, IT has historically accepted the role of the “order taking – behind the scenes” group hidden from society. For many years, there has been a clear division between “the business” and IT.

Now here we are, amidst the new era; waist-deep in Digital Transformation and yet many still haven’t quite connected the dots; folks – nothing can be done without IT.

It’s fascinating to think that IT, the youngest of all the professions is leading the digital transformation revolution. Now more than ever, IT leaders are being called upon to move past partnering—and start driving the business.

A business-partnering IT organization is the order taker, and it’s this model that has fueled the thinking that over half of IT organizations are still regarded primarily as a support function, not a strategic organization. IT leaders have suffered the fate from the business perceptions of “IT takes forever to get things done,” eroding trust and ultimately perceived that “IT expenses have become a cottage industry that achieved full cost transparency.”

A business-driving IT organization, on the other hand, is the opportunity maker. IT leaders driving the business are working with (not for) other leaders to continuously deliver value, manage on-demand, architect process change for business growth, becoming strategic advisors, and navigate through technology changes.

Making this transformation from an order taker to an opportunity maker has not—and does not—come easily. However, when done right, it will radically unlock the potential of your company.

It takes more than a few Scrum teams to solve the Transformation puzzle. It involves more than just IT. It requires the entire organization.

At LeadingAgile, the Transformation journey starts by focusing on predictability. Teams delivering on a predictable cadence earn the trust of the business. Pretty soon, business and IT leaders join forces to orchestrate dependencies and implement Lean pull systems. This keeps the teams fed with smaller batches of work and moderates the work in progress. As the Transformation scales, leadership ensures that appropriate clearing and conditions are upheld:

Form Complete Cross-Functional teams at ALL levels of the organization. (Delivery-level to Leadership)
Manage the flow of work, balance capacity against demand, and ensure teams have a well-groomed backlog of work at all times.
Hold Teams, as well as overall organization, accountable for producing a working tested increment of product on a regular cadence
Aggressively manage dependencies and help the organization break dependencies over time. Dependencies always limit business Agility.

Over the past few years, IT leaders and executives have become savvy. They clearly understand the importance of not just Agile Transformation, but more so broad-scale organizational that leverages Agility.

What this means is that clever CIOs and IT leaders influence investment and portfolio tiers to ensure priority and alignment are stabilized and streamlined. Successful Transformations that take the necessary steps to holistically engage the entire organization’s broad-scale Agile Transformation ensure that investors and senior leaders are committed to spanning strategy, value creation, and value delivery.

IT leaders that are driving the business are privileged to establish strategically aligned objectives and support key results, contributing to the creation of opportunities to grow the business, encapsulating and organizing value creation and delivery portfolios, baselining capacity and course-correcting to ensure the supply and demand mix are realistic and creating product and service key performance indicators to better understand performance in the market.

Business drivers have the ability to seize the opportunity of broad-scale Agile Transformations and formations as decision-makers. They co-create the Supply Mix and Demand Modeling, setting the table for alignment, prioritization and encapsulation. They work across the business to understand Impact, Confidence, and Ease scoring is applied so that ideas, initiatives, and objectives may be clearly communicated and understood quickly. They share in the conduction of Risk & Asset Allocation analysis in order to provide for optimizing and sound decision making. Last but not least, business drivers continuously leverage Value Proposition modeling; looking through the lens of the customer to gather invaluable information for creation, delivery, alignment, and return.

IT has come a very long way in a short time, especially during these past few years. Successful Transformation efforts that are sticky and get deeply rooted:

Are aligned both horizontally and vertically; Holistically aligned to stretch across the business and positioned to grow vertically; engaged ownership throughout the organization from top to bottom; Investment, Portfolio, Program and Team environments are synchronized for success.
Position IT as a business driver and opportunity maker.
Ensure there is clear alignment and that prioritization is tightly coupled with highly encapsulated systems of value creation and delivery.
Include Agile investors and senior leaders that are committed to spanning strategy, value creation, and value delivery.

IT and Business leaders… get out in front of your digital Transformation. Make the change from order taker to opportunity maker; drive the business together.

At LeadingAgile, our Investment and Portfolio Tier Transformations create the Agile state for better business outcomes. Let’s build something amazing together.

LeadingAgile

Predictability and Adaptability Live in Tension

CapEx and Agile Transformation w/ Justin Polk

Listen to the SoundNotes Podcast on the go!

Contacting Justin Polk

Contacting Dave Prior

Increasing Enterprise-Level Predictability With Agile

How Much Predictability Do We Need?

The 3 Things You Need for Team-Level Predictability

Complete, Cross-Functional Teams

Backlogs

Getting to a Working, Tested Product

Obstacles to Predictability

Dependencies

Backlog Problems

Predictability at Scale

The 3 Things at Scale: Structure, Governance, and Metrics

Structure

Governance

Metrics

Team Level Agility is Insufficient for Enterprise Level Agility

Closing Thoughts

More On This Topic

Leveraging Agile to Improve Quality

Paving the Way for Quality with Agile

The Impact of Agile on the System of Delivery

More on This Topic

Remote Work and PSTIR w/ Jeff Howey

Listen to the SoundNotes Podcast on the go!

Download the White Paper

Contacting Jeff Howey

Contacting Dave Prior

Cultivating the Kind of Culture Employees Crave

Our Cultural Hypothesis

Defining Culture

Defining LeadingAgile’s Culture

Executing on Our Cultural Hypothesis

But, Wait. There’s More…

Parting Thoughts

Leveraging Agile to Get Predictable

Transcript

Trust vs. Trustworthiness w/ Yaton Bowens

Listen to the SoundNotes Podcast on the go!

Links from the Podcast

Contacting Yaton Bowens

Contacting Dave Prior

When Being Nice Isn’t Enough w/ Rich Dammkoehler and Joel Norman

Listen to the SoundNotes Podcast on the go!

Rich and Joel on Twitch

Contacting Rich

Contacting Joel

Contacting Dave Prior

Using Earned Value with Agile w/ Justin Polk

Listen to the SoundNotes Podcast on the go!

Links

Contacting Justin Polk

Contacting Dave Prior

Getting Hired in Agile w/ Priya Sethuraman

Listen to the SoundNotes Podcast on the go!

Contacting Priya Sethuraman

Contacting Dave Prior

Selecting and Running Agile Pilots w/ Justin Polk

Listen to the SoundNotes Podcast on the go!

Contacting Justin Polk

Contacting Dave Prior

Unveiling the Agile Operating Model

Organization

Governance

Processes

Conclusion

Teaching OKRs to Executives w/ Andrew Young

Listen to the SoundNotes Podcast on the go!

Want more on OKRs?

Contacting Andrew Young

Contacting Dave Prior

When the Team Says, "We Don’t Need to Plan.”

Simply Having Agile Teams Does Not Make an Agile Organization w/ Dragos Dumitriu

Listen to the SoundNotes Podcast on the go!

Contacting Dragos

Contacting Dave