Body copy: Jobs to be Done is a Framework designed to enable more innovation and disruption. It’s used as a tool to see products through the eyes of customers and the goals they’re trying to accomplish.

In this video, you’ll get a quick introduction and overview of what Jobs to Be Done that includes examples of Jobs, plus an overview of how our LeadingAgile Studios team uses JBTD to solve problems for our clients.

The core of change management is helping an organization prepare, support, and apply changes to an organization. In execution during an Agile Transformation, it looks different depending on how the organization is going about this change.

The most significant aspect of change management is that it should include the people. Yes, deciding on the new structure, governance, and metrics is crucial. But you can’t do that without your people.

People are naturally resistant to change, and there will inevitably be pushback from some people. Change is uncomfortable, especially when it involves your livelihood at your job. Or, if someone has been doing the same position for 10-20+ years, teaching them to change their ways can be met with complaints.

During Agile Transformation, it’s essential to manage the expectations of what’s happening throughout the process, support people’s hesitancies, and work to alleviate them. Creating safety and reassurance that they are needed in this new Agile world and helping them process what it looks like moving forward helps calm fears and get people moving.

Even though change management should support the people, there may be more to it than you think.

How Change Management is Typically Implemented

Most organizations that adopt Agile are taking a practice or culture-first approach. This means that their change management strategy revolves around the following:

Practices First

• Agile practices training.
• Teach Scrum, SAFe, etc.
• The team goes back to work and implements new practices.

Culture First

• Training that empowers people.
• Focus on teamwork & collaboration.
• The team goes back to work and implements a new culture.

In these scenarios, the strategy is training people and then letting them return to work and implement the changes. It doesn’t need more than that because nothing around the team is fundamentally changing. The existing org structure, teaming strategies, org design, governance, metrics, and controls stay the same.

At the most basic, Agile is only seen as something that teams do at the work surface level. They may have a daily standup and work in determined sprint intervals, but they’re not Agile. They’re putting practices and culture changes on top of a broken system that isn’t designed to support them.

Because of this, these Transformations inevitably fail. People see that no amount of practice or culture change will help what’s systematically wrong, and these changes don’t make that big of an impact. They will slowly go back to working the way they used to.

What Agile Transformation actually needs is a systems-first Transformation strategy. Then, once the systems are in place to support everything else, practices and culture follow.

What’s Different with a Systematic Change Management Approach

 Here at LeadingAgile, we take a systems-first approach to Transformation.

Our approach looks like this:

• Look at the organization’s design and changes needed to support Agile.
• Form small, cross-functional teams around business capabilities, feature sets, products, components, services within the organization, etc.
• Refine backlogs to be clearly defined and reasonable to complete.
• Produce a working tested increment of product at the end of every sprint.
• Manage dependencies until we can break them.
• Governance model: interaction between different teams and levels of the organization.
• Metrics: decide what to measure and control.
• Connect progress to measurable business value that leaders care about.

Developing a systems-first plan gives us an incremental and iterative approach to Transformation. It will not work if you go in and upend the entire organization. We must choose a pilot section of the organization to start with, get it working, and then move on to another department.

In that case, our approach to change management is also more systematic. Because we are fundamentally changing the team structure, how they work within a sprint, the frequency of delivering work, and more, the people need much more support.

Our change management strategy involves communicating and ensuring a progressive understanding of what the Transformation means to the organization and the people themselves.

From there, we build upon progressive engagement from the top down and get leadership on board to facilitate change. Throughout this process, we are supporting the people to understand their fears, resistance, and overall understanding of their role in the Transformation.

When we keep a consistent flow of communication, show the people that they won’t be left behind, and help to calm their fears of change, we can implement Agile practices, and the changes will be sustainable.

Over time, this change management strategy is used to incrementally walk the organization and the people through Transformation. When they have a plan to follow, they’re much more likely to execute it. Once the organization sees one team succeeding, the rest will follow until the entire organization is on board and achieving Agile success.

There’s a layer to communication that is most important for understanding: intention. It’s the most often overlooked aspect because it’s hard to decipher if people are saying what they mean or if you actually understand what they’re saying.

By hunting for a shared understanding of intention, you can more deeply understand what people are saying and why. If you aren’t aligning on intent, you could be missing the mark, which can be detrimental, especially in a business environment.

