
The Agile Fluency Model - fagnerbrack
https://martinfowler.com/articles/agileFluency.html
======
jmull
I love this.

"Is [Huge pile of recently promoted buzzwords] not the silver bullet you
expected? We've got the answer: [A new pile of buzzwords]!"

"Here are some charts and graphs and vague paragraphs to confuse you and
intimidate you into hiring us as expert consultants!"

It's sort of like the Nigerian email scam, in that they don't even try to hide
the big piles of B.S. Anyone who makes it through this without rolling their
eyes out of their sockets self-selects as likely to fall for the whole thing.

~~~
apeace
_" Is [Huge pile of recently promoted buzzwords] not the silver bullet you
expected? We've got the answer: [A new pile of buzzwords]!"_

Does your team produce products on-schedule 100% of the time, receive positive
reviews from customers, and consistently generate more and more revenue for
the company? In my experience, a big part of what a team works on is making
these things happen consistently, and then maintaining that consistency as you
add members.

Your reaction suggests to me you haven't spent a lot of time thinking about
how engineering teams work and scale.

Sure, software engineering is easy given a couple constraints:

\- Everyone on your team is on the same skill level, and everyone communicates
well naturally

\- The problems you're solving are small, the system you're building is not
complicated, and in general there isn't tons of work to do

But if those things aren't true, it's harder to scale a team, and the type of
stuff in this article is really useful.

There are teammates who are weak in certain skills and stronger in others.
Bottlenecks arise. There are people in the company who want to take control of
the product and drive it in an unproductive direction. There are departments
who provide a constant flow of small/medium requests, and departments who
once-per-quarter request a large feature. There are valuable customers who
don't quite fit into the model your product supports.

Agility helps you react to all of these things and fix them quickly.

I think this article stands apart from the rest in that it emphasizes _team
learning_. There is only one diagram, and it's about _things you can get good
at_ , not steps you should follow.

Nobody is blindly reading this and following the steps (because there aren't
really steps, if you read it). It exists to help build a common language and
encourage thinking about how you can learn and get better. What's wrong with
that?

~~~
jmull
Well, I've been developing software for more decades that I'd like to admit,
so I've engaged all the issues you mention (and many more).

However, the fact that these problems exist doesn't mean this agile fluency
model has anything to do with solving them.

Generally, my problem with this model is that it's arbitrary, vague and
subjective. You, your team, and other stakeholders will need to take the time
to learn the model, restate your issues in terms of the model and then...
what? Even then, what steps or anything else actionable could result?

In fact, the agile fluency model itself is pretty daunting, what with all the
new terminology (all based on terms that are already massively overload, of
course).

We'd probably need an Agile Fluency Model Fluency Model, so we can label and
discuss the stages of learning and applying the agile fluency model itself.

------
dep_b
The problem with Agile is that it's a thing that only works with adult (of any
age) programmers that have enough experience to be let loose and prosper.

If you're going to pour Agile over chain gang junior sweatshops you're just
doing cargo cult Agile. I think it's important that somebody starts thinking
about what the best methodology for mediocre product managers for managing
mediocre programmers is - and I say this without sarcasm.

A lot of developers _need_ some kind of schedule, hand holding and so on to
grow into better developers while delivering value. Instead of wondering for
1.5 hours "why is this called a stand up while everybody is sitting down?".

~~~
kolinko
There was a nice approach described in the Pragmatic Programmer book if I'm
not mistaken.

The idea was to construct development teams in a way similar to the surgery
teams - one lead developer, one assistant developer (these two "adult" and
very good), and a 3-4 other people who 's job is to make the life easier for
the main devs - someone to manage documentation, someone else to do detailed
testing, one average dev to do the simple and boring stuff, and so on.

