Saturday, 7 February 2009

Agile and Scrum failure stories

Dear fans and readers,

I’ve now started writing a talk entitled Top tips to ruin your agile process. It is my intent to run the audience through the worst things that could happen to a team when they implement agile.

I have a fair share of miserable failures at turning (or keeping) a team agile, but I am now asking you to help me. Everyone has failed once or  more in being agile, and I hereby plead for you to give me your horror story.

Feel free to do so below, the comments can be made anonymously :)

Thanks!

12 comments:

Anonymous said...

Going very short iterations with too many features and changes, so no time for any refactoring and remodelling is left.

I call this ad-hoc reactive pseudo-agile. It drives me crazy and the system to a big monolithic ball of mud.
I think there is also the term "Death Sprint" for this situation.

Anonymous said...

I worked for a short time for a company that were quite forward thinking and into the agile way of doing things. However their client was not and preferred a more traditional approach like PRINCE2.

Short story is they lost the contract with client. Client and organisation need to be working from same page?

Alex

Anna Forss said...

Having stakeholders who thinks that agile means that changes does not bring costs.

Removing or not having a product backlog

Hiring developers who are senior in years but junior in competence

Developer manager's who still use command and control management

A lacking sense of quality

Having no testers or even worse, having a bad tester on the team which results in releases which are not deployable.

I could write horror stories on each sentence...

Zac said...

Everything I've seen done horribly wrong can be summed up as failing to understand that the freedoms offered by an agile approach must be balanced by discipline and responsibility, not just by managers or by developers but by both.

Sebastien Lambla said...

Anna, by all mean do!

The idea is to gather the situations that caused the process to fail, and see if by going back to basis I can provide some advice / tips on how to get out of a sticky situation

Daniel Fernandes said...

Company not understanding that an agile environment requires developers given ample information before an agile project starts, the more so if the project is 6 months+.
Some call it Sprint 0 or simply having workshops.


Company not undestanding that an agile environment requires a form of requirements that is both sufficient for the next iteration and that enables continual evolution to reach a quality they could be part of the product specification document once the product has shipped.
That means NO to 6 pages Use Case documents.

blog said...

My take on what not to do: Calling your process agile, without understanding what agile is.

I suggested to a team that we try agile, but no one, including myself really knew what it was. I knew you were supposed to break stuff up into iterations, and there usually is less up front requirements, but that's about it. No one else challeged me, or bothered to look into this more, and of course, how many developers like writing requirements, so anything that "promised" less requirements was seen as good.

So we basically ended up doing waterfall, but broke up our tasks into small enough pieces to fit into a 2 week iteration. We completly missed the customer feedback loop, failed to update our estimates based on project velocity, etc.

Needless to say, this process did not work. We are actually closer to an agile process now then we were in the past. An unfortunete by-product is that the word agile, and anything associated with it (i.e. TDD) is now Taboo.

I learned that agile is not a get rich quick scheme. Be sure to understand what agile is, and what you want to get out of it before going foward with it.

Anonymous said...

I worked on one project and the team lead/architect absolutely refused to produce any diagrams (even on a whiteboard) because "Agile doesn't have artifacts." This made it very difficult to understand the business model.

The Agile projects I have been on have actually been more restrictive than the RUP, Waterfall, etc ones: you must work in pairs, you must do TDD, code should not contain any comments.

In addition, I have found that coming onto an agile project after it has been in progress for some time, more difficult than coming onto a RUP project. The Agile project has no documentation. Sure, there are stories, but there is no context for the stories. And it's very probable that the story is out of date because a later story changed or even removed that functionality. With RUP, the documents provide much more context which is very helpful when one isn't familiar with the problem domain. Sure they too are probably out of date, but they're still good to get the basic understanding.

On one Agile project with two week iterations, we'd usually define what we were to build by Wednesday or Thursday of the first week. A build with the functionality in it had to be provided to QA on Wednesday of the second week. That left about 5 days of actual development per iteration. Our stories were too large to fit in 5 days of coding so developers took shortcuts like crazy and produced some extremely bad code.

