Agile isn’t about speed, it’s about direction
tim.mcnamara.nzIt's about whatever some commentator thinks its about this week in order to get blog hits, sell more books, or to appear influential or as a thought leader etc etc etc.
Most of us with a brain have looked at it and taken the best parts of what is there and incorporated into our workflow for ourselves and our teams, and dumped the rest.
The rest just parrot on the same talking points with a different angle every week.
I think your contempt here is not a bad default position, but I think you misapply it here.
I was involved in the movement before the term "Agile" existed. I agree it is now on average horseshit, and have been saying so a long time. [1] But I think that one of the things that hasn't been broadly incorporated what is mentioned here: vigorously pursuing faster feedback loops.
So many places are so top-down and plan driven that their corporate structures and corporate cultures just don't let them take advantage of release-early, release-often approaches. Done right, it is hugely powerful because you get to learn ASAP when you are wrong. But in so many places people essentially don't want to know that. They would rather lose months or years to bad plans and bad practices than seek out the kind of real-world feedback that lets them know when something is wrong. People would rather feel smart and look smart than take the hit and learn from enough mistakes that they become actually smart.
Indeed, I think the reason that so much "Agile" is horseshit is that people reject the most important Agile changes such that they can keep on believing they're doing just great. They just don't want their process rub their noses in the fact that however fast they're going, it's not in the right direction.
[1] e.g., from 2011: https://williampietri.com/writing/2011/agiles-second-chasm-a...
The problem is that organisations want a magic formula that will solve all their problems. So they buy an off-the-shelf process with no regards to how it even came to be.
Every time I see something not quite working the way it should in an agile environment, I refer back to the manifesto. Anything that feels like it's going more towards "the things on the right", I point it out.
Good managers are willing to listen. Most other engineers either already understand what's wrong or dislike the current processes anyway so are open to trying a bit less of them.
When all else fails or when something feels off, get back to first principles.
> The problem is that organisations want a magic formula that will solve all their problems. So they buy an off-the-shelf process with no regards to how it even came to be.
I feel we need to take a step back and look at the organizational problem. Is your job to get things done in a team environment or waste time and effort reinventing the wheel of how to organize work in software development projects? If you're there to ship software then you adopt pre-established organizational methods and adapt them to better suit your team and org's needs.
It turns out that planning projects with high levels of uncertainty and frequent changes in goals and requirements is hard, and thus a JIT/dead reckoning approach to planning with all the stakeholders involved provides acceptable results while minimizing uncertainty.
So what are you going to do, if your goal is to get stuff out of the door? Are you going to reinvent the wheel or are you going to get stuff done with standard approaches?
If the so called "standard approaches" are in the way of my delivering quality software, I'm absolutely going to call it out and do my best to change it. Most times, if that's impossible, the correct course of action is to leave rather than delivering poor quality.
It's a similar version of "build vs buy" discussions that happen at every level, from "do we even build an engineering team vs outsource to contractors" to "do we include leftpad or write our own method," and everything in between.
There are people out there with high amounts of resistance to using something someone else hasn't recommended or appeared to vet, at every level.
It's often about trying to manage downside risk vs trying to maximize upside. Orgs where people are more afraid of having someone they can blame than they are motivated to truly excel are going to lean towards things they can pay other people to decide for them.
I guess the “No True Agile” crowd is as alive and well as they were 10 years ago. When it’s a failure, they always come out of the woodwork to let you know you weren’t doing it according to the orthodoxy. When you point out that it isn’t faster in practice, they gaslight you and claim that was never the point in the first place.
In a way it reminds me of a cult. You do a series arcane rituals that have no scientific evidence behind them, none of the process is data-driven or statistically proven. Frankly, it can’t die soon enough but as we all know some new hype will simply take its place to give busybody managers a reason to exist.
Fine. Let's assume that Agile is worse than the alternative. I am willing to accept that. However, which process are you arguing for, in its stead? "Programming, Motherfucker?" Shapeup? (Shapeup gets pretty close to agile in spirit.) Spiral Model? (I am assuming you're not arguing for RUP or others.)
Conceptually, I like shapeup. I think spiral model is fine - I'd argue that a lot of "agile" shops are closer to spiral.
Now, there are tools in agile that I'll vehemently defend, such as continuous integration and retrospectives. I'm a fan of most of the principles, such as "Continuous attention to technical excellence and good design enhances agility." But we are now at a point that if we're going to argue that "agile doesn't work," we've had enough time as an industry to gather around an alternative.
The alternative is to just do what makes sense, without calling it anything. Junk shit like what scrum has become, for example not discussing technical stuff during standup (why the fuck not? that's what our job is about), artificially splitting stories into 2 week boxes (why the fuck should I break down something that isn't naturally breakable?), why create a card for every thing I'm working on (fucking control freak heaven), etc. It's completely juvenile, gaslighting, cargo cult scientology.
Continuous integration => of course, for me, never worked at a place where it didn't happen and that was before agile was even a thing. If I hopped on a project where it didn't make sense though, I should be free to ditch it.
There is no one way to write software that works for every project and there is no one process that works for every project. Just let the experienced folks decide what to use instead of leaning on some bullshit fixed crap process.
> The alternative is to just do what makes sense, without calling it anything.
You argue in favor of not calling things things, and then go on to call a lot of things things. You demonstrate why we need to name things: to talk about them more effectively.
What makes sense to one person may not make sense to another. I agree that each team should decide based what's right for them based on the people and the problems. But to do that beyond the trivial, we need to name things.
Sure you can name things, but there is no agreed upon definition of what scrum or agile means, so don't talk about them. They are useless, unscientific terms.
Does it need to have a fancy name and can’t be some frankenstein process you set as you look at the team and address the part where they needs structure ?
> However, which process are you arguing for, in its stead?
You don't need to do any other process. You can just talk to people as problems arise and do that "in stead".
Woah woah woah.
Hold up.
You mean to tell me that someone just pulled stories, story points, point poker, scrum, and the master of the scrum, burn down charts, spikes, iterations, sprints, and retrospectives ... all out of their ass?
> (...) all out of their ass?
This blend of mindless contrarianism gets tiresome. If this discussion was about hand-writing, you'd be accusing left-ti-right languages of being pulled out of the ass as well just because it's the standard shared by most.
People feel the need to plan work, estimate work effort, and allocate resources to get stuff done. Some people adopted these methods and they get value out of them. Not everyone has the luxury of picking up tickets created by magic and "it's done when it's done".
If you have a better way of doing this then be my guest and use it, but I have a nagging feeling you'd shit on that too just to feel smarter than everyone.
It's because a lot of agile is just plain stupid in real world use.
For example, story points are always being converted back to wall time because in the real world you have resources who can work x amount of hours and you need to plan around that.
What's the point of using an intermediate unit?
Story points shouldn't get converted back to resource time. They're just a way of ballparking estimates sufficient to let product managers make broad choices, and to help teams keep from getting excessive amounts of worked crammed into an iteration.
So don't use them as an intermediate unit. If you want hours, just ask for estimates in hours. I think that's not a great idea for all sorts of reasons, but if you're in a culture that values output over outcome, you may not have a choice, and clearly plenty of projects succeed with GANTT charts and whatnot.
In our process, we've been consistently told that a weight of 8 corresponds to a two week (10d) sprint, and that 80% of our time should be spent on scrum tasks. Then, if any developer closes more than 8 points in a sprint, we are told that we aren't estimating properly. They have all but equated 1 point to 1 day, but the scrum master consistently denies that weight corresponds to time.
I'm new to this. Are we agile?
I mean, that all sounds very Scrum to me in that uses agile words while sounding very top-down, awkward, and constrained.
To me, the agile movement, at least initially, was about empowering teams to get things done for users. I came out of the Extreme Programming end of things, which had a dozen practices to start with. But the people behind it said that they offered that set of practices as a place to start. From there, teams were supposed to use the short feedback loops to inspect and adapt.
So in my opinion, that is not agile. However, as I've written about elsewhere [1], I think the Agile movement got taken over by something that was more marketable to executives with a top-down orientation.
So in short, I think what they're saying sounds like bunk to me. The way I used points was as purely relative estimates. Point velocity per iteration was a measured quantity, used mainly to make sure the team didn't oversubscribe an iteration. E.g., if the team did 10 last week, this week we'd take on 10. If we thought we might get done early, we could always pull another card in.
But alas, it sounds like you're trapped in what I think of as mini-waterfall, where people who have waterfall biases have broken their big thing down into two-week-sized waterfall lumps.
For what it's worth, I long ago stopped doing estimates entirely except in special circumstances. I now prefer the Kanban-style approach where there's a backlog of modestly sized units of work and the team has a limit of the number of things that can be in progress at once (my starting point is half of the number of team members). You then release each thing as it's done.
[1] E.g., https://williampietri.com/writing/2011/agiles-second-chasm-a...
> So don't use them as an intermediate unit. If you want hours, just ask for estimates in hours
But then you aren't doing Agile!
The whole thing is just stupid terminology for existing things and distils down to "make a todo list and work through it"
That may be what you have experienced it as, but that is not what it is. There are more things, Horatio.
What would be a more data-driven software development process, that’s backed by scientific evidence and is statistically proven?
A shared todo list.
I thought agile was an elaborate scheme divised by energy vampires to drain the enthusiasm of developers through the use of rituals.
That's scrum. Scrum uses agile but agile is not scrum.
Your comment strikes me as a bit odd, let me explain why.
Yes you're correct in saying that op was talking about scrum not agile, but "scrum uses agile" is a very confusing phrase. Scrum predates agile by 8 years, so how could it use something that wasn't invented when i was created. Also agile isn't something "to use" since it's not a framework. Scrum is something that you use, since it is an actual framework, and often people who implement agile use Scrum, because scrum was very much in the minds of the creators of the agile manifesto. And this should not surprise anyone as the creators of scrum where also part of the group that created the agile manifesto.
Damn, didn't even know Agile and Scrum had such deep lore.
Agile is not a noun. You develop with agility. Your team is agile.
The largest problem with so many of these discussions is that people talking about them have pinned themselves to the noun of capital "A" Agile instead of recalling that the point is to curate and practice an empirical process instead of a defined process like in manufacturing.
Scrum became one of the more popular process tool kits because it was a lot simpler to use than the entirety of eXtreme Programming (for example). Later a lot of consultant artifacts got piled on including a mishmash of other practices like Kanban, planning poker... etc. You won't find any of those in the original book on Scrum.
The point was always frequent course examination and correction. Ken Schwaber, author of the Scrum book, was also one of the original signatories to the manifesto: https://agilemanifesto.org/
I think of scrum as a way to get work done under little to no established trust between leadership and ICs.
Isn’t that what the name supposed to evoke? Two groups locked in a push in opposite directions.
It's about both, it's just that ritualized Big-A Agile isn't about either. It's about the appearance of speed and selling certifications to companies and management that don't know better.
I think "velocity" (from Scrum) actually evoked the correct idea, but most people seem to forget that velocity != speed. Velocity is a pair, speed and direction. Raw speed is useless if you're heading the wrong way (e.g., towards a solution for the wrong problem because you didn't bother validating along the way).
But if you can adjust the direction fast enough, you can quickly recover from the wrong direction. That is, it's about speed of adjusting, not just speed. (In sports, it's the difference between speed and quickness.)
Only if you adjust into the right direction, and keep it after the adjustment.
Theoretically, scrum was aimed at adjusting faster. But if the adjustments just keep coming, you won't go anywhere.
If the adjustments just keep coming you have a business problem and no "process" will save you.
Where I currently work it's absolutely a process problem (of Scrum). The version of scrum they're running wants you to just get the committed stuff done, and it's irrelevant what it leads to. There is no room for understanding the end goal and making sure you reach it, with a set deadline as well.
You might as always happens attack them for not doing Scrum right, and I'll tell you that's the age-old cry of the agile-folks: you're not doing it right, and nobody ever was.
Fuck scrum, it's not agile, never was and never will be.
What prevents the committed stuff from going in the right direction? Is it that the business leaders keep changing the direction or that the from the business leaders direction is unclear? Or something lower-level? I was picturing the former in the above convo.
Scrum. It has nothing built-in for reflection and planning. It assumes you magically know everything already and can build and demonstrate progress towards the goal at the end of the sprint.
Adding any action to check if you are on the right track helps. Scrum doesn't have any, it assumes the development is subservient to the PO, and the PO is that flawless being that does everything perfectly, even when nobody tells him he has to do it. It also and adds a lot of confusing tasks that distract the PO from this one main goal.
Thus, the odds of a team knowing where they are going reduces drastically if they start doing scrum.
But equally you don't burn on for months in the wrong direction
Your semi-annual reminder that the promulgators of XP/Agile all came from the Chrysler Comprehensive Compensation System which failed miserably: https://en.wikipedia.org/wiki/Chrysler_Comprehensive_Compens...
Beck, Jeffries, Fowler, Hendrickson, and Wells are examples of Failing Upward(tm) rather than any example of good programming to be emulated.
This quote summarises everything that is wrong with Agile.
>> rarely well implemented.
The Agile Manifesto was published in 2001, over two decades ago. After all this time, and the involvement of a lot of clever people, even Agile advocates are stating it is rarely well implemented. Doesn't that suggest that Agile, as a management technique, has failed?
True Agile is appears to be as elusive as the holy grail.
Well, who is in the position to change an Agile process in any company? If we have 20 years of using this system, we should have enough feedback from developers and the business to refine what Agile is. I can tell you very few developers have input on the overall process in most places.
It's not evolving into a better system because it's under the new bureaucratic regime of project managers. They are an institution now within the tech industry and are a self preserving entity. It's idiosyncratic for them to change this bureaucracy.
If a developer were to say, "here is what I think about the process that governs me", the governors will laugh you out of the room with a delicate smile and sweet fuck you along the lines of "woah, that's great feedback!".
Isn’t agile just like 5 sentences that are pretty vague? If so what does it mean that it’s badly implemented? That sounds like the “they are not interpreting the bible correctly” type of argument.
I think it was Ward Cunningham who discussed that on a video. People in his group would interpret with nuances and good sense. But the thing became a fad and enterprise world turned it into an accounting exercise.
It’s actually about getting management out of the way of letting engineers do their jobs.
There has never been a better strategy for letting engineers steer the ship and make decisions that ship code instead of getting micromanaged by non-experts that generally bungle things up and insert a bunch of external priorities without reconciling them with reality.
The reality in my mind is that agile is the reaction to excess management, which is a massive problem in technology organizations.
I’m sure there are other things too. Some of the other comments are gold. But that’s my 2c.
Nobody seriously measures "speed" in terms of how many words you type per minute.
HN is pretty much in agreement that lines of code per day is a bad measurement of progress/accomplishment, right?
We've seen so many bad variations on this concept:
* Butts in seats means work is being done
* Movement is progress
etc. It's all bunk, of course, and here we are with agile. Corporate types are collecting some metric and the larger the value the higher the developer speed. Or so they think.
Ideally, "speed" in this context is about direction. They are almost interchangeable. If you are going in the right direction, you have some amount of positive speed. Otherwise, it is negative or zero.
No, compasses are about direction.
Next.
Seriously, there's very little substance to the article. It effectively says "agile doesn't work without customers."
I'm pretty sure "customer collaboration" mattered back when it was a developer movement and not some kind of training sold to management.
Anyone remember this? https://agilemanifesto.org/
It's about speed of changing direction.
Duh.
The entire supposed premise of agile is defining goals and constructing a product iteratively, so misunderstandings and changes in design can happen more quickly.
The "quick" part being a change in direction.
Given a perfect definition of a program and skilled ciders and unified vision from the beginning, agile would be meaningless.
For me, Agile is about risk migitation by early knowledge building.
That could apply to waterfall also. You build all specifications and understanding up front, then you implement it to the specification.
My opposition to waterfall is that building understanding through investigation and specifications is inferior as a way to get the finished product you need in the time you want, generally much inferior than building understanding through implementation.
But I've always seen that somewhat orthogonal to team-level processes.
You can "Agile™" or "Scrum™" the shit out of waterfall, after all. Create a ton of tickets for spec writing, etc.
The whole point of Scrum, in my opinion, is to create a working increment in the sprint. That’s the mechanism for managing risk. Finishing tickets for writing specs don’t achieve that. Unfortunately, it’s a common practice though.
Yeah, having running software forces you to prove a certain level of correctness and lets people test against it.
You can call a spec done arbitrarily and it's much harder to test that spec against any number of edge cases; and harder to visibly inspect "do these two specs get along" than "did this API call to this other place succeed?" "It doesn't compile" or "it throws an error" or "it doesn't do what it should" are all much more concrete and force you to confront "we might not understand the problem as well as we thought."
Well it’s both imo - i.e., agile is about velocity.
Any good process should care about both the vector and the magnitude.
The saddest state of affairs, and most common, is when highly capable people have a high magnitude with an incorrect (or inconsistent) vector, leading them nowhere.
Was the article created by a bot?
You are holding it wrong.
Give a break Agile is just an adjective. It's the antonym of clumsy/ungraceful.
Yes, an Apple is just a fruit. But a fruit didn't create the iPhone. So perhaps when people talk about Apples upcoming phone, they probably mean the company not the fruit. And when people talk about Agile in relation to software development they likely mean to refer to Agile software development not just the word agile.
Apple has a very clear brand whereas the agile practices are convoluted and meaningless
or its lack thereof
Right. I mean half the pitch of the ol manifesto was "don't plan on finishing software because it's impossible to actually get requirements out of a customer ahead of time"
And it was sold as a good thing.
Well, if that's the world you actually live in, then you'd better be able to live in that world. (I mean, sure, ideally one should fix it. But your development approach has to work in the world you're trying to apply it in.)
Can we just be done with “agile”? As far as I can tell it’s like communism. Seems to make sense on paper. Every time teams try and follow it things fall apart, and the crowd points and says they just weren’t doing it right.
How about we just get the requirements and write the code, however that is best achieved in your org.