In this episode of SoundNotes, Dave and Mike explore how improving communication can translate into an Agile work environment, personal relationships, and the benefits that better communication provides to individuals and groups of people.

Want to listen only? Here’s the audio:

Contacting Mike Cottmeyer

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

LeadingAgile: https://www.leadingagile.com/guides/mike-cottmeyer
LinkedIn: https://www.linkedin.com/in/cottmeyer/
Twitter: https://twitter.com/mcottmeyer
Email: mike@leadingagile.com

Contacting Dave Prior

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

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

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

Interested in CSM or CSPO Training?

You can find all the details at https://www.leadingagile.com/our-gear/training/

There were 12 Agile principles included in the Agile Manifesto when it was first written. Some still hold up today, but some were written in a context that doesn’t apply to business today.

In this video, Mike explores which Agile principles still apply today. He connects which ones succeed in large complex organizations typically undergoing a Transformation. And how they are used in a changing software development and deployment structure.

Finally, he answers the question everyone wants to know. By adopting Agile, what benefits will my company see from this new way of working?

Over the last decade, automation has become the norm for most organizations. And if they aren’t fully automated, they are going toward becoming fully automated. DevOps automates the process that connects development to operations, and now that DevOps tools are easy to get your hands on, most people want to be able to say they’re doing it. When you can get a tool to accomplish what it used to take teams full of people to do, and the cloud boosts that process even more, it can seem like a no-brainer to jump on the bandwagon so you can stay competitive and efficient. 

In the end, DevOps is about getting your teams to get software out the door faster. 

The trouble is that what we see in many organizations now is that they’re using DevOps automation because it’s “the thing to do,” rather than a thing to do that’s tied to a particular reason or business value. So it seems like everyone is doing the right thing, but the truth for many of these organizations is that they’re just going through the motions of these technical practices without a purpose. 

It’s great to have a DevOps initiative. But what are you doing? Why are you doing it?

“Because we should do DevOps” is not a good answer.

Are you trying to get software into production faster?
Are you trying to reduce defects?
Are you trying to get your teams to work with fewer dependencies?

What you want to do is actually connect your technology to the real business problems you need to solve. Solve the problems you need to solve and then you can get ROI for adding this automation in the first place.

Without knowing your “Why,” all you’re doing is aiming for completeness. “We do DevOps.” That’s it? If that’s the case, then you won’t have any leverage to have future conversations with the business and leaders about why they should invest in more automation or technology. 

Don’t Do DevOps for the sake of DevOps. Do DevOps for the sake of solving a business problem.

What Are You Trying to Achieve? 

So when you want to take on a DevOps initiative, you need to start by figuring out what you’re trying to do. What’s your goal? What business value do you need to get from it? If you know what you’re trying to do and then scope your DevOps effort to that, you can begin to see the ROI you get from using technology to solve real business problems. 

Here are the 6 most common DevOps goals we see: 

Predictability. You want to reliably make and meet commitments to your customers, plus build trust with internal stakeholders, customers, and markets.

Quality. Ultimately you want to get the right features and functionalities released, reduce defects and reduce technical debt so you don’t erode trust and keep a good reputation with customers. 

Early ROI. You want to be able to charge for the product sooner, and realize revenue faster. Usually this means building for automation and working in smaller increments. 

Cost Savings. You want to release more at a lower cost and focus on real business problems that offer the highest value. 

Innovation. You can’t innovate if you aren’t freed up to explore what works.Ultimately software development slows down as soon as you’re afraid of change. You want to make sure you’re always moving forward. 

Product Fit. You want to know you are building the right product for your customers. To do this, you need to be able to get quick feedback and change directions quickly to suit any changes. 

Coincidentally, these are the same goals organizations usually have for Agile Transformation. 

Bridging the Technology-Agile Gap

In recent years as more companies begin to take on DevOps initiatives during Transformation, we’ve found that they’re increasingly constrained by a lack of people with the necessary skills to deliver the type of technical results required. So companies have to make the decision to slow down their Transformation and reduce business value until they can close the gaps between Agile Transformation and DevOps. But Transformations don’t need to be put on hold. There are other ways to solve the problem. 

