For me, Agile works well when tasks can be broken down into assignable chunks which can be undertaken by a multitude of people in the team as they have similar skills, knowledge, etc. Where it fails is when your team is comprised of multiple specialists attempting to do something that’s never been done before. Sure, in certain circumstances and for certain tasks, this can still work, but it’s largely the mundane tasks that are urgent, but not important that then take the specialists away from what they really need to be doing, but which is difficult to describe in a text box or update on a daily basis. The specialists feel the need to show that they’re accomplishing something and so do the quicker tasks rather than the deep thought tasks.
People who are pro-Agile always say "Agile works when it's done properly".
But it's never done 'properly'.
Because it doesn't work.
The specialists feel the need to show that they’re accomplishing something and so do the quicker tasks rather than the deep thought tasks.
For me, it's fundamental that it's team velocity, and you shouldn't be looking too hard at trying to track individuals.
People who are pro-Agile always say “Agile works when it’s done properly”.
But it’s never done ‘properly’.
Are you comparing it to communism?
Because it doesn’t work.
You are right, but I have 34 years of experience that tells me that it works better than everything we tried before. Somewhat like Churchill's description of representative democracy as the worst possible systems - apart from all the others that we've tried.
damn, beat me to it with the Churchill quote.
I've worked in agile, pretend-Agile, whatever you want to call it, since 2007.
Before that, I worked in the same field for 10-15 years.
And I have seen far more failed, abandoned, re-started, written-off, or just generally hopelessly off-track projects under Agile than I ever saw before it became the thing.
And far more highly capable individuals who are frustrated, unhappy, stressed, harried-to-the-point-of-bewilderment and probably burnt-out yet still determined to do a good job.
Just my observations; I'm not even trying to make a point beyond saying that if something can't be implemented correctly no matter how often people try, the fault is probably with the thing, not the people.
… a building project under Agile would see the roofer, bricklayer, electrician, digger driver, architect and plumber all turn up at once and told to start building, typically without first being told if they're aiming for a hospital, airport or block of flats.
Because it doesn’t work.
Just out of interest then, what's your alternative?
People who are pro-Agile always say “Agile works when it’s done properly”.
But it’s never done ‘properly’.
Because it doesn’t work.
It does. Loads of examples out there, I've been on a couple.
Does the alternative work? In software, most non-agile projects I've been on have been late, over budget and under-delivered too. So what does work, in your view?
a building project under Agile would see the roofer, bricklayer, electrician, digger driver, architect and plumber all turn up at once and told to start building, typically without first being told if they’re aiming for a hospital, airport or block of flats.
No, it wouldn't, because those things all have dependencies. Agile doesn't tell you to ignore dependencies, bloody obviously.
Premier Icon
Dorset_Knob
Subscriber
… a building project under Agile would see the roofer, bricklayer, electrician, digger driver, architect and plumber all turn up at once and told to start building, typically without first being told if they’re aiming for a hospital, airport or block of flats
I don’t think you understand the basics of how agile approaches are supposed to be used.
a building project under Agile would see the roofer, bricklayer, electrician, digger driver, architect and plumber
All work together to work out what the customer wants, be it an airport or a shed. Then they'd work on the first thing the customer needed.
In fairness though, your building example doesn't match agile development well as a metaphor.
There's a lot of crap spouted about software development methodologies and how wrong agile is. The important things are listening to people, treating them like people, working out what is of value and getting people working on that with minimal barriers. But I probably don't know what I'm talking about as I'm an Agile coach 🙂
The important things are listening to people, treating them like people, working out what is of value and getting people working on that with minimal barriers.
Yes.
Does the alternative work? In software, most non-agile projects I’ve been on have been late, over budget and under-delivered too. So what does work, in your view?
To be fair, I've seen quite a few non-agile projects delivered on time and on-budget, too. I think the main problem is trying to run a big software project the same way as a big civil engineering project: software is (currently) far more in flux than bridge building, and you just can't estimate or run big (e.g year long) projects the same way.
All methodologies can be done well or badly. It's not the methodology, it's the people applying it.
I suspect a lot of the original enthusiasm for agile was the lack of management (people not process) it needed and their salaries (The philosphy was power to the developer), but now we have product managers and scrum masters etc doing the same instead.
I do find the constant meetings and rituals tiresome.
Been a developer for about 30 years.
I think the main problem is trying to run a big software project the same way as a big civil engineering project: software is (currently) far more in flux than bridge building, and you just can’t estimate or run big (e.g year long) projects the same way.
You can, but a lot of organisations simply aren’t prepared to put in the rigour or the money to do so.
Some software - SCADA systems, or flight control systems for example - sure ain’t built using Agile.
Construction is done using waterfall for good reason, it’s bloody hard to change bricks and mortar after you’ve laid them. Software is easier to change (that doesn’t mean change doesn’t cost!) so Agile approaches work.
Personally I think Agile is best suited to places like Netflix, or Facebook, where continuous improvement of their single product is what they do. Or in a BAU situation where you’re working to a backlog of improvements and fixes to a deployed system.
I don’t think it works quite so well when you have a clear deadline and a clear set of business functionality that must be delivered. Where you can’t just out-scope something because you can’t fit it in, because otherwise the business doesn’t function. In this case, I prefer to take an iterative approach, using Scrum and some Agile techniques but not pure Agile or as rigid as Waterfall. IBM RUP is a good example of this way of working.
Software is easier to change
But it never is, is it, once it's released. Yeah I know there are exceptions. But generally it isn't.
I don’t think you understand the basics of how agile approaches are supposed to be used
Well, I think I do, but my whole point is the huge gap I see, in real life, between "supposed to be" and "actually".
And the agony (I don't think that's overstatement) for some of the people caught up trying to make it all work and build something in the process, who don't want to speak out for fear of being seen as an outsider among all the fake, infantilising bonhomie that agile also seems to love (whooping and cheering when someone moves a post-it 6 inches, bean bags and miniature rugby balls etc, making the office feel and look like a playgroup).
I love reading the agile theory books and I'm struck by the brilliance of it. Although it does all seem to come down to "speaking to the right people at the right time", which I was capable of before all these weird ceremonies.
If I knew of a better approach, and was able to sell it in the same way some of the big consultancies are doing, I guess I would be a different, more capable, and better off person than I am. I'm just a bloke trying to do my job as best I can 🙂
Interesting how offering my experience here has been received by the agile fans.
For a methodology so dependent on listening, another thing I see in offices is a lot of people desperate to have their say, and very little genuine listening, which I am sure I am about to be told is not how it *should be done*.
Perhaps the only thing wrong with Agile is human nature.
Perhaps the only thing wrong with Agile is human nature.
I feel you've nailed here, it's not the framework itself, but the egos of those involved with it that cause it to break.
For reference I wasn't aiming any insult in my replies to you, as that would be fundamentally against everything I work for, so hopefully I didn't come across the wrong way 🙂
And I have to agree with a lot of the sentiment, I've seen a lot of stuff done poorly and very rarely seen agile working well, but I don't believe it's the fault of the approach, just of the people involved in it.
Is this some sort of IT version of Mornington Crescent?
There’s a lot of crap spouted about software development methodologies and how wrong agile is. The important things are listening to people
And then tell them they are talking crap?
And I have to agree with a lot of the sentiment, I’ve seen a lot of stuff done poorly and very rarely seen agile working well, but I don’t believe it’s the fault of the approach
I would say it is the approach to blame. Its a bit like meeting one arsehole or meeting them all day. At some point in the latter case you need to think that there might still be just one involved.
You have claimed yourself its an approach all about people and yet, when it fails, you blame the people. Unless you can say how it can be improved to allow those people to work with it effectively then its a failed approach unless you just happen to have people it works for.
Which in my opinion is the problem with most of the management approaches that are trendy from time to time. They find something which works for one particular industry and most of the time just one particular company in that industry and then try and announce its the cure for all.
Sadly though since generally people are evangelical about just their favoured system there is rarely any proper analysis and going yeah I like agile but you know what in this case it will be crap.
whooping and cheering when someone moves a post-it 6 inches, bean bags and miniature rugby balls etc, making the office feel and look like a playgroup).
What? Is that part of the Agile methodology?
Or are you having trouble separating the bullshit from the genuine ideas?
What? Is that part of the Agile methodology?
It's certainly a big part of agile culture as I have lived it, yes - and even if it's not part of the 'the methodology' (said as though we all share the same idea of what 'Agile' means), then it seems to be so closely related as to be indistinguishable from it. It doesn't even matter if it's part of the methodology or not; it's been part of my experience, and that is what I'm reacting to on this thread.
And if you read my post again, you will see that I do not say that these things are part of the methodology, I just point out an association. You seem to agree with me that something is 'bullshit' but you're not specific on what.
Or are you having trouble separating the bullshit from the genuine ideas?
Clearly.
I don’t believe it’s the fault of the approach, just of the people involved in it.
I think this kind of supports my point. Any framework for humans that doesn't take human behaviour into account seems to be a bit doomed.
Is this some sort of IT version of Mornington Crescent?
🙂
They find something which works for one particular industry and most of the time just one particular company in that industry and then try and announce its the cure for all.
This is a lot truer than a lot of people care to acknowledge; many rather large day rates depend upon it remaining a buried truth.
But I feel I’m being constantly interrupted and having to update on things. Also everyone in the team having to be involved at every stage makes things very tedious.
I look forward to ‘the next big thing’ in software dev management. I think the problem with Agile is that someone has tried to formalise a way of working (small, flexible teams) but in doing so has broken the essence of what makes it work.
Anyone else feel the same?
Anyway - to the OP - yes, a lot of people feel the same. You're not alone 🙂 I know many people have been forced into stress-related time off as a result of all this so do what you have to to protect yourself, and good luck! It can be done; just takes a very studied zen-like approach, constantly reminding yourself what you're good at and what you've no interest in being good at, finding like-minded souls to bitch with at lunchtime or after work, and keep getting the miles in 🙂
Any framework for humans that doesn’t take human behaviour into account seems to be a bit doomed.
The human nature in question is not being able to successfully explain to others how something works; not being receptive to new ideas; not really listening and thinking you know best; or all three. So how does a project management methodology fix those things?
Techies are expected to master new skills all the time. So why is it different for PMs? It's not like they haven't had time to figure it out it. I sometimes think no-one takes project management seriously, not even all PMs.
One of the biggest issues we face is upper management not understanding things, but not wanting to be told because they are the big bosses.
It’s very hard to argue with anything in the Manifesto for Agile Software Development
(It’s never been called the agile manifesto)
https://agilemanifesto.org/
But working with those values can be difficult if you don’t have a similar stance on what they mean for your work as a team.
Scrumdamentalists and the consultancy industry around different branded flavours of so called agile are huge problems.
So how does a project management methodology fix those things?
Good question but if you cant come up with an answer then you have to consider whether you can use agile or are you just sticking that name onto something else? Its why you end up with the OP and many other devs being extremely skeptical.
I sometimes think no-one takes project management seriously, not even all PMs.
I dunno. I have met several PMs who seem to think the purpose of a project is to complete the project management tasks and tick the project management checkboxes rather than anything so tedious as delivering a working piece of software.