Agile isn’t about speed, it’s about direction(tim.mcnamara.nz) |
Agile isn’t about speed, it’s about direction(tim.mcnamara.nz) |
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 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...
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.
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?
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.
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.
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.
Isn’t that what the name supposed to evoke? Two groups locked in a push in opposite directions.
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).
Theoretically, scrum was aimed at adjusting faster. But if the adjustments just keep coming, you won't go anywhere.
Beck, Jeffries, Fowler, Hendrickson, and Wells are examples of Failing Upward(tm) rather than any example of good programming to be emulated.
>> 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.
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!".
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.
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.
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.
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.
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 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.
And it was sold as a good thing.
How about we just get the requirements and write the code, however that is best achieved in your org.
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.
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.
You don't need to do any other process. You can just talk to people as problems arise and do that "in stead".
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?
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.
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/
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."
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.
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?
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.
I'm new to this. Are we agile?
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"
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.
Thus, the odds of a team knowing where they are going reduces drastically if they start doing scrum.
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...