Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Agile Fluency Model

martinfowler.com

Post reply on HN
Print view View original

91–100 of 112 posts

Re: The Agile Fluency Model

#91

Post by TheOtherHobbes »

jerf wrote: post #40
sidlls wrote: 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…

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…

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

Does this accurately reflect how software development works in the real world?

Re: The Agile Fluency Model

#92

Post by dragonwriter »

TheOtherHobbes wrote: post #91
jerf wrote: 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…

>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. Does this accurately reflect how software development works in the real world?

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

Re: The Agile Fluency Model

#93

Post by daveslash »

kolinko wrote: post #81
dep_b wrote: post #34

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 thi…

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…

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.

Re: The Agile Fluency Model

#94

Post by TheCoelacanth »

dep_b wrote: post #34

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 thi…

Come up with a method that lets you reliably produce working software with only junior developers and you will probably become the world's first trillionaire.

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.

Re: The Agile Fluency Model

#96

Post by swanson »

jdmichal wrote: post #78
swanson wrote: post #63

Earlier quoted context omitted.

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…

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/epi…

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.

Re: The Agile Fluency Model

#97

Post by Lunivore »

seertaak wrote: post #16

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

I've also heard the Agile Fluency people use the term "Release at Will".

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.

Re: The Agile Fluency Model

#98

Post by TheCoelacanth »

commandlinefan wrote: post #87
sidlls wrote: 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…

You make it sound as though I could do all of this up-front design and analysis work, and it would all be time well spent, and it would save time and effort in the long run, and it would produce a better end-product and the customers and my boss would be happier with the results, but I'm not doing that because... I'm just difficult that way? I'm a lazy, coddled, spoiled, petulant developer who'd rather play with his…

WTF kind of Agile process is that? I've never heard of anyone having daily demos. The processes I've seen schedule them for every 2-3 weeks. If you're referring stand-up meetings, the people involved in those aren't supposed to be managers, they are supposed to be the people who you are directly working with.

Re: The Agile Fluency Model

#99

Post by Lunivore »

fouc wrote: post #10

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

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

Re: The Agile Fluency Model

#100

Post by jdlshore »

seertaak wrote: post #16

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

First two sentences of that section:

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

Post reply on HN