LeadingAgile

Multiple Product Owners With Competing Priorities w/ Jeff Howey

Fri, 08 Jan 2021 06:20:18 GMT

“How do you coordinate work across multiple Product Owners within a single organization when they are all working on different parts of a larger thing, the PO’s have each been given different priorities, and they are all competing for the same resources (people)?”

That question came up recently in one of our Certified Scrum Master classes and this week in SoundNotes Jeff Howey joins Dave Prior to talk through the different “opportunities” this scenario presents. As they unpack the different facets of it they offer suggestions and ideas that could help the organization cope with it, and, ideally, introduce changes to alleviate some of the things causing this situation to exist in the first place.

Contacting Jeff Howey

Email: Jeff.howey@leadingagile.com
LinkedIn: https://www.linkedin.com/in/jeffhowey/
Contacting Dave Prior

Contacting Dave Prior

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/

Agile is More Than a Mindset

Mon, 04 Jan 2021 10:30:01 GMT

Though it’s helpful to have the right mindset when you want to be an Agile organization, actually achieving Agility is going to require more than adopting a mindset or creating a culture.

Transcript

What’s the operating model that’s going to enable those leaders to behave in the way that we want them to behave? And somebody says, and this is like a really common thing, agile is a mindset. Right? And if you’ve been following my stuff for a long time, this is a little bit of a trigger for me. I’m just warning you, right? So, this idea that agile is a mindset. The other thing that you see quite often is that agile is about culture. Okay? Both of those things are true, but not like primarily true.

The reason why people want to talk about agile as a mindset, is because like we’re going in and we’re saying, okay, we don’t want our leaders to be command and control, and we don’t want our leaders to micromanage and tell the team what to do. And we want our leaders to be open, and adaptive, and responsive to change, okay? And while all of that stuff is true, and all of that stuff feels like a mindset shift, what’s underneath every single thing that I talk about it’s like what you have to do if you want to change mindset. It’s really kinda two things, right? You have to enable the systems that enable different behaviors. And I’ll say behaviors and attitudes, okay?

And one of the examples that I like to talk about it’s like, if you want sales people to cooperate with each other, right? You can’t put them in the same region with competing financial objectives, right? Cause if they’re incented to behave in their own best interests, and they’re compensated to behave in their own best interests, getting cooperative behavior that results in them working against their best interest is not necessarily reasonable, right? So if you want to change a sales person’s mindset to be more collaborative, you have to create an incentive system that enables that level of collaboration.

So if we want to ask our leaders to deliver, or be less command and control, right? We have to put the team into a situation where they don’t need as much structure to achieve the same objectives, right? So, what I’ve been finding myself saying in a lot of different contexts, is that we have to build the systems that perform the way we want them to perform, and then we have to educate our leaders, or our business partners, or our market to exploit that system to their economic advantage. So if I want, you know, it’s a little bit like what we about in the physics of agile stuff, right?

So if we want our leaders to trust the team, then the team has to be trustworthy. Okay? And so, I just wanted to hit that first, because I know a lot of times the things that I’m teaching about and our point of view as a company, they center around things like structure, and governance, and metrics. And the inevitable response with a lot of agilists is to say, well, no, agile is not about that. Agile is a mindset.

Well, all I’m really gonna say is that almost everything that I’m talking about is what are the structures, organizational governance strategies, what are the metrics and controls? Like, what’s the operating model that’s going to enable those leaders to behave in the way that we want them to behave, okay? So that’s like almost every single thing we talked about.

Building a System Where Agile Can Thrive

Thu, 17 Dec 2020 21:03:02 GMT

Transformation is really about forming teams, building backlogs, and producing working, tested product. At scale, it’s about defining structure, and creating governance, metrics, and tooling strategies that support Agility.

Anything that gets in the way of doing any of these things is an impediment to Transformation. But the actual work of the Transformation is getting rid of all the organizational things that get in the way of doing that—and to do that, you need the right system in place, an ecosystem where this can happen.

Teaching people the basics of Scrum and telling them to self-organize, except in possibly the smallest of organizations, isn’t going to lead to Agility. Most companies will need more guidance.

If we define it as a culture problem or a process problem… we fail.

If we recognize it as a systems problem… we have a shot at fixing it.

In the absence of simply telling people to self-organize, where do you start?

Understand where you are and where you want to go.

Agile fails because the underlying preconditions that must be in place for organizations to get the benefits of Agile are not clear. Luckily, creating the conditions necessary for Agile to thrive in an organization is a science that can be understood, planned, executed, and measured. We need the right systems in place that provide enough structure, accountability, and transparency that good business decisions can be made at the lowest appropriate level.

As the overall understanding of the underlying mechanisms of Agility increases, and real impediments are removed, dependencies are broken, business Agility will improve across the entire enterprise. But it all goes back to having a system you can trust. Because Agile, implemented only at the team-level doesn’t work.

Biological Systems, Organizational Systems, and Catalyzing Change w/ Matt Craig

Thu, 17 Dec 2020 15:20:22 GMT

In this episode of SoundNotes, Matt Craig joins Dave for a discussion that centers around comparing the way biological systems and businesses function and respond to change. In a biological system, enzymes bring elements together that catalyze reactions and keep iterating until they find an effective response. (Think of the body’s immune system learning to fight off a cold.) At LeadingAgile, our coaches and consultants serve in a similar manner helping to catalyze change within our client’s organizations. Matt is a Principal Consultant at LeadingAgile and he specializes in strategic and sustainable organizational health and improvement. But his background also includes the study of medicine and this has led to compelling insights into the parallels that exist between biological and organizational systems and how they respond to foreign elements and change.

Contacting Matt

Web: https://www.leadingagile.com/guides/matt-craig/
LinkedIn: https://www.linkedin.com/in/mattiasc/
Email: Matt.Craig@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 on 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.

Keeping Life-Critical Decision Support Applications Shippable

Thu, 10 Dec 2020 06:00:52 GMT

In an earlier life, I coded several different life-critical applications that aided decision support in complex domains. Domains where a mistake could result in people being injured or dying. As the code was written, new use cases were discovered. What if there is a 2,000-pound baby with kidney failure? Is that a typo or a real thing? What if the scientist in the lab did not follow the formula as described? What if, what if?

Naturally, the fear of harm slowed development due to an abundance of caution. The qualified clinicians and scientists could describe scenarios fantastically, and always prescribe a solution. We would record each scenario or use case in the following format:

Given these INPUTS when WE DO SOMETHING then RETURN THIS MESSAGE

As the product was developed and new use cases were discovered, the clinician would always have an answer. For example, even the 2,000 Pound Baby scenario resulted in a prescribed solution.

Given a 2,000 Pound Baby when prescribed ANYTHING then return “Ask a qualified clinician.”

If all the inputs could be discovered, it could be codified into the correct set of outputs. As the product matured, a pattern started to appear – all edge cases followed the same algorithm. Any patient or scenario in which we did not have clarity on the solution would result in asking clarifying questions to the clinician or scientist. All edge cases followed this same pattern, then I realized – all cases followed this pattern, a default use case, “Ask a Qualified Clinician.”

Given ANY INPUT that doesn’t meet any other input criteria when WE DO ANYTHING then return “Ask a qualified clinician”

If the first use case or scenario had been, “Ask a Qualified Clinician” and carefully coded the other exact scenarios, we could have theoretically released daily since the “Ask a Qualified Clinician” scenario would protect us from the “What if, what if” scenarios.

This was our first step on our pathway to keeping our Life Critical Decision Support Application always shippable. A future post will talk about carefully coding the other exact scenarios. And like all good decision support systems, before you adopt this practice, “Ask a qualified clinician in your organization and domain.”

The Right Way to Think About Cost Savings with Agile

Wed, 09 Dec 2020 10:13:03 GMT

Cost savings is a tricky subject with Agile. But it’s not because Agile can’t impact cost savings. It’s because Agile has very little impact on direct and immediate cost savings. The problem is, most people think the wrong way about how to save on cost with Agile. They usually say Scrum is how they realize cost savings—but they’re missing something.

To watch the full webinar on how Agile adoption can reduce costs, check out the Key Business Drivers of Agility on-demand webinar series here.

Transcript

In its simplest form, like why shouldn’t you think about Agile as a cost-savings tool? Well, the problem is with thinking about Agile as a cost-savings tool, is that most of the organizations that we walk into are are legitimately 10 X over subscribed. I mean, it’s absolutely insane what most organizations are being asked to do. You know, you go through and you do this kind of annual planning cycle and you have all this stuff, you have all these objectives and OKR’s all this different stuff, and you’re trying to run it through an organization that just is not capable, in reality, of being able to do that. So a lot of times the challenge becomes is like what do you do when you legit need to save money?

But the problem is, is that you’re super overloaded. So, just to kind of give you guys a little bit of a hint of, I think where this is going to go, is the right conversation, I believe, is that what we have to focus on are things like throughput, getting things in market as fast as we can, making sure that we’re focusing our delivery dollars on the highest value things we can possibly do, things that are most likely to yield return on investment, things like that. And if you can do that with the existing staff, that’s great, and so, but sometimes, you know, we’re out of balance and so sometimes it’s like redeploying staff and getting people into the right seats or getting some of the wrong people out, some of the right people in. So there’s like, there’s like a like a big efficiency play, but like cost savings is like really, really difficult to promise.

And so what I want to talk about a little bit to start off with those kind of hypothesizing a previous hour, like how would I start to tell the story to you guys? And so where I thought it would start are what I kind of see as a few anti-patterns. So there’s a belief, there’s a belief, it’s almost like a Dilbertesque belief that Agile, just by virtue of doing Agile stuff, right, so by virtue of doing Agile process, that we’re gonna save money. So our challenge is to unpack a little bit why, but as we do that, right, this belief is, is pretty pervasive, right? So it’s almost like if I send you to Scrum training and you start doing the Scrum ceremonies, you start having the Scrum rolls, right. So we’ll do a daily standup meeting, that kind of a thing, then somehow that’s going to magically like solve the problem.

So what we see in practice, right, the simplest thing is that we have this hypothesis this belief that Scrum is going to save us this money, so we train everybody on Scrum. And then we do like really crazy things like fire all our project managers, or we get rid of all of the architects, right, ’cause Agile doesn’t do architecture. That’s not true, but that’s like what a lot of people think. Or we realize that we think Agile is going to flatten our organization by default, so we let go of all our middle managers or something. I mean, you guys might be laughing on the inside or maybe you’re cringing because you’ve experienced it. But people do stuff like that, right? And so what ends up happening is you have this big, complex organization that hasn’t really fundamentally gone through a transformation, it’s full of dependencies, lots of orchestration costs to try to deal with those dependencies. You teach that organization’s Scrum and then you remove all the costs associated with orchestration, but the dependencies and things like that, that are in place that necessitated that orchestration didn’t actually go away.

So it’s like we spend the dollars to teach people Scrum, and then we save the dollars by letting people go, and we ended up on the backside, not with cost savings, but with a more chaotic environment than we had before. People get frustrated, say Agile doesn’t work so they throw Agile out. But the reality is, is that Agile wasn’t the problem. We prematurely tried to reap those benefits before we had created the ecosystem where those benefits could be realized. Okay? Another thing that we’re seeing, and I’m going to anchor this back to a talk that I think I launched in the market about eight years ago called “Why Agile Fails,” but another thing that we’re seeing quite a bit with some organizations are going into, usually like a lot of times we’ll follow behind another consultancy or something like that, or maybe it’s a failed Agile implementation and they like our approach to trying to figure this out, so we come in behind somebody in one of these things.

