Agile is people, the rest is commentary
buttondown.email
buttondown.email
> I don’t think anyone could object to a ban on the word when it is used as a noun. That’s just plain wrong. “Do Agile Right” and “Agile for Dummies” are just two of the innumerable attacks on the English language featuring the word. They are meaningless. Agile is not a noun, it’s an adjective, and it must qualify something else. “Do Agile Right” is like saying “Do Orange Right.”
> But, beyond the grammar problem, there’s a bigger issue. Once the Manifesto became popular, the word agile became a magnet for anyone with points to espouse, hours to bill, or products to sell. It became a marketing term, coopted to improve sales in the same way that words such as eco and natural are. A word that is abused in this way becomes useless—it stops having meaning as it transitions into a brand.
...
> Let’s develop with agility
> You aren’t an agile programmer—you’re a programmer who programs with agility.
> You don’t work on an agile team—your team exhibits agility.
> You don’t use agile tools—you use tools that enhance your agility.
https://pragdave.me/thoughts/active/2014-03-04-time-to-kill-...
The word has been stolen by the worst charlatans who are enriching themselves on the back of our industry.
Like, in big projects I would like one QA for every 5 programmers to keep us from building backwards.
Scrum et all offer what looks like systematic answers to these understandable concerns.
So you end up spinning up a dozen different manual reports at different granularity levels that take all Friday afternoon to do.. mostly in excel/outlook, and.. so again its just manual grind work and qualitative fluff.
I am still very pissed that the job of an SWE has become this pastiche of different business fucks telling me how to make stuff and hectoring me with random JIRA bullshit.
Tell me what you want, put me in touch with my stakeholders, give me a POC for progress updates, and stand the hell back.
LEAN seems to be about as close as we can get. Otherwise, to this antisocial developer that just wants to be left alone, agile sucks.
We have some scrum-type rituals. Primarily stand-ups (15 mins teams call to sync and have stakeholders listen in if they want) and the occasional retro, although it's not a typical retro with a format. They're basically a full team meeting when things aren't going smoothly or something else happens that everyone needs to be aware of ('sudden' crisis at the customer, which they have a lot) and use round tables to make sure everyone is heard. Most other things are handled in smaller groups of relevant people.
We have a backlog in Jira to keep track of what we want to do and in which order. We pick up work kanban style. The current team is 13 people, so it also gives an overview of what's going on where. There's no formal format for writing things down, but over time we've learned to add quite a bit of context, especially for nice to have stuff we don't pick up straight away.
The reason this works is that we hire people who can deal with the freedom and responsibility. We put a lot of trust in them from day one, while coaching them using all kinds of formal and informal systems.
Form tiny independent teams capable of designing and shipping features. Assign them features and have them design and ship within 6 weeks. If they can’t fit in that time, drop the feature.
The tiny teams (2-3 people) have near full decision power on all details.
The stakeholders bid on features every cycle.
No micromanagement, no running tasks through a shredder and reassembling them. Trusted teams building the product.
Companies adopting shapeup say it’s a breath of fresh air.
I work in a company/team that has this, and while we use Jira[0], it's effectively there to remember what we need to do for a given task/bug and ensure that two people don't work on the same thing. The use of Epics lets management & stakeholders see what is happening with a given feature without bugging us.
We don't have estimations, retros, or any of the other usual rituals, and it's amazing. If there's a mismatch of expectations or we need to hash something out there's Slack and Zoom. Someone volunteers to write up a card, and we're done.
The corollary is that we've had a couple of hires come and go who just did not have the skills and/or interest in being part of those conversations, and they did not last. I'm in two minds if this is the damage inflicted on them by years of managerial Taylorism, or that they just could not keep up with the rest of the team. I expect (but hope to be wrong) that once we expand enough to have actual juniors we might have to embrace some of the more ritual parts of agile.
[0] We use Jira in Kanban mode with a couple of text templates for the different card types (epic, story, bug), and none of the usual rules about what can be moved in and out of what column.
EDIT: complete->couple
Kanban, which is an agile method. It contains the good parts from Scrum, without the pointless ceremony. Just take the most important story off the list, do it, then repeat until done. Feel free to adjust priorities of not started stories.
JIRA and the like can be useful tools to track what work is done. However the value isn't to engineers, it is to management on a large project. Keep that mindset in mind, on a large project management is hard.
Oh wrong discussion. But it fits anyway. Just don't give managment the ability to micromanage you in an automated and machine like way and there is no risk of misuse of that power happening. Manual micromanagement is hard work you know.
How many people do you think have fallen into this trap?
It seems that every single company out there are trying agile, and almost all of them are doing it wrong. I have yet to be part of an organization that does agile right, or at least the way it was promised to us from the beginning.
Perhaps the whole idea is just another utopia that will never reach its full potential.
The actual problem with agile, as I’ve seen first hand, is that teams adopt Scrum as if it’s some Agile Silver Bullet. If you just do what you’re told by the CSM, then projects will go better. This is especially true when there is a power imbalance, developer problems are swept under the carpet, and retros are discouraged or non existent.
It’s nonsense. Like all practices, there are all sorts of problems intrinsic to Scrum that need to be considered carefully and resolved.
How do you manage a large backlog?
How do you deal with unexpected complexity discovered at the very start of a sprint?
Where are the overall project goals documented - and how do we measure against them?
This is not to say that these problems can’t be dealt with in scrum. The Agile Manifesto leaves plenty of room for resolving them, but Scrum is being taught by many as the One True Way, and if you dare suggest changes or deficiencies in the process then you just Don’t Get It.
It’s the rigidity of these practices that has become the problem - the way I’ve seen Scrum implemented in several large projects is effectively waterfall with a scrum veneer.
When you’ve been shipping software for more than the length of your adult life, it gets tiresome to have someone with a dodgy certification in agile project management explain how to ship.
The reality is that well-tuned processes can reduce cognitive load in day-to-day work, freeing up mental cycles for higher level problems. But process also adds overhead and rigidity, so it needs to be tuned to the environment at hand and reevaluated regularly. This can't be done be done by a drive-by consultant or a detached manager, it requires boots on the ground context and applied expertise to relate the day-to-day reality to the highest order business goals. Anything short of that is MBAs and juniors clinging to an arbitrary process as justification for why they are delivering adequate, but not exceptional results.
Period.
From a business perspective, Agile means some suits can look at a dashboard and see, with a granularity of one sprint at the coarsest, whether the project is proceeding on schedule, who completed what, which individuals and teams are ahead and which are stragglers. Information they need in order to make budget, risk, and resource (read: hiring and especially firing) decisions. That's how the consultants pitched it because that's what executives want to hear. They read about Agile in CIO magazine, its promise of quick turnaround times, and its need for communication between the developers and business experts, and their takeaway is that it's an efficient micromanagement strategy, a panopticon that will help derisk persnickety programmers by having them under constant observation and forcing them to provide constant feedback.
Unfortunately even in healthy orgs where leadership concerns itself with results and appropriately delegates process and execution to experts that understand how the sausage is made, you still find a lot of lower level managers or even ICs who embrace the ceremony and rote process of Agile as a substitute for really reflecting on the quality of the team's output at a higher level and over longer spans of time.
It's enough for the executives that the information is gathered and the audit trail established. Honestly, getting an auditable log of the developers' thought process is such a wet dream for management at software shops that companies will use any excuse to become a dystopian hellscape in pursuit of it. One such company used the following rubric: Compliance with the Sarbanes-Oxley act requires full auditability of anything that may affect the company's stock price, including the software's source code and any changes made thereto. Therefore, all developers must make a log in the bug tracker of what they're doing every 15 minutes to ensure an audit trail of developer activity.
Agile just happens to be the excuse that gained traction, because it's easy to dress up as something that's good for developers and it's not as ridiculously onerous as the above.
In many companies it seems that people get promoted due to political skill rather than management skill. And micromanagers often appear competent because they can report on exactly why a project failed… leaving out the bit that they strangled it to death while nobody was looking.
Not that I’m bitter or anything.
I honestly don't blame them for trying to industrialise software production, I blame the engineers which is probably the only white collar profession that don't care about being in control of their own field narrative
We didn't allocate more architectural tasks to seniors, or pair them with juniors, or give them long running slices of work across sprints.. we just were like "more points please".
We ended up with under-engaged seniors all leaving, and juniors being given tasks they couldn't accomplish.
The terms "junior", "senior", etc make it appear as if the latter is just an older version of the former, but the correlation between work experience and actual skill is far from 100% in my experience.
The idea that everyone gets a vote on story points & planning meetings in a conference room for hours&hours, while democratic, is counterproductive.
Further, as it turns out, the dev who has done the thing 2-3 times before knows all the mistakes not to make, and move onto make new & unique mistakes (joking, sometimes) whereas the junior gets to make all the mistakes all over again.
The senior is always going to give a higher effort estimate, but will generally be able to accomplish the task within that estimate more often.
A junior has no ideas what they don't know, and can often be off by orders of magnitude on their estimates. Usually because they consider only what is required for the "happy path" of the code to work as expected when used as expected, with no bad data/etc. Further they will include the time it takes them to get the first cut of the code working on their box, undocumented, uncommented, not in git, not tested, and not ready for release.
Of course, the fact that programmers don't actually work that way is something these corporations' management didn't get the memo on...
No.
Because programmer jobs have a knowledge and creativity bottleneck, that is the hard part to scale, and require workers that have autonomy, can take initiative, and can put together a solution from known part in ways that create solutions for one off problems.
Metaphorically speaking they are not tightening the same bolt type over and over again to the same spec every time. Software is not manufactured, it's largely artisanal.
It is again one of the problems with scrum. There is pressure to complete a feature in a given sprint - and a sense of failure if you don’t.
The problem is not processes like Scrum, it's the fact that many of the people who are in roles that are ostensibly responsible for "fret[ting] over higher order problems" actually don't care about that.
They get paid regardless of how productive everyone else is, and in my experience they get paid more if they implement "best practices"... which are practices designed by marketing teams to sell CSM courses.
But Scrum's approach to this is overly simplistic (product owners?), backlog reprioritisation is not part of Scrum, and in any case you really ought to have some control over priorities because doing certain stories in the wrong order will reduce productivity.
The problem that I'm pointing out is that Scrum has become synonymous with Agile in many quarters, and yet it is far from a complete solution to software project management. It's not that Scrum is no good, it's that it's not enough (or, in some cases, too much).
When I've been forced to use some BigCo's rigid version of "Scrum", it's always been a nightmare. Of course it was, because rigid is the opposite of agile.
This is why we keep seeing those "no true scotsman argument" against any real world attempt to "be agile" where no failure can ever be seen as an argument against the usefulness of "The Agile Manifesto", and it's not really a new or surprising process but something that happens to most movements created around a loose manifesto.
What will change things for the better is pragmatism based on observations and currently thats not the way the Agile movement seems to be moving.
So I strongly reject your implication that it's not really possible to get it right and that all the consistent failures are true-scotsmanned away. Being agile is awesome, and it is not actually hard, with the right people and mindset.
I also don't agree that the manifesto is as loose as you appear to think, as almost all the places where Agile falls down can be shown to be in contradiction to the manifesto. (Looking at you, Scrum, and you, Jira, etc.) However, it is fairly loose where many people would like it to be tight, that is in prescribing certain fixed processes.
For example, nowhere in the manifesto does it say you should have lots of meetings and you should stand during those meetings, but for some reason that is one of the key takeaways people seem to have from Agile. The standups actually come from XP (which is sadly mostly ignored, though it contains most of the real gems), and are not even mandated. The key idea is to eliminate meetings altogether, and to keep the ones that the team finds unavoidable as short as possible by making them somewhat uncomfortable.
And those with the "wrong" mindset -- i.e. who can't seem to force themselves to mouth all the nonsense and claptrap behind the Agile cult -- are just a bunch of uncooperative dolts, who you wouldn't want on your team anyway.
The teams that were agile didn't do any of that crap, never mind mouth it. We were busy getting stuff done.
In fact, in one instance we had two of these teams right next to each other. The one that did all the claptrap of The Agile Cult™ right, the standups and whathaveyounot, and got cancelled, because they couldn't deliver (the software was still needed so the effort was rebooted).
The other did no standups, no biweekly sprints, no retrospectives, no planning game, no story points, no epics or whatever. But we did do the technical practices such as TDD, YAGNI, DTSTTCPW etc. And we accomplished something that people, including many on the team, did not consider possible. And with a team that of people that were mostly not considered very good.
And one of the best teams actually predated the Agile Manifesto by quite a number of years, and even XP was only publicised afterwards. When XP came out, there was a lot of recognition, a lot of what we were doing was XP. And there were definitely things we were doing differently, because our situations were not the same.
But by this stage, that's all beside the point. The "[Aa]gile" meme/cult has become radioactive. I'm personally done with it, and would greatly prefer never having to hear about it ever again.
The claptrap and nonsense is the stuff that was added later, as Agile or as we call it Fauxgile. If you look at it in detail, you will notice that it pretty much invariably violates most of the actual agile principles in the manifesto: they set up plans (epics etc.) to be followed in tools (Jira) following rigid processes (Scrum) enforced by "masters" (really?!) with an entire industry behind them.
Now all of that seems completely farcical, so bad that one almost has to assume cynical motives. But when you go into these teams, it at least looks like they're being very earnest and honest in their efforts, even if they're consistently, insistently, doing the opposite of being agile. Teams/orgs will actively resist and route around efforts to help them become more agile, again while honestly (or at least it seems so) professing their desire to become more agile.
One example was the org that had a regularly scheduled weekly pre-meeting to the regularly scheduled weekly meeting on "how can we reduce process in our org". <raises hands> Ummm...I might have an idea.
Another was an org that was following the highly dysfunctional but extremely common process for mobile development: product managers think of new feature, spec it out, hand it to design, design does screens and then throws them over to engineering.
Raise your hands if you're in mobile development and this sounds familiar.
There's so much wrong with this that I don't really know where to start, but one thing it certainly isn't is "agile". Yet they were very sure they were "doing Agile™". I tried to suggest that in order to get feedback loops going, it might be better to involve development a little earlier.
They thought that was a great idea and instituted a new meeting involving design/engineering/product mgt. before the handoff to design.
Khaaaaaaaaaaaaaaaan!!. I mean aaaaaaaaaarrrrrrrrgggggghhh.
The Gitlab CEO Sid Sijbrandij has also written about this. A lot. Though under the label of "iteration" rather than "agile". These are largely identical. To him, good iteration is possibly the most powerful development technique, but he also writes that it is hard. That is where I think the people difference that I mentioned earlier comes in: for some people this is both extremely useful and also natural and easy. For the other group, the techniques are just as valuable (the reasons why they're valuable are not people-dependent), but don't appear to come naturally.
My guess is that most of the signatories of the AM belong to the former group, and so they thought that all that needed to be done was to free people from the shackles of their dysfunctional processes and all would be good. That appears to have been naive, these waterfall-ish style processes seem to be very attractive and comfortable to a lot of people, while being no less dysfunctional.
And so the coaches/scrum-masters etc. stepped in. And gave their customers what they wanted: a prescriptive "process" for achieving Agile. And since their customers were managers, they focused on management ceremonies, hence Scrum. Which IMHO is not just useless, but actively harmful.
The problem is that by now more people have failed at agile then succeeded and instead of going back and modifying or challenging the universality of agile they way it happened with waterfall, people keep doubling down on the universality of "The Agile Manifesto" by discounting any failure as "no true agile".
Not really. Waterfall was never a serious process.
> one success story
It's not "one" success story, but an extremely consistent pattern.
> any failure as "no true agile".
Again not so. If you're burning down Epics specified in Jira from your one year plan while doing daily standup status meetings, but not following any of the technical practices, you simply really aren't being agile at all.
And that seems to be the vast majority.
The technical practices are the meat, and the heart of the matter. Most of the rest is Fauxgile and somewhere between worthless and harmful.
It kind of seems like the manifesto points out that the best way to create software is to get the right people and don't disturb them. And, if fact, if I try to think of examples of good software, this is usually how it came about, doesn't it? A small, talented, motivated group of people just working passionately on a problem.
Obviously, though, this does not scale at all.
> What if you’re working with a major language barrier in the team, and misunderstandings can be mitigated with processes?
Process is communication. It's a way of doing mass communication. Instead of explicitly communicating everything to everyone, a process is way of saying "when X happens, you can assume Y".
For example, if a card is in the Done column, you can assume the code is in version control, deployed to production and checked to make sure it didn't explode on impact.
Then, instead of explicitly communicating every single deployment, you only need to communicate the exceptions. (ie; the things that don't fit neatly into an existing process)
If you're working in a team that has a major language barrier, I don't see how having a process can mitigate the need to explain that process, nor how the exceptions can be communicated effectively.
I guess you've never seen a team argue over "Definition of Done" for months.
Unfortunately, I have had that conversation plenty of times. The point is to have that conversation/argument once, make a decision on what it means for the team, and then move on.
People would say it is flexible and meant to be guidelines that can be changed to fit your team. And then we would go and do a bunch of training, hire scrum masters, etc that would all tell us we were doing "Agile" wrong. Those 2 statements don't work together.
I also cannot understand how we convinced companies that hiring full time agile coaches, scrum masters, etc were at all not a waste of money.
I also felt like we had way too many meetings with very little value. Meetings that were really just focused on the process. I know some people think that meetings are being productive but I strongly do not feel that way. Obviously there are some valuable meetings, but most of the agile ones I felt were a waste of time.
There are pieces of Agile that have continued, like standup, but largely I have not been "agile" for several years and I feel like I am more productive because of it.
They sure don't. But they work another way. By getting people to go along with patently contradictory belief systems (or glaring conflicts between what it said and what actually happens in reality), so as to break down psychological barriers, and make them more pliant to authority generally. As with any functioning cult operation.
I also felt like we had way too many meetings with very little value.
Well yeah, but only in the superficial sense related to, you know, the company's business and the actual work to be done.
But in terms of their true purpose: keeping the Agile cult running, and helping legions of undertalented managers keep their jobs (along with the SCMs they inevitably hire in place of actual engineering or management talent) -- these meetings are beautifully effective, indeed.
I also enjoy the 2010 version: https://www.halfarsedagilemanifesto.org/ .
I made a more accessible version of it a couple of years ago.
It takes 6 months to act on customer feedback with our current release strategy, and a full year to fix the bugs related to that feedback. We should be rapidly iterating on feedback quickly to avoid churn. Let's try xyz...
That's even simpler, and you can even keep waterfalling and still benefit from shorter iterations.