Slashdot Mirror
Playing Politics With Agile Projects (cio.com)
A harsh perspective on agile software development, shared by Slashdot reader itwbennett: Politicians would be utter failures as agile project managers, writes David Taber, and for all the reasons you might imagine, but mainly because they wantonly make promises they have no hope or thought of keeping. But then he gets into the political attributes successful project managers need. And that's where things get interesting because, while he points out that agile was 'conceived of as a way of bypassing bureaucracy and internal politics,' the attributes he says are required for success are pretty much the worst of the political behavior we've all witnessed in our organizations.
For example, "A key success factor for agile projects is the ability for every team member to talk expectations down at every possible juncture. Agile should inherently involve frequent 1:1 contact with users: use that time to lower expectations! Without this habit, the inevitable scope creep and the impulse to believe "of course the system will do X for me" will get you."
His submission ends with this question. "Is it any wonder why users hate agile?"
For example, "A key success factor for agile projects is the ability for every team member to talk expectations down at every possible juncture. Agile should inherently involve frequent 1:1 contact with users: use that time to lower expectations! Without this habit, the inevitable scope creep and the impulse to believe "of course the system will do X for me" will get you."
His submission ends with this question. "Is it any wonder why users hate agile?"
Different development methodologies are appropriate for different projects. One size does not fit all.
If you're doing "Agile Projects" or have "Agile Project Managers" you're not doing agile. Agile is a set of PRODUCT methodologies. If you assemble a project, identify scope, get seed funding, kick off, and then decide to delivery you're project "Agile", you've missed the key point of agile: adjust priorities in response to change.
I get why people hate "agile", it's because most people haven't done the real thing. https://www.youtube.com/watch?...
I don't think it's bad, exactly. I've worked in a shop that has been using agile for about 5 years now. Before agile, we had good releases and bad releases. After agile, we have had good releases and bad releases. I certainly *like* aspects of it, like daily meetings, limited goals, being two weeks from something shippable, etc. But my *liking* it is different from being able to prove, quantitatively, that it's much better or worse than any other software development method.
Please do not read this sig. Thank you.
"Agile" is -whatever you want it to be-, and that's part of my problem with it. There's no real normative definition that can be used to distinguish 'agile' from 'not-agile.' And whenever you push back at 'agile' asserting it is not meeting its promises, you get told "you're doing it wrong."
So at the end of the day, "agile" means not having to do anything you don't want to do (see 'technical debt')
Where I work, Agile means 50 people sit around a conference table for an hour (at least) watching the project manager fill out a spreadsheet.
I myself keep my brain from dying during this by writing limericks and praying to ancient gods for a merciful death.
writes David Taber..A key success factor for agile projects is the ability for every team member to talk expectations down at every possible juncture.
That's really dumb. The proper response isn't to lower expectations, the proper response is to give the user insight into the trade-offs of a new or changing requirement. Increase the budget? Reduce scope somewhere else? Extend the schedule? If the new requirement is more important that something else, let the user make that call.
My problem with Agile is the stand up meetings. I have been at places where they go for 2-3 hours a day, with people doing little each day, and using "Wah, I'm blocked" as a way to blamestorm and shift responsibilities to other parties. I could be doing a -lot- more with my time than hearing some other person talk about their stuff, what they did today in detail, down to how many times the HANA developer shook her weewee in the restroom, what their aspirations are tomorrow, and "what have you done tomorrow" questioning.
With 0 productivity getting done during a stand up meeting, at least 25-35% of the the day is shot to hell in the finger pointing session.
So basically, like every other corporate management fad since WWII. Got it.
I'm still old enough to remember when managers were reading ancient Chinese texts like the Art of War or Tao te ching (or rather, were reading books written by hucksters who claimed to have read the Art of War or the Tao te ching) and brought their newly-minted Oriental WisdomTM to their workplaces.
God, it sucks to have to work at a corporation for a living.
You are welcome on my lawn.
As a lead video game tester for three years, I had to talk down the expectations on the delivery schedule. The original schedule is based on what it would take for the developers to get every milestone bonus on time without any inevitable delays taking place. I usually add a month to the original schedule and a +/- two week window for code release, and my schedule have proven accurate nine out of ten projects. (The sole developer who submitted a 256-page design doc — most design docs are promises on napkins — got their video game done on time.) The developers always get pissed off when I remind them that I don't get bonuses and I'm not obligated to care about their bonuses. Most of the inevitable delays come from them trying to get their bonuses instead of fixing the problems in their code.
I absolutely agree that the Agile theory that you don't find out the requirements before you begin work is stupid. Over the medium to long term, without a plan you end up either doing work and then throwing it out three months later, or constantly working around earlier decisions, ending up with a system full of duct tape hacks. That creates unreliable systems that are difficult and expensive to maintain.
Artificial deadlines are just as problematic, however. Properly designing and building a system with certain requirements requires a certain amount of time. That can't be changed by management fiat. Regularly attempting to complete projects in less than the required time can only result in one of these three results:
A) Projects are frequently not completed on time.
B) Shortcuts are used regularly, duct tape that makes the next project take longer, while compromising reliability and security.
C) Workers are frequently asked to work long hours, resulting in turnover as well as the same problematic shortcuts as b).
Once in a while, there is an externally imposed deadline - taxes have to be filed by April 15. In such cases, you can either limit the scope and only do as much as you have time
to do, or choose from the three failure modes above.
Pretending otherwise may appear to work for a while - the product is delivered. However, by shorting time, the work was necesarily shorted - testing wasn't done, code was copy-pasted from Stackoverflow without understanding what it actually did, or perhaps to make deadline the programmers used code you have no license to use. These things will come back to bite you.
The way to quality software, reliable software that can be maintained with reasonable manpower, is to recognize that it takes as long as it takes. You can rush it no more than you can rush the growing of crops. Is this inconvenient for management? Absolutely! And the job of management is to figure out how to get the best possible results from real world, non-optimal conditions.
In fact, software development management requires talent because not only can you not dictate how long it will take to achieve a predetermined set of requirements, you can't even reliably predict it! Development is a process in which most of the work moves along at a steady pace, but the trouble spots can take unpredictable amounts of time. Yeah, that makes it hard for management. That's why management is paid five times as much as production - because they have the skills to deal with uncertainty on a significant scale.
Waterfall doesn't have analysis and planning phases?
You're just wrong, waterfall handles 'honestly new' just fine. Virtually every piece of software used was built with waterfall.
What it doesn't handle is 'constantly shifting demands', but agile doesn't handle that at all well either, nothing does. If the customer doesn't understand the problem, you have an analysis problem, no methodology will solve it.
If the problem changes faster than you can release, the best move is not to automate that part until it settles down.
Agile is just waterfall with all the roles and phases renamed and with a fixed, very rapid, iteration cycle.
John McAfee 'It was like that time I hired that Bangkok prostitute; to do my taxes, while I fucked my accountant'
God, it sucks to have to work at a corporation for a living.
Just take the money and run...
“He’s not deformed, he’s just drunk!”
I thought that, and then I thought "surely there's more to it, or why is everyone talking about it?"
And then I figured technology is as prone to hemline oscillation and varying tie widths as the clothing industry.
Confucius say, "Find worm in apple - bad. Find half a worm - worse."
That's not waterfall. That's 'off the cliff'.
John McAfee 'It was like that time I hired that Bangkok prostitute; to do my taxes, while I fucked my accountant'
Fred Brooks famously pointed out that, "If you have a small team of competent developers, any development methodology can work." 'Competent' here means largely soft skills: things like being able to plan, and reach your plan on time (or recognize when the plan will be behind schedule as soon as possible). Agile is fine, but not-agile is ok too.
Actually I've been reading through a lot of Agile consultant training lately (had to go to the training myself, too), and I see a clear divide. Some of them are focused on process.....they say, "here follow these steps and everything will turn out well." Those are garbage. The other one is focused on improving the skills of the developers, basically teaching them soft skills (here's one example). Those work better.
"First they came for the slanderers and i said nothing."
It's all iteration. Waterfall is a special case where the iteration count is one. Agile is a special case where the iterations are arbitrarily short. In some of the most successful projects, the length of an iteration is determined informally in the planning phase based on logical stopping points. The rest is largely window dressing based on the principle that all teams and all programmers are exactly alike.
Managers (especially the MBAs that have never programmed) tend to like waterfall and Agile because it lets them stick to hard fast rules. Managers that came up through the ranks and kept current will be more open to variable iteration.
I worked in an Agile house for 4 years.... and went to local Agile meetups regularly. Overall, my opinion about Agile is bit.. hmmm.. Fragile!
Firstly, Agile is good at getting half-baked products out of the door. Two (2) week cadences, where features to be build, demo and shipped is quite narrow... and you get time to barely test it. Yes, you can demo it is working, but it is the tip of the ice berg. How the feature interact with other features or infrastructure is the iceberg what's below the water surface.
Secondly, Agile is good at sweeping hard work under the carpet. For an example, because there is no centralised architectural thinking or planning, every developer goes wild and build their own architectures... half of them are duplicates doing similar functions (and not to forget, poorly tested). Things like database or API designs generally takes lot of planning and thought process. By design, Agile doesn't allow such lengthy ventures.
Thirdly, Agile not scalable. Agile works best for smaller website projects.. say 5-6 page dynamic websites. If you are to do a huge mission critical project involving 100+ templates, 20+ devs so on... Agile will fail half way point, and you will have to downgrade to Waterfall, and pretend you are doing Agile to your client... which method I christened as "ScrumFall" (after James Bond movie).
Overall, I promote "prototype, maturity and ship" model (I don't know there is an actual name for this). Basically, try out prototypes first.. if it works, then promote to regular development, and finally production. I see JavaScript & C++ language committees adopting a similar work cycle. Overall, they are doing pretty well IMO, with regular releases and good quality.
> it is impossible to find out the full requirements before you have tried putting out some code.
>... emphasis on the word "full"
You may never fully understand all of the users' needs and desires. There are three approaches to handling that:
A) Ask the user's manager what the requirements are.
B) Walk over to the user's desk and watch them work for 30 minutes, asking questions.
C) Guess, then build the minimum thing that might address some of the requirements.
It's well known that option (a) doesn't work. It's frequently tried, and rarelt effective.
With option (b), I might get 90% of the requirements up front, and have those in mind from the very first moments that I start thinking about a design. I'll also get a rough idea of what categories of additional functions or requirements may come up in the future. Often, I see how the requirements could be simplified by removing a redundant or unnecessary part of the existing process. The point is, I get 90% of the requirements up front.
With option (c), you design and build something that meets 10% of the requirements. When you try to deploy it, you learn about another 10%. So you scrap it and build something that meets 20%. You try to deploy that and learn about another 20%, so you shove twice as much functionallity in wherever it will fit, creating a bit of a mess. You deploy that and find out about another missing 20%, so you pile that 20% on top. Then you learn that the 40% that's still missing is the important part, so you rip out the guts, keeping the gui, and shoehorn the new guts into the old gui. Now you meet 80% of the need - still less than the 90% you could get the first time by sitting down and watching users work before you design anything. And your 80% code is an unholy mess from shoehorning new stuff in at each stage.
You really really don't want some SCRUM team messing around with those.
And yes, Agile is superior to Waterfall when it comes to adapting software to en-user requirements that can be accommodated within the constraints imposed by architecture and application-server and application-application interfaces and have only "local" implications.
It absolutely helps if coders can talk to their users directly instead of through a layer of architects, analysts and designers. But you have to constrain what they can talk about.