And a lot of times what happens is that somebody decides, and I don’t know what the, exactly what I want to call it, but somebody basically decides to create some sort of like green field pilot. So they do this, right? So they go on, they say, “okay, we’re going to do something in a totally new business with really open requirements. We’re going to give it total autonomy over the tech stack. We’re going to give it a total dedicated team.” Right, all this stuff, right. They’re going to basically create like all the conditions for Agile to be successful. And they’re inevitably doing it in something that’s built on new technology, mobile web, right, some distributed system kind of architecture, things that really lend themselves to service orientation, all that kind of stuff. And so we’re gonna do a pilot, right, and that pilot’s going to be really fast and it’s going to be really efficient, and it’s going to use some variant of Scrum XP, Lean Startup, right, something like that, right.

So the hypothesis becomes is that because we used the methodology that is what drove the efficiency and the savings. The reality is, is that it was actually the new business, open requirements, ownership of the tech stack, continuous integration deployment, good architecture, dedicated team. These were the things that actually led to the efficiency play. So like what we’re seeing is we’re seeing is that like an organizational will come in here and any organization has some percentage of new stuff, innovative fast stuff, and then organizations have some percentage of legacy stuff. And so what will tend to happen is you’ll carve off a piece of this and you’ll do your pilot and it will work really good, right, because we know Agile works if you create the conditions to do it well, and then we’ll say, “Oh, okay.” So we’ll take that hypothesis, we’ll come and we’ll train everybody else on Scrum and we will cut 25% out of the staff.

Well, the reality is, is this legacy stuff, we didn’t create the conditions for to get those efficiencies, so what we ended up doing is we have this really shining star example of something that worked and we have this really bad example of where it didn’t work. So going back to the themes, right, some of the physics stuff, right, if we don’t create the right levels of encapsulation, if we don’t figure out how to break dependencies, we can’t alleviate the orchestration costs. And so we save the money, but we don’t get the organizational improvements we want. So this is why I think this is like a really, really dangerous conversation to have.

An Agile Approach to Personal Development w/ Mike Cottmeyer

Thu, 03 Dec 2020 10:30:38 GMT

Dave Prior sits down for a conversation with LeadingAgile CEO Mike Cottmeyer and they explore Mike’s Agile approach to personal development and dig into the details of how and why his approach to growth and development has evolved over time.

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

Encapsulation vs Orchestration: Dependencies in Agile

Tue, 24 Nov 2020 10:42:28 GMT

Dependencies will stop Agility dead in its tracks. In the presence of dependencies, you’re never going to achieve the level of Agility you desire—unless you do something about them.

So you only have two choices when it comes to this. You can either encapsulate the dependencies within the team or within the value stream, or you can orchestrate them. Another way to say this is that you either must break the dependencies, or you must manage them.

Either way, if you have dependencies, you cannot pretend they don’t exist.

The Assumptions of Scrum

So, what does Scrum say about dependencies? It assumes you don’t have them in the first place. And if you look at the way that Scrum is architected, you’ll notice that it assumes a lot, including that each team:

Consists of six to eight people
Focuses on a particular business problem
Owns its technology stack
Has a singular input
Has a singular measurable output

In effect, Scrum assumes that you have encapsulated teams that can address any dependencies internally by self-organizing around the ceremonies of Scrum. They can then either resolve or prioritize dependencies in real-time to ensure that the team can deliver on their commitment by the end of the Sprint.

But what happens when the dependencies are outside the purview of the team?

The Reality of Scrum

Sadly, the reality for many large organizations is that when forming teams, it’s all too common for a select person or people to be jumping between multiple teams.

For example, a QA person is spread out over six teams. That’s six Sprint Planning sessions, six daily standups, six reviews, and retrospectives. At that point, there’s no room for QA work.

Each team then has to make sure that person is available to them when they need them to do the work. They’re no longer instantly available to that team, which means the team now has planning dependencies and coordination dependencies. There’s a dependency between one project and another based upon either project’s ability to stay on track.

Theoretically, you could have two teams that meet most of the criteria of an Agile team. But if you have only one QA person straddling the fence between two groups, you also have a dependency, and that’s going to limit the ability of both teams to achieve Agility.

Any time we inject a dependency into the system, we create something that has to be managed outside of the team. And that limits our ability to be Agile.

Failure Modes of Other Popular Methodologies

Many methodologies have acknowledged that dependencies are real and have come up with various ways of addressing them. But it doesn’t matter which methodology you choose because they’re all just ways to orchestrate dependencies at the end of the day.

Here is a closer look at how some of the most popular methodologies, Scrum, SAFe, and LeSS, can attempt to manage dependencies, yet usually still fail:

Scrum of Scrums

At one point in time, Scrum came up with this idea of Scrum of Scrums. The idea is that you have some number of teams, each with their own ScrumMaster. At some point, usually at the beginning of the Sprint, all the ScrumMasters meet up to coordinate the dependencies in real-time. This is a valid construct that works under some conditions.

The problem is that when you have two teams with a dependency, and you’re trying to mitigate them in real-time, you end up with late resolution of the dependency. And that tends to destabilize the velocity of the teams. When the velocity of the teams become destabilized, you end up unable to make and meet commitments.

A lot of organizations put buffering strategies into place, like setting aside extra time to deal with known dependencies. But it becomes very ad hoc and hard to manage as you try to scale the system. So, while Scrum of Scrums is a fine communication tool, it’s not a good strategy for eliminating dependencies.

SAFe

SAFe suggests that you need Program Increment (PI) Planning. Basically, you’re going to have some sort of early “big room” planning session on one end of the PI Plan and a closing ceremony on the other end. In the middle, you’re going to deliver features on some kind of cadence.

When you do an early planning meeting, the idea is that everyone’s going to get in a room and address the dependencies in advance, at least to some reasonable level of assurance. But they’re going to understand those dependencies at the beginning and hopefully front load them so that they can resolve the dependencies sooner. Or, if they’re going to fail the PI, then at least they’ll know that sooner and can pivot or reprioritize.

Where SAFe struggles in large organizations is when you have something like a banking platform. This platform is responsible for things like ACH processing transactions, reconciliation, bill payment, etc. Typically, these platforms are dealing with incredibly high volume, large, robust mainframes, and super-fast transaction processing.

Imagine if you have four products, each with seven to ten SAFe teams, and each value stream is potentially injecting dependencies into the platform So, what you’ve done is simply moved the dependencies one degree out. You haven’t done anything to break them. They’re still there, and they’re still limiting your ability to be Agile.

What if the dependencies are encapsulated within the value stream? If that’s the case, SAFe might work for you in your situation. But be on the lookout for the presence of dependencies to make sure that’s always a true statement. Because if you have value streams that intersect, meaning that you have dependencies across value streams, you might not have your value streams set up right.

Or maybe you do, and these dependencies actually exist, and you’ll need to manage them across value streams.

SAFe typically is set up with a 4-tiered governance model. But that model only works if each layer is orchestrating the dependencies for the layer directly below them. And that level of orchestration gets expensive, and you wind up with a hierarchy of teams.

Dependencies are not your friend. Even if you get to a place where you can effectively manage them.

LeSS

LeSS talks about team-level execution and the way it rolls up into bigger things. But to do a LeSS implementation, you’d have to have a tremendous amount of encapsulation at the team level and a very minimal amount of orchestration as you go up.

So, how would LeSS address dependencies?

Well, let’s say you have a few front-end teams and a few backend teams. You might have a PO team who is decomposing and sequencing the work across these teams and who’s operating off a dependency-aware backlog.

The PO team starts loading all the teams up with Feature 1 items. Then Feature 2 items. But where it gets interesting is when you get to Feature 3 and not all the teams have work to do on that Feature. What do you do with teams that don’t have work, yet have capacity? Do you move them on to Feature 4? If the teams that don’t have capacity for Feature 4 work, you can’t.

So, you wind up in a situation where each team can either be a bottleneck or starved for work. The inclination is to load up the teams that have capacity with non-value-added work just to keep them busy, but that’s probably not the best use of their time.

Ideally, what you’d want to do is move the capacity to the bottleneck. But, in reality, this often isn’t reasonable due to the distribution of skills across teams. The skills of one team might not apply to the work the other teams are doing.

So, why not just collapse them into one complete, cross-functional team that can service all the components?

What if the backend is in Cobol and the front-end is in .NET? You’d have a multiple technology problem.

On the other hand, what if you’re in an environment where it’s not just about technology and skillset, but the work is also mission-critical and can never break?

When you get into these pure-play LeSS environments where any team can touch anything, you have to ask yourself, do you have the right level of test-safety? Can you continuously deploy it? Can you be sure that it’s never broken?

Do you have the right architecture in place, the proper organizational alignment to operate this way, and do it safely? If the answer to any of these is no, then you have dependencies.

Compensating Controls

As you can gather from what you’ve read thus far, dependencies are a real thing that organizations are dealing with. And after seeing some of the common failure modes of the most popular methodologies, hopefully you’re starting to see that while most of them are attempting to address this issue, not all methodologies work in all environments. So, what do you do when your methodology of choice doesn’t prescribe a course of action for your particular environment?

To be truly Agile, by definition, you have to have encapsulated teams. That’s the ideal state, but it’s also probably not your current reality.

And if it’s not your current reality, then you know you need to manage the dependencies, but a lot of people don’t like that because it doesn’t feel very Agile.

So, there’s this tension that organizations are feeling, and they’re asking themselves what can I do about it?

The answer is you have to put some sort of compensating control in place. What’s a compensating control? A compensating control is any orchestration mechanism you implement on top of your chosen methodology to help you get to your desired end state.

How Agile Do You Want to Be? And How Quickly?

Understanding where you are today vs where you’re going and acknowledging that dependencies are going to get in the way means that your Transformation journey isn’t about implementing a methodology that’s too heavy for your future end state, or establishing a set of compensating controls that are going to hinder your Agility in the long term.

Instead, your Transformation journey is about creating the right conditions today that will help you begin incrementally and iteratively creating the right conditions for tomorrow.

The reality is that none of this Is going to happen overnight. But, knowing where you want to go and having a plan for the interim, allows your organization to decide which dependencies are worth the money to break. There will surely be dependencies that may never be worth the money to break, or aren’t economically viable enough to break.

So, you’re going to have to do something on top of your methodology to ensure you’re reaping the benefits of the methodology until it becomes reasonable to break the dependency.

When you start to view your Transformation through this lens of encapsulation v orchestration, you begin to see that each methodology is just a different way of attacking the same problem at varying degrees of heaviness.

As you begin to strike a balance between encapsulation and orchestration, you might realize that your ideal end-state is some sort of multi-methodology environment that depends on the needs of the teams and its application.

Either way, once you’re in this mindset, you can start to make better decisions to get you to your desired end-state, and you can make strategic decisions about which dependencies to break. Meanwhile, you have controls in place to maximize Agility in the parts of your organization where you still have dependencies until it’s time to deprecate those controls.

Organizational Impact of Dependencies

An organization that doesn’t understand how to balance encapsulation and orchestration doesn’t have a viable way of managing or resolving dependencies. So, they inevitably wind up doubling down on methodology as well as team-level and work-level practices. And they end up not being able to deliver on the other fundamental building blocks.

Because when you have unmanaged dependencies, you’re not going to be able to establish a stable velocity at the team level, so the organization isn’t going to know how much demand to put into the system, so the net effect is that the organization is going to overload it.

And when you can’t know the teams’ ability to deliver against the known backlog, it makes it very hard to make informed bets and tradeoffs as we go based on the known capacity of the system so that we can level the demand against it.

Then we get to the point where the teams just aren’t trustworthy, and so the organization has a hard time trusting them. Many Agilists say that we need to trust the teams, but what we really mean is that we need to put the team in a position where they can be trusted. This primarily means that we have to create the right conditions for them, which means we have to create an ecosystem in which they’re encapsulated.

Dependencies kill Agility, So, you have to either find a way to encapsulate them within the team or find a way to orchestrate them.

Agile Unplugged EP04 | Mike Cottmeyer and Matt Van Vleet

