I am not a team member, I am a free resource!

I’m developing a very strong dislike to the often corporate-speak in which people get referred to as resources. I think it’s OK when doing high level planning and you’re working out roughly what you can fit in over the next few months and if there are any skills or resource(!) holes that need plugging. By the time that individual teams and people are being talked about working on an individual project you’re not dealing with resources any more, you’re dealing with people. And people do things which upset project continuity like go on holiday, get sick, have good and bad days and just (and you should even know about this one up front) different areas of expertise.

Project running late? Add some resource. Need to mitigate against some risk? Add some resource. It’s another face of the mythical-man-month and neglects that they’re going to need to be brought up to speed and that, even in some of the most parallelizable of jobs, communication overhead means that you won’t get double the work done. People frequently coming and going on a project can make velocity hard to measure and can hide potential trouble with delivery dates. I’m sure that even people who do this kind of thing know, really, that this is true. But resourcing projects instead of getting people to work on them encourages this kind of thinking long after it’s a convenient shorthand for planning.

Too agile

“Lately we’ve been too agile”.

It’s not true, of course, but it does highlight a risk that isn’t immediately apparent when attempting to introduce agile processes into an organisation. That to different people, the term ‘agile’ can mean very different things.

To me, the core principle of all of the agile processes, and what the agile term actually means, is building anything in short cycles and reducing the feedback and change time to within that single cycle. At the shortest time it’s test driven development, and the cycle time can be down to a few seconds. At the very longest it can be several weeks, as individual projects get delivered and future work can build up on it but would typically be the 1-2 week pulse of an iteration. Any of the methodologies are to put processes around development that allow these cyclic events to occur and to manage the change they introduce. To anyone used to working with agile processes, the details may differ, but the big picture is the same.

To people not used to agile, the term will be overloaded with ideas they already have. These may not even be from agile development. Quite simply, you have very little idea of what someone else may mean when they say ‘agility’. To some it may simply mean being able to change frequently and without any real agile processes in place to support that change, then it simply represents risk. This could be a real problem to a project you’re running – if they are a stakeholder on your project they may attempt to impose far too much change into it and with the belief that it is not a problem or that it is even advantageous and can take a great deal of skill to manage successfully. Longer term this can damage agile processes’ reputation in an organisation, leading to attempts at agile development eventually being abandoned or a company believing itself to be agile while carrying on with uncontrolled, modified waterfall style development. Either will not be pleasant.

It’s probably better to not use terms like agile unless you are very sure of the audience or can agree up front (!) on your shared definitions. You can pick a specific methodology and implement as much of that as possible, and stick to the terminology it uses. The more specific and less familiar terms such as sprints, iterations, user stories, burndowns and so on leave much less room for differences in understanding and should make the job of selling the ideas if not easier at least more measurable.