1. business and industrial
2. business operations
3. management
4. project management

March - April
May2013
- June 2013
Government Agility
How to
Reduce IT
Cost Using
Agile
Managing
Federal
Projects
in Agile
Top 5
Agile
Transformation
Strategies
Agile
The Catalyst
for Innovation
&
Scrum
The Framework
for Change
Does Agile Scale? · Using Agile to Inspire Loyalty · Flipping the Iron Triangle
All Agile,
All In
T
he word ‘agility’ has not often been
associated with government agencies
in years past. The common perception
of government as large and ponderous
does not mesh with the traditional
definition of agility. And government
agencies are not often thought of as being
lean, nimble, and quick to adapt to evolving
technologies.
achieving a department’s goals.
In recent years a new paradigm of
software development methodology
has taken the I.T. world by storm. It’s
called Agile software development, and
as its name implies, it’s a methodology
that utilizes quickness, flexibility and
responsiveness in developing quality
software with great efficiency.
Certainly there is some truth to these
stereotypical views of government. But if we
expand our view a bit and search for large
and ponderous departments within the realm
of private industry, we’ll find them. It’s a
false perception that government agencies
have grown large, inflexible and inefficient
simply because they’ve been funded with
free flowing tax dollars. (And these days, of
course, the tax dollars aren’t flowing quite so
freely as they may have in years past!)
Rather than a traditional linear, end-toend approach to software development,
Agile is more of an adaptive, reactive
approach. The result for both government
and private operations can be software
development projects more on-target with
end-user requirements.
Many factors influence the efficiency
and flexibility with which a department
functions, whether governmental or private.
Focusing particularly upon I.T. departments
charged with software development,
efficiency of operation has much to do with
the philosophical methodology employed in
We expect that those of you already
utilizing Agile development practices
will be nodding your heads in knowing
agreement as you read through this “All
Agile, All In” issue of Modern Government.
And we hope that those who have not yet
availed themselves of the benefits of Agile
will be motivated to explore the potential
benefits in deeper detail.
Jenna Bratten
President and CEO, AEi International
Publisher, Modern Government
Features
Content
7
Flipping the
Iron Triangle
By Jennifer Bleen
Cardinal Solutions
11
Does Agile Scale?
By Larry Putnam, Jr.
Quantitative Software
Management
33
Using Agile to
Inspire Loyalty
By Michael Swansegar
Swansegar Consulting
20 TOP 5 Agile Transformation Strategies
By Sally Elatta
Agile Transformation, Inc.
14
Agile The Catalyst for
Innovation. Scrum The
Framework for Change.
By Lizzy Morris
Bearded Eagle
On the cover
All Agile, All In!
Agile takes over!
Federal
Government
27 Managing
30
Projects in Agile:
Agility: How to
Moving Away from
the Waterfall
reduce IT cost using
Agile
By Christine Bottagaro
& Ronica Roth, Rally Software
By Devon Morris
Bearded Eagle
Modern Government
May - June 2013
Published by AEi International
Modern Government is a bi-monthly online
publication that goes beyond the traditional
business divide to bring leading organizations
together to share thought leadership and
practical insights for government.
MODERN GOVERNMENT · May - June 2013
3
Contributors
Jennifer Bleen
Christine Bottagaro
Sally Elatta
Jennifer Bleen PMP, ACP, PSM
is an experienced agile coach,
change agent, program manager,
business analyst, trainer, and
industry consultant. Using her
breadth of industry experience,
she creates strategic solutions
to develop high performing
organizations. She enjoys
coaching and mentoring teams
and individuals to help them
reach their full potential. She
actively serves the central Ohio
agile community as co-Founder
and President of Central Ohio
Agile Association, PMICOC
Director of agile training and PMI
Agile CoP Chapter Engagement
Representative.
Christine runs integrated
marketing campaigns for Rally
Software, focusing on how
Agile practitioners learn, what
they need to know, and how
to apply these learnings to
their organizations. Christine
has a background in product
management, customer
advocacy programs and strategic
marketing development - as well
as a passion for good reading
material.
Sally is the President of Agile Transformation
Inc. (8a Certification in progress)
Contact Jennifer:
[email protected]
www.huntington.com
Contact Christine:
[email protected]
www.rallydev.com
She is an Enterprise Agile Transformation
Coach who comes from a strong technical
background as a software developer and
architect for several years. Sally fell in love
with Agile methods almost a decade ago
because ‘They just brought back common
sense approaches to getting work done
and re-emphasized the need for Servant
Leadership’. Her organization is made up
of a talented team of highly qualified Agile
trainers and coaches who are passionate
about helping organizations succeed with
their Agile Transformation. Their clients
range from large fortune 50, 500 to medium
size businesses and government agencies/
contractors such as HHS, DHS, DOD, Nebraska
Dept of Roads, US Navy, USDA, US Army,
US Air force, Raytheon, Northrop Grumman,
Cayman Island Gov.
Sally is the Agile Expert for PMI’s Learning
and Education CoP, a frequent public speaker
at national conferences and has published
several popular videos on AgileVideos.
com. She is also a co-author of the ICAgile
Leadership certification track. She is also
the founder of www.AgileforGovernment.
com which is a site that will be dedicated
to helping government agencies learn and
apply Agile methods. She is a proud mother
of 3 young children and enjoys traveling and
exploring the world with them!
Contact Sally:
[email protected]
www.AgileforGovernment.com
4
May - June 2013 · MODERN GOVERNMENT
scrum and raising scrum master and
future coaches. Lizzy believes she is
blessed to go to work everyday able
to pursue her passions.
Elizabeth Morris
”Lizzy”
Lizzy as she likes to be called, is a
British native who relocated to the
USA in 2005. She is a seasoned
organizational change agile
executive management consultant
that focuses on driving measurable
results for her clients, processes,
employees and financials. Lizzy has
over 19 years in-depth experience
in delivering software development,
project management and strategic
consulting. This has given her a
unique ability to provide clients
with the right tools and techniques
tailored to the needs of their
organization. Lizzy career has taken
from the UK across Europe, North
America, Asia, and Africa.
Lizzy and her husband own a
company called BeardedEagle,
they offer services that are geared
towards executives, private
individuals, teams, managers, large
and midsize organizations that
are ready to embark on their Agile
journey. Lizzy passion is Scrum and
considers herself blessed to be able
work everyday pursuing one of her
passions. A mother of 6, 4 boys and 2
girls Lizzy understand the benefits of
Scrum in action.
Lizzy considers her sweet spot to be
Agile Organizational Trans-formation,
the reason she is loves it so much is
in her own words “there is nothing
greater than starting to see all
the “arhah” mo-ments happening
with teams, executives and middle
management. It tends to be like a
domino effect that had once seemed
impossi-ble. When every training
class and Agile presentation and side
conversation you have had comes to
life and makes sense to cus-tomer.
Nothing like it ..it beats ice-cream!”
Lizzy considers herself a lifetime
student at ecosystem of learning
and development. Lizzy is always
pursuing new techniques and
methods to help teams evolve.
Her training always have her students wanting more. Her belief
is that students should leave her
training with a tactile knowledge of
scrum that they can immedi-ately
put to use. Lizzy has her students
engrossed in games, simulations
and group facilitation exercises to
provide an immersion experience
into the philosophy and culture of
agile. By no means your ordinary
agile change agent . Lizzy is currently
writing her first book which she
hopes to be available for purchase
by the end of the year. It is called
Agile Transformation from Agile
Heels. We will look forward to it
release
Contact Lizzy:
[email protected]
www.beardedeagle.com
Larry Putnam, Jr.
Larry has 21 years of experience
using the Putnam-SLIM Methodology.
He has participated in more than
80 estimation and oversight service
engagements, and is responsible for
product management of the SLIM-Suite
of measurement tools and customer
care programs. Since becoming the
Managing Partner of Products and
Customer Care, Larry has developed a
new customer care program that has
increased customer satisfaction levels
by 50 percent and increased client
license renewals by 46 percent. Larry
is a member of and active participant
in numerous organizations, including
the Quality Assurance Institute,
Software Program Managers Network,
International Function Point Users
Group, and International Society
of Parametric Analysts. Larry has
delivered more than 27 speeches at
conferences on software estimation
and measurement, and has trained –
over a five-year period – more than
1,000 software professionals in the
use of the SLIM-Suite.
Contact Larry:
[email protected]
www.qsm.com
Lizzy has three passions training
scrum, coaching executive leaders through agile adoption with
MODERN GOVERNMENT · May - June 2013
5
Devon Morris
Michael Swansegar
Ronica Roth
Devon Morris is a Certified
Scrum Trainer and EagleEye at
BeardedEagle. He was introduced
to Scrum in 2000, where he
played several roles ranging from
software developer to project
manager. In 2005, Devon started
consulting to influence the
cultures and work environments
of his clients. He has helped
with the adoption of Scrum and
Agile at numerous companies,
including Allstate, Awana Clubs,
Capital One, Experian, Johnson
& Johnson, Pearson, Rackspace,
Sears, State Farm, TransCanada
and USAA.
Michael is an active Agile Trainer and
Product Manager. Michael has spent
over 12 years in infrastructure support
and has now paved a way through
Quality Assurance and Product
Management. Michael has been on a
quest to find “who is in charge” when
it comes to defining the right product.
As many Product Managers realize,
the customer on the call with support
is exactly the one we need to inspire.
Michael believes that agile is designed
to inspire loyalty with internal and
external customers. Michael loves
to teach and uses radical methods
such as movies clips, games and
stage props to memory retention
by associating our normal life to
the content being taught. Michael is
married, has two dogs and lives in
Colorado.
Ronica brings incomparable energy
and passion to promoting Agile
principles and practices. Her mission
is to build learning organizations that
honor the individual, give everyone
the chance to do what they do best,
and harness the power of team to
amplify great work and produce
great software.
Devon’s brings his broad
range of experience to every
training event and coaching
session, so that you boost your
performance when applying
techniques. Devon believes in
values espoused by the Agile
Manifesto and applies in to
his everyday life. He holds the
follow certifications - Project
Management Professional, Agile
Certified Practitioner, Certified
Six Sigma Black Belt, Lean Six
Sigma Black Belt, Myers-Briggs
Type Indicator Professional
and California Psychological
Inventory 260 Professional.
Contact Devon:
[email protected]
www.beardedeagle.com
6
May - June 2013 · MODERN GOVERNMENT
Contact Michael:
[email protected]
www.swansegarconsulting.com
As Rally’s Solutions Evangelist,
Ronica works with stakeholders to
set strategy for evolving Services
solutions that support our customers’
needs for Agile coaching, consulting,
and training. She uses her Agile
Coach and Consultant experience
to evangelize how Agile + Rally =
company greatness.
Contact Ronica:
[email protected]
www.rallydev.com
Flipping
the Iron
Triangle
BY Jennifer Bleen
Practices such
as limiting
the amount
of work being
performed in
order to get
more work
done may
seem counter
intuitive.
Triple
Constant
B
eginning an agile
adoption is a disruptive
change that impacts
not only the processes
used by team members
performing work, but
the organization’s culture and
your role as a leader. Agile is a set
of values and principles shared
by application development and
product lifecycle methods and
frameworks. Practices such as
limiting the amount of work being
performed in order to get more
work done may seem counter
intuitive. In my opinion, the
paradigm shifts required are the
toughest for leaders. Not because
they are difficult, but simply
because they are unfamiliar
territory. More often than not, no
one explained in practical terms
what the paradigm shifts really
mean for everyday business
as usual. In this article we will
explore some aspects of one
such paradigm shift, the triple
constraint or iron triangle flip.
For those of you unfamiliar
with the triple constraint
concept, an organization
managing projects in a
traditional manner will generate
a list of requirements up front.
This defines the scope of the
project and drives the project’s
planning efforts. Estimates and
schedules are built based on
the scope. The triple constraint
is named based on the idea
that the three factors of scope,
cost and time are all related.
Decisions and changes to
one, impacts the other two.
At any point in time you can
only constrain two items. For
example, I can define scope
and let that drive my schedule
and cost. If I want to reduce
the amount of time it will take
to deliver the scope, my cost
will change. If I change my cost
and schedule, my scope will
change. Other models expand
the triple constraint to include
architecture, risk, quality and/or
customer satisfaction as these
are also affected by changes
in scope cost and time. For our
discussion, we will keep it simple
and focus on the iron triangle:
cost , schedule and scope.
MODERN GOVERNMENT · May - June 2013
7
Before I dive into the paradigm
shift, let’s explore the goal of
introducing agile.
Fundamentally, the goal is
to drive toward predictability,
flexibility and quality of our
product and service delivery.
We need a way to respond to
the ever faster changes in our
market place. In addition to fickle
consumers and general market
place changes, government
organizations may experience
change with each election. For
some organizations the election
changes may happen more
frequently than their current
project lifecycle. A new law
maker governs within the fixed
time box of the seat held. Driven
to make a noticeable change
before the next election, your
organization is provided an
arbitrary deadline by a law maker
to change a manner in which
you operate. Many times this is
in the opposite direction of the
predecessors orders. Introducing
agile into your organization is
not as simple as mandating all
new projects start following
agile practices and processes.
Remember, agile is a set of
values and principles supported
by practices.
Now let us return to the
triple constraint flip. Most
organizations practicing agile
use fixed time boxes known as
sprints or iterations to create a
potentially shippable product.
The work is ideally performed by
a dedicated and consistent team.
Given my team is fixed, I have
a fixed cost or run rate for that
team. My time is constrained by
8
May - June 2013 · MODERN GOVERNMENT
the time box. If my time and cost
are fixed variables, they will drive
the amount of work that can be
delivered. The scope that can
be delivered is the value being
created for the organization.
Sounds simple, right? What
does this really mean to your
organization? Let’s look a couple
of the factors.
First let’s explore time. What
does it mean to have a time box.
Similar to the law maker in office,
your team has a fixed start and
end date to deliver work. Let’s
understand the assumptions
around time. In order to deliver
a potentially shippable product
in a time box, we must have the
right people on the team, they
are self-organizing and have the
resources available to perform
the work needed.
In order to be successful, a
team must be accountable and
have ownership. Ownership in
the deliverable and ownership
of the method in which to create
the deliverable. Most day to
day decision making needs to
be within the team. If the team
is required to ask permission
and gain approvals on all
decisions their ability to meet
commitments within a time box
are hindered.
In my experience, I have
found government agencies
have a strong military influence.
By nature the military has a
dominate command and control
culture. Rightfully so, lives are at
stake when out in the battle field.
Knowledge workers on the other
hand have different needs. Too
Introducing
agile into your
organization is
not as simple
as mandating
all new
projects start
following agile
practices and
processes.
If the team is
required to ask
permission
and gain
approvals on
all decisions
their ability
to meet
commitments
within a
time box are
hindered.
much command and control can
stifle creativity, lower moral and
hinder productivity. The trick is
to find the right balance between
the organization’s strategic goals,
the organization’s culture and
your leadership style.
Leaders who learn their
managing techniques within
the military often find it
uncomfortable to let go and let
their subordinates make the
decisions. Many times identity
and ego are tied to position and
authority. Giving up decision
making authority may feel like
a loss of power. It also requires
trust. Trust in the process and
trust in the team. In order
to be successful as an agile
organization, you will need to
allow your teams to make day to
day decisions.
To help you over this hurdle,
I suggest, you define clear
boundaries for decision making.
Set allowable change tolerance
thresholds. This is especially
useful in union environments.
Clearly defining the boundaries
of each role’s authority for
decision making around changes
and day to day decisions will
help set expectations and
help keep peace with union
requirements. I used this
technique with a government,
union managed client where
agile practices were introduced.
The thresholds defined allowed
the product owner to make
the priority decisions on work
to be completed by the team,
this included the robustness
of the features to be delivered
within the release. However,
One example is to complete
unit testing of new features
and deploy to a shared system
testing environment where
dedicated testers are available
to finish testing. Then create a
technology roadmap to improve
your environments to evolve into
an agile organization over time.
Another
barrier to time
is not having
the supporting
technology to
complete work
within the
time box.
if a feature was to be moved
to another release or omitted
all together it took a superiors
sign-off. For the organization,
two sprints would be packaged
into one production release. We
had created a product roadmap
and aligned features to release
dates. By making this distinction,
the development team was able
to explore with the product
owner the best way to meet
the needs of the organization
and deliver on time without
having administrative overhead
of capturing approvals for each
low level requirement. Because
we had contracts in place with
vendors, thresholds went on to
define when procurement was to
be involved. More on that later.
Another barrier to time
is not having the supporting
technology to complete work
within the time box. Definition
of done is extremely important.
For work to be considered done,
a set of requirements must be
met. Usually this means the
requirements have been fully
integrated, tested and are ready
to be delivered to production.
Coupling agile engineering
practices such as acceptance
test driven development
and automated continuous
integration with a framework
such as scrum will allow an
organization most flexibility.
Note, the automation is key.
Without automation, the team
will slowly lose their ability to
deliver within the time box. For
example, a team is building a
new application. In the first sprint
they build and test the features.
In the second sprint they build
features set two and regression
test feature set one. In sprint
three, they build a new feature
set and regression test one and
two. If the regression testing is
manually completed, the team
will get to a point where no new
work may be introduced in the
sprint as the team regression
tests all the prior sprint’s new
work. If your organization is in a
situation where you do not have
the technology to support agile
fully, you may need to look at a
hybrid model in the short term.
Now let’s look at scope. As
we discussed above, if time and
costs are fixed then scope varies.
Many government agencies work
with vendors based on contracts
with defined scope. If scope is
variable, how can we measure
a vendor’s services for contract
payments?
First, let’s remember one
of our goals is flexibility
to the changing needs of
the organization. In order
to be flexible, we have to
accommodate the changes
of the organization needs.
We want to be able to do this
without introducing unnecessary
administrative overhead. An
example of how this was handled
at a government agency I
coached, was to clearly define
the time boxes and roles in
the vendor contract. General
scope items were identified but
not committed. The roles were
clearly defined for both the
vendor’s roles and the roles to
be filled by dedicated full time
employees of the organization.
This is a partnership and both
parties must be at the table.
The product owner role was
defined as the accountable role
for directing what was built
and the priority. This role was
MODERN GOVERNMENT · May - June 2013
9
If scope is
variable,
how can we
measure
a vendor’s
services for
contract
payments?
10
filled by the organization. The
organization had clearly defined
authority and accountability.
This accountability on the
organization is the shift in the
paradigm. The organization had
a stake in the game and could
no longer blame a vendor if
something was not delivered
since the organization was
defining what was to be worked
on every step of the way. This
also minimized the need for
a lot of administrative change
control overhead. Remember
the change tolerance thresholds
we discussed earlier, they also
applied for contract changes. If
the product owner wanted to
add scope that would extend the
contracted number of sprints,
a contract change would need
and require appropriate superior
approvals.
As for vendor deliverables,
in order to receive payment, the
vendor provided sprint reports
describing what features were
planned and what features
were delivered along with
end customer reactions to the
sprint show and tells. Metrics
on the number of points or any
other velocity metric were not
included. Points are a relative
May - June 2013 · MODERN GOVERNMENT
unit of measure to define the
effort and complexity of a piece
of work. Velocity is the sum of all
work pieces completed during
a time box. The team’s track
velocity internally to gain insight
into predicting the amount
of work they are capable of
completing in a time box. Points
are not transferable to another
team. Beyond a team’s use, the
values can be misconstrued. For
example, if one team reports a
20 point velocity and another
reports a 30 point velocity, does
it mean the one who completed
30 points did more work? No.
If a leader attempts to use this
as a means of comparison,
the behavior it will drive is
inflated point estimates not
increased output. Increased
out point requires continuous
improvement and removing
obstacles standing in the team’s
way, including unnecessary
process.
We have only touched on a
few ways one paradigm shift
from an agile adoption is a
disruptive change. Through
knowledge of these changes
you will be one step closer
to fully attaining the benefits
of predictability, flexibility
This
accountability
on the
organization is
the shift in the
paradigm.
and higher quality products
and services that agile is
capable of delivering. By truly
understanding the nature of the
disruptions you will understand
and respond appropriately to the
needs of your team. My parting
suggestions for leaders new to
agile are have an expert conduct
an agile readiness assessment
to help you understand where
your process and technology
constraints exist. Then hire
an enterprise agile coach to
develop a roadmap for the agile
adoption and help you navigate
the cultural and leadership
style changes required on your
journey to becoming an agile
organization capable of quickly
responding to change no matter
which way the political winds
may blow. [MG]
Does Agile
Scale?
BY Larry Putnam, Jr.
L
ike Romeo and Juliet,
government’s flirtations
with Agile software
development practices
have been the talk of
the town. But there’s
one aspect of the story we
tend to forget: government is
big—really big. So what happens
to Agile projects when they’re
forced to scale to the size of
major government enterprise
initiatives? We could speculate,
of course. But instead, let’s take a
look at the data.
For this exercise, we analyzed
93 Agile projects, occurring
between 2002 and 2012, mainly
in the Government, Financial,
and Health sectors. We divided
the data into two datasets called
Early Adopters (2002-2008) and
Later Adopters (2009 – 2012),
which gave us similar sample
sizes in both groups. At the same
time, we examined a sample of
93 non-Agile projects with the
same sample demographics.
Then, we charted how the
projects fared as their sizes
(measured in lines of source
code) increased.
Here’s what we found:
Early Adopters
vs. Later Adopters
❚❚ Early adopters had a
significant proportion of
smaller boutique software
firms
❚❚ Later adopters were mostly
large enterprises, with many
from the financial services
and banking sectors
❚❚ Early adopters exhibited
shorter project durations
(faster to market) than later
adopters
❚❚ Later adopters tended to use
more staff than early adopters
and tended to look more like
the non-agile group
Agile vs. Non-Agile
❚❚ Duration of Agile projects
was mostly lower on projects
larger than 14,000 lines of
code
❚❚ Number of defects created
were lower on Agile projects
than non-Agile projects
“Large staff”
projects cost
significantly
more,
achieved
negligible
time savings,
and produced
many more
defects than
“small staff”
projects.
MODERN GOVERNMENT · May - June 2013
11
MB Average Staff VS Effective SLOC
Figure 1: Plotting the number of lines of source code (SLOC)
against the average staff sizes of “small staff” and “large staff” Agile projects.
LARGE TEAMS
1,000
1o0
mb average staff PEOPLE
SMALL TEAMS
1o
1
0.1
1
10
100
1,000
10,000
EFFECTIVE SLOC thousands
So, if our question is whether
Agile projects can scale, the
answer would seem to be yes. As
the projects we analyzed grew
in size, Agile methods produced:
shorter project durations, fewer
errors, and higher productivity.
However, we also learned that
as Agile projects grow, they tend
to expend more effort and use
more staff. And that’s a problem,
because we know from separate
analyses (e.g., the QSM Almanac
study in 2005) that high staffing
12
May - June 2013 · MODERN GOVERNMENT
“Large staff”
projects
keep adding
more people
as they add
functionality,
but the “small
staff” projects
do not.
levels correlate strongly with
waste, regardless of development
methodology.
We also know that
government IT departments
aren’t exactly flush with cash
these days, and that hiring an
army of Agile developers is
probably not in the budget.
So just for fun (yes, this is
what we do for fun), we decided
to take a closer look at Agile
projects in relation to staff
size. Projects with 7 or fewer
staff members we classified as
“small staff,” and projects with
more than 9 staff members we
classified as “large staff.” When
we compared the two groups,
here’s what we found:
“Large staff” projects cost
significantly more, achieved
negligible time savings, and
produced many more defects
than “small staff” projects.
That’s fairly definitive.
But does it hold true even at
maximum scale? 80,000 lines of
code? 200,000? 5 million? The
answer seems to be yes. And
here’s why:
As Figure 1 shows, the “large
staff” projects keep adding more
people as they add functionality,
but the “small staff” projects do
not. (As functionality increases,
“small staff” projects add fewer
than one full-time employee,
whereas “large staff” projects
grow fifty times in staff size.)
What this suggests is that
large-scale Agile projects may
not require big staffs after all.
(Staffing up is just how most IT
managers reflexively respond.)
If, instead, we kept our Agile
staff small, the data indicates
we could complete large-scale
enterprise initiatives much more
efficiently, in nearly the same
time frame.
This is phenomenal news for
government, particularly during
the dog days of sequestration—
when keeping IT teams small
and lean is worth its weight in
U.S. bonds. Using this method,
government organizations can
keep costs down by influencing
the way their contractors staff
development projects, while at
the same time producing more
reliable products.
We must be careful, however,
not to view Agile as government’s
panacea. If our data shows
anything, it’s that Agile projects
are highly variable. We’ve seen
how adopting Agile methods
can potentially lead to modest
schedule compression and
fewer errors, but also a tendency
toward bigger staff size and
higher costs at scale.
So the question becomes:
With all of these variables in
play, how will government
IT managers know when it’s
the right time—or the wrong
time—to implement Agile
methodologies?
The answer, we believe, is
to do exactly what we’ve just
done—run the numbers.
Agile practitioners might try
to minimize upfront planning,
but in large-scale government
initiatives, there will always be
a need for some semblance of
pre-project assessment (even
if it’s done in an iterative, agile
fashion). In fact, one reason
government IT managers have
been reluctant to adopt Agile
methods is for fear of losing that
planning and predictability.
However, this is where
software estimation and
forecasting tools can bridge the
gap. In a recent Harvard Business
Review article (“Why Your IT
Project May Be Riskier Than
You Think”), Bent Flyvbjerg and
Alexander Budzier write:
“[Smart managers] break big
projects down into ones of limited
size, complexity, and duration;
recognize and make contingency
plans to deal with unavoidable
risks; and avail themselves of
the best possible forecasting
techniques...”
But to forecast effectively,
you need data—and lots of
it—on past and present Agile
development projects.
Because the truth is, Agile
development in government is
here for the long haul. [MG]
We must
be careful,
however, not
to view Agile as
government’s
panacea. If our
data shows
anything,
it’s that Agile
projects are
highly variable.
MODERN GOVERNMENT · May - June 2013
13
BY Elizabeth Morris “Lizzy”
Agile
The Catalyst
for Innovation
Scrum
The Framework
for Change
14
May - June 2013 · MODERN GOVERNMENT
T
oday we are blessed to
live in a nation whose
roots were planted by
a people that had the
courage and aptitude
for change. This great
quote “We hold these truths
to be self-evident, that all men
are created equal, that they are
endowed by their Creator with
certain unalienable Rights, that
among these are Life, Liberty and
the pursuit of Happiness”
This quote sets the bar rather
high and is the catalyst of what is
known as the ‘American Dream.’
Today, many Americans would
say that they do not live this
happiness, some would say it is
because they do not feel free.
Liberty is not something that is
evident within their environment.
Here lays the question
how can agile principles and
values drive innovation that
can empower every Americans’
pursuit of happiness.
How can agile
principles and
values drive
innovation
that can
empower
every
Americans’
pursuit of
happiness.
The Agile Principles
Let’s look at the twelve agile principles
1
Our highest
priority is to
satisfy the
customerthrough
early and
continuous
deliveryof
valuable software.
(services,
representation)
5
Build projects
(communities,
job programs),
around motivated
individuals.
Give them the
environment
and support they
need, and trust
them to get the
job done.
9
Continuous
attention to
technical
(details)
excellence and
good design
enhances agility.
2
Welcome
changing
requirements,
even late in
development.
Agile processes
harness change
for the customer’s
competitive
advantage.
6
The most
efficient and
effective method
of conveying
information to
and within a
development
team is face-toface conversation.
10
Simplicity-the art of
maximizing the
amount of work
not done--is
essential.
3
Deliver working
software (services
and government)
frequently, from
a couple of weeks
to a couple of
months, with a
preference to the
shorter timescale.
7
Working software
is the primary
measure of
progress.
11
The best
architectures,
requirements,
and designs
emerge from
self-organizing
teams.
(Communities,
citizens,
townships)
4
Business people
(citizens and
residents) and
developers
(senators, mayor,
must work
together daily
throughout the
project.
8
Agile processes
promote
sustainable
development.
The sponsors,
developers, and
users should be
able to maintain
a constant pace
indefinitely.
12
At regular
intervals, the
team (local town
hall, government
elected officials)
reflects on
how to become
more effective,
then tunes
and adjusts
its behavior
accordingly.
You will note that I have
underlined certain words within
certain principles. The words
within the brackets after the
underline are suggestions for the
replacement.
We are uncovering better
ways of developing software by
doing it and helping others do it?
Through this work we have come
to value:
❚❚ Individuals and interactions
over processes and tools
❚❚ Working software
over comprehensive
documentation
❚❚ Customer collaboration
over contract negotiation
❚❚ Responding to change
over following a plan
That is, while there is value in
the items on the right, we value
the items on the left more
.
Bold words wouldn’t you
agree? Let’s look at what we will
call agile principle number 6.
Well if The most efficient and
effective methods of conveying
information to and within a team
is face to face conversation.
When the last time face to face
interaction was was part of your
company culture? When we have
the option to send an email or
walk around the corner and see
the person, what do we tend to
do? Send an email. Technology
advances seems to have killed
the art and need for in person
MODERN GOVERNMENT · May - June 2013
15
relational interactions. Now we
don’t even pick the phone up to
make a call, we simply shoot a
text. Be careful not to misplace
the message. The 1st agile values
states it best, Individuals and
interactions over processes and
tools. It is important to note
that the people we call the
founding fathers of the agile
manifesto were a cross section
of brilliant technologist and
business thought leaders from
multidisciplines. However, they
realized from year of running
projects and being part of
projects within corporate and
governmental organizations
that if we lost site of the people,
the customer, the user, and the
citizen; we will have missed
the ‘plot’ Technology tooling,
and processes should be there
to empower the individual’s
interaction.
Why Are Individuals
Interactions Important?
At the very core we are simply
human beings as a result
we all have basic needs and
desires. One of those core
needs is interaction with other
individuals. The need to feel
connected, the need to belong,
the need for recognition and
acceptance. Each of these needs
drive human behavior. The
pursuit of happiness requires
these needs be met. Maslow’s
hierarchy of needs shows
the levels at which we need
the interactions with another
individuals
1st Physiological Needs
(air, food, water, shelter,
clothing, sleep)
16
May - June 2013 · MODERN GOVERNMENT
2nd Tier - Safety & Security
Needs (Health,
employment, property,
family, stability)
3rd Tier -Love & Belongingness
Needs (friendship, family,
intimacy, connections)
4th Tier- Self- Esteem Need
(Confidence, achievements,
respect of others,
connections, need for
individuality)
5th Tier - Self Actualization
(Morality, creativity,
spontaneity, acceptance.
Experience purpose,
meaning and inner
potential)
What Environment
Framework Fosters
Individual Interactions
The Scrum framework and scrum
values provide actualization to
tier 3, 4, and 5. Let’s talk scrum.
Scrum is simple framework that
facilities complex problems,
projects, processes being built
out and delivered. It came about
through Jeff Sutherland and Ken
Schwaber released a framework
called, “Scrum.” This framework
is known as an empirical process.
In short, this framework allowed
you to take large complex
unknowns, break them down
into simple statements clarified
by success criteria known as the
acceptance criteria. And these
simplified statements, known
as user stories would be placed
into a time boxed environment
in which a cross-functional team
of individuals would collaborate
their skills in order to make each
simple statement a viable, usable
Scrum is
simple
framework
that facilities
complex
problems,
projects,
processes
being built out
and delivered.
product that delivers value to its
customer. A key principle would
take place through a mechanism
known as a retrospective. The
team would introspect along the
five core scrum values:
❚❚ Commitment
❚❚ Focus
❚❚ Openness
❚❚ Respect
❚❚ Courage
All held on three Scrum Pillars:
❚❚ Transparency
❚❚ Inspection
❚❚ Adaptation.
Agile Siblings that
look like Twins
The very
domestic
threat that
lays within
our borders, it
is our fear to
step out and
innovate, our
fear to adapt.
Agile and Scrum although two
individual separate entities, Agile
speaking to a philosophy and
belief system of working. Scrum
speaking to process that fulfills
that philosophy while delivering
product or service increments.
Interact in such a collaborative
fashion in perfect support of
each other, the industry at large
tends to declare as agile scrum
or scrum agile. Thus suggesting
by implication that to be agile
you need to scrum. That is an
interesting debate to be had at
another time.
❚❚ Commitment speaks to
Tier 2 stability
❚❚ Respect speaks to
Tier 4 Respect of Others
❚❚ Courage speaks to Tier 4
Confidence- Self Esteem
❚❚ Focus speaks to Tier 5
Purpose - Self Actualization
❚❚ Openness speaks to
Tier 3 - connections
❚❚ Customer Collaboration
Speaks to Tier 3 Friendship
Tier 5 Creativity -Self
Actualization
❚❚ Responding to change speaks
to Tier 5 Spontaneity,
❚❚ Working software speaks to
Tier 5 Experience purpose
❚❚ Build projects (communities,
job programs), around
motivated individuals.
❚❚ Give them the environment
and support they need, and
trust them to get the job
done- Speaks to Tier 3
How Can This Knowledge
Empower life liberty &
pursuit of happiness
Taking what is known as the very
simple framework of Scrum, it is
possible to facilitate consistent
value in small increments of
change. Changing the way inner
city children are educated,
changing the way inner city
schools are funded. Allowing
large organizations tax breaks for
financing inner city school and
equipping them to learn today
what they will need tomorrow.
Corporate workers time
volunteered to teach courses in
these schools that don’t attract
the best teachers.
Why not begin an open space
backlog for improving inner city
schools. If cities were allowed
to be self-organizing and make
alliances with businesses to
increase their budgets. Today,
as Americans, we are faced with
many complex unknowns. We
need to be courageous enough
to admit we do not know what
we do not know and implement
an iterative approach to break
down complex issues utilizing
the methods the scum framework
prescribes.
Our department of Defense
mandated a new acquisition
process for information
technology systems, leading to
Agile becoming law. The very
domestic threat that lays within
our borders, it is our fear to step
out and innovate, our fear to
adapt. Our failure in retrospect
to adapt and roadmap our
technology future and education
path has Japan, China, Sweden,
as epic centers of technology
innovation. In times past these
countries and others like them,
were seen as nothing more, but
third world types. Today they
have become leaders due to
their willingness to embrace
innovation, the courage to be
able to step out and get it wrong.
XP (Extreme Programming)
prescribes to fail early, fail fast,
fail often, and fail better. Why is it
so important to be willing to fail?
Thomas Edison said, “I have
not failed. I just found 10,000
ways that won’t work.” James
Anthony Froude says it best,
“Mistakes themselves are the
best teachers of all,” because
as Aristotle said, “He who has
overcome his fears will truly be
free.” This is our root impediment
fear. Our American forefathers
were not fearful they fought to
maintain their freedom from the
Great Britain. It is time to fight
with knowledge, and inspire
innovation!
MODERN GOVERNMENT · May - June 2013
17
Where Do We Begin
Most people spend According to
US dept. of Labor people in the
US spend at least 1896 hours
per year at work on average. If
were to take a closure look at
corporate America we could
probably double that number.
That would raise the issue that
people need to be happy at work.
Let’s talk Work
What can be done in your
environment to make things
better for your teams? Do
you care to improve their
environment? Is the traditional
model of management fostering
innovation in your employees?
Is is easy to think that innovation
only belongs in technology, but
if you encourage innovation
in accounting in your hotels it
means you give your teams the
space to self-organize create
better ways of doing what they
do on an everyday basis. Scrum
prescribes inspection of what we
do so that we can adapt it and
continually improve. If we are not
encouraging improvement and
growth then we are by default
encouraging stagnancy. Managers
should be coaching mentoring
servant leaders thinking about
how they can build team and
inspire growth. The leaders of the
millennium, led by inspiration
and example, not by tasking
and micromanagement. Gardner
report has said waterfall is
dead it is the day of agility
why? Because it creates an
environment and ethos of
empowerment trust and freedom
to be creative which births
solutions to complex problem.
John Fisher’s transition curve
states that we all go through
a transition of happiness. The
18
May - June 2013 · MODERN GOVERNMENT
impact of the awareness that
one’s viewpoint is acknowledged
and shared by others provides
a feeling of relief. A feeling that
something is going to change and
not continue as before. A feeling
of anticipation and potentially
excitement about the possibility
of improvement. Regardless of
the familiarity of the old system,
there also lies truths that no
matter how well we like and are
comfortable with the status quo,
there is something unsatisfactory
about it.
The anticipation makes the
happiness phase one of the more
interesting because we transition
through the phases without
knowing. The feeling of knowing
we have an impact to take control
of our destiny helps move
through the process. Hence the
drive of an individual to pursue
higher education solely from the
extra income an education brings
to satisfy a lifestyle of freedom.
Under the belief that freedom
buys happiness because freedom
in decision making means living
a happier lifestyle.
Dare to Innovate You be
the change agent
Agile principle #4 talks to
business people and developers
must work together daily
throughout a project because
it incites innovative concepts
from the power of collaboration.
Don’t underestimate the
power of synergy that comes
from collaborative efforts.
Bringing these techniques
to our local government to
empower government from
the people by the people
can be more than historical
statement from an epic speech.
It can be a reality! Communities
Is is easy to
think that
innovation
only belongs
in technology,
but if you
encourage
innovation in
accounting
in your hotels
it means you
give your
teams the
space to
self-organize
create better
ways of doing
what they do
on an everyday
basis.
must demand governmental
support to build projects
around the people within
communities the real people,
to develop an environment
conducive for enriching and
cultivating innovation. Methods
of innovation could be the
introduction of serious games to
produce serious results.
The founder of innovation
games Luke Hohmann spent
the last ten years aiming to
shift the mindset of traditional
thinking and techniques around
data harvesting or people’s
opinions, desires, and priorities.
When these methods were first
introduced, it went against the
graining of traditional customer
market research techniques.
Rather than interpret and assume
the end customer’s desire,
Luke had the concept of why
not just ask the customers in a
collaborative face to face fashion.
This led to innovation gains like
creating the product box, buying
a feature.
Today, the San Jose local
government utilize buy-afeature gain model to engage
their constituents in matter
of government budgeting and
priorities. A great mind that is
well respected today once said,
“The secret of change is to focus
all of your energy, not on fighting
the old, but on building the new.”
(Socrates)
They have the courage to
formally engage the people
to become a part of their own
governance model; a wonderful
innovative prototype that sets the
dial on a government, “For the
people, by the people.” (Lincoln)
Bringing in two hundred citizens
from varying demographics in
San Jose’s Town hall, and giving
them copies of the budget and
a limited amount of money to
spend and furthermore, dividing
that amongst the table of fellow
citizens needing to come to
consensus about serious issues
that would affect their city for
the next fiscal year. An example
of these issues: increasing the
police force, closing public
libraries, repaving roads, opening
vs. closing – closing vs. opening
afterschool clubs. These are
just an example of some of the
serious issues this innovative
technique was able to facilitate,
the process of decision making
and prioritizing. Corporate
organizations like SAP, FIAT,
CISCO, ADOBE, and EMERSON
are few organization who use
these serious games to drive
productivity and customer
collaboration.
American Government
customers are the American
It is time to
take Agile and
Scrum beyond
software
into the
communities,
take it to the
people.
people. It is time to actively
listen and deliver continuous
improvement.
Let’s Summarize
It is time to take Agile and
Scrum beyond software into
the communities, take it to
the people. The spirit of the
constitution offered justice,
equality and the hope that the
pursuit of happiness was viable
for everyone. The Principles and
values of agile coupled with the
scrum framework provides the
guidance and agility momentum
to take citizens from theory to
execution. [MG]
MODERN GOVERNMENT · May - June 2013
19
TOP 5
Agile Transformation
Strategies
A practical guide for government
leaders who want to make a difference!
BY Sally Elatta
G
overnment IT isn’t
much different than the
private sector in some
ways, there are simply
too many simultaneous
projects started, very
few are ever “done” and the
handoffs between various
functional silos are killing
productivity.
One major difference however,
is that often government
planning, contracting and
auditing methods are stuck
with antiquated, cumbersome
and wasteful procedures. These
20
May - June 2013 · MODERN GOVERNMENT
waterfall multi-year-you-won’tsee-anything-until-the-end
methods have repeatedly proven
that they lead to failure, BIG
failures on both IT and non-IT
projects.
Unlike the private sector,
government departments
undergo frequent budgetary
crises and mandated policy
changes. Often government
projects are under much more
scrutiny because these BIG
projects are paid for by taxpayers!
For example, the US Department
of Defense canceled a Human
Resources project after 12 years
of wasted effort and 1 billion
dollars was written off costing
every US taxpayer $100. (Thank
you Vivak Kundra for doing so!)
So has Agile actually
succeeded for large government
projects? You bet! Agile saved
the FBI’s Sentinel project at the
cost of $99 million after 10
years of failure and 2 aborted
Waterfall projects that cost $597
million! The US Army Software
Radio was also a large multibillion dollar Waterfall project
saved by Agile methods in the
Agile
methods
are now
being used
to complete
the avionics
software
systems for
both the F35
and F22.
GOVERNMENT
LEADERS
Top 10 Strategies for
Leading an Agile
Transformation
This paper will focus on the first 5
which are fundamental to kicking
off a successful transformation.
The next 5 focused on Scaling the
Transformation will be covered in a
future paper.
1
2
3
Invest in Your
Own Agile Learning
Design a Transformation
Roadmap
Take on the Spiral of Death
– Gov. Planning, Contracting
and Auditing Processes
11th hour. A small Agile team
finished all the hardware and
software at a fraction of the total
budget delivering a complex
system on time. Agile methods
are now being used to complete
the avionics software systems
for both the F35 and F22. The
Ministry of Defense, US Veteran
Affairs, the UK Government
Digital Service, in India, Australia
and New Zealand have all
demonstrated that Agile can work
for Governments.
It’s Time for Serious Change!
But an Agile Transformation for
the Government will require
strong hands on leadership
to drive its success. For this
reason, we will focus on the
key strategies that Government
executives and leaders can
take to lead a successful Agile
Transformation within their
agencies. You see, we can debate
fiscal responsibility all day in
Washington, OR we can roll up
our sleeves as leaders and do the
hard work of making it a reality. If
you succeed, the taxpayers and
citizens of this great nation will
love you!
4
5
6
7
8
Pilot Agile
Successfully
Invest in Agile Training
and Coaching
Invest in a Strong
Technical Foundation
9
10
Scale Agile to Programs and
Larger Initiatives
Transform the Culture to
Servant Leadership and
Cross-Functional Collaboration
Apply Agile and Lean Portfolio
Management
Transform to Enterprise
Stable Agile Teams
MODERN GOVERNMENT · May - June 2013
21
1
Invest in Your
Own Agile
Learning.
Take time out to learn the difference between Agile and Waterfall,
why Agile works and read about real case studies for Agile in the
government. This training Executive/Leadership level training
should help you learn:
❚❚ How an Agile Transformation
will help you make better
buying decisions and improve
quality and time to market. Be
able to answer the Why Agile
question with real statistics
and case studies.
Agile to Scaling Agile to the
Enterprise Transformation
stages successfully.
❚❚ Understand that this is an
organizational transformation
that requires a change
management plan as part of
❚❚ HOW do you actually transform
the roadmap.
your teams to Agile? What
❚❚ Learn and speak to the
is the strategic roadmap and
differences between Waterfall
practical implementation steps
and Agile development. See
necessary for this to work?
below for some key points on
How to move from Piloting
this:
Waterfall
Development
REQUIREMENTS
ANALYSIS-DESIGN
1
DEVELOPMENT
1
2
DEPLOYMENT
2
3
1
TESTING
1
3
4
2
5
6
7
8
9
10
3
4
5
6
7
8
9
10
2
3
4
5
6
7
8
9
10
2-3
months
3-4
months
2-3
months
3-4
months
4
5
6
7
8
9
10
1
2
3
4
5
6
7
8
9
10
DONE!
1
month
22
May - June 2013 · MODERN GOVERNMENT
The chart shows the typical cycles of the
Waterfall process. If you are trying to build
a new software product using Waterfall you
could spend 5 – 8 months just in upfront
planning activities ‘Requirements gathering
and Analysis/Design’. This is called BDUF (Big
Design Up Front) and it’s one the key killers
of projects, especially large ones! Next time
someone tries to convince you to spend 6
months+ getting ‘All the Requirements’ and
design documented in detail and ‘signed off’
you should RUN!
This could be biggest risk factor to your
project because:
1. You will never ever get ‘All’ the
requirements and by the time you think
you did they will all change.
2. You have just spent a third or more of
your budget on ‘documentation’ and have
nothing to show for it. If this project gets
canceled then you have wasted 100% of
your investment and cost.
3. You have many features (10 here) all in
progress but none are ‘Done’. Sounds
familiar?
Work in progress
10 features
Planned
completion time:
11-15 months
4. You’ve lost time and the opportunity
for early feedback. Instead of working
on delivering working products in small
chucks so your target customer can start
testing and giving you feedback (think
Lean Startup), you’ve wasted valuable
time and left all the testing for the end.
Consider if you walked through a new
home you’ve built for the first time right
before moving in… how many ‘defects’
would you find?
Don’t take our word wfor it, here is what
the Dr. Winston Royce, author of the Waterfall
Model says in the paper he published that
gave birth to Waterfall in 1970: “I believe in
this concept but the implementation above
Story Points Delivered
Cost (USD)
Current project done 83%
Current Project Burn 74%
TARGET ACTUAL TOTAL
60
58
TARGET ACTUAL TOTAL
63
58
63
20
0
10
ITERATION 0
52
43
33
20
500,000
400,000
300,000
200,000
100,000
0
63
48
40
63
28
ITERATION 1
ITERATION 2
is risky and invites failure. The
problem is illustrated in Figure 4”
(http://bit.ly/waterfallpaper)
Contrast the waterfall
approach with the above chart
that shows the same project with
10 deliverables going through an
Agile approach.
❚❚ Release Planning: This
is where the Agile team
performs ‘Just Enough’
planning for the project so
that we have a clear ranked
Backlog of requirements
(called stories in Agile) and
a ‘initial’ plan of iterations
needed to accomplish our
goal. This is the first estimate
provided by the team for
potential duration of the
effort using their ‘estimated
velocity’. This approach to
planning is the REAL value
Agile provides; the structure
and discipline of traditional
methods with the flexibility
to adapt to changing mission/
vision needs!
While the Waterfall team
is spending months in
‘Requirements and Design’,
an Agile team would
have already delivered
a few high priority/
valuable items with a few
iterations executed under
their belt. Why does this
matter? Because VELOCITY
MATTERS! That is the only
real number you can count
on for estimating future
performance and delivery.
VALUE DELIVERY matters
because if the Agile project
got ‘cut’, you will have
something to show for it.
450,000
450,000
288,000
550,000
540,000
450,000
360,000
270,000
170,000
85,000
408,000
550,000
180,000
90,000
ITERATION 0
ITERATION 1
ITERATION 2
that is customer tested and
accepted as DONE. In many
cases for larger projects it
takes several iterations to
get enough features that
produce a ‘minimal viable
product’ MVP. These stories
can be software, hardware,
business operations or any
type of valuable deliverable.
Once the team executes a
handful of iterations you will
start to get ‘real velocity’ data.
Velocity is represented by
how many points the team
got DONE within an iteration.
See the sample burn up chart
below answering “What is
Done? How much is it
costing me?”
ITERATION 3
ITERATION 4
PRE-RELEASE
Download a sample
Agile Lifecycle
Diagram from here:
http://bit.ly/
agilelifecyclediagram
Watch these videos
The Business ROI
of Agile Methods
http://bit.ly/UaK0aB
Agile Estimating
and Planning
htt://bit.ly/11c69Gx
Agile
Development
RELEASE PLANNING
ITERATION 0
1
2 DESIGN ITERATION 1
ITERATION 2
3 SPIKES 1
ITERATION 3
4 ARCH 2
4
ITERATION 4
5 SETUP 3
7
5
DEPLOYMENT
6
8
DONE! 6
10
DONE!
2-4
weeks
9 DONE! DONE!
DONE!
2-4
weeks
2-4
weeks
7
8
9
10
2-4
weeks
❚❚ Execution (Iteration 1+):
Deliver small chunks of value
ITERATION 4
Consider this:
2-4
weeks
❚❚ Iteration 0: Build the
foundation with ‘Just
Enough’ setup work needed
to make Iteration 1 Demo/
Review successful. Typical
deliverables maybe High level
architecture diagrams, setup
software/hardware needed,
high level look and feel
designs, team environment
setup, risk mitigation spikes
and so on.
ITERATION 3
550,000
450,000
2-4
weeks
MODERN GOVERNMENT · May - June 2013
23
2
Design a
Transformation
Roadmap
We’ve seen too many Agile adoptions fail
because the organizations and teams got
stuck after they finished Piloting Agile.
Somehow they feel that the logical next step
is to stand back and wait for Agile to grow
organically to other teams.
All the while, leaders once excited and
supporting Agile are now attracted to shiny
new objects to put their weight behind. This
short term attention span can be devastating
to successful organization transformation!
An Agile Transformation doesn’t just
happen organically; it needs a plan and a
roadmap for success. There are 3 stages of
maturity when transforming to Agile:
Plot
Agile
Plot Agile methods on
a few projects to prove
value, gain buy-in and
identify and address
obstacles.
Scale
Agile
Scale to multiple teams,
larger programs and
distributed teams to
gain wider adoption
and confidence in
scaling.
Enterprise
Adoption
Transform the
organization to stable
teams and communities
of practice. Adopt
Agile/Lean Portfolio
Management.
24
May - June 2013 · MODERN GOVERNMENT
So, as a leader of this kind of change
you will need to collaborate on designing a
transformation strategy/plan that includes:
❚❚ Transformation Vision, Drivers for Change,
Objectives, Measures for Success (Why
change and how do we measure success?)
❚❚ Define transformation stakeholders
(who do we need buy-in from for this
to succeed? How will we keep them
involved?)
❚❚ Define transformation barriers and
mitigation plan (how can this fail and what
is our mitigation plan?)
❚❚ Define the Transformation Team (who will
lead this on the ground? Run this as an
Agile project itself)
❚❚ Roadmap for upcoming quarters (what
do we need to get done in the upcoming
quarters to meet our goals?)
Your roadmap may have high level goals
such as which teams to standup and when.
The Agile champion’s team might break
these high level EPICs (large deliverables)
down into smaller chunks to be completed in
short iterations (basic Agile) such as: Training
for the Blue team, standup ScrumMaster
CoP team, address Agile concerns from
compliance team, provide coaching for the
Yellow team, etc.
Watch these videos
Thinking of Agile Adoption?
Start Here
http://bit.ly/11y7KGB
Success Factors When
Transforming to Agile
http://bit.ly/Ok6bJg
Scaling Agile to
Multiple Teams
http://bit.ly/10KtJ1C
3
Take on the Spiral of Death!
Gov. Planning, Contracting
and Auditing Processes
If you’re convinced at all that
using traditional to plan for
large project invites large risk
and waste then consider this:
❚❚ Traditional planning
inspired by the Waterfall
stages advocates spending
significant time and money
on heavy upfront planning/
design followed by a signoff
to seal the requirements.
Development and testing time
is usually crunched because
the initial ‘planning’ phase
usually goes longer than
expected (requirements keep
evolving and don’t stay fixed
like they should!)
❚❚ Traditional contracting
advocates that the processes
outlined above are signed
and sealed in all major legal
documents with contracting
vendors and suppliers. This
means even if you get a
contracting partner who wants
to deliver sooner and apply
some level of agility, they
really can’t because the big
waterfall deliverables and
heaps of documentation are
due (shooting ourselves in the
foot perhaps?).
❚❚ The auditing and compliance
processes now follow. These
individuals could care less
about the difference in Agile/
Waterfall. Their job is to make
sure everyone is sticking to
the contract terms and all the
deliverables as outlined are
being delivered. They assume
that the contract is there to
‘protect the government’,
therefore they will apply
strict review and compliance
procedures to make sure all
the rules are followed.
So poor John who just got
his manager convinced to try
Agile on the current government
project is about to get a reality
check when he realizes the
contract doesn’t have what he
needs for success and actually
mandates many heavy processes
that will get in the way of value
delivery.
Agile contracts should
outline the iterative delivery
of value and not attempt to fix
requirements in detail upfront.
You can still have fixed bid
contracts with Agile but you
should understand that you are
buying a fixed number of team
iterations ‘Purchasing Capacity
and Points’ instead of ‘Purchasing
Specific Features’. Agile contracts
should also outline the expected
gov./contractor collaboration,
visibility and Agile practices to
be employed and define with
clarity the role of the product
owner.
What can YOU do as a leader to
address these issues?
❚❚ Bring the leaders/decision
makers from planning,
contracting and auditing to
have an open conversation
about this. Educate them on
why you are moving to Agile
and collaborate with them to
design ‘lean’ processes that
support Agile. Form a strong
alliance team that is focused
on value delivery, waste
reduction and better buying
power for the government.
❚❚ In June 2012 OMB released
contracting guidance
to support Modular
Development (Agile and
Iterative delivery) that
includes sample SOW and
pricing arrangements. Begin
to write your contracts this
way. (http://1.usa.gov/
Qh7g5M).
Further reading:
Better Buying Power
in the Agile World
http://1.usa.
gov/15u8C3o
Agile Contracting
Manifesto
http://bit.ly/ZnfwXr
Agile Contracts
Primer
http://www.
agilecontracts.org/
❚❚ Take a look at the GAO’s
‘Effective Practices and
Federal Challenges in
Applying Agile’ (http://1.
usa.gov/MPHkM5) and
incorporate the best practices
in your contracts and start
planning ahead for the
top 14 challenges they
identified. This report isn’t a
comprehensive guide but a
good place to start.
❚❚ Design incentives that
reward for value delivery
(story points that are
Done). Foster a culture of
transparency, measurement,
iterative delivery and high
collaboration between your
government agency and your
contractors and suppliers. Do
not accept high risk waterfall
processes where full testing
and delivery are scheduled
at the end.
MODERN GOVERNMENT · May - June 2013
25
4
Try Agile
Successfully
(Pilot)
Piloting Agile means choosing a few teams
to ‘try it out’ and prove success. We can’t
emphasize enough the importance of setting
up these pilot teams for success and giving
them the autonomy they need to deliver
value. Here are some key tips:
❚❚ Choose the right team with the right
technical/soft skills and positive attitude
towards change.
❚❚ Choose the right product owner who can
commit a significant amount of time to the
team. They will need to effectively manage
customer and stakeholder expectations
while providing clarity and focus for the
team.
❚❚ Choose the right project. Not too large,
not too small, one that has good visibility
from leadership.
❚❚ Provide initial training and coaching
for the Agile team and also for their
management/leadership team.
❚❚ Plan ahead and address organizational
impediments (like the spiral of death,
command and control functional
managers, technical environment or skills
gaps, etc.).
26
May - June 2013 · MODERN GOVERNMENT
5
Invest in Agile
Training and
Coaching
The statistics of Agile adoption
success and failure as reported
by the VersionOne State of
Agile Development Survey
2012 (http://bit.ly/18IbPyn)
has consistently pointed to the
importance of Agile training,
education and coaching. Having
internal support groups and
common tools were also cited
as lessons learned. If you’re
getting started with Agile, here
is what we would recommend:
❚❚ Agile Team Training – 3 days
minimum focusing on walking
through the entire Agile
lifecycle with the team and
clarifying roles, expectations,
planning and execution
processes. The goal should
not just be training but also
to gain buy-in and generate
excitement for the change
ahead. If done correctly, this
could be a great jump start for
the team in the right direction.
❚❚ Agile Team Coaching – Some
teams have done well with
only training but the risk
of failure and reverting
back is much higher. You
should consider having an
experienced internal or
external coach supporting the
team for the first few months.
One Agile coach can coach
several teams at the same
time if they are experienced.
❚❚ Leadership/Management
Training: This is a big lesson
learned for us. We’ve found
that teams have struggled
when their own management
and leaders haven’t really
invested any time in learning
Agile and how they can
support the teams. This
should cover challenges such
as resource shifting, balancing
support vs. project work, the
new role of a manager, etc.
❚❚ Product Owner Training: We
usually recommend that the
product owner attend the
team training with everyone
else. If you have a team of
future product owners and
want the existing product
owners to go deeper into
their role then setting up this
workshop would be valuable.
❚❚ Once the team has some
experience with Agile then
you can go deeper into soft
skills like Servant Leadership,
Agile Meeting Facilitation,
Team collaboration skills
in addition to technical
Agile skills such as Agile
Requirements, Agile
Engineering and Agile Testing
practices. [MG]
Managing Federal
Projects in Agile:
Moving Away from
the Waterfall
I
n July of last year, the GAO
issued a report chronicling
the advantages and the
challenges of applying
Agile in government. Simply
put: Ongoing scrutiny of
long-running and expensive
IT projects propelled a move
to change. And now, with the
current sequestration, federal
budgets are squeezed further
and projects are more at risk.
The GAO report includes
direct instruction to avoid
cost overruns and schedule
delays: “To reduce the risk of
such problems, the Office of
Management and Budget (OMB)
recommends modular software
delivery consistent with an
approach known as Agile, which
calls for producing software in
small, short increments. Recently,
several agencies have applied
Agile practices to their software
projects.”
So the question is not, “Why
Agile?” It’s “How Agile?” How do
government agencies adopt a
new way to develop and manage
programs and move away from
tradition-bound practices? And
how do Agile practices work
in the reality of government
organizations? This article
provides practical guidance on
applying Agile in government,
addressing the sheer size, scale
BY Christine Bottagaro
& Roncia Roth
and scope of projects in the
federal sector.
Walk Away from the
Waterfall and into Agile
Waterfall has traditionally
involved big upfront planning
that hinges on an exacting
requirements discipline to
deliver, well, exacting plans. In
contrast, with Agile, you move
away from an up-front, formal
requirements-gathering phase,
as this slows the process of
getting to that short increment
of minimal viable features.
In fact, Agile requirements
development and approvals
are themselves delivered
So the
question is
not, “Why
Agile?” It’s
“How Agile?”
How do
government
agencies
adopt a new
way to develop
and manage
programs and
move away
from traditionbound
practices?
MODERN GOVERNMENT · May - June 2013
27
iteratively and incrementally.
This evolutionary approach
allows teams to gather
stakeholder feedback
sooner – and thus deliver
faster. The requirements
and story elicitation process
is embedded in the Agile
process itself.
In Agile, most
requirements are captured in
what are called user stories.
While that distinction might
be seen as merely tactical,
the move to user stories is
actually a pivotal point in
transitioning to Agile from a
waterfall-based environment.
Deceivingly simple, user
stories encourage Agile teams
to behave differently. Wellcrafted user stories present
the context that leads to
better design, more valuable
features, and faster results;
they are key to team delivery,
velocity and estimation.
These stories are then
delivered in short – typically
two-week –timeframes called
iterations, or sprints.
Written from the
perspective of the end user
or customer, user stories are
managed in the product to-do
list, or backlog. This backlog
is stack-ranked by what can
provide the highest value
soonest, and this backlog
is worked in order. Details
are fleshed out just-in-time,
with an emphasis on the user
stories slated for the next
iteration. Stories further down
the list can remain vague
until they bubble to the top.
By waiting to refine them,
teams wait until they have
more information.
As much of Agile practice
is driven by collaboration
among team members and
across teams, conversation
drives user story definition
and acceptance criteria.
With these largely informal
communications, providing
documentation and
traceability is another
matter. Larger organizations,
or those with multiple,
distributed teams, find using
a centralized Agile lifecycle
management tool essential
for tracking and historical
capture.
Piloting Agile
– Where Do We Start?
New teams, or teams
working with customers
who are new to Agile, might
want to start their Agile
journey or their project
with an “Iteration Zero.”
They use a short timebox
to set the stage for success,
understanding project vision,
reviewing requirements with
stakeholders, and identifying
a roadmap of the most
valuable features. They use
Iteration Zero to set up their
environment and ideally
deliver at least a “hello
world” feature.
Most Agile teams will
simply dive into delivery
at this point. However, an
interim step in the journey
from plan-driven to valuedriven is to conduct an
upfront high-level analysis of
the full project, as well as a
more in-depth analysis of an
initial release or milestone
objective. This analysis
can provide good context,
although it might ultimately
prove wasteful when the
team adjusts the long-term
plan in favor of new learnings.
As the team begins
delivering, and the customer
begins to trust the team,
the weight of these upfront analysis and planning
activities are gradually
reduced. Cadence is
established, focus is clear,
and customers see output
earlier, allowing for inspection
and adaptation to the final
release. Planning activities
settle into a cadence of midrange Agile Release Planning,
wherein teams predict which
stories will be delivered in
which iterations, looking 3 - 6
iterations out. These plans
are refined via more-detailed
iteration planning, at the
beginning of each 2-week
timebox.
Meeting Federal
Documentation
and Reporting
Requirements
with Agile
So how does this apply
to government projects
and programs? Explicit
documentation demands
and regulations are brought
into user stories through the
acceptance criteria for those
stories. When implementing
a user story, the team
completes tasks that include
reporting requirements of
any kind, including those
specified in Exhibit 300. As
the team works on the story,
the specific acceptance
criteria dictate whether the
story is complete or not. The
“definition of done” for that
story has all reporting and
documentation requirements.
Fixed timeline reporting
deadlines are built into the
corresponding iteration,
including any specifics. If the
report due date falls outside
of an iteration, results from
the latest iteration can be
shared, or align the iterations
with the reporting cycles.
Alternatively, engaging
the customer throughout
the process, sharing
achievements and progress,
will gradually reduce the
volume and frequency of the
requested reports.
Agile and Government
Contracting: Productive
Co-existence
Agile delivery methods
don’t actually change the
fundamental nature of
contracting. The basic firm
fixed price (FFP) and time and
materials (T&M) structures,
as well as the many hybrid
permutations in between,
still exist. Just as when using
traditional delivery methods,
with a FFP contract a certain
amount of up-front analysis
and design can reduce risk.
Regardless of your delivery
method or contracting
structure, real success is
about building a trusting
cooperative relationship with
the customer. Applying Agile
helps this process. Valuing
customer collaboration
over contract negotiation,
Agile methods engage
customers earlier in the
process, removing uncertainty
over priorities, trade-off
decisions, and how success
is defined. The visibility and
value-based, data-driven
progress checkpoints of an
With Agile, you
move away
from an upfront, formal
requirementsgathering
phase, as
this slows
the process
of getting to
that short
increment of
minimal viable
features.
Done well,
Agile allows
teams to
deliver more
program value
with less time
and effort.
Agile approach make contract
management and change control
natural and cooperative.
To be clear, Agile does not
remove contractual compliance.
Contracts that explicitly require
detailed up-front analysis and
documentation must be honored.
However, there is often more
flexibility in the form and level
of detail in these documents. An
Agile team serves its customer
by satisfying these requirements
in a lightweight, high-value
manner, with an emphasis on
getting past the documents
and moving the program into
development as quickly as
possible. This is because an Agile
team understands that the best
analysis and the most thorough
risk mitigation comes from
testing, validating and iterating
on a real product.
Going Agile in
Government – Pushing
the Rock Up the Hill
Moving to Agile in government
can be hard, seeming akin to
Sisyphus-like punishment.
Simple in concept, it is decidedly
difficult in application. Perhaps
unsurprisingly, the biggest
challenge is altering mindsets
and changing the underlying
organizational culture. Agile
can be seen as disruptive or
anarchic, when in reality it
produces a more consistent
delivery discipline and
encourages true engagement
and thoughtful behaviors.
Some groups try to ease
the shift by adopting Agile in
phases. However, this approach
introduces significant risk in
the resulting hybrid, or mixed,
methodology. Hybrid methods
reduce the value of both
waterfall and Agile practices,
adding risk to the delivery
and overall programs. Typical
government projects have
uncertainty, complexity and
unknowable requirements.
Clearly an incremental approach
with frequent feedback is
necessary to define, adjust and
apply learnings throughout
the project. A more reasoned
approach is to adopt Agile
wholly, but in a small group. Start
with a pilot project and commit
to Agile for all team members
and stakeholders. Coaching,
resources and a purpose-built
Agile lifecycle management tool
are key success factors.
Choosing a good pilot project
requires paying attention to
two aspects: Is the work a good
candidate for Agile, and, can
you set up the environment for
success? For the first, choose
a project that is especially
likely to benefit from Agile:
One where there is uncertainty
around either the requirements
or the solution, but also
where there is relatively low
complexity -- either technical or
human complexity. In terms of
environment, choose a project
in which you can ensure the
following:
❚❚ A small, cross-functional team
that is dedicated to the work
of the project
❚❚ A person who can fill the
role of Product Owner by
being embedded with and
dedicated to the team and
by gaining consensus from
stakeholders on goals and
features
❚❚ Co-location can reduce risk;
a distributed team must have
good communication tools
and strong facilitation skills
among team leads
Finally, you can pilot Agile
without the express support
of the customer, but you will
achieve far greater results if
customer supports the approach.
Often that first demo of
working software and that first
opportunity to provide feedback
wins the customer over. Seek to
sell the benefits of an iterative,
learning-based approach.
Agile is a tremendously
effective process methodology
for many different environments,
allowing for change and
continuous input throughout
the program or project. Done
well, Agile allows teams to
deliver more program value with
less time and effort. Success
requires re-education, training
and a dedication to the practice,
resulting in on-time, on-budget
projects with less risk and higher
acceptance.
In today’s environment of
budget challenges, effective
Agile projects can make all
the difference. From last
year’s A Common Approach to
Federal Enterprise Architecture,
“Success in accomplishing an
Agency’s mission and optimizing
resources requires a coherent
and consistent understanding
of program and service
performance, and agile planning
and development processes.
This coherent view and agility
becomes more important
in resource-constrained
operating environments.” Or,
as management consultant W.
Edwards Deming wrote, “It is not
necessary to change. Survival is
not mandatory.” [MG]
MODERN GOVERNMENT · May - June 2013
29
Government Agility:
How to reduce IT
cost using Agile
BY Devon Morris
Y
ou have heard the
buzz words - Scrum,
continuous integration
and test driven
development. You have
also heard the myths:
Agile does not work for the
Government; Don’t use agile
on large projects; Agile teams
don’t plan. We could spend time
debunking these myths, however,
it would not add any value to this
article. With a little research, you
can find the truth. Take a journey
with me to discover ways that
Agile can help the government
with Information Technology (IT).
According to the Office of
Management and Budget, federal
IT spending is estimated to be
$74 billion this year, which does
not include the local government,
legislative or judicial branches.
Roughly one third (or $25 billion)
is mismanaged, including cost
overruns and duplications. By
any standard, these numbers
are staggering. What can the
government do to be more
efficient with the dollars that are
entrusted to it? How can they
reduce the cost of IT or at least
better manage the $25 billion?
Simple - GET AGILE.
30
May - June 2013 · MODERN GOVERNMENT
What is Agile anyway?
Agile is a different way of doing
software development. The
term “Agile” is derived from the
Manifesto of Agile Software
Development, known to most
as the “Agile Manifesto,” which
was created in 2001 by a small
group of people that were using
lightweight frameworks for
software development.
The Agile Manifesto consists of
4 values that we have come to
live by:
❚❚ Individuals and iteration over
processes and tools
❚❚ Working software
over comprehensive
documentation
❚❚ Customer collaboration over
contract negotiation
❚❚ Responding to change over
following a plan
Although there is value on the
right, we value the things on the
left more. All Agile frameworks
and methods align with these
values.
There are 12 principles that
support the Agile Manifesto:
1. Customer satisfaction Delivering valuable software
2. Welcome changing
requirements, even late in
development
3. Frequent delivery of working
software
4. Working software - The
principal measure of
progress
5. Sustainable development
and pace
6. Close, daily cooperation
between business people
and developers
7. Face-to-face conversation
- The best form of
communication (co-location)
8. Build projects around
motivated people
9. Continuous attention to
technical excellence and
good design
10. Simplicity—the art of
maximizing the amount of
work not done
11. Self-organizing teams
12. Regular adaptation to
changing circumstances
Think practices
not frameworks
Maybe you have used Scrum
or XP. Maybe you heard of
Feature Driven Development
or the Crystal Orange. Each
agile framework is a collection
of practices that have been
proven to work well together
and drive better results. These
agile practices empower teams
with tools that can exponentially
increase productivity. These
same practices are building the
blocks for demonstrating value
each Sprint, while gaining trust
with customers, stakeholders,
teammates and most of all,
oneself. Although we talk about
frameworks, it is the common
agile practices that help us
continually improve, so let’s talk
about the common practices that
can help
Quicker Time to Market
Agile encourages early and
continuous delivery of software
to satisfy the customer. It
offers a set of tools that foster
improved productivity, shorten
the feedback loop and deliver
based on value. Functionality
is released incrementally and
accelerates return of value from
the government and citizens.
Here are some of the practices
that help improve time to
market:
RELEASE OFTEN – Release
Often is the practice of getting
the software out to the end
customer as often as possible
without inconveniencing them.
This will test your deployment
process and help streamline
it, which removes waste and
clearly creates more value for the
customer.
CROSS-FUNCTIONAL TEAM
– Cross Functional Team, as a
practice, is very important. It
refers to having the necessary
expertise on the team to take
a requirement from concept
to deployed for the user or
customer. This allows the
teams to eliminate waste and
bottlenecks. It enables team to
be iterative and incremental,
which support the team ability to
release early and often.
ONE DECISION MAKER - One
Decision Maker represents the
users of the system and has
knowledge about the business
domain. This person owns the
backlog, writes and clarifies
requirements, and accepts or
rejects the results. This provides
the team with a go to person
for feedback, confirmation of
requirements, and demonstration
of results. This person prioritizes
the backlog to get the highest
value targets done first. All these
things help to improve time to
market.
Fewer Bugs
Most software development
environments are breeding
grounds for a few “friendly”
guests. These guests arrive for
a variety of reasons including
human error, communication
failure, poor design logic and
unrealistic timeframes. When a
time crunch hits, the first thing
to go is testing of every kind and
people begin cutting corners
instead of re-evaluating the
committed.
Here are a few practices that
help foster fewer bugs being
created:
Although we
talk about
frameworks, it
is the common
agile practices
that help us
continually
improve, so
let’s talk about
the common
practices that
can help
ACCEPTANCE TEST DRIVEN
DEVELOPMENT (ATDD)
– Acceptance Test Driven
Development allows us to
build projects that deliver what
the customer wants by using
acceptance testing to validate
requirements. This creates a
trustworthy safety net because,
as you incrementally meet the
needs of the customer, errors are
caught early, mis-communication
is discovered sooner and
ambiguities are cleared up faster.
This results in a code base that is
continually tested and reduces
re-work, which leads to fewer
bugs.
PAIR PROGRAMMING – Pair
Programming is the practice of
two developers working together
on the same computer to build
functionality. One developer
works on building the code with
hands on the keyboard, while
the other developer is looking
forward at the design and
reviewing the code that has been
completed. Two people working
on the same problem improves
MODERN GOVERNMENT · May - June 2013
31
the design and reduces
defects, while building in
a continuous code review
process and collective code
accountability.
TEST DRIVEN DEVELOPMENT
– Test Driven Development is
the practice of writing clean
code by writing tests prior
to writing to just enough
code to pass the tests and
refactoring. At the core, this
practice is ensuring the
software’s technical quality
with tests that are written and
maintained by developers
to enable change of design
and reduction of the cost
of finding and fixing bugs.
This practice takes time and
requires discipline otherwise
the tests become stale.
Stop Building Everything
Many government projects
seem to be infused with a
culture of waterfall norms and
behaviors that support people
building everything perfectly.
Imagine a world that was
imperfect and projects are
only given 20% of the budget
and are held accountable for
the results in order to get
more money. You’ve heard of
the Pareto principle (aka the
80/20 rule), which is the law
of distribution and states that
80 % of your results come
from 20% of your efforts.
If 20% of our efforts
delivers 80% of the value,
common sense would
suggest that we build our
most valuable and most
used features first. The
research from the Standish
Group supports that 20%
of requested features are
Functionality Usage
7%
45%
13%
16%
19%
always or most often used
(See Figure 1). Think about the
software that you use. Now
ask yourself what percentage
of the feature do you use
most of the time... Pause...
Good reason for us to stop
building everything.
Here are a few practices that
can help you get on the right
path of not doing everything:
PRIORITIZATION SCHEMES
help people prioritize work.
The most common scheme is
simple prioritization. Simple
Prioritization is a relative
prioritization scheme from
1-n where no two items can
hold the same prioritization
slot. Another scheme is
MoSCoW, which is divided
into 4 categories - Must Have
(mandatory), Should Have
(desirable), Could Have (nice
to have) and Would Have,
But Can Wait. There are many
prioritization schemes that are
being used by teams.
PARTICIPATORY DECISION
MODELS are when a team
needs to make a decision. One
example is “A Fist of Five”,
where each team member
raises one hand to vote with
their five fingers. When the
hand is raised, each person
must pick one of the six
votes - a closed fist suggests
strong disagreement, 1 finger
suggests slight disagreement,
2 fingers suggests slight
warm disagreement, 3
fingers suggests Luke warm
agreement, 4 fingers suggests
agreement and 5 fingers
suggests strong agreement.
OPEN SPACE TECHNOLOGY is
a simple way to run productive
meetings for five to 2000+
people and a powerful way to
lead any kind of organization,
in everyday practice and
extraordinary change. It is
known for beginning without a
formal agenda and harnessing
the power of self-organization.
This is simply one you have to
see for yourself.
If 20% of
our efforts
delivers 80%
of the value,
common
sense would
suggest that
we build our
most valuable
and most used
features first.
Conclusion
If you are already using an
Agile Framework, consider
using some of these
additional practices. Maybe
you are doing waterfall. If
so, just start with one agile
practice to experiment
with how it works. Gather
the results to find areas of
improve and implement the
improvement. When you
get comfortable, try another
practice. Keep growing with
practices and soon enough
you will get to the point
where you are ready to
pilot an Agile Framework to
implement this new found
knowledge. These are very
simple practices that can
help the government reduce
cost in IT. [MG]
Using Agile to
Inspire Loyalty
BY Michael Swansegar
A
gile transformation is
often confused with
implementing a tool or
a process change. Those
are symptoms, not the
end result. The end
result is inspiring partner loyalty.
There is a stark difference
between a loyal partner and a
paying customer, just as there
is between a paid employee
and one that is loyal. These
simple use cases can be termed
internal and external customers.
Customers are part of a market,
whether it is your commercial
market or internal company
market (the employee pool).
Nowhere else can this be
evident than in our modern
government. The American
democracy is a government by
the people and for the people.
We have a civilian population
and then we have a loyal civilian
population. This is not to say
we have anarchists and then
we have sheep. Rather we have
those who are loyal to our
cause, to our varying beliefs and
needs. We have those that pay
taxes and obey the law, and we
have those that inspire the law
and add the word modern to
government. The loyal civilians
are normally between 15-18% of
the market. Marketing 101 calls
this Maloney’s Rule.
Sometimes they are called
agile, innovators, creators and
visionaries. Many people in the
government do not think we
need an agile culture. Why is
this? When I was teaching at a
Federal office in Washington DC
There is a stark
difference
between a
loyal partner
and a paying
customer,
just as there
is between a
paid employee
and one that is
loyal.
on agile culture, I was told, “We
don’t need to concern ourselves
with loyalty, we make laws
here.” This was disheartening,
to hear. However, just like in a
commercial company, we have
paid employees and we have
loyal employees. This Federal
office is designing the software
exchanges for the Affordable
Care Act (termed ObamaCare).
We can say that everyone must
pay for the end game product
and build the product to meet
the law. Individuals would not
be wrong with that mindset, as
it is reality. Nevertheless, we can
be agile and still want to inspire
loyalty and term it differently.
We can build the product to
the law and call it done.
Or
We can build a product to the
law and take into consideration
that 50% of Americans do not
agree with buying or potentially
using it.
MODERN GOVERNMENT · May - June 2013
33
The majority of that 50% tend
to fall into the Republican party.
The goal is to not only get the
Republican to buy the product
but to see value in the product
and the idea behind it. For
example, if their child is sick, they
now have health care whereas
before they may not due to preexisting conditions. Agile isn’t
about the process change or the
purchase of a product, it is about
inspiring loyalty and identifying
value as the end game result.
How does agile accomplish this?
Let us look at the Scrum process
to see how psychologically we
are inclined to become loyal to a
product or idea.
Pre-planning meetings
are designed to force the
Product Owner (the voice of
the customers) to convey the
vision to the delivery team. The
vision is in the form of user
stories, small slices of value.
The delivery team, also known
as “development”, reviews them
and voices concerns about the
individual stories being too
small or too large. If the story
is too small, they are indicating
that the Product Owner is telling
them how to do their jobs. This
is not the place for the business
minded Product Owner. If the
story is too large, the Product
Owner is still in the clouds, being
the visionary. The Product Owner
needs to come down to a lower
altitude and provide a tactical
pathway for the teams to build
and believe in. This also forces
the Product Owner to go back to
the customer base to get more
information and engage their
thinking. Inspiring a customer
to participate, give input and
more importantly identify their
needs will bring about the “right
34
May - June 2013 · MODERN GOVERNMENT
Agile isn’t
about the
process
change or the
purchase of a
product, it is
about inspiring
loyalty and
identifying
value as the
end game
result.
product” faster.
Planning meetings stimulate
the delivery team to commit
to the forecast of deliverables.
This encourages your internal
customer to believe in the
product and method of delivery.
Do you think only left wing
Democrats are building the
software exchanges? Absolutely
not, the delivery team is made
up of people from all political
spectrums. If the delivery team
is committed, they will want to
build the right quality thing and
an inspiring belief to go with the
tangible good.
The daily stand-up meeting
brings visibility to the company,
and to the Project and Product
Manager roles. These individuals
(titled Scrum Master and Product
Owner) go back to the business
with visibility of the current
pulse of the product and belief.
They remove impediments
whether it be security, a distant
customer, an over-commanding
manager or any thing or belief
that stands in the way of
producing value. The daily standup also changes the employees
to become loyal employees. They
are loyal team members to each
other, constantly challenging
each other to commit and adjust
the workload.
The demo meeting inspires
both the internal and external
customers. The delivery team
does a show-and-tell. The
customers provide feedback.
Why? The customers are there, in
tune, putting their blood, sweat
and time into this product and
belief. They may be of the 50%,
but slowly come to believe that
if this must be in place, it should
be of the highest value, lean,
and lowering cost to our health
care system. In the commercial
world, the customers “are your
employees without being paid,
because they constantly review
Agile is about
people,
people,
people.
Many think
it is a tool or
a process
change.
Instead, as you
have just read,
everything
is about the
interactions
and the
morphing
aspect of
belief systems.
your product and give you the
data you need to build the right
product faster.”
The retrospective meeting
motivates change, adaptability
and most importantly, loyalty.
The delivery team is honest,
open, and direct about what went
wrong and what succeeded. Like
a healthy family, they “mine the
conflict” (5 Dysfunctions of a
Team – The Table Group) and get
in arguments. This helps because
they can commit to being a team,
a family, because all options
are on the table. Offensive
sometimes yes, but never is an
idea about improvement hidden.
The retrospective meetings
have an action plan. This output
encourages the customers to
become partners because they
see a team is maturing in how
they work together. Everyone is
engaged, even if indirectly, to
make things better.
Agile is about people, people,
people. Many think it is a tool
or a process change. Instead, as
you have just read, everything
is about the interactions and
the morphing aspect of belief
systems. A tool may encourage
natural human behaviors to occur
or stifle them. A process change
might make things easier or
harder, but nothing is stronger
than a culture shift, which
occurs in people. The culture
shift is far reaching to your
internal customers and external
customers. Tools are tangible
but devoid of human loyalty.
Processes are not tangible; they
are a framework of the mind
and can’t inspire loyalty without
human commitment.
Regardless of the product
or idea, you need 15-18% of
the market to believe in it. This
is why those odd rubber shoes
(Crocs) dominated the market
for a while. 15-18% of the shoe
market they were trying to reach
thought they were the right
shoe. That all changed when
kids started getting them stuck
in escalators. There is a reason
why individuals stood in line for
5 hours to get the first iPhone,
but now the majority read their
contracts to see if they want to
break them before upgrading.
As markets change and buying
conditions adapt, we constantly
have to evolve to target the 1518%. This is the strength of the
agile culture.
As more people believe, you
have to fight to keep it going.
Products and ideas change
over time to be right. If you
don’t change, they will become
wrong. The government needs
more loyalty, more compromise
and more beliefs. America was
founded by 15-18% of a civilian
market. Our founders were agile.
They believed we needed to
change to become a government
of the people by the people and
for the people. [MG]
MODERN GOVERNMENT · May - June 2013
35
Subscribe
now
Don’t miss the next issue of
MODERNGOVERNMENT
Visit www.moderngovt.com to subscribe
or read the issues you missed!