ALLEN HOLUB

Agile Process and Architecture, Training and Consulting

CLASSES
TESTIMONIALS
CONSULTING
VIDEOS
SPEAKING
ABOUT
GOODIES
UML QUICK REFERENCE
SWIFT
DESIGN PATTERNS
SLIDES
MORE
BLOG
SUBSCRIBE
You are here: Home / Agility / Getting Started with Agility: Essential Reading
JANUARY 19, 2017 BY ALLEN HOLUB LEAVE A COMMENT
Getting Started with Agility: Essential Reading
0Share
6Share
Tweet
60Share
As is the case with many of the people who actually know what they re talking abou
t, I ve come to shudder when I hear the word Agile, at least until I can figure whet
her the person who uttered the word actually knows what they ve just said. More of
ten than not, they don t.
The word Agile has taken on a meaning that the folks who coined the term at Snow
bird wouldn t recognize a rigid process, mindlessly followed by a small part of an o
rganization that isn t the least bit agile (lower case). The word agile means nimb
le, flexible, adaptable, quick. If you aren t all of those things, you re not agile,
whether or not you re using some Agile technique. Agile is a frame of mind and a cu
lture, not a process. You can implement Scrum perfectly, and not be in the least
bit agile.
What s important, then, is agility, not Agile . I ll be writing a lot about that in th
is blog, but this post lays the groundwork.
I ve found in my teaching that the best way to really get agility is to start with
the basics and work towards the practices (and to actually do it, of course). T
his article is a curriculum of sorts that will get you up to speed on those basi
cs.
There are a boatload of books on Agile, and many are worth reading, but I ve tried
to keep this list short. I focus on the essential background that you need to t
ruly understand what you re doing. The list is, nonetheless, a tad longer than I d l
ike. There is no one source that covers everything, however.
If you re interested in my take on the state of Agile, watch my Death of Agile key
note.
Definitive Documents
Agile is literally defined by the The Agile Manifesto and associated Principles.
If whatever you're doing adheres to the Manifesto and Principles, it's Agile. I
f it doesn't, it's not. Period.
I'm not a big fan of Scrum, but it is popular. Scrum is defined in the The Scrum
Guide. There's a lot of pseudo-Scrum out there, and a lot of things that people
imagine are part of Scrum which are not. For example, stories, burn-down charts
, and stand-up meetings are not part of Scrum. Project managers are not mentione
d in the Guide so are not part of Scrum agile teams are self managing. If you want
to know what Scrum really is, read the Guide.
Agile Culture and The Workplace
Agile is not a process. It's a culture and a philosophy that you can apply in ma
ny ways, with many different processes. Given its cultural nature, the biggest d
ifference between fully Agile shops and traditional ones are the ways that they
treat people. To paraphrase a friend of mine, traditional organizations assume t
hat the workers are conscripts, agile shops assume they're volunteers.
Agile workplaces, then, are completely and utterly different from traditional wo
rkplaces. There are no people telling other people what to do, there are very sh
allow hierarchies and many fewer departments, internal systems are based on trus
t, not control. The idea of accountability is gone, replaced by responsibility.
You're not in Kansas any more, and this is definitely not your father's company.
So, you cannot become agile simply by training a few people in Engineering. Ever
ything has to change.
Spotify, with almost 1000 programmers working in three countries on two continen
ts is a poster child for a functional Agile workplace. They're also proof that A
gile scales just fine within having to use an elaborate prescriptive framework l
ike SAFe (which I think of a way for a big corporation to pretend to be agile wh
ile maintaining the status quo it's a sham). Spotify is the ultimate answer to the
that-can't-possibly-work crowd. If you think it won't work, they're probably do
ing it, and it works. For example, the "squads" (teams) don't have a budget. The
re's a big pot of money, and if a squad needs something, they just buy it. They
don't ask for permission first (which would slow them down if you need the tool/tr
aining/resource now, you need it now!). A dozen of them traveled from London to
NYC so they could interact face to face with another team. They didn't ask permi
ssion. They just went. Working that way saved them vast amounts of time, as comp
ared to the mistrust-based system of permissions that you see in traditional org
anizations.
So, Spotify provides us with a great example of what an Agile organization looks
like. Here are some resources:
Drive: The Surprising Truth About What Motivates Us by Daniel H. Pink
This book is the most important one that I'll discuss. If you read nothing else,
read Drive. Daniel Pink talks ostensibly about what motivates people, but a fun
ctional agile shop is full of motivated people who want to go to work every day
and finish the day satisfied. Turnover in fully agile shops is very low.
Drive talks about how to do that by following three principles: Autonomy, Master
y, and Purpose. Spotify's culture is built on those principles, and they work sp
ectacularly well. Without a Drive-style culture, you can't really be fully agile
.
 Scaling Agile @ Spotify, with Tribes, Squads, Chapters & Guilds by Henri
