Skip to main content
Here's the White Paper You Requested

While you’re here, be sure to check out some of our other videos and white papers. If you have a question or want to discuss any of these topics, feel free contact us or email our CMO directly by clicking his headshot below.

Tim Zack
Video
Why LeadingAgile?

Let us show you how to safely and pragmatically introduce agile into any size organization

Watch
Video
Agile Transformation Explained 47 Min Watch

Learn how to achieve true business Agility.

Watch
Blog
Dependencies Prevent Agility 5 Min Read

How do you form Agile Teams? You break the dependencies.

Read

Dependencies Prevent Agility

A truly Agile team isn’t just any random group of people and it’s not a group of business analysts doing a daily standup to coordinate their work either.  It’s not merely a group of developers that meet every other week to do sprint planning. Nor, is an Agile Team a project team with folks matrixed across two or more other Agile teams.

What is an Agile team?

An Agile team is a cross-functional group of people that have everything, and everyone, necessary to produce a working, tested increment of product.  Dedicate these people to the team, and as a rule, do not move them between or across teams as demands ebb and flow.

I’m going to suggest that the very definition of an Agile team is getting in the way of forming Agile teams. Mostly, because we misunderstand what a product actually is.

In the small, this guidance is clear, it’s the system.  All the way from user interaction to data and back and all the abilities to deploy and install said product into production. However, in the large, forming a team like this isn’t usually possible, and often not advisable—even if it is possible.

Also, in the large, a product is actually a sub-system of a larger systems-integration.

When you look at a product this way, it’s often possible to create a small, cross-functional group of people that has everything—and everyone—necessary to produce a working, tested increment of product.

Business Capabilities

You should organize around products, or features, where you can.  Organize around subsystems where you have shared functionality. We call these business capabilities, collectively. Once you have the business capabilities understood, align the business capabilities with the technical architecture and ultimately the organizational architecture.

The intersection and alignment of business, technical, and organizational architectures are where you form a complete cross-functional group.  A team of people that have everything—and everyone—necessary to produce a working, tested increment of their part of the product.

Because your business, technical, and organizational architectures are probably broken—you will have dependencies between these teams that you are going to have to manage. For now.

Dependencies

Over time, the job of the Transformation initiative is to break these dependencies because dependencies are evil and you need to break them.

The more you manage dependencies the less Agile you will be. Period.

Over time, as you break dependencies, you will be able to treat each of these teams as pure Agile teams.

Start forming teams that align business capabilities with technical and organizational architecture. Then, you are ready to begin the hard work of breaking dependencies. If not, all you can do is go through the motions of Scrum. Until you break the dependencies, you will never get the value you are working towards.

The reason you’re not feeling very Agile is that you don’t have these kinds of teams.  You have way too many dependencies.

No amount of daily standup meetings are going to fix this problem.

An Agile culture won’t do the hard work for you.

White Paper
Agile Transformation Whitepaper 74 Min View

Learn what a structured Agile Transformation is supposed to look like.

View
Video
Our System of Delivery 16 Min Watch

Maximize the flow of value in your organization.

Watch
Podcast
Prioritizing the Work to Maximize Return 42 Min Listen

This series focuses on how to build an organization that can embrace change.

Listen

Prioritizing the Work to Maximize Return

This week, on SoundNotes, we’ve got Part 3 of a trio of interviews with LeadingAgile Chief Methodologist and Co-Founder Dennis Stevens. The series focuses on how to build an organization that can embrace change. In the final episode of the series, Dennis and Dave cover how to prioritize work being done to maximize return.

During the interview, they discuss how prioritization at all levels of the organization can support the ability to inspect and adapt and how some lingering traditional approaches to work, compensation, and prioritization can have a negative impact on your organization’s ability to embrace change.

Links

If you’d like to check out the first two parts of this interview:

Here are links to the two other podcasts mentioned during the interview:

Here is a link to the article he co-authored for Harvard Business Review

Contacting Dennis Stevens

Contacting Dave Prior

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

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/

Video
Our Transformation Hypothesis 5 Min Watch

A systems-first Transformation is a sustainable Transformation.

Watch
Podcast
Culture is the Boogeyman 43 Min Listen

Assume you could flip culture overnight. What’s next?

Listen

Culture is the Boogeyman

“Culture is just the boogeyman people use when they don’t know how to articulate an organizational change management strategy that executives will buy into.”
~ Mike Cottmeyer

In this episode of SoundNotes, LeadingAgile CEO, Mike Cottmeyer shares his thoughts on why we need to stop blaming culture when organizations are unable to adopt Agile. During the interview, Mike and Dave dig into the reasons why many of the organizations that struggle with Agile are dealing with deeply rooted mechanisms that extend far beyond culture. Unfortunately, one of the most common refrains in the Agile community is that the culture is the primary thing that must be addressed, and once that is solved, the rest will take care of itself. For many organizations that buy into the promise of Agile without having clarity on the organizational impediments they must overcome for Agile to be able to exist, maybe culture isn’t the best place to start.

If you’d like to read Mike’s blog post on the topic, you can find it here: https://bit.ly/2pO8YU4

Contacting Mike

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

Contacting Dave

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

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/