Archive for June, 2010

Zombie Agile: Bad Things Done Right

I currently have the pleasure of working in one of those “waterfall-ish” shops where things actually work: Profitable projects get delivered in fairly predictable timeframes by sane people. They have a fairly “traditional” setup with business analysis folks who write old-style requirements documents (… few if any new-fangled “user stories”…).  These are given to development for implementation, to be manually QA’d by the QA team.  A few lone rangers not withstanding, practically nobody seems to write any tests.

How can this be … ? Aren’t we supposed to TDD/BDD/scrummerize everything, practicing kanbanilism for good measure? Blasphemous whispers in the Church Of Agile; Petty doubts: Have I joined a fringe cult …. ?

So what’s the difference? How do they get away with it?  Situations where I’ve encountered “traditional” software development life cycles that actually worked all had the same combination of traits in common:

A healthy “that was then, this is now” attitude to requirements.  A recent project is a good example: The “traditional” business analyst–produced requirements remained a living document which was updated throughout the delivery of the project. It could thus be relied upon to closely match what was implemented in the code. As much as anything, the habit of keeping it up to date led to many more conversations between BAs and developers than would otherwise have taken place, greatly helping everybody to understand the problem domain.  Very importantly, the document also served as vital input for doing the second part of the trick:

Relentless QA. Unsurprisingly in the absence of automated test coverage, there were many bugs. QA used the “living” requirements document as their guide to making manual test plans. They were very well-organized in executing them and very proactive in sharing the results with the developers. The resulting back-and-forth further helped to grow a shared understanding of the system and it’s requirements.

Smooth Deployments. Calling it “continuous integration” would be a stretch, but they had their builds and deployments organized in a way which allowed for one or two QA releases per week.

Awareness. They were aware of test driven development, the potential advantages of Agile and many of the techniques. However, they had a large legacy code base and many organizational structures and developer habits which did not lend themselves to “Agile” without major changes and a lot of experimentation.  It was a matter of “Koennen vor Lachen” (… German for “Easier said than done”.  It doesn’t translate well.).  Yes, sounds great, but how do we start … ?

Hard to say. Trying to do “Agile” without test-driven development is an extremely hazardous idea.  At the same time doing TDD in legacy situations is a tall order. For a team of developers to start consistently writing tests in brownfield projects takes a lot of new ways of thinking and technical savvy which I feel absolutely has to go hand in hand with appropriate ways of managing the process: Without knowledgeable support and commitment by non-technical stakeholders the effort will die. (Very common scenario/attitude: “We don’t have time to write tests.”)

The practices of “waterfall done right” could serve as initial steps when iterating towards “real agile”. Compared to a seasoned SCRUM / Lean team at their best,  “Zombie Agile” with living requirements, relentless QA and smoothed-out deployments is expensive, inefficient and somewhat dead. Nonetheless, it seems to be delivering a surprising number of good results.

June 19, 2010 at 10:51 am 4 comments

Slides from “Refactoring Towards Sanity”

See below:

PrairieDevCon 2010 – Refactoring Towards Sanity

The free CodeRush VS add-in which seems to do some of what can be found  in Resharper is at:

http://msdn.microsoft.com/en-us/vbasic/ee663901.aspx

I haven’t tried it yet, but look forward to give it a whirl.

Thanks everybody.

June 2, 2010 at 1:59 pm Leave a comment

PrairieDevCon: Sample code for “Refactoring Towards Sanity”

The sample code for the “Refactoring Towards Sanity” can be found here:

https://robertblogs.files.wordpress.com/2010/06/raceresultdemobeforerefactoring-zip.gif

IMPORTANT (and awkward): It turns out that WordPress doesn’t allow uploading .zip attachments, meaning that you’ll have to jump through the extra hoop of right-clicking the link, selecting “Save Link As…”, and renaming the file to RaceResultDemoBeforeRefactoring.zip.

See you at the session.

June 2, 2010 at 5:33 am Leave a comment


Twitter

   @robertreppel