POSITION STATEMENT FROM PETER HANTOS

Preambles:

(1) While most of the debate is on the published practices of agile methodologies, I believe that addressing and resolving some higher-level, fundamental issues is more important.

(2) Project teams/project managers should have considerable freedom in selecting project management processes and process or engineering tools under any circumstances. Nevertheless, they are not totally little islands to themselves, and all projects have to always operate in a bigger context.

(3) Sincere focus on people’s needs and optimal working conditions instead of giving lip-service should be a primary concern regardless of the chosen development methodology.

Fundamental Issues:

(4) The main, declared reasons for the emergence of Agile Methods are the disappointment with processes, and the characterization of software development as a sequence of repetitive steps instead of a creative endeavor. We have to realize though that the real source of process disappointment is the past abuses of major frameworks, and not necessarily the content of those frameworks. Piece-meal negotiation of practices and processes between Agile and Conventional camps is an exercise in futility. Until the representatives of the Agile Movement receive believable guaranties that the new planned, hybrid processes will prevent abuses by virtue of their definition and people will have a chance to focus on what they like to do and not what they must do, there will be no “peace”.

(5) Software engineering is a social process (although some people like to view it as a collision sport …). Trust is the most critical component of any human interaction. In most cases heavy documentation, policy statements, detailed contracts, reviews and assessments, the long list of verification requirements in the CMM are acting as substitutes for establishing trust between the impacted parties, for example between organizations and their contractors, or managers and their teams. Frankly, just because of the use of lightweight processes there are no guaranties in the agile/extreme teams either that the necessary trust is built. In fact it is very naïve to expect that trust can be created by a mandate. (Shunning documentation, contracts and assessments, and relying only on verbal interactions implicitly mandates a trusting behavior.) Finally, trust has to be earned. Most people in their human interactions would start with a careful stance, and would loosen up only after substantial positive experiences with the other person. There is no reason to think that programmers, teams, and their managers behave differently.

Other important points:

(6) All projects have to comprehend the context they are operating in. The context has a relationship with size, but not in a simple, obvious fashion:

· The straightforward – and commonly accepted – issue is the growing complexity of communication between people when the team grows

· Scaling issues are determined by both the size of the task, and the size of the team. There is an underlying assumption that it will be always possible to pull together a bigger team for a bigger task, but it is not always true. For example at a certain point the organization will trade schedule for manpower, by freezing the headcount but negotiating longer schedules. The opposite can be true too: Even though the generic model for effort distribution across the life cycle is a Rayleigh curve, in practical situations the manpower loading is kept steady, even though the model would call for less engineering involvement.

· In case of stretched projects of artificially small teams maintaining communication is not an issue, but the lack of “organizational memory” might become one.

· Similarly, even if the team is kept small, if it will be engaged in numerous, similar projects in the future, then the rules about dealing only with immediate requirements and implementing only those features the current customer wants might have to be reevaluated.

(7) The attitude toward risks is different in Agile and so-called process-oriented organizations. Agile teams are more optimistic about their ability to deal with any kind of risk in “real-time”. Other kind of organizations and their managers are very risk aversive, and that’s one of the reasons why some of the processes are developed and their performance is monitored. Again, being ignorant toward risks is an attitude on their part and not an oversight. This attitude should be subordinated to the greater operational context, but unlikely that Agile people would make this concession easily.

(8) Agile methodologies do not address two critical levels of the Product Development Framework:

(9) Cross-Functional Project Management and Enterprise-wide integration of Product Development. They are certainly provide an alternative though on the lowest, Functionally Focused Project Level.

(10) Agility is an attractive characteristic. Nevertheless, agile organizational components do not guarantee agile organizations.

***