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.