Home  News The Four Pillars of Agile Adoption
|
The Four Pillars of Agile Adoption |
|
|
|
|
Written by Ó N. Van Schooenderwoert
|
|
Thursday, 12 June 2008 |
 Now
that the world has heard of Agile[i],
they think - incorrectly - that the pieces of Agile they like best can be
cherry-picked and used in isolation. Unless it is combined with Lean Thinking,
Agile software development can achieve only a fraction of its potential. Agile
software teams are not sustainable for very long if they are islands in a sea
of waterfall projects. The presence of Agile teams creates a new and incompatible
dynamic within a waterfall company. Agile adoption programmes conducted without
a thorough understanding of this dynamic will continue to have a very high
mortality rate, especially in larger organisations. This paper examines four
change processes that must occur simultaneously for an agile adoption programme
to succeed.
High Mortality of Agile Adoption
Why do we see such a wide variation in agile adoption programmes across companies? Why is it that we so often see agile pilot projects able to deliver better quality software in significantly less time, and yet the companies involved do not replicate this success across the enterprise? Every year a growing number of Agile conferences offer new experience reports showing high quality projects delivered in 30% to 50% of the time they would have needed using previous methods. From the agile coach community (no verifiable statistics, unfortunately) I know that a very large percent of companies fail in their attempt to take agile the rest of the way to being used enterprise-wide.
Often when a company has piloted a few successful Agile teams, managers decide that they can mostly go on as before and just "cherry-pick" some of the Agile practices and tools. The "mostly go on as before" part means conducting product development as a push system, rather than as a lean pull system. So rather than bother with having a Product Owner (the person who pulls value from the development team on behalf of the business), they let analysts decide via committees what features to have the agile team build. Testing is difficult for realistic data and error handling scenarios so rather than invest the effort, they settle for superficial testing that is too labour-intensive to be sustained. These are just a couple typical compromises that pave the way for failure.
There are actually four change initiatives that must be managed successfully if a business is to sustain and spread the success of agile pilot teams throughout the enterprise. Even more critical is that they must occur simultaneously. These pillars of Agile Adoption are:
-
Teams must be able to produce bug-free software
sustainably
-
Teams must consist of empowered, engaged people
- Work flow to the agile teams must be controlled
via a ‘pull' system
- Lean portfolio management must be used to
control work flow for the organisation
Unless all four of
these change initiatives are running successfully, characteristic problems
arise. They did for the Comet team. Let's look in on this agile team a year
after they completed their agile adoption programme.
Agile Entropy - An Example
The Comet team is one of several agile teams that were set up
in the course of an agile adoption programme at an insurance company. Their
story here is a composite of events that I and other agile coaches have seen.
They had external help for a total of eight months: Scrum training, and
additional technical training in the use of agile test frameworks and help in
cleaning up their build process. Their consultant Scrum Master was on site most
of the time for the first 3 months and then present every other week until
disengagement when they felt confident to continue on their own.
Comet Team from Agile Adoption to
One Year On
When the consultants completed their work, the 8 members of
Comet team were running 3-week iterations. Their velocity had initially jumped
around but was stable and gradually increasing. They were holding
retrospectives at the end of every iteration and checking a few days into the
next iteration to make sure they were really following the new resolutions they
made in the retrospective.
Their Product Owner was 50% allocated to that role and was
meeting with stakeholders a week prior to the end of each iteration to finalise
stories for the backlog. The team's ongoing mission was to maintain and enhance
risk analysis software for use by the underwriters. The work they turned out
was the best quality the company had seen. The team knew that there were still
bugs in the legacy code but at least they were not adding many new ones. As
they improved their tests they were cleaning out more and more old bugs.
A year later the consultant Scrum Master saw Tony, the Comet
team's lead developer, at an industry conference and asked him how things were
going. Tony said he wished they had never gotten into Agile at all! They were
no longer doing real iterations, just moving the work along in a more or less
continuous stream. They had dropped doing the retrospectives after Joanne, who
facilitated them so well, moved on to other work. They continued them awhile but
they were just making a quick list of what worked, didn't work, and what they'd
change, without delving into the tougher issues. The biggest problem with the
retrospectives was that things they most needed to change required cooperation
from another department that was always overworked. So there seemed no point in
making the same useless resolutions over and over. The other department was not
responding and wasn't going to. They were invited to send someone to the
retrospective but they never did.
Dissension Within Team
The biggest letdown in Tony's mind was that Agile had opened
the door to turning software development into a sweatshop. That's the word he
used - "sweatshop". Before the conversion the developers had their own
cubicles, and in the enthusiasm of early Agile they'd given them up in favour
of a team room. But they were happy for
eight months with the team room - why the problem now? They were arguing a lot now, and being
together all the time in a team room only increased the tension.
Stressors
They were arguing a lot because of disagreements over how
much time to devote to cleaning up quick fixes they'd had to put into the code
versus getting new functionality in place that their customers needed. At least
that's when the arguing began. Now there were many running arguments on all
sorts of things. The quick fixes got rushed into place when new features
activated a couple latent bugs in the code that their agile test framework
didn't yet cover. Those bugs got a set of insurance policies written with
incorrect risk assessments, forcing Legal to sort out a remedy. That brought
criticism on the project manager who'd been fine with team autonomy so far. But
now he was being criticized by his manager for not having been firm enough with
the team.
Repercussions on Team, Product
Owner, and Managers
The Product Owner had cut way back on the time he devoted to
his role because the team was delivering so predictably month after month,
before the problem with the bugs and the Legal department. He felt that at some
point Agile should just be able to run on autopilot; besides there were many
other demands on his time. He was feeling caught-out when Legal had to come to
the rescue. At first he defended the team, understanding their explanation
about the test framework. But he became dismayed by their incessant arguing and
no longer wanted to be in the Product Owner role.
Both the Product Owner and the Project Manager were starting
to wish for the good old days when you just had the analysts write a specification
and hand it over to a virtual team - one where the Project Manager rotated
people in and out of a dispersed team and assigned all work tasks. It was
getting easy to forget the headaches associated with that, when these new
problems seemed so intractable.
Team velocity was steadily decreasing. So managers pressured
the team to speed up. With each iteration, the team responded by promising more
and delivering less. Often nearly half the stories committed to were not
completed in the sprint. In an effort to work faster, they no longer helped
each other out, working solo on the tasks they claimed for themselves. Everyone
missed the teamwork they used to have but didn't know how to get it back again.
Tony was using the conference to renew his contacts elsewhere.
He had decided to leave the company.
Diagnosis
It is clear that in this agile conversion this team learned
how to operate using agile practices - to an extent - but managers did not
learn how to monitor this new Agile system and use the leverage points that
could have kept the situation from spiraling downward. Pleased by the agile
turnaround, they expected it to just remain on course of its own accord.
Agile systems don't automatically stay on track. No system
does; they all need some degree of monitoring and adjustment to counter
entropy. In an organisation, the "Agile system" consists of the core team, plus
the stakeholders[ii]
who've chartered that team, and others who manage or interact with the core
team. As part of an agile adoption programme, managers need to learn the
critical role they must play in fighting entropy by exercising control in a new
way.
Let's look at a simple analogy. If enforcement of traffic
laws were suspended, it wouldn't be long before there would be chaos on the
roads. People who want to follow the laws would have to respond to those who
don't and the whole thing would spiral downward. Likewise in an organization it
is for managers to understand the laws - the key leverage points - and use them
correctly to keep the agile system running with minimal ad hoc intervention.
Let's take it one step further. Suppose there has been a
breakdown - as we've seen with the Comet team - what are managers to do? An
accident, flooding, or downed trees can create a big traffic jam on a road. Regardless
of the cause, the individual motorists are powerless to move their vehicles
once they are caught in the gridlock. No amount of pressuring or punishing them makes any sense. The first thing
the police do is not to pull cars out
of the jam, but to halt the inflow of more cars. They block off the routes into
the gridlock, thus preventing it from growing. Next, they free cars out the
other side by clearing the blockage.
The jam is a system
problem, not a problem of the individual motorists. Although each driver has
responsibility for controlling their vehicle properly, that won't prevent or
solve traffic jams. Likewise many of the problems that software teams
experience are really system problems
of their company. Executives and managers govern that system and have a special
role to play during and after a change to Agile.
What should be done in the case of the Comet team? The set of
problems they encountered can be viewed in terms of the four change pillars.
For each one, we'll look at the leverage points that could've stopped agile
entropy.
Problems With Pillar #1:
Sustainable Bug-Free Code
Agile teams must be capable of delivering bug-free software.
That doesn't mean zero bugs every time, but it does mean that they should have
negligible impact. Troubleshooting and fixing bugs should not take up a
noticeable amount of an agile team's time. Agile technical practices are
designed to achieve this goal, and keep the code base in a fit condition for
further work. Agile technical practices shift the mindset from:
Specify ->
code -> integrate -> then do ‘infinite' test & fix loop, till
resources depleted
To:
Specify via
tests -> code -> integrate continuously so code is always releasable
Agile teams must be able to estimate their work and - in the
absence of blockages - be able to deliver on their estimates every time.
Managers are partners with the teams. They fulfill their part by promptly
removing blockages, and by providing the team with resources to fully test
their code during development.
Technical Debt and Latent Bugs
Let's look at Comet's bug issue. Activation of bugs in the
legacy code via new features added to the code base was the initiation point
for the unraveling. "Technical Debt" is a term covering hidden problems in the
code: unnecessary complexity, unclear naming, excessive coupling, inflexible
architecture, and latent bugs. Perfectly running software can have these
breeding grounds for bugs. Technical Debt shows up when you try to make changes
to the software. It makes bugs far easier to create, even for careful
developers.
All software has technical debt. But code written the agile
way with strong unit tests has much less debt and therefore far fewer bugs -
typically one or two orders of magnitude fewer. In Comet's case, technical debt
was getting removed incrementally. This is normal. Removing it all in one go
would mean having to focus on that alone for quite some time without building
new features. That would be unacceptable to the project sponsors.
Without their unit tests fully constructed, the possibility
of a critical bug getting through does exist. Even if the unit tests were fully
constructed, it is always possible to overlook something in the design of the
unit tests. Human error cannot be eliminated completely by Agile or any other
methodology. With that said, agile teams do routinely achieve bug rates on the
order of 0.2 defects per function point, or roughly 2 bugs per month for a team
of 5 people.[iii]
Who Owns Bug Risk?
Management in this case needed to own the risk of bugs. If
you view the organisation as a system
for producing software-intensive products and services, then the maintenance
and enhancement of that system is the
job of managers. Owning the bug risk means understanding that technical debt is
a precondition for bugs and that technical
debt is not there by accident. It is a property of the system that can be
controlled.
The bug risk can never be taken to 0% but it can be lowered
to any level that one cares to pay for. This is always a cost-benefit decision
that is ultimately up to management, not the team. Managers decide how good a
development environment to provide. Even if a perfect testing environment is
provided, there is no limit to the number of agile unit tests that can be
written for a given code base.[iv]
You can make the tests as fine-grained as you need. But they will require
effort (cost) to maintain.
There is a constant tension between how much technical debt
you allow into the code vs. how much effort you put into your agile testing
strategy to combat it. This cannot be managed effectively from outside the
team. It requires a deep and constant familiarity with all aspects of the code.
Only a cross-functional core team will have the skill and judgment to do this
efficiently. This is why testers need to be part of the team, and why the team
needs autonomy to decide how the work, and the testing, will be done.[v]
Agile technical practices give the team new skills to take
the bug risk far closer to zero than they could have before. Still, it is for
managers to own the fact that accidents can happen, and they must be prepared
to untangle the resulting traffic jam if an accident does occur. This is what
Deming names "common cause variation", variation intrinsic to the system that
is not due to any mistakes made by those working within the system.
Particularly in software development, insufficient early
investment takes a very heavy toll. The problem is that it's hard to say
definitively just how much specification detail is enough, or how much
requirements analysis is enough, etc. Agile teams solve this problem by
following a simple rule: In every iteration deliver tested, working code that
customers can directly evaluate. That means deliver whole usable features, not
mere technical components.
Takeaway Lesson
Every agile team needs to be able to produce bug-free code.
To the extent that you have bugs, your project is out of control. The Product
Owner and line managers of the Comet team members should have owned the bug
risk by defending the decision to pay down the technical debt incrementally. If
they had fully explained the risk and its mitigation plan to higher-ups
beforehand, the incident with the Legal department needn't have been so
damaging to the agile adoption programme.
Problems With Pillar #2:
Empowerment
Partnership between team and stakeholders is fundamental. If
one side can never say ‘no' to the other then it is not a partnership - it is a
master-slave relationship where neither side can ultimately get their needs
met. Partnership is what opens up the entire domain knowledge of a whole team
and places it fully in service to the organisation. Only autonomous teams can
take full ownership of a goal, relieving managers of tedious unnecessary
control tasks.
Two things are needed for a core team to step up to their
role in this partnership:
-
Autonomy over their work, with a practical way
to make decisions as a group
- Mentoring to continuously improve their skills
in the technical work itself
Empowerment of agile teams is not optional; it is crucial for
the high degree of focus and dedication necessary to produce bug-free code
sustainably. Mere process rules that a company may institute cannot make people
engage to the degree necessary for producing such high quality software. Their
commitment, creativity, passion, and energy are needed - not just their
obedience to rules! No externally imposed discipline is any match for
self-discipline. This is the key to Agile (and to Lean Thinking), which is
completely missed by so many would-be adopters.[vi]
Let's look at how issues with empowerment surfaced for the
Comet team. There are many problems stemming from this, and in my coaching
experience that is common - empowerment is widely viewed as a "nicety" that can
be skipped or, even worse, as a step toward anarchy.
Erosion of "Soft" Skills as First Danger Signal
The first danger sign was the disappearance of
retrospectives. Group learning and team unity of purpose must be renewed periodically. This is a very high-leverage activity
that solves a great many thorny problems while they are still tiny. The line
manager(s) of those on the team should have noted that Joanne was carrying the
load for retrospective facilitation, and should have recognized the importance
of that skill by helping others get trained to do it well also.
Facilitation is only part of the picture; good data is needed
too. Teams should experiment in every iteration with ways to improve their
work, recording data on each experiment. Data plus an efficient way to make
team based decisions should have prevented the team's arguments from getting
out of control. Comet team's first argument was over how much effort to spend
cleaning up the quick fixes in the code when customers were clamouring for new
features. A wise technical manager knows that new features built on top of
quick fixes just creates a bigger cleanup job to be done later. If this wasn't
being grasped by the Product Owner, then it was a point where a technical
manager could've reinforced the team's message.
Too often good facilitation is dismissed as a "soft skill"
not as important as the technical skills, and something we can do without in a
pinch.
Missing Cooperation Between Departments
Failure to act on issues raised in retrospectives is another
problem. The team had repeatedly raised issues requiring the cooperation of
another department, but it was not forthcoming. By letting this issue sit,
managers sent a message to the team that it wasn't important. This contributed
to the team's feeling that retrospectives were pointless. A deeper root of this
problem is insufficient larger commitment to Agile, spanning departments. This
is a system problem that the core team cannot solve. Managers need to take the
lead here.
In an agile adoption programme, friction between the agile
teams and the surrounding organisation will
occur. The organisation evolved to support waterfall teams with handoffs
between siloed job functions. It will have to change if the agile teams are to
survive. Management's chief job in an agile adoption programme is to watch for
the friction points and then adapt the
organisation to the agile teams.
Misalignment of Accountability and Control - ‘Blame' culture
The organisation was trying to hold the project manager
responsible for the team's actions. The team has to be responsible for its actions.
There was nothing the project manager could've done to make the team avoid
those bugs. When things go wrong there is often an impulse to place blame. The
need to deflect blame is what lies behind much of the overly-detailed planning
in waterfall projects. Deming placed "Drive Out Fear" as one of the principles
in his 14 Points for Management. The project manager needed support from those
sponsoring the agile adoption programme. By allowing others to place blame on
him they let fear grow.
In the case of the bugs that occurred, they were
unforeseeable since they were latent in the existing code. Probably the only
way to have prevented them was if the company had invested in more thorough
testing designed to catch a scenario of that type. But it is very common (and
possibly justified) for companies to decide not to invest in doing that. In
that case, the team were operating within a system that had set this trap for
them. Once the bugs had repercussions in the Legal department, the
organisation's blame reflexes kicked in. Too bad they didn't have the benefit
of a good retrospective to identify these dynamics and find a constructive way
to address them!
Failure to Sustain Agile Feedback Mechanisms
Another key leverage point that managers neglected is the
extremely vital feedback loop between team and stakeholders. A strong Product
Owner actively engaged with both the team and the stakeholders is necessary for
agile teams. Like well-run retrospectives, this prevents a host of problems
that are very difficult to address in firefighting mode. Once a team loses the
trust of their stakeholders everything is an uphill battle. Although projects
vary in their demands on Product Owners, it is always wise to invest in keeping
that feedback loop healthy. Give them time to perform the role.
Comet team's Product Owner was feeling pressure to minimize
the time devoted to his role. The executive sponsoring the agile adoption
programme (the Agile Champion) should have been making sure that people in key
roles were allowed the necessary time. A Product Owner's manager won't be
willing to cooperate unless they have bought-in to their own role in the agile
adoption programme. The programme must have sponsorship high enough to span
business and technology departments.
A reminder from the Agile Champion would be all that's needed
to keep the Product Owner properly engaged, if the right agile sponsorship
groundwork had been laid.
Summary of Empowerment issues
In summary, Comet's management needed to do these things to
prevent the problems stemming from insufficient empowerment:
-
Recognise the importance of facilitation skills
and grow those skills
- Act on issues arising from Retrospectives that
are outside team's control
- Support the Project Manager when he/she gets
inappropriate pressure to direct the team
- Support the need of Product Owners for time to
perform duties of their role
Takeaway Lesson
Without the right empowerment, the goal of sustainable
bug-free code cannot even be achieved. A properly empowered agile team is the means to generating sustainable
bug-free code.
Problems With Pillar #3: Team's
Work Stream
An agile team ‘pulls' work from the Product Backlog into a
time-boxed iteration. After a couple iterations they know how much they can do
in a given period; they have established a velocity. A common problem for
managers new to agile is that they want the team to do more than the amount
their velocity indicates. So they pressure the team to give artificially low
estimates, or to work long hours, and so on.[vii]
Velocity as an emergent property
An essential idea of a pull system is it recognizes that the
team cannot control everything that has a bearing on their velocity. The team
is part of a bigger, interconnected system. That system can produce bug-free
code at a certain rate, full stop. That's the velocity. It might be stated as
so many story points per week. If faster output is needed then the
interconnections between the agile core team and the rest of the system need to
be understood and improved to generate a higher velocity.
Velocity is an emergent
property of the system. It cannot be directly commanded. If you get 50
story points this week by working 12 hour days, when the usual was 40 points,
you are not working sustainably. You're simply robbing future production to get
a peak now. Perhaps a tool to do data profiling would result in higher
velocity. Tools are an example of an interconnection between the core team and
the organisational system. So is training. If the team is given training to
help them write better agile unit tests, that could improve velocity in a
sustainable way. So could having a good team workspace. Each idea has to pass
the sustainability test - if you could do it indefinitely then it's a valid way
to influence velocity.
A very common mistake is to try to drive velocity directly,
through pressure.
Diagnosis of Comet's Work Stream Problem
Comet team's velocity eventually started decreasing. When
more coding is done on top of quick fixes, the code base quickly becomes
brittle, and very hard to work with. Changes produce new bugs and they take
time to fix, hence a slower speed. An increasing bug rate tempts people to do
even more quick fixes leading to a downward spiral.
In frustration over the developing problems, Comet's managers
reacted by pressuring the team to get more work done. Direct pressure cannot solve this - it
intensifies the problems. The team responded by overly-optimistic
"commitments", and by refusing to devote any time to helping each other with
tasks. Undoubtedly, that further slowed their progress.
The team could not, in a short period of time, clean all bugs
out of the legacy code. It was not within their control to do that; it was part
of the landscape they had to cope with. They also could not quickly cover all
the legacy code with agile unit tests. It had been agreed that this would be
done incrementally along with creating new code. Deming said in his 14 Points
for Management "the bulk of the causes of low quality
and low productivity belong to the system and thus lie beyond the power of the
work force", and that applies perfectly here.
In this instance, managers needed to recognise that the
velocity was slowing because the group had decided to go with using quick
fixes, and they were not taking the time to clean these out of the code. The
question technical managers needed to ask is "why are we using an unsustainable
technique to keep code production going at this rate?" Was the team simply
bowing to inappropriate pressure to keep velocity up? That's the surest way
into trouble. Or did the team really believe the quick fixes would be harmless?
If so then they should have seen that wasn't the case and reversed course.
Retrospectives provide a good way for managers to gain early insight into
issues like these before they are compounded.
Lessons Learned for Keeping Team's Work Stream Healthy
Agile teams should receive their priorities through the
Product Owner, and no one else. Sometimes standards groups, regulatory
representatives, or others expect to direct team activities. They are stakeholders
in the team's outputs and should work through the Product Owner. When a team
has too many bosses they are set up to fail. Note that the Product Owner does not
assign tasks to other team members. The Product Owner collaborates with them
and is an information resource for them.
Pressure on a team to make optimistic estimates is often
non-verbal, and it may come from many sources. Teams want to deliver, and when they err it is always on the optimistic
side. It doesn't take very much pressure to move them onto shaky ground.
Learning to push back in an appropriate way is one of the last skills agile
teams acquire, so new agile teams are especially vulnerable to this mistake.
Wise managers will watch for times when a team commits to do
much more work than they usually accomplish, and they will ensure that the team
know they'll be supported if they need to push back on demands made of them. A
commitment that cannot be fulfilled is of no help to the organisation but can
become a magnet for blame. Managers must understand that they have a
responsibility to regulate the flow of work to agile teams. It is a simple,
effective way to help teams keep their credibility.
The worst thing an agile team can do is erode trust with
their customers. Each iteration should build up that trust.
Agile teams that form spontaneously "under the radar" are
very often undermined because management has not acknowledged any obligation to
regulate their workload. They are flooded with too much to do, no time for
learning new tools or for maintaining a unit test infrastructure, and they can
only hold the line so long.
Takeaway Lesson
If teams have mastered bug-free code and are empowered, they
can still be destroyed by the failure of management to regulate the flow of
work to them, i.e. allow them to pull the work in at their sustainable pace.
Managers at every level have got to buy into the idea that they must never jam
more work into a pipeline than its proven
capacity. The good news is there are legitimate ways managers can increase that
capacity.
Problems With Pillar #4:
Organisation's Work Stream
One of the worst things that can happen to a good Agile team
is to be assigned to a weakly supported project. That will mean blockages don't
get removed. People and other resources get taken away when needed by other
projects. The team repeatedly fail to deliver on their commitments and they
lose the trust of their Product Owner.
Need Lean Project Portfolio Management
The previous three pillars of agile adoption are covered by
the popular agile methodologies, but this issue of governing the work stream at
the organisational level takes us over to Lean territory. Unless a lean
discipline is used to decide what work an organisation undertakes, it runs the
risk of spreading its energy too thinly. Weakly supported projects will thrash
and waste resources. A company that regularly completes 40 to 50 projects a
year should not have 500 active projects in their portfolio!
Projects that have a direct business need are easiest to do
as agile because there is a strong pull
by a customer. Necessary infrastructure projects are harder to gain sponsorship
for. There is less will to allocate a dedicated team, and pay for the tools
they'll need. There is no easy answer here, but if the project is truly needed
then it is the responsibility of the business to understand what it will
accomplish and be a sponsor for it.
In the example of the Comet team, they were one of several
agile teams. There isn't enough context to tell for sure whether theirs was a
weakly supported project. Probably not, as their software was for use by the
insurance underwriters to determine risks. This illustrates that it's not
enough to just look at individual agile teams - you need to understand how
groups of agile teams function within an organisation.
Agile Habitat
One agile pilot project can be sustained by almost any
company. It will place more or less demands on various other departments and
infrastructure, but can be coped with. As the number of agile teams increases,
pressure on certain resources (testing environments, Product Owner attention,
team rooms, etc.) reaches a point where something has to give. Either the agile
teams will be reined in and forced to make more and more compromises in their
roles and practices, or else managers will recognize that they have to make the
organisation into a better habitat for agile teams.
A perfectly skilled and competent agile team may still fail.
It's the same problem as when healthy animals are released into a habitat that
is being decimated. They don't have a real chance to survive even though each
individual knows how to survive. The highest priority projects should go to
agile teams. Portfolio managers will have to regularly kill off those projects
that cannot deliver or that are vying with Agile projects for resources.
Takeaway Lesson
If teams have mastered bug-free code, are empowered, and
their work stream is properly controlled, they can still be destroyed by the
failure of managers to match the organisation's
work flow to its sustainable capacity. One more time: Managers at every level have got to buy into the
idea that they must never jam more work into a pipeline than its proven capacity.
Lean Thinking and Agile belong together for creating
software-intensive products and services. They are actually different names for
parts of one unified concept.
Conclusion
The Comet team got into quite a difficult situation even
though they were in good shape when the external coaching ended. Once problems
accumulate to this degree, it is very difficult to sort them out - too much so
for an organization still getting used to Agile. The key is to prevent these
problems by understanding the control points in an agile system.
Too often it is easy to dismiss those control points when
they involve so-called "soft" skills like good facilitation, or when people
feel too much time pressure to clean up a "quick fix". Agile adoption must be
led by executives and managers who thoroughly understand its dynamics.
Otherwise the normal frictions that arise will completely erode the agile
adoption programme.
Agile is not just new software development techniques, or new
project management techniques. It is that and more - it is an overall
management philosophy for an organisation. Agile points the way to applying
Lean Thinking to software-intensive parts of product development, and of
business process improvement. Comet's managers had adopted lean-agile practices
but had not yet fully grasped its management philosophy.
The biggest gains of all come from management innovations.
Management innovation is very hard to copy because it is almost invisible from
the outside. Practices are easy to see and copy but copying them seldom
produces sustainable benefits within an incompatible system of management. Lean
businesses are radically different from traditional businesses in almost every
respect. This is why it is so difficult to move an organisation fully to
lean-agile methods. It's also why big rewards still await those who get there
first.
About the Author
Ó N. Van Schooenderwoert
[i] The term "Agile" is used to
mean any approach that addresses lean software development together with lean
management. Scrum plus Extreme Programming does that. So do DSDM and Crystal,
to mention a few.
[ii] The term "stakeholders" is
intended to include customers, or those who represent them, representatives of other groups within the
company that are affected by the agile project, and groups whose cooperation is
needed by the agile team.
[iii] "Embedded Agile Project by
the Numbers With Newbies", paper presented at Agile 2006 conference by N. Van
Schooenderwoert. Available at http://www.leanagilepartners.com/publications.html.
The author found many other agile teams who had similar successes but had not
produced detailed metrics. They typically said that they don't track bugs
because they're so rare - maybe one in a month. They sometimes could not recall
when they last had a bug.
[iv] There are many factors
involved beyond just the number of tests. The quality of tests matters, as well
as how easy or difficult it is to change them. The key point is that there is
no natural, obvious stopping point when creating tests. They can be as fine or
coarse grained as desired.
[v] Independent testing
external to the team is a separate matter, and is not being ruled out by these
statements. In a lean organisation, each work group should routinely produce
defect-free outputs. Ideally, final inspection or quality control should only
find defects that could not have been prevented by the team. One of Deming's
management principles is "Cease dependence on
inspection to achieve quality. Eliminate the need for inspection on a mass
basis by building quality into the product in the first place."
[vi] Quotation: "Only after American carmakers had exhausted
every other explanation for Toyota's success -
an undervalued yen, a docile workforce, Japanese culture, superior automation -
were they finally able to admit that Toyota's
real advantage was its ability to harness the intellect of 'ordinary' employees." Source is
"Management Innovation" by Gary Hamel, Harvard Business Review,
February, 2006.
[vii] There are techniques to
achieve higher velocity, such as using multiple agile teams for the project,
changing composition of the team, etc. These are beyond the scope of this
article.
Comments () |
 |
|
|
|
Tags:
Click to add your tags...,
|
|
|
Latest Issues of Agile Journal
|
