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

101–110 of 112 posts

Re: The Agile Fluency Model

#101

Post by jerf »

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?

How often do you iterate through the edit-build-test cycle? If you're not able to do it in under a minute, you may want to invest some attention to your development processes. At a slightly higher level, CI integration should be building your product from scratch at the same rate that commits come in for projects in the 1-5 devs, and you can do a lot of building in 5 minutes. With continuous deployment you get the "clients living in the building at the time" part of the metaphor. I don't have anything like that myself, but it's certainly a thing. Cities would look a lot different if things were this changeable in the real world.

Re: The Agile Fluency Model

#103

Post by TheCoelacanth »

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…

They define releasing at market cadence as being capable of releasing at will, so that you can release at any time that the market conditions make it desirable to release.

That is in no way in conflict with CI and automated testing. In fact, it would be very difficult to achieve without them.

Re: The Agile Fluency Model

#104

Post by jdmichal »

swanson wrote: post #96
jdmichal wrote: post #78

Earlier quoted context omitted.

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

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

Re: The Agile Fluency Model

#105

Post by throwaway2016a »

knightofmars wrote: post #89
throwaway2016a wrote: post #15

Earlier quoted context omitted.

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

> The end result... 5% more than my "wild guess" How long did the project actually take?

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

Re: The Agile Fluency Model

#107

Post by jmull »

apeace wrote: post #84
jmull wrote: post #21

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

"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 t…

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.

Re: The Agile Fluency Model

#108

Post by jdlshore »

gormz wrote: post #106
jdlshore wrote: post #102

Earlier quoted context omitted.

I hope he credited us!

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

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.

Re: The Agile Fluency Model

#109

Post by DanielBMarkham »

TheCoelacanth wrote: post #98
commandlinefan wrote: post #87

Earlier quoted context omitted.

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.

Sure. You can have daily sprints if you like --- if you know what you're doing.

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.

Re: The Agile Fluency Model

#110

Post by polotics »

kolinko wrote: post #79
jmull wrote: post #21

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

Perhaps we should invent some kind of a term for Agile, as it was meant originally... "Agile? I'm not doing Agile. I'm doing Post-agile."

Yes! My suggestion: SoToSe self-organising team-oriented software-engineering
Post reply on HN