A Commonplace

What is a commonplace?

IndexNextPrevious

30/9/2017

Sun, 27 Jul 2014 11:25:22

Managing Agile by Managing the Box

I'm currently putting together a training course that follows the syllabus of the BCS Agile Foundation.

It's an interesting process, because it involves going back and reading some of the original sources. And for, me, it's made me think a lot more deeply about the notion of "empirical process." And it's made me realise what a difficult concept this is, both to teach, and to comprehend. I bought a few of the books that Ken Schwaber references in "Agile Software Development with Scrum" - one of them is a book about engineering system control. It's an enormous book, and I think, there's only one page, that is actually useful from the point of view of software development. But still, I think it might be useful, just for that one page. And of that one page, I think there might just be one sentence that I've started to think might be the most valuable - "treats the process like a black box."

The idea is that some processes are just too complicated to control directly, so, rather than control them directly, you just focus on inputs and outputs. You start to think about this from an Agile software development point of view, this becomes really interesting.

What's in the box? - the software development team - this includes the business analysts, the developers, the testers and also the UI people (I think).

What goes into the box?

Prioritised requirements - this is the job of the product owner - to supply the box with prioritised requirements.

What comes out of the box?

A bunch of things

  1. Working Software for the product owners to respond to

  2. Reports of progress - this is a bi-product of looking at the working software.

  3. A list of escalated impediments that the team in the box say is slowing down the process.

What I find interesting is that all of these inputs and outputs tend to be problematic.

"Yes we absolutely need this software by this deadline that we thought up all by ourselves without any regard to the capacity of the team. No, we will do nothing to help provide you with an environment where you can develop it. In fact we'll supply security 'experts' to hobble your every attempt to find a solution."

This is what doing this exercise has made me realise:

One of the most appalling and upsetting tendencies that I've been witness to now, multiple times, is project managers opening the box, or the other thing that I've seen recently is an attitude of "We're paying for the box, we should be able to say what happens in it."

When the project doesn't go well (and how could it under such circumstances?) this is when we get the dreaded hourly-status meetings and other measures absolutely guaranteed to produce failure such as requests for the development team to record their time down to the hour.