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
Working Software for the product owners to respond to
Reports of progress - this is a bi-product of looking at the working software.
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.
Product owners (or project managers who are interfering)aren’t available to prioritise the backlog - so don’t provide the box with meaningful inputs.
Product owners (or project managers who are interfering)aren’t available to respond to the working software that comes out of the box, so are unable to provide meaningful feedback.
Product owners(or project managers who are interfering or other senior stakeholders) respond to reports of actual progress with “La, la, la, not listening” strategies (e.g. “I don’t know how you tell that so early in the project.”, “I thought you were professionals who could do the job.”, “I don’t believe that - here’s an exercise to provide me with more detail that will take you six months.”)
Almost everybody who claims that they desperately want the software, will ignore the impediments which are reported which are preventing the software from being developed. This is so common we have a biblical-themed name for it “Bricks without Straw syndrome.”
“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:
when people talk about Agile, they almost always talk about what happens in the box, stand-ups, stories, story-walls.
almost everything that goes wrong, that stops the project being a success, goes wrong outside of the box
You probably need somebody, full-time managing what’s going on outside of the box.
this isn’t the scrum master - he’s managing what’s going on inside, the box, I’m not saying what’s going on inside the box is easy.
when people talk about Agile - they’re normally talking about what’s going on inside the box.
projects are BIOLOGICAL SYSTEMS - so, as I mentioned in my previous article it maybe lines and boxes isn’t the most useful - or the only way to think about this stuff. Maybe it’s more useful to think of the box as cell, with semi-permeable membranes - stuff has to get in and out
magic (working software) happens in the box
No box, no magic.
Customer in box = fox in hen house.
what goes on inside the box if it’s healthy and functioning properly, is quite similar from project to project, what goes on outside the box is completely different in every case.
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.