Feed on
Posts
Comments

Heading home on the subway after a late meeting, and picked up the free evening newspaper. I was standing on the platform flipping the pages, reading headlines, and glanced up to see a familiar face on the platform looking back at me with that “don’t I know you?” look.

“Vladimir, how are you?” I exclaimed, shaking hands with a fellow networking buddy. We quickly caught up on where we were, what we were doing. Vlad had now landed a role with one of the big consulting firms after a lengthy stint consulting overseas.

“You’re doing Project Assurance? What’s that?” he asked me. He got my elevator speech –  “Project Assurance helps manage risk and improves delivery confidence” – and how we’re more than an audit service, think of us as the family doctor going along for the ride for the life of the project or program. Fire Prevention hopefully, more than Fire Fighting.

The subject of waterfall versus agile development arose. Vlad was learning the ins and outs of their in-house Agile development practices. He was curious about my experience with Agile. I pointed out I did have a recent experience with an Agile development team, where work was outsourced to a local company. My experience was the developers liked Agile because they could rationalize not developing any documentation, after all it’s about developing code quickly, and documentation just gets in the way. Which is anathema to me. (I am a big fan of what my friend Julie strongly preaches, “If it’s not written down, it doesn’t exist”.)  Based on that experience, I explained to Vlad, my spidey senses start tingling whenever I hear ‘Agile’.

Vlad commented with a similar observation (!). When he asked the inhouse Agile developers about documentation, similar response, “Oh we don’t produce documentation.”

Generally, Vlad and I agreed that the customer – the person signing the cheques, you know, paying the bills? – has the right to documentation. At minimum, proving traceability, from requirements to code to testing. And also to provide a blueprint for maintenance and enhancements. “The code is the best documentation”, just not acceptable to Vlad and I.

Also, a stated advantage of Agile is that code would be reviewed with the customer on a daily basis as it was being built. But I never saw that happen, on a daily or weekly basis. So, what did I see? Weak waterfall, minimal documentation, rebranded as Agile.

I trust you can see why I might grimace when I hear the phrase ‘Agile development’. I hope you do too, enough to read up on what proper Agile management is intended to be. And don’t let the coders bully you (especially if you are or represent the person signing the cheques) that documentation is not required. In fact, build it into the SOW and into the cost of services.  Without this, you are open to being held hostage by the developers. You then have to talk to them to learn or know anything, which is an unreasonable risk for any corporation to accept. When they depart, you will have no documentation on the system for maintenance or enhancement. And while we can make many excuses for this happening decades ago, no excuse for this happening in the 21st Century. We are supposed to be smarter.

And I reached my stop before Vlad did and we parted company. But not before we made plans to get together in a few weeks after he’d settled down again after returning home for good.

4 Responses to “When ‘Agile’ isn’t really Agile”

  1. Maybe your developers would benefit from a review of the Agile Manifesto.

    The Agile Manifesto speaks about valuing working software over comprehensive documentation. These words were carefully chosen.

    We do not value working software over documentation. We value working software over *comprehensive* documentation.

    We do not justify the absence of documentation through the delivery of working software. We value working software *over* comprehensive documentation, recognizing the value of both.

    In a previous life, I insisted on delivering comprehensive documentation. I came unstuck and became a “the code should speak for itself” nazi. Then I met a bright guy called Ryan Lemmer who taught me agile documentation.

    Now I write broad overviews that feed into a few very detailed descriptions of critical areas. I focus on documenting that which is hard to change (architecture); critical processes and interactions that present valuable starting points for further exploration of the code; and undesirable compromises and transient design.

  2. Vin D'Amico says:

    I agree that documentation is often needed even if only to satisfy the compliance police and the auditors. The unanswered questions relate to the type and quality of the documentation.

    For example, if we have a whiteboard session, is it okay to record the event and call that the documentation (assuming everyone present agrees to the recording)? Or what if I simply take a picture of the final drawing and save it along with a few notes, is that good enough?

    I think the reason that “documentation” often gets a bad rap is that we spend too much time on it. Making it look pretty can be hugely expensive. In addition, mountains of project documents are often redundant, vague, contradictory, and just plain wrong.

    We need to find a middle ground.

  3. Joe Caruso says:

    Sheldon – thank you for your words of wisdom. While I have glanced at the Manifesto, I have not critically reviewed it for what qualifies as ‘agile documentation’. I shall followup. Thank you again for your contribution.

  4. Joe Caruso says:

    Vin – thanks for your input. I agree on the middle ground viewpoint, i.e. what is good enough. Thank you for your contribution.

Leave a Reply