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

81–90 of 112 posts

Re: The Agile Fluency Model

#81

Post by kolinko »

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

Re: The Agile Fluency Model

#82

Post by OnlyRepliesToBS »

throwaway2016a wrote: post #15
GiorgioG wrote: post #5

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/

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 last sentence is nothing but hope.

But the company was definitely billed for consultancy.

This pattern of snake oil keeps repeating, all to sell you the ability to force developers to follow Order by PM.

This goalpost moving is evil.

Re: The Agile Fluency Model

#83

Post by gaius »

jungturk wrote: post #77
gaius wrote: post #37

Earlier quoted context omitted.

But you’re not done. A sprint is immediately followed by another sprint.

But you are done - with the goals of that sprint. You complete the work, reflect, and reset for the next sprint's goals. Think Pomodoro technique rather than belaboring the marathon/sprint metaphor. https://en.wikipedia.org/wiki/Pomodoro_Technique

I am not belabouring anything - that was the metaphor the methodology merchants chose. To sprint then sprint then go on sprinting until you are exhausted.

Also, a scrum is a violent battle for control between opposing teams... that one fit better than they thought too

Re: The Agile Fluency Model

#84

Post by apeace »

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

Re: The Agile Fluency Model

#85

Post by zbentley »

GiorgioG wrote: post #42
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…

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

Part of the reason this becomes so dangerous is myopia. If I'm "just building an internal issue tracker", sure, I don't need to spend ages securing it . . . until someone else exposes it to the open internet because that's the only way to make it available to offshore partners (which in turn is because someone in networking made the--from their perspective reasonable--decision not to pay for the setup of a VPN because it was expensive).

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

Re: The Agile Fluency Model

#86

Post by gaius »

spamizbad wrote: post #59
GiorgioG wrote: post #5

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/

> The consultants have taken over "Agile" Taken over? Nah, Agile is native to consultants: Many of the thought leaders behind Agile are consultants themselves.

Agile exists to sell books, consulting, training etc

If any software gets produced, that is mere coincidence

Re: The Agile Fluency Model

#87

Post by commandlinefan »

sidlls wrote: post #30
DanielBMarkham wrote: post #19

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…

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 toys than put on his big-boy pants and do some real work? Pardon me while I bristle with indignation here. First of all, under the repressive regime of "agile" methodologies which demand that I: say exactly what I'm going to do and exactly how long it's going to take and provide ongoing evidence that I did exactly what I was going to do and that it took exactly how long I said it was going to take, have something to demo every single morning to prove that I wasn't wasting the whole day goofing around on Facebook, something open-ended like design is an impossible pipe dream. What does a "design" even look like? A word document? A visio diagram? A powerpoint? In this micromanaged, "I know that you programmers can accomplish any task of any difficulty of any level of lack of definition in any compressed timeline I can think of, but I know you're not doing it because you're a bunch of overeducated spoiled brats" management environment, we've gotten the message loud and clear that we had better do whatever produces what appears to be working software as fast as possible, regardless of how inefficient or anachronistic it might be because in spite of the supposed "talent shortage", every one of us is one angry boss away from unemployment and a line of skeptical prospective employers who don't care how much education or experience you have, but do you know Angular 5? Because we only use Angular 5.

Re: The Agile Fluency Model

#88

Post by gaius »

sankyo wrote: post #64
chrisseaton wrote: post #11

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.

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

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

Airline pilots do between flights. You can cherrypick an example for anything.

Re: The Agile Fluency Model

#89

Post by knightofmars »

throwaway2016a wrote: post #15
GiorgioG wrote: post #5

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/

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?

Re: The Agile Fluency Model

#90

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

Post reply on HN