Tue, 17 Nov 2020 10:00:13 GMT

Welcome to our latest episode of the Agile Unplugged podcast with host Mike Cottmeyer, LeadingAgile’s CEO. In each episode of Unplugged, Mike and a special guest explore LeadingAgile’s freshest ideas, mental models, frameworks, and solutions with the people that are actually doing the work of leading large-scale Agile Transformation in the real world.

We’ll hear about Matt’s background and reveal our roadmap for building the new LeadingAgile Studios, our newest offerings to enable clients to use their capabilities to gain the strength, Agility, and craftsmanship to take on digitally native organizations in the marketplace.

Remember to subscribe and listen to Agile Unplugged on Soundcloud, Apple Podcasts, Spotify, and Podbean—and watch each and every episode on YouTube, IGTV, and Facebook.

Transcript

– Everybody welcome. We are doing a LeadingAgile Unplugged and I have a special guest here, Matt Van Vleet. Welcome Matt, how are you doing?

– Great.

– Yeah. Awesome. So Matt just recently joined us. He is helping us build our technology transformation studio. And we’re gonna explore a little bit about what that is going to look like. And, but what I want to talk about a little bit is, let’s just talk about your background. Like what have you been up to for the last 10 years since we worked together?

– Yep. Yeah, so I, I spent about 18 years at Pillar and eventually sold the company to Accenture. And in that we grew the company where originally, we did a mixture, as you know, between transformation and building custom software solutions. Over time, we grew to focus more, mainly on customer soft, custom software solutions, and eventually Accenture purchased us. And then I was, helped for a couple of years and in that transformation and getting them up to speed on what we did and I was out exploring what to do next and we reconnected. So—

– We reconnected, yeah. So we first worked together, I guess it was probably back in like late 2009, 2010. I had joined Pillar for a little bit. ‘Cause that was when Pillar was thinking, that I guess I wanted to be a transformation company.

– Yeah, one of the challenges we had is we wanted to do, be a transformation company, but a lot of what we did was from the bottom up and we really weren’t in position to affect some of the things we needed to, for transformations to be successful. We could affect in our, in our pocket. So we could set the conditions so that we could deliver a great product, but it wouldn’t continue to change the overall organization without being engaged at the right level of the organization.

– So let’s explore that a little bit because that was actually one of the things that I struggle with a little bit back in that time was trying to figure out because I’ve been, as everybody probably knows, like super passionate about this space of transformation and trying to figure out how to get companies from A to B and really always kind of took what I called, like a top down, bottom up approach, right? Where you have to have engagement at the lower level, right? But if you’re not doing it with like executive support and with an integrated strategy from beginning to end, it’s really difficult to sustain momentum. Talk to me about some of the challenges that you had taking it straight from a software development perspective.

– Well, when you’re trying to build software and the software we were building was, was very innovative and kind of leading edge for organizations. So sometimes when you were on the proper project, you could get some of the dependencies and constraints or some of the rules, you know, waived for your project, which is great for certain projects. But if the, if you’re always breaking the way the organization is designed in order to effectively write software, then it’s very hard for it to be sustainable. So things like, you know, dependencies on other departments or groups where we may have been allowed to do that work ourselves and just review it with them, that wasn’t standard operating procedure or our project was important enough that it had the funding set up such that it could make decisions around where to move and how to do things in the marketplace without needing to fit into the overall portfolio directly. There were a lot of exceptions that were needed in order to put software out quickly.

– Interesting. So basically if you tie it back to like the talk that I gave, what seven, eight years ago, “Why Agile Fails and What You Can Do About It”, one of the things I hypothesized was that one of the reasons why Agile was failing in a lot of transformations was because you would do this thing off to the side and you’d give it all of the conditions that needed to be successful, dedicated teams and a ton of autonomy over what to build and the ability to really massage it’s CICD pipeline or get all the different things in place and then wrap it in Scrum or XP or whatever. But then when you took those practices back into the rest of the organization, they would actually fall apart because you didn’t have all those exceptions that you were talking about.

– Right. And so, you know, ultimately, there were a lot of needs for those types of projects. So we were very successful and grew and so forth, but that’s why we somewhat got out of the transformation business because in the end we were great at building software and we weren’t engaged at the right level with the right expectations in order to change the way organizations were structured or the way those processes worked by default.

– So it’s interesting. So, on the other side of that, so when I left Pillar and started LeadingAgile, we approached it from a pure play transformation perspective. I wasn’t actually trying to help anybody get better at software development per se, or product management per se. That was kind of part of it. But we were trying to help people figure out how to form teams and how to get backlogs and governance aligned and to be able to just even, conceptually get to the place that you could produce a working test and increment of software. So I think where this is kind of interesting is that we kind of hit a wall, right? So in our model, we talk about base camp one, base camp two, three, four, and five. And we got really, really good at getting companies to base camp two. And we could do some of the things that you guys did around base camp four and five, but getting people to bridge through two to three to four, by breaking those technical dependencies actually became quite a bit of a challenge.

– Right, and I think, you know, as you talked about it, there’s this, you need to balance the top down and the bottom up and in base camps, one and two, the bottom up are more like, you know, getting predictability and getting, you know, batch sizes down. So they’re more the management type practices than they are the technical practices.

– [Mike] Yeah.

– And so now, the technical practices need to come much more into the forefront from the bottom up perspective, as you’re going to base camps three, four, and five, because those dependencies aren’t just organizational, they’re software and some of the tasks around how do you refactor code to break dependencies, or how do you automate build pipelines are pretty complicated things for our clients, but they need some help and support in doing the first time so that we can then help them accelerate their transformation to those higher base camps.

– Yeah, it was actually kind of interesting because, you know, we would hit the market and we would talk about base camp one, two, three, four, and five and then a lot of our focus would be around base camps one and two. And so the kind of, the first aha moment was we actually had worked with a couple of clients long enough to where they’re like, “Okay, now base camp three, base camp four.” And with base camp three, we realized that there’s actually quite a bit of technical runway that had to be established. And then with base camp four, there’s quite a bit of product runway that had to be established. And we actually tackled the product side first. And so we started to build a product practice within LeadingAgile and started pulling some of those core skills that we needed for base camp four into base camps, one and two, and started laying the foundation for that. So talk a little bit about the kinds of things in an early stage transformation you might want to lay the foundation for. So you can do some of that technology refactoring once you get past base camp two.

– So when you’re thinking about base camp one, and you’re wanting predictability, there’s a set of practices that give you that predictability. You know, if you’re trying to produce work in tested software, first of all, do you have an automated build? Do you have a build pipeline that’s getting you things between environments smoothly? Are, you know, are things being done the same way from a technology, just basic standards perspective? Then as you’re trying to get to smaller batch sizes and in the base camp two, there’s a lot of things where if I do it twice as often, or if I’m doing it five times a year, instead of once a year now I’ve got to look at that overhead costs and reduce it. So anything that I’m doing manually, that’s not value added and getting the value density of the software up, I need to look at it as waste and say, “Well, right now me moving between environments, “I only do it three times a year. “The fact that it’s manual is not that big of a deal. “If I’m doing it every day, every week, every month, “now I need that automated.”

– Yeah.

– And those are technical practices that are the foundation for some of the higher level technical practices that we need in base camps, three, four, and five. So as we look at applications or products that are needing to move to those higher base camps, we’ll engage in some of the fundamental technical practices in the earliest stages of transformations to make sure those teams are prepared to keep moving up the base camps.

– Well, so talk to me a little bit about, because you know better than most that it’s much easier to build it right the first time than it is to kind of refactor it and to try to get it into a state where you can do some of these more advanced deployment kinds of things. So what kinds of skills have to be established within the team to get to the point where they can start to break the dependencies and start working on encapsulation?

– Yeah.

– So, you know, so the basics end up being that we have an automated build and automated scripts to move things between environments. And then we’re starting to look at test automation, where I want to make sure that what I’m doing doesn’t break something that used to work. So taking an area of the system that I now want to be able to work on independently so that, you know, every team or every need doesn’t have to go through the same team. I want different teams to be able to work on different parts of the system. I need to wrap that area of the system with some tests, with some source of truth, to make sure that I know that I didn’t break what used to work. One of the things we’re going to do in the studio, is do some of that initial work where we can split up the application, we can put those tests in place. And that kind of gives a blueprint for teams to now know how to take that going forward. Because one of the hardest things to do is to take a legacy application, find the seams in it, find the ways to break that architecture and make it more componetized, find a way to get those tests in place because it wasn’t designed to be testable.

– Right.

– So we’re going to take some of that heavy lifting and take it off of the transformation teams so that they can continue to learn and grow. And our technical coaching, that’s in the team room will help define and, get the organization ready to take that now, that new application with reduced dependencies to take that on and continue to move that forward for future development.

– So let’s explore that a little bit. So if you think about a LeadingAgile engagement, like one of the things that we start off with is an engagement called Define The End State and really what we’re thinking about during that stage is we’re looking at the business architecture of the organization. And we’re looking for alignment between what I might say, like the business architecture or the technology architecture and the organizational architecture. I want an encapsulated business problem, an encapsulated technology solution and a dedicated team. Right, so you talked about the seams in the organization. So like early on, we’re actually looking for the seams in the organization, so we can start grouping people around dedicated business problems. So, so what, you said something that was kind of fascinating. So it’s like, while the, while that part of the transformation is happening, then the studio’s practice is going to start going in advance and start to do the decoupling work on the backside. Like, explain that to me a little bit, what you had in mind there.

– Yeah, so, what tends to happen right, is your application ends up looking like your organization. So if you have an organization that has a front end team, a middle tier team and a backend team, then your application is going to be focused on that. Instead of if you have your organization focused on business areas where you may have one overall solution that needs to solve, you know, payment issues or, or pricing, or what have you. So a lot of times when we’re going into the transformation, we want the payment team and the pricing team to have everything they need to be successful. But the applications weren’t designed such that the payment people could be changing their part and the pricing people could change their part. And there’s not a whole lot of coordination of those in between that. So what we want to do is first get a foundation in place where the things like builds and deployments and versioning are automated, so that if one side changes their piece, the other side doesn’t have to be in lock step, that the application can be deployed and built. And then we’ll validate that what used to work on one side still works so that teams can now work independently. So as we reorganize the organization and refactor the organization around these business areas and value areas, we need to make sure that the application infrastructure and the environment is set up to support that. And that starts early on by getting some of the underlying technical craftsmanship, you know, practices in place. And then as we reach those higher base camps, you know, we can help prepare the applications to do that.

– Yeah, very cool. So this isn’t a new concept for us. Back in, we’ve actually had studios on our website since about 2015, right before we did our Collective Soul Concert in Atlanta. Mentioned we ever did a collective soul concert in Atlanta? One of my best moments in my life. So Google might Mike Cottmeyer Collective Soul and you’ll get to see me doing some awesome guitar reffing on stage with those guys. That was a lot of fun. But we kind of hypothesized this. So we hypothesized studios, we talked about a training practice. We talked about a talent practice. We’ve talked about actually a media company, and we’ve talked about labs. Those are some things we can explore in a little bit, but we’ve been noodling on this for a long time. And so for the last couple years we’ve been bringing in technical coaches working on the team room. How do you see these studios offering that you’re going to help us build advancing past where LeadingAgile’s been over the last couple of years?

– Yeah, I look at the technical coaches that are working directly with the teams and the studio as providing kind of a one-two punch. When you’re in the team room, you understand the process, the application, and you’re mostly about helping the people transform. The studio can help the environment and the code be transformed. So the output is going to be, you know, more testable code or more, less code with less dependencies, or what have you. And the challenge is, is that, you know, ultimately a lot of what we do at LeadingAgile is we teach people to fish, but you can’t teach people to fish if they’re starving. So the studio can help get some of the things done, make sure that the business is continuing to get value, that these things are broken up. And, you know, one of the dichotomies you run into is the hardest type of code to work on when learning these new practices is legacy code.

