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 reflex that a heavier and more precisely choreographed methodology is "safer." It is a non-negligible 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 around the subset parts of UML they expect to use or perhaps a variation for real-time systems.
Evaluating 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.
Start by recognizing that no single methodology definition can possibly suit all projects. Don't even think that the Rational Unified Process, Unified Process, or the Something Else methodology will fit your project out of the box. If you follow a methodology out of the box, you will have one that fits some project in the world, but probably not yours.
Practice noticing how the seven principles of methodology design relate to your project:
· Look for where your team could benefit from using warmer communications channels and where cooler ones are needed.
· Identify the bottleneck activities on your project.
· Track them as they change.
· Invent ways to utilize some other group's excess capacity to streamline the bottleneck group's work or to reduce uncertainty.
· Reduce the internal deliverables on your project:
· Arrange for higher-bandwidth communication channels between the developers and opportunities for rapid feedback, and you will find that some of the promissory notes are no longer really needed.
· Find the bottleneck activities, and see if you can trade efficiency elsewhere for increased productivity at the bottleneck station.
· Find a place where lightening the methodology would actually cause damage. Think about what might be an alternative.
· Review the list of purposes of a methodology. Evaluate the purpose of your group's methodology, and then rank its effectiveness with respect to that purpose.
· Practice naming the scope and elements of your methodology and other methodologies. Observe how much they differ due to addressing different scopes or different priorities.
· Look at the different methodologies in use on different projects, and evaluate them according to how they address their different project sizes.
· Experiment with the difference between problem size and project size.
· Can you think of a project that had more people than it needed?
· Can you think of a difficult problem that was turned into an easy problem through the application of some particular point of view?
Level 2 readers:
· Add these ideas to your bag of tricks.
· Learn where to apply, adjust, and drop them. Level 3 readers: See if you can explain these ideas to someone else.
The pieces of the puzzle are in place. We have seen Software development as a cooperative game of invention and communication.
People as funky but good at looking around and taking initiative, communicating particularly well informally, face-to-face Methodology as the set of conventions the team adopts, with different conventions suiting different sorts of projects Light methodologies as delivering more quickly, but having to become heavier as the team size grows Projects as unique ecosystems, a project's methodology needing to fit the project ecosystem.
Everything fits together neatly, except, How light is right for any one project, and how do we do this on our project?
"Light but Sufficient" discusses how light is right for any one project, in particular, what it means to be too light. The target is to balance lightness with sufficiency.