Erik Meijer hating on Agile: “we talk too much about code, we don’t write enough code.”
The article claims a former priest from the Church of ThoughtWorks has “debunked” this. Can a religion ever be said to have debunked a skeptic?
Dr Dobbs piece on how Agile mutated into the dogma we know today: http://www.drdobbs.com/architecture-and-design/the-corruption-of-agile/240166698
You’ll have to forgive me if previous posts convey the impression that I regard Agile as simply an elaborate practical joke that exists solely to wring cash out of clueless organizations and unworldly cretins. Nothing could be further from the truth, and to prove it I present you with a wonderful and educational gift.
This exciting “graphic novel” produced, we have to assume, in earnest by PMI shows how Agile(R) skills are not just of use in the Scrum room of a dull IT company but can save lives godammit! Experience the thrills as Angela, our plucky protagonist, manages to not just save a little girl from an icy death but also free a crack team of project managers who could have been trapped in a luxury hotel for several inconvenient days! As others lose their heads, she calmly uses her knowledge of the Agile Approach(tm), to make signs, arrange meetings and facilitate the deployment of information radiators. Without wanting to spoil the end of the story, it’s worth noting that she never lets her ego get in the way of The Agile Approach, and invites everyone else to congratulate themselves in a sincere display of selflessness. Woo-hoo! they all shout joyfully, for they feel happy to have been part of the experience. But deep down acknowledge that Angela alone was responsible for the success.
Think on Hollywood – perhaps it’s about time someone remade The Poseidon Adventure with an Agile hero!
(Thanks to Mr Fritz for sending me this gem)
Here it is! A cut-out-and-keep Genuine(R) Agile(R) Voucher with the value of 13 Genuine(R) Agile(R) points:
Please read the terms and conditions before you award it to someone, otherwise the points may end up being a meaningless waste of everyone’s time.
Seven months after our official launch date, as estimated by the extraordinary powers of Agile, we launched our new software. Even to the most meagre intelligence it must be obvious that it took this length of time because that’s how long it takes to produce a viable product using our current “Agile” process. I’m only glad that the people higher up were able to delay release until all of the problems were ironed out. Obviously they aren’t all ironed out, but that’s software development for you. At least now I’m not embarrassed to be associated with the released product.
A few months back, our born-again-Agile-boss came out with one of the most fatuous statements imaginable; faced with the fact that each team failed to finish every “Story” in the allotted time of a two week “Iteration”, we were described as being “addicted to overhang”. Let’s put this another way: the fact that we can’t produce the goods in our arbitrarily allotted time-span isn’t because the requirement is unreasonable, it’s that we are “addicts” of not finishing on time. It’s truly cathartic to get this out by the way – it has been gnawing away at my soul.
Yes we addicts of lateness have finally managed to get a product out. We are genuinely happy about that.
My only gripe is that the management have learned nothing from the past year; we have a new platform to launch and we have a new arbitrary deadline that is not feasible. Not only are the management pretending that it *is* feasible but the middle management, composed entirely of contractors from a consultancy that I now consider to be more of a church than an IT firm, go along with the fantasy plans.
Can’t we stop lying for a few minutes a day? Can’t we be honest?
No. We can’t. That’s the rule apparently.
Honesty leads to tears, literally. That is how fucked our company is.
As the iteration continues, and the developers write code, and the developers fix bugs, the software improves. The developers and the QA teams know this because they are using the software all day and are naturally aware of the progress being made. However the BA’s, PO’s, and PM’s do not know how things are going, because they try to spend as little time as possible dealing with the “technical stuff” (they’re much too important to deal with the nuts and bolts). Consequently they rely on the post-cards (or the post-card emulators) to determine what’s being done. Only when a Story gets “Accepted” do they celebrate; even if the feature was coded weeks ago and was simply being debugged or honed since then. Even if it was just sitting around waiting for one of the high-folk to approve it.
For daily business, we all communicate via an Instant Message system. Around three weeks after a developer has finished implementing a particular feature, it is common to get a message directed at everyone which reads something along the lines of “Story-1554 has been accepted! That’s 12 points!!!!” at which we’re all supposed to get excited, whoop, jump around and high five each other or some shit. Some people regard points as being akin to money, treats or gold stars – others, like me, just get saddened. A feature we implemented has been “accepted”. We already know it works because we (and QA) have tested it. But now, the actual work has transcended from boring-old-code to something really valuable: Agile Points!
So I’ve decided to make a range of official Agile-points gift cards that we can give out to BA’s and PO’s and all of the other worthless MBA fucktards for their birthdays etc. What better way to celebrate than to apply an extra 5 Agile Points to your project! The work will get done even quicker after that (and that’s Science that is)!
The elders of the Agilist church at money.moo see all work in terms of points. Using this, decidedly broken, metric they base all timelines and deadlines on a team’s velocity. If you are unfamiliar with Agilism and have a functional brain there are some questions you should be asking around this point. Let me attempt to preempt you and answer them in the manner of our Agilistic overlords:
Obviously this is a bullshit definition, and completely unworkable; but that is how we do it at money.moo.
So, once we’re all agreed on what one point is worth (however we’re supposed to do that), how do we ensure that Stories are assigned the correct number of points? The answer is…”Poker”! Well – that’s the Agilist name for what we do. Here’s how it works:
Once all the stories have been allocated a point store, the BA and PM use their craftsman-like skills to plot a projected “Burn-up chart”, which demonstrates, scientifically, how long it will take to complete the stories. Obviously this doesn’t include the time it will take for QA to test the stories or the developers to fix the bugs found; but that’s fine because bugs have zero points and take no time!
After this, the solid scientific projection is presented to the CTO. The CTO looks at the total estimated time the project will take, realizes that it is twice as long as her already announced arbitrary deadline allows and asks the team to re-evaluate the points.
The team then
waste invest another afternoon re-estimating the points with lower numbers.
This cycle continues until the CTO is happy that we can do the work in the arbitrarily allocated time-span, according to the scientifically proven Agilist burn-up chart.
Reality is irrelevant – it’s all about the points. If the points say it’s possible, then it can be done. So mote it be.
Let’s examine a generic software project.
Firstly, the project needs to be broken down into manageable chunks – each chunk, in our particular Agilist sect, is known as a “Story”. The act of a developer implementing the Story is known by the Agilistas as “playing the Story”. Traditionally each story is initially designated by a post-it note stuck the the wall, although it’s now common to have an expensive “post-it notes stuck to the wall emulator” instead: GreenHopper is such a system and we used GreenHopper at money.moo.
Once you have a set of post-it notes stuck to the wall, the Stories are said to be “On Deck” and the next step is to flesh out each story with a concise description of what it actually means. This involves the BA’s (Business Analysts) and the PO’s (Product Owners) creating AC’s (Acceptance Criteria) for each Story. AC’s are simply lists of behaviors that the software should exhibit after the Story has been Played in order for the Story to be “Accepted”. In principal, the BA’s and the PO’s are experts in the software and fully understand what the customer will require in their UX (User eXperience). They will, as part of this process, ask the art department to produce “Comps” (graphical mock-ups) of each aspect of the Story so the developers know what their final product should look like.
Then, each story is allocated a “Point” score, which is a number that is supposed to indicate the amount of work involved in developing the Story. The more work required by a Story, the more Points it is worth. We’ll discuss the value of Points and how they’re calculated later on, but the number of Points a team can complete in an “Iteration” is known as the team’s “Velocity”. Velocity is related to, but completely different to “Capacity” apparently. Once you know a team’s Velocity you can use this value to plan for development deadlines. If you are mentally ill.
As stories are developed, a QA (Quality Assurance) team is employed to break them by finding bugs. The bugs go back to the developers to fix, and the QA team check them out again. This is an age old, and surprisingly effective, technique because the more bugs discovered before the customers get to find them the better. Obviously a good QA team will find more bugs than a bad QA team, but they instantly render themselves unpopular with the developers (no developer likes to admit they created bugs) and the management (no manager likes the idea of the project being held up). Agile has solved this problem by not assigning a point score to bugs – consequently, in the Agile timeline, they take no time. If you ever find yourself with too many story points to complete in a certain amount of time (based on your “Velocity”), simply turn the stories into bugs and the problem vanishes! It’s like magic!
Even a complete simpleton would see the advantages of this as a way of measuring progress and performance. Whether this simpleton was capable of recognizing the number of ways the idea is profoundly flawed is questionable. For the benefit of readers resident in the class of complete simpleton, there should be an appendix containing explicit descriptions of the flaws at the end of this text.
All you need to know at this point is that, as far as the Agile Bishops are concerned, if your team has the “Capacity” to “Play” all of the “Stories” in a specific time-span, then the time-span is realistic. Don’t. I know. We’ll talk more later.