Mostly Agile

Does this ever happen to you?  Friday night I was engrossed in my project.  I was coming off the back of a sixty hour week in which we’d crushed a multitude of bugs, increased test coverage, and performed some great refactoring on our presenter classes to expose code for coverage and consumption much more cleanly.  I was in the code, I was breathing the code, I was the code.  After a fun Friday night and great weekend I arrive at work this Monday morning refreshed, ready to go, and with absolutely no clue about what I was doing last week.  I look up and down the active bug list and find its pretty clean.  I scan the solution for signs of life; yup, there’s some code in there and it is apparently ready to do something.  It’s time to fill up the Nalgene, take a quick walk around the block, and then check the schedule.

Unfortunately, we’re only implementing part of an agile process, something I don’t have direct control over but have influenced to the best of my abilities.  While we have iterations, a backlog, something approximating sprints, and a bug resolution workflow, we don’t really have them filled out in any cohesive manner.  There’s a lot of information there, and a lot of contradiction too.  It’s a sort of hybrid between the waterfall model and the agile process.  The entire project’s worth of requirements, iterations, and tasks were entered on day one.  As the project has progressed and been refined, the initial requirements and tasks haven’t always stayed in sync because let’s face it that would be an insurmountable chunk of work to do every week.  Unfortunately, this leaves us with agility in terms of project scope, and very much a lack of agility in terms of project planning and tracking.  Last week was a focused grind because a specific set of needs were identified and the fire hose was activated.  I blasted through an incredible amount of code and tasks but now I find that this morning the hose has been reduced to a trickle as I weave my way through four of five different versions of the truth in search of the next blast of work.

This is something I’ve seen in a couple of places that I’ve worked.  It leads me to believe that the source of the problem is that processes such as agile development promise a lot of benefits making people really keen to get on board.  However these processes, for all the good they can do, can lead to more bad than good if not followed carefully.  The danger is to believe that the process itself will solve the larger problem and that implementing 80% of the process will yield 80% of that safety.  Not true!  Eighty percent of the process can be just enough to mask the underlying danger that your project is actually way out of control.  It looks good on the surface to have things like iterations, continuous builds, sprints, backlogs, and standups flying around, but then someone asks “Where’s the single version of the truth on xyz requirement?” and suddenly the comfortable feeling falls away.  No-one knows because the incredible overhead of filling out countless task lists, schedules, work items, and requirements has left little time to keep all of these pieces of information up to date.  Furthermore, because of the massive effort that has already been invested, people are less willing than ever to entertain discussions directed at clarifying this information.

The result is that the wealth of electronic information that has been generated and entered into various systems remains heavily under-utilized.  Unless the information is quickly and easily digestible it quickly loses value.  Instead we tend to operate more by word of mouth than by sprint plans or backlogs.  In essence, we’re maintaining a kind of verbal backlog and sprint plan by having morning conversations disguised as standups.  It works, the software is being built, and QA have a high confidence in the builds they are receiving.  It’s just interesting to reflect upon the process and see what happens when only part of a development process is embraced.  It is also useful to remember that the “wealth” of certain set of information cannot be judged by its size, or even by its accuracy (see the complete version of Oregon Law for an extremely accurate and completely indigestible source of information).  In my mind, the relative value of information is the ability for that information to be digested and understood in the shortest amount of time possible paired with the ability for that information to be kept up to date with the minimal amount of effort.  Information is very much like code in that respect : the shorter and clearer a piece of code is, the easier it is to test and maintain.  Similar tenets should be kept in mind for information.

This entry was posted in Uncategorized. Bookmark the permalink.

Leave a Reply

Your email address will not be published. Required fields are marked *