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.

Tags: [ ]

A Note on Patterns

Filed under [ Agile Process Patterns ]

Patterns organize implicit knowledge about how people successfully solve recurring problems. Patterns describe solutions that have been successfully applied on numerous occasions; they are not theoretical abstractions created in ivory towers.
Christopher Alexander defines a pattern as follows: “Each pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice.” (Alexander, 1997, A Pattern Language)
There are a number of pattern formats available — Alexandrian, GoF, Portland, and Coplien to name a few. While these may differ in style and format, they all attempt to convey the same basic information. Irrespective of the format used, the pattern will at a minimum describe the problem, specify the context in which to apply the pattern, enumerate the forces in-play, and describe the solution in that context. The last part is important — patterns will only solve the problem in an appropriate context; they cannot be applied arbitrarily in all situations.
I am going to use the Alexandrian format throughout this book to describe the best practices. The Alexandrian format contains the following elements:
Name — single word or short phrase that refers to the pattern. This allows for rapid association and retrieval.
Aliases
Context — preconditions which must exist in order for that problem to occur, this is often a situation. When forces conflict, the resolutions of those conflicts is often implied by the context.
Problem — definition of a problem, including its intent or a desired outcome, and symptoms that would indicate that this problem exists.
Forces — description of forces or constraints and how they interact, some of the forces may be contradictory, such as being thorough often conflicts with time or money constraints.
Solution — instructions, possibly including variants, may encompass pictures, pictures, diagrams, prose, or other media
Resulting Context — result after the pattern has been applied, including post-conditions and side effects. It might also include new problems that might result from solving the original problem.
Rationale — the thought processes that would go into selecting this pattern, The rationale includes an explanation of why this pattern works, how forces and constraints are resolved to construct a desired outcome.
Examples — sample applications and solutions, analogies, visual examples, and known uses can be especially helpful, help user understand the context
Related Patterns — differences and relationships with other patterns, possibly predecessor, antecedents, or alternatives that solve similar problems.
The patterns described in this series of blogs have been observed over the years while working at various client sites. In keeping with the spirit of the pattern-writers value system (http://c2.com/cgi/wiki?PatternValueSystem), I will use existing pattern names where possible — most of these patterns were originally proposed by people like: Jim Coplien, Neil Harrison, Ward Cunningham, Alistair Cockburn, and Don Olson.

Patterns organize implicit knowledge about how people successfully solve recurring problems. Patterns describe solutions that have been successfully applied on numerous occasions; they are not theoretical abstractions created in ivory towers.

Christopher Alexander defines a pattern as follows: “Each pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice.” (Alexander, 1997, A Pattern Language)

There are a number of pattern formats available — Alexandrian, GoF, Portland, and Coplien to name a few. While these may differ in style and format, they all attempt to convey the same basic information. Irrespective of the format used, the pattern will at a minimum describe the problem, specify the context in which to apply the pattern, enumerate the forces in-play, and describe the solution in that context. The last part is important — patterns will only solve the problem in an appropriate context; they cannot be applied arbitrarily in all situations.

I am going to use the Alexandrian format throughout this book to describe the best practices. The Alexandrian format contains the following elements:

  • Name — single word or short phrase that refers to the pattern. This allows for rapid association and retrieval.
  • Aliases
  • Context — preconditions which must exist in order for that problem to occur, this is often a situation. When forces conflict, the resolutions of those conflicts is often implied by the context.
  • Problem — definition of a problem, including its intent or a desired outcome, and symptoms that would indicate that this problem exists.
  • Forces — description of forces or constraints and how they interact, some of the forces may be contradictory, such as being thorough often conflicts with time or money constraints.
  • Solution — instructions, possibly including variants, may encompass pictures, pictures, diagrams, prose, or other media
  • Resulting Context — result after the pattern has been applied, including post-conditions and side effects. It might also include new problems that might result from solving the original problem.
  • Rationale — the thought processes that would go into selecting this pattern, The rationale includes an explanation of why this pattern works, how forces and constraints are resolved to construct a desired outcome.
  • Examples — sample applications and solutions, analogies, visual examples, and known uses can be especially helpful, help user understand the context
  • Related Patterns — differences and relationships with other patterns, possibly predecessor, antecedents, or alternatives that solve similar problems.

The patterns described in this series of blogs have been observed over the years while working at various client sites. In keeping with the spirit of the pattern-writers value system (http://c2.com/cgi/wiki?PatternValueSystem), I will use existing pattern names where possible — most of these patterns were originally proposed by people like: Jim Coplien, Neil Harrison, Ward Cunningham, Alistair Cockburn, and Don Olson.

Tags: [ , ]

Alexandrian Pattern Format

Filed under [ Agile Process Patterns ]

Pattern Name*** (with confidence level)
Aliases: if any
… Context in which we find the problem
The context is often described via a “situation” rather than stated explicitly. Sometimes, the context is described in terms of the patterns that have already been applied.

???

Forces or trade-offs behind the pattern
The often contradictory considerations that must be taken into account when choosing a solution to a problem. The relative importance of the forces (those that need to be optimized at the expense of others) is implied by the context.
This section outlines the various factors that affect the problem (circumstances), and the tradeoffs between them that complicate and constrain the solution. Pattern writers refer to these tradeoffs as “forces” because they will push or pull you in different and sometimes competing directions as you attempt to solve a problem. The relative importance of the forces (those that need to be optimized at the expense of others) is determined by the context.
A headline in bold type that gives the essence of the specific problem in 1-2 sentences
Use Context-Free Problem to ensure that the problem is kept separate from the constraints on the solution.
The body: background, motivation, variations
Therefore:
The proposed solution in bold type
A diagram that shows the solution as a labeled picture
???

Discuss why the pattern works: how it balances the forces, what the strengths and liabilities of the pattern might be, and so on.
Note that many problems may have more than one solution, and the “goodness” of a solution to a problem is affected by the context in which the problem occurs. Each solution takes certain forces into account. It resolves some forces at the expense of others. It may even totally ignore some forces. The most appropriate solution to a problem in a is the one that best resolves the highest priority forces as determined by the particular context. Use Solution Clearly Related to Forces to ensure that the reader understands why this solution was chosen.
Related patterns:
Principles involved:
Sample situations:

Book Content and Layout

Filed under [ Agile Process Patterns ]

As mentioned previously, this blog series will cover the basic patterns only; advanced topics may be addressed in the future.

I will cover the basics on the principles and process before discussing the team and technical practices. Lean Software Development will be covered subsequently.

The following topics will be covered in the order (more or less) listed below:
1. Agile Principles
2. Iteration Planning
3. Requirements Management
4. Estimation
5. Quality
6. Communication and Visibility
7. Team Roles and Organization
8. Technical Practices
9. Lean Practices

Tomorrow, we start with the first pattern in the Agile Principles section.

Software Development is not Manufacturing

Filed under [ Agile Process Patterns ]

Software Development is Not Manufacturing
… Your company likens software development to a production (manufacturing) environment and expects people and processes to reflect the same.
???
A number of organizations use Waterfall based processes for software development that call for all requirements to be gathered at the start of a project.
Software project managers and delivery departments (IT) are often evaluated on how well they meet the budgetary and schedule constraints while delivering the agreed to scope. Variations are frowned upon and delays are attributed to poor planning — if the team had done a good job in anticipating and planning, the team would not have been surprised in the middle of the project, and would have delivered on time. To get better, then, the bias is to try and drive out the variation by doing more rigorous up-front planning.
A perfect metaphor for this is manufacturing — isn’t the team producing units of work just like in a manufacturing environment? If manufacturers can get to 6-sigma tolerances then can’t software engineers do the same?
It is important to note that manufacturing environments work well because:

  • The requirements can be well defined and these requirements seldom change.
  • Production systems have a very low variance of time spent on a step — each unit produced is the same and six sigma tolerances can be defined for each unit and for the time spent at each step needed for the production of the unit. Variability is the enemy in manufacturing and needs to be driven out.

Treating software development as manufacturing gives a false impression that everything can be planned upfront and that subsequent deviations from the plan are due to people problems, i.e., people did not plan well enough.
But, software development differs significantly from production processes:

  • It is fallacious to assume that software requirements can be well defined and that these requirements will seldom change. If there is one thing about software development that we have learned over the years it is that requirements will change due to market changes, competitor moves, regulations, and just plain insight gained from seeing a mockup or a prototype.
  • Meeting the original requirements as defined is not the end goal; the only measure of success is whether the implemented solution solves the customers’ real problem.
  • In software development projects the requirements and technologies used differ — no two projects are exactly the same. Learning (discovery) is the central value creating activity in software development; consequently, the definition of tight variances is fraught with danger — there is a much higher variance of time spent on a step. Put another way, if software development was analogous to manufacturing then software development teams would be highly successful by simply writing the same code over and over again. However, reality tells us that every worthwhile software development project is a custom one-off endeavor to solve a singular problem.
  • In manufacturing, backflows are rare and viewed as errors. But, in software development backflows are common (whether encouraged or not) and help learning.

Therefore:
To optimize software development, quit trying to make it look like production.
To succeed you must:

  • Create feedback early and often to accelerate learning.
  • Avoid measures and tolerances which drive a predictive factory mindset.

???
Think of software development as a inventing a recipe for a book; production as someone else following the printed recipe exactly. Inventing a recipe involves experimentation and the final recipe is rarely the first attempt at coming up with the right dish. Following the printed directions is easier and if done correctly will lead to a faithful reproduction.
To optimize software development, quit trying to make it look like production. Recognize that learning (discovery) is the critical activity and that software development is about people who are inventing and communicating in the face of a problem that keeps changing, a solution that keeps changing, technology that keeps changing.
Alistair Cockburn, said it best when he wrote that software development is a cooperative game of invention and communication, where people are:

  • Inventing and communicating and attempting to solve a problem they don’t yet understand (which keeps changing)
  • Creating a solution they don’t really understand (and which keeps changing)
  • Expressing ideas in restricted languages they don’t really understand (and which keep changing) to an interpreter unforgiving of error.
  • Resources are limited and every choice has economic consequences.

Standard defined methodologies also err by assuming that a single methodology will work all the time:

  • One size fits all methodology is not always applicable as projects vary in size, complexity, etc.
  • Intolerant methodologies fail as people do vary

Heavier methodologies incorrectly assume that more planning and documentation up-front equates to greater safety. But safety is not the goal; delivering user-valued functionality as fast as possible is! Signed-off documents at each phase of the project do not guarantee success — signing-off does not equate to eventual user happiness; close collaboration with the users to determine their shifting needs and how best to fulfill them is what is important.
Software development also has the advantage that the end-product does not have to be perfect (incorporate every bell and whistle) before release. Teams have the option of delivering value sooner even if in smaller chunks. This is unlike manufacturing, where often only the final product can be sold to the end user — would you like to buy just the engine and car chassis from then wait months till other sections of the car become available!

« Newer PostsOlder Posts »