- How can we scale agile to fit in our organization?- How do we adapt agile practices for our complex operation?- Which processes and roles must we add to make agile work for us?
Important, frequent and likely wrong questions. Let's explore!
Avoid Faux-agile
Do you have one of the following in your organization?
A PMO department responsible for resource allocation to projects?
Regular complex multiple-day increment planning events for all the teams to ensure alignment and dependency management?
A group of project managers responsible for removing blocking intergroup coordination issues to ensure the planned timing, budget and scope?
A group of scrum masters, agile coaches, architects, team leads responsible for the success of agile adoption and release plans?
Quarterly product releases that require long quality control cycles?
"Agile release trains" with a thorough agile testing at the end?
The above pairs of situations is a mixture of pre-agile and faux-agile practices.
Let's analyze the first pair. The pre-agile practices (e.g. 'PMO') rely on the idea of upfront detailed planning in order to ensure smoother and cheaper plan execution by assigning different narrow specialists to different tasks. Faux-agile practices (e.g. 'increment planning events') add a flavor of agile (usually just the terminology) to the pre-agile way of working without changing much.
Avoid Scaling Agile
Consider these questions:
How to make our PMO agile?
How to convert the architects group into the agile way of working?
How to ensure post-production quality control in an agile-friendly way?
These questions are based on thinking that the way things are is the way they ought to be.
Agile thinking that is built a lot on top of Lean thinking has never been about adding anything. The big idea is understanding the sources of the complexity and then rigorously and thoughtfully keep simplifying and improving.
This is why "scaling agile to fit in your organization" is accurately the opposite of what you should be striving for. The question should rather be: how do we change, simplify and descale to make our organization agile (or better yet adaptive)?
Think Like a Single-Team Company
Your organization is complex and requires advanced methods to manage everything that is happening in there. That's given.
Or is it accepted as given? Isn't it a sum of all previously made organizational decisions?
A big idea here is to stop accepting whatever levels of complexity you have in place. And instead ask yourself and your colleagues:
How the problem X will be solved in a single-team company?
Thinking about this question is a recipe for simplification. And it can be applied to a broad variety of situations:
We have too many feature branches with partially done work, how do we manage them?
We have numerous important objectives to reach this year, how do we manage them?
We have a lot of unclarity in the upcoming customer requirements, how do we manage them?
Each of such questions offers a cross-road: either towards adding more processes and structures (more added complexity) or towards simplifying by understanding and removing the sources of the issues.
Let's use the three questions above as examples to apply this powerful simplification method: what a single-team company will do?
We have too many feature branches with partially done work, how do we manage them? Feature branches add complexity and hence ought to be minimized or, better yet avoided, altogether. What a single-team company will do? A single-team company likely won't have any long-lived feature branches, and instead will make all the developers work on the trunk and talk to each face-to-face to address conflicts in a real-time. Managing very few (or none) branches will create a simpler, more transparent production system with fast feedback. It is a win-win.
We have numerous important objectives to reach this year, how do we manage them?Focus on too many things equals to a lack of focus. What a single-team company will do? A single-team company likely won't have too many objectives - maybe just one or two that are vital for overall success and painfully clear to everyone. Managing one or two objectives requires no objective-management-and-tracking system (not even the OKRs). A smaller number of objectives will create more focus, opportunities for joint work, a simpler organization. It is a win-win.
We have a lot of unclarity in the upcoming customer requirements, how do we manage them? Unclarity of upcoming customer requirements is expected and is rather normal. What a single-team company will do? A single-team company likely will talk directly to its customers, using quick prototypes and regular small releases to clarify the customer needs and the product implementation. A continuous process of getting feedback doesn't require extra roles of middlemen and makes organization faster and simpler. It is a win-win.
The simpler the processes and the structures, the more transparency there is. And transparency, in its turn, enables inspection and adaptation. These are the key ingredients for continuous improvements - getting better over time.
Simplification: Principles and Practices
Principle #1: Broaden the view (fighting bounded rationality)
With every built fence comes a limited view. Or in other words, people make decisions based on the information at hand. And the narrow is their understanding, the more local and suboptimal their decisions will be. The Stanford encyclopedia defines this phenomenon as 'bounded rationality'
So, how to fight non-systemic, locally optimized decisions?
What stays in the way of broadening the view to see the whole:
Backlogs and other task-lists defined at the level of the individuals or individual teams.
Limited ownership of a technology, component, module, feature by an individual or an individual team.
Managers who bring the work to the individuals or individual teams.
What helps:
Defining a broader customer-centric value area (aka 'product', 'ecosystem') that includes many teams, customers and stakeholders.
Treating the value area as a whole by making all involved teams share common objectives and work as much as possible.
Principle #2: Minimize the distance (avoiding middlemen and proxies)
Zero distance - a concept introduced by the Haier Group. It emphasizes the connection between the business and the end-user or customer. This has become central to the management model of the Internet of Things era. "Business people and developers must work together daily throughout the project." is one of the twelve principles of the Agile Manifesto.
So, no matter how you frame this principle, the organizations that enable their teams to learn to work directly with the customer make a difference.
Have you heard of teams claiming that they suffer from requirements changing often? Such a nonsense can occur only in organizations where middlemen gather and formulate requirements. And the teams are sitting and waiting for the specs to be delivered to them. Then every update to the spec is seen as an irritating requirements change, a scope creep.
Once the teams start working directly with the customers, they realize that it is the understanding that changes (and requirements really don't exist). So, the focus changes from preventing change by fixing requirements to improving shared understanding constantly.
What prevents zero distance and shared understanding:
lack of direct collaboration between customers and teams
lack of knowledge of the customer/domain language
lack of focus on improving communication skills
too much focus on internal concerns (e.g. architectural view)
too much focus on resource thinking: "developers need to develop, but not talk"
stereotypes, such as "developers are introverts and won't talk to customers"
How do people get good at anything? Especially talking to the others? Right - by talking to the others. This comes with practice. And nothing can replace it.
To enable zero distance and improved shared understanding:
focus on the importance of zero distance and shared understanding (making people understand how important this is, makes learning possible)
removal of all middlemen and turning them into match-makers and facilitators
making an effort in learning and speaking customer/domain language
having enough time spent together regularly (developers can visit customers or invite them in for workshops).
Principle #3: Shorten the feedback (doing more often what hurts)
Each principle here supports the others. And this principle goes hand in hand with the previous one. One of the best ways to engage with the clients is to show them how you understand things. In Scrum, for example, this is achieved with a practice of Sprint Reviews. But formal reviews must not be the only time and place where the teams meet with the customers to get a somewhat delayed feedback.
Going down the learning path of Continuous Delivery is the best way we know in software development of shortening feedback loops.
What impedes shortening feedback loops:
planning cycles that are in lock with shipping cycles
shipping cycles that are in lock with releasing cycles
In other words:
Software shipments should happen as often as possible, even if your organization does big upfront planning (e.g. a quarterly basis).
Releasing of individual features should be done on per-user basis, not per shipment basis. This can be achieved by using feature flags.
This way, you won't have any excuse not to integrate and release as often as possible, even if the plans are done quarterly and not all the features are ready for all the users yet.
Principle #4: Employ the managers (bringing them to Gemba)
Why is this important at all for descaling?
The fact is, managers will be trying to improve the system, even if they understand only a part of it. We discussed the phenomenon of bounded rationality above.
A rhetorical question. Which type of manager will be able to see the whole and improve the whole better:
the ones who sit in their ivory towers looking at the spreadsheets
the others who spend a lot of time with the teams and customers, seeing and understanding how the value is being produced, shipped and used?
The idea of a 'Gemba Sprint' takes this idea to an extreme by inviting managers to join the teams for several weeks and more. A truly powerful method. But you don't have to implement it in such an extreme manner. Find what works for you.
Principle #5: Simplify relentlessly (jointly and continuously)
This principle glues the other four together:
when the view on the problem and solution space is broadened
where the teams work together with the customers to improve their understanding
that is being constantly verified and improved with powerful fast feedback loops
and the ones who have most of the influence on organizational design (formal leaders and managers) deeply understand how the things really are
then true systemic improvements are possible.
And what is a true systemic improvement? The one that is not symptomatic, but cuts away the root cause.
Thus, removing, not adding, Therefore, simplifying.
Don't scale agile, descale your organization!
Comments