Agile Manifesto co-author blasts failure rates report, talks up 'reimagining' project The Agile Manifesto was published almost a quarter of a century ago. Yet as the years have rolled by, its lofty ideals have run headlong into the brick wall of management desire for process and reporting. Jon Kern, one of the authors of the Agile Manifesto, calls this the "Agile Industrial Complex." The proliferation of …
I tend to go further than that, agile (with a small a) is a toolbox of techniques that you can use to make sure you are delivering value quickly and sustainably. I include all of the tools from Lean, XP and more in the agile toolbox. You iterate on your process until you have a combination of techniques that work for your particular team
Yes. It's necessary to find a set of practices that work for the team and the projects they work on.
My primary team has been agile and notionally using Scrum since 2008. What that really means is the team subscribes to an agile philosophy: put useful stuff in each release, release relatively often (our cadence is monthly, more or less), don't get lost in process. It certainly hasn't meant slavishly following practices that don't work for us, or skipping requirements or design or testing or documentation or planning. It does mean that we know the team velocity with decent accuracy, and we've gotten pretty good at breaking work into small pieces and sizing them accurately, and we can figure out which features and fixes are viable for a given release and which will take longer, so stakeholders have some idea of when they can expect something.
It does require having managers that are capable of working this way, too.
And this is with large, enterprise software products that combine the output of dozens of teams and need to actually work correctly.
As Headley himself hasn't responded, I'll offer (from distant & unreliable memory, which in this age of instant information I should check, but where's the fun in that) that Headley Grange is a large country house rented by several bands in the 70s for rehearsals & recording with one of the two ubiquitous mobile studios of the day (Rolling Stones or Ronnie Lane's).
Led Zeppelin & Bad Company both used it.
Don't understand the down vote, I see this all the time. All. The. Time. I am regularly asked to provide a fixed price quote for a fixed outcome and a fixed timeline using an 'agile' approach. And I make the same point - you can't do that. Sure I can quote you for 'n' iterations with 'x' resources, but by definition there's no certainty of what you'll end up with within that arbitrary cost/time frame.
- It will use "agile" methodologies
- Budget is pre-defined
- Scope is pre-defined
- Deadlines are pre-defined
-----------------------------------------------
That, right there, is EVERY formal RFT process that has ever existed.
The customer has a specific job to do, gets a (fixed) budget allocation from 'higher up' to do it, and has several absolute requirements that define what 'done' looks like.
The customer gets some external companies in to quote, in the hope of choosing one that will actually result in a successful project.
The developers arrive, and waffle on about Agile, and Frameworks, and Methodologies.
The *clever* developers give a knowing wink to the actual techies in the room. They know it's all rubbish. They know that YOU know it's all nonsense. But right now there's a contract to be won, so they're playing the game.
Agile? It's a meaningless buzzword. Nothing more.
The real world has fixed budgets, solid due-dates, and very specific requirements.
If you're lucky, very very lucky, the 'internal resources' (ie: staff) will actually get enough 'spare time' from the daily grind to be of assistance.
You missed one crucial thing.
The developers arrive to win the project. When they win they are then told themselves what resources they have. Their employer want to spend no more than 75% of the budget on actually getting it done, leaving the 25% as profit to fund their Porsches.
Then when the shit hits the fan, the 75% of money is running out and the project is nowhere near complete, fingers are pointed at the person on the developer's side who specced the project out. Not at the managers giving the resource restrictions.
Agree 100%.
The root cause is that the "project mindset" never left the Finance Dept. In order to get a "project" approved you need a business case. The business case needs to guess at what it will cost and guess at what benefits will bring, then you subtract Guess A from Guess B to derive Guess C, the mythical Return, which you then decide again by Guess B to derive the all important Guess D, the ROI. You then line up all the projects in mythical guess D ROI order and do as many of them as your budget allows.
But in order to start this guess cascade you need to know what it will cost... And to do that you need to know how many people (Guess E) for how long (Guess F) plus whatever stuff you need eg infrastructure (Guess G) so you can add them up to derive Guess A.
And now amount of Agile or agile handwaving will ever change this...
The developers arrive, and waffle on about Agile, and Frameworks, and Methodologies.
Wrong, so far all the agile projects I've been involved with over the last 15 years it has been the BA's that do the waffling as agile means they don't need to do any work. All you get from the BA's is "Hey developers we need some code and here is a vague idea of what it is meant to do"!
I was on a project as a Test Analyst some years ago.
At one of the meetings, I pointed out a bunch of bugs, traceable to some common code and suggested that we include testing that in the plans (which i was willing to write)
Scrum master (so-called!) says "We haven't got provision for that in the Scope"
Me: "But we're Agile so could include it"
SM: "We're not THAT Agile!"
Needless to say, 3 months later SM was bitching about missed deadlines, slow progress blah, blah.
It looks like a test question... Or a question to weed out the drive-by candidates.
It could have been a great opportunity to have had a conversation with the "powers that be" -- if for no other reason than to cement your decision that this is a lousy opportunity.
Or to see if there was any chance that the box that the project was in was doable. And where were the biggest concerns in the constraints?
And did the company have a great attitude and were they nice folks who could learn how to control the "gas and the brakes" for a product development process?
Anyway, the optimist in me could make this opportunity work out if it was mildly reasonable in a few other attributes.
Or they may have been fabulously delusional. So "moving along" was the right call...
There will come a time when one will accept those jobs because it pays the bills and one needs to pay the bills - or else. A skill for when that time comes, is learning to interpret / lawyer the requirements into something that better match time and ressources. Another skill is separating concerns into "things I can do something about, me-problems, and things i cannot do anything about, you-problems".
Silly project going tits-up -> that's a "you-problem".
The golden rule of agile is that you should look at everything your engineers are doing that isnt actual software development and ask 'Is this adding value?'
Generally the answer is no. We have an industry of very well paid engineers, and we waste their time with reports and ceremonies.
Im a middle manager at a large fintech, and I trust my engineers. Give them a steer on what you want, hold informal checkins on a semi-regular basis, and then get out of the way.
And as for reporting upwards, I can, at any point, tell my boss a) What are my team working on right now and b) what is the current intention for them to work on next.
And thats all you need.
...look at everything your engineers are doing that isnt actual software development and ask 'Is this adding value?'
The problem here is that the the 'amount of value' is tainted by who is looking and the blind and short-sighted are generally the ones distributing the money. Some may say that the coffee-room is important whereas others will see it as a distraction and an expense.
The real problem with (good) software engineering is that it is as much an art as a skill. How do you determine that the produce of the artist(s) is actually skilled art?
Anyhow, it is certain that the amount of (strict) process is reciprocal to creativity and the expression of art you need in the software trade.
+1 for the art reference. I've always believed that software engineering is actually art - there isn't one set of books that say "do it like this and you'll be golden" (like in say, building architecture). Collectively, software books / practices are basically telling us the answer to "how should I do this?" is "it depends"
Civil engineering explicitly involves art history.
And there are mathematical metrics for software quality.
Programming is really a specific form of poetry, but it's a mistake to think that architecture isn't fine art first and foremost.
So much this.
In one place I worked, the top management were sold on the belief that you implemented all Agile framework [X]'s principles from A..Z and the world was suddenly a wonderful place.
When, for example, I queried the need for a team of 6 engineers *who sat right next to each other* to stand up for 15 minutes every morning to tell each other what they were working on (which often ended up as 45 minutes of two of them debating some technical issue while the others twiddled their thumbs), I was all-but denounced as a heretic.
The team should be shutting those conversations down and request they are taken out of the standup--Not everyone in the standup needs to be a part of those. The point of standing up is to make it "uncomfortable" for people to talk for a long time. Some teams even go into planks during standups to make it even more uncomfortable.
Standups are to touch base with everyone, tell them what you're going to do so they're in the loop, raise any blockers, tell everyone you feel like shit you your output be fucked for the day.
a stand-up also provides visibility to anyone that cares - the C-level management, project managers (eugh), whoever is interested, can drop in on a stand-up and be amazed at how well the team works together (done right). It's not uncommon for the next thing the team, or smaller cohesive groups, end up doing is to scribble on whiteboards to evolve a design or create a prototype
Personally, if somebody tells me to stand up for a meeting, I sit down and tell them I have a bad back and will be happy to discuss the matter at an employment tribunal.
Stand ups are nothing more a complete and utter waste of everybody's time. You get everybody to stand around and say that they are working on the same thing that they were working on yesterday (and probably will be for the next two weeks). And then you get a bunch of inexperienced pillocks sticking their oars in, asking stupid questions and trying to tell you how to solve certain problems even though they are manifestly unqualified to do so. And then you have to explain to them why their ideas are stupid and that they need to shut up and pay more attention to their own work.
... a team of 6 engineers *who sat right next to each other* to stand up for 15 minutes every morning to tell each other what they were working on (which often ended up as 45 minutes of two of them debating some technical issue while the others twiddled their thumbs),
Almost and exact word picture (down to the numbers) of actually witnessed for several months as a bystander. Scary.
I have too much respect for the profession of actual engineering to lump them in with the duffers who cobble code together. Software engineering is too much of a breach of the Trade Descriptions Act to qualify as an oxymoron.
I was all-but denounced as a heretic.
It's fortunate that you weighed a bit more than a duck as heresiarchs frequently get the same treatment. :)
Software engineering is too much of a breach of the Trade Descriptions Act to qualify as an oxymoron.
As an actual trained Software Engineer that has worked for engineering companies along side electrical and hardware engineers you have a point. I have also worked in other non engineering companies where they claim to employee software engineers... No f'ing idea!
not sure what either of you are going on about, except making it out like your know all gods.
Personnally
I've met "engineers" who couldn't engineer a paper bag.
I met trained "software engineers" who are fuckwit know nothings, but to a "manager" they sound impressive.
And loads of people with degrees in allsorts, that I had no idea how the hell they managed to do anything to keep themselves alive, nevermind do anything worthy of being paid, earning stupid money.
The main thing that they all have in common is they can spew bullshit fluently with utter confidence with no embarressment
"And that's all you need"
When you have good engineers, yes. But many projects don't.
I have been in agile environments where a just couple of us could work wonders.
I have been in others where the full management book was the only way to keep a bunch of incompetent communicators with big egos in line. They could not understand why we didn't like their anal sunshine, and were incapable of explaining why they thought we should. Sacking them and getting in a couple of smart developers would have been the cheapest, fastest and best-quality solution but was not in the contract.
And of course, shedloads somewhere in between.
"And thats all you need.".
No.
Because the people paying for this quite reasonably (from their point of view) want to know "How much will this cost?" and "when can I have it?".
Agile hedges these questions with a load of whalesong that does not address the underlying business requirements. Which are, to deliver stuff to paying customers (software, access to SAAS, features) in a predictable way. The customer will stop asking you for things if you never stick to a deadline. So your business goes bust.
... because they want to know how much it will cost, and when they can have it, without telling (or knowing, or caring about) dependencies the programmer has to factor into their estimate. Example:
Mgr. How long will it take you to get our web portal built and running?
Prg. Fuck if I know.
Mgr. C'mon, at least give me an estimate.
Prg. Hmm .. five ... no, ten years.
Mgr. That's outrageous! How can you give an estimate like that?!
Prg. It's because everything depends. How many brushfires will you divert me into fighting? Which will happen first -- Building T5 ("Temporary Building #5") where the server is supposed to go, will be torn down and replaced, or Facilities will finally get off its ass and bring in new, higher-cap mains service wiring which is required because the current wiring already is overloaded and some of the circuit breakers there trip-out every month or so? And when will that happen? Will your boss die of heart attack, or take early retirement? When will that happen? You KNOW he and Marge in Accounting will never quit feuding, and that 10~20% of the purchase orders he submits will continue to go "mysteriously missing." Yeah, ten years sounds about right.
@An_Old_Dog
What a complete load of rubbish. If someone asked you how long it takes to drive from Manchester to London, you'd say something like 4.5 hours. You wouldn't say, well it depends if you go via Land's End, or it depends if you have a medical emergency on the way and end up in hospital for a month before completing the journey, or that you can't say because they've not said whether they plan on driving at 1mph or 70mph.
Sure you might then go an caveat your estimate by saying there are some plausible variables which may affect things, and - if you were being helpful - you'd say that they might want to factor in perhaps an additional hour or so for some margin.
Your comment sums up everything that is wrong about the software development industry, and some of what is wrong about agile, Nobody likes the hard, detailed planning which is needed to come up with decent estimates, or the measurement needed to record how previous developments went according to their plan. Developers certainly don't want to do that (I'm generalising here), they want to start writing code at the very earliest opportunity, which is partly why agile is so popular. Of course there are unknowns, and variables which will affect things. And there are processes to accommodate and manage those. But jumping on the very first excuse and using that as to why it's impossible to come up with any estimate is ridiculous. So you've not been given all the requirements? Then estimate the ones you have. Estimate what your best guess is for the ones you don't know and explain what your margin of error is.
Can you name any other industry where your response would be considered acceptable? If you ask a builder how long it will take to add an extension to your house, you wouldn't expect him to say something along the lines of what you've put. And while I accept that many (far too many) software projects or indeed any form of engineering projects overrun, even that is no excuse for not having the plan. After all, if there is no plan, you can't say that you've overrun (hmm, and again that's another reason agile is popular), and if there is no plan, you can't improve on your estimation techniques for the next project.
But because it's hard, that doesn't mean it shouldn't be done and because it's hard, that doesn't mean that management shouldn't get told estimates.
If you ask a house builder to quote for an extension, you will have a design already, drawn up by an architect. If you ask for a computer program you might have a vague concept, you won't have a design. A builder won't quote for "build me a house" without a design.
That's the big difference.
The software is also much more risky:
For a house extension, you will have checked there's nothing buried under the extension, like a gas pipe or water main. And you will know what the ground is like and what foundations you will need. For software, it usually has to interface with other systems and processes that are not well defined, and trying to do that may uncover bugs or limitations or other difficulties with the 3rd party bits.
And the building materials supply is pretty reliable, your builder will be able to buy 2x4 timber without worrying that it might be completely rotten inside with just a veneer of good looking wood on the outside. For software, there is so much buggy and/or undocumented libraries and other code that you will be using.
If you want it in driving terms it's more like
M: How long is it going to take us to get there?
D: Where are we going?
M: I don't know, but I'll know it when I see it.
Then, after you've set off, it turns out there are some other destinations that are easily confused (I meant Poole in Yorkshire, not Dorset) and maybe additional passengers or cargo to deliver which you weren't told about before you set off so you need to go back and pick them up.
These aren't the devs being slack at their jobs, but refusing to give estimates without a detailed plan is a very good starting point. Otherwise it's your fault when you miss the estimate. The estimate _becomes_ the plan. If you've told someone that you can get from Manchester to London in 4.5 hours and they set off in their knackered Nissan Leaf that can do 30 miles before needing to stop and charge up, they're not going to be happy with you!
The estimate _becomes_ the plan.
This!
Find me a manager that can really grok the concept of story points. You won't; all will immediately try to convert them to a level of effort (if they're good), or worse, a calendar date, if they are typical).
@Hawkeye: Thanks for your comments.
* I wasn't writing specifically about Agile. I've never worked on an Agile project, though I've read a few of the XP books.
* Project managers are supposed to take care of the "Facilities won't get off their asses" and "Marge in Accounting is endlessly feuding with my boss' boss"-type problems. Sometimes (many times?) they simply cannot do so, due to the office-politics-environment.
* Most of the projects I've been on did not have a formal project manager; that duty devolved to me. My job title was "System Software Engineer", but I was doing it all, conducting user interviews, speccing and ordering hardware, etc. My dealing-effectively-with-office-politics skills are far-below my software and hardware skills.
* When a non-software-only manager asks you for an estimate, many times, regardless of what they say, or ask, or what you tell them, in their minds, the estimate estimate you give them is for the entire project, not just the software part.
* T5 is still standing, and its wiring has not been upgraded. My boss' boss did not retire, nor have a heart attack. He and Marge are still feuding. The engineer my boss re-assigned the web portal project to (he used me as a nearly-full-time firefighter) broke the logjams thusly:
- She convinced a manager in the PR department (which, among other groups would be using the new web portal) to convince the Powers That Be that the server should physically reside in the server room in CSB ("Campus Services Building"). CSB also needed a mains upgrade, but they got it, because Facilities' offices are located in ... tada ... CSB. Facilities doesn't like working in the dark.
- She worked out a deal betwen my boss' boss and a manager in HR (also major users of the portal) whereby IT made a conditional block transfer of funds to HR, which HR drew against to supply money for anything on this project which ordinarily would require a P.O. from IT. This sidestepped the feud between my boss' boss and Marge.
* Many times, "technical" problems are actually people problems.
>> Mgr. How long will it take you to get our web portal built and running?
Prg. it depends
>> Mgr. C'mon, at least give me an estimate
Prg. Pfffttt. 10 years
Mgr. outrageous, try again
Prg. 5 years?
Mgr. outrageous, try again
[...]
[many half-lives later]
Prg. 6 months?
Mgr. hmmm...better but still a little too long, try again
Prg. 3 months?
Mgr. wow that's great! exactly when I need it by
Prg. the fuck didn't you just say so. We can do a wordpress site for you in that time
@Missing Semicolon, have an upvote. You'd have more if I could give more.
I'm gobsmacked that anyone can genuinely say "And that's all you need". Too many developers think that it's all about them, all about the software. They have no regard for the other aspects that any sensible business needs to plan for. Like when does the training material need to get worked on? When can the sales people start selling it? When can the detailed planning start for the next project? What is the roadmap for the next 12 months? Do we need to employ more, or less, developers to handle the workload?
Any software development team or project manager who is unable to give estimates of how long it will take is quite simply failing.
Any software development team or project manager who is unable to give estimates of how long it will take is quite simply failing.
Fuck, without ACTUALLY knowing what the hell is being built you CANNOT give any estimates. To me the fundamental rule agile is you wing it and start before you know what you are building. So of course you will have no idea as to how long, what resources are required and cost! But Hey! we are agile!!
The problem is the people paying thinks it trivial. Its like they take you up in a plane and hand you all the materials they think you need to design and implement a new parachute. You are half into the flight and have a few prototypes and ideas when management comes in and bundles it all up and toss it and the team out of the plane. Yelling you have until you hit the ground to work out the bugs.
Give them a steer on what you want, hold informal checkins on a semi-regular basis, and then get out of the way.
All too often that leads to the situation we've seen at Birmingham council.
First, define exactly what your users need. Write it down, and agree a change control process.
Then let the good engineers loose on it.
That's Waterfall.
It fails because users really don't know what they need. Only what they have, and the myriad of ways that it sucks.
The theory of Agile is that you are supposed to continually deliver smallish pieces that are useful.
Agile fails because all projects and significant features have a minimum requirement before which the product/feature is completely useless. Decisions made right at the beginning always set the path, and changing out flawed foundations is incredibly expensive.
The true path lies somewhere in between.
And even if he did, he was likely wrong, since even before Ford came along people were eagerly experimenting with various sorts of automobiles. Many city dwellers in particular couldn't wait to get rid of horses, which were horrible (in large numbers) in cities. Horseshit all over the roads. Flies everywhere. Dead horses left to rot in the streets. New York City established its Department of Sanitation specifically to clean up horse-related messes.
In fact, people speculate about all sorts of solutions to their problems, not just improved versions of the ones they already know. Many of those speculations are daft. The problems with user research are 1) it's a bunch of work, when done properly, and 2) the chaff has to be winnowed. It is very much not the case that users are incapable of proposing viable solutions.
It's simpler than that.
Agile fails for the same reasons Waterfall does, or any other development "methodology" for that matter: there are people involved.
And some of them are simply not very good at their job.
Doesn't matter whether they're the customers providing input for the "user story", PM / "scrum master" herding the cats on all sides, or the developers working on the actual product.
Sometimes all it takes is a couple, or maybe even one, incompetent bungler, a chaos cowboy project lead or PM, customer with an axe to grind, a toxic malcontent, a manager with an agenda and enough say-so to make their employees miserable, etc.
If everybody on the team is pulling the same proverbial rope in the same direction, there's a fair chance they'll carry on and come up with something, regardless or even in spite of the dev methodology.
But you don't find real teams very often -- they're hard to build and even harder to keep together. Be thankful when you come across one, whatever their mission.
No, not necessarily.
I've been in tech for a bit under 4 decades myself, and I've been part of a few really good teams. Those were great times, and also very productive for us and the people we supported.
I've also had the sad experience of seeing those teams devolve and fracture around us, usually due to bad managers with bad agendas and more ego and ambition than skill or experience or even common sense. Sometimes it happened because the company itself was failing ... repeat the bit about bad management there too, I suppose.
Sometimes the individuals from those formerly good teams find each other elsewhere and build a new good team -- it happens. Happened to me, twice. I consider myself lucky -- IME that doesn't happen very often.
The point isn't fatalistic nihilism or whatever; it's that you should appreciate working with good people and teams when you find them.
And back on-topic: Agile and Waterfall et al don't make a team good or bad. Good teams find a way to get stuff done regardless of methodology. Bad teams are the same, in the other direction: they find ways to bollocks it up no matter what development program you give them.
Absolutely! I can't tell you how many 5 year, cast of thousands, multi-million dollar projects I've worked on that started with a one sentence requirement (get off the mainframe), that had sub-optimal outcomes. Well, the answer is one, but it's weird it happened at all.
>"It fails because users really don't know what they need. "
And the Developers have even less understanding of what the users really need and talk a different language...
Once you get beyond the simplest of developments, Agile becomes, a concurrent waterfall as work is untaken at multiple levels by multiple teams (analysis, process design, functional design, configuration, etc.).
One of the big issues I encountered was that developers underestimated the size of the system, so did agile development on a single server configuration, then got upset when told they had to rework because their code won't scale to multiple servers and/or huge databases. This is partly because they can only use a "benchtop" environment for testing until a representative production environment can be prepared. I've tended to bring in a second team of developers to do the rework, letting the first team focus on getting the logic and flow right.
define exactly what your users need
Perhaps defining the absolute minimum your users' roles require would have more satisfactory outcomes.
Unfortunately in most organisations roles are so ill defined that those assigned the roles are unable to unambiguously and consistently define their roles. Where the roles are a rigidly defined by the organisation they are invariably totally unrelated to reality.
People aren't at fault here. Human intelligence can take a collection of ill defined, shifting and often contradictory objectives, adapt and apply their experience and bit of realpolitik pragmatism to achieve positive outcomes which are frequently more resilient, reliable and consistent than anyone would have any right to expect. They, themselves, would have difficulty in explaining the rationale of their decisions and actions (or inaction.)
Understanding this and throwing in the wet dreams of generative AI the potential train wreck is pretty obvious.
The desire for the minimal is simply that small mistakes are infinitely easier to rectify than those of monsterous monolithic proportions. Start small but open, incrementally build in small steps on solid foundations and only in response to real needs.
I am guessing Agile started out recognising much of this - hence the choice of name - but neglected the unavoidable consequences of human nature in derailing any real progress. Once something becomes a methodology rather than just a method it's a lost cause in my book. I need both hands to rerack a server so I could never afford the luxury of sparing one for the current methological thrill.
It's not human nature.
The problem is that Agile was intended as a way of minimising management meddling in the work of programmers, keeping them out of their hair and not interrupting them.
And then it was the managers who embraced it and acquired certificates to put on their CVs and gave seminars about it.
As usual in history, none of this was inevitable.
> And thats all you need.
That *should* be all you need, yes.
Unfortunately the army of MBA's, PM's, and other acronyms will likely think and do otherwise. Especially if they have any motivation e.g. to bring in the whole atlassian suite to "make their mark", or collect some vendor appreciation season tickets to the local sports teams, golf club memberships, and so on.
A subtle tweak is:
"The more non-value-add process you have the less agile you are."
Or, put another way, you should create the minimal process required for you to be effective at delivering value.
Sadly, before we had all this certified process framework-in-an-expensive-box stuff, folks got together to do a thing (aka, achieve some goal, some flag in the distance product vision).
After a bit of time working together, they may have noticed some things they could repeat in a common way of working. Maybe they needed to add new people and wanted to "loosely" show them how they worked -- so they drew a process flow chart. They may have even written some documentation.
Then, some tedious crap that happened frequently started to annoy some of the folks. So it was automated -- and even better, a tool was invented to make it suck less.
Now the team has honed in on the right amount of process.
And as the months go on, they adjust up or down as needed in their process.
And that's great right up until the point where that team doesn't want to do something, so they just don't. The typical example is documentation. I know a lot of developers who don't want to write it. I know a lot of companies that don't want to employ someone else to write it, and if they did, the developers don't want to tell those people the kind of stuff necessary to write it. I've seen both those groups use the line about valuing working software over documentation in the Agile Manifesto as an excuse for why their stump of a readme and error messages is enough documentation. It isn't.
There are a lot of good processes that come about organically from a team just trying to get something done, but sometimes, that team needs to get a very specific thing done, the kind of thing that no team just decides they want to do. Few or no people have gotten together with the dream that, if they put in some time, they could build a really nice web interface for forms and processes of a local bureaucracy, but someone eventually has to write the software that does that. The processes that work for one do not necessarily work well for the other, because the bureaucracy in question doesn't understand the technical reality of what they need, the devs don't understand the processes the code is supposed to deal with, the customer does not have the time or inclination to test a gazillion intermediate versions that don't do anything of use because not everything is connected up yet, and the local government has fixed budgets and timelines because they are required to do so. That can be resolved in a variety of ways, and in some of them, the more Agile approach is the better one. However, the completely Agile approach, where the customer's whim is sufficient to change things at the last minute and there will be lots of those because nobody planned out all the needed functionality at the start, is bound to create chaos when the scope has changed but the timelines have not.
"And thats all you need.".
No.
How about knowing about "What you need to build!"
I've been involved with several agile projects that start the have to completely reset as no body actually correctly defined the requirements! Just little things like using a toy database system that couldn't cut it. Suddenly finding out the solution could not meet the NFRs.
https://www.reimaginingagile.com/
https://www.reimaginingagile.com/exemplars
The article read like transcript of a telephone call, hence the ambiguity: His team have been Reimagining Agile since 2023, and are currently in the process of collecting Examplars. Putting the shout out for Examplars to come forward may be why he spoke to the Reg.
Sweet Lord. It is more a last desperate fight for power, which is what Agile has always been about ... power.
I've read a post above this from a middle manager and it made me ill. I'm glad synergy wasn't used and I note the post-post-modern approach of hiding your crappy buzzwords in clauses now. We still see them.
Agile sucks. When it first came in it was full of jaded ex-hippies old tech heads from America posing a faux guru-like presence. Tossers. I witnessed this on 1 project and the Agile bloke was some world-famous twat. Left after 1 month. Insufferable theoretical planning with little understanding that people are actually people and work is a secondary thing to love, family and life.
Burn these witches. Do not let those project managers out in Production. Keep them back in middle management aspiring to the executive toilet key.
IT is still far behind Print in terms production.
Even simpler, the answer to any critique of Agile is "if it didn't work, it wasn't Agile". Handily unprovable and tautological. It means that no criticism is considered valid; if they don't like the thing that you don't like, then it was never a part of Agile, even if it's written right there. If they do like the thing you don't like, then clearly you weren't doing it right, so that's why you are wrong.
There are times when an Agile-like approach is the best one. Knowing when to apply that is important. It is not all the time, and it would do its adherents well to at least understand why we say that rather than try to dismiss immediately every time something is questioned.
I've seen a few fads at work - Lean, Six Sigma, CMMI, Agile. They all sort of failed and it's because the powers that be latched on to the fad and did the easy bits but ignored a lot of the hard stuff or the bits they didn't understand or which appeared to have minimal gains. And it sort of worked for a while - probably as much due to Hawthorne effect as anything - but once the boss stopped taking an interest things gradually migrated back to the old ways.
I liken it to me taking up cycling with a view to racing so I copy the successful TdF teams' approach. Expensive carbon bike? tick. Expensive bike fitting? tick. Expensive lycra? tick. Heart rate, power meter, performance tech? tick. Put in lots of miles against a training plan? tick. Spend hours analysing ride-data? tick. Follow a strict diet? tick - except Saturday beers and the curry club are sacrosanct. Proper warm up and warm down? tick, but not really. Gym work for core strength? I do the odd plank, so tick. Physio? Don't really need that cos I've got no twinges, but we'll call it a tick. Gradually the minor items, which glue all the hard work together, get dropped, but as far as the neighbours can tell I'm still training lilke a pro. I get measurably fitter and faster - so the metrics look OK but I'm a million miles away from being a racer.
"No true Scotsman would implement Agile that way!"
The problem is that the real world has: budgets, time constraints, deliverables. Pure Agile is nice for projects without these things, which is to say, imaginary ones.
Oh I mean sure, 95% of us who are actually shipping usable product are actually doing something like Agile, because Agile itself is an attempt to document how software actually gets made. We accomplish our goals by actually ignoring the deadlines and budgets and just going ahead with iterative development, on the assumption that it will take as long as it takes regardless, and a gut feel (sorry, "good estimate") about the overall complexity of projects to decide whether it's deliverable. Agile itself is a mostly-failed attempt to formalize what disciplined teams do naturally.
Agile is very similar to music theory. You can analyze the classics forever to try to understand why you like good music, but if you plug all the theory into a machine and try to make good music based on it you won't get any.
The challenge of marketing "Agile" as a product / methodology / conference however is that you can't sell a mindset.
Hence the fact it's become a process. That is something the unimaginative can easily grasp and the cynical can easily sell or put on their CVs. The agile manifesto needs rewriting with a big block capitals disclaimer at the top of the first page saying "Agile is not a process. Anybody selling this idea to you is a charlatan. Avoid them like the plague."
There are some things to like in Agile. And some things which make no sense at all.
But that's not really what I'd like to focus on. I've had some thoughts percolating in my mind for a while, and would like to dump them here.
We shouldn't need Agile. It's a sticking plaster. Agile is often brought in because of previous failures to deliver IT projects. When Agile fails it's often not because of anything Agile was doing - any project management system/methodology would have failed in those conditions.
It's an unfortunate truth that people in IT are often bad at explaining the necessities and requirements that their platforms/technologies/infrastructures have.
It's an unfortunate truth that people in Management are often bad at making time to understand their IT requirements and capabilities.
It's an unfortunate truth that people in IT are often bad at making time to understand their organisation's requirements and capabilities.
It's an unfortunate truth that people in Management are often bad at explaining the necessities and requirements that their organisation has.
It's an unfortunate truth that many people are eager to please others, so will give slightly optimistic estimates. (We've all regretted it, right?)
It's an unfortunate truth that some people in Management are grubby little climbers, happy to shave estimates down to make themselves look better.
All of this combines to create significant issues with communication and trust. In many organisations both sides might say they trust and respect each other, but their behaviour says otherwise.
I feel that Agile was created simply as a framework to try and deal with these unfortunate truths. Something we could wheel out and say "Let's start over with this, which will fix it!"
The sad fact is that in doing so, it fails to address the actual problems. It's like putting a splint on a broken arm and then saying "Right, that'll do it. Back to climbing up the north face of the Eiger then..."
Strangely, that's not very likely to end well.
I find it fascinating that our relatively immature industry thinks it needs its own methods of working. Generations of tallest buildings, fastest aircraft, largest ships, longest bridges, and much more were done with fairly traditional project management methods and systems. And yet somehow we can't use those? It's an interesting narcissism - "the problem isn't our industry, the problem is we're using bad tools". Well we all know a phrase related to that attitude...
I don't hate Agile. I don't love traditional project management. I'd just like to see us being honest about the root causes that often drive people to change their management methods. Because surely if more than one method system has failed, then the problem is likely to be somewhere else?
Anyway, sorry if I've offended anyone who's inexplicably wedded to the cause. Hopefully an alternative point of view is useful to you...
The problem is constant and it is "change". The other constant problem is humans.
Everyone likes to think they are an IT expert and put the 2 zorkmids in just because they have used a PC. Meanwhile, those same oxygen thieves can't explain what it is their department does, why it does it, what value does it add and what is unique about it. So, they will come in, sniff around for a bit, piss on everything and leave. (Wombats).
How many orgs are still running with a joint CFO/CIO instead of two for the role (and which hat will inevitably be more important?)
How many orgs will balance both the technical and financial aspects of a project at the outset instead of "This is the budget and I heard about this product in a magazine/the technology salesperson was hot/paid for my last holiday/promised me a consulting gig in 18 months, you go execute (waves hands)".
So, for all the "Worlds Blankiest Blank" projects, with clearly defined goals and a strong leadership team, there are a million variations on "I need something and I need it now (but I can't tell you what)".
Better, find a copy of Vivian Stanshall's 1978 studio recording of the original one man show. Amazingly, it seems to be available on the Toobs of Ewe ...
https://www.youtube.com/watch?v=DXdNUJBid5s
As usual when it comes to such things, I must tip my cap to the late, great John Peel for showing me the way ...
As an aside, and three days late, Viv Stanshall has recently released (despite death) a follow up to his first studio album: It's called "Rawlinson's End" and involves a baby dinosaur and is not bad (if you like this kind of thing. If you don't then just ignore me please). Find it on BandCamp.com published by Madfish Music.
>How many orgs are still running with a joint CFO/CIO instead of two for the role (and which hat will inevitably be more important?)
Just taken on a joint CFO/CIO role for a small organisation - taking over from a CFO and a CTO...
Agree, the CFO role takes priority - people need to be paid every month, bills need to be paid etc.
The CIO/CTO role is definitely a distinct second, good thing I have a substantive IT background...
Whenever agile is mentioned, there is an immediate torrent of 'religious' reactions as the for/against proponents ready for 'War'.
Every developer I have worked with has stated that they 'know' what to do and don't need to be told by any process/mindset or PM what to do !!!
Confidence and/or arrogance is OK in moderation but most developers do *not* have the full picture of what the true constraints and issues are and working in their silo is not the be all and end all !!!
[To head off the obvious attack ... I was once that developer !!!]
A more open mind and ability to see the flaws of the current process is necessary.
Agile or any pre-defined process/framework is *not* the solution to solve *all* problems ...
The solution is better communication and to get out of your 'silo of perfection' occasionally to see the real world.
(This applies to Managers & Developers)!!!
Less edicts from on high without understanding the consequences would help, while talking to the real-world users about what they really need would stop so much wasted time developing what no-one wants or can use only with difficulty (Usability is *my* particular bugbear) !!!
I live in hope but with low expectation ... would love to be proved wrong !!!
P.S. AI is *not* the solution it is just a different type of *problem* ... you have been warned !!!
:)
In fairness to Agile (I'm not an adherent as you can see from my comment above), communication with the customer is one of the things it calls for. I think that would have been better if they made it explicit that the customer is the user, not the person paying, but still, they agree with you there. It is also one of the reasons I say that Agile only works in some cases. If you can frequently bring things to the user and get their reaction, then it works as an approach and is, I think, similar to what you're suggesting. If the users are giving you good feedback during development, you can head off usability problems and stop working on things that nobody wants.
The problem with this is that there are times where the work that is necessary is not something users can comment on throughout development and that sometimes, they won't even when they can. If this applies to a project, then something needs to be done to accommodate for that lack. You should communicate often except when you can't, but those two alternatives need to be handled quite differently.
Original A/C.
Not anti-Agile, I *am* anti-blind_process. 'Horses for courses' applies *always* and totally agree with your comments.
The problem is whatever your chosen process/framework/mindset the user (Real as you have highlighted *not* just the person signing the cheques) must be involved and explaining the unexplainable is something you should be able to give to the PM to handle while you get on with the work.
Most problems are simply communication issues and 'Homo Sapiens' is not very good at this *still* !!!
:)
@AC "Every developer I have worked with has stated that they 'know' what to do and don't need to be told by any process/mindset or PM what to do !!!
Confidence and/or arrogance is OK in moderation but most developers do *not* have the full picture of what the true constraints and issues are and working in their silo is not the be all and end all !!!"
I am a developer and have had plenty of rows arguments discussions with Project Managers, Development Managers and Product Owners etc down the years, so I feel I have mastered arrogance. Those discussions were never because I'm a developer I know what to do, quite the opposite, I don't know what to do because there are technical issues that need to be resolved or can't be resolved*.
Or I don't know what they want, because they failed to give adequate requirements. "Hi" to the Product Owner who thought 'Make it work nicely' is all the requirements a developer needs, "how's it going?"
Everywhere I have worked have different processes which changed over time. In my experience when developers (myself included) complain about processes it's normally because those processes have changed**. Invariable complaints also suggest better (in their view) processes, better is what we used to do.
* A Product Manager required I design a feature with two mutually exclusive requirements.
** No one likes change when it's not of their choosing
I've heard applications programmers tout this over the years but whatever its intentions were it always seemed to be a "throw stuff at the wall and see what sticks" approach to engineering or what used to be called in the old, old, days "bottom up". There are times when this works, especially if your application work is mostly tweaking UIs or toolsets and doesn't involve algorithms, coordinating processes or anything like that but overall all I've seen it do is endless "Phase 1" (i.e. incomplete) releases and less than stellar reliability.
I suppose what the proponents were trying to do was chart a course between slapdash and "so ponderous that we've forgotten why we're here". Laudable, but its a bit naive to just publish a "bleedin' obvious" screed, call it a Manifesto and expect everyone to really understand what they're trying to do from it.
(Yes.... I know how to write quite decent software quite quickly, I've done a lot of it. I can't quite put my finger on how its done, a pity because if I could bottle it and sell the method to all comers then I wouldn't need to spend hours fiddling with computers.)
Well, because in the great agile tradition of putting some kind of structure around kicking the can down to the road, you can stuff "get requirements" in the first sprint and have them completely sorted out by the end of it.
you can stuff "get requirements" in the first sprint and have them completely sorted out by the end of it.
Completely? Really? That is the usual reason for ultimate failure, never quite understanding what is needed in real life.
The tricky bit with Rapid Prototyping is convincing management that its just a model to get a feel for the scope of the problem. This is a bit nuanced -- to many its going to look like you've developed the product, it just needs a bit of tweaking here and there and its ready to go. This is why its so dangerous for applications people to do this -- their mockups are going to look like real products, its so easy to simulate a working product and to make matters worse 'on the bench' tests are hardly likely to reveal the real life product shortcomings.
We have to use tools that need extra custom tools to produce the reports we need for a certification authority.
Said custom tools are supported by a team that use 'scrum', not proper 'agile', but that's beside the point.
They buggered up a tool during a server change because they had never gotten around to making the 'proof of concept' work properly on any server (I suspect lots of hardcoded values). My experience here is that 'agile' = technical debt, where the devs move on to the "next new shiny" rather than actually finishing anything properly.
For 4 x 2-week scrum cycles they have push the fix onto the next scrum as it's not a 'sexy' thing to work on. Yes, it keeps making it into each scrum, rather than remaining in the backlog!
Letting the devs decide what they want to work on does not work in the vast majority of business cases I have come across.
Unfortunately the VP in charge of the department (yes we've taken it that far) just believes in the 'agile' process and says that of course the tool we desperately need will be fixed soon.
Disclaimer I am a certified Scrum Master, so I know how it should be done and was part of a highly functional team using scrum for 4 years and only manglement called it agile.
I loved the manifesto. It was simple. It was short and it was well meaning, but what I saw happening was packs of process fascists grabbing it, ripping the cash off the customer and building what they wanted and not what the customer needed. And they did it with scrums and sticky notes and a Nazi aire of superiority. If you "denied" Agile you were in the gutter... And that included the customer. It's been a horror.
Mind you, just look what happened to the bloke that came off that mountain with God's manifesto in stone... OK that had 10 points and not 9 but you get the idea.
Many comments on here back up exactly what Jon Kerr is saying.
Let's reset, reboot and consider the agile manifesto for what it is - a suggestion for a way of working smarter, delivering value in increments.
You can follow all the frameworks and earn all certificates you want. But the more rigour like this you add the more it begins to feel like old school development.
In the real world we have dependencies, e.g. do this before you do that. You cant break everything down to do it in any order the developer can cherry pick (Writing new test harnesses and refactoring as you go) Thats called stupid...
You can't use agile to build a house.
You can't use agile for hardware deliverables
You can't use agile to write a book
You can't use agile on an oil rig
Why do we think software is so different?
I always viewed agile as a way for shit developers to avoid being responsible for delivery.
Honestly, I think the only real route is benevolent dictatorship.
> In the real world we have dependencies
Have this with my current client [1] who have contracted out their IT capability in different pillars [2] to different suppliers under different contracts. So we want to start testing but have a dependency on another team to set up the cloud test environment.
Us: When will the cloud test environment be ready?
Infra team: In sprint 2
Us: that's a 3 week window - beginning, middle or end?
Infra team: Can't say
Us: So if we stand-up a team for the start of the sprint they could be sitting around doing nothing for 3 weeks?
Infra team: <silence>
Us: Who will be paying for that?
Infra team: <silence>
[1] a Gov't department
[2] Because they have to
This.
I was on a project that was trying to be agile, and stand-up after stand-up, I said the same things about hardware delivery, sequencing, infrastructure timelines, system installation, client lead time for access, and just ticked off the milestones as I achieved them in each stand-up. Complete waste of my time.
I sketched out my timeline and milestones right at the beginning, and pretty much kept to that schedule. Nothing Agile about that, all about planning and timely execution over an extended period.
The PM could equally have said "let me know if you have any problems", and let me get on with it without any requirement to attend the standups.
What also made it complicated in this instance was that people were on more than one project, attending more than one stand-up, and had conflicting priorities between the different projects.
Agile can work, but it's not one-size-fits-all.
My experience has been the opposite. The people pushing Agile are the same ones pushing for open plans. They say the war rooms, bull pens, etc, enhance teamwork. The new trendy things to make developers more efficient and more productive.
Then they turn standups into status calls where everyone gets to tell the team the exact same info that anyone could see from a 30 second look at the Jira board. Mention any blockers, but if a solution requires more than a single sentence to clearly describe a work around, better move that to a different meeting. On a good week 20% (a full day of work) was wasted on meetings.
> On a good week 20% (a full day of work) was wasted on meetings.
Quite. The last 2 jobs where I had to work with (around) Agile teams and their Jira-ing, they couldn't be arsed to even fill out basic fields and info in Jira. No code review, the barest scrap of a user story, couldn't tell which engineer(s) were working on what, where the code was, what state it was in, on and on. It was practically useless. It looked more like a lazy helpdesk's low-effort attempt at creating a ticket after the fact, just to keep some manager off their back and juice the ticket metrics.
The jira dashboard was equally useless, as you'd expect. Basically a facade that management could point to and say "look, see! Progress!"
And yet they had several "stand up" meetings every week, and they weren't 15-minute affairs either. If they moved right along the meeting was a full around-the-table regurgitation of activity (or lack of it) that probably should have been in some jira report or dashboard or something, but clearly was not. Sometimes it devolved into rambling grievance sharing sessions, or ratholing into details that all but 1 or 2 of the meeting participants would have no idea about.
It was silly. Process for process' sake at best.
But at least Atlassian got paid, I suppose. And some folks got to put "Agile" or "Scrum Master" on their CV, I guess. For whatever that's actually worth.
Most of the places I've worked at over the last three decades claimed to be agile - only one of them came close. The one where I was CTO and introduced agile. We increased user count by two orders of magnitude, going from tens of thousands of regular users to millions.
Agile is almost certainly the antithesis of what you have experienced at an 'agile' company. I encourage people to read the manifesto and listen to people who actually know what it is like Alen Holub, MArtin Fowler and Ron Jeffries.
Agile is a mindset, it is not a process, tool or framework you do.
TLDR: Would you rather work at a company that 'does' kindness or is kind?
Because, when originally published, it started conversations here about whether Agile is a good thing. Not because the report was any good. If you review the comments when it was originally talked about here, you'll see many people making the same points about the uselessness of the report and you'll notice that few if any of the criticisms of Agile are related to the content of that report, but are instead about our experience of Agile, its theory, its execution, and its results.
In short, nobody is talking about the report except for the Agile promoters who, wanting to argue against those of us who have problems with the manifesto, have started with the obvious. They have correctly pointed out problems with a report that none of us care about, but they have not responded to any of the criticisms raised in the comments. Only one of the creators has actually joined a conversation here, and only to say that he didn't bother reading most of the discussion but was sure that whatever we were complaining about wasn't Agile anyway. Not that they need to, but if you want to complain about the people still referencing the report, those are the people you should look at.
Can you (= the team) do the job?
If you can, you will be able to do it to clear, strict requirements. Along the way, you will be able to argue about those requirements and suggest improvements, additions, deletions, modification, etc. You will know that those "strict" reuirements will change along the way and you will come up with a flexible design that will help accommodate the changes without rewriting everything from scratch.
By the same token, you will be able to do it without a complete set of clear, strict requirements. You will argue about what is needed (you will also find the right people to consult with, in addition to or, in some cases, instead of the Product Manager who came up with the original requirements, clear or not), and fill in the blanks along the way. Not everything will be certain - or correct - from the start, but your design will accommodate the new information.
If you know what you are doing you will also be able to estimate complexity and you will know where you do not even know the complexity (those will be the parts that you cannot easily decompose into tasks that you have already done in the past). That will be an essential input for your effort estimations that the managers will want to know, By the way, if all complexity is known and the job has been divided into familiar tasks (and known dependencies between them) a waterfall/Gantt will do as methodology. This is also the reason why old, well established industries like, say, construction can often/usually do very well. It is unknown complexity that engineers overprovision for and that is the source of those conflicts with Sales and Management. Knowing how to do the job includes being able to explain and stand your ground (and, on occasion, disclaim).
But what if you cannot do the job? For one thing, you very likely won't know the complexity. You'll make mistakes, You will redo stuff every now and then, and you won't have a flexible design to make changes easy. No amount of "methodology", "process", "daily status meetings", "looking over the shoulder" will help. As a special case, none of those things is a substitute - or compensation - for hiring cheaper but less capable workforce. And I do think that proponents of methodologies and processes have this assumption - that methodology can help regardless of composition of the team - implicitly in their theories and manifestos.
Oh, but what if you are young? How will you learn to do the job? From working alongside your more experienced colleagues who will generously suffer the overhead. Learning how to look at clear requirements and lack thereof, and how to design for various eventualities (and assess their likelihoods). In short, how to do the job. Looking back at my own career here...
Learning "methodology" won't help you much. Well, it might help you get that next job, but if it does chances are you won't learn much more in your new position. Therein lies your path to Management.
Both are bad.
The crappy code will always be crappy, and likely won't meet actual requirements for the whole lifespan -- bad code tends to fall down over time; then the poor sods who have to fix it down the road will likely have a real mess on their hands.
The wonderful code was probably a waste of time, depending on how far afield it is from the requirements. OTOH there might be a chance the good code could be re-factored to fit purpose. Depends on how badly the PM or scrum master bungled the requirements capture.
Both scenarios are possibly (probably) more costly than doing it right in the first place. Neither should be acceptable and no one should sign off on the project completion in either case.
"Start again."
Just pointing out that at least the first option produces a usable if problematic system. The second option will just get the project cancelled.
The worrying thing about agile is the obsession with code above all else.
Requirements come first and the project should have a deep understanding of them, the business and technical environment the system will run in and establish communication with all the major stakeholders before any UML is rendered let alone code.
has become the snake-oil-salesman types whose entire pitch is "your projects are failing because you're not doing Agile right, do Agile right and your problems will succeed". Management, of course, lap this up like a kitten does milk spiked with catnip.
Unfortunately, what most people* understand as "Agile" has become the "goto" of project management methodology. And I mean that in both the "default option" and "considered harmful" sense.
* and by people, I mean non-technical management
I work in games, which is absolutely perfect for Agile.
I've seen it done well, and I've seen people claim to be doing it when they've completely missed the point.
I worry the second is more common.
In the first case we spent about 5% of our time in meetings (literally one day per fortnight, usually finished by lunchtime at that) in the latter, it was 50% of the time.
In the first, we could make development more efficient the moment we thought of a better way of doing them.
In the second we could make suggestions for eventually making development more efficient, which were largely ignored.
In the first, standup was at the start of the day, and took about a minute tops.
In the second standup went on for half an hour.
In the middle
Of every
Single
Morning.
Just had a look at the Agile Manifesto (https://agilemanifesto.org/) and the first thing I spotted in the background is that all the people are white, fat, males.
Do the authors think that only white, fat, males should work in IT? I'd hardly call that inclusive.
I also take issue with their belittling of comprehensive documentation. Without that, all knowledge resides in people's heads and that quickly becomes a critical business risk.
If the code is not documented (TBH, a decent comment would do) then it may as well not exist. Any merge should be concise and refer to a single ticket. In short, if you are doing things correctly then comprehensive documentation is an emergent property of your processes. If it isn't, you are doomed to fail.
Almost 50 years in IT, but only the first four in development (the rest in systems, infrastructure, operations). Not going to pretend I understand Agile, but I am married to a scrum-certified PM and have enough experience to know how large companies make expensive decisions.
For any large project, the funding needs to come from some business component, which has a fixed allocation they need to spread around to satisfy all their needs. Not much different than a household budget.
They need to know what they're going to get, when, and what it will cost... in order to estimate ROI to justify the spend. Those decisions, while informed by IT input, are made by business leaders (NOT FINANCE, they just manage the money... the decision belongs to the budget holder, not the budget manager).
Imagine if you were looking to buy solar for your house and you were offered a contract that did not include all-in costs, full specs, estimated benefits, and timeline. Would you sign up for that?
We all know IT development is a 'job shop', not an assembly line, so things work differently for IT projects... all one-offs.
I just don't see how agile works in the large-company-large-project space. I know how waterfall works in that space... poorly, unless you have a very very very good PM.
But then I'm (retired) ops.
What I have observed that works in the past is skilled developers and committed SMEs. OK, something to track things to be done is useful to make sure things don't get missed. Everyone talks to each other as needed - not just at a fixed time every day. You want to get a UI right? Dev and SME sit down and look at it, tweak it and make it good. No tickets, fix turned around in 90 seconds. Really good automated tests - this gives the confidence to make changes.
Things that do not work: No SMEs available to work with the dev team. Massive heavy processes. Blindly following procedures/rituals/ceremonies instead of understanding what actually helps. Not having a "big picture" that can say "hey, all these tickets are the same underlying problem". Oh, and pineapple on pizza.
I have been delivering software that meets the needs of the end user for the last 40+ years for at least since the mid 90’s I have been “agile”
Never missed a deadline , never failed to deliver
Agile is a mindset that just means get the job done
I personally go through the ceremonies of the client BUT then talk direct to the 3 amigos and work out exactly how we support each other and deliver
I love it
I could NEVER go back to the old waterfall techniques
100% agree. But I don't call this Agile, I call it "common sense". Agile recently has been mostly the ridiculous pointless ceremonies, and story points, movies sticky notes on a whiteboard, and all this c**p that just takes time. Normally we just zoning out while the daily standup ceremony to finishes and all 20 people get their 30 seconds each rattling JIRA numbers, so we can actually talk to whoever we are working with about whatever we are working on. Don't you?
I agree with much of what he says, but disagree with it too. The Agile Manifesto made sense of a sort, back around the end of the last millennium. I was sympathetic to every word in it. And yet I felt its prescriptions were silly. It applied to small projects, one or two people, doing noncritical systems in common IT shops. Made not a lick of sense for anything larger or more technical.
"Agile" has grown into all of these stupid processes and games with basically no specs, no budgets, no endpoints. Massively stupid. I did better than that even on one-man projects. It doesn't take more than an hour or two to put together non-technical project docs management can read and rely on. As "The Mythical Man Month" suggests, do some specs first. As Agile says, the specs are never complete nor entirely accurate. Live with it, don't just complain about it and issue manifestos. OMG
And then there was Extreme Programming, ROFLMAO.
So, software projects today seem to be mostly awful. No better, no worse, and really not much different than the first ones I took part in lo these many, many moons ago, circa 1975.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