In response to seeing this, we created LeadingAgile’s Studios to address and close these gaps so our clients maintain Transformational momentum by maximizing both velocity and value while the business invests in its employees, grows, and continues Transforming. 

How do we do this? We make shifts organizationally to ensure your teams are cross-functional and can work autonomously. But when you change your teams, your code doesn’t just change itself,  you have to also change the way you write your code. The catch is that once you change your teams and the way you write code, you’ll have more dependencies. And if you want to be Agile, you have to manage those dependencies or break them. If you have unmanaged dependencies, you won’t have Agility, all you’ll have is continued chaos. 

So to make Agile and DevOps work, we start by orchestrating and putting in compensating controls to start managing the dependencies until we can break them. LeadingAgile has a journey we put clients on with measurable steps through what we call Basecamps, a reference architecture in 5 incremental phases. When we move into the last 3 phases of Transformation, where the team is encapsulated and software is too, DevOps becomes easier because it doesn’t have to move the whole world to get one thing done. 

We use Agile to stabilize the system we created to make all this work. But at some point there’s only so much you can do with organizational design, reducing batch size, and improving release plans. Unless you can start to remove dependencies and have teams operate autonomously, you are only as Agile as your dependencies will allow you to be. 

Aim Toward Outcomes

Ultimately, if you want DevOps to work and you want Agile to work, both of them need to be aimed at solving real business problems. Doing either one just because it’s the thing to do will not get you where you want to be. DevOps is only as valuable as the outcomes you get from it. 

When the Agile Manifesto was created 21 years ago, software development, technology, and the world, in general, were different.

Agile was first created in response to the frustrations around the traditional software development processes of the 1990s—years from idea to development to deployment—and the explosion of personal computing, meaning that software had to keep up, but it was struggling to do so.

What really made Agile work in the early days was the cross-functional team of people who collaborated in the room with their customers, building products and constantly iterating and testing.

As it evolved, we wrapped the core structure with different processes to get there but forgot the fundamental principles that made Agile successful. We’ve taken practices that worked in that room but overlayed them on top of organizations that aren’t teams in a room with the autonomy to change their software.

And because of that, we hear whispers that “Agile doesn’t work anymore.”

We get it. Organizations that adopt Agile have a lot on the line. They do it because they think it will increase their product delivery time, reduce mistakes, make them more predictable, get an edge on the market, and respond to customer feedback and changing demands. The list goes on.

Not only that, but they also invest thousands or millions of dollars and months or years in doing it. So, they lose money and sometimes even their jobs when it fails. There isn’t much forgiveness when leaders make promises of success to an organization that they can’t deliver on.

The problem isn’t that Agile doesn’t work. We’ve proven that it works if you do it right. The problem is that adopting Agile alone is not enough. You can’t simply put Agile practices on top of an organization not set up for them to succeed. And when you do that, Agile will fail every time.

We must also adapt Agile to a changing technology landscape and work environment. More often, teams are not working in a room together, and customers aren’t either.

For Agile to remain successful, we must remember the core principles and shape the organization to adapt to make those things work the way the world is now.

What Made Agile Work in The Beginning

Agile officially began with the Manifesto in 2001 and was designed to:

• Empower developers
• Increase development speed
• Working processes focused on the user
• Ability to adapt
• Quick response to customer feedback
• Small autonomous teams
• In a room with their customer
• Constant iteration and testing
• Local apps on local servers

Because of this small scope of software development, it was easy for small teams to operate with autonomy. They had a small, controlled environment they deployed into that only they had access to. The security requirements were minimal, as were the places where the applications needed to be deployed.

Remember, in 2001, people were still getting started with personal computers, and though they were becoming more and more common in households, not everyone had one. The amount of technology and software required to support it was minimal compared to what it is today.

Over the last 21 years, Agile has remained successful for those who still remember its core principles. The problem we’re facing now is that the technology landscape has evolved, and so has the way we work.

To adapt Agile to work today, we still have to remember that what makes Agile work is setting up the systems and the structure of the organization to be successful. No amount of culture change or practices will work if the underlying systems are not there first.

How Technology Has Changed & Its Impact on Agile

Fast forward to today, and the complexity of software and the problems we are solving are much broader. This leads to the following:

