Mental Agility

"Agile" isn't necessarily the same thing as "agile"

Month: April, 2012

What do points make?

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)!


Poker Face

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:

  • Q> What is “a point” worth exactly?
  • A> The value of points is different from team to team. A team needs to decide how much work is involved in a single point and multiply accordingly.
  • Q> So a team may suggest that a point is one developer day, and multiply up accordingly?
  • A> No! Never try to apply points to time periods! That is not the Agile way.
  • Q> So how are we supposed to value what a point is?
  • A> It doesn’t matter, as long as your team agrees. And as long as the work can be fitted into the already agreed time-frame.

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:

  1. The team book a meeting room and go there at the allotted time. The room is invariably occupied by some management bullshit group that takes precedence and so we wander around like brain-damaged chickens until we find a suitable alternative location in a corridor somewhere.
  2. The post-cards are applied to the wall, or the post-card emulator is fired up and projected on the wall by a laptop/projector combination.
  3. Each story that needs evaluating is described by the BA, who has already performed a rigorous and technically complete analysis of it.
  4. The technical people try to understand what the BA was thinking when they wrote the Story, what she actually meant by it, and then modify it in an attempt to make it feasible, by using technical skill.
  5. Once everyone is agreed on what the Story is actually about, the poker begins. All developers estimate a points score – but the score cannot be any old number; that would be ridiculous. The point score must be in the Fibonacci sequence! I’m not making this shit up.
  6. At an agreed time all developers display their suggested scores together. They may do this with fingers, numbers written on paper, or using special Agile Poker Cards that are given out as a booby prize to people who pay millions of dollars for Agile certification.
  7. The median score is applied to the Story.
  8. I’m not making this shit up.

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.

Agilist Basics

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.

Agile, agile and money.moo

One does not simply sit at a computer and write code any more – that is so old fashioned – ridiculous even! Any software worth considering by a bona fide business must now be Engineered(TM) Properly(TM). There are a plethora of engineering “methodologies” available, as any Computer Science graduate will tell you, but only one is really worth considering [as of 2012]: Agile. I have worked for and interviewed with many companies that claim to be “Agile”, and it sometimes seems that project leaders value “Agile experience” more highly than coding experience; but never before my tenure at money.moo have I had to suffer the shameful indignity of a company that has become born-again Agilist.

From what I can tell, the origins of Agile stem from the frustrations of “developers” (the new word for “computer programmers”, the nomenclature that some of us old farts prefer)  in decades past, having to deal with rigid, slow-moving processes in order to create software. Once fashionable methodologies such as Waterfall or Spiral, whilst popular with the management consultants who depended on their massively top-heavy processes to keep them in business, really started to piss the developers off; the ones who did the actual work. Trying to actually get stuff done was becoming increasingly difficult as a result of the heavy management-led process. The thought was that developers need to do their thing, and get feedback from users (which includes QA teams) rapidly in order to address concerns at an early stage; that way they can provide fixes and perform re-engineering where necessary in the face of design problems which only come to light when someone actually tries using the software. If a specification was faulty in practice, the project could be altered and the code changed before any more wasted commitment. Thus was born the idea of agile development, which begat The Agile Manifesto:

We are uncovering better ways of developing

software by doing it and helping others do it.

Through this work we have come to value:

Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan

That is, while there is value in the items on

the right, we value the items on the left more.

There are few experienced developers who would disagree with these sensible ideals. The idea of “agility” (small ‘a’) is key in an industry which moves as quickly as technology, and so it makes sense to us.

Such simple ideas form the basis of many doctrines, belief systems, and religions. Taking religion as an example: even basic ideas such as “be nice to people”, “look after your parents” or “forgive people because we all make mistakes”  will mutate over time as the result of egos, embellishments, and errors, into dogma that requires the cutting of holes in sheets, eating fish on Friday, not eating shellfish, or wearing special underpants. Until recently these splinter-groups could have taken hundreds of years to develop, but now we have the Internet. The Internet has allowed Agilism to evolve into a monster within a short decade.

Now read on…