Topic: Agile management
I wanted to reply to a post on Charles Miller's blog in which (I thought) he had misunderstood the gist of a post about shifting personnel on Mishkin Berteig's blog; a post that had sparked quite a lively exchange. The misunderstanding boils down to the notion that agile methods are rigid and inflexible. Any practitioner would find this odd, since the whole idea of agile development is adaptability and flexibility. But those who haven't lived it seem to be afflicted with all sorts of bizarre assumptions about agile development, based on...well, who knows what they're based on? Anything other than experience, I guess. It seems unfortunate that software development professionals would deny themselves this highly effective approach for no good reason, so I wanted to try and clarify what I thought Mishkin was getting at. Since Charles doesn't allow comments (due to a spam problem), I sent him an email with my comments and copied Mishkin as a courtesy. Mishkin asked me to post my comments somewhere, so here they are, for whatever it's worth:
Charles,
I just came across your Nov 2006 post entitled 'Rigid Agile'. I agree with you that Mishkin's reaction to the idea of reassigning a person was a little extreme. As an agile practitioner, I think I understand where he's coming from. Maybe he didn't express it very clearly.
On occasion, it's necessary to take a person off whatever they're working on to deal with some unexpected problem. That's life. It certainly wouldn't stop the person's team altogether, and (absent other issues that aren't presented in the discussion) would not be the singular cause for cancelling the iteration. Agile teams drive over taller speed bumps than that every day.
But do bear in mind that if the person were not returned to her team promptly (and it is a near-certainty that she would not be), then the team could not realistically be expected to meet its commitments for the current iteration. The Product Owner (or equivalent) would have to be engaged to deal with the disruption, most probably by removing work from the iteration. There is a potential domino effect that could affect other projects and perhaps some of the business goals of the organization for the current fiscal year, or goals for IT portfolio management.
Even so, if an emergency arises then we must deal with it. Dealing with the emergency will not be free of charge, and I think that's what Mishkin was trying to say. Fortunately, we now have methods to deal with such issues realistically, without pretending they won't cause any damage. That's all to the good.
The larger issue, potentially, is that this sort of management can lead to an endemic problem in an organization - the routine shifting of people all over the place for all sorts of reasons, without proper consideration of the impact. The net result is that people never feel much commitment to their work, since they never actually have the opportunity to finish anything, and they never feel as if they are a member of a team for the long haul. They know they're only marking time on some task until their manager shifts them to another task. In fact, this is one of the underlying problems with traditional IT organizations that led to the emergence of alternative approaches such as agile and lean development in the first place.
Mishkin's reaction reflects the fear that we might be stepping onto a slipperly slope. The slope leads back to where we came from...back to old-school problems. I think it's valuable for us to be aware of that slope, even when we can't avoid shifting people around.
Regarding the idea of 'embracing change' - It doesn't mean that people have no idea what they will be working on when they arrive at the office every day. It doesn't mean that there's absolutely no rhyme or reason to the way IT work is managed. It doesn't mean a total absence of planning and subsequent execution.
What it *does* mean is that we want to use methods that accommodate change in a 'clean' way, recognizing that change is the norm and not the exception in IT work, and that the old notion of 'change control' reflects an assumption that change is, somehow, 'wrong'. There is a practical middle ground between trying to avoid change (the traditional approach) and forgetting all about planning and management (the strawman against which many opponents of agile methods rail). Agile methods such as Scrum and XP include mechanisms for handling change, including change that occurs mid-iteration. By embracing change through those mechanisms we can ensure that high-priority and high-value work doesn't get slighted in the rush to deal with emergencies.
It should also be noted that 'change' in the context of agile software development doesn't mean that the team's composition is subject to arbitrary and unplanned change. It means that the team uses methods that are designed to accommodate changes in requirements, schedule, and priorities. Agile teams become more productive as they work together over time. When people can be pulled off teams arbitrarily, this particular benefit of agile methods is destroyed.
The reason is simple - people are people, not 'resources' (interchangeable machine parts). You may have read the now-classic book, Peopleware, by DeMarco and Lister. They don't mention 'agile' methods at all. They do mention the importance of recognizing that people are people, and the importance of keeping well-functioning teams together.
When management thinks of people as 'resources', it becomes natural for them to assume any 'resource' is the same as any other 'resource', and that shifting them around shouldn't have any effect on the results of the projects they're working on. We are all interchangeable machine parts, and nothing more. That's 1980s management thinking. It didn't work in the 1980s, and I doubt it will work today.
Keep up the good work and the clear thinking.
