Human Issues of
Agile Processes
Hans Wegener
Credit Suisse
Financial Services, Postfach 100, 8070 Zürich, Switzerland
Phone: +41 (1) 334 66 51, Fax: +41 (1) 334 50 60, Mail: hans.wegener@csfs.com
I just copied the workshop questions from the call [1] and only address the ones which I have experience with.
Discipline is only a means to reach a certain goal: quality. Quality assurance can take three forms: measurement, review, and discipline. Measurement is the most accurate and reliable form, and it can sometimes be automated. Reviews involve other people (peers or nominated reviewers). These are less reliable, but process improvement activity can increase reliability. Discipline is the weakest form of quality assurance, because it can not be spotted directly when it escapes the attention of the individual. Only its effects can be made observable, e.g. through measurement.
Discipline is not a goal in itself. To the contrary, it is to be avoided as much as possible that the process depends on discipline, because quality can be affected negatively. However, measurement and reviews are sometimes costly countermeasures as well, and not a silver bullet at all. Each project must weigh the advantages and disadvantages in order to maximize achievable quality in the face of change and cost.
In my opinion the question should be phrased differently: "How can I build trust between customer and developers?" Any informal way of dealing with contractual relationships carries the risk of being abused or to degenerate to one party's disadvantage. Both customer and developers must be able (and willing) to work towards a common understanding of the problem at hand [2]. To do that, they must agree on the method of getting there. Whether that is a formal, rigidly defined method or an informal, weakly defined one depends on the needs of the contract partners. The answer can not be generalized.
It requires one to be very attentive, technically well educated and socially apt. When things go wrong you must react quickly and couraged. The readiness to deal with the tiniest details to solve the worst problems must be present. You can not go and say: "This is none of my business." Especially in organizations with a strong division of labor this can be difficult, because you steadily step on other people's turf. This can be unnerving. Talking of which, a high degree of frustration tolerance is yet another must.
I think it would be wrong to mix skills management and development process, because they're orthogonal. However, some processes lend themselves easier to skills development. For example, in XP it is considered bad style when you just do architecture or databases or user interfaces. Someone with a strong desire to specialize would have difficulties finding the right spot in such a team. Generalists, however, would have it easier to find themselves at home. Maybe the question should be: "Can agile processes create specialists and will we ever need them?"
I think this requires pretty much the same answer as: "What does one need to know about design patterns?" Having experienced disaster and failure is the best antidote against bad practices. This is the same for development processes: having gone through death march projects tells a story one shall never forget. Novices can only be educated to a certain degree, and growing their professional discipline takes time, attention, and above all a good role model. This is all very difficult. On the other hand, some personalities are more eager to do good work and strive for excellence by themselves. If they listen carefully and put into practice what they hear directly, things get much easier.
Outsourcing should only happen when the architecture is stable and requirements clearly defined; I wonder when that is ever the case in a project that requires an agile process. Offsite development automatically impacts communication, which is crucial when design issues have to be discussed. Therefore, to me the question: "Under what circumstances would you consider architecture and requirements well-understood?" should be answered before considering outsourcing.
There is no ultimate contradiction between agile and enterprise, but to a limited extent between agile and large. Scaling an agile method to me certainly means that parts of the problem domain and the software architecture can be considered stable. These can demarcate borders between individual agile teams, which act mostly independent of each other.
A completely different issue is requirements and growth: any large-scale enterprise application project I have seen started with unclear requirements and lots of people. Large organizations seem to fancy such projects, for what reasons so ever. All this is impossible to manage in an agile fashion.
Therefore, my credo is: "Start small and grow big slowly [3]." It is clear that this is very difficult to achieve.
1. http://www.coldewey.com/publikationen/conferences/oopsla2001/agileWorkshop