• Teams can’t encapsulate software development.
• Dependencies between teams
• Teams operating separately from their customers and markets
• Lag in response to customer feedback
• Inability to react quickly to market changes
• Delay in deploying and re-iterating software

Now, we are also deploying applications differently—to the cloud. This enormous scope of deployment creates more obstacles resulting from technological advances:

• Requires more robust security
• Specific development skills
• More moving parts that work together
• Cloud needs to work anywhere, anytime, on any device
• Code and user experience suffer
• Increasingly difficult to consider the whole ecosystem of deployment

When the performance scale is much larger, and the stakes are much higher, there’s increased risk involved from a financial standpoint. In a world where everyone is constantly online, one application launch failure can result in consumers rejecting the application altogether.

Today, consumers are more ruthless than ever, and though feedback is essential, there are so many applications on the market that consumers might not wait for you to fix yours.

So, while software needs to be moving quickly, so do the teams developing the software. It means that organizations need to create the conditions for speed and autonomy in team pockets.

The problem is that they don’t always do that. They don’t make the conditions for teams to operate correctly. They don’t build backlogs. They don’t encapsulate teams because the problem scope is too large for them to do that.

They adopt Agile into an ecosystem where it can’t work, but they blame it when it doesn’t.

Haven’t we learned yet that Agile practices aren’t successful without the systems to support them?

Agile won’t give you the leverage you think it will in the market without overhauling an organization, restructuring teams, and fundamentally changing the work environment. Agile is not a quick fix, as much as people want it to be.

 How We’ve Adapted Our Approach Over the Years

1. Establish Software Development & Agile Transformation Knowledge

The first adaptation we’ve made is to establish our knowledge and experience surrounding software development, Agile Transformation, and how the technological landscape has changed. We’ve learned a lot from working with clients over the last 12 years as a company and people whose experience began way before that. We acknowledge that things aren’t the same as they were 21 years ago, and we have created special teams to help tackle software challenges. We have also gathered groups of incredibly knowledgeable people who understand how Agile works on the ground and how to implement it in many different-sized organizations. We also know where it can commonly go wrong and how to help.

2. Leading with Empathy in Client Engagements

Arguably the most important thing we do is lead with empathy in every client engagement.

We don’t just walk into an organization and demand things be changed because we said so.

It’s essential to establish empathy about the problems the organization has faced and wants to solve, especially if they tried implementing Agile before and failed. The stakeholders and executives involved in those types of Transformations will be hesitant, have trouble trusting our process, or be skeptical that we can make it work for their organization—but there’s a reason they bring us on board.

Because of their hesitation, we need to develop a trusting relationship. We listen with empathy for their problems and where things go wrong, work to deeply understand what matters to them, and create transparency for the process ahead.

3. Build Trust and Influence with Key Stakeholders

To build trust and influence, we develop a relationship of communication and transparency every step of the way. While these stakeholders may not be involved with the day-to-day teams, software development, and training, they must be in the loop to support their people.

The better leaders can understand what needs to change and why the more influence they will have in getting their people to change. Many Transformations fail to include executives and key stakeholders in the minutiae, thinking they don’t need to know when it couldn’t be further from the truth. Because they influence their organization, they will have more power to affect lasting change.

Overall, our strategy has adapted over the years to encompass the changing technological landscape, with teams to handle software Transformations and organizational Transformations. This is the complete package of what Agile requires today to set up the foundations and systems for Agile to succeed.

Agile Still Works If You Do It Right

In the industry, we still see people beating the culture first or practices first drum. But we know from experience that no amount of culture or practice change will Transform a broken system. To achieve sustainable Business Agility, you have to change the system first.

When the system is not set up to support small autonomous teams, weed out impediments, break dependencies, allow for constant iteration, and work within designated sprints to completion, no amount of daily process or culture boost will help.

Cultural change may seem like it works at first, but when things don’t actually change, morale will tank, and people will go back to doing things the way they always did. The same goes for practices. If they aren’t producing results, what’s the point?

Along with that, we must continue to consider the current state of technology, how we build, deploy, and iterate software, how people use it, and what the consumers want. We must make the systems work with how and where people want to work. We are shifting to a lot of remote work, which will probably be the norm well into the future.

