Home » Agile Process Patterns

Upcoming Agile Patterns Book Online

Filed under [ Agile Process Patterns ]

Recently I was interviewing candidates for a couple of positions on an Agile project. As part of the recruiting process, I had to spend considerable time (aka late nights) going through dozens and dozens of resumes in order to shortlist the ones that seemed promising enough to call for a face-to-face interview.
While going through the resumes, I realized that the more resumes I went through, the more impatient I kept getting. I soon realized that each and every resume mentioned at least once that the person had done a project in an Agile manner. However, there was nothing further to back this up anywhere. It seemed like people were gratuitously dropping the term so that their resume would be picked-up when a keyword search was done.
A handful of candidates seemed to have potential and I decided to call them in for an interview. Big mistake! They were all uniformly terrible and had no Agile experience to speak of. The few that did weren’t really doing Agile — they were CrAgilists (Crappy Agilists)! It was amusing to hear things like:
Our company has been doing Agile since early 2000. (Funny, I did a gig at that same organization in 2007 and their process was as Waterfallish as could be. Also, the term wasn’t coined till 2001.)
We released into production every iteration and our iterations were 10-week long.
We had iterations and depending on the amount of work our iterations were from 2-4 weeks long.
We followed a sequential process (waterfall) within our iterations. After all Agile is about being iterative, isn’t it. Agile is all about welcoming change so what’s the problem if we changed the process to suit our needs.
We did TDD, QA would write the functional tests — for the requirements written earlier by the BA’s — and developers would then try to code and get the functional tests to pass.
After a few of these, I gave up and hired someone from out of state who I had first hand knowledge about.
On introspection, I realized that:
Agilists were far outnumbered by CrAgilists — 6-0 based on candidates interviewed; 38-0 if considering all resumes received.
Most people learned Agile by working on an “Agile” project where the person who was the Agile “coach” had minimal (if any) Agile experience.
The couple who had gone to a CSM course couldn’t apply the knowledge or what little of it they had retained. For them, the certification was simply something to put on their resume.
Uniformly, people had a poor (sometimes non-existent) understanding of Agile principles.
There are a number of well attended discussion boards online. However, the problem with them is that they often don’t meet the needs of novices. People new to Agile are mostly looking for the basics and not for esoteric discussions.
A couple of years ago I had started writing a book on Agile patterns. However, it slipped in priority and was sitting 80% completed since mid-2007. It occurred to me that I could publish snippets online to serve as a resource for people interested in learning the basic principles. The whole series could serve as a readily available guide for those interested in learning why Agilists do things the way they do. Hopefully, this may alleviate some of the issues that I observed.
My next two posts will cover the layout of the upcoming material and a brief discussion of patterns — a proven solution to a problem in context. The patterns themselves will be posted over the next few months, 2-3 patterns a week. Feedback will be highly appreciated and will be worked into subsequent patterns.

Recently I was interviewing candidates for a couple of positions on an Agile project. As part of the recruiting process, I had to spend considerable time (aka late nights) going through dozens and dozens of resumes in order to shortlist the ones that seemed promising enough to call for a face-to-face interview.

While going through the resumes, I realized that the more resumes I went through, the more impatient I kept getting. I soon realized that each and every resume mentioned at least once that the person had done a project in an Agile manner. However, there was nothing further to back this up anywhere. It seemed as if people were gratuitously dropping the term so that their resume would be picked-up when a keyword search was done.

A handful of candidates seemed to have potential and I decided to call them in for an interview. Big mistake! They were all uniformly poor in their understanding of Agile and had no Agile experience to speak of. The few that did weren’t really doing Agile — they were CrAgilists (Crappy Agilists)! It was amusing to hear things like:

  • Our company has been doing Agile since early 2000. (Funny, I did a gig at that same organization in 2007 and their process was as Waterfallish as could be. Also, the term wasn’t coined till 2001.)
  • We released into production every iteration and our iterations were 10-week long.
  • We had iterations and depending on the amount of work our iterations varied from 2-4 weeks.
  • We followed a sequential process (waterfall) within our iterations. After all Agile is about being iterative, isn’t it. Agile is all about welcoming change so what’s the problem if we changed the process to suit our needs.
  • We did TDD, QA would write the functional tests — for the requirements written earlier by the BA’s — and developers would then try to code and get the functional tests to pass.

After a few of these, I gave up and hired someone from out of state who I had first hand knowledge about.

On introspection, I realized that:

  • Agilists were far outnumbered by CrAgilists — 6-0 based on candidates interviewed; 38-0 if considering all resumes received.
  • Most people learned Agile by working on an “Agile” project where the person who was the Agile “coach” had minimal (if any) Agile experience.
  • The couple who had gone to a CSM course couldn’t apply the knowledge or what little of it they had retained. For them, the certification was simply something to put on their resume.
  • Uniformly, people had a poor (sometimes non-existent) understanding of Agile principles.
  • There are a number of well attended discussion boards online. However, the problem with them is that they often don’t meet the needs of novices. People new to Agile are mostly looking for the basics and not for esoteric discussions.

A couple of years ago I had started writing a book on Agile patterns. However, it slipped in priority and was sitting partly done since mid-2007. It occurred to me that I could publish snippets online to serve as a resource for people interested in learning the basic principles and inherent rationale for the practices. The whole series could serve as a readily available guide for those interested in learning why Agile practitioners do things the way they do. Hopefully, this may alleviate some of the issues that I observed.

My next two posts will cover the layout of the upcoming material and a brief discussion of patterns — a proven solution to a problem in context. The patterns themselves will be posted over the next few months, a couple of patterns a week. Feedback will be highly appreciated and will be worked into subsequent patterns.

Tagged with: [ ]
You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.

Leave a Comment