1.
Organizations are implicitly optimized to
avoid changing the status quo middle- and first-level manager and
"specialist" positions & power structures
2.
As a corollary to (1), any change
initiative will be reduced to overloading the new terminology to mean basically
the same as status quo
3.
As a corollary to (1), any significant
change initiative will be derided as "purist" and "needing
customization for local concerns" -- which deflects from addressing
weaknesses and manager/specialist status quo
4.
Culture follows structure.
i.e., if you want to really change culture, you
have to start with changing structure, because culture does not really change
otherwise. and that's why deep systems of thought such as organizational
learning are not very sticky or impactful by themselves, and why systems such
as scrum (that have a strong focus on structural change at the start) tend to
more quickly impact culture. John Seddon also observed this: "Attempting
to change an organization's culture is a folly, it always fails. Peoples' behaviour
(the culture) is a product of the system; when you change the system peoples'
behaviour changes."
I think that those who believe Agile and Scrum are
the way forward will be at odds with most businesses that have a deep
institutionalized Command & Control structures that rests responsibility,
but usually not accountability, within groups/committees while diverting
responsibility away from individuals. In Scrum we rest most responsibility on
the Product Owner and hold this person accountable for the business value
delivered at the end of each and every sprint. It is often this simplicity
Scrum provides that is in direct conflict with the ‘status quo’. So how to
begin changes to the existing structures?
First and foremost, you must have an Executive Sponsor.
Without Executive Sponsorship your attempt to directly adopt Agile will
almost certainly fail. This is more than just having managers that agree to
allow you to use Agile; this is a person who has the rank and status in the
business structure who can influence the often many groups/committees who
collectively and traditionally have controlled projects. Agile is a
movement that requires top-down leadership to say ‘this is going to happen,
here is why it is good and we should all start rowing in that direction.’ The
Executive Sponsor, along with possibly one or more Agile Coach specifically
trained and experienced in agile adoption at the executive level, will be
handing out the oars.
What if you have no Executive Sponsor or the Executive
Sponsor’s influence is severely limited? Under these circumstances, full Agile
adoption is very unlikely to happen. However, there is a strategy that could
overcome the tremendous obstacles that are in the way but it does depend on you
finding some in Mid to Upper level Management more interested in results rather
than institutionalized processes. The ultimate result is usually a hybrid
adoption of Agile where all or some of the institutional controls remain in
place but an Agile sanctuary is carved out with fewer of these institutional
controls than a traditional waterfall project. This hybrid Agile project is not
truly Agile but neither is it true waterfall. The strategy follows a bottom up
Agile Adoption approach that will take time, maybe a lot of time, to slowly
chip away at the traditional structure and replace it with an Agile structure
and Agile mindset.
The strategy is twofold:
1.
Target getting support from managers in the
organization that are more likely to support Agile; and
2.
Target going around the organizational structure
of “over seers”
The strategy includes targeting those executives in middle
to upper management that are more likely to support an Agile process and have
some influence on those in the organization who are stanch supporters of the
institutional controls. The idea here is not to change these people completely
over to the Agile mindset but rather get these targeted managers enthusiastic
enough about Agile so they can see the possibilities and potential of Agile.
Targeting managers who don’t have influence over supporters of the processes or
targeting managers who are the stanch supporters of the processes is usually a
tactical mistake. Targeting a manager who doesn’t directly influence those in
control of the processes might be an easy convert but other than a quick burst
of satisfaction, the real battles will still lie ahead. The manager who is a
supporter of institutionalized processes is very difficult to convert; they
probably believe in their familiar processes and controls much like you believe
in Scrum, albeit for different reasons. A word of caution, because you’ve
gotten some support for your Agile project, you must remember that “success has
many fathers, failure is an orphan.” For those in middle to upper management
who supported you earlier, to ensure their continued support of Agile and
endorse its use, hybrid Agile projects must succeed and succeed “loudly”. If
your project fails or succeeds but with only a whimper, some, most, or all
middle to upper manages may forget that they ever supported Agile.
The second part of your Agile adoption strategy will be to
identify all those organizational groups and individuals who traditionally
sign-off on projects and find a way to exempt the Scrum project from these. These groups are
those who sit on gate committees, steering committees, technology committees,
or any one of a dozen other committees that approve, sign-off or use other
mechanisms of “over-seeing” a project. These groups are often a source of power
and prestige for its members and are traditionally very difficult, if not
impossible, to get around without an appropriately positioned Executive
Sponsor. The best way to get around these groups is to make your project a
separate business unit that answers to the CEO/board. This follows along how IBM
built its PC division in order to get out from under the bureaucratic thumb of
IBM’s corporate structure. Another tactic is to chip away at the
required process these groups require projects to follow. This can lead to some
relief for the project but will probably not succeed at allowing full Agile
adoption for quite some time.
Is doing a Hybrid Agile Scrum adoption good? The short
answer is yes. By simply following the activities defined for Scrum, (Sprint
Planning, Daily Scrum, Sprint Review, and Sprint Retrospective), Jeff
Sutherland has said that this will increase productivity by 20%-30%. However,
the greater benefits of Agile are really attained through following of and
embracing the deeper meanings of the Agile Manifesto, the Scrum Guide, and
Scrum Primer. To become “hyper-product” would require everyone involved in the
project (managers and scrum teams) to believe in and live Agile and Scrum.
Unless the Mid to Upper level Managers of the business are only interested in
results and don’t really care how you achieve them, your best approach to
adopting Agile is incrementally, one step at a time.
Craig Larman is co-author of:
- Practices for Scaling Lean & Agile Development: Large, Multisite & Offshore Product Development with Large-Scale Scrum
- Scaling Lean & Agile Development: Thinking and Organizational Tools for Large-Scale Scrum
- Agile and Iterative Development: A Manager's Guide