As the world becomes increasingly digital, we must adapt our approach to ensure that Agile’s core principles are honored and set up to work. As long as we set up the ecosystem first, everything will fall into place after that.

With a solid organizational foundation, we will create an environment and organization that can quickly adapt to the continually changing technological marketplace.

Mike Cottmeyer chats with CTO Matt Van Vleet about the currently emerging patterns we’re seeing in Agile and DevOps. They explore how some of the lingering assumptions that don’t apply to the present state of DevOps can get in the way of actually solving the real business problems we expect DevOps and Agile to solve.

Imagine you were building library databases for schools.

The librarians are your economic buyers, and they value advanced search pages—Boolean searches for just the right keywords or publication dates. But the librarians aren’t buying these databases only for themselves.

Instead, they’re buying them for high school students. Students who don’t have a master’s degree in Library Science, who probably don’t know or care about Boolean searches because they’re used to using Google.

If you only considered the economic buyers’ wants, do you think you’d end up building a suitable database? Do you think your database would get widespread adoption from the end users, a.k.a. the students you and the librarians were hoping to get?

Probably not. On the contrary, if you assumed that the buyers’ values matched those of the end users, you’d likely look back and see this product as a total fail.

“No one’s using our product? But why?”  

“If only we knew what we needed to build ahead of time, we could’ve built the right thing the first time.”

This library database scenario exemplifies how making a big assumption, even in a relatively short decision chain, can disrupt your ability to deliver a high-quality product that will delight your customer.

This same type of scenario plays out in business all the time, too. But, in business, we often deal with more significant decisions, longer decision chains, truckloads of more money, and people’s livelihoods on the line. The fallout of making a poor decision about the product you’re building can get costly from both a human and financial perspective, so it behooves us to figure out some way to get it right.

Fortunately, there’s a way to weed out poor product assumptions early in the build process to mitigate risk, reduce waste, and save some dollars and heartache along the way.

But first, let’s look at how product assumptions can creep into our work.

Product Fit: The Hunt for Red Herrings

We’re unsure how red herrings became synonymous with a false or misleading clue. Maybe if we had some sort of advanced Boolean search to help us find the answer—wait, erm—we’ve been down that path already, haven’t we? Alright, we don’t have to go there again.

But product assumptions are, in fact, red herrings, though. They lurk inside your organization, just waiting to sabotage your product, and they can come from many different locations: sales, marketing, Ops, finance, you name it. Heck! Even talking to your actual customers sometimes isn’t safe.

Sales may say, “Look. Our competition has 20 features, and we only have 10. We look bad by comparison, and it seems to be a sticking point in most of my calls. We’ve got to build in more features. Pronto!”

Or marketing might tell you, “Hey, bud. We’ve been doing market research, and the customers are looking to solve problem X, and they want this very specific feature that’s incredibly heavy and complex. Still, we think you need to build it because, hey…the customer is always right.”

Or even worse, maybe your SVP ambushes the teams one day and exclaims, “Everyone! Today is a new day for us. We will begin the launch of Our Product 2.0! It came to me in a vision last night as I lay there deep in my slumber. It’s going to be great! Just. Trust. Me.” *commence eye rolls*

Okay, that last one might include a little hyperbole, but you get the point. These assumptions can come from anywhere, at any time. But you know the old saying about assuming, right?

Are All Product Assumptions Good or Bad?

 But Derek? But David? Aren’t we supposed to be innovative and inventive so that we might push the boundaries of the market to keep up with our competition?

Glad you asked. Absolutely. You want to be both innovative and inventive in a competitive marketplace. And especially in new markets. We’d even go as far as saying that in new markets, sometimes all you have are assumptions and hypotheses.

So, it’s not that all assumptions are good. And it’s not that all assumptions are bad. It’s the wrong question to ask. The truth is that assumptions are reality. Often necessary.

So, the question is how we can create a product roadmap enabling us to test our assumptions. How do we get fast feedback from the people who matter to ensure we’re investing our time, energy, and dollars into the right places, at the right time, to release the most value into the market and get the most ROI?

And how do we do these tests and get the feedback at scale without losing our ability to be Agile?

Because if you’re not asking the right questions and thinking about your products in investment increments, you’re doing it wrong, and you’re going to run into product fit issues. And product fit issues lead to rework or, worse, tearing it all down and starting from scratch.

