Why Methodology at All?


At this point it is appropriate to review the reasons for spending so much energy on methodologies at all, because they are the cause of so much argument and frustration the world over.

What a Methodology Addresses

A methodology addresses "how we work around here." As such, it can serve several uses:

1. Introducing new people to the process

"Hi. How do we work around here?" is a natural question for new team members to ask. It is helpful to have something available so they can learn their place in the organization.

Methodology in a Drawer

On my first hardware design project, my team leader told me,

"We draw the gates and ICs on these D-sized sheets of paper, name at the bottom left. We use only symmetric clocks, triggering on the rising edge. We put our drawings in the drafting department's cabinet, second drawer from the top. Let me know before you do that, though, and we'll schedule a design review . . ."


Even experienced people coming onto the project need to know how to play into the process in action.

2. Substituting people

Although people are not plug-replaceable, they often do need to be replaced.

Methodology on the Job

A colleague was being hired by a contracting company he didn't know, to do some proposal work in a field he didn't know, for a client he didn't know.

The contract lead sat with him for two days reviewing the company's methodology: who produced what, how the work products were structured, what standards were needed, what his priorities should be, who he would talk to.


I found this an impressive use of methodology. My colleague will walk onto the project and be useful in less than four hours, even though so much of the work will be new to him. Contracting companies make the most use of this aspect of methodologies.

3. Delineating responsibilities

A methodology indicates what is not part of a person's job. Thus, XP states that decisions about a story's priority belong to the customer, not the programmer; design estimates are made by the programmers, not the customer.

4. Impressing the sponsors

This force drives construction of thick methodology manuals.

Consider two companies bidding to do work for you. The first says, "We have this carefully thought through and documented process that we have used many times. Here it is in these boxes of binders."

The second says, "We sit close together and trade notes, without writing anything down. In particular, we don't need to write down our methodology, because we are all responsible individuals."

Which would you hire?

The force plays on the natural assumption that a heavier and more precisely choreographed methodology is "safer." It is a nonnegligible factor in the awarding of contracts, even if the process used on the job is not the same as the one that is outlined in the manuals.

5. Demonstrating visible progress

Related to impressing the sponsors, the purpose of the methodology may be to allow the contractors to show their sponsors what they have been doing.

In the methodology my colleague was being taught, a key element was to produce something visible every single day so that the sponsors would know that they had been "making progress."

Exercise for the reader: Reconsidering XP in this light, ask yourself what an XP team could show every single day to demonstrate visible progress to the sponsors.

6. Curriculum for education

After a methodology names techniques and standards for people to use, courses can be found or designed that teach skills around those techniques and standards.

For example, the people can be sent, according to their job responsibilities, to develop skills in writing use cases, facilitating meetings, semantic modeling, programming, and the use of various tools.

People can be sent to learn standards that will be used. The organization might center a class on the subset parts of UML they expect to use or perhaps a variation for real-time systems.

How to Evaluate a Methodology

In light of the above, how might you evaluate a methodology?

You would first ask why the methodology exists, and then what game you are playing. Based on those you might evaluate the methodology for:

  • How rapidly you can substitute or train people

  • How great an effect it has on the sales process

  • How much freedom it gives people (or how constraining it is)

  • How fast it allows people to respond to changing situations

  • How well it protects your organization from lawsuits or other damage

You have undoubtedly noticed that the principles of methodology design presented in this chapter are oriented toward designing methodologies whose priorities are being productive and responsive to change.

I leave as an exercise for another author to capture the principles for methodologies that enhance sales, substitutability, and safety from lawsuits.



Agile Software Development. The Cooperative Game
Agile Software Development: The Cooperative Game (2nd Edition)
ISBN: 0321482751
EAN: 2147483647
Year: 2004
Pages: 126

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net