DZone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
Refcards Trend Reports Events Over 2 million developers have joined DZone. Join Today! Thanks for visiting DZone today,
Edit Profile Manage Email Subscriptions Moderation Admin Console How to Post to DZone Article Submission Guidelines
View Profile
Sign Out
Refcards
Trend Reports
Events
Zones
Culture and Methodologies Agile Career Development Methodologies Team Management
Data Engineering AI/ML Big Data Data Databases IoT
Software Design and Architecture Cloud Architecture Containers Integration Microservices Performance Security
Coding Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Partner Zones AWS Cloud
by AWS Developer Relations
Culture and Methodologies
Agile Career Development Methodologies Team Management
Data Engineering
AI/ML Big Data Data Databases IoT
Software Design and Architecture
Cloud Architecture Containers Integration Microservices Performance Security
Coding
Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance
Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Partner Zones
AWS Cloud
by AWS Developer Relations
Building Scalable Real-Time Apps with AstraDB and Vaadin
Register Now

Trending

  • Observability Architecture: Financial Payments Introduction
  • Competing Consumers With Spring Boot and Hazelcast
  • Effortlessly Streamlining Test-Driven Development and CI Testing for Kafka Developers
  • Microservices With Apache Camel and Quarkus

Trending

  • Observability Architecture: Financial Payments Introduction
  • Competing Consumers With Spring Boot and Hazelcast
  • Effortlessly Streamlining Test-Driven Development and CI Testing for Kafka Developers
  • Microservices With Apache Camel and Quarkus
  1. DZone
  2. Culture and Methodologies
  3. Agile
  4. Aggressive Decoupling of Scrum Teams

Aggressive Decoupling of Scrum Teams

Mike Cottmeyer user avatar by
Mike Cottmeyer
·
Dec. 23, 14 · Interview
Like (0)
Save
Tweet
Share
12.85K Views

Join the DZone community and get the full member experience.

Join For Free

What does aggressive decoupling look like?

Last post I talked about the failure modes of Scrum and SAFe and how the inability to encapsulate the entire value stream will inevitably result in dependencies that will kill your agile organization.

But Mike… as some level of scale, you have to have dependencies? Even if we are able to form complete cross-functional feature teams, we may still have features which have to be coordinated across teams or at least technology dependencies which make it tough to be fully independent.

But Mike… you talk about having teams formed around both features and components… in this case, it is inevitable that you are going to have dependencies between front end and back end systems. Whatever we build on the front end, has to be supported on the back end.

What if…

What if you looked at each component, or service, or business capability as a product in and of itself. What if that product had a product owner guiding it as if it were a standalone product in its own right?

What if you looked at each feature that might possibly need to consume a component, or service, or business capability as the customer of said service who had to convince the service to build on it’s behalf?

What if the component, service, or business capability team looked at each of the feature teams as their customer, and had the freedom to evolve it’s product independently to best satisfy the needs of all it’s customers?

What if the feature teams could only commit to market based on services that already existed in the services layer, and could never force services teams to commit based on a predetermined schedule?

What if feature teams could *maybe* commit to market based on services which were on the services teams near term roadmap, but did so at their own risk, with no guarantees from the service owner?

What if feature teams were not allowed to commit to market based on services that didn’t exist in the service, nor were on the near term roadmap, eliminating the ability to inject features to the service?

I think…

I think you’d have a collection of Scrum teams… some Scrum teams that were built around features and some Scrum teams that were built around shared services and components… each being treated as it’s own independent product building on it’s own cadence under the guidance of it’s own PO.

There would be no coordination between the feature teams and the services teams because each set of teams would be evolving independently, but with a general awareness of each others needs. The services teams develop service features to best satisfy the collective needs of their feature team customers.

So…

I’m not suggesting this something that most companies can go do today. There is some seriously intentional decoupling of value streams, technical architecture, business process, and org structure that has to happen before this model would could be fully operational.

That said, if you want to have a fully agile, object oriented, value stream encapsulated organization, this is what it looks like. You not only have to organize around objects (features, services, components, business capabilities), but you have to decouple the dependencies and let them evolve independently.

The problems ALWAYS come in when you allow the front end to inject dependencies into the back end shared services. You will inevitably will create bottlenecks that have to be managed across the software development ecosystem. Dependencies are bad, bottlenecks might be worse.

If we can create Scrum teams around business objects, work to progressively decouple these business objects from each other, and allow the systems to only consume what’s in place now, and never allow the teams to dictate dependencies between each other… I think you have a shot.

Do this, and you really have agile at scale.

scrum agile Decoupling (electronics)

Published at DZone with permission of Mike Cottmeyer, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

Trending

  • Observability Architecture: Financial Payments Introduction
  • Competing Consumers With Spring Boot and Hazelcast
  • Effortlessly Streamlining Test-Driven Development and CI Testing for Kafka Developers
  • Microservices With Apache Camel and Quarkus

Comments

Partner Resources

X

ABOUT US

  • About DZone
  • Send feedback
  • Careers
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • Become a Contributor
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 600 Park Offices Drive
  • Suite 300
  • Durham, NC 27709
  • support@dzone.com

Let's be friends: