Live data from Hacker News

The Agile Fluency Model

martinfowler.com

61–70 of 112 posts

Re: The Agile Fluency Model

#61
post #57
post #53

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…

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.

"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

Re: The Agile Fluency Model

#62

Earlier quoted context omitted.

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.

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

I’ve never worked at a place that took breaks between sprints.

Re: The Agile Fluency Model

#63

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

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.

Re: The Agile Fluency Model

#64

When management says sprint, you say, “How fast?” I find the language plain disempowering to developers.

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.

Do cops and doctors get “free time” between cases?

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.

Re: The Agile Fluency Model

#65

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

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.

Re: The Agile Fluency Model

#66
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.

Re: The Agile Fluency Model

#67
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".

Re: The Agile Fluency Model

#68
post #30

Earlier quoted context omitted.

The consultants have taken over "Agile" 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 proces…

It isn't just a "BigCorp" organizational issue. You touched on it, but gently: developers share some blame here. There's a real anti-engineering bias in this industry. I mean engineering as it's practiced in other contexts. There is a process of design and analysis that is done before build and implementation starts that in this industry is considered wasteful or work to be done by lesser mortals who aren't smart eno…

> There is a process of design and analysis that is done before build and implementation starts that in this industry is considered wasteful or work to be done by lesser mortals who aren't smart enough to code.

That's called "backlog refinement" in scrum. And it's supposed to be done by the engineers.

Re: The Agile Fluency Model

#69
post #30

Earlier quoted context omitted.

It isn't just a "BigCorp" organizational issue. You touched on it, but gently: developers share some blame here. There's a real anti-engineering bias in this industry. I mean engineering as it's practiced in other contexts. There is a process of design and analysis that is done before build and implementation starts that in this industry is considered wasteful or work to be done by lesser mortals who aren't smart eno…

> There's a real anti-engineering bias in this industry. 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.

I've watched the "my product isn't safety critical" line of thinking utterly fuck some companies.

Any recommendations on which of your projects I can keep an eye on?

Re: The Agile Fluency Model

#70
post #48
post #40

Earlier quoted context omitted.

I am honestly having trouble parsing through how you simultaneously accuse engineers of being too lazy to use process and then agreeing that there is too much process. 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…

I'm not accusing anyone of being lazy, rather inappropriately arrogant and consequently ignorant. Also, I don't agree there's too much process. I think there's too much bad process that isn't recognized as either bad or process. 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…

"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.

Post reply on HN