8 ms·
The Agile Fluency Model
- calineczka 9y agoIt seems to me this is James Shore and Diana Larsen writing about "Agile Fluency" on Martin Fowler's blog.
- pi-squared 9y agoAgile 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 https://youtu.be/a-BOSpxYJ9M?t=406
- Fiahil 9y agoDo you think we could draw a parallel between agile software development and the communist movement ?
- pi-squared 9y agowat
- gaius 9y agoAbsolutely. Both claim to be about empowering the Workers but in fact disenfranchise them.
- mjburgess 9y agoAll roles are equal, but some are more equal than others.
- quetzthecoatl 9y agowhy/how? Agile is based on decentralized decision making and is not very big on hierarchy - the exact opposite of communism. Not everything that has a manifesto is communist related.
- gaius 9y agoYou should look up the original meaning of “soviet”.
- state_less 9y agoWhen management says sprint, you say, “How fast?” I find the language plain disempowering to developers.
- chrisseaton 9y agoIn 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.
- taneq 9y agoIt's not "sprint" compared with "walk", as in "go flat out". It's "sprint" compared with "marathon", as in "short burst and we're done". Using the word 'sprint' as an excuse for permanent crunch time is doing it wrong.
- gaius 9y agoBut you’re not done. A sprint is immediately followed by another sprint.
- jungturk 9y agoBut 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 https://en.wikipedia.org/wiki/Pomodoro_Technique
- gaius 9y agoI 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
- emddudley 9y ago
- GiorgioG 9y agoThe 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/ http://programming-motherfucker.com/
- iovrthoughtthis 9y agoSafety in process. Ironic that one of the principals of agile is "people over processes"
- throwaway2016a 9y agoTo 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.
- thesz 9y agoThe time it takes to return to focused/productive state is roughly proportional to interruption time. So this guy above spent 10% of time on meetings and another 10% of his time on the exists and returns to productive state.
- 9y ago
- gormz 9y agoVery odd coincidence. A professor I have just have this whole lecture with the same graphics on Wednesday.
- jdlshore 9y agoI hope he credited us!
- gormz 9y agoI actually just checked the class slack channel and he posted the article in there right after class :)
- jdlshore 9y agoWhich 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.
- quantumofmalice 9y agoAgile methods are solidly in the mainstream, but that popularity hasn't been without its problems. Organizational leaders are complaining that they’re not getting the benefits they expected. This article presents a fluency model that will help you get the most out of agile ideas. Perhaps, rather than a fluency model and the associated billable consulting hours, there are simpler and less expensive explanations of the failure of Agile Inc.'s advice to software developers.
- fouc 9y agoIt seems a bit weird when a methodology requires fluency to be effective at all.
- Lunivore 9y agoIIRC 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.)
- fouc 9y agoUltimately, 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.html https://8thlight.com/blog/uncle-bob/2013/12/10/Thankyou-Kent...
- seertaak 9y ago> Delivering teams deliver on the market cadence. "delivering teams deliver" -- got that. "... on the market cadence" -- err... market. cadence?
- lucozade 9y agoAs "market cadence" doesn't mean anything but sort of sounds like it does, you can just define your delivery schedule as being on the market cadence and you are now a delivering team. When it all goes to shit, the person brought in to clear up the mess can just tut and state that the problem was that the team wasn't delivering on the market cadence after all. Very handy term if you want to sound good but don't actually want to change anything.
- dullgiulio 9y agoYeah, it's written in Consultenglish, not the language you speak. But that sentence just means "an effective team delivers in time for a product to be useful." ... now that is 5000 euros for my consulting service.
- dep_b 9y agoConsultlish, right-clicked it and tapped "add to dictionary"
- quetzthecoatl 9y agoI think it means the teams deliver what the market wants in agile-pugilist speak (cadence of delivery is in sync with the cadence of changing requirements of market).
- swanson 9y agoI 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.
- goalieca 9y ago> "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.
- bullen 9y agoYour 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.
- lulmerchant 9y agoI agree with this 100%. In order to benefit from agile, your codebase and pipelines absolutely NEED to be built in such a way that they can easily accept and ship lots of small changes, and ideally should maximise the efficiency of your code. You should spend most of your time writing business logic, rather than code to facilitate the code that contains your business logic.
- jmull 9y agoI 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 rolling their eyes out of their sockets self-selects as likely to fall for the whole thing.
- honest_george 9y agoI couldn't even read the article, it may as well be written in a different language.
- deleted 9y ago[deleted]
- deleted 9y ago[deleted]
- kolinko 9y agoPerhaps 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."
- polotics 9y agoYes! My suggestion: SoToSe self-organising team-oriented software-engineering
- apeace 9y ago"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?
- zabil 9y agoQuoting something agreeable I read on Twitter a few days ago "If your code is crap, stickies on the wall won't help." - @HenrikKniberg
- perseusprime11 9y agoCan we now talk about Lean as brain and Agile as BS?
- dep_b 9y agoThe 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 this without sarcasm. A lot of developers need some kind of schedule, hand holding and so on to grow into better developers while delivering value. Instead of wondering for 1.5 hours "why is this called a stand up while everybody is sitting down?".
- tempodox 9y agoI was thinking the same thing about Extreme Programming in its day. Developers with the maturity, discipline and experience to employ the methodology don't really need it at all and those who need it don't have the capability to actually make it work. All that remains is cargo cult.
- alistairSH 9y agoIsn't this where agile frameworks like Scrum and Kanban come into the picture? They place some ground rules around "doing agile" for the immature teams to follow. As the team matures, they can drop or alter the rules as needed. And I don't disagree that some teams might never be capable of doing agile in a productive manner. But, I wouldn't aspire to work on one of those teams, or for that team's employer.
- MartinCron 9y agoI don’t think there’s any sauce you could pour over a chain gang of immature programmers to make them palatable. When building teams, I deliberately aim for a mix of developers of more and less experience, as that is a more realistic sustainable steady state than a half dozen superstars.
- kolinko 9y agoThere 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.
- boffinism 9y agoI thought this might have something genuinely valuable to say until I saw the 'TM' after 'Agile Fluency'.
- swanson 9y agoFrom 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.
- martinfowler 9y agoThe title for this HN item is misleading. The article was written by James Shore and Diana Larsen, and they should be credited for that. It is published on my site, because we felt that would help it gain more visibility. I find their model very helpful in understanding how teams take on agile thinking and practices.
- fagnerbrack 9y agoI'm very sorry about that, I was referring to the "Martin Fowler" brand/website, not you as the person. Can't change it anymore...
- sctb 9y agoWe've reverted the title to that of the article. Thanks!
- fagnerbrack 9y agoThanks
- borplk 9y agoDevelopment 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? ... "Agile! shiny ... daily standup" now it's acceptable. Perverse incentives mean businesses devour and bastardise any given methodology into a leverage for themselves and a stick to beat others with. Methodologies were partially meant to empower the employees but that didn't last long. Consultants may ponder about nuances and details. The businesses and managers who never see beyond the next quarter just see it as a socially acceptable brand to exert power.
- tw1010 9y ago"Have been"? This is not a new phenomenon. "Culture" in various forms have for ages (long before you and I were born) been used as a tool to control mindset. See Engineering Culture by Gideon Kunda for more[1]. [1] https://www.amazon.com/Engineering-Culture-Commitment-High-Tech-Corporation/dp/1592135463 https://www.amazon.com/Engineering-Culture-Commitment-High-T...
- ngcazz 9y agoYou 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.
- lovich 9y ago"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
- vermooten 9y agoI'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.
- swanson 9y agoI 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".
- OnlyRepliesToBS 9y agoAgile is a religion lead by salesmen in consultants' clothing.
- knightofmars 9y agoI 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.
- jdlshore 9y agoHi everyone, James Shore here, co-author of the article. I'm happy to answer any questions that you might have, or debate the value of the model.