""I think from a tactics perspective, Agile is increasingly a 'solved problem'," said Forrester's Jeffrey Hammond when asked to demonstrate how completely industry misunderstands the core concepts of agile."
After roughly 20 years, agile software development has wheedled its way into most every developer's mind as The Way Good Software Is Done. Like flossing, while we can all agree agile is a good idea, we're not quite up to snuff on keeping all our teeth in our heads, so to speak. A recent Gartner survey [registration required] …
"As most of the people who develop software find, however, very few people know exactly what needs to be built ahead of time, least of all the actual users and customers."
Erm...to a point but I've got a few ranting points on this about why waterfall has a bad rep
1) More often than not so called requirements are simply vague notions and ideas of in the head of some user*. There actually isn't much in the way of empirical research or data to support the requirement apart it seems like a good idea.
The most recent example I've had "our new online shop must allow discount codes to be applied to the shopping basket". Putting aside the mechanics of it for a second (which havent been at all thought through), if you ask the question why does the shop need to do that, i.e. what are you hoping to get from that feature - the person looks at you blankly and basically says "because". Normally the "because" is they've read it on a Gartner blog and its what everyone is doing*.
2) Often businesses want to see something created as quickly as humanly possible with minimal cost/effort/disruption. So when Waterfalling, the requirements engineering and testing phases are always compressed to be short as humanly possible because it doesn't deliver *anything useful* and is disruptive on user's time. How many of us have been in situations where the users try to use the testing phases to deliver new requirements?
So in round agile sounds perfect...but wait you're never given time to iterate the MVP to keep adding all those vague requirements. Many of the projects given to me have finite end points where you have assigned something else completely unrelated.
In a nutshell management want you to be "agile" but only in the sence of working faster/harder/longer, the end users want you to telepathic and turn their vague ideas into requirements. So you are left with a broken waterfall project lifecycle model, descoping everything and upsetting the users because their next best idea doesn't materialise.
I know above is preaching to the choir but I need to share my burden...
"testing phase", is that the bit where you ask the customer if they've bothered testing the new system you've developed and they say "yeah, looks fine", so you go ahead and deploy it to production, only to get a phone call five minutes later saying "it's all broken". You ask why they didn't bother testing that bit and they say "I thought it would be ok".
Because I find that pretty testing...
@phuzz Try that one on bl**dy GDS testers.
ME: "But you know I moved this in Jira from Development Complete to UAT and you moved it to Completed, so why are you saying it didn't work?"
TESTER: "As far as we were concerned the App did exactly what it said it does"
ME: "But, did you actually go to the UAT test server URL to see if it was working or not?"
TESTER: "Err. Actually no, we didn't. Should we have?"
"...our new online shop must allow discount codes to be applied to the shopping basket.."
Wait just a minute there cowboy. What do you mean you can't support discount codes in the shopping basket? Pfft.
Next you'll tell me that this so called "shopping cart" of yours doesn't support language translation into Sentinelese. Or that it doesn't just fix the credit card entry transposition errors that people sometimes make. Or how about a Zero-Click feature where the site figures out what the user wants, puts it in their basket, and automatically fills out all the payment details and submits the order for them?
The UK golden rule of late night deliveries:
1) The pizzas must always taste the same, except where someone (and there is always one) has ordered the Hawaiian special so you get the taste of grilled tinned pineapple.
2) Chicken wings, nuggets, fillets in breadcrumbs or BBQ ribs might look different but always taste of the same sickly, sweet BBQ sauce, and always arrive cold/lukewarm.
3) Nobody ever delivers CocaCola. For some bizarre reason it is always Pepsi at room temperature.
4) The person who ordered the Pad Thai is usually the most smug, right up until they realise that the pork still has hairs on it.
Given the eating habits of every coder I know, that rule means teams of two, maybe three.
Certainly not twelve.
But no matter, there is only one way to develop : ensuring that you have the input of all people that matter to the project.
Mind you, that doesn't mean all the people listed in the project manifest. It means all the people that matter to the project's success. The key users who can express what they need and how they can use it, the db admin for access and optimizations, the network engineers for traffic analysis and routing solving, and on the side, the manager for specifications and for knowing who to keep away from the grunt work in order to prevent stupid ideas.
Well hold on with the criticism. The piece suggest that a DevOps team do everything themselves. That's a recipe for rank amateurism that will end in rubbish. If you're building software for a vending machine, that's fine. For anything more complex than an 'app' (how I detest that word), it's not. There are centres of expertise in most large shops for good reason - it takes time and experience to get expertise.
I work in the mythical team of twelve in a company of thousands. What do I know about MQ? Next to nothing - just enough to ask the right questions and go to the right people. What do I know about DB? A fair amount, I used to be a DBA, but I am no longer current because that's not my primary focus now, so for anything complex I go to the DBA team. What do I know about Ops? Lots, I used to be in ops... er... 20 years ago... that's a fat lot of good now...
Ongoing development and a version of agile can work. But for most of my experience, you can use waterfall (AKA knowing what you want before you start) but no-one wants to get off their backside and create a decent set of requirements. They don't want to talk to users, they don't want to listen to other opinions, they want their favourite technology and they want to play.
'Agile' lets people do this and nudge it into usefulness. Yep it has some useful attributes and waterfall isnt everything, but if you dont know what you want you end up with a brittle unclean solution.
but if you dont know what you want you end up with a brittle unclean solution.
I think this applies whatever methodology you follow and is true of most projects.
You won't know all the requirements at the start so a regular release, test, feedback approach is inevitable. Good project managers will be the ones who can spot bottlenecks, blind alleys and fucking stupid ideas early on. And, of course, how to compromise when key aims (features, timeline) are in conflict.
Communication is important but mustn't get in the way and needs to be between the relevant people. Meetings should be constrained by the size of the teapot: 4 or 5 mugs at most; brown jenny on special occasions.
This could all be called common sense programming™ but without a fancy name, gurus and expensive certification courses it'll never take off.
"Meetings should be constrained by the size of the teapot: 4 or 5 mugs at most; brown jenny on special occasions."
With experience I learned not to be upset by the size of the original meeting. A quick look round inevitably showed the following:
A few strangers, sent along by someone or other and looking slightly dazed.
The occasional known trouble maker.
Two (seldom more) other people who'd helped do the work on other projects.
Once the formalities were done, just work with the last lot as before, but sound out the first lot as some of them might actually know what's what.
".....I think this applies whatever methodology you follow and is true of most projects....." No, no, no. Agile just panders to the coders' desires to "just get coding, we'll make it fit later". If you employ someone with a clue you will get both good requirements plus a contractual financial penalty for the galloping goalposts that agile encourages. Nothing like the threat of added costs to focus the customer's minds on getting the requirements done correctly. If you are going into development with poor requirements then you are (a) going to waste a lot of time continually prototyping and rehashing, and (b) probably not spending enough money on the analysts/consultants you hired to gather the requirements in the first place.
If you employ someone with a clue you will get both good requirements plus a contractual financial penalty for the galloping goalposts that agile encourages.
Yes, because all of those massive waterfall projects always get the requirements right and never produce overruns.
Once of the biggest fiddles in software development is to draft a seemingly complete specification based on what the customer thinks they want and then force the customer to sign-off on increasingly expensive change requests as it turns out that the specification wasn't actually what they need.
Any contract that doesn't include some degree of iteration is just as doomed to fail as one that is based on unlimited iteration.
"knowing what you want before you start" is also pre-requisite for agile development. It ls usually called "use cases", the difference from formal specification in waterfall is that it focuses on "what it needs to deliver" rather than "what the design should look like". I find that the focus on the former (as opposed to the latter) tends to drive projects such that they often meet users' needs, not sure know why ...
You can define requirements how you like. Words, lines in an Excel spreadsheet, in DOORs, using UML, SysML an enterprise architecture, whatever. The point is the maturity of these. A lot of Agile seems to be, 'Don't worry too much, we'll figure it out when we get feedback after delivery'.
I suspect you're confusing a project and a web-project. Requirements can be functional (what it does) and non-functional (what it looks like). What the design looks like is the human interface part - you can't define this before you know what information you're trying to exchange with a human.
By the way, use-cases suck and are a fundamentally bad idea.
the difference from formal specification in waterfall is that it focuses on "what it needs to deliver" rather than "what the design should look like". The specification should always focus on what it needs to deliver for all methodolgies. A good specification is an essential requirment because without it how does anyone test whether the system is working correctly? Most agile projects seem to think a good specification is not needed.
My experience of agile is when 'successful' it is becaus the agile evangalists have managed to convince those that matter that what would have been considered abject failure, huge delays, fragile SW, massive overspend, final SW which does not deliver key functionality, constant bug fixes as being an inevitable part of the process.
What the F**k are you talking about?
I've seen scrum masters totally mess up a project because of the way they implemented their version of Agile. It was anything but Agile.
to me and from my experience
Agile should be renamed Fragile if any of the requirements are unclear.
It is a good way to burn through lots of money without actually delivering anything. Just like 99% of HMG's IT projects.
Done right it can work but this seems to be the exception rather than the rule.
Me to one scrum master,
"And no, I don't want to go to every standup. I actually have some work to do. I've done all my work on your project in sprint 1. When you are ready to use the stuff I developed, let me know."
Yours, an old dinosaur who has been coding for 40+ years and can still teach these youngsters a thing or two.
"an old dinosaur who has been coding for 40+ years and can still teach these youngsters a thing or two."
yeah I like your rant against this 'Agile' thing, which I've only seen ABused. meeting, after meeting, after meeting, and a year (and 400 direction changes) later, they're *STILL* using the prototype I hacked together BY MYSELF in 3 weeks [and spent maybe a week's worth of intermittent time making fixes] to DEMO THE PRODUCT's CONCEPT to prospective clients.
4 weeks' worth, done by me, by myself. OR, a YEAR by a team of 3 [one manager, one 'programming pair']. I was NOT in on those meetings. They knew better. I was working on OTHER things. After the layoffs, I assisted the more senior guy in FIXING IT UP so it would actually WORK "as advertised".
yeah, NOT a fan of "Agile". Analysis paralysis, meetings in lieu of actual work done, and "the junior guy" *ALWAYS* gets HIS way, because it's not FAIR to exclude junior programmers and their impractical [reflecting their extreme inexperience] ideas.
You want a team to work on something? DESIGN THE 'CONTRACT', then implement to it. Separate duties so nobody steps on anyone else's toes. Then, MANAGE the programmers by periodically asking "how's it going?" and "when will this be done?". then, solve the problems as they show up (you know, like CLASSIC management, not this "touchy feely" garbage).
You do know that Scrum and Agile are different things don't you ? Scrum is a framework whilst Agile is a methodology
Whilst the Scrum framework can be applied to Agile methodology they are not one and the same.
Also sounds like the the scrum master you refer to either does not understand "stand ups" or did not explain it to you. In essence it should comprise just 3 questions:
1) What did you do yesterday ?
2) What will you do today ?
3) Is anything stopping you doing what you need to do ?
Sounds like your answers should have been:
1) Work not related to this sprint
2) Work not related to this sprint
3) Standing here listening about a sprint I am not involved in
"....Whilst the Scrum framework can be applied to Agile methodology they are not one and the same....." Unfortunately, my experience is that is exactly how coders seem to see it, that "Scrum" = "Agile" and anything else is unimportant. Worse, they often seem to think Scrum removes the need for any other process, especially proper requirements gathering, roadmaps, or just basic planning.
It's amazing - I've worked at a handful of places that do "Agile" but none that do Agile. If you see what I mean. At the best it's waterfall with dithering.
My current place does "scrum" - an hour long meeting in the pub every other Friday.
this looks like a PRACTICAL approach, not a hard-line stick-to-the-definition approach. Isn't that what we REALLY want?
I've never seen pure 'waterfall' design. Normally things are done "top down", that is 'definining the spec' but the spec CAN change if it's necessary. It becomes more difficult as you go further along, but if you need to change an API before it's published, that should be fine. If you need to change it AFTER, you have a 'compatibility' version. I think APIs have been managed like this for as long as they've existed. So you have to think *REALLY* hard about "that kind of design work" before you actually implement it.
But you could still be 'agile' without diving 100% into the concept known as 'Agile'. So your comment about 'waterfall with dithering' makes sense.
And, it probably ships product ON TIME and UNDER BUDGET. then you can work on 'Rev 2.0' (that deals everything you COULD still be working on if you'd done Agile, but you wanted revenue from sales of 1.0 didn't you?)
AND, bi-weekly "scrum" meetings at the local pub, yeah. In my part of the world, it might be an actual BREWERY.
In my experience the methodology you choose matters less than the having good management of a project. I've seen "agile" used as an excuse by a customer to bugger about with requirements, changing what's important from week to week and pushing out development until the project overran massively. If that project had had decent requirements established at the start then that wouldn't have been possible.
If you start a project not knowing what you're making then often you end up with a sprawling mess of unfinished features. I worked on something like that recently, no one could tell me clearly what the software was supposed to do (a couple of days into the project I was working on a ticket and asked the tester who raised it what the desired behaviour was, "What do you think it should do?" came the reply.) and instead of fixing the bits they had they were just continually adding more badly thought out half functioning "features".
Good management is required to develop good software. Unfortunately it's much easier to get concrete metrics on the ability of an engineer than the abilities of a manager, I guess that's why so many of them are not very good.
"....If you start a project not knowing what you're making then often you end up with a sprawling mess of unfinished features...." Totally agree on the management of the project being key, but sometimes they collude with salesgrunts to create what we used to call "A Never-Ending Story". If the salesgrunt can bill for coders by the hour, he will often make a lot more money on one of those dithering, prototyping, Scrum-style projects, especially as he will save on having to pay up front for the consultants skilled to do the right requirements analysis. Project managers and coders, especially contractors not wanting to have the pain of looking for a new contract the minute they finish the current work, may often go along as it is financially better for them too. For the salesgrunts, the longer the project drags out and the more rehashing of requirements happen, the more commission he stands to make, and the bigger the pat on his back will be from his senior management when he books the larger revenue.
I have worked for a consulting company where we had direction from management to "seek out opportunities to maximize revenue by expanding project scope" with the unspoken directive that revenue was more important than delivering what the customer actually needed. In Scrum it is the Product Owner (aka Customer Representative) that is the key to making sure the customer does not get taken for a ride, but it also the position that seems to most often get assigned to a junior with little experience and no authority.
"especially contractors not wanting to have the pain of looking for a new contract the minute they finish the current work, may often go along as it is financially better for them too."
My experience was that delivering a good job was the key to not having that pain as it ensured you moved straight onto the next project.
"What do you think it should do?"
New job. The company had a system it had written for a client. They and the client had decided to sell it to other customers as a joint venture. I was given the job of knocking into shape for their first two new customers. I very quickly realised it was monolithic - any user could get into any part of the system irrespective of whether it was needed in their job. Isolation wouldn't be easy due to the technology used (good for prototyping, not for production) so I made a start in re-writing it in a different language as a series of separate modules.
Then the salesman sold it to another customer assuring them it would be a drop-in replacement. A quick look at what they had told me it wouldn't fit, someone was going to have to manage customer expectations and I was the one caught in the middle. So I went to management, asked for a spec of what I was supposed to produce and was told that whatever product I came up with would be the spec.
I left shortly afterwards.
Wrong question. The right one is "Will this help long-term sales/subscriptions/etc., possibly expanding them?" This is especially important in complex systems development and design, where the "customer" (and you have to identify the correct ones) is a dimension, albeit the very important one, because they pay - to take into account. Just pleasing the customer, ignoring all the rest, usually lead to house of cards which will eventually don't satisfy the customer and crumble. Complex systems may need changes invisible to the customer that ensure long-term stability and evolution - which in the end will help the customer as well.
Of course that doesn't mean development should stall and no "customer features" are added, but beware to add more and more "customer features" on a structure that can't handle them properly, or even features that are thought to help the customer but don't, because the wrong customer expectations are used. You can see it, for example, in products that can sell only in a single geographical market, because only a very market-specific customer has been identified.
I had troubles some years ago when I proposed to fully unicode-enable an application and it was rejected because it wouldn't have benefited actual customers. Until they lost a big order from a new one because the lack of it...
To be hip and trendy the latest multi year project I'm involved in is being run on Agile principles. From a coding perspective it's going great. There is a lot of research involved so we really don't have a clear view of what we are doing next and it is pretty dynamic as one analysis methodology might pan out while another collapses. The customer mandated the product be managed using Agile, I'm sure based on the fact that there was a high profile report in their trade association magazine the month before we started saying how Agile was the way to go for any new projects...
So here's the rub. Our senior management keep asking to see the gantt chart and a feature roll out plan for the next two years. We have given them sprint data, burn down charts, access to Epics, Stories and work packages etc in our PM tool, even gone so far as to export things to excel and munge the data to look a bit like a giant chart but still they fail to get their heads around the fact that agile isn't waterfall.
For what it's worth this project would have been much better developed using an iterative waterfall model with 3 to 6 month iterations. As it is our sprints are currently a full month long as we try to get some basic stability into the platform and integrate the primary components. Once it's running we will be able to shorten the sprints and get some serious incremental content delivered. Until then its all a complete cluster fuck trying to keep the new age customer happy, the old age executives happy and still deliver a credible product in the short term.
I just wish people, who don't know shit about delivering projects, would just quit writing articles that purport to show the latest greatest "one size fits all" methodology that absolutely must be used.
I hate to break it to you, but there's nothing really that hip or trendy about Agile. It's like Coldplay. It might well be more recent than some other things, but it was interesting and new quite some time ago.
I've seen Agile done extremely well (place where I currently work) and it done extremely badly. Often it depends on management. Gantt charts, IMO, have no place in an agile methodology - the entire thing is focused on the short term and emphasises that there are vast uncertainties in the long term, so you can shove your precise long term planning out the window.
That's part of the problem, too, though. It's very good at dealing with the short term. It offers no framework for the long term. If your team and management can plan for the long term in agile without a framework, you're golden. Otherwise you can find yourself in a world of pain.
Also, wrt the original post, if your standups are over 10 minutes long, you're doing it wrong. Our standups have 10 or 15 people in and they're often only about 5 minutes. It's a status update. Say your piece, don't get into a discussion.
"To be hip and trendy the latest multi year project I'm involved in is being run on Agile principles."
"The customer mandated the product be managed using Agile"
reading your intro reminded me of some of the BOFH articles. well done! Simon would've been snarkier, of course.
as for me, I'll fill in the blanks as I see it:
1. Customer exec read an article that had the word 'Agile' in it.
2. This filtered down to the contract manager as a "requirement"
3. Agile 'as a requirement' became part of your development contract, with no explanation as to what that actually means.
4. People on YOUR end head-scratched for a while, trying to document how they were fulfilling the contract, and "came up with something"
and the result (as you described it):
"its all a complete cluster fuck trying to keep the new age customer happy, the old age executives happy and still deliver a credible product in the short term."
It can't be said any better.
Agile. DevOps. Whatever. If I ask two people to define these terms I get three answers. If you can't define it, it doesn't exist. And if it doesn't exist, it can be sold to the CxO at a premium and when it fails, the guy in the fancy suit disappears leaving a wrecked crew, a broken project, a bankrupt department, and a lot of people angry at the word that was used to describe it.
We know what waterfall is because even the Department of Defense put out eleven three-ring-binders full of specifications and rules for how to work a project using waterfall. Let's not venture too far into the weeds about how Winston Royce (the fellow who called it "waterfall") said it would never work on large projects, okay? So, back to the topic.
Some "versions" of agile might actually work. We'll never know because they call the ones that work "agile" and they call the ones that fail "agile" and there's no way to tell them apart.
What's worse, though, is that what will succeed with one group won't succeed with another. If the real meaning of "agile" were followed, we'd take the person into account; not just the project.
'Let's not venture too far into the weeds about how Winston Royce (the fellow who called it "waterfall") said it would never work on large projects, okay?'
That's exactly where we should venture because what he described as waterfall was a straw man. What he was trying to point out was that you may need to go back and revise some of the previous stages as you discover more about the job. Obviously the paper was too long for the PHBs who got as far as the end of the description and thought "That'll do.".
I've seen agile in both the good and the bad.
The Good: People who know what they were doing (always helps) and were able to deliver a product from scratch in 9 months. We didn't follow every meeting (no retrospective) because people had shit to do; planning was limited to 2 hours and conducted well. No Scrum Master.
The Bad, nay Ugly: This mostly stemmed from evangelist(s) and Scrum Masters (not all of them tbf) who seemed to me to be absolutely STEALING a living. They created so much bluster and bullshit that you ended up with no requirements, no cohesion, no comprehension, no fucking idea. So when things fell flat on their arse they'd just change the framework. Kanban, Scrum, XP, something else, SAFe all within 12 months.
When you have useless scrum meetings where nothing is achieved and you're sat in a room with some 10 contractors on £500 a day that useless 2 hour meeting has cost your company THOUSANDS, for what? For fuck all!
Lose the idiots and get off the bandwagon or you will spend so much money it's un-freaking-believable. Don't pander to Agile just because you heard someone say it and it's the thing all the cool kids are doing.
Holy shit, flashbacks of such stupidity its overwhelming... nnnnghhh.
In't good old days a business analyst would work with the business to understand what the business actually needed. A System Analyst would work with the business analyst to work out what software was required to achieve it and write it up into a specification. Then a programmer simply coded it up.
Given the cyclic nature of IT trends, who knows, this could be the next big thing !
I often spent a day sitting near a business user. First I ask what their business needs are, then whilst they get back to their work I knock up a basic demo for them. When I show them this I usually find that either my understanding of their needs was not perfect, or they realize that their description of their needs was imperfect or they change their mind as to what their needs are. Maybe do 3 or 4 such iterations in a day and all parties end up with a far greater understanding of needs and realities.
Here's the part I find confusing. If you're "developing as you go" how do you avoid the inevitable "oh shit, the architecture/db/performance won't support that new feature without a major redesign" problem you inevitably run into when you don't really understand what you're building until after a lot of these requirements have been discovered?
Does a good Agile process allow for re-factoring or redesign of fundamental architecture later on in the process when you've discovered you've painted yourself into a corner? Not that you can't get that with Waterfall, but it's been my experience that a lot more thought is given up front to make sure you don't end up in exactly that situation, just by thinking more about the future before you write the first line of code.
Having done been on Agile projects a few times - the answer is you mostly don't avoid "oh shit, the architecture/db/performance won't support that new feature without a major redesign".
The phrase is "technical debt" - the fastest and least elegant kludges tend to win out. In Agile's defence though at least this point is usually recognised, conceded and there can be a willingness to refactor when ones back is against the wall. Whereas with waterfall - when your information models, architecture etc. are s**t usually no one is given the opportunity to do anything about it as the PHB's 'output based specifications' are infallible.
Having just worked on an Agile scrum project where this was most definitely going to be a regular problem, I'm afraid the answer is that you lie to the Scrum Master. You create a sufficient number of over-estimated tasks, and smuggle in some good engineering practices. Either that or you find a "particularly tricky" bug that takes up your time.
My recent experience of Scrum has demonstrated to me that it doesn't work for exactly this reason. The re-work wouldn't be so bad if it weren't caused by the fact that we're working to an arbitrary deadline of a 2 week sprint that we've set for ourselves purely in the name of "processes". Sometimes to do a job well takes 4 weeks solid work, sometimes that work cannot be divided up usefully between team members, and most terribly for a scrum master & product owner, sometimes that work doesn't directly add business value (The product owner cannot directly demonstrate the product actually works, so seems to think this isn't a requirement). The answer from the Scrum process is avoid doing that work. My answer is to avoid doing that Scrum process.
I tried to shift the team over to a Kanban process to see if it would do any better, but met with political resistance from the P.O and the Agile "expert" in the company who feared it would reduce their control on the processes (which it would, and should because their not software engineers).
If you're working on a system with any complexity or that requires a well planned architecture (most systems) then avoid Scrum.
I've asked agile (and scrum and devops) experts how they apply their chosen approach when the organisation is implementing a software package. I've yet to hear an answer.
.....is this because only writing code is "cool"? ....or because no one implements packages today? .....or for some other reason?
By "Package" I assume you mean "shrink wrapped" software that you'd previously have burned onto a CD, and sold (also referred to as COTS).
If so, then yeah agile works for this, as does DevOps, but Scrum does not for anything complicated (see my post above). DevOps is nothing new, we've always had modular systems, used interfaces, practiced continuous deployment. It's not really viable to push that to your customers regularly unless you've got a very intrusive upgrade system like some gaming platforms have, but if you consider your PO to be the end point, then it's viable. You just build a lot of point versions of your product, and make sure that it's all automated right through to your signed and packaged installer.
From what I can see of Kanban, it could be viable as a process, and the backlog management that it brings can certainly aid in developing such software.
What do you see as the roadblocks of Agile when it comes to packaged software?
"....agile software development has wheedled its way into most every developer's mind as The Way Good Software Is Done...." Great! The problem is most developers haven't a clue how to do any of the other parts of the project process that actually are required to ensure success. I have lost count of the number of times I've heard coders exalting "We'll go scrum, that means no project manager", followed shortly after by the project grinding to a dead-end, over-budget and having not met the customer's needs. And the number of times I've seen developers gather business requirements successfully can be counted on one hand! It's quite amusing watching customers desperately trying to adjust their requirements to suit the prototype a scrum has delivered, just so there is something of value to show for the money spent.
Sure, do the development phase as agile, but make sure the preceding phases are done properly, and that someone knows how to close the project after development too. Waterfall (with feedback) is still superior for that reason and that is why it is still preferred by businesses.
Where I work, they are developing a new case management system. Several, actually. As always, the developers are getting all their information from managers and such. After all, why ask the line staff (who are going to be stuck using this) anything about THEIR needs or what actually WORKS opposed to management's theories of how it should be? Don't be silly!
So we have yet another government software project disaster in the works. AC for obvious reasons.
"After all, why ask the line staff (who are going to be stuck using this) anything about THEIR needs or what actually WORKS opposed to management's theories of how it should be?"
Why would the line staff know anything worth while? They're on a much lower pay grade than the managers.
This, if you think about it, is where consultants come into it. They can find out from the line staff and pass it on with a price tag which shows that it must be right. When dealing with management who know the price of everything and the value of nothing adding to the price actually is adding to the value.
"....young, excitable project analysts whose jobs seem to consist of moving postits around a wall...." Funniest meeting ever. Pre-holiday break, massive planning session led by one of those excitable "Agile" Gurus. Cue a length of wall roughly thirty-feet long covered in Postits from mid-thigh to head-height. Post-holiday, when the team returned to the room, all the Postits had fallen off the wall - disaster! The Guru hadn't thought to write everything down and had to spend the rest of the day sorting all his Postits out again. I didn't tell him I'd taken a picture of the wall when it was all in-place as I thought he would learn more from putting it back together again.
Thanks for the article, Michael. To avoid treating Agile as a fairy bringing my business dreams into life, I regularly come back to... the basics. Every sunday evening, before new week, I sit down and read http://kanbantool.com/kanban-library/kanban-kick-start/implementing-kanban-in-practice observing my past actions and checking if I haven't swum away from the foundation, if I haven't done any brief affairs with not useful practices ;) I want to know what's going on in my company, in my team, and I put some effort to achieve it. Not once, regularly, like flossing.
Most organisations are utterly failing at Agile. Usually it's the opposite problem to how organisations failed at ITIL; the typical ITIL implementation fails because people try to implement every line of every textbook using five different frameworks and then wonder why they're buried in process. The typical Agile implementation fails because people go to Scrum as if it was a buffet, pick one or two easy-looking things (usually stand-ups and two-week iterations) then wonder why it's a horrendous uncontrolled mess.
If you can't dive into whatever you're using to run your project and get out some metrics that say, "this is where we are, this is our likely delivery date and this is the amount and trend of scope creep" on a release-by-release basis then you are not doing it right.
Problem is, you won't get that by doing "seat-of-pants with stand-ups" the way most people do. Even teams who tick as many boxes as they can often fail at the core thing which makes this work: locking in a well-planned subset of the product backlog into a coherent increment that you achieve every single iteration unless something truly catastrophic happens. Very, very few teams actually do that. It's far more common for them to fart around dragging half-arsed requirements from their backlog, into a sprint which they have no hope of completing on time, spend a week on something else entirely, fail to invite any stakeholders to their review meeting, then go, "ah well, we failed our commitment, never mind, we'll just push it into the next overpacked, unrealistic sprint". Three months later they wonder why the release date is shifting sand and the product is a mess of half-finished features that don't work the way anybody wanted them to.
It's not helped by the market being full of charlatans (seriously, some of the cowboys I've interviewed for Agile coach positions...) and transformation projects typically being giving some unwilling victims a 2-day training course and abandoning them to fight Larman's Laws. Which is pretty much status quo for almost anything in IT, it seems.
Biting the hand that feeds IT © 1998–2019