– For sure.

– That it wasn’t designed and has these dependencies in it. So if the studio can help break those dependencies, get it in a state that’s better, in a better shape than the technical coaches are going to have a more successful time when they’re doing things like mobbing and other things with the teams to help the teams get better. The teams are going to not have to learn, they’re not gonna have to start with advanced calculus, right? The hardest thing to do while they’re trying to learn some basic algebra, right? The teams are gonna be learning algebra, or they’re going to be learning how to do these practices and tasks and so forth, but we need them to do it in an environment where they’re set up for success.

– Yeah. Cool. So talk to me about why this is so difficult. Why don’t teams do code like this naturally?

– It’s interesting. I think—

– [Mike] That stump you?

– Yeah. Well, you know, teams are more and more, so a lot of these practices, you know, we’ve been doing them for years, but a lot of them, they’re not as old as the software industry. So it took a while to really figure out, like, you know, the automated unit testing and the refactoring and so forth, to get those into the mainstream of how people built software. I’d say like an automated build pipeline, if you look at, you know, new teams being formed, it’s almost like, it’s like breathing to have an automated build pipeline.

– Yeah, sure.

– It’s like, it used to be that having a compiler that would build your entire application was an optional thing. And now people, like would never think of like building code without a compiler that was real time, or what have you. New teams, would never think to not have a build pipeline anymore. Like and it’s, so it’s more and more common with green field applications. But now you’ve got these teams who have really valuable software that’s been out there for 30 years and it keeps getting, growing and solving new problems. And it wasn’t designed from the ground up with some of these things that you would do today, if you started it. So it’s hard, now you’ve got to go retrofit that while you’re trying to add new value to the organization. And it’s just a specialized skill to help them get caught up.

– So this might be a little bit of a rabbit hole. I want to see where this goes. One of the things that I think about a lot, and I don’t think about it just with code, but I think about with organizations, and in any kind of like systems of people or what have you, but I don’t think most people think like architects and I know in Agile, a lot of times we don’t necessarily talk about having architects, although a lot of us do, right? Do you think the principles of encapsulation, the solid principles, things like that, do you think those are well understood and like deeply internalized by a lot of developers out there?

– Now you stumped me again. No, I think, you know, one of the interesting things is that if you build software the way we advocate, right? You know, it’s test driven. There’s a test around it. So ultimately we want is any component you build to be self validating, and, so that if one team changes it, they can know whether they broke something that used to work.

– Yeah.

– Ultimately building software that way naturally forces you into those solid principles.

– Okay.

– Right, so, those principles end up becoming an outcome based on how you build things.

– Ah, fascinating. So what you’re basically saying is that when you build using the, like the software craftsmanship kind of things, using TDD and continuous integration deployment and such, that you naturally get an effect encapsulated standalone modules?

– [Matt] Right.

– That’s how I’m thinking about, yeah.

– ‘Cause you can’t test a module if it’s dependent on everything else in the organization. So it kind of forces some of those things, but instead of needing to learn all of them and then do that, if you really fundamentally, as a team embrace some of the automated testing, automated builds, like, you know, kind of a microservice architecture or a similar architecture, those things are going to become, you know, you’re naturally going to implement some of those things.

– Cool. Interesting. So, you talked about the idea. So, now we’re dealing with systems that are not built that way, right? They weren’t built from the ground up and now you’re looking for seams and ways of breaking them apart, so you can begin to wrap them in tests. Is that an art or is that a science?

– I think it’s a little bit of both. So it takes people with experience to do it, at times, but ultimately knowing that, you know, what we tend to teach people is you can’t just go look at a million lines of code and say, “Well, let’s just spend the next year “writing tests.”

– Yeah, sure.

– So if you just take a disciplined process to say, whenever something changes and I need to make a major change to it, I’m going to go in there and make that area more testable. And I’m going to put those automated tests there and I’m going to explore that area of the code, or whenever something breaks. So whenever there’s a defect, I’m going to create a test to repeat that defect and then implement it. What happens is that over time, you’re going to end up with the most tests in the area that it is that you’re changing the most, which means you are investing in them or that break the most, which means you need to get them more solid in the, that investment self prioritizes. Now, so that type of a process and an approach, building that into your organization, I think is a bit of a science, right? We can lock that in. Now, over time, people get more and more experienced of figuring out, right, now that I need to test this because I’m making a major change or because it keeps breaking, what’s the best way to do that? And that, you know, some of those things you need experienced people, especially when it’s, when it’s, you know, legacy code, that could be pretty complicated.

– So why is it hard to do the people side of transformation and the technology side of transformation simultaneously with the same group of people?

– Well, ultimately, you’re trying to take a person, you know, it’s like teaching someone how to walk on the moon on the moon.

– Okay.

– Right. You know, you’re,

– I have no firsthand experience with that one, Matt, so yeah.

– Neither do I, so maybe I, ultimately there’s some, fundamentals to go, “Okay, well, let’s, “let’s help the teams get uplifted “and let’s look at the constraints and make sure “that we’re not trying to have them solve a problem “beyond where they’re at.” It may be a problem that only needs to be solved once for the organization, right? So once your application is split up and some of those technical dependencies are removed, you don’t have that issue going forward. So sometimes, rather than trying to take my team and teach them all of this heavy lifting of how to split it apart, it may be better to just get someone to split it apart, so my team can focus on creating businesses modules.

– So the group that’s being transformed doesn’t necessarily need to learn how to split the code, do the legacy refactoring, they just need to know how to maintain it after it’s already been split apart. Is that what you’re saying?

– I would say maintain it, but then if it’s a base camp three or four or five team, it’s enhance it and add lots of value to it.

– Continue to extend it using the same principle kind of a thing.

– Right, yes. Extend it using the same principles. So, you know, ultimately this is in a sense, a one time effort that I need to break it apart. Now, a lot of organizations have a lot of these legacy code bases, but for a team or a set of teams that need to work on an application, we can help get it split apart and then let them focus on, how do I build and enhance this code going forward using these practices so that it never ends up again, back in the state it was in.

– Okay, cool. So as you’ve been hypothesizing this, has been working together to define this offer. So there’s four areas I recall that you think that you’ll see LeadingAgile evolve into.

– Over time, there’s a different set of problems. We’ve been talking a lot about coming along side of transformation and helping with technology uplift. So we would help, you know, break dependencies, add tests, or what have you. There are times where clients are gonna come to us and say, “I have this base camp three, four or five problem. “I just need a team to build this application “because I have to get it done. “And I don’t want it to distract my transformation, “but I want to make sure that whatever’s built, “won’t have the issues I have in some of my other areas. “So one is I just want value delivery. “The second is that technology uplift. “The third is really a team uplift. “So, we have a team that has a certain level of capability. “There’s some of the practices that we’re doing “that aren’t once a week things “that you need to learn to do, or once a month things, “they’re things that change “how you write every line of code.” And for those getting into an environment or a dojo where I can then, learn how to do those things, working against real code with a real business problem is an effective way to build up those things. And then the fourth is the technical coaching. Again, providing that one, two punch that says, “Great, you’re giving me an application “that now has reduced dependencies, that now has tests, “but I have an existing team “that needs to know how to build on that “and needs to know how to build new features.” I don’t want to just provide this application into there. And then I could have atrophy where it just gets, like the value goes away because we didn’t learn the practices along the way.

– So, basically it’s like, it’s like everything from, okay, we’ve got this one offer over here that basically says, you guys are over here transforming. We’re going to help you build stuff in the right way. And then we’ve got another piece that is okay, we’re going to help you split this apart so that when your team is ready, that we can, they can continue it forward using these solid practices. And then it’s like, we’re going to develop the skills within the team so that they can sustain it. And then it’s like, we’re going to work side by side with you coaching along the way to help you actually do it. Is that a good summary of it?

– Yeah.

– Yeah. Okay. Awesome.

– And I think that’s kind of, what I’m actually interested in, so that ultimately it’s very hard to move to these higher base camps, especially with an existing set of applications and we need to provide that wealth of things, right? It’s actually interesting back in 2015, when you prognosticated the need for studio and these other practices or business units, what was the thinking about how that all would fit together? Is this kind of going down the direction?

– Yeah. Well, so it’s kind of fascinating, right? You really have almost have to go back to like my early days. Like when I launched out, so prior to working with you at Pillar, I was at Version One and I had this idea that I wanted to go out and be an independent Agile coach, right? And had no idea, right. ‘Cause I’m not, I mean, a degree in computer science, right. I’ve written code, I understand code, understand architecture and things like that. Like I’m not a guy that can go actually like do this stuff, right? And so in the early days of this, like I was, you know, out solving problems that I was qualified to solve, candidly, which were mainly around organizational design, project management, governance, right. And what I would do is I would spend a lot of time with teams back in the early days when I was on the ground coaching. And I would say like, “Look, you guys have to be able “to do a build every day. “You have to be able to get the testers integrated. “You have to be able to write unit tests. “You have to be able to do these things.” And what I found was that for the teams that I was working with is that most of the time they knew what they needed to do. And they knew how to do these things. They just needed permission, just needed time. They needed ground cover and things like that. And so we probably spent the first four or five years building LeadingAgile within that frame, that as long as we create the right conditions for the developers to have permission to do these kinds of things, that they would do them, right? And then as the company grew and the size of the engagements grew, right, and we’re trying to do this thing at scale, even sometimes thousands and even tens of thousands of people, what you start to recognize is that not everybody actually has those skills and sometimes permission wasn’t sufficient. And so what we started to think about, or what I started to think about is if we were going to become a full service change management transformation company, we had to have the methodology for change, right? So a big part of what LeadingAgile has built over the last 10 years, isn’t really a better, deeper understanding of Agile, what we’ve done is we’ve built a better, deeper understanding of change management and how to orchestrate change and how to create safety for change and how to measure change. Because one of the big things about our engagements is that we can walk in and we can say, “Here’s the kinds of changes we’re going to make. “Here’s the hypothesis on that return on investment. “Here’s the leading indicators that demonstrate “that we’re moving in that direction. “Here’s what you want to measure “in terms of lagging indicators. “And this is how all that’s going to translate “into business results, right?” And so, and so what we started to find is as got better and better at telling that story and doing that kind of work, the barriers to actually getting those measurable results, as you might imagine, are in the technology transformation and uplift side. And then, and actually, and on the product management side, some of the base camp four stuff, because what we were really good at early on was helping organizations unlock their delivery pipeline. So, you know, there’s this challenge it’s like, when you can’t build anything, is the conversation, are you building the right thing or can you build anything at all? And so base camp one and two in practice in the early days ended up being a lot of, “Okay, I’m not trying to tell you what strategy. “I’m not trying to tell you what to build, “I’m not trying to tell you what your customers need, “I just want to unlock your ability to build anything.” And we got a lot of companies to where they could build stuff really predictably, but they were building some of the wrong stuff, right? And then, so we moved into the product space and then it was like, well, we know that in order to be able to move faster, they’re going to have to unlock some of these technology problems that we had kind of punted down the road a little bit. So that was what was going on in my head at the time. It was this evolution and what the market was showing us was that there was indeed a need to be able to unlock. It was like gridlock in these organizations, right? To get rid of the gridlock. But then once you got rid of the gridlock, you know, the constraint moves and it moved into some strategy conversations, some product conversations, some technology conversations, sometimes it was training and skills transfer conversations, sometimes it was change management communication conversations. It was all over the place. And so the market revealed to us that this is what the next step was. I think we took the right first steps in those early years, but it became really, really clear. And so why the gap between 2015 and 2020? Well, it was like, we just took off. It was like, we started getting large clients and we doubled the size of the company. And it was like, there were so much of the base camp one and two work that really difficult to get the right level of investment and intention in doing some of the technology stuff and the product stuff necessary for four, five, three, four and five. That makes sense?

