Author: Simon Papson

Rhinestones Look the Same as Diamonds…

I was recently working on a project team of three: two developers and me. One of the things we had in common was that all three of us are perfectionists (in our various ways).

I noticed this trait in one of the developers early on: every button on every screen that he produced was aligned just so, the fonts were sized just right and the colours were the ideal shade. Similarly, the other developer enjoyed refactoring code just for the sake of making it more elegant; he loved the idea of working on a  section of code for hours at a time to reduce it to just a single line. And I, the BA-cum-tester—if a system contained any defect, however small or esoteric, I rooted it out. Corner cases were merely a starting point for me!

This perfectionism led to us deliver absolute diamonds of features; between the three of us, we were producing an utterly perfect system. Which is something to aspire to, isn’t it?

Like every project, we were operating within constraints. In terms of the time-cost-quality project triangle, we were limited in cost and extremely limited in time. The business was desperate for a working version of the system we were developing: last year was too late (no exaggeration!). And, in this context, we were making quality the highest priority.

Luckily, we had a project manager who wasn’t afraid to shake things up when necessary. So, he made us all sit down and assess our performance to identify and fix the problems that were slowing us down. As a result of this exercise, one of the problems we found was our drive for perfection (naturally!).

For example, whenever a story was “developer-done” and passed to me for the first round of user testing, I would put it through its paces and pull it to bits. No defect was too small, no niggle too minor. And, the minute I found a problem, the developers would compete with each other for the chance to fix it. “Zero defects” was our goal!

Some days, we would find ourselves caught in a cycle of UAT – defect finding – defect fixing – UAT – defect finding – etc… with no development being done on new features.

No wonder we were delivering so slowly! Our perfect diamonds of features were being formed over near-geological timescales, just like actual diamonds.

So, we changed, and one of the things we threw out was our commitment to “zero defects.”

Defects were then put through a triage process. Did it stop the system running? Did it cause the system to produce the wrong result? Would it cause difficulties for the users? Would the end customers notice the difference? If yes, then it must be fixed, by all means!

On the other hand, was it just cosmetic? Did it only occur under extremely rare circumstances (just how often do all the planets align in a single line, anyway?)? Could the users still get the right result? Would the customers still receive the right information?

No one was saying that the system should have defects. We merely decided that some defects could be lived with in the short term, in the context of a system that must be delivered in working condition as soon as possible. We could (and would!) fix all defects over time. All we did was prioritize the defects that must be fixed now over those that could be fixed later.

And, if the users don’t notice, and the end customers don’t notice, and the system is fit for purpose, then who’s to tell whether it’s a rhinestone or a diamond? After all, rhinestones look just the same as diamonds… but they cost a lot less.

Don’t forget to leave your comments below.


Simon is a Business Analyst with about 5 years’ direct experience in the BA field, but he’s a spent a lifetime gathering insights in careers as diverse as accounting and pizza delivery – and even acting! He’s worked in both waterfall and Agile environments (and prefers Agile!), in large corporates as well as small businesses. He’s always had the writing bug, too!

An Accidental Agilist

I never set out to be an Agile Business Analyst. It happened to me quite by accident.

For starters, I thought I already WAS an Agile BA!

The corporation I was working in while I learned Business Analysis promoted the fact that its project methodology was based on Agile principles. So naturally, when I was out in the job market and saw ads asking for Agile experience, I applied. Why wouldn’t I? I had Agile experience!

When I started to work at my current workplace, one of the first things my manager asked me to do was to prepare a presentation explaining the Agile methodology to our stakeholders. They were unfamiliar with this philosophy, so it was best for us to explain what this was about before we started the project.

So I sat down and wrote an informative presentation, explaining our Agile methodology: how we’d sit with them at the beginning of the process and document all their requirements; how we’d then go away and work on these requirements; how we’d come back at the end of the development and ask them to test the program. It was a wonderful presentation.

I gave it to my manager for review.

He came to me a couple of days later and asked me to do it again. I was a little surprised but, well, he was the boss and I was the new employee trying to make a good impression. So I revised it and re-wrote it, still explaining gathering requirements up front, then doing development, then getting the users to do their testing.

A few days later, my boss came to me again and explained that our company had an account with an online bookstore, and I might be interested in reading a book that was available there: Agile and Iterative Development: A Manager’s Guide by Craig Larman. Well, why not? He’s paying me — if he wants me to read, I’ll read.

So I read.

I read about sprints and iterations, and just-in-time requirements, and user stories, and story points, and The Agile Manifesto, and prioritising working code over documentation, and preferring response to change over following a plan — this was nothing like what I knew! And, embarrassingly, it was nothing like the presentations I’d written. I went back to my manager and said I’d revise the presentation again.

I then realised that my previous employer had led me astray. Their statement about their processes being Agile was misleading at best — from what I now knew, there was nothing agile whatever about what I learned there.

So I kept reading — every online book and website I could lay my eyes on, including the following:

  • Agile Estimating and Planning by Mike Cohn
  • User Stories Applied: For Agile Software Development by Mike Cohn
  • www.agilemodeling.com by Scott W. Ambler

I had no idea who these people were — I just knew that I needed to learn about Agile, and quickly. Thank you, Google!

Luckily, I had some time: the developers’ start date was delayed due to budget issues. So I read and read and read.

Then the developers arrived and the project started in earnest. The project manager and both developers were experienced in Agile methods. I…was not.

We were using a hybridised Scrum methodology. So I started writing user stories. I helped plan iterations. I sat with the developers and worked with them every day. I wrote test cases instead of requirements documents. I attended daily stand-up meetings. I did none of the things I’d done before; none of the things I was used to. Everything was new to me.

I worried that I didn’t know what I was doing; I stressed every day that I was letting the team down; I tried as hard as possible to work in a way I’d never worked before. There were times when it got too much for me — and I’d take it out on our more senior developer, who would patiently accept my bad temper, knowing that it was directed more at me than him.

However…I adapted. Now, I can’t imagine working any other way. When I attended a BA conference recently and a presenter started talking about how to write a better up-front requirements document, or how to manage change requests, I found myself thinking that this was a silly way to work. Why would anyone waste time writing a big up-front requirements document, knowing that a lot of it would change or even be out of date by the time it was needed? Why not simply write another user story and add it to the product backlog to be fleshed out just in time for development?

Without ever intending to, I made the transition from traditional waterfall to one of the Agile methods.

And…if I can do it accidentally, you (or your organisation) can do it deliberately. What’s holding you back? Fear of the unknown? I didn’t even know what Agile was when I stumbled across it. Fear that you won’t be able to change the way you work? I didn’t know what I was doing, but I managed.

I’m not here to say that Agile is better than waterfall (that’s another blog post!). But, I will say to anyone who is considering making the transition: If I can do it, anyone can.

Don’t forget to leave your comments below.