Process over results…

I seem to be stuck in a run of “process over results” – that is, organizations that are far more interested in getting the practices and techniques right without understanding what results these techniques are designed to deliver.

Let me give you an example. I was recently working with an established team who had a fairly poor history of delivering working software. Their iteration planning meetings run on-time and with the right people, their standups never go over 14 minutes, their stories are in the classic “as a….I want….so that….” format, and they have retrospectives at the end of each iteration.Yet they constantly fail to deliver software. Hmmm….

After only a little digging, I found what could be the problem – in this organization, it is very important to be seen to be working, as opposed to taking the time to plan what I should do next to be most effective. Consequently, the developers open multiple stories each, working on these stories in no particular order, or even focusing on finishing anything. I discovered one developer working on 20 stories at the same time – and delivering nothing!

Add to this that their testing organization (even typing that phrase is painful, as the testing folks must be part of the delivery team, not a separate function) is 2 timezones away, and with very little interaction (they rely on Jira to schedule all testing, even during an iteration), and you can see why they carry-over multiple stories every iteration.

Later that same week I had the opportunity to sit-in on a management meeting to discuss what was wanted in the next quarter – a chance for IT and the business to collaborate, and determine the most valuable things to be delivered. Sadly, it didn’t go that way. Nobody actually led the meeting, with one person asking “OK, so who called this meeting, and why are we here?”. Now, not being known for my shyness, I decided to hijack the meeting, and explain to the attendees what they could accomplish if they so wished. We then proceeded to spend the next three hours talking about business issues, and having the technology folks participate in how best to solve them. This was something they had never done previously.

Later, I talked with the VP of Product Development (from the business side of the house) and the VP of Technology. They told me they had been directed to “be agile”, but with no direction, no expectations, no training – but “being agile” was now one of their performance metrics. So what did they do? They simply added the word “Agile” to everybody’s job title – Agile Business Analyst, Agile Tester, etc. – but measured and performed in their old (broken) way. Sigh…

What, after so many years of agile development, do organizations still do this? And why do we – the agile community – allow this to happen?

And this organization I mentioned above? Yes, they went through some training, and with coaching managed to start delivering within fairly short order – and they are starting to spread this approach across the rest of the organization. Everybody loves success, but too often we are reluctant to risk a small failure even if it can yield tremendous results (double sigh…).

 

 

Leave a Reply

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