– Right, yeah. Makes lots of sense.

– Yeah, so it’s kind of funny, right? It’s like, you know the answer to the question at the beginning, but you have to kind of, we’re a very agile company, right? So you have to go to market with what you can do, right? You have to go to market with what the customer is willing to buy from you. And then the market tells you what’s next. Right? And it was really kind of a funny thing. It was like, when you were wrapping up your last gig, we were just at the place where we were encountering some of these challenges in a real way. And it was very timely, you know, to be able to take this leap during this COVID shutdown and all these different things. And yeah, it was just very timely, the way it all came together because I think we’ve gotten so effective at getting companies started and moving and into base camp one, base camp two, and we had danced around the base camp three and four problem enough, that it just got really, really crazy clear that now was the right time to go do all that. So, welcome.

– So no pressure.

– You got a big job ahead of you, man. You got a big job ahead of you.

– Exactly.

– Cool. So let’s talk a little bit about the offer, right? You’ve been thinking about this quite a bit. So one of the things that I’ve really appreciated is as you’ve joined us, is that you’ve really kind of snapped a grid, right? You said you’ve gone to school on all my talks and presentations and things like that. So you’ve been walking our team through this, why, what, how, who kind of framework? So talk to me a little bit about why. Why studios, why now from your point of view?

– Well, and when I talk to people about why for an organization, there’s always three components of it. So why for LeadingAgile and we just covered a lot of that, right? We understand what we’re wanting to do. So why for our clients? You know, again, some of those constraints that are preventing them from getting the higher base camps and some of the unique constraints when you’re, when you’ve got a lot of legacy code that some of the digital native new companies don’t have. So that’s a big why for our clients. And then there’s also a why for our people.

– Well, so why don’t they just go build it themselves? I mean, we talked about this a little bit, but let’s just put a fine point on it. Why wouldn’t they just go build this capability themselves?

– You know, some can, but there’s, you know, there’s a lot of, of work and know-how to know how to build that. And a lot of what we do is help build that capability for our clients and help them get there. But in the end it will become a capability that they have, and we will be an extension of that capability when they need it.

– Cool.

– And then why for our people. You know, we have technical coaches, who are great on doing that technical coaching, but they also would like to move into building things and creating once in a while. Our great consultants like to do three things. They like to create, they like to learn and they like to teach. And if they’re only in a teaching mode, then where do they learn, right? And letting great technical people move between a studio context and a coaching context without even leaving the organization, I think is a great why for our people.

– So let me just see if I can summarize, right? So, we talked about how LeadingAgile needed to fill some gaps in our mission of being able to be a world-class transformation company, right? So we realized that unless we closed this particular niche in the market, that we weren’t going to be able to realize our full brand promise, right. And then from the client’s perspective, sometimes it makes a lot more sense to have somebody help with this aspect of it, because it’s not something that they need to do forever. It’s something that they need assistance and kind of a heavy lift. And then once everything’s refactored, split apart, you know, test harness continuously integrated and deployed, then they need to have the skills to maintain it and to evolve it. But they don’t necessarily need to make the investment in their people for the heavy lifting. And then the last bit, right, is a little bit about us and our people and having the ability to move across these domains and make sure that everybody’s skills are fresh and that people are doing what they love. And they’re able to engage in a lot of different aspects of the things that make work fun to do.

– Yeah, exactly.

– Yeah, cool. Awesome.

– And then kind of when you go from that why to the what, and we touched on this, so in order to solve those problems for clients, we need to have those four different capabilities, right? We need to be able to help a client, just get something built when they need it. We need that to be able to help them transform their technology environment, to make it a more conducive to these types of base camp three, four, and five team needs. We need to help their teams get to a position where they know how to build on top of these code bases, as well as extend them and maintain them. And then we need that coaching, that gets there on a daily basis to help get those things successful during the expeditions that the teams are going on.

– Cool. So, loaded question. What do you think we can bring to the market that makes us different than anybody else? Like why LeadingAgile?

– The number one thing is to having the things integrated into the model, right? We don’t just decide that everyone in the organization needs to get to the same level, right? We talk about base camps and different base camps have different outcomes. And some of those outcomes can be better achieved by having these technical practices in place, and helping solve and affect the metrics or the outcomes. Right, so, so this integrated offer that helps, you know, large organizations look at, where do we need to make change, prioritize the investment in those changes, align both the organizational aspects, like government, governance and funding and so forth. What’s the technical aspects that need to change, and being able to do that, you know, within one system of transformation or one system of delivery, I think is a huge advantage.

– So let’s talk about that a little bit, ’cause that actually will dovetail probably nicely into the, the how conversation, right? So, one of the things that I think has been a really awesome advancement of the last couple of years is that we’ve made a clear distinction in market between what we call a system delivery, right? And for everybody listening, that’s like what you expect. That’s like SAFe, scaled, Agile, right, kind of things, LeSS, what have you. So basically, if you look at the operating model of the organization, the end state organization, we call that a system of delivery. And so we have patterns and we draw from a lot of things. We’re not really in bed with say for lesser, disciplined Agile delivery or anything like that specifically. But we draw from the same core patterns in market. And then we coined this thing, we call the system of transformation, which is really around how do you get from point A to B, right? How do you start down the path? And so we have, we have a define the end state where we work out a lot of the business architecture and governance and dependency issues and tooling issues and how we’re going to measure and think about during the transformation, how we’re going to spin up an Agile transformation office, how we’re going to measure progress. One of the key innovations that we made a couple of years ago was something we called outcomes based planning. So every, whether it be a define the end state or whether it be like an expedition to base camp one or two, we have predefined outcomes that have to be achieved really rich activity level guidance. It’s amazing how repeatable actually moving an organization through these states is, right. And so what did it gives us the ability to do is to call our shots and to basically say, “Okay, “we’re going to take this organization to base camp two. “We’re going to take us next organization “to three or to four. “And here’s all the intermediate outcomes “that have to be achieved. “And this is the roadmap, and this is the playbook “for how we’re going to do those things.” And what it gives us the ability is to do is to say, “Okay, there’s a coach on the ground “or an organization we’re working with. “Here’s the activities that are going to lead to an outcome. “And these collections of outcomes “are going to lead to the state we call a base camp, “which is a definable set of organizational “performance criteria.” It basically says, okay, this is what you’re going to get for your dollars. This is what the organization is going to be able to do when we’re done achieving these outcomes. So it’s been fun to watch you do, right, is where a lot of our outcomes have been around organizational design and teaming. And how do we do all the alignment things? How do we do the governance things? How do we do the metrics things? What you’ve kind of come in and done is helped us overlay what are the technical foundations that have to be put into place at the outcome level and at the activity level? So that was a long preamble. Talk to me a little bit about where you see the opportunity around overlying with our outcomes based planning.

– Yeah. So, any of these practices we’ve talked about so far test driven development, automated builds and so forth, the goal is never we should implement those practices. The goal is the outcome, right? So we’ve got these outcomes and ultimately, you know, usually they come around, how do we make or save the organization money? And as we’re taking those outcomes, then how do we that outcome? So as an example, if we’re building a release and we look at it and our define the end state, and we do a technical uplift assessment and find out that on average, each release has about 40% of overhead in it and about 60% of value added work in it, then we can look at that and say, well, how can we use some of these technical practices to reduce that amount of overhead? Maybe by automating builds or moves or reducing rework by having automated testing. So the practices affects some metric like the value density of the work. And that metric is based on one of the outcomes that we’re trying to do. So by, by making sure that the practices and the technology changes don’t become the goal, but the outcome is the goal, and these are techniques to achieve the goal, now these investment decisions can roll up to people that can prioritize budget and say, “That’s

UCD and Enterprise Business Agility

Wed, 11 Nov 2020 11:38:04 GMT

Earlier this week, working with clients in a large global organization, I received a question from some folks responsible for design in another area of the organization. They are experts in design but had not yet been exposed to Agile practices at an enterprise level. This was “first contact” with the Transformation for them. Here is the gist of one of their questions (Note: I’m paraphrasing how the question was asked):

We are concerned because we do not see how a User-Centered Design (UCD) process is evident in the System of Delivery being established as part of our Agile Transformation.

We define UCD as an iterative cycle which includes the following elements:

a. Empathize
b. Define
c. Prototype
d. Test
e. Implement

Here’s my response:

Hey {awesome design leaders},

You will already know most of this, but may not have seen it presented from the frame of the System of Delivery we use to support the cross-functional product development activities at {awesome client name}.

The way I think about UCD (and design in general), there are three primary frames of work:

Understanding the needs of users – understanding what the most important problems are from the point of view of users; organizing market segments into personas, etc.

This is mostly “off-stage” work which affects the quality of the artifacts which move through the system. {Awesome client} has typically taken an agency-approach to all of this work – development of personas, primary research. The system of delivery accounts for including the necessary aspects and insights through the activities, definitions of done, and the training around how to facilitate discussions – primarily with portfolio teams.
Developing design approaches – collaborating to develop the design approaches for how we choose to solve the problems we choose to solve.

In this case, the System of Delivery explicitly accounts for all of the activities of designing and selecting solution approaches in the solution definition and solution design phases. Design participation is integral to effective cross-functional team collaboration at both the portfolio and product tiers.
Evaluative research – gathering the signals, synthesizing them, and learning from them to enable us to course-correct our approaches as we discover our mistakes.

In this case, we identified—particularly in the context of the globalization of evaluative research practices and the partnership with in-market product owners—the key learning-opportunity points within the System of Delivery, where targeted research is appropriate.

Further, during epic validation, we have the opportunity for teams to evaluate the success criteria/effectiveness/solution hypotheses of individual epics. This measurement activity for “speeds and feeds” epics is naturally gravitating towards the analytics group, and for “more qualitative” behavioral changes, UCD is the right frame for discovery.

I believe the (centralized) Transformation office has already provided documentation and explanation of the System of Delivery, but may have emphasized different points at that time (there are many!). Hopefully, this additional specificity helps connect the broader context to the UCD frame.

TLDR

Design is deeply integrated throughout the cross-functional and cross-team collaborations articulated in our approach to enterprise business Agility. UCD is the current industry best-practice flavor of design. All the elements of {awesome design leader’s} described UCD process live expressly in each of the areas also described above:

Understanding needs – (a) empathy (b) define (c) prototype
Designing approaches – (b) define (c) prototype (d) test (e) implement
Evaluative research – (d) test (e) implement

The key difference is that a given objective is not pursued (a) through (e) in isolation as a functional “design service” providing insights to the teams, but rather all of those elements are appropriately and deeply intertwined into a shared process. It is within this context we solve for internal/external “agency model” staffing, dedicated stable design members of teams, etc.

Please feel free to reach out with any follow-up questions. Sometimes it is the nuance of specifics that helps people reach a shared understanding, happy to help do that.

Creating the Right Conditions for Stable Teams

Mon, 09 Nov 2020 10:00:41 GMT

Anytime something must be managed outside of the team, we’re creating a dependency. And dependencies kill Agility.

But sometimes we need expertise on multiple teams and only one or a few people with that expertise. How do we keep them from becoming a bottleneck, or destabilizing our teams?

It’s all about making trade-offs and balancing tensions.

Here are some teaming conditions should you avoid, and what to do instead.

Get on-demand access to watch the complete talk along with all five of the other Business Drivers of Agility series webinars with Mike Cottmeyer here.

Transcript

So here’s the interesting thing. There’s always going to be a tension, and this is where we got into in pretty good depth in the encapsulation versus orchestration thing.

So you have a team, right? And I can do one or two things, right? I can put a person on a team and leave them there for a little bit. And I can measure maybe velocity goes up sometimes velocity goes down when you add another person to the team, right? There’s no linear correlation necessarily between human beings and the throughput of a team.

