At the BBC, Agile means 'making it up as we go along' A £75m “Agile” BBC IT project has evaded scrutiny because managers could make up the benefits as they went along, according to the spending watchdog the National Audit Office. Any likelihood of the project achieving savings is now officially rated as “in doubt” by the BBC’s own project monitoring. Since the costly failure of …
Yup, there must be broadcasters the world over who envy the BBC their ability to piss away the odd £75m - £100m without risking anyone's job.
Look at the timeline for this project and they started it almost at the same time as the Digital Media Initiative collapsed in on itself.
So they definitely learned a lesson, though probably not the one we were hoping...
>Yup, there must be broadcasters the world over who envy the BBC their ability to piss away the odd
>£75m - £100m without risking anyone's job.
The BBC is just another in a long line of public bodies or governmental organisations or the government itself that prove its very easy to spend someone elses money and not have to worry about being accountable to anyone about it.
"Well all this money squandering will cease when the Tories force the BBC to publish how much money their on screen talent get paid."
Which will happen shortly after we find out how much the relatives of MPs get paid for all those directorships and so on. Remember how "commercial confidentiality" is used to prevent us from finding out how much privatisation is really costing us.
Well all this money squandering will cease when the Tories force the BBC to publish how much money their on screen talent get paid.
I would suggest that the squandering will only cease when it is the off-screen talent that has salaries published. The on - screen talent cannot be held responsible for this sort of debacle, however much it is paid. If the off-screen talent is allowed to keep its collective head below the parapet then the process is almost certain to be repeated.
Public sector project traffic lights - an insiders guide
Green - This was something that already existed but we changed all the fonts - delivered only three years late and at double the budget - trebles all round!!
Yellow - It will never be delivered but no-one has yet noticed - this gravy train is still open for relatives and friends to get their bit
Red - oh fuck - we're going to need a scapegoat - where's that work experience bloke we send out for the lattes
In every instance I've seen an agile sprint or whatever run by a non-dev, it is just waterfall on a shorter time frame. Rather than one big drop, you get sequential pratfalls (or concussions) as you move along to the same inevitable conclusion.
Most people simply don't get it. I've even had to put up with management types saying how agile will remove use from the Cost-Time-Scope triangle. SMH.
"Give me a waterfall any day, at least it makes people admit when they're going off track."
I can't see anything in waterfall that makes people admit they are wrong. If anything, waterfall delays the realization of what is wrong until much, much later in the cycle, when sponsors/stakeholders/whatever you want to call them start QAing the final product. At that point in time the biggest share of project resources have already been burnt and people fall to the sinking cost fallacy: it is too late to admit anything wrong.
Yeah, you can attribute that as a problem with improper design and planning. But let's face it: given enough size or complexity, most people are very poor at being able to describe something they want built in abstract terms, that's why brick and mortar architects build scale models. So what Agile does is recognize this very human trait and assume that the customer will change its mind along the way. And the sooner that happens, the better because less resources are wasted in something useless.
Don't blame this on Agile, because in these contexts Agile actually mitigates the risk. Agile may produce deliverables that are weak in some other dimensions (architecture, integration...) but if the customer focus is kept, Agile will at least deliver something useful quicker and cheaper than waterfall.
"Don't blame this on Agile, because in these contexts Agile actually mitigates the risk."
It mitigates one risk and creates another. Agile is just another name for goalpost moving which if done often enough is the kiss of death to any project as what you'll end up with is an inefficient, poorly written disaster which isn't so much released as booted out the door with a prayer.
Its a well known fact that customers will always change their minds given half a chance - well you don't give them that chance. You nail down the spec BEFORE any work is done, get them to sign it off and get to work. If they change their minds tough - they either stick with the spec as is or cough up more cash and put up with a delay. Besides, they'll probably change their mind back again anyway before the work is complete.
@Boltar, you're living in a world where software is "finished". That world is 1990 - Agile addresses the fact that software isn't finished and never will be. Someone above mentioned architects for buildings building models. That's not the end of the story, speak to a real building architect and you'll find they make changes right up until the end of the build, as do the engineers and builders. Architect says 10m wide room, engineer says 9.5m is all we can achieve, builder says he built it 9.6. Every other industry accepts adjustment, ours is based on personalities who reject change in the false hope that we can control things. That's one reason IT often fails, and certainly the reason big projects never complete. If you spend too long locking down the spec you'll never even find out what you're wrong about or don't yet know. If you at least start with what you do know you can learn as you go. Every "engineered" project I've ever seen has delivered something different to the design without exception, all Agile does is recognise this and allow you to learn some of the facts as you go, the same as you do with waterfall but without the massive delay before learning the lesson.
>@Boltar, you're living in a world where software is "finished". That world is 1990 - Agile addresses the
>fact that software isn't finished and never will be.
Rubbish. Software is often finished and a customer isn't heard from again for years because they're happy with what they've got. Even where software is part of an incremental upgrade, in a PROFESSIONAL enviroment (which precludes most web companies and startups) you still have projects with milestones and deadlines, you don't change the spec on a daily basis or suddenly switch tasks to something some suit has decided is more important this morning. The only time a spec should be changed once formulated is if a major issue appears and needs to be worked around.
"Every other industry accepts adjustment, ours is based on personalities who reject change in the false hope that we can control things"
ITYM personalities who expect the spec from the BAs or design engineers to be correct and are concerned about changing things on the fly since this can lead to unintended consequences.
"f you spend too long locking down the spec you'll never even find out what you're wrong about or don't yet know. If you at least start with what you do know you can learn as you go. "
Jesus christ, I seriously hope you never get a job in any industry where safety is paramount. I really don't want to fly on an aircraft where you've designed the avionics where you "learnt on the go".
You're everything thats wrong with modern development.
@Boltar, you not only make incorrect assumptions (software is never finished, if only because it always has bugs. Whether your customer(s) bother to ask you to fix them is another matter. Unless of course you claim to write bug-free software, in which case I'd suggest you apply for a Turing award/Nobel prize) but you're also confusing "engineering" with "development"
Going back to you analogy, I hope that you never get involved in developing a new product or device. Think going ten years back and try create a "social network" site or a site for "sharing videos" or a "100.000 node cluster to compute search results" The people building those had no idea of what the final result would look like and had to learn on the go and make changes as necessary to accomplish what they wanted. By the way, just as people developing avionics had to learn iteratively what works and what not. They took the knowledge they had and tried to apply it to the job at hand. Some if it worked, some not, and as a result they learned new ways of doing things.
All this may not apply to the article's specific topic, of course, which looks like yet another case of "big waste of money because nobody had a concrete idea of what they wanted"
"Going back to you analogy, I hope that you never get involved in developing a new product or device. Think going ten years back and try create a "social network" site or a site for "sharing videos" or a "100.000 node cluster to compute search results" The people building those had no idea of what the final result would look like"
Apples and oranges. Blue sky R&D is something you do in your own time, not the customers time. Google and social networks didn't have customers to start with (arguably the latter still don't) so its hardly the same thing as writing some software for a customer who has specified the functionality.
"Jesus christ, I seriously hope you never get a job in any industry where safety is paramount. I really don't want to fly on an aircraft where you've designed the avionics where you "learnt on the go"."
Funnily enough it's experience in safety critical environments which has given me this view. They are some of the worst for spending far too long engineering and then starting the project only to retrospectively change everything because of unforeseen requirements. Prototyping is a thing and should be considered in any engineering toolkit. Locking down the spec is a good idea, but only a fool would rule out future changes where needed. The ultimate goal rarely changes but the approach to that goal must be allowed to change if it makes sense to do so.
"Its a well known fact that customers will always change their minds given half a chance - well you don't give them that chance. You nail down the spec BEFORE any work is done, get them to sign it off and get to work"
You are either very lucky or working in a very narrow field, health care or defense perhaps? Rest of the world experience is that if you try to nail down a spec so tightly you won't find many people willing to sign it off. And if/when they do, that only means that negotiating change costs is going to be a nightmare.
It is much better to do short iterations with something usable (even if not perfect) at the end of each cycle and allow them to tinker and change whatever they want, under the full understanding that each of these tweaks means adding cost, time or both and allow them to prioritize these changes. Yes, you may have to sacrifice architectural cohesiveness or cleanliness, but at least you're delivering something usable, and thus, able to generate some return.
if the customer focus is kept, Agile will at least deliver something useful quicker and cheaper than waterfall.
You could say the same for projects delivered by an enthusiastic summer intern.
The problem is not "useful" but "supportable and maintainable"
"Don't blame this on Agile, because in these contexts Agile actually mitigates the risk."
There are plenty of situations where waterfall simply won't work because by the time the project is done it will be hopelessly out of date, F35 <cough>. Been there, done that.
My objection to Agile is the bits which seem designed to enable salesmen, buyers and senior managers to bamboozle one another with uncomprehended bullshit. The pseudo-Zen terms like "Scrum master" somewhat infuriate me. Compare that with the lucidity of the business school terms - CFO, CEO and so on are so easy to understand and remember. It's a job, not a religion.
"Don't blame this on Agile, because in these contexts Agile actually mitigates the risk. Agile may produce deliverables that are weak in some other dimensions (architecture, integration...) but if the customer focus is kept, Agile will at least deliver something useful quicker and cheaper than waterfall."
True. It is equally possible to blame both Waterfall and Agile entirely fairly.
But NOT when either the methodology has been adopted in name, but not in practice. For example: Just as Agile does not (always) mean making it up as you go along, neither does Waterfall mean "not doing any testing until the thing is finished". True waterfall is an iterative process, not a sequential one and there is nothing in the methodology that says everything has to be delivered at once, only that things that are delivered have to go through a series of (iterative) checks and balances on their way and some of those checks and balances will ensure that the deliverables work together as a whole when they form part of a larger system.
Agile on the other hand is a manifesto for ignoring the bigger picture. All too often the focus lands squarely on the MINIMUM in "Minimum Viable Product" to the detriment of longer term viability. But it's "Agile", so it's OK. It's a process. A methodology. So even if it FEELS like we're just making it up as we go along, it's all going to be OK in the end. It's an OLOGY.
The real problem is mis-applying the methodologies. Neither is a Magic Bullet to solve all your problems.
You don't built a high-rise apartment building using Agile. You have to do a lot of up front work to establish and prepare the ground you are building on not to mention determine the quantities of material and the schedule of trades required to erect the thing (it's no good bringing in the plumbers before the foundations are laid). And once you have planned your elevator shafts, ventilation and other utility conduits any changes will require a comprehensive review of the impact on the building.
Waterfall is the way to build a skyscraper.
But once the building is up and it's time to start fitting out the apartments inside. Well, you might have settled on a nice faux granite panel effect on your walls but once it goes up you can change your mind and swap it out for an oak panel. Polish the concrete floor but then decide you'd like carpet or a nice wood floor instead.
Agile is the way to do interior design.
(You probably won't have much luck trying to move the bathroom though).
Deltics "it's no good bringing in the plumbers before the foundations are laid"
But some plumbing does have to be done before the foundations get poured. OK, probably closer to drainage, but some pipes go *under* and through the foundations. Especially if it's a concrete slab.
Which is probably emphasising the point that no single methodology covers the big jobs. And it's the big jobs where the money can really be pissed away.
But have an upvote for the general thrust of yr post
Waterfall is not a process. It is only a theoretical model out of many described by Dr Royce in an IEEE paper about managing complex software development projects. He himself dismissed the model as being far too risky for any but the simplest of projects.
Agile will at least deliver something useful quicker and cheaper than waterfall.
Agile will[1].
The bullshit that so many claim to be Agile will not...
Vic.
[1] This isn't actually true; the Waterfall model as originally described by Benington had feedback loops within it, meaning it really doesn't differ much from Agile. But the Waterfall model is as mis-represented as the Agile model, albeit generally with less-serious consequences.
Isn't the main issue here that whatever you want to call your process, if it's not working, it's not going to produce anything useful.
If you can't pin down either some requirements, or a group who can at least review the product, then you're fucked, whatever methodology. Agile, waterfall, spiral et al all rely on some part of either having a clear idea of what you want, or someone who can tell if it's what they want (even if they didn't know beforehand).
It does seem that there is a distinct pattern of people not being able to make projects work for reasons that are fundamental to the organisation trying different methodologies when the issue is the company itself. Using a methodology to hide the fact that no-one is making correct decisions or designs isn't the fault of the methodology.
It's also a bit sad to see that almost every "Agile project fail!!!" is actually a failure to implement Agile methodology, and that leads to the tools being blamed, not the workmen. It's supposed to generate documentation as you go along, but the number of times I hear "we iz agile, we don't need no steenkin' doco" is scary. You are supposed to build and refine requirements, not just assume the customer* doesn't know and can never know them.
It also varies a lot by industry. Groups that are used to thinking and planning well ahead (power, utilities, construction, mining etc) can be a hell of a lot easier to work with than charities, arts sectors, and worst of all government departments. Legislation is magic you see, and can bend physics, time and anything else you wish by passing a law or writing a memo :)
Oh, and anyone insisting they've managed to break the iron triangle** is like someone selling you a money printing machine/free energy device. If what they had worked, they'd never need to sell it, and could just become successful by using it themselves. SW development methodologies improve these, making work more efficient and effective, but you can't suddenly create quick+cheap+good. Agile *should* give you quick+cheap, and allow you to assess these for what is good, then repeat. Planned should give you good+cheap, but speed depends on how well known the problem area is.
* inevitably there are people at the customers end who do know what they need. They are usually too busy/useful to be at any requirements meetings, or several layers of manglement have inserted themselves to ensure chinese whispers can destroy the useful information.
** Well, you can. Sort of. If you have teams of domain experts and excellent developers for a slow changing system it's somewhat possible to achieve an optimal solution, if rather inflexible.
re: Give me a waterfall any day
I'd rather have something more like Barry Boehm's Spiral model. Make risk management part of the culture and try to tackle the biggest risks first. Like maybe, you know, in this case they could have thought "let's try to pin down requirements because right now we really don't have a clue."
In theory, I guess Agile is supposed to be some sort of successor to the Spiral model, but as someone else mentioned, it just ends up with lots of little waterfalls and no overriding sense of direction. It seems that some sort of magic is supposed to happen because "tools" or "teams" or "continuous delivery" or whatever. So much (under)pants (gnomes), I say!
Give me a waterfall any day, at least it makes people admit when they're going off track.
My Team uses Escher Waterfall:
https://en.wikipedia.org/wiki/Waterfall_(M._C._Escher)#/media/File:Escher_Waterfall.jpg
It always looks like it's going great, but .....
"How is this is different from most other Agile organizations, exactly?"
In the real world if you do a bad job there are consequences. At the BBC it's business as usual. I too would behave like them if I had a bottomless pit of money and could do whatever I liked with it.
Not sure what those consequences are, in the real world.
In the real world it's perfectly acceptable to piss away $100m and keep your job, just ask any investment bank or multi-national, who are absolute masters at hiding failed projects from anyone who matters. It is only in the UK government where the PAC asks tricky questions.
One of the great things about Agile development is that if you get your contract right, you carry no responsibility whatsoever and are in effect a T&M development with the customer carrying the can for not giving you a realistic development target, and properly planning your sprints.
In the real world, it doesn't matter what method you use, provided that the client has a clear and well articulated requirement and a realistic timescale, but they never do. Making it up as you go along doesn't work for anything for very long.
@jack
In the real world if you do a bad job there are consequences.
Oh how naive you are.
I've worked at a number of big corporates and I can assure you that the execs never get the consequences they deserve for failure, at very best they leave after years of the gravy train, only to move to the competitor down the road and repeat it all again. I don't see why we expect the Beeb to be different.
"In the real world if you do a bad job there are consequences. At the BBC it's business as usual."
Actually, I'd argue that this is the case at any sufficiently large organisation. Once you're got too many people for any one person to keep track of then you've got opportunities for shenanigans.
Even in small organisations I've seen a manager screw up and waste loads of money, but still get a pat on the back because they were mates with the boss.
> And how is this is different from most other Agile organizations, exactly?
Well, call me old-fashioned, but I thought the benefits case was supposed to be made before the project starts, regardless of how the project is intended to be run if it gets the go ahead.
>Well, call me old-fashioned, but I thought the benefits case was supposed to be made before the project starts
What I love is there are some real jagoff MBA in IT types posting on here that often accuse developers of not caring about the business or whatever when it tends to be management and people like them why projects that are useless to the business get green lit, go off track etc. Developers generally do what they are told.
Well, yes, you make the most common mistake of saying "Agile" when perhaps you mean "agile". The latter meaning the weasels, agile as they are, will have weaseled off before anyone who does proper project management will have noticed.
"Agile", adjective, quick and well-coordinated in movement - describes the path of your cash.
All very well, but those BBC chappies with 6 figure salaries are highly influential (probably due to the dirt that the Beeb has on various politicians). If TV licence revenue drops too much due to people streaming all their content rather than watching off-air, the law will simply be altered to make a licence mandatory for streaming as well.
IT projects with poorly defined scope, over-promising and under-delivering?
Maybe they should developed RESTful microservices implemented using component-based sub-systems on an object-oriented paradigm, hot deployed using a loosely coupled devops process on a high-availability cloud infrastructure.
"Maybe they should developed RESTful microservices implemented using component-based sub-systems on an object-oriented paradigm, hot deployed using a loosely coupled devops process on a high-availability cloud"
You're not going anywhere these days without adding BIG DATA to your buzzword set.
"Maybe they should developed RESTful microservices implemented using component-based sub-systems on an object-oriented paradigm, hot deployed using a loosely coupled devops process on a high-availability cloud"
"You're not going anywhere these days without adding BIG DATA to your buzzword set."
And surely we've moved onto a "post object-oriented paradigm" by now?
I've had lots and lots of people tell me they do Agile, or they're all about Scrum, when what they mean is they read a book on it once and loosely agreed with a few of the concepts that they could contextualise at that time.
Agile is great and so is the notion of really delivering benefits, but it's not easy and companies the size of the BBC won't manage it for at least another generation.
That doesn't mean is Agile is wrong, bad, or a bullshit buzzword. It just means there's a whole lot of arseholes out there. Who knew!
It's also not an excuse for not defining the long-term aims of a project. Any project that doesn't do that will fail badly whatever methodology or technology is employed.
I've always thought that the point of agile was that the iterative development and feedback loops help get the details right (because you can't imagine everything at the start) and guarantee that at least something will work.
No it doesn't.
Whatever the original intentions - in my experience it ends up as an excure for management to micro manage a project (scrum every day to keep tabs on the team who are treated like schoolkids unable to function without daily direction, not IT professionals) and do the three bags full routine to customers who can't make up their minds.
Agile is a f***king joke.
> Project managers report faster and more often
Neither of which does anything to improve the accuracy of what they are reporting. I am reminded of a piece from a comedy sketch (can't recall which genius of comedy it was), that went a bit like this:
They gave me 2 weeks to answer a very difficult problem
I said I could give them an answer straight away
They asked me what my answer was
I said "I don't know"
speed of reply is not always what you want.
I've lost count down the years of the number of new and revolutionary project methodologies that have come and gone.
All they're fit for is giving each new generation of business analyst foetuses a job.
You carry on kids, the rest of us will just be back here, quietly continuing to keep the lights on.
I've found the last thing managers seem to want is someone below them who actually knows what's going on, what's really needed* and how to get things done. But then I've had the miss-fortune to work for managers trained as managers and rarely a manager who would understand when the water was pissing off the side of the waterfall or if familiar with the term Agile would tie your hands to the chair so you couldn't quite reach the keyboard.
I must confess the work I have been proudest off and most useful has been written outside the office, or on several occasions during meetings as I've found the only way to get the job done is to do it and not have some buzzword mangler reinterpret the laws of mathematics to find eleventeen solutions to a quadratic. It requires a bit of subterfuge to get it in but the think I really like about agile computing is you can sometimes get to sit down with the customer and say ' I know we've had thirty six meetings trying to build this vastly complicated piece of software but I wonder if what you really want to do is this.....' and then you have to hold on to your chair very tightly while there is a bloody massive earthquake.
Oh and you will probably get sidelined after that as the customer will still want you on the project but the manager will refuse to let you near anything in case you make a complete fool of him again.
*the customer is never right unless they have 35 years IT experience.
In recent years the cultish Agile development methodology has fathered a buzzword that dazzles non-technical management. These days it adorns many Whitehall press releases, even on non-technical subjects; you have to call a department or initiative "agile", even if you can't define what that means.
Isn't being unable to define it the whole purpose of using the word in the first place?
"Isn't being unable to define it the whole purpose of using the word in the first place?"
An agile department or initiative is one with sufficient mobility that, when the shit hits the fan, it turns out not to be in the vicinity. Like those executives that move from job to job just slightly faster than their incompetence catches up with them, reaching the very highest levels without actually ever having done anything that worked, and wafted upward on a column of hype, hot air and knowing the right people.
You KNOW you want this!
Here's how to do the Agile Process:
1) Say you've "worked at Agile shops previously", then start kicking the terms back. Such as, "hey, what kind of coffee do you want at the Scrum?" and "Hey, bring that box of (US: donuts, UK: scones, *:muffins) with you the Scrum, guy!", and many, many more!
2) Reset your work schedule and life to fit the size of Sprint; this is usually two weeks, but it can be anything from 2 minutes, right on up to two centuries.
3) Ask a bunch of questions relating to the process, like; "Hey, who's the Scrum Master?" and "These Sprints taste DELICIOUS!" also, "My, your looking Agile today, Mr. Boss. Is that a new Scrum you're wearing?" and many, many more!
How agilely resources are 'consumed' at those external contracts! But don't feel bad. Quite the mode at Governments, also.
"The problem is then trying to run such an exploratory effort when management are fixated on SMART...". Agreeing with Matt, problem use to be a bean-counter Management.
That project should be tagged as exploratory, and keep the regular maintenance expense, also.
Is this the same as "Knock out something quickly to get Marketing off our backs!"?
Back in the day the longest time to deliver a "product" was always 6 months because that was as far forward as Marketing (the customer) could see/think.
Saying "It will take 18 months to deliver and test that." would never get approval.
Taking 2 years in 6 month chunks however seemed fine.
I realise that in Agile you probably need to substitute weeks (or even days) for months.
Sorry but, IMHO,this has nothing to do with "agile" and a lot to do with staff trying to work around senior management controls. In the old days we would have called it a "blue sky" project or a "skunkworks" gig - something that was intended to explore an expected future requirement that couldn't be clearly defined. The idea is you risk wasting resources on an endeavour that may actually return nothing of "benefit" (usually determined by management as benefit=profit) in the hope it at least gets you ready for what you may need to face further down the road. That type of project is very unpopular with the beancounters as it is usually impossible to define either the scope nor the likely costs involved with accuracy, and definitely not the fiscal benefits. The problem is then trying to run such an exploratory effort when management are fixated on SMART (specific, measurable, assignable, realistic, time-related) without having the scope of the exploratory work hampered by deliverables and deadlines. In essence, it is the most "agile" you can get, with an emphasis on prototyping to see what you can actually get to.
In science this is called research, and a lot of it actually makes a loss and is unsuccessful, but when it succeeds it leads to real breakthroughs and major profits. The problem is the majority of MBA types can't see beyond their profit-and-loss spreadsheets long enough to see the real benefits.
What could possibly go wrong in a model where the "customer" is told to pay, "or else", for just having a TV? And then all this jucy money with no strings attached has to be spent somehow. And every year the same "customers" are told again to pay, "or else".
At least with Sky I can look at the total cost (once the introductory offers have expired), and say "f*ck that"!
Now when BBC couldn't even hang on to F1, and the only thing of value left is 90 years old, I don't really see any point in paying for it. I can just buy the DVD/BD of the one or two things I want to watch (there are so many variations of XYZ Planet that I can't even keep up any longer anyway).
This post has been deleted by its author
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