That way, in a company of a 100 devs, you'd need 15-30 super-smart developers
(who don't need methodologies and scaffoldings), and the remaining 75 just
junior/average specialists doing specific tasks and fitting into the
structures provided by seniors.

~~~
daveslash
Chapter 3 of "The Mythical Man Month" is titled "The Surgical Team" and
describes just this. If you enjoyed the Pragmatic Programmer, I recommend The
Mythical Man Month as well.

------
GiorgioG
The consultants have taken over "Agile" and turned it into a process-heavy set
of practices. Over the course of a 2 week sprint I spend more than 8 scheduled
hours in various meetings (grooming, planning, scrums,etc.)

[http://programming-motherfucker.com/](http://programming-motherfucker.com/)

~~~
throwaway2016a
To play devil's advocate... that is 10% of your time in meetings that are
defined by scrum to have specific goals that should be accomplished in each.
It is possible (every case varies) that that 10% of time spent has a
multiplying increase on product quality.

It is equally if not more probable it is a waste of time too though.
Especially if the scrum master can't stay focused. I've been able to get 20
person scrum / standup meetings on schedule for 15 minutes every day from
scheduled start to end. You could set your clock by it. But I've seen other
teams take a half hour for less people. That is ridiculous.

As a fun anecdote, once I gave a project estimate and my client paid us to do
detailed project planning because he didn't believe the estimate. We spent 3
days (with 5 people in the room) in requirements gathering, specing, and
estimating stories. The end result... 5% more than my "wild guess" that I gave
the client originally (that they already thought was too high) only now the
client had to also pay for the additional 120 hours we spent in planning.

They asked incredulous how my "wild guess" could have been so close and my
only answer was... experience.

But in the absence of experience those meetings could have provided a valuable
service.

~~~
knightofmars
> The end result... 5% more than my "wild guess"

How long did the project actually take?

~~~
throwaway2016a
We missed target but it was because the client changed a major requirement
half way through after they saw it working the way they originally requested.
I believe that if that didn't happen we would have hit target.

Another argument against up-front estimating and fixed cost projects. It
doesn't take into consideration things like that.

But to that point, really target + what it took to do the estimation. So an
extra week + the money..

------
swanson
I see the comments are trending negatively, so I wanted to share a different
perspective.

Having worked on and along side companies doing "agile transformations" and
every version under the sun of the doing-agile-but-still-not-performing
process, I do think the article is valuable.

My biggest takeaway is a good framing for how I can describe the situation
where teams skip the basics in order to jump to the practices that seem most
exciting.

Having a DevOps group spin up a scalable build pipeline using the latest and
great container cluster will not fix a team that has glossed over the basics
of the "Focusing" team. You'll have individuals that haven't bought into team
success or delivering business value who want to do advanced practices because
they read a blog about how it worked at Etsy or GitHub or Netflix. When the
team still cannot deliver or work together effectively, no one will look at
the root cause but instead layer on more flavor of the month processes, burn
the bridge with anyone non-technical in the organization, or lose people
because the company is just "dysfunctional".

------
fouc
Ultimately, agile was successful[1]. Most companies took up many of the good
practices. It didn't cure all our problems because coding is hard.

[1] [https://8thlight.com/blog/uncle-bob/2013/12/10/Thankyou-
Kent...](https://8thlight.com/blog/uncle-bob/2013/12/10/Thankyou-Kent.html)

------
borplk
Development methodologies have been turned into weapons against the employees.

That's how the average manager sees it, plain and simple. Everything else is
just fluff and cake decoration sprinkled on top.

It's a hip brand that justifies things that would otherwise be hard sells.

Want to drag people into daily meetings where they take turn in telling
everyone what they did yesterday and what they are going to do today? ...
"Agile! shiny ... daily standup" now it's acceptable.

Perverse incentives mean businesses devour and bastardise any given
methodology into a leverage for themselves and a stick to beat others with.

Methodologies were partially meant to empower the employees but that didn't
last long.

Consultants may ponder about nuances and details.

The businesses and managers who never see beyond the next quarter just see it
as a socially acceptable brand to exert power.

~~~
ngcazz
You present a negative outlook that isn't necessarily the endgame of agile,
but it's pertinent to frame it this way! Of course those are some very likely
risks if the team doesn't claim its leverage and demand its stakeholders
engage the development process responsibly, but that's the point of demos and
signoffs.

~~~
lovich
"Sounds like you're a bad culture fit and it's time for a PIP."

That's the usual response I see from managers to employees who try to leverage
anything. The only option I see for employees has been to get another job,
companies are willing to sacrifice all the costs of hiring and onboarding an
employee to make sure they don't have any non compliant ones

------
calineczka
It seems to me this is James Shore and Diana Larsen writing about "Agile
Fluency" on Martin Fowler's blog.

~~~
gaius
Neither of them is an actual engineer, did you notice?

~~~
wagonman
james shore is

[http://www.jamesshore.com/Blog/Lets-
Play](http://www.jamesshore.com/Blog/Lets-Play)

------
pi-squared
Agile is an adjective; The values of the manifesto for agile software
development are lost, this is the original idea of The Manifesto:
[https://youtu.be/a-BOSpxYJ9M?t=406](https://youtu.be/a-BOSpxYJ9M?t=406)

~~~
Fiahil
Do you think we could draw a parallel between agile software development and
the communist movement ?

~~~
gaius
Absolutely. Both claim to be about empowering the Workers but in fact
disenfranchise them.

~~~
mjburgess
All roles are equal, but some are more equal than others.

------
bullen
Your software should be agile, not your process. Your process should be
"disturb as little as possible".

Either you code or you get out of the way and take responsibility for the
people that code by slowing them down just enough to trust them.

~~~
lulmerchant
I agree with this 100%.

In order to benefit from agile, your codebase and pipelines absolutely NEED to
be built in such a way that they can easily accept and ship lots of small
changes, and ideally should maximise the efficiency of your code. You should
spend most of your time writing business logic, rather than code to facilitate
the code that contains your business logic.

------
seertaak
> Delivering teams deliver on the market cadence.

"delivering teams deliver" \-- got that. "... on the market cadence" \--
err... market. cadence?

~~~
swanson
I think it captures a subtle nuance pretty well.

If you're building a SaaS app, you can release several times a day and users
will not notice and be fine.

If you're building a mobile app, you can release maybe 1-2 times a month and
users will be fine. If you push out 3 app store updates every day, that is
going against the market cadence.

If you're building software for automated machinery, you can release maybe 1-2
times a year. The market will not accept running updates every night.

Without considering the context of your market, saying things like "we need to
be doing more CI/CD" or "we need to be working in 2 weeks sprints" or "we'll
be ready to release the new version in 18 months" might not make much sense at
all.

~~~
jdmichal
I disagree. I got the opportunity to hear a talk from Jez Humble, and one of
his examples was HP and printer drivers. So this is likely in your last
scenario there. They still reaped a lot of benefits from fixing their
development processes and advancing continuous integration and automated
testing. It looks like it might be mentioned in this podcast, though I haven't
listened yet:

[http://www.se-radio.net/2015/02/episode-221-jez-humble-on-
co...](http://www.se-radio.net/2015/02/episode-221-jez-humble-on-continuous-
delivery/)

EDIT: HP is covered roughly minutes 8-10.

Also found this, though I'm having trouble getting the video to load to vet
it:

[https://www.safaribooksonline.com/library/view/continuous-
de...](https://www.safaribooksonline.com/library/view/continuous-
delivery/9780134389363/CONT_01_05.html)

~~~
swanson
I don't think we are in disagreement. Certainly there are benefits from these
things. The crux is that practices will reach diminishing returns at different
times depending on context -- one such piece of context being market cadence.

Is continuous integration and automated testing helpful? Yes. Is the
cost/effort to move from a process that can deploy monthly to one than deploy
hourly worth it? Well, it depends -- if our customers want software updates
once per year, then no, it doesn't particularly matter if "master is ALWAYS
deployable" or "no builds are failing" on a given day.

~~~
jdmichal
Except what happens is that business want to release a completed feature. But
you're half-way through your monthly deploy cycle and thereby have to either
push the date or force your process faster.

TheCoelacanth made a sibling comment to yours which I think addresses the idea
very well:

[https://news.ycombinator.com/item?id=16774940](https://news.ycombinator.com/item?id=16774940)

------
knightofmars
I give credit that each section actually calls out a "Core Metric". I'd wager
that most organizations get through "Focusing" and "Delivering" only to fall
apart at "Optimizing".

They call out exactly why the "Optimizing" step fails, "One of the biggest
challenges in enabling Optimizing fluency is giving the team true control over
its product direction. The distinction between an Optimizing team and a
Delivering team is that, within the constraints of its charter, the Optimizing
team makes its own decisions about what to fund and where to focus their
efforts. Managers need to delegate this power to teams, which is often a
difficult change for organizations."

A CEO, VP, or high level employee in a product management capacity will not
want to give up this control. After all, from their perspective they're in
their position because they've steered the product to it's current success.
Yet, there's never an actual track record, metrics, or decision record to
determine how well these "decision making" individuals have actually performed
in steering the product. And attempting to implement any sort of framework to
track successes and failures at this level will be met with extreme prejudice.
After all, nobody wants to find out that they're actually bad at a $200,000 \+
a year job.

------
zabil
Quoting something agreeable I read on Twitter a few days ago

"If your code is crap, stickies on the wall won't help." \- @HenrikKniberg

------
state_less
When management says sprint, you say, “How fast?”

I find the language plain disempowering to developers.

~~~
chrisseaton
In agile are you permanently in a sprint? When one sprint ends you start a new
one, right? That's insane - you can't sprint all your life.

~~~
emddudley
Which is precisely why there is a break between sprints, for planning and
downtime...

~~~
pault
That's funny, in all of the places I have worked the sprint ends on a Friday
and the next one starts on Monday. I want one of these sprint breaks.

------
gormz
Very odd coincidence. A professor I have just have this whole lecture with the
same graphics on Wednesday.

~~~
jdlshore
I hope he credited us!

~~~
gormz
I actually just checked the class slack channel and he posted the article in
there right after class :)

~~~
jdlshore
Which university and class was it, if you don't mind me asking? I'd like to
keep track of where the model is being taught. Feel free to email me at the
email in my profile if you'd rather not respond publicly.

------
goalieca
> "Organizational leaders are complaining that they’re not getting the
> benefits they expected."

Aah, the good 'ol consultant proverb: If agile isn't working then it's your
own damn fault.

------
vermooten
I've had a downer on Scrum for a long time - and yes I'm a Scrum Master - but
this article has crystalised my thinking. Also the site someone posted below
with a profame name - awesome. Enough already jeez.

------
jdlshore
Hi everyone, James Shore here, co-author of the article. I'm happy to answer
any questions that you might have, or debate the value of the model.

------
boffinism
I thought this might have something genuinely valuable to say until I saw the
'TM' after 'Agile Fluency'.

~~~
swanson
From the footnote:

> Agile Fluency is a trademark of James Shore and Diana Larsen. (We’ve had
> problems with other people using the term “Agile Fluency” while
> misrepresenting our model, so we felt we needed to trademark the term to
> prevent that from happening.)

I can see how that would be frustrating, as this model is a response to the
warping of Agile. Have to fight fire with fire, I suppose.

------
fouc
It seems a bit weird when a methodology requires fluency to be effective at
all.

~~~
Lunivore
IIRC it's named after similar levels of language fluency. So the idea is that
you start by:

\- being able to ask for things you want (ordering in restaurants or getting a
team to deliver something),

\- then offering things to other people (waiter in a restaurant, or saying,
hey, would this feature be useful to you in the state it's in right now?)

\- then being able to negotiate and talk about advanced themes (running a
business, or saying, so, we couldn't do quite what you designed, but here's
something that meets your intent; how's that?)

\- then by being totally fluent and disruptive (writing poetry and literature,
or moving into a new market).

The idea is that there's value at each stage, and some people won't actually
need to move to subsequent stages if they're getting what they want in earlier
ones.

(I am not an expert in the AFM and stand ready to be corrected.)

------
martinfowler
The title for this HN item is misleading. The article was written by James
Shore and Diana Larsen, and they should be credited for that. It is published
on my site, because we felt that would help it gain more visibility. I find
their model very helpful in understanding how teams take on agile thinking and
practices.

~~~
fagnerbrack
I'm very sorry about that, I was referring to the "Martin Fowler"
brand/website, not you as the person. Can't change it anymore...

~~~
sctb
We've reverted the title to that of the article. Thanks!

~~~
fagnerbrack
Thanks

------
perseusprime11
Can we now talk about Lean as brain and Agile as BS?

------
quantumofmalice
_Agile methods are solidly in the mainstream, but that popularity hasn 't been
without its problems. Organizational leaders are complaining that they’re not
getting the benefits they expected. This article presents a fluency model that
will help you get the most out of agile ideas._

Perhaps, rather than a fluency model and the associated billable consulting
hours, there are simpler and less expensive explanations of the failure of
Agile Inc.'s advice to software developers.

