There is no conflict in these statements. The problem is with the organization.
Change In A Change-Resistant Culture
If, for example, I plan a release in 10 months, and assign each of my developers a ten-month task (or a couple of five-month tasks) then I am not only at capacity, I'm likely well over and don't know it.
Now, in month two I have a change I would like to see. I can't get any of my developers to put aside their work and take my task. Those obstinate developers!! What's wrong with them?
Nothing is wrong with them. They are doing the work they are assigned, and since they have no slack or reserve capacity they know that the new task puts their release in jeopardy. They also know that they are being reviewed, graded, rated, and ordered by their ability to get those assigned changes into the next release.
If they drop a task to do the new work, they will fail.
If they don't, then they'll be deemed uncooperative which also will possibly cause career damage.
They can work overtime to do all the work that they were assigned (which is probably an ambitious goal anyway) and try to absorb the new change by stealing time from their significant others, sleep periods, side projects, and other obligations but this will make them less likely to recognize shoddy work and less eager to correct it.
Assigning work this way creates a reserve-free system in which any response to any change is costly both professionally and personally. No wonder developers become demotivated.
Embracing Change In Healthy Organization
Instead, what if we have a release in 10 months (or so). We break all the features into pieces, where each piece is valuable to the end user, but each one can be completed in a week or two. Maybe there's an admin screen, a data entry screen, and a small bit of processing for the first feature. Rather than assign these to an individual (tying up his next few months), we assign it to the team as a whole. Now each of the people working on this feature will come "free" (ie. have completed a task) in a week or two. They will be able to switch pair programming partners, take on new features, make revisions, etc.
Now I can introduce changes between tasks, or instead of planned tasks. These task boundaries are frequent, so change is much more welcome. In addition, a developer is only committing to one change or feature at a time, and so only an uncompleted feature is at risk instead of the programmer's career.
In addition, the code for a completed feature is available much sooner, so that it can be tested, demonstrated, and evaluated. A few months in, it can even enter an alpha-testing program to get end-user feedback and determine the effect of the change on performance and scalability.
Smaller Assignments Are The Secret
If you can't accept change, it is because the work assignments are too large. If you are going to want changes often, then you need to have "change injection opportunities" more often. If changes are daily, then every day there should be some programmer(s) coming available to make the changes. Furthermore, they must be at work in a system that does not punish them (career-wise or by depriving them of the things they hold dear personally) for accepting orders for change.
You don't have to have an Agile organization or an Agile team to harness the power of smaller work assignments. There have been many methodologies, including some from very large contracting companies, who have long touted "a series of small successes" as the way to best ensure success of a project.
Early feedback is also known pre-Agile to be important to a good user experience and to dissolving contract discomfort.
The trouble is that working this way erodes the strong central authority many managers have enjoyed, and which may have brought them respect as "strong leaders" in the eyes of their managers. That is a topic for a whole different conversation.
If your development organization can't accept change without interruption and multitasking, then:
Your work assignments are too large, too personal, and too well enforced.
No comments:
Post a Comment