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.
The Agile Fluency Model
11–20 of 112 posts
Re: The Agile Fluency Model
#12It seems to me this is James Shore and Diana Larsen writing about "Agile Fluency" on Martin Fowler's blog.
Neither of them is an actual engineer, did you notice?
Re: The Agile Fluency Model
#13Re: The Agile Fluency Model
#14Ultimately, agile was successful[1]. Most companies took up many of the good practices. It didn't cure all our problems because coding is hard.
[1] https://8thlight.com/blog/uncle-bob/2013/12/10/Thankyou-Kent...
Re: The Agile Fluency Model
#15The 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 / 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.
Re: The Agile Fluency Model
#16> Delivering teams deliver on the market cadence.
"delivering teams deliver" -- got that. "... on the market cadence" -- err... market. cadence?
Re: The Agile Fluency Model
#17Agile is an adjective; The values of the manifesto for agile software development are lost, this is the original idea of The Manifesto: https://youtu.be/a-BOSpxYJ9M?t=406
Do you think we could draw a parallel between agile software development and the communist movement ?
Absolutely. Both claim to be about empowering the Workers but in fact disenfranchise them.
Re: The Agile Fluency Model
#18> "Organizational leaders are complaining that they’re not getting the benefits they expected."
Aah, the good 'ol consultant proverb: If agile isn't working then it's your own damn fault.
Re: The Agile Fluency Model
#19The 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"
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.
Re: The Agile Fluency Model
#20Your software should be agile, not your process. Your process should be "disturb as little as possible".
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.