The Agile Fluency Model
martinfowler.com
martinfowler.com
"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.
"Agile? I'm not doing Agile. I'm doing Post-agile."
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?
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.
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?".
And I don't disagree that some teams might never be capable of doing agile in a productive manner. But, I wouldn't aspire to work on one of those teams, or for that team's employer.
When building teams, I deliberately aim for a mix of developers of more and less experience, as that is a more realistic sustainable steady state than a half dozen superstars.
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.
A process for creating good software with only mediocre developers is not a realistic expectation. You are always going to need some more experienced people for the juniors to learn from.
Ironic that one of the principals of agile is "people over processes"
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.
So this guy above spent 10% of time on meetings and another 10% of his time on the exists and returns to productive state.
How long did the project actually take?
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..
No, what's happened is that BigCorp has decided to adopt Agile and won't adopt anything without a lot of instruction books and role descriptions.
The consultants, at least the ones who know what they're doing, have been trying to fight this all along. It's the industry itself that continues to over-engineer everything it touches, from Javascript frameworks to development processes.
What we keep finding is that you can't keep people from themselves, that is, if you don't give somebody a 47-page instruction book full of diagrams and processes they want, somebody else will.
I really, really wish the problem with Agile was simply the consultants. Instead, as we've seen with process after process, we keep screwing it up, feeling that the more of something we have, the better it must be. Consultants, tool vendors, trainers, and the like? They're just adjusting their marketing pitch to what people want to hear.
That's a big reason why there's all this over-engineering of everything.
I don't engineer as other engineering disciplines do, because my world is not like other engineering disciplines. If architects could push a button and see a skyscraper built in five minutes, then push another button to tear it down and build it with a slightly tweaked again, for basically no cost, often while clients are actually living in the building (!), you'd see them doing a lot less up-front planning from them, too. Stop having "real engineering" envy. As the characteristics of software are added to other engineering fields, they start engineering more like us, because that's the right answer. No, we are not in fact specially stupid or lazy, which is exactly the same mistake as thinking we are specially smart or industrious. We're neither, and we do the things we do for reasons every bit as good as the reasons for their processes.
I strongly disagree with this: "As the characteristics of software are added to other engineering fields, they start engineering more like us, because that's the right answer." It's the wrong answer, and we get things like these recent Tesla and Uber incidents because of this attitude.
That is not what I'm talking about; that's software engineers operating in non-software fields without taking in the appropriate expertise. There's nothing special about software there, excepting perhaps that because software is everywhere our field has greater exposure to that mistake, but I've read all sorts of stories where people didn't respect the expertise of people who came before them and made grave errors as a result. That's not even limited to engineering. (In fact it's a well-known common mistake of youth across the board....)
Ironically, the automotive industry is actually the one I had in mind when I wrote that, because I live in Michigan, and personally know some automotive engineers, both on the design and testing sides. We've had several conversations over the years as to how their design processes have changed now that they can plug designs into the computers and do thing like finite element analysis in the computer before they build anything physically. In the 1980s, booking the crash chamber was really hard, because it was in constant use. Now it's easy to get into. They can't close it, because the real automotive engineers know they need the validation of reality, but they do many fewer crash tests than they used to.
Because of the introduction of more of this software into their process, they're doing a lot less of the up-front planning that you might think they are doing, which they used to do, in favor of more exploratory engineering and experimentation in the computer before making anything physical. And you can see the results in modern cars... if you know how to look, anyhow. A lot of it is invisible to the end consumer [1], and some of the engineering gains get somewhat eaten up by additional requirements for safety and such, but a modern car is not just "sorta nicer than they used to be", they are orders of magnitude more sophisticated than they were 30 or 40 years ago, and a lot of that is a direct impact of the fact that they are now able to adopt more software-engineering-like processes into some parts of their engineering. If it weren't for that power, we'd never have cost-effective cars that also meet the safety and emissions requirements.
[1]: "This car is quieter on the road because this strut is here instead of 1.5 cm closer to the front, which is why it has this weird bend in it." Not even an exaggeration. If you look around, you'll also see these weird bits of gluey stuff stuck to a piece of metal or something that doesn't seem to even be gluing something. Those are often for noise or vibration. Some of them are empirically discovered during testing, some during simulation. There's all kinds of little details like that that you don't notice if you don't know what you're looking for.
Does this accurately reflect how software development works in the real world?
It accurately reflects what is both technically possible for software in general, as well as actual practice in many places. It's true that lots of places have heavier process that treats software engineering more like civil engineering. This is sometimes for good reasons based on the consequences of errors in the application domain, or because the software is a component of a hardware system that will be deployed in conditions where easy upgrades aren't practical; on the other hand, it's often not.
What we do is hardly real engineering in most cases. I don't mean medical or transportation systems. In BigCorp, most of us write line of business applications, which will generally speaking not directly kill anyone - unlike designing/engineering bridges, roof systems, etc.
Any recommendations on which of your projects I can keep an eye on?
Each person is making more or less reasonable decisions, but the way they interact with the rest of the whole is what causes disasters and inflicts real harm on people's lives.
A question I'm interested in is: "real" engineering has the same issue of scale and potential myopia. Consider the guy mixing concrete at the batch plant on a tight schedule who, faced with an impending shortage of aggregate, mixes a little less into his mud--he does this so the trucks lining up to fill won't have to wait for the other truck bringing more aggregate. Now, his concrete was headed for a bridge, which is genuinely structurally compromised by the lack of aggregate. Do things like this happen in other fields of engineering with anywhere near the same frequency they happen in software? Why or why not?
(In the concrete example--and, to be honest, this is just 'cause I like talking about concrete--there is no "right" answer given the shortage. "Fatten" the mud by lacking aggregate? Structural issues. Let trucks wait? Jobs with unfinished pours may have premature cementing, which, unless their contractors are willing to bite the "tear down the partial pour; it's too cemented--wreck it, rebuild the forms, start over" bullet which pretty much always ends up pointed at them and not the batch plant, leads to . . . you guessed it, structural issues).
That's called "backlog refinement" in scrum. And it's supposed to be done by the engineers.
The rule with frameworks is this: the more time you spend thinking and screwing around with the framework, the more you're either doing it wrong or it's hurting more than helping. Scrum/Agile should just work, just like your C compiler just works. It's a tool that operates almost invisibly in the background while you make stuff people want. If it takes a long time to work with it, or you spend a lot of time fussing with it or arguing over whether you're doing it right or not? You've got something backwards somewhere.
People end up with long sprints and tons of meetings either usually because they don't understand what they're doing or they're doing it the wrong way. Personally I prefer week or less sprints. Anything else tends to grow a bunch of meeting BS over time that's non-productive.
Scrum/Agile can help competent people who want to improve get better at delivering software that is valuable to their users. No process will magically turn incompetent people with no interest in improving into a productive software team.
You know, you can spend a lot of time mucking around with your C compiler also if you don't know what you're doing. The goal of your C compiler isn't to make you a programmer. It's to help people who already know how to program do it better/faster.
Process doesn't replace software engineering. It takes people who already know software engineering and lets them move as quickly as possible.
We almost never consciously get rid of them, either, because even after we've been paying the price of processes for years, somehow we still don't account for them as a cost for that specific process. They're just the cost of doing business or something like that, vague ambient costs that don't attach to anything specific somehow, mysteriously. Something that nobody can get a cognitive handle on and start thinking about clearly.
You'll note I haven't limited this in scope to software engineering at all.
It's not hopeless, though, because people can be educated (for lack of a better word) into properly accounting for costs. For some people it can be a "why didn't I realize this years ago" sort of revelation.
If you manage to start communicating in this way properly, it's also a bus that engineering and the business management can start communicating with each other productively. They don't want to hear about the details of your technical debt, and you probably don't want to hear about the details of how they are refinancing their debts or whatever; you need to trust them to drive the business and they need to be able to trust you to offer them solid cost/benefit analyses of technical decisions, and offer them the correct suite of options (some they may not have considered), and while that may not bring heaven on Earth, at least these two traditionally disparate worlds can be communicating based on cost/benefit terms.
I mean they say "individuals and interactions over processes and tools".
Waterfall is what happens when you slide all the way toward resource planning and ignore the psychological side of the house. Kanban is probably the farthest to the psychology side you can get in a productive manner. Scrum is somewhere in the middle, but the bigger the organization the more they try to steer towards waterfall.
What a lot of business fail to recognize is that different strategies match different businesses.
Scrum is a great fit for contract companies with multiple clients.
In a larger company where you are continuously building one project, you need to be able to move as fast as your developers can go. That generally means Kanban.
Taken over? Nah, Agile is native to consultants: Many of the thought leaders behind Agile are consultants themselves.
If any software gets produced, that is mere coincidence
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".
[1] https://8thlight.com/blog/uncle-bob/2013/12/10/Thankyou-Kent...
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.
[1] https://www.amazon.com/Engineering-Culture-Commitment-High-T...
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
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.
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.
"delivering teams deliver" -- got that. "... on the market cadence" -- err... market. cadence?
When it all goes to shit, the person brought in to clear up the mess can just tut and state that the problem was that the team wasn't delivering on the market cadence after all.
Very handy term if you want to sound good but don't actually want to change anything.
But that sentence just means "an effective team delivers in time for a product to be useful."
... now that is 5000 euros for my consulting service.
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.
http://www.se-radio.net/2015/02/episode-221-jez-humble-on-co...
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...
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.
TheCoelacanth made a sibling comment to yours which I think addresses the idea very well:
That is in no way in conflict with CI and automated testing. In fact, it would be very difficult to achieve without them.
The idea is that you could release, if you wanted to... but there might be good reason not to want to, in a particular market. For instance, a retailer might time the release of certain features around Christmas or summer clearance.
> Fluent Delivering teams not only focus on business value, they realize that value by shipping as often as their market will accept it. This is called “shipping on the market’s cadence.”
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.
"If your code is crap, stickies on the wall won't help." - @HenrikKniberg
I find the language plain disempowering to developers.
Using the word 'sprint' as an excuse for permanent crunch time is doing it wrong.
Think Pomodoro technique rather than belaboring the marathon/sprint metaphor.
Also, a scrum is a violent battle for control between opposing teams... that one fit better than they thought too
If you let the product team dictate every story, you are doing it wrong. Grow a spine and negotiate some tech stories into the sprint. After you establish credibility, it will get better.
If something needs refactoring and a 2point story comes along with that code, make it a 5 point story and clean up the code.
In a business, cash is oxygen and it must make smart choices about what gets worked on. And software developers are expensive. Just like democracy is the worst form of government except for all the rest, agile is the worst process ...
Don’t get caught up in the rigamarole of agile consultants. Every activity is meant to help communication between product and developers. If some activity does not help then convince people with data to stop doing it.
Stories are a blueprint for WHAT is built.
Points are GUESSES at the effort to complete something, which may better inform someone about the order in which stories are played.
Groooming is about meeting those devils hiding in the details.
If you lack the conviction to be an active participant in the process, then do not be surprised at what unfortunate kafkaesque universe you find yourself in.
Even the most mundane stories can have a lot of variability. “I need to mail a lettter” ok, 1 point. Um, there are no stamps. Get in the car to buy some. Car has low gas. Go to the gas station. Get to post office and realize you have no cash ... software development is no different.
No but they plan to have a workload that doesn’t mean they have to work as fast as they can for their entire career.
You can’t sprint all the time. If you are then you aren’t really at your sprint speed.
Airline pilots do between flights. You can cherrypick an example for anything.
Aah, the good 'ol consultant proverb: If agile isn't working then it's your own damn fault.
> 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.
- 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.)
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.