So my first inclination would say, okay cool drop that person on the team and don’t create a dependency between them, okay? Probably the thing I would hate to see the most, is to have multiple teams and have that single person on all three of these teams. And manage that way, because here’s the problem, right? If the person over commits and gets overloaded on any one of these three teams, they are going to make the prioritization decision about who gets the work done and who gets starved, okay? That’s the condition I want to avoid is time slicing people across multiple teams.

What I will usually do… What I’ll usually find these are all just trade-offs and it’s all situationally specific, is if I have a Kanban up here, that’s like doing some sort of analysis, design, build, test, deploy queue. What I might do is I might take this person if they’re like a specialist and they’re contributing to the architecture design or definition of the feature or something like that, what I might do is put that person up here and have them operate on the highest priority features that are coming in at this level. So that when things go down here when they get into build, then that person’s expertise is captured in the backlog. And they’re unavailable ad hoc resource for this team.

So everything is tensions and trade-offs, right? There’s never a super, super clean answer. And that’s where I started in the first thing with this idea of encapsulation versus orchestration.

My preferences to encapsulate ’cause that’s going to give you the greatest agility. Where you can’t encapsulate, you have to orchestrate. The worst thing you can do, and this is what the… And using that language, right? If I put a person here, a person here, a person here, the same person, and I have no orchestration layer, then all I’m doing is I have unmanaged dependencies or I have this person actually managing their own commitments. And that can be an incredibly volatile thing. And you’re likely to starve one of these teams from being able to get their work done. So look for opportunities for encapsulation first. And if you can’t encapsulate explicitly orchestrate and I liked the idea of doing that with Kanban. But avoid the condition where you put an unmanaged dependencies between teams. That’s how I hunted down.

My sister one time said she goes like, “How do you walk into any organization “and like have a recommendation “on how they should do something “or take these random questions on a webinar?” It’s because at the end of the day, these are your companies, they’re your decisions to make, they’re your objective. Like, it’s your stuff, right?

What I’m doing is I’m walking you through the trade-offs that you have to make. And I’m basically pointing out when you’re violating the laws of physics.

So encapsulate where you can, that’s preferable, orchestrate where you can’t, that will reduce your agility. But if you choose to time slice people and create an unmanaged dependency, you will likely create douse. And you can do that too, right? I just don’t recommend it.

Governance, the Investment Tier, and Business Agility

Thu, 05 Nov 2020 10:30:33 GMT

In this week’s episode of SoundNotes, Ross Beurmann is back to talk about how to create a funding mechanism that’s as adaptable as the governance model. Or, to put it more simply, how to allocate funds and pay for things when we’re continually tuning the way we work, and what we’re working on.

As your organization moves further down the path toward Agility, you may experience some dissonance when more traditional methods of funding work meet with the need to inspect and adapt. And we’re not just talking about inspecting and adapting through the lens of product development, we’re also talking about how the organizational governance can inspect and adapt and how that supports Business Agility.

Links

On ProjectManagement.com, you can find another one of Dave and Ross’ recent podcasts entitled: “Business Planning for Agile AND Traditional Time Horizons”.

Listen to the Podcast.

Contacting Ross

Web: https://www.leadingagile.com/guides/ross-beurmann/
LinkedIn: https://www.linkedin.com/in/rossbeurmannzcea/
Email: Ross.Beurmann@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.

Building An Agile Operating Model That Accelerates ROI

Tue, 03 Nov 2020 10:00:42 GMT

Accelerating your time to ROI isn’t about delivering more lines of code faster. And it isn’t about delivering working tested product faster.

To accelerate ROI, we must reliably put the right combination of working tested product in front of customers so that it can drive revenue, self-fund further product development, and create opportunities to get critical feedback.

So how do you get all of this? By designing your operating model in a way that makes it all possible.

This clip is from Mike’s series on the 6 Key Business Drivers of Agility. You can check out the full ROI webinar on-demand here: https://go.leadingagile.com/gj1

Or to learn more about how we think about and approach Agile Transformation, you can download our Agile Transformation white paper here: www.leadingagile.com/whitepaper

Transcript

So early ROI, this often gets expressed differently. What it often gets expressed as is I want to be able to do things faster. They will say things like, “I’m a hint Jeff Sutherland wrote a book.” There was something like twice the work and half the time, right? That kind of a thing.

So 2X the work, one half the time, right? And that’s valid, right? Because people are looking for efficiencies, they’re looking for ways to get things into market faster. But you know, we have the physics of project management, right? It’s always kind of like, looking us in the face, right? You have scope, you have time, and you have cost, right?

So you kind of like pick two, and then you have to kind of float the third, or you have to figure out how to bring all of these different variables into balance. And so if you’re going to say something like, I’m going to do 2X the scope And I’m going to do it in half the time. Like, is custom save same as custom drop? Like, I don’t know, right? So like, what I want to explore with you guys a little bit is what are our options around doing things faster? And what does it actually mean, to do things faster, or to get things in the market faster.

And the reason why I categorize it as early ROI is because what the executives want is they don’t want to just deliver faster, right? It’s not just about like lines of code as fast as you can deliver them, right? It’s not even about working tested software as fast as you can deliver it, it’s really about what is that combination of working tested software that we can put reliably in front of a customer, so that we can start charging money for it. And we can start, you know, obviously getting revenue to fund further development. But we can also start to get that product in the hands of paying customers faster, so that they can start to give us feedback around it.

Okay. So a lot of it is how you might think about it, is we need to start thinking about optionality to release. Okay. And so I think an option is a lot, right? So I’m creating options to release things and to be able to get them into market faster, so we can start charging money for them and we can start getting feedback. So like a lot of things, we’re gonna build from kind of the atomics of this.

And then we’re going to start talking about how do you like dealing with it at scale and different things? So let’s talk a little bit about what the system of delivery looks like that gives us that optionality to release. Right? So I’m going to talk about the idea of the system of delivery. But then the other thing that we’re gonna have to figure out how to do is how do we educate the business to exploit that optionality to their economic advantage? Okay, and so it’s a tension between kind of the system of delivery and the business’s ability to exploit that. Okay. And we find that both of these can kind of become a problem.

And like, let me give you a for example, like, let’s just at the simplest level, let’s say, we had a really well functioning agile team that knew how to operate off of a well defined backlog that could produce a working tested incremental product at the end of the sprint, right? And life is good. But then we have the business that is approving big giant projects that are long, cost a lot of money and they aren’t willing to do anything with it until the team is totally done. You kind of go like, well, “how am I gonna be faster? Like what things are going to contribute to being able to do that, right?” So let’s go back to the teams backlogs to working tested software thing, right?

So what gives me optionality to release at the team level is, you know, again, things we’ve talked about, right? So there’s not a whole lot new when you get under the mechanics system, right? So I want a complete cross functional team that owns a technology stack that has very few dependencies highly encapsulated. You know, has everything and everyone necessary to be able to deliver the product. And I want that team to be able to establish a stable velocity. I want a product ownership capability, that enables me to break big things down into small things. So that, you know, I can pull a piece of the backlog off, feed it into the team and then have the team on two weeks cycles, be able to produce that piece of the software, right?

And then we talk about this idea of potentially shapable, right? In an ideal world at a minimum of about every two weeks, I would like to be able to take this bit of backlog, run it through the team, deploy it into production, and to be able to actually put it into the product and have like a real person pay me for it and use it. Okay. Sounds like pretty simple. Okay.

So again, mechanically, right? You think about, I’ve got to have these things broken up into small pieces. I have to have the team, have some ownership, there can’t be a whole bunch of external dependencies. I have to be able to continuously test the product, I have to be able to have some sort of maybe CI/CD pipeline here, I have to be able to push something into production really safely, I might have to be able to roll it back if there’s a problem, right? So there’s this whole like, execution pipeline that has to be in place in order to be able to give something, actually to a client and to be able to use it, right?

So that’s kind of like the mechanical side of early ROI, right?

You have to have the ability to do that. But here’s the other side of that, what goes into the backlog, right? What the product owner puts into that backlog, there has to be a hypothesis there about what a customer might actually use. Okay, and so what we want is, we want stuff at the top of the backlog, that there’s some person out here that might actually find it useful, and maybe even pay you money for it, right? That’s the goal. So we can have the ability to deliver this way all day long, Right? But if we’re not feeding the backlog with the right stuff, then we don’t have the opportunity to be able to get it in front of a customer and potentially charge for it or to get feedback or to learn or to do any of the other things. Right? So I’m sure you guys have heard of the idea of like, a minimally viable product. You know, at this level, right? So we’re still just like single team level Scrum level execution, right? All that kind of stuff, right? Single backlog, right?

So the idea is that I’ve got this, I have to understand what is the smallest thing that I think is valuable to put in front of a customer. Like I’ll give you an example within LeadingAgile. I like to give LeadingAgile examples, we’re building into another small internal dev team, and we are building a product that we call ELM Cooperstown. Whole reason why I call it ELM Cooperstown, but it’s employee Lifecycle Management. And eventually this is gonna be an iPhone app that is going to be able to will be able to pull up somebody in the database. I’ll be able to see like their location, I’ll be able to see their salary, I’ll be able to see like who their leader pod leader is, what account they’re on, we do a lot of personality profiling assessments in LeadingAgile. So I’ve got the ability to see their personality profiles, eventually I’ll be able to see things like what learning LMS modules they’ve been through, what onboarding things they’ve been through, what core skills are? And then the holy grail, right?

Somewhere down the road from now on, we’re going to have the ability to say, okay. We had this consultant it was operating in this way, with this client, they were really successful, we’ve got a similar engagement. Okay, show me all the consultants that are available that profile like Melissa, or show me all the consultants that are based in Atlanta, that profile like town, something like that, right? Because what I wanna be able to do is I wanna be able to really dynamically look up people, because we’re getting pretty big now. We have over 100 consultants, right? I wanna be able to look up people and understand kind of what their strengths and weaknesses are. Okay, so the instruction that I gave to our lead software guy, a guy named Donald, is I said, really fast, I want the ability to show me an employee database. And I put some constraints on it. Because it’s an iPhone app, I said, I want like some weird hacky iPhone app, like I want it to be like a beautiful, can’t spell beautiful iOS app. Okay. And I want to it beautifully display a list of people. I want to be able to search. And I want to be able to have just up on a name. And I want to be able to see some basic information. And I want to be able to see those one assessment we use called color code that I think is really super valuable. We could do a whole talk on that, that would actually be a pretty interesting talk. This whole thing called color code, I wanna be able to see somebody’s color code. So within like, a matter of weeks, it wasn’t like a super long time, I had this bit of stuff on my iPhone and I am telling you one of the most valuable things, right? I use on any given day, I use it by five times a day, because I’m constantly doing one on ones with people and talking to people and we’re making decisions about staffing.

And you know, why maybe somebody struggling here and not struggling there, we’re not getting the performance we want or behavior we want or something like that. I use this thing five times a day, every single day. And it was delivered in something like four weeks. Okay, in his spare time, right? Super, super valuable. Not nearly the vision that I anticipate having in this product a year from now. But what it does today, it does beautifully. And it does it with incredibly high quality. And it’s super, super valuable. Right? And that’s the kind of thing I’m talking about. Right?

So the tension on that dimension potential mentioned kind of run the tension in that dimension is that the product people have to orchestrate and sequence the backlog in such a way that everything is like getting to like an MVP or incrementing the MVP.

Okay, so you create the conditions for delivery. And then you have to teach the business, how to exploit those conditions. So that you can actually get the return.

I imagine you guys see this quite a bit. It’s like what starts to happen sometimes and this is really the core of the elevate agile conversation that we’re starting to have we’ve really learned a lot trying to talk about this over the last year is that there’s a lot of people out there that have built these really sophisticated agile delivery models. But the reality is that the business doesn’t really know how to exploit it, to get things in market early. So while we can do agile, because we’re still kind of dealing with project based funding models, we’re still dealing with large batches, annual cycles, right? All these different things. Nobody’s thinking through, how do I decompose this work and put it in front of customers as fast as we possibly can. Then this really great agile delivery capability that we built goes really underutilized.

