Passed down to me by the senior dude when i first started working...
"On time, on spec, on budget. Pick any two..."
Anyone have similar experience...;-)
A couple of months back, Dutch computer scientist Erik Meijer gave an outspoken and distinctly anti-Agile talk at the Reaktor Dev Day in Finland. “Agile is a cancer that we have to eliminate from the industry," said Meijer; harsh words for a methodology that started in the nineties as a lightweight alternative to bureaucratic …
Indeed. Problems appear when management inevitably decides that such a "negative attitude" is unacceptable, and both three shall be satisfied, or else. Predictably this works about as well as throwing a tantrum about working warp drives and teleporters to be produced at once, except one can't actually explain that to management - they exist to communicate decisions to you, not to let you talk back.
@ phil dude
Shit mate, I don't know where you worked but when we were writing Assembler on an IBM mainframe for an airline back in the day before "organised" management came into play, we ALWAYS got all 3 right on target.
It's when the "professional managers" were involved and they brought in all the meetings to report 'progress' and multi-level management of a project that it all got fucked up.
We spent more time on so-called project management which in my experience, simply added more time and expense to the overheads.
I can quote, without mentioning any names, that I was involved in a project involving international companies, which we managed to complete in 6 months for a cost of around a quarter of a mill, while our opposite numbers spent several million and took well over 12 months to complete.
Bullshit costs money!!
Just my humble opinion but then I am now safely retired, and so obviously old-fashioned and 'out of touch' so I MUST be wrong!!!!
Back then Agile wasn't a concept, it was the normal way of working.
The few good points he has made are not sufficient to result in the summary conclusions.
Scrums suck, no doubt about it. I have yet to see a scrum that is not a waste of time.
Test driven development as used in most companies does so too because in most cases developers write tests to test a piece of code and NOT THE FAILURE CONDITION BEHAVIOUR. However test driven development does not suck as a general rule - it is doing it wrong which sucks.
Other elements of agile - retrospectives, etc are quite useful when done properly.
Even just working with the success paths, if you're building the foundations of a larger application having plenty of unit tests is by far the best way to ensure that it at least works to some degree. You won't catch all the problems that the system will encounter in the real world, but if you don't have the test suite in place, loads more problems will be encountered further down the line. I have no strong opinion whether you write the tests or code first, as long as they are written in close proximity to one another, but unless you have unit tests for most of your logic, you're lining yourself up for unnecessary pain.
Also putting an automated test in to catch bugs once they're identified is a great way of ensuring you don't inadvertently put them back in later. In an ideal world nobody would do that, but it turns out that some things about the world are less than ideal.
I think the real problem is the cargo cult approach to any methodology that is taken by many users. The problem is exacerbated by consultants who make a living telling people the "right" way to do whatever is fashionable at the moment.
There's no one right way to do things in all cases. As was said years ago in a different context "there is no silver bullet". Managers and developers still have to know what they are doing, and they have to apply techniques that are suitable to the project at hand within the industry they are operating in and appropriate to the size of the team and the personnel involved. In other words, we need competent people and they have to think about what they are doing.
The main problem that people have with unit tests is writing them to satisfy a "code coverage" metric rather than using them to find problems. In other words, a useful tool has become subverted because process is elevated over result.
And that pretty much sums up with what has happened to agile in general. It has been systematized into the antithesis of what it was supposed to be, which is the elimination of bureaucracy so that people can get on with the job of producing something useful.
"I think the real problem is the cargo cult approach to any methodology that is taken by many users."
Well said. I once had to tell a project manager in rather blunt terms that PRINCE is not a religion.
Try processes, sure, but drop what isn't working. Don't keep it purely out of stubbornness.
A software tester friend of mine refers to Agile as Fragile (and he has an alternative and shorter word for Scrum) . Testing is a nightmare when the client keeps changing his mind about what's wanted and there's either no written specs or the specs keep changing. Also, software testers are almost as rare as hen's teeth and yet every Fragile project needs at least one tester.
Having worked as a test engineer on both Waterfall, PRINCE2 projects, and with Agile, Scrum, projects, I have to say this isn't my personal experience. As a tester, I want to get my hands on the code as soon as the dev is done with it. If I find any problems, I can talk to them while the code is still fresh in their mind, retest any fixes as soon as possible, and just generally keep the cycle as tight as possible. In my fairly considerable experience, these short cycles are far easier to create and maintain in agile dev environments.
The hideous, pre-agile, old school way of getting a code drop for test with hundreds of bugs and features meant that by the time you uncover an issue, the devs already re-factored the problem code creating further newer bigger issues without having realised the problem, then moved onto some other feature and forgotten all about the nugget they were working on.
I never again want to be working crazy hours to get everything done in the compressed 'testing phase' because the dev time took longer than planned, but the release milestones had already been agreed.
As a tester I absolutely want the product owners to be able to change their mind after seeing something they don't like rather than stick with some decision made with limited information weeks ago.
Testers probably benefit more from iterative, agile workflows than anyone else on the team. I'd go as far saying a tester that doesn't like agile is probably doing it wrong.
I'm a software tester and if I'm going to work on a bad project I would rather it be agile than waterfall.
I've recently finished a contract where almost no-one talked to each other and there were silos of control all over the place. The project was waterfall and most times I would pick up the specification and find the code didn't match, usually a month or more after it had been completed. Every time it would end up that the dev had 'interpreted' a different version of the spec and the business analyst had a version which was almost all in their brains. I spent most of my time during testing discovering specifications and what time I had remaining I would raise bugs that would be descoped and never fixed. Because it was waterfall both groups were reluctant to talk to me and discuss what it is they had done.
If it had been agile at least there would have been an expectation that they should talk to each other and me. There would also be an expectation that the code should be available to me sooner rather than later.
I've just finished up on a failed Agile/Scrum contract with exactly the same problems you mention. The day I started, I remarked that "this place is awful quiet, nobody talks to each other". Every new starter said exactly that same thing. The same lack of communication was flagged umpteen times including by fly-in management gurus. At every retro, someone forlornly would say our communication is getting a little better now" and I said, "it sure isn't" until I couldn't be bothered anymore. I counted at least 3 scrum gurus over a 2-month period. But nobody could fix this team.
The SQA process has many times helped to find critical bugs prior to officially being released. Because of time constraints put on the developer, I do feel it is an essential process and the role of SQA Engineer is an essential role and will be for the foreseeable future.
I believe testing and that's still needed. Earlier testing was sole responsibility of testers now whole team is responsible.
Do we still need testers? Yes. Team consist all skills that require to code, test, deploy and maintain software.
Scrums suck, no doubt about it. I have yet to see a scrum that is not a waste of time.
Your personal experience may not be definitive. We've been using Scrum for years, and I've generally found the daily scrums useful. I'm in three feature teams at the moment, which means 15 scrums a week; they rarely take more than fifteen minutes a day together, and I'd estimate at least one participant learns something useful about the state of the release in 10-12 of them.
By the same token, sprints (we usually run two-week ones) have been effective at keeping feature sets reasonable and ensuring complex features get broken down into small component features with good separation of concerns and well-defined interfaces, and making sure work-in-progress gets committed to source control and tested by the CI systems.
As usual, what we have in the story and comments are various people generalizing from their anecdotal experience and turning it into dogma. Unfortunately software-development culture not only allows but positively encourages this sort of grandstanding, and celebrates this sort of contrarianism as a good in itself.
Your personal experience may not be definitive. We've been using Scrum for years, and I've generally found the daily scrums useful. I'm in three feature teams at the moment, which means 15 scrums a week; they rarely take more than fifteen minutes a day together, and I'd estimate at least one participant learns something useful about the state of the release in 10-12 of them.
Scrums are brilliant for team newbies. I'm a remote worker on a new dev team, and the daily scrums mean that there is a guaranteed 15-30 minutes* each day when all the busy people who already know everything about the system stop and talk about it for a bit. If I have a question on how to proceed, what something does, or I need help on some stack trace explosion that happened because silly ol' me dared to run "bower update", I can get assistance.
*10 mins of team updates, generally extended by a follow-on discussion on some aspect of dev
He advocates instead a “move fast and break things” model
This, and an apparent aversion to unit testing, is fine if you're writing apps to edit cute cat videos, less so if it's something I'm counting on for my life or livelihood. I don't think the idea behind Agile was to shove bug-riddled shit out the door as fast as possible.
I'm willing to give the guy the benefit of the doubt and suggest he's implying that all code will invariably ship with bugs so shipping quicker and being more agile (for want of a better word) is preferable to the old bureaucratic bullshit methods whereby the fix came on some bizarre rolling interval after the issue. I've worked at places where releases could only occur once a fortnight. Period.
".....so shipping quicker and being more agile....." Unfortunately, that is exactly the problem - senior management's perception of what agile (or any trend du jour) will deliver. The people that came up with agile thought an inclusive approach would lead to better/happier coding teams and therefore more successful projects. But what management hear is "agile means quicker results". In short, they believe agile will magically allow them to deliver the same product with the same resources in a shorter time (hence saving money), which, as any fule PM doth know, you get two of three not one for free.
I'd don't understand how you can do "move fast and break things" without having unit tests. They seem pretty sine qua non to me, otherwise how do you know what's broken?
That said: tests are a development aid and a developer's friend and not an end in themselves. TDD can be a trap because without some code you won't really know what to test for. Better to write code/test couplets where the tests help you think through (and perhaps improve) the logic you've coded and then fix the implementation so that any breakages will be caught.
As a Business Analyst, I prefer the quicker turnaround times afforded by a sprint, as there is always going to be a change in what a requirement holder wants when even the most basic of features is demoed (or demoed as it self-destructs) in front of them. Having worked in a waterfall-esque environment where requirements documents contained a whole quarter's worth of development, to be delivered two quarters from now, it's impossible to keep the requirements to come in mind while gathering the requirements still needed (especially when there are multiple BAs working on a larger project). This goes double when there is migration from an existing app to a new one with different user bases, as you're also likely to run into duplication of requirements worded differently so you end up with two ways of doing similar things in the same application.
At the same time, I find that code fast and break things is a feature of the current agile-esque methodology at my new company. Things are produced, shit hits the fan, and we move on. Things break; it happens. That's why we hire support staff and keep the software architects employed.
@Eric Olson - Speaking as the requirements gatherer...
Yea, the BAs like Agile as it means they don't need to do a proper job of collecting requirements. The approach appears to be "hey just throw some ideas over the fence to the development team and waste their time building crap to ill defined sh*t".
When stuff goes wrong they then blame it all on the developers...
".... in a waterfall-esque environment where requirements documents contained a whole quarter's worth of development, to be delivered two quarters from now, it's impossible to keep the requirements to come in mind while gathering the requirements still needed....." The best PM I ever worked with was an old civil servant, he was strictly waterfall and no other, and he always added a section to the requirements doc he kept secret from the customer - the Wants. This was compiled from right at the start of the analysis phase and consisted of all the "wants" that anyone expressed but which didn't get actually made into firm requirements. Added to this was a good slice of political "likely-to-happens", which was a cynical look at the politics of the customer and associated risks. It was amazing how often his Wants section predicted the customer's (often many) requirements changes, but then one of that PM's skills was an absolutely brilliant way of getting inside the customer's head and understanding their real business drivers, environment and politics and not the bullshine the customer presented to us. Where possible, we dialled in the Wants into the design phase so that we could add them modularly if possible, then when the "unexpected" change in requirements arrived he could hum and haw, charge the customer for a massive redesign (which meant the sales team loved him too), extend the deadlines (so us grunts had extra time for quality control), and proceed with almost no change to the plan. The guy was a genius!
of course business analysts prefer agile. you get away with writing vague specs and chucking the risk over to the developers and testers.
when the shit hits the fan, users don't go back to reading your specs to work out what was agreed. and if they do it's so vague they read into it whatever they want.
no. what happens is the developers end up capturing the specs *you* were supposed to capture, the functionality has to be rewritten and the testers have to redo their tests (which they have to rewrite beforehand).
i've noticed a steep decline in the quality of output from business analysts since agile became popular. i've also noticed any idiot can (and does) train to be a ba when they appear to be unable to fulfill any other function in the company. rubbish at everything? you can be a ba!
apologies to all the good ba's. i know a few and they get lots of flack from the numpties who charge the same rates but struggle to tie their shoe laces.
On your Life...
Some of the code I write has other peoples lives hanging on it since it's used for medical decisions.
I really don't want to find myself hauled in front of a Fatal Accident Inquiry for a coding fault going live that's entirely avoidable with a tiny bit of effort.
But looking at the guys shirt in the picture he clearly lives in a fairly land of cute cat videos.
Agile is just decent communication and getting dickwad project managers off your back so that you can actually take time to refactor code instead of just shoving hastily-written deadline-driven "just about good enough" code out into production.
Scrum is what happens when you let people are a) idiots b) Americans* AND c) in marketing get their hands on Agile and it should be burned with fire.
And Unit Tests are not about predicting failure conditions in live! They are about making each unit of code modular and robust
*seriously, nobody involved in the creation of Scrum had ever even seen a game of rugby. "Oh, it's named for the way a scrum runs up the field passing the ball to each other" - the fuck? Shut up and go away.
small mod tweak - fewer ad homs, please
> Have you ever played rugby?
Every weekend for about half of every year since 1982, yes. A scrum does not run anywhere unless something's gone very badly wrong. A team does. A scrum does not. This basic lack of information is a fine example of the half-baked nature of everything about Scrum.
small note to mod - the ad hom was ad Erik Meijer.
I think the metaphor is appropriate but misinterpreted.
One of the key attributes of rugby is that the team is composed of specialists who co-operate within a rigid structure, and the emphasis is on team play. You can get by on a running/kicking game or if you've a heavy front line just steam-rolling the ball, but the best teams master the continuum between both, and thus draws in the entire team to the simple goal of getting the ball over the line.
The actual "scrum" itself is where play restarts. Your scrum-half (not sure if this is the scrum-master or product owner - I feel the latter is more like the coach) puts the ball in, you all push and squeeze a bit the ball is released and play continues.
I think the scrum itself is meant to be the standup, though many other aspects of the process (refinement, retrospectives, sprint planning) create this "pressure cooker" scenario, where the team comes together in uncomfortable yet intimate circumstance (anybody ever played lock?) as a punctuation between plays.
I suppose the process could have more appropriately been called "Rugby" (glaringly absent from the metaphor is the opposing team though), but I guess Scrum was more catchy and is probably the most
salient attribute of the sport to an outsider looking in.
Unit tests aren't a TDD only thing. His complaint was against TDD rather than unit tests.
However he has a point. A bad developer writing unit tests is pointless. If he writes bad code why on earth would anyone think he'd write good tests?
Moon pig uses TDD, C.I. and all those cool buzzwords and look how safe their api turned out.
Relying on the code writer to test his own code is just about pointless.
"Relying on the code writer to test his own code is just about pointless."
At the last place where we did Agile development, for any given module we'd split into pairs - one would write the module, the other would write the tests from the module specifications, ideally without knowing (apart from the interface definition) how the module was coded.
"a scrum runs up the field passing the ball to each other"
I spend a fair bit of time watching rugby and it seems that these days a scrum is something that starts with an attempt at organisation that rapidly turns into a collapsed heap with a random assignment of blame and punishment as a result.
Come to think of it that's not a bad metaphor for a lot of software development but I don't think its something to aspire to.
I think this is a good observation. The term 'scrum' appears to have been applied to s/w development by someone unfamiliar with software, rugby, or both.
Or perhaps it was coined by someone with a wicked sense of humor who was spot on with an analogy describing the butting of heads while the object (the ball, or the code) sits unmoved. And the term was sold to the PHBs with exactly this hidden meaning in mind. And management hasn't got the joke yet.
Nonsense. You've forgotten to say what one of the fundamental principles of agile is: iterative and incremental development. Agile aims to be an alternative to the traditional waterfall life and it has many things going for it.
The issue is that there are several agile methodologies with varying levels of rigour, of control, of process, including: XP, Scrum, DSDM Atern.
Before slagging off agile, I suggest you go do some formal study of the methodologies, understand what they are first. Then you can slag them off knowing you have the knowledge to criticise them accurately.
"Which is a nice way of saying "guessing your way to the answer"."
Actually, no. It's a nice way of saying "guessing your way to the original question", since the hardest bugs will turn out to be the ones where you were given the wrong spec in the first place and enshrined that in the architecture. If Agile promotes "letting the customer use something as early as possible", then it probably avoids quite a lot of that kind of problem.
I say "if" because I confess I lost interest in software methodology when it suddenly became trendy enough for marketing folks to get involved and it became a tool I could buy (and keep on my shelf) rather than a method I could use on my own.
> > Which is a nice way of saying "guessing your way to the answer
> Actually, no. It's a nice way of saying "guessing your way to the original question", since the hardest bugs will turn out to be the ones where you were given the wrong spec in the first place and enshrined that in the architecture.
.. which is an excellent case for rapid front-end prototyping (after all, the users won't be seeing the middle tier etc).
So doesn't necessarily excuse the rest of the juju, nor does it necessarily avoid finding out late in the cycle that some major feature should have been approached/architected differently
Matt, there are an infinite number of possible guesses, and your probability of guessing something is remote. Any methodology that iteratively attempts to "home in" on a solution based on the next set of guesses is inherently broken.
I stopped going to the guessing game meetings and spent my time analysing the fundamentals of the issues that we were trying to address, in order that I might be able to clearly articulate the issue at hand and subsequently formulate solutions to the then well understood issue. This is apparently not very agile and I continue to pay an "organisational " price for my open antipathy to the whole agile ethos around here. I manage to keep my job because I am actually phenomenally good at abstract problem analysis (I have a very strange brain well suited and educated for this task), and my solutions make this evident - my productivity and output exceeds that of entire agile teams in many cases, and I definitely write was less code than they do. YMMV
".....Any methodology that iteratively attempts to "home in" on a solution based on the next set of guesses is inherently broken....." COUGH* prototyping *COUGH.
I find a modified waterfall methodology works quite well as you can bolt in prototyping if the risk analysis / feasibility study show you actually don't know enough to fix the requirements and ensure the success of the project. Of course, advocates of modified waterfall will often tell you XP (Extreme Programming, presumably what Mr Meijer is a fan of) is 100% "guessing". The biggest problem is those that are inflexible in their approach and cannot bend to suit the project.
"....You've forgotten to say what one of the fundamental principles of agile is...." I think what the author and posters are pointing out is not the problem with the principles of agile dev, but the way it is often implemented by those who believe (due to the hype) it will magically deliver perfect results if only they follow the process inflexibly and unimaginatively. Processes can most definitely help, but having worked inside failed and successful CPM, PROMPT, PRINCE, PRINCE2, waterfall and agile projects/programs, all I can suggest is the most important aspect is the skills and capability of the people involved, not the process.
".....Scrum is what happens when you let people are a) idiots b) Americans* AND c) in marketing get their hands on Agile and it should be burned with fire....." LOL, too late! It's even got into the PMI certification setup, which means it has A Piece Of Paper that HR/agencies will want to see on your CV to get the big bucks.
"....And Unit Tests are not about predicting failure conditions in live! They are about making each unit of code modular and robust...." No, no, no! They are about showing that you have met the requirements in the contract because then you get paid! If you actually spend the time to make the product work as it should and that wasn't actually in the requirements then you just delivered something for free. Salesgrunts will not like you for that, they will prefer you to sandbag the fix/addition so they can sell it to the customer as a project extension. Of course, if you are internal and not a contractor, make sure you point out the issue (to cover your backside).
Then I would suggest that your sprint model is wrong, not the concept.
I hold 1 x 2 hour planning meeting per week with a preset agenda for each meeting so that we can achieve enough in 3 meetings to populate a sprint. We run 3 week sprints from Wednesday to Tuesday with a code freeze 3 days before release and use git flow to control this. We have a daily standup for on-site and Skyped-in developers plus project owner plus scrum master which takes no more than 10 minutes.
The point of the scrum/standup is to quickly identify any weakness in the project. Developers should be able to speak openly about issues that cause concern ('blockers') or if they feel that someone is not pulling their weight on the project. Certainly there is an argument for having the project rushed through and having flaws and defects fixed at a later date, but only if you have a QC unit that is separated from the Agile process, which many larger companies have now. Otherwise you need to fix defects as a part of the sprint cycle or move the task into the next sprint.
Wow, down voted and told your job is crap because you have 10 mins/day and 2 hours/week in planning meetings.
My tuppence recalls that, as meetings go, planning meetings involve the developers and are at peer level - not a PP presentation or looking at some awful Gantt chart - infinitely better.
The 10mins/day, stuck to rigorously, allows one to bemoan someone not producing that thing you need and it quickly getting a red blob on a board or something indicating that a blockage is on-going and some manager needs to send a rocket somewhere.
All-in-all, I have found the experience much better than the preceding systems and I have three decades in the game.
Nothing is perfect but, done well (particularly stymieing the guy that ruins the planning meetings), Agile can work.
It also helps that the system produces a working system after every sprint, tested and ready. this means that engineers that deliver early can add stuff later because everyone knows that the system is on time without some nasty missing thing that hasn't been done (at least, if the planning was done correctly).
The real failure is trying to shoehorn methodologies without taking into account the environmnent.
Scrum can turn itself into an array of endless useless meetings and methodology artifacts that lead to no code in organizations that are deeply entrenched in micromanagement, because that gives managers the opportunity to play microtracking much better.
Agile is close to impossible in any organization where accountants govern IT and insist in quarterly and annual budget forecasts that have to be met, because that leads to projects with closed scopes and one of the key points of Agile is that the scope evolves as the customer realizes what it really needs.
Recognizing the character of the organization is key to choosing a methodology: even waterfall works very well in some contexts (where lives are at stake, for example), whereas in others fails miserably. Same with all other.
The real mistake is to pretend that there is a single process that can fit all situations well enough. Attempts to create such methodologies end up usually in unmanageable monsters that nobody understands and are only useful to rack up consultant fees and certification programs.
"The real mistake is to pretend that there is a single process that can fit all situations well enough."
...this. And there seems to be a fundamental problem with understanding what Agile means - it's not adhering to any one methodology but an agreement between stakeholders and development teams that we live in an imperfect world and must collaborate to organise an efficient process accordingly. For example, Scrum doesn't work for agencies whose teams are responsible for a number of unrelated projects. In this case Agile doesn't say 'find another methodology', it says adapt something whose fundamentals help avoid team, communication and legal problems and so avoid widening the divide between different parties involved in a project. It's also a response to traditional development methodologies creating software that's already obsolete when it goes into production, rather than products that might be imperfect to start with, but generate substantial value even in that state. Being successful in business is usually about being pragmatic, and Agile is all about pragmatism.
I can only assume that his experience of scrums and agile development have been rather poor.
A short stand up is what you are meant to have. It's to focus your mind at the start of the day, let your team members know how you are doing, allow you to ask questions for your work, or of other's work, and spread knowledge you have that a developer may not.
As for TDD, it's rarely implemented to the book. But you do need tests. The tests (1) document the code's expected behaviour, (2) and stop code changes breaking what is tested, (3) encourage code to be written in a modular, testable manner, and (4) allow the developer to sleep at night (and more).
And I'm not just talking about unit tests, there's integration tests, component tests, etc. These all test the software at different levels, including the ability to model real world breakages.
Sure - there will be things that you haven't tested for that break. But that's better than simple things that you could have avoided breaking. I don't know about you, but I like sleeping at night instead of worrying, or getting phone calls to fix things.
And as for agile - what it means is "do what is necessary for this bit of work to be complete; don't do more, don't over design up front, don't anticipate future requirements (within reason). It really does mean "move fast" - but in a safe manner.
..sounds like hacking code to me.
@dogged good points, totally agree - especially about Unit testing. Who said that unit testing should be the only testing done before the software goes out the door?
On the one hand, he rubbished the most basic level of testing and on the other presumably advocates no pre-release testing at all in his 'move fast and break it' approach... Moron.
"Then again he did once work for Microsoft and man, have we been buying the results of the 'move fast and break things' approach for years now." Actually, MS has a very good testing perspective and had a suite of good testing tools long before its competitors. I suspect MS's problems are more due to conflicting headline requirements - "make it easy to use" vs "make it secure", with the former winning at the design phase but the latter becoming more important in later development. If you identify imperfect requirements then no PM process on Earth is going to save you from delivering an imperfect product, and subsequent attempts to adapt an imperfect product is always going to be harder (but less of a case of market suicide in the case of Windows) compared to just starting with a fresh design.
I suspect Erik Meijer's problem is he is a "gasshole" - a super-genius asshole who continually irritates his colleagues with statements like "What, you couldn't see that?". I suspect he is one of those people that is so smart and good in the narrow field they work in that they have a problem realising not everyone can work to their level, hence the disparagement of processes he deems "unnecessary" or "irrelevant" because he is just too smart to need them.
The problem with any programing paradigm is that people like project managers throw the baby out with the bath water. They follow the paradigm too rigidly, instead of letting the users of the paradigm (e.g. coders) adapt to the situation.
There is no universal tool or technique for managing projects of every shape and size. A good manager will adapt/modify techniques to the situation as it develops.
I've worked with good and bad PMs. Often times I have to stand in, as I'm the poor sap who has the BA title appended to my name. A good PM keeps people focused on the task at hand and gently steers the ship towards the goals. They cut out scope creep, keep the numbers looking good for finance, and if necessary, throw themselves in the line of fire when management comes calling, wondering why something isn't being delivered on time, under budget, and with pristine quality.
The newer PMs often come out of school and/or training with a specific set of tools in hand they are to use, and when one tries to upset that particular apple cart, they have a tough time. I've noticed in my travels the PM is the one who struggles to move from one methodology with one set of tools to another, as they are raised in a world with specific metrics and reports. You put story points and velocity in front of them when it used to be IT spend and burn rate, and suddenly the foundation of their world takes a huge hit. The PMs I've worked with who have multiple methodologies under their belt tend to take whatever crap their current company throws at them. Just like any other professional, experience and thick scar tissue is what makes for a good PM.
And it's a job I never want to do. Ever.
Agile is just a way for management to pass the blame to developers when a project is late.
After all development teams are now "self managed" and have taken "ownership" of the job so it is their fault it is late.
Nothing to do with management have unrealistic expectations of how long something takes and making commitments that development teams can never achieve.
Agile is just a big con job all smoke and mirrors.
That is not all that it is, but it certainly is massively misunderstood by a lot of its proponents. One of the points of Agile is that you implement features on an interative basis. There is no "done" in an Agile project, just an ongoing process of improvement and feature addition. This is not actually what most business customers want, but it's just the kind of term that marketing chumps love, so they start making up their own amorphous definitions for their own purposes and of course it's the developers who suffer when we can't do the impossible.
It's like a fucking revisionists party here today.
There is quite clearly the 'definition of done' in Agile. It is not an ever-lasting quest.
The problems being discussed here seem to be about two things:
- Egos, of both developers and PMs
- Bad management
Neither of which are about a project management framework. They're about people.
I always hoped it would lead to an end to "project managers" at all but sadly, most employers still reflexively insist on a "project manager" for every project.
One used to insist on selecting the technologies and tools we'd use despite the fact that she literally never written a line of code in her life.
And these are not edge cases. These are normal. "Project managers" are parasitic scum but whichever methodology you select, you can guarantee that some cretin further up the food chain will insist that there has to be one.
Speaking as a parasite I would say one of the problems with project managers is they often don't have experience of the sharp end for agile I guess its coders, I am more engineering and I have seen the same thing, you get someone who has no idea about engineering but know there way round an excel spreadsheet and got the nice Prince2 certificate and apparently this makes them fully qualified to understand a subject that most people spent three years sweating getting a B Eng for. Why ask your upper management who have been sold the marketing bullshit, seriously I have seen someone who has all the skills and working in a company as a project coordinator (knows the job, knows the contacts for clients etc, lots of construction experience) be overlooked in preference of them hiring externally someone who went and got herself a Prince2 foundation certificate before that she had been a secretary she lasted about two months btw before leaving due to stress....,
However also having seen some jobs go completely tits up because the engineers were left to sort it for themselves and have done stuff that makes you go "hold on I thought you were intelligent, so wtf?" Frankly some tech people can be blinding at their job and complete shite at understanding how it integrates into everything else that comes with running a business or even understand that a budget and profit margin may be quite relevant to continuing pay packets. I can say that some projects do need project management as long as they are the sort who can do a decent interface between the business side of things and the tech side.
Actually Agile is more of a way for developers to say to management "Hey, this is what we have worked on, these are the problems we found and this is what we are delivering". Things only really get bad when you have a project manager who promises the board delivery dates beyond the capability of the process, and I have seen this at high government IT levels.
We use an agile system not just as a means of structured development but also as a monitor for bad developers. The number of apparent 'back end developers' who can just about scrape through a PHP fizzbuzz test is sorely in contrast with the numbers who do not even know the differences between and object and a class.
Just because you *can* be agile doesn't necessarily mean you *should* be agile.
Its a great excuse for continually sneaking in additional functionality *without* altering the project plan. In other words to any sane person completely fucking ludicrous. But of course thats fine you just steal time from the testing phase of the project to swallow the additional development effort.
Moving fast and breaking things is all well and good if you're whipping up a pocket-size app at a code jam, but if you are working on something large scale and serious then all you're doing is charging around making a big noise and leaving everyone else on the team to tidy up your mess.
The problem in most development projects is not too much communication between the different stakeholders.
A lot of design methodologies work fine in the hands of experienced coders. By experienced I mean they've been through the process from top to bottom a few times.
1)Oh - and management has to have done that too. Which is where most things fall down.
I've used the 'write the code in meetings and when no-ones watching and then present it as an option" approach a few times. Best to bring out working code that's not 'a la mode' when they're desperate for it.
But the best approach is normally to subtly get the customer to accept something that's already out there - its what they want most of the time and the chances are only an experienced developer will recognise their problem is really as old as the hills. But see point 1) above.
I read an interesting description of Agile/Scrum the other day: If houses were built the same way that Agile software is developed, you'd need a bulldozer to fit a microwave oven in the kitchen.
Not a great fan, but thankfully it doesn't really affect me (now), since I'm mostly left to get on with my own thing.
Again, this implies that the overall aim of the project isn't actually known whilst the work is going on.
For your house building example, that's like saying "I want to build a shelter to sleep in" up front, rather than saying "I need to build a house with all the modern expectations of a house which are XYZ".
Agile doesn't mean you don't design up front for the end aim of the project. It doesn't mean you give up on good software design practices. You will analyse the needs of the Kitchen aspect of the project, and decide you need worktops, and cupboards, and you need water, and space for a fridge, oven, microwave, and power for each of them, and the ability to rearrange things, and to meet safety regulations (i.e., plug sockets, etc).
However once you've done that, you can start work on it, you don't need to have the bathroom designed (well, it needs access to the water stack in the house, etc), nor do you need the garden landscape design completed. Which is what waterfall model would require before you even started clearing the site.
And sure, the first kitchen appliance might require refactoring of the kitchen a bit (hardly knocking the house down!) ... oh, the analogy is stupid at this point.
Of course, contractor development methodology is even less restricted, although dealing with clients often means you need to be more waterfalley in terms of getting the requirements and specification done up front.
And if you truly are doing your own thing, then enjoy!
Actually getting the customers input to the problem before the "solution" is set in concrete.
We all know that in general the customer doesn't know how to explain (well enough for a spec to be written) and/or know (usually case of both..) what it is that they need (was going to say want, but they usually want truckloads more than what they actually need).
Rapid development cycle and the customer being more directly involved greatly alleviates the problem which is probably the most useful part of agile.
I'm a BA. I know what it's like to get folks to think about what they want in the future as opposed to fixing the problems they have today. At some point, you just have to say that today's solution is as good as it's going to be, and if the business model changes or the workarounds become too costly, we'll come up with something new.
The worst part of my job by far is trying to convince people that a new solution means that the old baggage doesn't need to come along. So that six-step process to validate an ETL or manually modify the loaded cases isn't needed any longer as long as we capture why that ETL validation was going on or the cases were being modified after the fact. We don't need to create custom functionality in the new world to account for the broken crap in the old world.
The problem is that operations is usually heads-down trying to keep up with today's work. They aren't incompetent; they were hired to keep the ship from grounding on a sandbar rather than finding a new, pristine harbor to sail to. Getting them to see that and dictate requirements from that POV is a Herculean task and often the reason for overrun and scope creep, in my experience.
Thank you Eric, yours is the very first mentions I've seen some of the unspoken side effects of Agile, one that the Dev's and Mgmt refuse to acknowledge until forced. All of this grandiose methodology has to be supported by Operations and Infrastructure teams who in my experience are run on a shoe string, and run ragged. They support Dev, Testing, and Live most of the time as well, often at shitty hours of the day while others sleep, or at least are able to hand over to another shift. They don't appreciate at all that none of their crap will work without the underpinning infrastructure and operational support until it's not there for some reason, and then all they do is vilify you, even if they couldn't be arsed to identify their massive requirement that broke it at the design phase. Oh no, they'll make sure it is known as an 'infrastructure problem', which sticks; the more you defend it the louder they hum. You have to deal with Dev's, PM's, Business, Mgmt and other infrastructure teams all at the time to manage all the unrealistic expectations that emanate from each separate faction who thinks the world revolves around them.
"what passes for an agile community seems to be largely an arena for consultants and vendors to hawk services and products.”
I think you'll find most methodologies/processes that have a name generally exist to serve as "an arena for consultants and vendors to hawk services and products."
And, whichever methodology is in fashion, that's the one that'll attract all the idiots.
Some 'agile' methods were genuinely helpful, back before they were buzzwords, so we had to think about what we were doing and why. Nowadays agile talk is a warning sign. Lately I've had better experiences on rush projects where we had to do some waterfall development to meet deadlines... and nobody really talked about methodologies, we just did our damn jobs. :)
The first thing we do, let's kill all the lawyers..."
This was first spoken on stage in 1623 by an actor in one of Bill's plays. I think the only reason lawyers drew such scorn was because middle managers hadn't risen to such surplus population by that time.
In this time, I think it would read much more favorably toward lawyers and other vermin, and much less favorably toward middle managers and like diseases. Such is the necessity for temporal interpretation.
The enthusiastic embrace of Agile by coders was, I think, in greater part of its inference that we might, one day, live and work absent the middle manager. Indeed, if Agile says anything, it says to eschew anyone in the team who is either not writing code or not going to use it. This is the very soul of reason.
But, given the virulent nature of management, as soon as the threat was identified, the virus changed both itself and the host and became the destructive member of the symbiosis -- what biologists might call a parasite; which is really no morphological change at all, when you consider the species.
Agile in its current form should surely die. If we can kill it, we should. But the practices of the agile developer should be taught, mostly in the trenches, mostly by the experienced, and always while producing working code.
The most certain indicator that agile is _not_ being used in a team is the presence of anyone whose job it is to oversee or manage (e.g., a scrum lord or other non-developer/non-user posing as participant). The two questions to ask are 1) are you writing code? and 2) will you be using the code? (or 2a) are you paying for the code?) and if neither are answered in the affirmative, a large trap-door should open beneath the plaintiff and s/he should disappear with a whoosh!
[In defense of test driven development, I have found the personal value for me is in its ability to keep me from over-engineering. This is a practice of an agile developer and if it takes a trivial and simple process to enforce the stricture on myself, then I accept the shackle.]
"He advocates instead a “move fast and break things” model, where software is deployed and errors fixed as they are discovered."
Great, except that'd get people killed. So, er, no.
Erik's being a bit silly here. He's not railing against Agile, but the horrible waterfall-agile Wagile hybrid that is all-too-common in large enterprises trying to "act like a startup". Which is fair enough, but Agile done right is just such a pleasure to work in. It gives the lightest of frameworks to the things we all know work well - small, incremental targets; small, self-organising teams, direct and frequent user involvement. None of these are Bad Things.
Having watched the talk Erik strikes me as just too much of a pure programmer - he considers any minute not spent hands-to-keyboards churning out [potentially broken] code; including any time spent by non-programmers, as a wasted one. That's bonkers.
Having watched the talk Erik strikes me as just too much of a pure programmer - he considers any minute not spent hands-to-keyboards churning out [potentially broken] code; including any time spent by non-programmers, as a wasted one.
He's a coder. Coders are OK, for what they are, and they have use in an organization. I find that I prefer working with engineers. Erik is no engineer.
Geez you "developers" sound like a bunch of self interested whingers if these comments are anything to go by. Don't forget you are employed on a business project to deliver what they want, not the other way round. ANY form of project should be constrained by the limits of time, scope and cost, so what you should be referring to is Agile change management if it is regular ongoing development, not Agile Project management which should have a finite lifecycle.
Regardless - when you reflect on the amount of self interested whinging that gets done by developers, it isn't too hard a leap to understand why Programme and Project managers need to have these regular planning/scrum sessions to ensure that your focus remains the correct one and so that progress reporting is completed accurately.
As a developer, you might think that being "project managed" is beneath you; but I assure you... it is not, and you need to be.
Developing code is a mixture of a mechanical and craft skills along the lines of a bricklayer a plumber or numerous other trades. Anyone who does it can recognise skill in others by the elegance of effort, speed of production and quality of the work they produce.
Unlike bricklayers who can usually estimate how long to build repetitive designs made from common components;.most businesses commission unique systems, because they believe themselves to be unique and special.(doubtful). Consequently the system we are expected to produce is a pioneer with a huge number of unknowns.
Programming also operates at many scales from a cool line, a neat function, a tidy module and a finished app. Being able to see the whole project across these scales is a definite skill and quite often different developers work better at different scales. A succesful PM should be able to see all scales.
Most programmers bitch about project management because it's practitioners tend to be purely amateur accountants who think that guiding a project to success is purely about coming in under budget. Maybe if PMs started their meetings with "How are we going to do this bit.?" rather than "When will it be ready? Oh come on it's already been promised two weeks earlier than that." they would be appreciated more.
What do you want! Code or meetings. You can't have both.
Agile is absolutely crap at change management, requirements wander all over the show. Agile has no concept of scope control, time or cost. Hey we just do stuff and keep changing it until we run out of time or money and then ship....
Correct. Also, unlike what this clown on stage believes, it is not about testing, even if they are called unit tests. It's about specifications.
Course, I would like my specifications to be Dijkstra-airtight and not depend on random examples to be verified against, but you get the Zimmer frames that you can in this "industry". Better than nothing, until Lamport's TLA+ or similar things get acceptance.
My company uses what one could describe as 'move fast and break things', but it comes with a few very important provisos including;
* Not for mission critical applications
* Very robust plans and technology in place for fast rollout and rollback
* A very solid automated test procedure so minimal user testing is required for each release
* A very good change documentation procedure (linking client requests, project management and code versioning together into something that makes some semblance of sense).
It works very well in certain markets - we provide technical solutions for very non-technical (marketing and design) clients, and they are guaranteed to change their minds 20 times before the end of the project, demand things go live at a moments notice and generally ignore our advice whenever possible, so we have a development lifecycle that deals with this very well, and we manage their expectations with regards to bugs appropriately.
I can see the point in scrum, but I don't think I've ever seen a situation where it couldn't be handled in a more flexible, slightly less smug/self-satisfied manner. Scrum Master...
As a Selfish Programmer, I do not care about any benefits of Agile that help management track the workers.
What I do care about is being given an interesting project and doing the work to deliver it.
Agile breaks projects down into tiny, boring bits and take all the fun out of development.
>> Agile breaks projects down into tiny, boring bits and take all the fun out of development. <<
That is so true. And what is worse - it turns the programmer into an automaton driven by the sprint.
You end up with a load of partly-written code and no documentation to maintain it (so when you discover some bit that needs adding after release - and you will - no one knows how).
I guess the main problem are Agile zealots, who received their 'Scrum Master' certifications and now are trying to apply Agile onto anything - and that's where the problem is.
You cannot use Agile for everything - impossible. Agile is great if you are adding a feature to an existing product and can be shipped with minimum viable functionality and then iterate and add more.
If you need to build an API that needs to be specced, secure and simply just work out of the box, forget Agile. You need good old waterfall - at least for the core functionality and then use Agile to plaster on top bits.
If you're starting fresh, I would go every single day with Lean instead of Agile - because you have no idea yet what's going to work and what isn't.
Yes, those of us who have been in development for some years can see where it fits, zealots don't - they treat it as a silver bullet for everything.
Thing is the exact same thing can be said for his argument, he wants "move fast and break things" model, this wont work on everything. Yes agile wont work on it all but then again, making software as quickly as possible, pushing it out THEN fixing it after the nuclear dust clouds dissipate is not a good idea.
I have recently observed a so called 'Agile' system at first hand. In my last job we used Agile and it worked pretty well when the Scrum Masters understood that DBA's work in a different way to Java devs.
1) Having a 2 or even 3 day session where the last Sprint is reviewed in minute detail and the next 2 week sprint it planned.
2) Every line of code has to be reviewed by at least two other developers. WTF?
Applies to comments as well.
3) Absolutly no documentation produced. Even the WSDL's are guarded like the crown jewels.
4) Any criticism not matter how small is regarded as personal and you get attacked on social media for have the temerity to do so
5) Using Google Hangouts (Free) which has a limit of I think 10 participants when the team is at least 12 strong.
6) Taking 4*2 week sprints using 3 people to produce something that I wrote in 3 days, documented in 2 and included a full regression test suite after 4 days. I did my version because the customer was fed up with waiting for it and being onsite, I ran out of excuses. So I said, 'I'll give it to you on Tuesday. Ok?' He agreed. Needs must.
7) No considerations given to ANY aspect of Performance.
Agile can work but as has been said, far too many Scrum Masters with very little Sodtware Dev experience are ruling the roost these days.
I can be thankful that I was not part of the team. If I was, there would have been blood spilt.
Agile methods work for some situations, particularly where the client / end users don't know or can't describe what it is they actually want up front (e.g. customer service agent portal) - so you get the basic gist, build the prototype, then have a round of, "well, could this bit be red, can we show this here, I need to see this when I'm doing this", and then go and tweak it and have another round of 'testing'. been there, done that, it worked well to give the end user the system they needed in the sorts of timescales available.
When building stuff for aircraft with millions of pounds and lives at stake, everything spec'd up front 'It will do this', 'it will not do this', then tested to destruction once built to make sure it did and didn't tick all the boxes. That also works well for its intended purpose (planes staying in the air and people staying alive). It can tend towards over-runs and over-spends because the projects take longer, so there is more time for the true requirements to change, and you have to pay for more, and repeated testing of those changed systems.
I know which one I want my phone company to have used for the system for their customer service agents, and I know which one I want Airbus to have used when building the A380 I'll next be sitting on at 30,000 feet.
Obviously does not have to go through the convoluted change control procedures of onw of my customer, every time he goes round the break/fix/deploy cycle!! Agile is not something most large corporate change control processes are aware of!
For Agile to work properly you need agile customers. I have yet to meet one.
> Agile methods work for some situations, particularly where the client / end users don't know or can't describe what it is they actually want up front
I happen to agree that Agile doesn't suit every requirement but you've literally just described every project ever.
Oddly, the single best methodology for an industry which insists on Waterfall - such as defence weapon systems - is TDD because you write tests for all the documented acceptable outcomes and error conditions and then make them pass.
"Working software over comprehensive documentation"
Fine if the original developer has to fix any problems that are found. Not so good if the system is thrown over the fence for someone else to fix, especially if the problem is not found until some time after the original developer has gone or forgotten how it works.
The adjective is "comprehensive".
Sure, add a user and surve manual.
But there is no use to respecifying a system down to the level of detail where you get something akin to code, only in Word Document form.
It is generally appropriate to use a domain-specific language or a high-level general-purpose language (not the C/C++ detail-laden crap) to express what you actually want to do and let the machine fill in the details underneath.
I've seen agile implemented with varying degrees of success, and produce products with varying quality, quantity and delivery time (not necessarily exclusive). It's been my observation that the main thing that causes agile to be majorly neutered is when people start seeing it as an "answer" that will make their life easier.
One particularly disastrous project I saw (and was involved in cleaning up) the team said "We're going to be agile now, so we don't need to plan anything". They then proceeded to each take a bit of the system, not talk to each other, and code it. In that case they didn't know what agile was, but even when people do, they want agile to just go off and fix that problem for them. I'm sure everyone on an agile project has encountered someone saying "We're agile now, so I don't have to do x". As the article said, that's not really what it was about.
In my opinion the only way agile works is if everyone in the process, from analysts to designers to developers to testers to managers to customers, invests time and effort in doing their bit for the process. Agile requires more ongoing effort than waterfall because with waterfall you produce the deliverable for your step, then head off down the pub. Agile requires everyone at every level spending time every week from day 1 to quite a way after day of release.
"Even Test Driven Development, where developers write unit tests to verify the behaviour of their code, comes in for a beating. “This is so ridiculous. Do you think you can model the real failures that happen in production? No,” says Meijer."
I have to agree. Having sanity checks in your code? Good. Running a setter to set a=5, then running a unit test to verify a is in fact 5? Assinine. I'm sure there might be useful unit tests, but the majority of unit tests I've seen do just this.
"Is Agile bunk? No, but much of what is sold as Agile has little to do with what you find in the Agile Manifesto.®"
Ahem. i'm only a dog (iOAD™), but:
Is Communism bunk? No, but much of what is sold as Communism has little to do with what you find in the Communist Manifesto.
Is Free Enterprise bunk? No, but much of what is sold as Free Enterprise has little to do with what you find in Adam Smith's "Wealth of Nations."
Cf. The "No True Scotsman" fallacy: http://en.wikipedia.org/wiki/No_true_Scotsman
Whatever your views on agile, Erik is the man behind bringing FP concepts such as monads into the mainstream īn the form of LINQ and more recently Rx to .NET. Both immensely powerful additions to .NET.
I realise this doesn't have much to do with the discussion, but whatever, thanks Erik.
Most of this is about people and governance, not really code. What you use Scrum, XP, Waterfall, JCI (Just Code It) is largely irrelevant.
You can think of Agile as promoting a method of people organising themselves similar to daft democracy. In my experience JCI is normally an exercise in Anarchy. Waterfall tends to be used in some sort of bent Monarchy. As far as I can tell XP is related to communism.
None of them are perfect. But I'll use the most pragmatic approach possible. With the people that we have.
The most important part of TDD to me is what TDD actually is supposed to be, Test *Driven* Development.
Write the tests to the spec for the module. In the process you think of pass and fail scenarios that you probably wouldn't have just by writing the code. Then write the code. The developer should write the test and code in my opinion as it keeps their mind focused on how to write the code bearing in mind the things they were thinking about writing the test. The resultant code will be better quality than jumping in to write the code or having different people write code and test. And for the love of god, don't let a tester write unit tests!
Then, unit tests aren't TDD, though they can be used in TDD. The main benefit outside of TDD for unit tests is as a regression test. So long as you run them. Ideally run on every build.
Anyway, as for Agile, the problem isn't the original principle of Agile, but that anyone tried to control it with processes and meetings. SCRUM and the like are exactly what Agile was trying to avoid. That said, I quite like the Sprint approach, at least in that you agree with everyone, including stakeholders, what will be in the next sprint release. Once agreed, no manager can say "we must have this quick change now, drop everything! Though I still want everything else". It's not agreed, tough. Next sprint you can have it. To me it's a way of developers keeping control, not managers.
Where I've seen Agile fail is with too much process and management, and a lack of involvement by all stakeholders, which should go right to the top. That and people who just say "we're agile now" but don't do anything agile at all.
The developer should write the test and code
The bug that causes the most expensive screw-ups is the spec ambiguity. The coder goes off and does what he thinks meets spec - and might even do so - only to find out that that wasn't what the spec-writer meant.
By having two separate individuals write the code and its test suite, you get two goes at interpreting the spec. If there is a disagreement, it's pretty clearly a spec problem, and that can be sorted out earlier rather than later.
I've experienced a situation of a test team being assigned to write unit tests, and their coding knowledge is often not so great. The tests (with the likes of nunit) miss a lot of things that a developer knows to check for. They also aren't concentrating on the architecture, just the higher level spec, but unit tests are individually wrapped around internal structures that the testers may not know or care about. When it comes to TDD they'd only be able to write the high level test for a module, not a unit test for a class they haven't thought of and thus under TDD that class would not get written (for example).
That's not to say that non-coding testers shouldn't write tests also, just not the low level unit tests. Another developer could write them though.
This is where BDD comes in. TDD focuses the developer on the architecture and implements a series of regression tests. BDD focuses everyone on the requirements.
Agile has morphed into a religion backed by big money. Consultants will tell you you're inefficient, preach of miracles, and offer themselves as a guide down the long path to being Agile. Go ahead, find an employed consultant who says otherwise. Most Engineering teams suffer from weak project management so execs welcome change at all costs. In the end it's no different. Agile reduces the chances of having epic project cancellations but the pressure of rapid release cycles and unclear long-term goals instead pushes projects into a slow death of technical debt long before anyone is happy with them. I often say that I prefer a flexible process rather than Agile but it's heresy.
Anyone claiming that scrum does not work due to too much talk and not enough code is just plain doing it wrong! The talk should be kept to a minimum. Also if the Business analyst keeps throwing crappy requirements at you until he/she hits on the correct requirement then the scrum master needs to have a serious word with them. There is nothing inherently wrong with scrum or agile as a whole it is just that everyone has jumped on the bandwagon without understanding it properly. However anything is better than bloody waterfall..... also I do agree that TDD is bad as there is no way you can know all the potential issues to test before you have written your code. How many times have you written code thinking it will be simple only to find that as you write, it becomes more and more complex?
The pyramids were built incrementally though...... They did not just suddenly build the great pyramids perfectly first time!
Agile is by far the best way to build anything other than tiny projects. All these comments about it involving too much talk and too many requirement changes just points to how many people are doing it wrong. There should never be too much talk as the meetings should be kept to a bare minimum, Also managing requirement changes is what agile is all about, You can make the project owners aware of the impact of their changes by letting them pick what requirements now get thrown out as a result. The release date stays the same so if a new requirement comes in then a current one gets thrown out. This makes management etc think more before they change things. People are acting as if there are no requirement changes in Waterfall, there are and they cause major issues. Agile is just a way of managing the scope creep better. Most places I have been at have run frAgile which is where the developers are all on board with Agile but the rest of the business can't let go of the control they had with Waterfall.... this is by far the worst way of doing things but seems to be the most common.
As with all things the initial idea has been subverted by the higher ups.
Scrum is great if it can actually be implemented correctly. short stand ups are useful first thing to know what everyone is doing, but should be less than 10 mins (that's total not per person)
the problem as always is that managers and business in general does not buy into scrum. Scrum will produce you great software but it will not do it in any fixed time frame you have in mind (i.e. it's not always suitable). Business as a whole does not work in that way. Business is all about making profit. That's it nothing more nothing less. Make profit is their one and only concern, regardless of what they say (business will fail if they do not make a profit, so saying they are in business to help or be ethical or any other bull is just that it's bull)
Scrum can and does lead to profit (better software with good customer relations will eventually lead to better sales and better user experience which will drive profits) , but not if you are following a traditional business methodology (get it done, get it done fast and i don't want to pay for it), which is why managers say they are implementing scrum but they really aren't.
Self organising teams are great if they are actually allowed to self organise. In my experience the managers say "you are self organizing" what the actually mean is "we are going to blame you if anything goes wrong". They say "You can choose what you take into a sprint" what they mean is "you will do what I say when I say it or I'll fire you" they say " you can release with the minimum viable functionality" what they mean is "I've signed a contract that says I will deliver every tiny bit of functionality that the client wants, in a time line that is completely ridiculous, and I intend to lay the blame squarely at someone else's feet when it all goes tits up because I'm a moron."
the problem is not in the agile methodology it's in the world wide business culture that says "the person at the bottom is held responsible". The truth of the matter is that the person at the top is ALWAYS to blame every single time.
if the people that do the work could be allowed to do the work, without interference from above (Guidance, yes! Overall vision, yes! Bigger picture thinking, Yes?) then agile would work, waterfall would work, move fast and break things could work, but with the caveat that it would work only if everyone knows what the hell they are doing.
Sticking to scrum or any agile methodology as defined in a book or some certification course will probably end up as a failure because such definitions assume an ideal environment, and the business place is far from that.
You need to find the flavor, or combinations of flavors that work for your organisation. Even go as far as changing it on a project by project basis.
I always put it like this: "If you can't be agile with your agile process, then you have a problem"
Please, if you are a member of the Army Special Forces Green Beret, do not hate me nor my comment. I am not usurping your honor nor your motto. But my experience is truly embarrassing and failingly instructive.
About ten years ago I worked (as a consultant) at an online service corporation that suffered from a myriad of problems -- all of them streaming down (like the plumbers' bane) from above. After executive councils had deemed that neither bad product quality, nor failures in market research, nor lackluster sales campaigns, nor the decision to send technical support offshore, nor inattention to the customer could explain the current business environment nearly as well as a lack of motivation, the C-level announced a new internal motto.
Improvise. Adapt. Overcome.
They actually thought that using a motto on folks otherwise unfit for duty would magically transform them into a fighting unit.
In the same way, they introduced agile (through an expensive consultant) to the development teams. It failed for exactly the same reasons. Bringing an "adaptive" practice to undisciplined, unfit, and untrained programmers is the recipe for chaos, not victory.
When serendipity hands you superb coders and designers, it doesn't matter what "methodology" they are told to follow. They change the rules (at least internally) and figure out how to succeed. Agile is the shiny toy in the new box (or was ten years ago) and is still climbing the precipice from which it will eventually fall, but for now it is lofty. But the truth of battle and the truth of coding remain: warriors will win in battle, no matter what the motto; good coders will succeed in their development, no matter what the methodology.
Bad coders? Well, they fail no matter the best tools, best language (another argument), best practice, and best leadership.
Building software is the most egalitarian pursuit in the universe. The quality of the whole is never any better than the lowest capability of the worst developer on the team.
Methodology be damned.
IMHO coding is one of the _last_ steps of a successful project.
(by "successful" I mean 'meeting the originally specified requirements' and "being maintainable in a cost-effective way for as long as the product is required in-service" and "providing for an ordered shutdown of the service/withdrawal of the product").
I've seen far too many projects run by superannuated geeks on the "We'll all start our coding in a variety of languages and platforms - meantime can someone go and find out what the client wants!" basis. Coupled with a client who doesn't really know what he/she wants and even if he/she did know he wouldn't be able to adequately express it - the result is chaos.
The other big issue I've had is when projects escape from development and slide into production without a proper clean demarcation between the two. ITIL, PRINCE, Agile etc are useful toolboxes but shouldn't be religions.
Seems to me most people who actually type program code as a living agree that in their experience Agile is pants.
All the hangers on, BA's, PM's, architects and other work dodgers love it because they can't code but they can all talk none stop bollocks in a meeting.
If you have ever spent hours getting into deep concentration to deal with a complex issue only to be interrupted for a pointless meeting to hear what irrelevant bobbins your teamies are up to, you would hate meetings too. And scum with its daily scum master led micro-Mc-miss-management is the worst. The task switch cost is enormous, the opportunity cost massive. I hate to imagine the number of errors introduced on resuming coding after the daily scum concentration killer.
Seriously which other professionals are required to report in daily on what they have done and what they plan to do. Daily?? The number of projects where that level of coordination is regularly required is truly minuscule, and yet we are all forced to stand up and give praise to the great master of all scum. Ridiculous. I got them removed the last two places by pointing out the staggering productivity cost, replaced with a proper useful weekly update report and team building discussion, often in the pub.
If your team need a stand up meeting to coordinate and communicate you are doomed anyway.
Maybe fantasy Agile is a joy to behold and guarantees superb progress visibility, excellent risk management, exponentially high quality, early delivery, low cost epic software, but real world agile is shit.
".....All the hangers on, BA's, PM's, architects and other work dodgers love it because they can't code but they can all talk none stop bollocks in a meeting......" IMHO, I think it's more to do with the management numbers game. Modern management practices taught on MBA courses and the like totally focus on efficiency/productivity and putting a number/value against everything in some Excel spreadsheet somewhere. They can then crunch the numbers and supposedly tell senior management "exactly where we are". They always want to be able to put a number on coder productivity, like estimating each coder will produce a thousand lines of code each per week with an average of three bugs per coder - complete rubbish, but it is numbers they can crunch. I have had great fun trying to explain that tasks differ in complexity, that a coder may complete a thousand lines on an easy task in a day or two, bug-free, because it is a task that is easy or well-known, but the same coder could struggle to complete a really tricky coding task in a thousand lines in a month. Inevitably, I get asked to "qualify" the difficulty of a task with some form of "difficulty factor" so they can slap a sum into a cell in their spreadsheet and think they have it covered. I have even had requests to "grade" project team members, irrespective of the fact coders are all different and how they performed on one task could have zero bearing on a new and completely different task. IMHO, they like Agile because it says every period of X weeks they get a sprint and a release, which is measurable.
Since Agile first became popular in the l990s and later I have been highly critical of the paradigm and its supporters. And it finally appears that some in the profession are beginning to get the message.
"Agile" was a re-development of the "XP" paradigm, which turned out to be a complete failure as everyone would have known had they been tracking the history of this early paradigm. "Agile" was merely a new face to a very stupid idea; that you can design software by bypassing its most vital processes with a new paradigm.
There is no such thing as developing software without using some level of the "Waterfall" approach, which simply details the basic common-sense steps to the creation of any type of product; design, implement, test, validate the defects, correct, re-test... and so on.
Anyone who believes they can re-arrange common-sense does not belong in any creative field such as IT.
Now there are many ways that one can approach these steps and in standard software engineering practices there are approximately 13 such variations, two of which already somewhat mirrored what Agile was attempting to accomplish but failed to do. These variations can be found in the standard "bible" of software development by Steve McConnell, "Rapid Application Development", which is still a standard in the industry though it was first published in 1996.
Now before anyone decides to rebuke my contentions please understand that the development of Agile was not a reflection of software engineers attempting to produce better results but to do so under increasing, severe pressures. The development of Agile was more a reaction to the increasing and utter incompetence of US corporate management to understand the realities of software development with the idea that you cannot create anything worthwhile under foolish time constraints, limited budgets, and poorly staffed development teams. To such management everything is about the money, which in the end they never save but only lose more as a result of poor results. For some reason this proven logic cannot seem to enter the highly narrowly focused brains of such people.
This reaction in the software development industry should have been thwarted by more engineers insisting that the original precept in our field in which management will simply have to wait until developers can produce a product correctly. And this is how it was done in the mainframe era where we had our own issues to deal with and when technical management was little better than we have today. Nonetheless, project planning and implementation was somewhat better understood and to a degree somewhat better implemented than currently.
What happened was that with the incursion of the micro-computer into daily business processes along with the newer development tools some people got the ludicrous idea into their heads that software could now be developed faster. These people never considered the fact that better development tools does not translate into faster Humans in terms of development processes.
Nonetheless, this idiocy took hold and the rest is history.
Needless to say, the overall project failure rate in the United States has not moved very much from the 70% average, though some limited studies have attempted to show some improvements but not against the overall, historical average when such broad project failure statistics are taken into account.
I do disagree though, with the contention that Agile should just be dropped so that developers can simply do more code. If Agile is to be dropped then what should developers then do in terms of proper design processes? Simply coding is like just saying we should all just become "guerrilla programmers" as it was known in the mainframe era when instances of projects were not properly designed and managed.
There is absolutely nothing wrong in telling management to either wait and do it right or find another staff member. By not doing so we professionals have been bullied and coerced over the years into producing garbage, which is having terrible ripple effects in US society; the "Affordable Care Act" web-site introduction is a classic example of this. The current, massive issues with the new F-35 fighter is yet another.
In the end we are all going to pay a heavy price for allowing so much bad software to enter our daily lives and we are already doing so as software use is exponentially growing while its development is being done on increasingly flimsier foundations since so much of it is done at the behest of the "bottom line" in business.
Nobody really knows how much effort and cost it'll really take to build the new edifice.
Some are taken seriously when, at the beginning, they display a strange and rather baseless confidence in a schedule that magically matches the deadlines and costs imposed at the start... and they find themselves in charge.
And [insert methodology of choice] is what you invent to cover your arse when it doesn't all go as 'planned'.
I'm not sure what the solution is. There probably isn't one. After all, non of us have crystal ball. Much of what is worth building comes with a generous amount of 'unknowns' that might throw the project into the ditch.
So agile, waterfall, whatever floatation device you pick, don't forget that none of it will rescue you from the fundamental uncertainties that underpin our industry.
It isn't like bricklaying. That's predictable. It's a lot more like architecture... where you only find out about all the challenges during the journey.
Erik condemns Agile but his "move fast and break things" is equally rash and unsystematic. What he recommends is a more sever form of Agile having the same fundamental flaw of NO OVERALL GOAL, NO PLAN but all rash and random action!
This is what I posted where his article was cited:
It is NOT clear what Agile is. Some claim it is a set of principles and others claim it is a methodology.
AA: A principle must be well defined and should be valid under specified conditions. It should not lend itself to multiple interpretations and unspecified open-ended conditions (like the skill, judgment, versatility, understanding, culture, team spirit etc.). The principle should facilitate its application and speed up whatever is to be done but NOT become a point of debate and distraction.
BB: A methodology must have well defined action steps to be carried out with a set of well-defined tools in some specified manner and assure expected results within specified tolerances. Such results must be obtainable repeatedly and reliably by any qualified / trained practitioners within specified conditions.
Agile Manifesto is a set of beliefs which fails to meet AA or BB. Thus, it has become an excuse for doing what the team likes and claim it is Agile. As a consequence it is utterly useless as a principle or a methodology.
I agree with the general conclusions of Erik, though not with all his other claims.
Meijer's rant says nothing more than that he is incapable of working in an agile team process. Fine, he's off the team. It would be great to hire lots of Erik Meijers, put them in cubicles and let them write perfect code all day, but we live in the real world where Erik Meijers are rare, so we try to arrange things such that teams having a range of abilities can get actual work done. Agile is a good way to do that in many cases.
It would be great to hire lots of Erik Meijers, put them in cubicles and let them write perfect code all day [...]
You think the likes of an Erik Meijer can write perfect code? Puh-fukin-LEEEZE already!
Can I have some of what you're smoking...It must be really great shit, Mrs. Preske!
I think that not exist good or bad metodológies exist bad implementations or interpretations. Anyway Agile in a whole not its only for a write good code, Scrum maybe its not oriented to a good code , XP its oriented a good code, Agile it is more that Scrum!! Agile are values and principles, its like an Catholic Religion. Values and Principles are good but some implementations of this are very poor!! This article show that you dont understand this fact. :D
I first come across Agile on a large Government programme in a department that had never used Agile before, with suppliers that did not have a track record in Agile delivery and with a management team who did not understand Agile.
Needless to say the programme was not 'Universally' successful and was not a 'Credit' to the Agile methodology.
One of the key failings in the Programme was the mismanagement of the feedback loop and the lack of developers in the elaboration rooms. So elaborated designs disappeared off into the ether and we never knew how they fared.
Guess what, Agile run poorly give poor results.
Despite this faltering start for me, I believe Agile has its place in developing software and can see tremendous advantage in a well-run Agile project over Waterfall.
What is wrong with Agile? Meijer’s thesis is that “we talk too much about code, we don’t write enough code.”
This can be translated from whatever language Meijer speaks into: "I want less yack, and more hack!"
A Product Manager type (read: marketdroid) actually stood up and said this in an engineering meeting where the team was wrestling mightily trying to understand the gibberish that this same marketdroid was trying to pass off as specifications. Said marketdroid was shortly shown the door. One can hope that Meijer meets the same fate.
After many years of trying everything on the market I can state the following:
Agile like Communism is a very nice theory... nothing more!
In practice, a very small number of projects are gaining by applying Agile instead Traditional management and those projects would have been just fine managed by a Project Manager instead of the 'self-managed team'.
The only method working so far, only because is addressing the core issues of a company is Fast-adapt, which so far has not reached the Mainstream.
When a certification in a method is around £1500 I doubt if there is more gain in using it or in selling it?
I work within an enterprise, where agile has so much management overhead that it doesn't feel particularly agile. Daily scrum meetings, bi-weekly sprint planning, constantly having to log my work hours and update my progress in JIRA (seriously, fuck JIRA) - it doesn't feel like a bunch of eager coders working together to Get Stuff Done. If anything, I feel more micromanaged than ever, having come from a team some years previous where Get Stuff Done was the ruling mantra, and solo coders were allowed to wander off and create prototypes for things they'd come up with in the shower. We used to get crazy amounts of code written, whilst still looking out for each other.
I'm working with good people, and some of the overhead is useful, but when you start on at me about story points and work logs and all this other bullshit, I just want you to leave me alone so I can write code.
Agile has serious issues these days but going back to hack and hope development is not a solution either.
Agile wannabes often suffers from a creed of people who chase technology and what to use it whatever the cost. Sometimes these leaves software written badly because the technology was never understood when it was used and small teams with several different technologies, meaning everytime a dev works on a different application they need to relearn; killing productivity.
A second issue is the love of TDD, it's not a pancea for all ills. Writing tests first can be a great tool, but as a design tool it'll just as much validate and produce a bad design and bad code as a good one; at the end of the day it always comes down to a developers ability to visualize the solution.
Also writing tests, whether before or afterwards, to test behaviour of a service layer will by definition test all the functionality underneath it within the domain layer, meaning tests written against a domain layer are often duplicates of other tests.
Other aspects of agile such as Kanban management can be a great tool, however, to ensure work gets done.
Anyone else heard of "Flow" or "in the Zone" that wonderful mental state where you understand the problem, your mental model of the code and data structures is firmly formed in you're minds eye and...
Bring Bring Phone Call
30 seconds later after answering some dumb ass question "Now where the Fuck was I.."
2 hours later and you still haven't returned to that sweet spot.
Moral:: House your developers sensibly
1) Always assume the person following and maintaining your code is a homicidal maniac who knows where you live.
2) Write code like an old guy rides a motorbike, Defensively; Assume that every other road\code user is either out to kill you, or just doesn't give a shit about any rules..
Moral:: Teach defensive programming from Day 1 (Always include the 'Else If')
On the few instances when I had to write code, I found that if I drew the flow chart first and got that to work properly, the only erors in my source code were typographic If I got cocky and didn't bother with a flow chart I soon had hours of 'fun' debugging.
Of course, drawing a flow chart does rather rely on a stable requirements specification and actually thinking about what you are going to do before you do it.
So much time, money and sweat goes in to Agile/Scrumming that everyone gets too fatigued to do the real work of keeping the effort properly guided. "Real" leadership is crowded out. I've never seen Agile/Scrum consume less than 20% of a team's time. That may be an understatement too. In this article and elsewhere it has been widely commented that if stand-up happens at 10am, everyone's "flow" is utterly ruined thru the whole morning. You might end up diluting your resources by half!?! I've noticed an uncanny trend, that "where Scrum is, real software project management isn't". The Scrum rubric actually alludes to this, something like "Now you have a scrum-master, you don't need a project manager anymore", which is demonstrably nonsense.
You just end up with brittle code that everyone's afraid to change or refactor because the tests will break. The tests almost never cover failure scenarios that you're actually going to hit, but go into excruciating detail about stupid edge cases that the developer thought were interesting at the time.
They also take ages to write and they cause you to solidify the design too early because even though you want to change things around you don't because you can't face the thought of re-writing all those tests.
Total and utter bullѕhit.
You seem to have missed the whole point of TDD which is that the tests give you the freedom to change things and experiment more without wondering what else you've broken!
And if your tests cause you to solidify your design at all you are writing them at the wrong level at the wrong time.
The methodology employed is entirely dependent upon the particular application. Quite obviously applications in which a bug could cause an airliner to crash have a need for extremely extensive and formalised testing, while an application where the worst consequence of any bug would be a failure to play a few movie discs can happily get by with more ad-hoc and incomplete testing - and in fact that approach is more desirable because a company that takes 5 years to develop a completely bug-free Blu-ray player that is 4 years out of date or that costs £1000's due to development costs is not going to survive.
In short it is perfectly true that you can only have 2 out of the three - and the methodology you should use to develop the code depends very much on *which* 2 you have chosen.
Looks good on paper you just can't implement it.
I think a process or methodology should solve problems not create them.
The first indication that a process has failed is the deluge of supporters whose every missive ends with, you just didn't implement it correctly.
My major complaint is with the word iterate. It allowed the principles to do the age old project killer of Saying "Start coding we will get the design to you later". If you said, wait a minute we need at least a bare frame work, you got the old, What do you think this is Waterfall???
There is nothing in Agile that will cause the Project leads pain, or make them change the dead lines. I will believe in Agile when they include the following.
If a Scrum runs over and development and QA have to work overtime, they get to beat the project lead about the head and shoulders for not doing the job correctly.
It happens twice and the Project lead is let go. I was a prop forward, lets have a real scrum
My major complaint is with the word iterate. It allowed the principles to do the age old project killer of Saying "Start coding we will get the design to you later".
And that's why you'll hear proponents of Agile saying "you're implementing it wrong"; Agile *doesn't* want you to start keyboard-bashing without a design, for reasons with which we're all very familiar.
But certain people *claim* to be "Agile" whilst doing the above. They're simply wrong; they are not implementing an Agile process, they're implementing a specless, designless anarchy that will fail to produce anything of note.
Agile is about getting your customers to see your trajectory throughout the development process. It pprevents that awkward meeting when you suddenly realise you've developed what the customer said he wanted, not what he actually wanted. It's pragmatic. When you see someone expending more effort over the ceremonies than the development process, you know you've got someone who's completely misunderstood the situation...
Senior developer with 20 years experience. Degree in an ACTUAL engineering field - Mechanical Engineering. Tech lead and architect on dozens of projects using various methodologies. The SIMGLE MOST factor in the success of a project is the talent and dedication of the developers. The SINGLE MOST detriment to morale is the micromanagement of talented developers.
The Daily Standup:
I'm not a moron. I have enough professionalism to be aware that I might need help/answers from another team member. I address issues as they arise and don't need to have a daily meeting to ensure that I do so. If yor teams need that then you need to fire those who are unprofessional. Idiotic and disruptive processes do NOT inspire talented and experienced developers. It CRUSHES their creativity and motivation.
At one of my recent clients who had just adopted Scrum, I suggested that standups should be reduced to 3 times per week. I was told that "The daily standup is the most important thing you'll do all day!". Idiot much? My response was "I thought that the most important thing I would do all day is to develop working production code. Can I leave and bill for the entire day once the standup is over?"
2 week iterations to deliver a viable product. That's an idiotic concept. A minimum viable product might take 6 months to deliver. There is value in delivering features incrementally but if the minimum viable feature set for a product takes 6 months to develop then 6 months - plus design - is the length of the iteration. To time box everything at 2-4 weeks shows a fundamental lack of engineering knowledge and experience.
Incremental delivery is fine. Design up front is crucial. Those who say that customers don't know what they have abdicated their engineering responsibilities for taking the effort to understand and help to define the business process. Pure laziness. I have always been able to define the business process and hence develop solutions that work the first time.
Agile has become an excuse to hire bad developers and not take the time to understand the business problem. "we'll just try something and if it doesn't work, we'll try something else". That's not engineering. That's just laziness!
I've worked in Waterfall, Spiral, and Agile methodologies (SCRUM, Kanban). All three have issues, but to me I've very rarely seen success when using Agile SCRUM. Why? It's not due to communication issues between team members, it's due to the inflexibility of SCRUM, which is an antithesis to Agile. Where I've seen it fail is preventing technical discussions. For example, I've encountered countless Sprint Grooming and Sprint Planning sessions at multiple companies where the Scrum Master prevents technical discussions. Essentially, this attitude that engineers can't speak technical during ceremonies prevents understanding of the story and prevents accurate story pointing. I hate the fact we cannot understand a story, then have this idea we are committed to finishing story in a sprint. Then, when the story isn't finished during the sprint, there's a retrospective to determine what went wrong to improve and the team experiences, "you didn't meet your commitments." Well, what went wrong is the process prevents committing to an understandable story. So how is this combatted? According to scrum.org create a Part 2 planning meeting or more meetings just between the development team. This is a foundational issue with Scrum and it needs changed. Sprint Grooming and Sprint Planning are for the pigs, not the chickens. Why have them without an understanding and an accurate depiction of the Acceptance Criteria? The story will most likely fail. Granted it fails fast, but it's still a failure.
I also find that Scrum doesn't provide the time necessary to properly decompose and design a solution. Vertical slices are great but they can create more integration points, creating more points of failure. If the whole picture of what is being sliced is not understood, you're going to encounter decomposition and design flaws, even using SOLID principles. I've yet to see code written in an Agile SDLC that consistently displayed high cohesion with low coupling. Why? When in SCRUM is there time to design? You typically design during the sprint. I know some successful companies run with separate boards for system design, ux design, and implementation. But, this is the lesser case.
The fact is, there is no silver bullet. Brooks is very correct with this. I have no problem with Lean Principles and Agile on a high level. But, I think when you follow SCRUM and avoid flexibility, it will create a ton of headaches that can be avoided simply by being Agile.
Biting the hand that feeds IT © 1998–2019