k Kniberg & Anders Ivarsson.
Spotify's internal workings first came to everyone's attention with this white p
aper (from 2012). They've evolved a bit since then they're an agile organization a
fter all, and if you can't apply the word to your internal processes and structu
re, you're not particularly agile but the basic structure of the company is still
the same as the one described here. The main structural thing they've added is a
triumvirate of managers (for lack of a better word) that guide each the tribes.
These folks are not managers in the traditional sense of assigning tasks and ma
naging budget and time, but they are in charge of the direction that the develop
ment is taking and coordination both within the tribe and between tribes, howeve
r.
Spotify Engineering Culture (video), Part 1 and Part 2 by Henrik Kniberg
.
This video goes into more detail than the white paper, and talks a bit about Spo
tify's internal philosophy and culture. The white paper is more about company st
ructure.
Lean Thinking
You can't understand Agile if you don't understand Lean. Many agile practices li
ke short cycles, non-negotiable quality, regular retrospectives, pulling work fr
om a "backlog," come from Lean. So do important cultural values like trusting th
e people who do the work to decide how to do the work, continuous process improv
ement, and the notions of servant leadership. It's essential that you know Lean
in order to understand both why we do what we do and how we do it.
The four essential books on Lean for the programmer are:
The Goal: A Process of Ongoing Improvement by Eliyahu M. Goldratt.
This book desribes the Theory of Constraints, from which various Lean practices
derive. It talks about workflow, what makes it fail, and how to optimize it. Sou
nds boring, but the book is written in novel form, and is quite readable. Unders
tanding the theory of constraints makes a lot of agile thinking make sense. For
example, the notion of a multi-disciplinary team solves problems associated with
bottlenecks and handoff inefficiencies.
The Phoenix Project: A Novel about IT, DevOps, and Helping Your Business
Win by Gene Kim, Kevin Behr, and George Spafford.
The Phoenix Project takes the ideas layed out in The Goal and applies them to th
e software world. The focus is on DevOps (think: automated and continuous deploy
ment driven by the development process), not software development per se, but pr
etty much everything here applies outside of "operations." The book does gloss o
ver a lot of the details covered by Goldratt, so it can't hurt to read The Goal
first. You might also want to augment this book with Humble and Farley's Continu
ous Delivery: Reliable Software Releases through Build, Test, and Deployment Aut
omation , which has a lot of detailed, nuts-and-bolts advice, but is short on th
e big picture.
Implementing Lean Software Development: From Concept to Cash by Mary and
Tom Poppendieck.
The Poppendieck's have written a lot of books, and they're all worth reading. I
think this one is the best practical introduction to Lean, as applied to softwar
e development.
The Lean Startup: How Today's Entrepreneurs Use Continuous Innovation to
Create Radically Successful Businesses by Eric Ries.
This book is about neither Lean (in the manufacturing sense) nor Startups, but i
t's essential reading nonetheless. Reis lays out an agile-friendly approach to b
usiness planning that centers around customer interaction, short cycles, experim
ents, and making business decisions based on the results of those experiments. L
ean manufacturing is a development process (and philosophy); lean startup is a b
usiness process (and philosophy). You need both.
I should also mention two practical books: Marcus Hammarberg and Joakim Sundeno'
s Kanban in Action, is a good nuts-and-bolts practical guide to implementing a L
ean process (i.e Kanban) in a software development shop. It's not a complete int
roduction to Lean thinking by any means, but it's a great practical introduction
to a Lean/Agile process. Also, David J. Anderson's seminal Kanban: Successful E
volutionary Change for Your Technology Business is the first book to suggest app
lying Lean thinking (Kanaban) to software development. His discussion of introdu
cing Lean at Microsoft is priceless.
Finally, I'd be remiss if I didn't list Taiichi Ohno's Toyota Production System:
Beyond Large-Scale Production. Ono invented Lean. This book is about making car
s (which is why it's not in the main list), and is really about how to run a lea
n business, but it's a great read.
Planning and Process
I'm a little reluctant to list books about process, though I did list a couple o
f Kanban books, earlier.
First of all, Agile is a organization-wide philosophy and culture, not a process
. Agile and Scrum are not the same thing, for example, and Scrum is neither the
only nor the best approach to agility at the engineering level. Moreover, none o
f the processes (Scrum in particular) are complete. You can implement them perfe
ctly and not be in the least bit agile. Finally, you cannot achieve agility by i
mplementing some process "in a bubble" (an existing engineering team doing Scrum
, for example). True agility typically requires a massive cultural shift in the
organization as a whole, and probably a major reorganization and a major rethink
ing of things like governance practices. Reading the books, though, you'd never
get any of that.
I'm also not a big fan of proscribed process in general. You can't be rigid abou
t what you're doing and be agile at the same time. It's best for the team to get
some training, then working with an experienced coach, develop a process that t
hey think will work for them. I do that sort of work and enjoy it immensely (get
in touch!). The process is one of education (literally, "to lead from"). You ca
n't successfully impose process from outside.
If you don't have adequate experience in house or can't find a competent consult
ant/coach, and you want a well-documented place to start your agile journey, the
n implementing a documented process (like Scrum or XP) is a good start. Just bea
r in mind that something you read about (or take a class in) is just a start.
I'm deliberately not listing books on the big so-called "enterprise" processes (
e.g. SAFe). To my mind, these big processes are actively destructive. They are w
ays for expensive consultants to make a lot of money working for big corporation
s that don't understand agility, and probably never will. Don't waste your time
on them. In any event, Spotify is proof that you don't need an over-elaborate ps
eudo-agile process like SAFe to scale agile.
User Story Mapping: Discover the Whole Story, Build the Right Product by
Jeff Patton.
This book isn't about process, per se, but the so-called story is at the heart o
f agile planning. A story is a simple narrative that describes an end user in so
me domain-level role going through some domain-level process to achieve a domain
-level, and valuable, outcome. It does not describe a computer program. All agil
e processes require you to organize your stories by value to decide what to work
on next, and Story mapping is the best way that I know to do that.
Extreme Programming Explained: Embrace Change, 2nd Edition by Kent Beck
and Cynthia Andres
Extreme Programming (XP) was the first Agile process that anybody ever heard of.
Scrum, which actually predates XP, was quite obscure at the time, and XP is act
ually a much more complete process than Scrum, which describes itself as a "fram
ework" for a process. This book describes XP, but more importantly, describes th
e philosophy and culture that underlies it. Most Scrum implementations use XP to
do day-to-day work. Read this book, even if you never plan to implement XP, so
that you can understand Agile thinking.
Succeeding with Agile: Software Development using Scrum by Mike Cohn.
If you do opt to go the Scrum route, Cohn's book is probably the best descriptio
n of how to do Scrum successfully. Its advice is useful even to people who aren'
t using Scrum.
So that s my list. If you have a favorite book of your own, tell the rest of us ab
out it by leaving a comment.
Filed Under: Agility Tagged With: agile, Lean, Spotify
Leave a Reply
Your email address will not be published. Required fields are marked *
Comment

Name *

Email *

Website

POST COMMENT
Contact Allen
+1 (510) 859-3620
allen@holub.com
@allenholub
COPYRIGHT 2017 ALLEN I. HOLUB (ALLEN@HOLUB.COM). ALL RIGHTS RESERVED.