The world is not binary, it is context-sensitive
As people start to change their ways of working, people often think in absolutes. In a learner's eyes, ideas, practices, and patterns are…
As people start to change their ways of working, people often think in absolutes. In a learner's eyes, ideas, practices, and patterns are often treated as either all good or all bad.
This polarity can be a powerful way to show contrast, the devil is in the detail and there is often far more nuance required to appreciate context and learning over time.
This type of behavior isn’t exclusive to the agile community, in fact in many cases it is a cultural norm that has been around for a long time.
Individual vs team (collective)
Autonomous vs command and control
Scrum vs Kanban
Project vs product management
Hierarchical vs flat organizations
Global vs local optimization
Microservices vs monolith
Ordered vs chaotic
Worker vs manager
Good vs evil
I’m sure you could easily add your own examples too, I struggled to stop producing examples when writing this article. I suspect the reason for this is generally because people like simple models they can use when thinking about the world. We know from Complex Adaptive Systems, Cynefin and other such heuristics that the world is far more nuanced than simple vs complex.
We know that people crave simplicity, culturally we often say that reducing complexity is always a good thing. Even that isn’t always true, this is especially true for human / natural systems. There’s unintentional and intentional complexity, knowing which one you have will help you know how to respond and act.
You cannot physically simplify the human body or the solar system, even if you can produce models that abstract the detail, to useful levels of granularity for practical purposes. e.g. Biology, Chemistry, Physics (including Newtonian, Einsteinian, Quantum) all afford for useful systems for reasoning about the world at differing levels of granularity. Quite often those levels are also arbitrary and are there for thinking rather than being a physical separation.
So how does this manifest in the real world and how can this help our way of thinking and working?
Putting things into practice
When thinking about your teams, your departments, your organization and beyond thinking in absolutes can often be a quick and dirty way to get things done but that can quite often end up in missing the bigger picture.
When people start learning and changing how they work, it is easy to jump from one extreme to the other and often taking giant leaps can lead to large failure which then creates a negative feedback loop.
e.g. ‘We tried ‘agile’ and it was fine for our team but we had too many dependencies on other teams so we couldn’t get anything done, so we stopped’
It may seem obvious, taking an incremental approach to building up and adopting practices is a far more pragmatic way for people to keep their heads above water as they learn as a team.
I see a common anti-pattern where a team (new or existing) are told to simply start doing all of these ‘ceremonies’ (events, rituals etc..) from day one rather than starting to build them up over time, getting value out of them or tweaking them until they do work.
Once the team starts getting into a rhythm and trusting each other, they often top out with local optimization because teams do not exist in isolation inside of large complex organizations.
This is confounded even further in an environment where people are talking about scaling agile (whatever that means). To keep it simple and agnostic, this often means having a delivery structure setup that is somehow up to 150 people in a team of teams' formation with some sense of common alignment, purpose, and mission.
This grouping of teams can make sense when it ‘belongs together’ (cohesive) or it could just be a grouping of teams that have the same leadership and teams are grouped more in the form of a fruit salad / miscellaneous configuration because we didn’t have an obvious team of teams to belong to.
Target state thinking can be misleading
As a recovering Enterprise Architect / Domain CTO, I know how easy it is to fall into the trap of thinking in current and target states. Target states from an architecture and roadmap perspective can be quite alluring and a powerful way to sell a dream. We cannot predict the future and what we think the target should be vs how it ends up can vary wildly.
It can be useful to think of the future, but it should be done at differing levels of planning, granularity (precision) and it should be focused on the outcomes rather than the solutions.
You cannot be responsive and agile if you are chained to a predefined way of doing something that is the wrong thing to do. We learned this during COVID, we should not forget it! Plans went out the window and people reacted, they made decisions and adjusted based on feedback.
In a typical ‘Agile Transformation’ people are given a formulaic way of thinking about grouping the organization into teams, team of teams etc and this gets people thinking about a delivery structure. This leads people to believe that things are simple, and people can just move the pieces around and set things up as they want. The issue here is a top-down set of decisions rather than a vision / north star that enables people to self-manage around the mission.
Top-down decisions made in isolation are a recipe for a traffic jam. The people that do the work are the ones who understand the interdependencies between teams, systems, and components. I’m a fan of the approach Daniel Mezick and team take with regards to Open space Agility. People are invited into the discussion to try things for themselves, and this creates a sense of ownership and investment in the solution rather than being told what to do.
From Better Value: Sooner Safer Happier (BVSSH) ‘Invite over inflict’ continues to stick in my mind, it sends a powerful message.
If a set of practices are imposed on people, they are less likely to embrace, especially if they are sceptical and lacking in social proof. If things fail, they will blame the system or the leadership and won't take the time to continue to experiment, learn and adapt.
The teams were supposed to be autonomous, however without understanding the system of work and the flow of value, making changes to the teams without making changes to the systems and capabilities we end up increasing the cognitive load of the teams and increasing fragility of the system of work. Now more coordination is required to get simple things done and this quickly becomes the antithesis of agile.
BVSSH, ‘Want to scale agile? Don’t. Descale the work first. Achieve big through small.’
Without changing the underlying system of work you really cannot scale anything. This is where thinking about things like Team Topologies, interactions and team boundaries can be quite helpful. If you want to have more autonomous teams, autonomy can be created through internal developer platforms that reduce the individual team complexity and offload to a platform that solves the problems for many teams.
Having autonomous teams doesn’t mean, that every team needs to be independently solve every problem themselves. The teams need to be able to deliver value independently. Teams can leverage platforms to solve common problems, a single team doesn’t create hardware from scratch, they leverage virtual infrastructure, so why can’t they move further up the stack to focus on what is valuable to the teams' customers / consumers. Wardley Mapping can help visualize the value if you are looking for a way to focus on what matters and to whom.
This can only be done if there are problems solved by other teams that help them get there. If you don’t think about this, ahead of time you will end up in a long dependency chain that often resembles a Rube Goldberg machine.
This is a dangerous time and requires persuasive communication and expectation setting with leadership. Their lack of patience and existing book of work that needs to get done will be impeded by a new people configuration whilst still having an existing system configuration. The result is a traffic jam, and everyone becomes frustrated, and trust starts to erode.
A tightly coupled environment requires disciplined / structured coordination of releases. This means teams are tied to a fixed release cadence to get things synchronized. This isn’t a long term solution but it is a temporary measure to align on the beat of a drum. This is often where SAFe is able to get some benefits in the system as this forcing function occurs above the team level and emphasises getting things done at a higher level (a feature, rather than simply a component) so in theory there is a chance that the release will be more useful as it has all of the individual pieces being released at the same time.
I don’t like this approach, but I understand it, it may be that a short term forced cadence across many teams can at least be a way to focus on aligning to the customer / consumer of the product but that can only be a scaffolding until the underlying dependencies and technical debt issues are resolved. Making sure these dependency busting items are part of the team of teams level backlog is crucial and ensuring that product leadership are prioritizing this work as valuable must occur or you’ll quickly end up in an IT vs business debate all over again.
SAFe (whilst I’m not a fan in general) at least tries to acknowledge this problem with the idea of a Release Train and a Release Train Engineer (RTE). I’m not sure if the intent is to purely have someone who understand the value stream to enable things to be delivered or if there is enough focus on improving the system of work and optimizing for flow by descaling. I’ll leave that topic to the SAFe enthusiasts to discuss / answer.
The idea of having someone responsible for system complexity and flow of work can make sense if they were there to manage and improve, rather than to keep things held together.
Chris Matts imprinted the notion that an architect in an agile context, focuses on managing future risks and reducing the cost of change over time. This lookout type activity is crucial but equally you should not only look out or look too far as you may not see the rocks the ship is about to hit.
Addressing current problems and future problems from an architectural perspective will allow for a balanced way of helping teams in the short term and long term.
The teams themselves must participate and see the benefits rather than the architect being treated as someone above them. The architect is taking a different perspective, they also want the same outcomes.
This is also where having a common backlog that ties the greater aspirations together with the teams can be helpful as it allows for a convergence on intent and outcomes. Linking work that creates greater independence to the intended outcomes helps everyone understand the why and not just treat the items as ‘techy’ or ‘esoteric’. If your architects can’t explain these risks to product and delivery focused people, then they aren’t going to be effective.
Having this feedback loop between teams and the team of teams is critical if you want to optimize for value whilst also optimizing for flow.
Wrapping things up
Where possible, look to avoid an absolute / extreme approach of A or B, in fact in many cases things are a spectrum and since they depend upon context taking an all or nothing approach can be dogmatic and turn you into an agile extremist.
Listening to people, observing their patterns, and taking small steps to work through the problems is far more useful and long lasting than coming into an environment and telling everyone that you know best, and they need to use Scrum / Kanban because of your experience / expertise.
Understanding problems and understanding the cause is far more useful than applying a band-aid solution and walking away.