Work: Agile thinker, writer, project manager, consultant, CEO Life: Catholic, husband, dad, guitarist, backpacker, coffee drinker. Backpacker is aspirational.
Joined January 2008
- Tweets 12,351
- Following 916
- Followers 7,178
- Likes 237
28 Photos and videos
10 Aug 2025
Last weekend I started playing with the idea of dependencies. Why? In my experience dependencies are the primary impediment preventing Agile methods from producing a potentially shippable increment of software at the end of a sprint and… dependencies are the main impediment preventing the team from responding to change when they learn new things.
Here is the breakdown: Define a way to measure the business value you want to create. Align that value to a single business capability or product capability. The capability should encapsulate the domain. Domains should encapsulate sub-domains. Sub-domains should encapulate bounded contexts and data. Of course there are exceptions.
One-to-many relationships are fine. Many-to-one and many-to-many relationships cause dependencies and create bottlenecks in the system.
Turtles all the way down.
2
10
297
10 Aug 2025
Wrap capabilities or domains or sub-domains or bounded contexts with teams. Those teams deliver against encapsulated objects at whatever level maintains the 5-7 person team size. If the stories a team works with have to be integrated into higher order features that span teams, that isn’t ideal, but that is where some sort of lean, value stream oriented, program or portfolio governance comes in. You could also use SAFe in this context to orchestrate several integrated teams. If interactions are minimal and orchestration is light, you could even use a scrum of scrums metaphor.
7
197
5 Aug 2025
Let's keep playing with this idea of dependendencies. Dependecies show up as constraints in our system. The more dependencies, the harder it is to change when we learn new things about our customers and what they need. If we want to be able to change when we learn new things about our customers and their needs, we have to elminate, or at least mitigate, the impact of dependencies. If we see any constraint in our system as immutable, we will design systems around those constraints, likely resulting in a suboptimized system. Transformation can happen when we are able see past constraints, and imagine what might be possible, and go there.
5
138
4 Aug 2025
If dependecies kill agility, what exactly is it they are killing? I define agility as the ability to deliver in such a way that we can put our products in front of customers, get feedback, and change direction when we learn new things about what they want or need. The more dependencies we have, the harder that goal is to achieve. At smaller scale dependencies limit agility. At larger scale, dependencies kill agility. Dependencies do not prevent you from 'doing' Scrum or SAFe. But at best Scrum and SAFe are only proxies for agility. At worst they are process theater that only get in the way.
5
135
3 Aug 2025
This feels like an irreducible truth to me. Dependencies kill agility. This is true when we talk about Agile. And it's true when we talk about agile. It's not methodology dependent. Any time one actor has to coordinate with another actor to make a change, or add a feature, this slows down both actors and makes it impossible for either to move independently. In the presence of dependencies, you either have to manage them or break them. You cannot ignore them. There are agile ways to manage dependencies, but they still slow you down. This is true in Scrum, this is true in SAFe. Every problem in the modern agile movement comes down to the failure to either manage or break dependencies.
3
155
Mike Cottmeyer retweeted
8 Apr 2025
RT if your team won the national championship
41
2,493
2,640
146,120
Mike Cottmeyer retweeted
7 Feb 2025
CIOs face a common challenge: justifying the cost of operating model improvements. To justify the cost of change, you need to approach transformation a certain way. You need:
🔹 An approach with defined, repeatable steps so that the benefits of each step can be forecasted based on historical data, either within the organization, industry, or the market at large.
🔹 A roadmap that shows how different parts of the organization will progress through those steps over time so that the timeline to ROI can be factored in.
🔹 A model for turning transformation outcomes such as Quality and Value Density into dollars allowing you to calculate the NPV and IRR of your investment.
🔹 A robust set of assessments and metrics to ensure ROI targets are being met once the work is underway.
Learn how we create a transformation roadmap: go.leadingagile.com/bom
2
7
268
Mike Cottmeyer retweeted
29 Jan 2025
Dependencies aren’t just bottlenecks—they’re expenses hiding in plain sight. Every time a team waits on another team, or you need a meeting to align priorities, the cost of delivery increases.
These costs not only show up on the balance sheet, but they also impact your speed, predictability, and ultimately your ability to compete.
Dependencies slow everything down, but they also create an invisible tax in the form of coordination overhead, missed opportunities, and wasted effort.
The more your teams rely on external resources, the higher the hidden costs of managing those relationships. Every delay and handoff introduces risk, inefficiency, and frustration across the organization.
The solution? Focus on creating self-sufficient teams. By equipping them with everything they need to deliver independently—skills, tools, and resources—you eliminate these hidden costs and allow your teams to move at full speed.
When your teams don’t need to coordinate constantly, they can focus on what matters most: delivering value to your customers. And that’s a competitive advantage you can’t afford to ignore.
How are you currently managing the hidden costs of your dependencies? Could you be investing in autonomy instead?
1
5
177
13 Feb 2020
Putting the Enterprise Back in Enterprise Architecture w/ Ross Beurmann dlvr.it/RPyvVM
1
3