Agile 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
why/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.
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
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 choices about what gets worked on. And software developers are expensive. Just like democracy is the worst form of government except for all the rest, agile is the worst process ...
Don’t get caught up in the rigamarole of agile consultants. Every activity is meant to help communication between product and developers. If some activity does not help then convince people with data to stop doing it.
Stories are a blueprint for WHAT is built.
Points are GUESSES at the effort to complete something, which may better inform someone about the order in which stories are played.
Groooming is about meeting those devils hiding in the details.
If you lack the conviction to be an active participant in the process, then do not be surprised at what unfortunate kafkaesque universe you find yourself in.
Even the most mundane stories can have a lot of variability. “I need to mail a lettter” ok, 1 point. Um, there are no stamps. Get in the car to buy some. Car has low gas. Go to the gas station. Get to post office and realize you have no cash ... software development is no different.
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.)
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.
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..
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.
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 enough to code.
That's a big reason why there's all this over-engineering of everything.
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 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. Stop having "real engineering" envy. As the characteristics of software are added to other engineering fields, they start engineering more like us, because that's the right answer. No, we are not in fact specially stupid or lazy, which is exactly the same mistake as thinking we are specially smart or industrious. We're neither, and we do the things we do for reasons every bit as good as the reasons for their processes.
I'm not accusing anyone of being lazy, rather inappropriately arrogant and consequently ignorant. Also, I don't agree there's too much process. I think there's too much bad process that isn't recognized as either bad or process.
I strongly disagree with this: "As the characteristics of software are added to other engineering fields, they start engineering more like us, because that's the right answer." It's the wrong answer, and we get things like these recent Tesla and Uber incidents because of this attitude.
"recent Tesla and Uber incidents because of this attitude."
That is not what I'm talking about; that's software engineers operating in non-software fields without taking in the appropriate expertise. There's nothing special about software there, excepting perhaps that because software is everywhere our field has greater exposure to that mistake, but I've read all sorts of stories where people didn't respect the expertise of people who came before them and made grave errors as a result. That's not even limited to engineering. (In fact it's a well-known common mistake of youth across the board....)
Ironically, the automotive industry is actually the one I had in mind when I wrote that, because I live in Michigan, and personally know some automotive engineers, both on the design and testing sides. We've had several conversations over the years as to how their design processes have changed now that they can plug designs into the computers and do thing like finite element analysis in the computer before they build anything physically. In the 1980s, booking the crash chamber was really hard, because it was in constant use. Now it's easy to get into. They can't close it, because the real automotive engineers know they need the validation of reality, but they do many fewer crash tests than they used to.
Because of the introduction of more of this software into their process, they're doing a lot less of the up-front planning that you might think they are doing, which they used to do, in favor of more exploratory engineering and experimentation in the computer before making anything physical. And you can see the results in modern cars... if you know how to look, anyhow. A lot of it is invisible to the end consumer [1], and some of the engineering gains get somewhat eaten up by additional requirements for safety and such, but a modern car is not just "sorta nicer than they used to be", they are orders of magnitude more sophisticated than they were 30 or 40 years ago, and a lot of that is a direct impact of the fact that they are now able to adopt more software-engineering-like processes into some parts of their engineering. If it weren't for that power, we'd never have cost-effective cars that also meet the safety and emissions requirements.
[1]: "This car is quieter on the road because this strut is here instead of 1.5 cm closer to the front, which is why it has this weird bend in it." Not even an exaggeration. If you look around, you'll also see these weird bits of gluey stuff stuck to a piece of metal or something that doesn't seem to even be gluing something. Those are often for noise or vibration. Some of them are empirically discovered during testing, some during simulation. There's all kinds of little details like that that you don't notice if you don't know what you're looking for.
>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.
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.
> 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.
I've done work for organizations where the practices ranged from extremely strict processes, to no process at all (from requirements gathering to devops.) I feel my best experiences were always in places that had some process that was developed over time, that had management in place that was willing to experiment with changes to said processes. But the way Agile is bought into at most big companies these days...it feels like management just wants to be lazy: "follow the process because hey that's what these smart guys say worked over in org X" even if it's a waste of time/resources/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).
> 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 enough to code.
That's called "backlog refinement" in scrum. And it's supposed to be done by the engineers.
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.
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.
That is a completely unrealistic expectation. There is no human process that "just works". People are not computers.
Scrum/Agile can help competent people who want to improve get better at delivering software that is valuable to their users. No process will magically turn incompetent people with no interest in improving into a productive software team.
You are misunderstanding what I'm saying. I never said the purpose of Agile/Scrum was to turn incompetent people with no interest in improving into a productive software team. That's not the goal. That was never the goal.
You know, you can spend a lot of time mucking around with your C compiler also if you don't know what you're doing. The goal of your C compiler isn't to make you a programmer. It's to help people who already know how to program do it better/faster.
Process doesn't replace software engineering. It takes people who already know software engineering and lets them move as quickly as possible.
It seems to me one of the human irrationalities we don't hear much about is the widespread belief (proved by actions) that process and bureaucracy is free, and therefore, when analyzing a new process, it is not necessary to consider what the costs of the process are. Once you set the cost incorrectly to zero, it only takes some very vague, theoretical, handwaved benefits to tip apparent value of the process positive, and that is a very low bar. So there is an enormous bias in humans for instituting processes.
We almost never consciously get rid of them, either, because even after we've been paying the price of processes for years, somehow we still don't account for them as a cost for that specific process. They're just the cost of doing business or something like that, vague ambient costs that don't attach to anything specific somehow, mysteriously. Something that nobody can get a cognitive handle on and start thinking about clearly.
You'll note I haven't limited this in scope to software engineering at all.
It's not hopeless, though, because people can be educated (for lack of a better word) into properly accounting for costs. For some people it can be a "why didn't I realize this years ago" sort of revelation.
If you manage to start communicating in this way properly, it's also a bus that engineering and the business management can start communicating with each other productively. They don't want to hear about the details of your technical debt, and you probably don't want to hear about the details of how they are refinancing their debts or whatever; you need to trust them to drive the business and they need to be able to trust you to offer them solid cost/benefit analyses of technical decisions, and offer them the correct suite of options (some they may not have considered), and while that may not bring heaven on Earth, at least these two traditionally disparate worlds can be communicating based on cost/benefit terms.
Project management is one part resource planning, one part psychology.
Waterfall is what happens when you slide all the way toward resource planning and ignore the psychological side of the house. Kanban is probably the farthest to the psychology side you can get in a productive manner. Scrum is somewhere in the middle, but the bigger the organization the more they try to steer towards waterfall.
What a lot of business fail to recognize is that different strategies match different businesses.
Scrum is a great fit for contract companies with multiple clients.
In a larger company where you are continuously building one project, you need to be able to move as fast as your developers can go. That generally means Kanban.
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.
Agile 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.
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.)
As "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.
I 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).
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.
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:
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.
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:
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.
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.
> 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.”
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.
"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.
"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?
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.
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 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?".
I 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.
Isn'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.
I 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.
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.
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.
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.
> 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.
The 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.
Development 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.
"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].
You 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.
"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
I'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.
I 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".
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.
111 comments
[ 4.3 ms ] story [ 176 ms ] threadhttp://www.jamesshore.com/Blog/Lets-Play
I find the language plain disempowering to developers.
Using the word 'sprint' as an excuse for permanent crunch time is doing it wrong.
Think Pomodoro technique rather than belaboring the marathon/sprint metaphor.
https://en.wikipedia.org/wiki/Pomodoro_Technique
Also, a scrum is a violent battle for control between opposing teams... that one fit better than they thought too
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 choices about what gets worked on. And software developers are expensive. Just like democracy is the worst form of government except for all the rest, agile is the worst process ...
Don’t get caught up in the rigamarole of agile consultants. Every activity is meant to help communication between product and developers. If some activity does not help then convince people with data to stop doing it.
Stories are a blueprint for WHAT is built.
Points are GUESSES at the effort to complete something, which may better inform someone about the order in which stories are played.
Groooming is about meeting those devils hiding in the details.
If you lack the conviction to be an active participant in the process, then do not be surprised at what unfortunate kafkaesque universe you find yourself in.
Even the most mundane stories can have a lot of variability. “I need to mail a lettter” ok, 1 point. Um, there are no stamps. Get in the car to buy some. Car has low gas. Go to the gas station. Get to post office and realize you have no cash ... software development is no different.
No but they plan to have a workload that doesn’t mean they have to work as fast as they can for their entire career.
You can’t sprint all the time. If you are then you aren’t really at your sprint speed.
Airline pilots do between flights. You can cherrypick an example for anything.
http://programming-motherfucker.com/
Ironic that one of the principals of agile is "people over processes"
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.
So this guy above spent 10% of time on meetings and another 10% of his time on the exists and returns to productive state.
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.
How long did the project actually take?
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..
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.
That's a big reason why there's all this over-engineering of everything.
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 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. Stop having "real engineering" envy. As the characteristics of software are added to other engineering fields, they start engineering more like us, because that's the right answer. No, we are not in fact specially stupid or lazy, which is exactly the same mistake as thinking we are specially smart or industrious. We're neither, and we do the things we do for reasons every bit as good as the reasons for their processes.
I strongly disagree with this: "As the characteristics of software are added to other engineering fields, they start engineering more like us, because that's the right answer." It's the wrong answer, and we get things like these recent Tesla and Uber incidents because of this attitude.
That is not what I'm talking about; that's software engineers operating in non-software fields without taking in the appropriate expertise. There's nothing special about software there, excepting perhaps that because software is everywhere our field has greater exposure to that mistake, but I've read all sorts of stories where people didn't respect the expertise of people who came before them and made grave errors as a result. That's not even limited to engineering. (In fact it's a well-known common mistake of youth across the board....)
Ironically, the automotive industry is actually the one I had in mind when I wrote that, because I live in Michigan, and personally know some automotive engineers, both on the design and testing sides. We've had several conversations over the years as to how their design processes have changed now that they can plug designs into the computers and do thing like finite element analysis in the computer before they build anything physically. In the 1980s, booking the crash chamber was really hard, because it was in constant use. Now it's easy to get into. They can't close it, because the real automotive engineers know they need the validation of reality, but they do many fewer crash tests than they used to.
Because of the introduction of more of this software into their process, they're doing a lot less of the up-front planning that you might think they are doing, which they used to do, in favor of more exploratory engineering and experimentation in the computer before making anything physical. And you can see the results in modern cars... if you know how to look, anyhow. A lot of it is invisible to the end consumer [1], and some of the engineering gains get somewhat eaten up by additional requirements for safety and such, but a modern car is not just "sorta nicer than they used to be", they are orders of magnitude more sophisticated than they were 30 or 40 years ago, and a lot of that is a direct impact of the fact that they are now able to adopt more software-engineering-like processes into some parts of their engineering. If it weren't for that power, we'd never have cost-effective cars that also meet the safety and emissions requirements.
[1]: "This car is quieter on the road because this strut is here instead of 1.5 cm closer to the front, which is why it has this weird bend in it." Not even an exaggeration. If you look around, you'll also see these weird bits of gluey stuff stuck to a piece of metal or something that doesn't seem to even be gluing something. Those are often for noise or vibration. Some of them are empirically discovered during testing, some during simulation. There's all kinds of little details like that that you don't notice if you don't know what you're looking for.
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.
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.
Any recommendations on which of your projects I can keep an eye on?
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).
That's called "backlog refinement" in scrum. And it's supposed to be done by the engineers.
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.
Scrum/Agile can help competent people who want to improve get better at delivering software that is valuable to their users. No process will magically turn incompetent people with no interest in improving into a productive software team.
You know, you can spend a lot of time mucking around with your C compiler also if you don't know what you're doing. The goal of your C compiler isn't to make you a programmer. It's to help people who already know how to program do it better/faster.
Process doesn't replace software engineering. It takes people who already know software engineering and lets them move as quickly as possible.
We almost never consciously get rid of them, either, because even after we've been paying the price of processes for years, somehow we still don't account for them as a cost for that specific process. They're just the cost of doing business or something like that, vague ambient costs that don't attach to anything specific somehow, mysteriously. Something that nobody can get a cognitive handle on and start thinking about clearly.
You'll note I haven't limited this in scope to software engineering at all.
It's not hopeless, though, because people can be educated (for lack of a better word) into properly accounting for costs. For some people it can be a "why didn't I realize this years ago" sort of revelation.
If you manage to start communicating in this way properly, it's also a bus that engineering and the business management can start communicating with each other productively. They don't want to hear about the details of your technical debt, and you probably don't want to hear about the details of how they are refinancing their debts or whatever; you need to trust them to drive the business and they need to be able to trust you to offer them solid cost/benefit analyses of technical decisions, and offer them the correct suite of options (some they may not have considered), and while that may not bring heaven on Earth, at least these two traditionally disparate worlds can be communicating based on cost/benefit terms.
I mean they say "individuals and interactions over processes and tools".
Waterfall is what happens when you slide all the way toward resource planning and ignore the psychological side of the house. Kanban is probably the farthest to the psychology side you can get in a productive manner. Scrum is somewhere in the middle, but the bigger the organization the more they try to steer towards waterfall.
What a lot of business fail to recognize is that different strategies match different businesses.
Scrum is a great fit for contract companies with multiple clients.
In a larger company where you are continuously building one project, you need to be able to move as fast as your developers can go. That generally means Kanban.
Taken over? Nah, Agile is native to consultants: Many of the thought leaders behind Agile are consultants themselves.
If any software gets produced, that is mere coincidence
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.
- 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.)
[1] https://8thlight.com/blog/uncle-bob/2013/12/10/Thankyou-Kent...
"delivering teams deliver" -- got that. "... on the market cadence" -- err... market. cadence?
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.
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.
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.
http://www.se-radio.net/2015/02/episode-221-jez-humble-on-co...
EDIT: HP is covered roughly minutes 8-10.
Also found this, though I'm having trouble getting the video to load to vet it:
https://www.safaribooksonline.com/library/view/continuous-de...
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.
TheCoelacanth made a sibling comment to yours which I think addresses the idea very well:
https://news.ycombinator.com/item?id=16774940
That is in no way in conflict with CI and automated testing. In fact, it would be very difficult to achieve without them.
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.
> 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.”
Aah, the good 'ol consultant proverb: If agile isn't working then it's your own damn fault.
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.
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.
"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.
"Agile? I'm not doing Agile. I'm doing Post-agile."
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?
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.
"If your code is crap, stickies on the wall won't help." - @HenrikKniberg
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?".
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.
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.
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.
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.
> 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.
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.
[1] https://www.amazon.com/Engineering-Culture-Commitment-High-T...
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
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".
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.