On my current Agile project, we developers have unit tests but, obviously, the unit tests don't verify that individual classes or modules work together. The business analysts write integration tests but the developers don't have access to them because of a shortage of licenses. Us developers get demerits if we introduce bugs but we have no way of double-checking before we commit our code. This has made some of our developers very reluctant to do any refactoring.

On another Agile project, we were concurrently working on three iterations: a two week, a monthly, and a quarterly. Usually the people working on the quarterly iteration only worked on that iteration while the other developers worked on multiple iterations. We were very reluctant to do any refactoring because of possible merge problems.

I have more horror stories. Having worked on RUP and Agile projects, I prefer RUP. They tend to be less screwed up at the process level and developers have a better idea what they're building and why (and thus can contribute rather than just being code monkeys).

Lee Campbell said...

PM/BA misunderstands Agile; their interpretation is "I don't have to write any docs or do my job at all. Everything will come out of the dev team. But the dev team still cant meet the client." As there is no documented requirements, PM/BA/Client can change their mind at any time and the dev still has to meet the "sprint" deliverables.

Anonymous said...

Using "we're agile" as a euphemism for "we're crap":

* Let's not write unit-tests (before or after) because it's well known that developers cannot test their own output (read: "we don't want to think too hard about what we're building or why, because that would involve effort"). We have a tester! Surely he will just tell us what's broken; his mental powers of communication should be adequate to the task of reading our minds (or at least the 1tonne write-once/read-never specification that's being written)

* We're a team, but we all have our individual tasks to work on and when we finish we don't take our head out the sand to see whether another team-member needs help to meet the team's deadlines - "Well, _I_ finished on time, _those_ guys were late!"

* The business/stakeholders have such low expectations, and have got so much into the habit of accepting "but we're working on the innards, not the UI at the moment - you can't see that stuff", that they don't ask for things any more, but still complain when the project is late but they don't really understand why. People who want a project but don't set goals, don't get a project that achieves any goals.

* Retrospectives? What do we need to learn from our mistakes for? Wait wait, mistakes? We don't want to talk about those, especially not when other people might hear about them! Definition of insanity - doing the same old thing in the same old way and expecting a different result.

* Geographically distributed "agile" without strong leadership (as distinct from "management") DOES NOT WORK (here, at any rate).

* Let's not put the web-developers on the website project; let's put the infrastructure guys on that, and watch them use font tags and style attributes despite being told that this application must be skinnable via CSS. Let's make the competent people not work on the system that is supposed to save the company; let's glue them to the legacy system and not give them the resources they ask for.

* Documentation? Sure, we'll write stuff in a wiki, but it's only useful when people READ IT.

* Let's not have a backlog, and, you know what? Let's not have tasks at all! We'll just say "we're writing code!" whenever we're asked about what we're working on - that way, we can be telling the truth! Of course, we're writing things like validation frameworks (because the world doesn't have enough of those) instead of things that, you know, the business can market and sell.

* Let's have a manager that micro-manages from a remote site instead of leads from the trenches. Delegation is for those pinko-liberal teams where we've heard whisperings of such voodoo as "independent thought" "initiative" and "innovation". No, it's the MS way or the highway in our well-tuned outfit; how would we recruit if we didn't write stuff that anyone off the street could pick up and work on? It's FINE to use copy/paste, because everyone knows that's simpler than that object-orientation stuff - those features ("inheritance", "interfaces", "separation of concerns" etc) are far too advanced to risk using.

Does the dailtywtf have a "wtf agile" category?

RhysC said...

thinking agile means 1 week/fortnight/month water fall project backed up next to each other.
Poor communication channels, Dev cant talk to stakle holders
Not focusing on business concerns
No ubictous language
No automated deployment process
Thinking agile means cowboy...

Kristen said...

Sprint teams burning out because product owners are oldschool and think sprints are dumping grounds for their changes because of a lack of thought on what they want to build.

Post a Comment