"It's all rather simple." I said
confidently. "It's a process to maximize our transparency so that we can
deliver the maximum effectiveness of end purpose value to our constituents
while ensuring the highest possible predictability in deliverable milestones
."
Hogarth cocked his head to the side, "I'm not
following. I thought this was supposed to be easy?"
I tossed my hands in the air energetically. "It
is! That's the beauty of it. Why the framework for one implementation can be
summed up in ten minutes."
"Really, so what's the value?" Hogarth
asked.
"Total optimization!" I beamed. "Using
a collaborative team structure you generate value in an iterative cycle that
completely optimizes your process and maximizes customer return."
Hogarth looked at me for a long moment. Finally he
reached up to scratch his chin. "Huh… I'm still not sure I'm following.
How is this different from waterfall?"
I jumped up "Totally different! It will change
the world!"
Hogarth shrugged, "How?"
I let out an exasperated sigh, "Have you been
listening to anything I've said? Haven't you read anything about
this?"
He nodded, "Yep and I'm still not understanding
what's in it for me." He opened up his arms, "If you're going to sell
me on a new way of doing things, you have to tell me what's in it for me and
you need to use small words."
"What's in it for you? Why that's…."
Well damn, the gorilla was right again.
What the Heck is Agile?
A blindingly simple
question that is a lot harder to answer than one might think. Trust me readers,
I will get to the answer, just bear with me a moment as I expound.
I'm an experienced
agilist, I speak about agile often, and I write about agile regularly. And the
other day I found myself trying to explain agile to a program manager who had
zero knowledge of it.
Wow… It's not that
easy.
First problem, where
to start? I took part in the May 11th #PMChat twitter chat, which had a topic
of "An Intro to Agile." It was a great Tweetchat, with a lot of
valuable information. Only it would have been better called "An Intro to
Scrum." That's great, it was a good topic and judging by feedback, very
informative. Only Scrum isn't all that
is agile. When discussing agile, do you start at the nuts and bolts, or do you
start at the overarching philosophy?
Or maybe… You start
with the user.
User Stories:
Skipping ahead to an advanced lessons, we find that User Stories are different
from requirements in that they are focused on the benefit given to the user. So
maybe we should be using the same concept to explain agile. Today is version
0.1 (zero dot one [zed dot one for British folks]) of my agile primer.
Let's look at our users and what agile can do for
them:
Company President- Do you want predictability?
Do you want happy customers? Do you want happy shareholders?
Agile
is a company initiative that creates more predictability in releases and allows
the company to quickly adapt to the customer's needs. Through happy customers
your company has happy shareholders.
Product Manager- Do you want to be able to
change your mind? Did your customer change their mind? Do you want what really
matters, when you need it?
Agile
is a flexible product design process that allows you to adjust the product to
meet changing customer priorities. What ships is what the customer really needs
(and will buy).
Manager- Do you really want to be looking over your
team's shoulder every day? Do you want to help your people grow, not just make
the next code drop?
Agile
gives your team the ability to what they do best, create. It gives you the
ability to do what you are best at, helping your team grow.
Project Manager- Are you tired of chasing down
everyone with the age old "What's your status?" Are you tired of living in the DMZ between
product management and engineering?
Agile
is founded on transparent communication and puts deep focus on collaborative
solutions that have the whole team working towards a common goal.
Developer- Would you like development model
that puts the power in your hands? Do you want to decide how to build
something? Do you want management to listen to you when you say it will really
take three weeks?
Agile
lets you be directly involved in helping to define how something will get built
and even what gets built. The company puts its trust in you to make decisions
and listens to you when you say how long something will take. Schedules are
based on what can be built not some artificial line in the sand.
Great, so what exactly is Agile?
Ah yes, once we get past the benefit we still have to
figure out just what agile is.
An early attempt I
had at a one line summary is: "a customer
focused, iterative process that is executed through a collaborative effort of
the team and company."
Yeah, I know, with
that kind of double speak I should be in politics.
Agile is:
- Listening to the customer
throughout the entire development process, not just at the beginning.
- Focusing on the team. A
better team makes a better product. Trust in the team.
- Building with GPS. You're
constantly making sure you're on course.
- Learning from mistakes, not
just writing them down at the end of the project.
- and -
- Not new. The term is new, the
ideas reach back decades. We owe the Agile Signatories for helping bundle
the concepts into a single word.
- Not a methodology. It's a set
of principles and values. Below these are frameworks like Lean, Kanban,
Scrum and XP.
At its barest
essence, that is what agile is. It's not some secret, make it all perfect,
sauce. It's hard work and incredibly rewarding. It's moving from shareholder
value to customer value. Go read the
Agile
Manifesto. It's not about process, it's about results.
Okay, and?...
Right, that and four
dollars will buy you a cup of coffee. What do we do with this? Good question.
Agile itself isn't a solution. Agile is a mindset, a way of thinking, of
interacting. You still need a framework to work within. The are four common
agile frameworks, Scrum, Kanban, XP and Lean.
In a nutshell:
Scrum- Is characterized by its iteration cycle.
At the start of a sprint (1-4 weeks), the team commits to working on a certain
amount of the Product Backlog (Everything we want built). They meet each day to
review progress and impediments. At the end of the sprint (iteration) they
demonstrate working results (no PowerPoint). Then the team reflects on how the
team did and what can be done to get better.
Scrum
can be very good for new development, where uncertainty is high, change is
constant and the customer is involved.
Kanban- Kanban has evolved from Just in Time
manufacturing concepts. Its primary characterization is the WIP, or Work in
Progress, that limits what can be pulled from the Queue (What needs to be
done). It does not work in iterations, instead working in available workload.
By limiting work in progress, you limit waste and generate greater focus by
reducing multi-tasking. It's other driving factor is it starts with where you
are now, and works to get you to a better process. Where most frameworks are
replacements for existing methodology, Kanban focuses on continuous,
incremental improvement from where you started.
Kanban
can be very good in maintenance, where each item is often unique.
XP- Extreme Programing is probably best known
for the concept of pair programming. XP is known for pushing the limits of
traditional practices (hence "Extreme"). It also uses short iteration
cycles, typically, one week max, as well as demos and retrospectives. It is
also heavily leverages code reviews, unit testing and automation. Typically
more so than Scrum. The average person will see little external difference
between XP and Scrum.
XP
is very common with start ups and for projects that extremely dynamic or have
few starting requirements. You are rapidly prototyping to a final product.
Lean- This practice is best characterized by
the elimination of waste. Anything that does not create value for the end
customer is considered wasteful and a target for elimination. It's a "do
more with less" framework that at works primarily thanks to strong
principles that oversee the structure. Toyota's Total Production System is the
most common example of Lean.
Note: Some will argue that Lean isn't agile. Not
being an adherent to any one framework I see Lean as sharing many of the same
principles and thus put it under the loose umbrella of agile. It's easier than
calling them all "customer focused, iterative development practices that
focus on the team."
Lean
is most common in manufacturing, where the product is relatively fixed and the
improvements are focused on how to produce the product better.
Anything else?
Oh, Gorilla, yes.
There are stacks of books and gigabytes of blogs on agile. I can't even begin
to scratch the surface with all my blogs. Let me leave you with some additional
resources and one last thought.
Mountain
Goat Software- Mike Cohn is one of the leading educators of agile.
His web site is full of information.
Wikipedia- Seriously, the articles on Agile
are very extensive and a great way to get started.
One last thought: All the above is a fairly
basic and fact based review. I'll want to leave you with why I use agile. We've
spent several decades with companies focused on shareholder value. I think the
time is coming to swing back to focusing on customer value. We've also spent
the last several decades focused on getting more out of our teams. I think it
is time to start giving more to our teams.
I think agile is the
key to these changes. I think the values and principles of agile and lean will
change the world for the better.
And I want to help.
Joel
Bancroft-Connors
The Gorilla Talker
Posts
