Brainmoda | Staffan Nöteberg’s blog

Enterprise companies make strategic choices of branded processes like Scrum, Rup and XP. This is not enough since every single project is unique. Still, authorities with investments in process brands claim that their methodology is atomic with statements like:

1. “Any one practice doesn’t stand well on its own (with the possible exception of testing). They require the other practices to keep them in balance.”
2. “Composed of several well-matched, interacting parts that contribute to the basic function, wherein the removal of any one of the parts causes the system to effectively cease functioning”

Guess why?

Circumstances fluctuate

Let’s start with quote (1) above. In 1999, Kent Beck defined the process XP in his book “Extreme Programming Explained”. The backbone of XP is twelve best practices like pair programming and continuous integration. Each practice is explained in detail with rationale and examples. But, according to Beck, the practices don’t stand well on its own. They reinforce each other and need to be used as a take-it-all-or-nothing.

Opposing, Alistair Cockburn spelled out in an article, also in 1999, about a methodology growing technique. He wrote that “It is not the case that the national bank’s Year 2000 project, the space shuttle software project, an overtime food request project, a promotion tracking project and a word processor software project should all run the same way. They differ at least by the he number of people involved, the criticality of the project, and the project priorities.”

Cockburn tightens the boundaries a bit in his 2002 book Agile Software Development: “Every person is different, every project is different, and each project differs internally across subject areas, subsystems, sub teams, and time. Each situation calls for a different methodology (set of group conventions).”

Agile Alliance has declared principles behind their Agile Manifesto. In the last paragraph it reads “At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.”

In Scrum, the reflection meeting is known as a Sprint Retrospective Meeting and is held once a month. Ken Schwaber pinpoints the rules of this meeting in his second Scrum book “Agile Project Management with Scrum” published in 2003:

• The Sprint retrospective meeting is time-boxed to 3 hours.
• It is attended only by the Team, the ScrumMaster, and the Product Owner. The Product Owner is optional.
• Start the meeting by having all Team members answer two questions.
  • What went well during the last Sprint?
  • What could be improved in the next Sprint?
• The Team prioritizes in which order it wants to talk about the potential improvements.

Still, most enterprise companies in the software development industry are very clear on what process they intend to follow. They can name a brand like Scrum or Rup: “This is how we work.” And it’s independent of a particular project’s criticality, priorities and people. Have you ever heard of a company declaring: “We started with a no-process and added practices along the race when needed”? I wouldn’t think so. That’s why most companies only tutor the employees in one single process.

Creationists vs. Evolutionists

Process constructors define their methodologies as irreducible complexity. Enterprise companies also stick to one single process brand. But, the Agile spirit is to respond to change. Remember that Agile in the beginning was called Adaptive. How can you be process smart? The options are:

1. Creationists: Make a really clever choice of process brand for your company – run it out of the box
2. Evolutionists: Self organizing teams armed with an arsenal of knowledge chose their process independently

Alistair Cockburn’s solution walks the evolutionary path: “The trick to fitting your conventions to your ever-changing needs is to do two things, individually and as a team: 1. Bother to think about what you are doing. 2. Have the team spend one hour together every other week reflecting on its working habits.”

If all projects are unique, then there can’t be a silver bullet process that is suitable for a whole company. But, if every project should adapt to its own home made process, then we need to handle problems like diverse education, inter project communication, and company supported tools.

My message is to add the following practices to Cockburn’s two points above:

• Educate the employees in many different processes: Rup, XP, Scrum, Pomodoro Technique, DSDM – the limit should not be the methodology that you happen to implement right now
• Never say: “At our company we do [process brand]” – instead you should say: “At our company we know Scrum, XP, Rup, DSDM, and Pomodoro Technique and we use practices as needed”
• Create small self organizing teams that are free to decide how to work – with deep knowledge of many processes they will chose what suites them best
• Minimize mandatory inter project interfaces – maximize the ease of inter project communication
• Share experiences of implemented practices – keep a forum where project members tell the other projects what lessons they have learnt

Practical Whisdom

Example: Developer goes to one day Pomodoro Technique course. He comes back and says “Most things in Pomodoro Technique don’t fit with our project and culture, but I love the idea of making a To-Do-Today list.” When his team has tried this for a month they share their experiences with members from other projects on the company’s monthly lessons learnt half day.

It all boils down to your belief. What investment gives the best interest; knowledge or strategically, up-front selected rules? Either you think that if all project members are prepared with diverse and deep knowledge, then they will know how to adapt their process to the circumstances. Or else you think that your employees can never have the ability to understand why they are doing something – they just need hard rules how to do their work.

Oh, and what about quote (2) in the beginning of this text? It comes from Michael Behe who follows a tradition of argumentum ad ignorantiam started in 325 AD in Iznik. Occasionally he didn’t think about software development processes at all, did he?

Additional Facts

• Mike Dunford reports that “The Christian schools hired Dr. Behe (for $20,000) as an expert in “biology and physics.” (That second part should make Chad and Rob’s heads explode, given that Behe has absolutely no physics experience of any kind.) To earn his fee, Dr. Behe prepared a report that said, basically, that the Christian textbooks are excellent works for high school students.”
• Cockburn is pronounced Co-burn with a silent ‘ck’. This name is of territorial origin being mentioned in late 12th century as Cukoueburn or Gowk’s Burn in Roxburghshire. The Ragman Roll (1296) bears the name Peres of Cokeburne with seal of ‘a cock walking’.
• Kent Beck received his B.S. and M.S. in Computer Science from the University of Oregon.
• Adaptive processes are also known as “method tailoring”, “method fragment adaptation”, and “situational method engineering’”.