That’s a lot of wasted time and money. Not to mention a lot of unhappy customers.

And the only people you end up delighting are your competition.

Your competition? They love to see you fail.

 The Product Strategy You Want & Need

 How do you not delight your competition and delight your customers instead?

It’s easy. Make smaller bets.

First, what do we mean when we say make smaller bets? We mean that it’s always easier to build more. You can always add a feature later. But if you’ve already built it, you can do nothing to get that time, effort, and money back.

In Agile, the delivery organization inside your business strives to reduce batch size and deliver an increment of working-tested product that has some value to the business or its customers at the end of every sprint.

Your product organization must work similarly. The product organization can’t say we’re going to build this suite of features based on these hypotheses, then turn around and wait eight months before a customer ever gets a chance to lay eyes on it. That’s Waterfall.

In our experience, most people hip to Agile understands the Dev teams’ work intuitively. Epics decompose into features. Features into stories. The work flows through some tiered governance model. The delivery teams are rapidly putting increments of tested products on the market. Typically, we see some automation to mitigate the risk of escaped defects. Pretty standard.

But how do you do that with a product assumption? The names and faces may look a little different for product organizations, but they have the same principles. We’re looking to quickly get a lightweight version of the assumption—an MVP if you will—in the market. We want to validate that assumption with real people as fast as possible and then apply what we learn to the next batch of work.

How Agile is Your Product Organization?

If you want your product teams to be more Agile, there are three critical categories they should focus on: prioritization, prototyping, and metrics.

Prioritization  

Most organizations don’t lack ideas. There are a ton of ideas inside every organization. And when you have a ton of ideas, you need a way to prioritize them that isn’t just a gut feeling. You need a methodology that uses metrics and data to help you decide what to build and when to build it.

Every organization is different, but your criteria might be something like Business Value to the organization + Business Risk Metric + Level of Validation Required = Proceed or Holdoff. Whatever your specific criteria are, you must have a way to marry the art and the science of product development to ensure you make the appropriate level of investment.

In a company full of ideas, people are going to have opinions. And developing a methodology to prioritize what you’re going to build will enable you to keep the feelings out of it, have value-based conversations as a team, and ultimately make better decisions for the business.

Prototyping

Remember when we were talking about an MVP assumption earlier? That’s what prototyping is. Things inevitably cost more as they move down the product line. The goal of prototyping is to create the most realistic façade of the product you can without actually building it so that you can get feedback from your customers.

Think about the old-timey towns in Western movies from the 60s. The sets would only include the fronts of the buildings. As an audience member, you got 10% of the buildings but 90% of the experience. We’re doing the same thing.

We want to give our customers 90% of the experience. Just enough usability. Just enough navigation options. Just enough so we can see how they interact with it and use it when left to their own devices.

You can prototype in Photoshop, PowerPoint, Keynote, InVision, or Figma. Regardless of how you build a prototype, it needs to be lightweight, cost-effective, and take up the least amount of bandwidth possible from the rest of the organization.

Once you validate your assumption with the customer, you can begin the technical work, get Ops involved, and Support when necessary. You want to be careful you’re not jumping down the product line too early.

Metrics

Metrics are tricky due to every organization’s unique structure, values, risk tolerance, and current reality. That said, understanding things like feature development cost, customers gained, feature usage, and revenue are safe bets, regardless of the organization. Mileage may vary on all of these, but the point is that you need to have a way of understanding what success looks like.

And if you’re only measuring features built or hours spent—those don’t have any business value, so they’re hard to get excited about and don’t mean anything at the end of the day.

The Benefits of Agile in Product Organizations

Alright, we’ll admit it. We said delighting your customers was easy, but maybe it’s easier said than done. It’s going to take some planning. But it’s worth it. Here’s why.

Once you nail prioritization, begin prototyping like a boss, and have tangible business metrics to tie it back to—it’s like you’ve discovered this new hidden superpower. Suddenly, you’re stacking cash, keeping stakeholders happy, providing your teams meaningful work, and ultimately delivering products your customers crave.

And happy customers are always the number one hallmark of any successful business.

LeadingAgile Studios is our latest offering where our team of expert builders and creators help enable our clients to boost their capabilities and reach their Agile goals—faster and easier.