So the promise of agile as a team level, or even an enterprise class delivery model doesn’t really realize the promise until the business understands how to exploit it. Okay. And so that example that I just gave you guys is like really simple, right?

This is single team, it’s really actually non-revenue generating piece of technology, right? Very little pressure on that team to perform it any kind of RAID. I’m the product owner, I’m the guy that’s funding it, right? Really super simple. But because of that relationship between me and my expectations, and delivery capability built, it’s working really well. And every single time there’s a release every couple days now. I get something new to play with. That is that is like really cool. Other examples in market that I imagine being like this, when I talk to kids at university, I talk about Snapchat a lot, because that’s obviously one of the latest and greatest, if anybody, social platforms, or maybe that’s even getting old news, I guess, TikTok, or whatever’s new. But I remember when Snapchat hit the scene, it was effectively just kind of like private video messaging that like just deleted a message, like right away.

As I recall, I was not an early adopter of Snapchat, because at the time, as a parent, right, everybody’s like, “Oh, no Snapchat, right? That’s how kids are sending inappropriate pictures to each other right? So where nobody gets busted, right?” And when my first adult friend ever landed on Snapchat, I was like teasing her that she was Snapchatting her kids and how weird that was. But apparently, by that time, Snapchat has actually evolved into how to add a more mature user base. But that’s where it started, it was this little thread of functionality that was like, “I’m gonna send you a message or picture and it’s gonna go away.” Right?

As that product is evolved right now, it’s got a more wide, more diverse user base, stories, and all kinds of different things, and filters, and all kinds of fun stuff, right? That people are using and you know, kind of a fun factor on that, my kids literally will not text me, like, they’ll ignore my text. But they’ll reply to Snapchat, which I find incredibly annoying. But point being is that, that was like an example of like an MVP, that got into market using agile delivery capabilities. And the business understood how to put something into that team really quickly, to bring something in market, and then grow it based upon user feedback, right? That is the absolute definition of early ROI.

Okay, so now let’s scale that concept. Right? So now let’s look into like a multi-tiered kind of enterprise agile kind of thing. Let’s talk about like, how that’s working. Right? So now we have like, we probably have like Shared Services teams, right? Service one, service two, service three, service four. We might have product teams or feature teams, that might be a better way of saying, like, feature teams, right? That kind of a thing, right? And then we have some sort of program layer. Right? If we’re thinking safe, we’re doing like release trains, we’re doing PI planning, right? All that kind of a thing. That’s probably subordinate to some sort of portfolio layer.

Okay, now, the trick when you start to get to this level of scale, right? And there’s kind of typically two ways you can manage this, I tend to like to model this as a kanban based queue, up here you could also manage it as in more like a kind of a release planning. Planning kind of PI planning kind of model, right? If you prefer Safe, right? What have you, right? So I tend to like Flowbase, Batch-and-Queue, Fun, right? Whatever. But the trick is when you start to scale this kind of stuff, let’s say you want to have a 12 week release. Okay? The trick is that you have to sequence the features that go into this release in such a way that enough of the user stories at the team level and at the feature level, product level, right? Get done, such that at the end of the 12 week release, you have something to actually put in the market, right? And then kind of like all this kind of same rules apply, right? What is the smallest set of features that is going to add value? How are those features going through decomposed into team level backlogs, right? How are those backlogs going to get rolled up into the program level? How are the features of user stories roll up into? How are they going to get validated? How are they going to get tested? How are they going to get deployed? How are they going to be put into market? How are they going to be rolled back if there’s like a crisis or a problem, right? That whole chain, that whole release management chain has to be like leaned out and tightened up so that you can put these bigger things into market. Right? What often is necessary there is you need a portfolio level that is dealing with projects that are way smaller investments than how we’re thinking about it now. Right?

David Spann introduced that language to me at one point in time. Right? If we could get the organization to not put anything not 30 months, type that out, three months, right? So if we could get the organization not to put anything into the system that was greater than three months. And everything that we put into the system broke down into features that were maybe a week or two big that broke down into user stories that were a few days. And we could sequence all of this work here in such a way that it rolled up and flowed through the product here. And then as features got done, we were actually able to release projects into market every couple of months. Right? Then we have the ability to know these big top level things that have big level ROI. Right? Now we can start to have that kind of a conversation around how this works.

Okay, so you start to think about it, so we got the delivery capacity here at the team level execution teams, teams, backlogs, working tested software, making sure that we’re running the smallest set of stuff through getting it to a really clear definition of done working tested software. Everything’s potentially shapable. Everything’s deployable. These things roll up into larger increments that were maybe continuously releasing or maybe batch and queuing, right? But they have a testing and integration cycle that’s fast and continuous. And then the organization has the ability to release things in market in a more fast and convenient way.

Using Agile To Get Early ROI

Mon, 02 Nov 2020 10:00:42 GMT

The best way to achieve early ROI with Agile is to create a delivery engine where the teams at the execution level are aligned with the business strategy.

To watch the entire webinar series, you can sign up for the On-Demand version and watch at your leisure by clicking this link: https://go.leadingagile.com/gj1

Or, to learn more about how we think about and approach Agile Transformation, you can download our Agile Transformation white paper here: www.leadingagile.com/whitepaper

Transcript

So early ROI, this often gets expressed differently. What it often gets expressed as is I want to be able to do things faster. They will say things like, “I’ma a hint Jeff Sutherland wrote a book.” There was something like twice the work and half the time, right? That kind of a thing. So 2X the work, one half the time, right? And that’s valid, right? Because people are looking for efficiencies, they’re looking for ways to get things into market faster. But you know, we have the physics of project management, right? It’s always kind of like, looking us in the face, right? You have scope, you have time, and you have cost, right? So you kind of like pick two, and then you have to kind of float the third, or you have to figure out how to bring all of these different variables into balance. And so if you’re going to say something like, I’m going to do 2X the scope And I’m going to do it in half the time. Like, is custom save same as custom drop?

Like, I don’t know, right? So like, what I want to explore with you guys a little bit is what are our options around doing things faster? And what does it actually mean, to do things faster, or to get things in the market faster. And the reason why I categorize it as early ROI is because what the executives want is they don’t want to just deliver faster, right? It’s not just about like lines of code as fast as you can deliver them, right? It’s not even about working tested software as fast as you can deliver it, it’s really about what is that combination of working tested software that we can put reliably in front of a customer, so that we can start charging money for it. And we can start, you know, obviously getting revenue to fund further development. But we can also start to get that product in the hands of paying customers faster, so that they can start to give us feedback around it. Okay.

So a lot of it is how you might think about it, is we need to start thinking about optionality to release. Okay. And so I think an option is a lot, right? So I’m creating options to release things and to be able to get them into market faster, so we can start charging money for them and we can start getting feedback. So like a lot of things, we’re gonna build from kind of the atomics of this. And then we’re going to start talking about how do you like dealing with it at scale and different things? So let’s talk a little bit about what the system of delivery looks like that gives us that optionality to release. Right?

So I’m going to talk about the idea of the system of delivery. But then the other thing that we’re gonna have to figure out how to do is how do we educate the business to exploit that optionality to their economic advantage? Okay, and so it’s a tension between kind of the system of delivery and the business’s ability to exploit that. Okay. And we find that both of these can kind of become a problem. And like, let me give you a for example, like, let’s just at the simplest level, let’s say, we had a really well functioning agile team that knew how to operate off of a well defined backlog that could produce a working tested incremental product at the end of the sprint, right? And life is good. But then we have the business that is approving big giant projects that are long, cost a lot of money and they aren’t willing to do anything with it until the team is totally done. You kind of go like, well, “how am I gonna be faster? Like what things are going to contribute to being able to do that, right?”

So let’s go back to the teams backlogs to working tested software thing, right? So what gives me optionality to release at the team level is, you know, again, things we’ve talked about, right? So there’s not a whole lot new when you get under the mechanics system, right? So I want a complete cross functional team that owns a technology stack that has very few dependencies highly encapsulated. You know, has everything and everyone necessary to be able to deliver the product. And I want that team to be able to establish a stable velocity. I want a product ownership capability, that enables me to break big things down into small things. So that, you know, I can pull a piece of the backlog off, feed it into the team and then have the team on two weeks cycles, be able to produce that piece of the software, right?

So if I’ve got the size of the backlog, I got the velocity, then I can start to think about duration, and scope. Right? That’s our basic like law, to me of team level agility. It’s like the three things that have to be in place. And you notice that’s like the anchor for almost everything that like, I like to talk about. So like, how does that get us into an early release situation? Well, you think about, like, what has to happen for that, right? So the idea is mechanically, whatever I pull off the backlog has to be built and tested, and accepted by the product owner. And then we talk about this idea of potentially shapable, right? In an ideal world at a minimum of about every two weeks, I would like to be able to take this bit of backlog, run it through the team, deploy it into production, and to be able to actually put it into the product and have like a real person pay me for it and use it. Okay. Sounds like pretty simple. Okay. So again, mechanically, right? You think about, I’ve got to have these things broken up into small pieces. I have to have the team, have some ownership, there can’t be a whole bunch of external dependencies. I have to be able to continuously test the product, I have to be able to have some sort of maybe CI/CD pipeline here, I have to be able to push something into production really safely, I might have to be able to roll it back if there’s a problem, right? So there’s this whole like, execution pipeline that has to be in place in order to be able to give something, actually to a client and to be able to use it, right? So that’s kind of like the mechanical side of early ROI, right? You have to have the ability to do that. But here’s the other side of that, what goes into the backlog, right? What the product owner puts into that backlog, there has to be a hypothesis there about what a customer might actually use. Okay, and so what we want is, we want stuff at the top of the backlog, that there’s some person out here that might actually find it useful, and maybe even pay you money for it, right? That’s the goal. So we can have the ability to deliver this way all day long ,Right? But if we’re not feeding the backlog with the right stuff, then we don’t have the opportunity to be able to get it in front of a customer and potentially charge for it or to get feedback or to learn or to do any of the other things. Right?

So I’m sure you guys have heard of the idea of like, a minimally viable product. You know, at this level, right? So we’re still just like single team level Scrum level execution, right? All that kind of stuff, right? Single backlog, right? So the idea is that I’ve got this, I have to understand what is the smallest thing that I think is valuable to put in front of a customer. Like I’ll give you an example within LeadingAgile. I like to give LeadingAgile examples, we’re building into another small internal dev team, and we are building a product that we call ELM Cooperstown. Whole reason why I call it ELM Cooperstown, but it’s employee Lifecycle Management. And eventually this is gonna be an iPhone app that is going to be able to will be able to pull up somebody in the database. I’ll be able to see like their location, I’ll be able to see their salary, I’ll be able to see like who their leader pod leader is, what account they’re on, we do a lot of personality profiling assessments in LeadingAgile.

So I’ve got the ability to see their personality profiles, eventually I’ll be able to see things like what learning LMS modules they’ve been through, what onboarding things they’ve been through, what core skills are? And then the holy grail, right? Somewhere down the road from now on, we’re going to have the ability to say, okay. We had this consultant it was operating in this way, with this client, they were really successful, we’ve got a similar engagement. Okay, show me all the consultants that are available that profile like Melissa, or show me all the consultants that are based in Atlanta, that profile like town, something like that, right? Because what I wanna be able to do is I wanna be able to really dynamically look up people, because we’re getting pretty big now. We have over 100 consultants, right? I wanna be able to look up people and understand kind of what their strengths and weaknesses are. Okay, so the instruction that I gave to our lead software guy, a guy named Donald, is I said, really fast, I want the ability to show me an employee database.

