When an organization decides to adopt agile the way it is structured often has to change. An agile way of working also brings along new practices for teams and managers, and usually impacts the organizational culture and mindset. All of these are related, but changing everything at the same time might be a too big challenge for an organization. The question then would be where we should focus on when we start an agile transformation: Culture, practices or structure? Let’s explore what can happen when we start with the structure.
Mike Cottmeyer shared his thoughts on agile transformation in big companies. He described that in agile adoption culture, practices and structures are all related to each other:
The first line of the Agile Manifesto says that we are uncovering better ways of developing software by doing it and helping others do it. How we implement agile is supposed to change over time, and how it changes should be guided by the values and principles in the Manifesto. The challenge is that the values and principles are supposed to guide the practices and structures we choose to implement. The values and principles don’t live by themselves or in a vacuum. To successfully implement agile, we have to have a system of delivery and supporting practices which enable the values and principles to be lived out.
The question Mike asks himself is how you can start agile adoption in large organizations, which are both big and complex. What do we need to change first: Should we focus on the organization culture, start introducing new practices or modify the structure?
Many of us suggest that ‘big and complicated’ is the problem and that we need to be ‘small and simple’. I agree… but, these companies ARE big and complicated so the question becomes HOW to help them become small and simple. Just saying BIG is bad and you should be SMALL doesn’t help. How do we get there? What is the path from A to B? Is adopting an agile value system enough? In the presence of the right value system, will the right delivery systems and practices emerge? In the presence of the right practices, can I impact the end-to-end system of delivery and make the cultural changes I need to make?
Tirrell Payton wrote a blog post about 5 common problems with Scrum adoption. One common problem he mentioned is that existing structures can hinder the successful adoption of agile:
The biggest pit fall is the organization leadership tries to tweak Scrum to force-fit into the existing organization structure and hierarchy. Some of the tweaks that are like to happen are;
- Managers jumping to role of Scrum Master still using a command and control style of leadership,
- Individuals working in silos without a team concept,
- Product Owners being pushed into the job without knowing the roles, responsibilities, and time commitments.
- Scrum Master being unduly influenced by managers.
According to Tirrel executive support is needed to change the organization structure where needed for agile adoption:
Executive management need to understand that Agile transformation is a major organizational change and not merely project level coaching. So every support functions in an organization need to support agile transformation.
Lot of executive support and direction may be required for agile adoption, to push the change top down the layers and they have to continuously monitor the progress and remove organizations impediments that surface time-to-time.
Alok Kumar, Frank Castagna and John Maher published an article on the Scrum Alliance website about challenges and considerations on enterprise agile adoption. To adopt agile we need to change the way that an organization structures and manages their operation:
In today's world, organizations lay great emphasis on becoming Lean and nimble so that they can meet customer expectations and remain ahead of the competition. This requires effective collaboration between business, systems, and operations to deliver innovative solutions quickly and effectively. Agile provides the basic concepts of bridging the gaps between business and development. However, scaling these concepts vertically to program and portfolio levels requires a paradigm shift in the way it operates.
According to them top-down training is needed for agile adoption at all levels. The adoption requires changes in the culture and structure of the organization:
Since Agile is a Lean method, exposure to Lean thinking for management at all levels is critical for their shift in managerial approach. The development, care, and feeding of an Agile culture and the necessary shifts in organizational systems and roles to support a self-directed team environment can dramatically reduce confusion at all levels.
Mike Cottmeyer stated in his blog post that we should start agile adoption by changing the structure in an organization:
I’m a big believer that agile culture and agile practices are essential for long term sustainable organizational agility. That said, I don’t think you can train your way into it and I don’t think you can believe your way into it. I think you have to start with a team based organizational design where the flow of value is governed across teams using an adaptive governance model, based on lean/kanban principles, where WIP is limited, capacity and demand are balanced, bottlenecks are identified and dealt with, and management is invested in improving the overall system of delivery. Only within this kind of organization can an agile culture emerge and agile practices thrive.
According to him structure should go first, followed by the practices and then culture.
I’d suggest you begin by focusing on your business goals, articulating a strategy to create a team based organizational model, and model based on iterative and incremental delivery principles, one that uses agile and lean methodologies for delivery and governance, but that operates within the operational and cultural constraints of the existing organization and it’s policies.
Tirrel Payton stated that not changing the structure can hinder agile adoption:
Do not force-fit agile into the existing organization structure and hierarchy, in fact there are many organizations out there, who tweak agile frameworks that fit into their existing structure and hierarchy, which is the biggest pit fall.
Alok Kumar, Frank Castagna and John Maher suggest to start agile adoption with a transformation plan:
"Plan your work and work your plan." As Watts Humphrey, father of the CMM and CMMI, said, "If you don't know where you're going, any road will do." And that means implementation agents are quickly relegated to catch-up, remediation of understanding, resetting of context, and running interference for the teams they're consulting for.
They prefer to change the organizational structure if possible.
If the organization can simplify its structure, advocate for it. If not, plan to integrate across applications at the program level before moving to teams, to reduce dependencies early.
When adopting agile, do you start by changing the structure?
/filters:no_upscale()/sponsorship/topic/c7a3c369-fdfd-4c13-b1f1-4938dc3bedc5/KalixLightbendLogoRSB2023-1681370636831.jpg)
/articles/architecture-architecting-role/en/smallimage/logo-1670404086277.jpg){kind=logo}
/articles/complexity-leaders-self-context-awareness/en/smallimage/LOGO-1669970324316.jpg){kind=logo}
/articles/remote-working-team-topologies/en/smallimage/logo-1669733754633.jpg){kind=logo}
/presentations/patterns-digital-transformation/en/smallimage/qcon-plus-s-1680898572577.jpeg)
/articles/culture-trends-2023/en/smallimage/InfoQ-Trend-Report-logo-1680287660356.jpeg){kind=logo}
/articles/kafka-clusters-cloudflare/en/smallimage/tales-of-Kafka-at-Cloudflare-small-1684768928637.jpg)
/presentations/refactoring-cleaning-code/en/smallimage/kent-beck-small-1684908700538.jpg)
/presentations/devsusops/en/smallimage/adrian-cockcroft-small-1684908390875.jpg)
/articles/gdpr-with-spring-and-aop/en/smallimage/easy-implementation-of-GDPR-with-aspect-oriented-programming-small-1684505109873.jpg)
/articles/software-delivery-performance-indicators/en/smallimage/software-delivery-performance-indicators-at-different-granularities-small-1684312207072.jpg)
/articles/api-design-review/en/smallimage/API-design-reviews-are-dead-long-live-API-design-reviews-small-1684310900854.jpg)
/presentations/dark-energy-matter-microservices/en/smallimage/chris-richardson-small-1684240727275.jpg)
/presentations/techno-solutionism-ethics/en/smallimage/katharine-jarmul-small-1684239823523.jpg)
/articles/learning-ebpf-observability/en/smallimage/learning-eBPF-for-better-observability-small-1684247266792.jpg)
Community comments
Consent
by Dan Mezick,
Re: Consent
by Mike Cottmeyer,
Re: Consent
by Dan Mezick,
Re: Consent
by Shannon Tillery,
Culture follows structure
by Nils Bernert,
Consent
by Dan Mezick,
Your message is awaiting moderation. Thank you for participating in the discussion.
Does consent matter?
Can we get people to do things a certain way....long-term...without their consent?
Is threatening someone's job a way to create the "motivated individuals" described in the Manifesto?
Are mandated Agile practices the antithesis of the Agile idea?
Does engagement matter?
If I get a duly authorized leader to agree to my Agile-adoption approach and write a big check for coaching, does this mean all the duly authorized leaders are actually supporters of this plan? If not, how might that effect the results?
(There is a cascading effect. Direct reports of leaders who do not support Agile tend to avoid supporting Agile as well. )
Likewise, if we force Agile practices, does this increase or decrease engagement? Does engagement matter?
(Resisters of the Agile idea do not up and leave. Nope. They stay for years, dragging their feet and requiring the adoption to tolerate low levels of engagement even as engagement is the very fuel of a rapid and lasting Agile adoption.)
How does an Agile adoption get traction if 1/2 the people are uncomfortable moving forward?
(The idea that engagement of ALL the people is not needed at the start is a very low-quality idea. All the people in all the departments, at all levels of authorization...all of them need to be engaged. Otherwise there is trouble for a very.long.time.)
Likewise, the idea that "people who do not like it can self organize to another job" mocks the concept of self-managing teams and implies that a forcing of Agile ideas and practices can actually work long-term. I'm sorry. This is not my experience as a coach.
What is the Solution?
Any approach is OK, so long as 2 things are true:
1. Whatever is used in terms of practices honors (at least does not offend) the Manifesto;
2. People are invited to experiment with various practices, and consent to this, and are not coerced to do so.
Martin Fowler said as much in 2006, right here on INFOQ:
martinfowler.com/bliki/AgileImposition.html
www.infoq.com/news/imposed-mandated-agile-fowler
In the present day, Open Agile Adoption uses Open Space and other essential elements to solve this problem. It rejects the mandate as useful, valid or even effective. Instead, it invites formally authorized leaders to INVITE ENGAGEMENT in enterprise-level problem solving. The problem of highly authoritative external coaches conspiring with management to force Agile practices is a worldwide epidemic of command-control prescription. Part of the problem. PUSH, not pull. Disengaging rather than inviting. A virus of command-control. An encourager of very LOW levels of engagement.
This problem is solved by an open approach that invites everyone into the process of figuring it out, rather than perpetuating extremely low engagement levels with authoritative, disengaging mandates and prescriptions.
The open approach requires courage on the part of formally authorized leadership. And everyone else!
The solution is very simple. Instead of pushing a process change, use “pull” instead. Crowd-source the Agile adoption. Use invitation, instead of that nasty and ineffective mandate.
Related links:
newtechusa.net/agile/telling-me-what-i-want-to-...
newtechusa.net/agile/push-vs-pull/
www.OpenAgileAdoption.com
Videos testimonials from people who have experienced the open approach:
newtechusa.net/open-agile-adoption/open-agile-a...
Daniel Mezick
www.DanielMezick.com
Culture follows structure
by Nils Bernert,
Your message is awaiting moderation. Thank you for participating in the discussion.
You may also add Craig Larmans 4.th "Law of Organizational Behavior":
"Culture follows structure"
www.craiglarman.com/wiki/index.php?title=Larman's_Laws_of_Organizational_Behavior
Mike Cottmeyer and me discussed it in a session at Agile Coach Camp Denmark last year. It seems to nicely fit together.
Nils
@nilsbernert
Re: Consent
by Mike Cottmeyer,
Your message is awaiting moderation. Thank you for participating in the discussion.
Dan, you and I openly disagree on some of this, but I think we have some common ground. I don't think that putting things into nice neat containers is helpful here. Let me establish context.
We work with companies that are very large and complex, often with large number of dependencies, technical debt, architectural coupling, cross-cutting concerns, poor organizational design... but a need to be predictable and while making and meeting commitments to market.
It's a tough problem to solve.
We don't believe that most organizations will self-organize out of this problem. We do believe though that there is a path forward. We also believe that that path forward doesn't require universal buy in to get started.
My non-negotiables with agile are pretty small. We want complete cross-functional teams that are aligned to solve recognizable business problems. We want backlog clarity at all levels of the organization and the ability to balance capacity and demand. We want the ability to produce working tested software on regular intervals.
Within those boundaries, we think that teams should have a tremendous amount of latitude to decide how they work. I think you and I are talking past each other. You are focusing on the mandate of practices... that is NOT what I am talking about.
I am talking about a top down recognition that it is necessary for form and support TEAMS that are formed to solve business problems. Executives must empower these teams by helping them break dependencies between each other. They must support a governance model that drives clarity, priority tradeoffs, and balances capacity and demand. They must measure progress in terms of product produced... value added... not activities performed or documents created.
Teams are the mandate. Flow is the mandate. Visibility and transparency are the mandate. Alignment is the mandate. I don't give a rats ass if the team does a daily standup, a retrospective, or even a sprint planing meeting. I have never advocated for top down mandate of practices. I do believe in top down mandate of agile structure, agile governance, and agile metrics while empowering the teams to decide within those constraints.
Not sure that supports your narrative, but I hope it help publicly clear up my point of view.
Thanks!
Re: Consent
by Dan Mezick,
Your message is awaiting moderation. Thank you for participating in the discussion.
Let's play a game. The object of the game is to get a rapid & lasting Agile adoption, at scale, as fast as possible. OK?
Let's assume the org is a very large well-known retailer based in Arkansas and California with hundreds and hundreds of huge stores ... and tens of thousands of employees...
...the main impediment to Agile adoption at this company? The legitimate concerns, worries and anxieties of everyone involved. Slamming "structure" changes into the organization triggers people with very legitimate worries, anxieties and fears.
There is lots of scientific proof that triggered, fearful people do not learn very quickly.
If at all!
Agile is about generating adaptability through learning.
Fear just shuts that learning down.
Hello?
But wait. Some of the triggered people are formally authorized leaders who run entire departments and divisions. People with some authority. With direct and indirect reports. What happens when these leaders are not really supporting the Agile "structure" changes? Answer: They send very clear signals to their direct reports, who receive the signal. They ALSO (rationally) fail to support the new change initiative. They in turn send clear signals about Agile resistance to their direct reports. It cascades down the line. At the start, just one leader had doubts. Now 80 people are "skeptical at best."
Multiply that times dozens of leaders, in a large company, at scale. This is actually THE main problem.
But wait. Some Agile coaches suggest these leaders (and their direct reports) can "self-organize to another job."
Really? Does that actually work?
Because the reality is: these triggered, worried people do not vacate. Far from it! The reality is that people at a job 10 years or more are very, VERY slow to vacate. They outlast, outwit and outplay those who authoritatively slammed in the Agile "structure" change.
When this happens, we say "Agile failed." What actually failed was an attempt to force a process change on people-- the leaders and the teams-- without their consent.
And people want to be free.
The mandated approach can work. For it to work, lots and lots of people have to quit.
This usually takes many years. By then, the Agile coaches have come and gone: just like the Agile adoption itself.
Mandates create disengagement. This disengagement torpedoes the best of intentions for Agile in your company.
A Faster and More Lasting Solution- the OPEN Approach
The best way to bring process-change into an organization is to frame it as an experiment to be inspected ... and invite people into the process of experimentation and inspection. Actually implement Agile in an Agile way.
Leadership sets the context with storytelling and direct behaviors that support the approach. This is the fast-track to a rapid and lasting Agile adoption. Engage people. The people you already have! If people sense they can help author the new story, and be a character in the new story, there is no "buy in" .... because there is no need for persuasion. The people are not "bought in" .... instead, they are "LOCATED IN" ... the new story. The Agile adoption story is THEIR story.
The Open Space meeting format can scale to thousands of people. I am using this format inside a method called Open Agile Adoption. It gets great results. It frames the experience as experiments-- with inspections. There are no mandates and nothing is set in stone. It starts and ends in Open Space with a period of experimentation in between. Everything is inspected and the enterprise then adapts.
The Agile Manifesto is the single constraint- any practice can be used as long as it supports the Manifesto principles.
Pushed people are triggered people. Invited people are not. Invited people feel that the story of the org is unfolding, and that they are helping to write it, and that they are free. This generates tremendous levels of human engagement, the very fuel of a rapid and lasting Agile adoption.
Here are some video testimonials:
www.openagileadoption.com/open-agile-adoption-v...
Here are some related links:
newtechusa.net/agile/telling-me-what-i-want-to-...
newtechusa.net/agile/triggered-by-process-change/
newtechusa.net/agile/push-vs-pull/
Daniel Mezick
www.OpenAgileAdoption.com
www.DanielMezick.com
Re: Consent
by Shannon Tillery,
Your message is awaiting moderation. Thank you for participating in the discussion.
Dan,
I fully appreciate what you're saying...right down to executing the transformation in an agile way. And I completely agree that big, structural changes bring about fear and resistance, which is a very real and serious impediment to the transition.
But I have several nagging questions:
1. How do we keep these "invited people" collectively on course when they've taken on a lot of new processes/overhead but don't see immediate improvements (in fact will likely see a downgrade in productivity at first)...without at least some enforcement of adoption?
2. How do we deal with existing layers of technical/project management between the PO and the dev teams? These "intervening" layers of management *will* hand down implementation directives to the team, defeating any chance we have at real team engagement/empowerment...and by extension, team ownership of the work.
3. Related to #2, in my experience, when a company begins an agile transformation, the product owner role is distributed amongst several different actors: e.g. product managers, project managers, technical managers, technical leads. If we agree that there has to be exactly 1 gatekeeper of the product backlog, how can we make meaningful steps towards a transition without at least some localized structure changes? Of course there's nothing in the manifesto about a single gatekeeper for the backlog. But I think most teams that are truly empowered to refine their processes are going to come to that conclusion eventually.