In this conversation, LeadingAgile CTO Matt Van Vleet and Principal Engineers Kevin Smith and Daryl Kulak share cases of real problems we’ve solved for our clients, and how our offerings have helped them meet their range of Agile goals.

Click here to learn more about LeadingAgile Studios

There’s a part of Transformation that’s essential that we don’t talk about as much—expenses. During Transformation, we mainly focus on variable expenses because those costs are negotiable. The most often overlooked variable expense during Transformation is external vendors, likely because they aren’t technically a part of your company.

It’s no surprise that companies don’t want to pay to Transform external vendors, in the risk that the people will leave after the contract is up, or the vendor won’t support the changes. But, even if they don’t make up a significant part of your workforce, they will stall your progress if they are unwilling to adopt your Agile way of working.

The external vendor we encounter the most—especially at large organizations—is contract employees. There’s an obvious benefit to contract employees because you can have a minimum number of staff and contract out the rest. The ratio will depend on the company and how they view their technology: is it a significant competitive advantage to invest in, or more of an expense? A company adopting Agile might be moving from IT being an expense to a strategic differentiator they invest more in during Transformation. It’s essential to understand your needs, how your vendors will fit into your Transformation goals, and what the relationship will look like afterward.

The Weight of External Vendors

Even if your external vendors only make up 20% of your workforce, that will weigh down your Transformation if they aren’t willing to get on board.

The biggest issue is the financial weight of vendors. They’re an expense that you need to run your company, but when you’re transitioning to a new way of working, you’ll have to decide if you’re willing to train them or find new ones. Many external vendors are used to save money in the long run, but it might end up being a more significant investment you have to make. You can’t have your vendors working in opposition to your Transformation goals.

Then, there’s the risk of running into other issues that are common with external vendors. A high turnover rate negatively affects your predictability and costs you more money to keep training new people. If they lack the commitment to the vision and resist the changes, this can tank morale among your full-time employees and leave them questioning, “what’s the point?”.

Overall, it’s critical that you have vendors that align with helping you achieve your goal of Agile Transformation and help you along the way, not hold you back. It should be a part of your Transformation plan to asses current vendors, get them on board, or invest in finding new ones that support your vision.

Turning Vendors into Assets

 There are two options for handling vendors.

1. Train Your Vendors

Even if your current vendors are willing to accept the training, you can encounter struggles there, too. They can be just as resistant to change as your full-time employees, not stick around for the long run, and depending on their current skillset, training could take a long time. This isn’t ideal if your goal is flexibility and saving money.

2. Find New Vendors

Look for vendors that better align with your needs. This can be tricky to navigate because there are different practices within Agile, and not every organization practices Agile the same way. If a vendor says they have Agile teams to offer, you need to ask detailed questions about how they operate to ensure their Agile mindset is the same as yours.

For example, if you ask how long their sprints are and they say “six months,” that’s not Agile. You need to get to the bottom of their understanding of Agile to be sure you’re on the same page. Unfortunately, some companies only say they do Agile as a marketing tactic and don’t follow the practice. The problem is that you probably won’t find ones that match exactly what you need and align completely with your Agile Transformation strategy.

3. Work with LeadingAgile & Our Studios Team

An option that we provide at LeadingAgile, we work alongside vendors, help train them, and show them the ropes of any Transformation we’re a part of. But in the best interest of our clients, we’ve found that having people who are well-versed in the LeadingAgile way of doing things is the quickest road to accelerate a Transformation and get our clients the help they need when they need it, and can ramp up that help or taper it off as the Transformation matures. This is why we set out to create a Studios offering of highly qualified developers who are ready to assist you in your Transformation and can hit the ground on day one with little to no onboarding and start adding value immediately.

With that level of experience provided by your external vendors, they become an asset to your Transformation. They have gone through a LeadingAgile Transformation before, so they understand the structure, governance, and metrics of your Transformation and value the same things that you’re trying to get your organization to value. It takes the stress out of finding more vendors and can speed up the Transformation process to work with those who already know what they’re doing.

The Impact on Transformation

If we don’t correctly leverage vendors, it becomes an anchor to Transformation. If you’re only spending time investing in how you want your software to be built and not building expectations with your teams and vendors, it will cause problems.

Addressing external vendors needs to be done across the organization as part of the larger picture of Transformation. Contracts should be updated with current vendors to cover changes made to your operations. For any bids made to new external vendors, be sure that the requirements are understood from the beginning. Get detailed in the contracts you present to these vendors, specifics like you want the code written in a certain language or automated tests in these places. Then, you only pay or accept the code when it passes your tests. The more specific you can get, the better.

Once you’ve built clear expectations, your employees and partner organizations can help you during Transformation. As a result, they will get better at writing software the way you want it written, managing teams and backlogs the way you want, and leveraging that foundation to carry it forward as the organization moves through Transformation and beyond.

We’re exploring product fit and its role during Agile Transformation. A big part of what our Studios team does is help with a product assessment to ensure the product our clients build is the right one for their customers, the market, and the organization’s Transformation goals.

In this video, we share unique perspectives from a Customer Experience and Product Management POV, symptoms of bad product fit, and a crash course on assessing how the product and everything around it fits into the end-state goals of the Agile Transformation.

Including technology in your Agile Transformation Roadmap is essential because you will have dependencies if you only transform people and processes. When technology is not addressed, it will slow down your Transformation because legacy technology doesn’t always fit into new product development or overall goals.

This video explores the five aspects from a technology perspective that need to be included in your Transformation roadmap so they can be addressed early on to set you up for success:

1. Workforce Capabilities

2. Evaluating Automations

3. Infrastructure Deployment Strategy

4. Application Architecture

5. Tech Dependencies

The Agile marketplace is evolving. Large companies are looking for different solutions than they were ten years ago. Therefore, Agile must evolve too. Watch this video to get an insider’s perspective on what’s new in the marketplace, what we’ve done to address the emerging needs of the businesses we work with, and how we account for the concerns of the key stakeholders and executives who run them.

During Transformation, we need a way to measure its performance and improvements to the organization so that leaders continue to support the initiative. Metrics need to be used to help teams get better over time and drive the right kinds of outcomes that leadership is looking for.

In this episode, Mike Cottmeyer shares his insights into different Agile metrics and what are the right ones that give leaders what they need to make the necessary changes to the system and improve overall performance.

Want to listen only? Here’s the audio:

Contacting Mike Cottmeyer

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

LeadingAgile: https://www.leadingagile.com/guides/mike-cottmeyer
LinkedIn: https://www.linkedin.com/in/cottmeyer/
Twitter: https://twitter.com/mcottmeyer
Email: mike@leadingagile.com

Contacting Dave Prior

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

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

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

Interested in CSM or CSPO Training?

You can find all the details at https://www.leadingagile.com/our-gear/training/

 

To be successful at Agile, you have to first eliminate what’s keeping you from it.

Find out about the top 5 hidden DevOps considerations nobody seems to talk about that are killing many Agile Transformations—and how to plan your Transformation so they won’t stand in your way.

Relevant Resources:

Why do Agile Transformations Fail?

Agile Transformation Collection

When you create an Agile Roadmap, it’s all about getting people to change and making the change sustainable and lasting. But change is hard and people tend to resist it. The thing is what derails Transformation isn’t actually your teams and executives not wanting to change, more often it’s that they don’t actually see how to get from point A to B safely and pragmatically.

All they can see is the magnitude of what must happen. The impediments, the dependencies, and resistance—and they don’t know what to do about it all.

But if you can provide a pragmatic roadmap, or plan of attack for how to deal with dependencies, overcome resistance, and clear organizational impediments, you’ll find your people and executives are actually very willing to change and will buy into it.

In this video, Mike Cottmeyer explores what’s required to create an Agile Roadmap so the organization can get a really clear plan for what kinds of changes are going to be made, when, how to get started and get executive buy-in, who is going to make the changes, what to expect along the way. Watch the video and find out how to get everyone to see what’s possible, create safety for your people and your business, and build trust along the way.

Chapters

At :50, Mike answers the question What is an Agile Transformation Roadmap? Then, at 01:08 you’ll hear a Step-by-Step Guide to Agile Transformation. At 6:50 explore How to Measure Success in Agile Transformation and at 12:42 find out How Leadership Can Leverage an Agile Roadmap.