And I put some constraints on it. Because it’s an iPhone app, I said, I want like some weird hacky iPhone app, like I want it to be like a beautiful, can’t spell beautiful iOS app. Okay. And I want to it beautifully display a list of people. I want to be able to search. And I want to be able to have just up on a name. And I want to be able to see some basic information. And I want to be able to see those one assessment we use called color code that I think is really super valuable. We could do a whole talk on that, that would actually be a pretty interesting talk. This whole thing called color code, I wanna be able to see somebody’s color code. So within like, a matter of weeks, it wasn’t like a super long time, I had this bit of stuff on my iPhone and I am telling you one of the most valuable things, right?

I use on any given day, I use it by five times a day, because I’m constantly doing one on ones with people and talking to people and we’re making decisions about staffing. And you know, why maybe somebody struggling here and not struggling there, we’re not getting the performance we want or behavior we want or something like that. I use this thing five times a day, every single day. And it was delivered in something like four weeks. Okay, in his spare time, right? Super, super valuable. Not nearly the vision that I anticipate having in this product a year from now. But what it does today, it does beautifully. And it does it with incredibly high quality. And it’s super, super valuable. Right? And that’s the kind of thing I’m talking about. Right?

So if I had this delivery capacity on my team in my organization that could be, you know, dedicated team, dedicated technology, really clear backlog, the ability to produce a working tested software, every sprint like whatever. But I was sitting here as the product owner going, ” You know what, Donald, this is never… I don’t wanna release anything until we can get everything.” Then I don’t get anything actually early and I don’t get any value from it. So the tension on that dimension potential mentioned kind of run the tension in that dimension is that the product people have to orchestrate and sequence the backlog in such a way that everything is like getting to like an MVP or incrementing the MVP.

Okay, so you create the conditions for delivery. And then you have to teach the business, how to exploit those conditions. So that you can actually get the return. I imagine you guys see this quite a bit. It’s like what starts to happen sometimes and this is really the core of the elevate agile conversation that we’re starting to have we’ve really learned a lot trying to talk about this over the last year is that there’s a lot of people out there that have built these really sophisticated agile delivery models. But the reality is that the business doesn’t really know how to exploit it, to get things in market early.

So while we can do agile, because we’re still kind of dealing with project based funding models, we’re still dealing with large batches, annual cycles, right? All these different things. Nobody’s thinking through, how do I decompose this work and put it in front of customers as fast as we possibly can. Then this really great agile delivery capability that we built goes really underutilized. So the promise of agile as a team level, or even an enterprise class delivery model doesn’t really realize the promise until the business understands how to exploit it. Okay. And so that example that I just gave you guys is like really simple, right? This is single team, it’s really actually non-revenue generating piece of technology, right? Very little pressure on that team to perform it any kind of RAID. I’m the product owner, I’m the guy that’s funding it, right? Really super simple. But because of that relationship between me and my expectations, and delivery capability built, it’s working really well. And every single time there’s a release every couple days now. I get something new to play with. That is that is like really cool.

Other examples in market that I imagine being like this, when I talk to kids at university, I talk about Snapchat a lot, because that’s obviously one of the latest and greatest, if anybody, social platforms, or maybe that’s even getting old news, I guess, TikTok, or whatever’s new. But I remember when Snapchat hit the scene, it was effectively just kind of like private video messaging that like just deleted a message, like right away. As I recall, I was not an early adopter of Snapchat, because at the time, as a parent, right, everybody’s like, “Oh, no Snapchat, right? That’s how kids are sending inappropriate pictures to each other right? So where nobody gets busted, right?” And when my first adult friend ever landed on Snapchat, I was like teasing her that she was Snapchatting her kids and how weird that was. But apparently, by that time, Snapchat has actually evolved into how to add a more mature user base.

But that’s where it started, it was this little thread of functionality that was like, “I’m gonna send you a message or picture and it’s gonna go away.” Right? As that product is evolved right now, it’s got a more wide, more diverse user base, stories, and all kinds of different things, and filters, and all kinds of fun stuff, right? That people are using and you know, kind of a fun factor on that, my kids literally will not text me, like, they’ll ignore my text. But they’ll reply to Snapchat, which I find incredibly annoying. But point being is that, that was like an example of like an MVP, that got into market using agile delivery capabilities.

And the business understood how to put something into that team really quickly, to bring something in market, and then grow it based upon user feedback, right? That is the absolute definition of early ROI. Okay, so now let’s scale that concept. Right? So now let’s look into like a multi-tiered kind of enterprise agile kind of thing. Let’s talk about like, how that’s working. Right? So now we have like, we probably have like Shared Services teams, right? Service one, service two, service three, service four. We might have product teams or feature teams, that might be a better way of saying, like, feature teams, right? That kind of a thing, right? And then we have some sort of program layer. Right? If we’re thinking safe, we’re doing like release trains, we’re doing PI planning, right? All that kind of a thing. That’s probably subordinate to some sort of portfolio layer. Okay, now, the trick when you start to get to this level of scale, right? And there’s kind of typically two ways you can manage this, I tend to like to model this as a kanban based queue, up here you could also manage it as in more like a kind of a release planning. Planning kind of PI planning kind of model, right? If you prefer Safe, right? What have you, right?

So I tend to like Flowbase, Batch-and-Queue, Fun, right? Whatever. But the trick is when you start to scale this kind of stuff, let’s say you want to have a 12 week release. Okay? The trick is that you have to sequence the features that go into this release in such a way that enough of the user stories at the team level and at the feature level, product level, right? Get done, such that at the end of the 12 week release, you have something to actually put in the market, right? And then kind of like all this kind of same rules apply, right? What is the smallest set of features that is going to add value? How are those features going through decomposed into team level backlogs, right? How are those backlogs going to get rolled up into the program level? How are the features of user stories roll up into? How are they going to get validated? How are they going to get tested? How are they going to get deployed? How are they going to be put into market? How are they going to be rolled back if there’s like a crisis or a problem, right? That whole chain, that whole release management chain has to be like leaned out and tightened up so that you can put these bigger things into market. Right? What often is necessary there is you need a portfolio level that is dealing with projects that are way smaller investments than how we’re thinking about it now. Right?

So I told an executive of a company, we probably did like a year two, year three transformation for, you’d be halfway there, if you would just never approve a project that was greater than three months, right? It’s all about smaller bets. David Spann introduced that language to me at one point in time. Right? If we could get the organization to not put anything not 30 months, type that out, three months, right? So if we could get the organization not to put anything into the system that was greater than three months. And everything that we put into the system broke down into features that were maybe a week or two big that broke down into user stories that were a few days. And we could sequence all of this work here in such a way that it rolled up and flowed through the product here.

And then as features got done, we were actually able to release projects into market every couple of months. Right? Then we have the ability to know these big top level things that have big level ROI. Right? Now we can start to have that kind of a conversation around how this works. Okay, so you start to think about it, so we got the delivery capacity here at the team level execution teams, teams, backlogs, working tested software, making sure that we’re running the smallest set of stuff through getting it to a really clear definition of done working tested software. Everything’s potentially shapable. Everything’s deployable. These things roll up into larger increments that were maybe continuously releasing or maybe batch and queuing, right? But they have a testing and integration cycle that’s fast and continuous. And then the organization has the ability to release things in market in a more fast and convenient way. .

The Physics of Agility: Quality

Thu, 29 Oct 2020 09:00:55 GMT

You have to deeply understand how what you’re doing at all levels of the organization is going to drive quality. In this week’s podcast, LeadingAgile CEO Mike Cottmeyer joins us to dig into why increased quality should matter to you, and some actionable steps to take to enable more of it across your organization.

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

Forming Teams in an Agile Organization

Wed, 28 Oct 2020 09:00:52 GMT

When teams aren’t formed in the right way in your organization such that they’re encapsulated to create working tested increment of product in a given time frame, they become a dependency.

Without encapsulated teams, you’ll find yourself with many dependencies. And dependencies kill Agility.

To watch the entire webinar series, you can sign up for the On-Demand version and watch at your leisure by clicking this link: https://engage.leadingagile.com/WCT-PAT-ODW-2020_Registration-Page-2.html

Or, to learn more about how we think about and approach Agile Transformation, you can download our Agile Transformation white paper here: www.leadingagile.com/whitepaper

The Three Things You Need For Agile Transformation

Tue, 27 Oct 2020 09:00:22 GMT

Agile Transformation is fundamentally about Three Things: forming teams, building backlogs, and having the ability to produce working, tested software. If we don’t these Three Things then Transformation fails.

To uncover everything you need to know about The Three Things, check out LeadingAgile CEO Mike Cottmeyer’s on-demand webinar series Preparing for Agile Transformation here: https://go.leadingagile.com/jeg

The Physics of Agility: Predictability

Thu, 22 Oct 2020 09:00:42 GMT

When large organizations set out to take on Agile Transformation, it’s never for Agile’s sake. They’re usually after one or more of these 6 things, Predictability, Quality, Cost Savings, Early ROI, Product Fit, or Innovation.

In this week’s episode of LeadingAgile’s SoundNotes, Dave Prior talks with Mike Cottmeyer to discuss the steps you can take to get more predictable and make and meet your commitments.

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

How Agile are you and How Agile do you want to be?

Wed, 21 Oct 2020 13:45:08 GMT

Understanding what constraints your organization is dealing with, what goals it’s trying to achieve, and where it wants to be in the future is a critical first step in the Agile Transformation.

Having this knowledge helps you craft a plan for how you’re going to iteratively & incrementally move Expeditions through Basecamps to get your organization to its desired end state.

In this video, Mike Cottmeyer takes a closer look at something we call the 4 Quadrants. This is a thinking tool we use to help organizations understand how constraints are driving their decision making and assist them in visualizing the steps they can take, over time, to change the constraints so that they have more flexibility in the future.

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.

LeadingAgile

Multiple Product Owners With Competing Priorities w/ Jeff Howey

Listen to the SoundNotes Podcast on the go!

Contacting Jeff Howey

Contacting Dave Prior

Agile is More Than a Mindset

Transcript

Building a System Where Agile Can Thrive

Biological Systems, Organizational Systems, and Catalyzing Change w/ Matt Craig

Listen to the SoundNotes Podcast on the go!

Contacting Matt

Contacting Dave

We Need Reviews

Feedback/Questions

LeadingAgile CSM and CSPO Classes

Keeping Life-Critical Decision Support Applications Shippable

The Right Way to Think About Cost Savings with Agile

Transcript

An Agile Approach to Personal Development w/ Mike Cottmeyer

Listen to the SoundNotes Podcast on the go!

Encapsulation vs Orchestration: Dependencies in Agile

The Assumptions of Scrum

The Reality of Scrum

Failure Modes of Other Popular Methodologies

Scrum of Scrums

SAFe

LeSS

Compensating Controls

How Agile Do You Want to Be? And How Quickly?

Organizational Impact of Dependencies

Agile Unplugged EP04 | Mike Cottmeyer and Matt Van Vleet

Listen to the Agile Unplugged Podcast on the go!

Transcript

UCD and Enterprise Business Agility

TLDR

Creating the Right Conditions for Stable Teams

Transcript

Governance, the Investment Tier, and Business Agility

Listen to the SoundNotes Podcast on the go!

Links

Contacting Ross

Contacting Dave

We Need Reviews

Feedback/Questions

LeadingAgile CSM and CSPO Classes

Building An Agile Operating Model That Accelerates ROI

Transcript

Using Agile To Get Early ROI

Transcript

The Physics of Agility: Quality

Listen to the SoundNotes Podcast on the go!

Forming Teams in an Agile Organization

The Three Things You Need For Agile Transformation

The Physics of Agility: Predictability

Listen to the SoundNotes Podcast on the go!

How Agile are you and How Agile do you want to be?

Predictability and Adaptability Live in Tension

Listen to the Agile Unplugged
Podcast on the go!