The need for people-centric software processes
Having a software development process or methodology -- although not completely adhering to it -- is better than not having one at all. Traditional software development methodologies spend a lot of time and energy in resisting change. The guys who thought up agile methods like eXtreme Programming, Crystal, Scrum etc. figured that out. These process thrive on change and are hence adaptive, in contrast to the traditional predictive model. There is one other big big [Yes, I did say that twice for emphasis] difference though. Agile methods are people-oriented rather than process-oriented. They look at the process as existing to support the development team rather than the other way around.
But enforcing this "people come first" philosophy is much harder than it seems. It goes against the grain of conventional management theory. But not everything that is appropriate to the manufacturing industry is completely applicable to the software world. In order that a process gain acceptance from the development team, it must aim to empower its target community. Anything different will be resisted. It is important therefore that software processes be flexible enough that developers see real value before they jump headlong into accepting it. Even as XP is an adaptive process, it requires a lot of discipline to execute; most developers -- including me -- would resist some of its tenets and would rather prefer something like Crystal which aims at being less disciplined.
Martin Fowler provides this topic a great treatment here. He suggests
And then there's Alistair Cockburn's analysis which categorically rejects the view that people are easily replaceable "parts" in a software process. That article can be found here.
In the end, agile processes attempt to fill in the gaps left over by the Rational Unified Process. And do a good job with it. Their version of technical leadership is a marked shift for most managers [Jad Bitar that does not include you!] who'd rather stick to the familiar confines of traditional models. If you have ever-changing requirements [who doesn't?] and a motivated development team who like to get involved in the decision-making process, then I highly recommend taking the adaptive process route.
But enforcing this "people come first" philosophy is much harder than it seems. It goes against the grain of conventional management theory. But not everything that is appropriate to the manufacturing industry is completely applicable to the software world. In order that a process gain acceptance from the development team, it must aim to empower its target community. Anything different will be resisted. It is important therefore that software processes be flexible enough that developers see real value before they jump headlong into accepting it. Even as XP is an adaptive process, it requires a lot of discipline to execute; most developers -- including me -- would resist some of its tenets and would rather prefer something like Crystal which aims at being less disciplined.
Martin Fowler provides this topic a great treatment here. He suggests
...the developers must be able to make all technical decisions. XP gets to the heart of this where in its planning process it states that only developers may make estimates on how much time it will take to do some work.
Such technical leadership is a big shift for many people in management positions. Such an approach requires a sharing of responsibility where developers and management have an equal place in the leadership of the project. Notice that I say equal. Management still plays a role, but recognizes the expertise of developers.
An important reason for this is the rate of change of technology in our industry. After a few years technical knowledge becomes obsolete. This half life of technical skills is without parallel in any other industry. Even technical people have to recognize that entering management means their technical skills will wither rapidly. Ex-developers need to recognize that their technical skills will rapidly disappear and they need to trust and rely on current developers.
And then there's Alistair Cockburn's analysis which categorically rejects the view that people are easily replaceable "parts" in a software process. That article can be found here.
In the end, agile processes attempt to fill in the gaps left over by the Rational Unified Process. And do a good job with it. Their version of technical leadership is a marked shift for most managers [Jad Bitar that does not include you!] who'd rather stick to the familiar confines of traditional models. If you have ever-changing requirements [who doesn't?] and a motivated development team who like to get involved in the decision-making process, then I highly recommend taking the adaptive process route.
0 Comments:
Post a Comment | Home | Inference: my personal blog