Geeks With Blogs
Jonathan Starr's Blog Thoughts on C#, Ajax, WCF, LINQ, Agile et al.

improve my => 'code' Add to Google

On weekends, I tend to go off tangent, and this weekend is no exception.  I started to read some of the works of Levi-Strauss, the structural anthropologist, and it occurred to me that many of the positive changes from Agile Development are not merely the result of greater business focus.  Agile also develops culture in a field that is generally devoid of culture.

This can be a stabilizing factor for companies by

- Reducing turnover by empowering team members.
- Creating rituals, taboos, and totems that increase the significance of work.
- Increasing communication through these rituals to increase trust between team members.

Rituals of Agile Development

Stand Up Meetings (or Scrum Meeting)

Picture Of Football Huddle

In order to make the initial meeting for the day a bit of fun, the meeting is time-boxed to fifteen (15) minutes.  And to emphasize the importance of keeping this meeting short, attendees stand for the meeting (like a football huddle?).  To show attendance is important, team members cannot allow another member attend the meetings by proxy for them.    Finally, to make the Stand Up as much of a ritual as possible, it is generally done at the same time and same place every day.

There are many other rituals that are sometimes adopted during Stand Up meetings.  Some teams rotate the facilitator role for Stand Up.  Likewise, some teams have a special time keeper role to keep the meetings short.  I suspect the richer the traditions for stand up, the more effective they may be for team building and enculturation.

A few other thoughts from an anthropology perspective:  Stand Up meetings are conducted around back log charts/ blockage charts that are highly visible charts with information about the project posted on 3 x 5 index cards prioritized.  It reminded of the Code of Hammurabi - the best way to may things important is by making them highly visible.

For more information, you may want to consult Martin Fowler's take here.

Red Light - Green Light - Refactor



When pair programming is used in Agile, typically a game of "Red Light - Green Light - Refactor" is played.  That is, one member of the pair  fashions a test that specifies a requirement for the user story the pair is working on.  When a satisfactory test is fashioned and it fails, the Red Light part of the game is complete.  Then the other member of the pair will write the code to make the test pass.  This is the "Green Light" part of the game.  Finally, to make the code work with accepted architecture requirements, or to make the card more maintainable or more performant, the first member refactors the code so that it still passes unit tests.  This is the final phase of this round game, and the members switch roles for the next round.

This game is not the zero sum game we Westerners normally engage in.  Instead, because the game has no losers, and only winners, it is ,according to Levi-Strauss, a ritual.

Personally, I have paired with four different individuals over the past six months, and I developed special relationships with each one partly because of the ritual nature of this practice.  It has been very satisfying, and not just on an intellectual level to do so (and many times illuminating as I have had some 'perfectionist' coding partners).

Agile Planning Games

When it is difficult to estimate the scope of new requirements (or user stories) the Scrum team will sometimes play a game to perform the estimate.  Cards with Fibonacci numbers of hours (1, 2, 3, 5, 8 , 13, 21, etc.) are distributed to each team member.  Each member uses one of these cards to indicate the number of required hours to complete the requirement, and when there is disagreement, members justify their estimations with specific reasoning so that a general estimate can be made.

This is another game that is, by its cooperative nature, another ritual of Agile Development.


Taboos of Agile Development

While many parts of agile development are flexible there are some parts that are absolutely fixed.

The taboos of Agile Development are in my mind:

1. Thou shall not miss stand up and iteration planning.

If these meetings are skipped, then work is not done in the proper order, and the team does not properly communicate progress to management.

2. Thou shall not write code without unit tests.

While agile teams have some control over length of iteration and scope of requirements for iterations, quality requirements are fixed.  All code components require covering unit tests so that code changes are justified, and coding errors can be easily located and fixed.

This taboo has many positive consequences for the business - the largest being the minimization of re-work, which is very expensive.

A side benefit is when interdisciplinary teams work together, and they publish unit tests with their work, it makes integration easier.  Consumers of services know how to use services provided, as examples are given.  And they have ways to test the code, so they can easily communicate problems.

Finally, when integration is made easier, diverse teams increase trust and harmony.

3. Thou shall not disrespect other team members.

Agile development is development based on a self-organizing team.  If team members are disrespected the whole team suffers.  Mutual respect is the cornerstone of Agile in my opinion as much as the failing test is the cornerstone of Test Driven Development.

4. YAGNI

While it's not a formal taboo in Agile Development, I hear it so often during my work, that I decided to give this concept some space.

"YAGNI" stands for "You Ain't Gonna Need It", and Agile generally provides the simplest solution for requirements.  While the more complex solution may be more powerful and provide features developers imagine may be needed, the truth is that most of the time that is not the case.

"YAGNI" is a controversial topic for most programmers.  But agile developers generally lean towards the KISS (Keep It Simple Stupid) solutions whenever possible.


Totemism in Agile Development

According to Levi-Strauss, "totemism is a code, a symbolic language whose purpose is to signify social differences.  It is an instrument used by primitive populations for classification of social groups."

Agile development speaks generally of pigs and chickens. 

A chicken and a pig are together when the chicken says, "Let's start a restaurant!".
The pig thinks it over and says, "What would we call this restaurant?".
The chicken says, "Ham n' Eggs!".
The pig says, "No thanks, I'd be committed, but you'd only be involved!".

[Schwaber and Beedle, 2001]

In agile development, most of the rituals are performed by pigs (the self organized team of developers and testers) without the chickens (that is without the product owner).  This totemism is not a formal as it is in primitive cultures, but the social consequences are enforced.

Agile vs. Traditional Development, and Hot vs. Cold Cultures

According to Levi-Strauss, "hot" cultures are based on writing.  They produce a great deal of work, but like hot steam engines, they produce a great deal of waste and entropy.  Furthermore, the 'writers' in hot cultures tend to be higher in the social hierarchy than the non-writers.

Cold cultures are preliterate, and they tend to rely on rituals, taboo, and totemism to preserve order.

I think that traditional development is like most typical hot cultures.  Decision making is made by a few individuals at the top of the social hierarchy.  They do most of the record keeping, so they can easily justify their decisions whether or not they are correct.

Agile development, while it may be a hotter culture than traditional development in the sense that there may be more record keeping on the development process, spreads the management of the process to all of the team members.  And its greater use of rituals, taboo, and totemism may be homeostatic functions that makes these teams more stable.  I think it's more of a tepid culture (hot and cold) based on its mix of practices.

The Future Of Agile Development

Based on this analysis, I have the following questions...  And I would love hear responses from you, the reader!

Question 1:  Agile requires a structured meeting for the beginning of the work day, and for the start/end of iterations.  Would providing an end of day work meeting serve any purpose?  Or would that just be overkill?

Question 2:  Are the rituals for Agile generally burdensome to you (if you are practicing it right now), or do they make your work more meaningful / enjoyable?  Which rituals do you appreciate, and which ones serve little or no purpose to you?

Question 3:  Do you think pair programming is a good idea?  If you pair program, how often do you switch partners?  What do you think is an ideal switch rate per year?  What do you do if you find your coding partner less than ideal?

Question 4:  What rituals do you think enable teams to learn the most during iterations?  Are there more rituals you know about that may facilitate more learning?  Perhaps a lessons learned section should be added to tear downs for iteration planning?

Question 5: Does your organization have a ritual to facilitate code reviews?  I am struggling with this question, as most team members I know are somewhat defensive when it comes to sharing their code, even when it is produced by pair programming.


Happy coding!  And thanks for reading,

Jonathan Starr Posted on Saturday, July 19, 2008 6:47 PM Software Design , Management , Software Development , Management , Anthropology , Agile Development , Scrum | Back to top


Comments on this post: Scrum / Agile Development: A Renaissance of Culture Through the Eyes of Levi-Strauss

# re: Scrum / Agile Development: A Renaissance of Culture Through the Eyes of Levi-Strauss
Requesting Gravatar...
"I have had some 'perfectionist' coding partners"

I don't know anyone like that... :P
Left by zac on Jul 21, 2008 11:55 AM

# re: Scrum / Agile Development: A Renaissance of Culture Through the Eyes of Levi-Strauss
Requesting Gravatar...
Answers to questions posed:

1) I invoke YAGNI. Generally, my gut/experience says that an extra stand-up doesn't provide any/enough value-add to be worth the effort. Individual teams and individual projects may have varying needs, though. Given a customer with sufficiently high volatility/fluidity of requirements, then 2 or more stand-ups a day might be crucial, but in that case I'd argue for a mid-day + start|end of day schedule for max. efficacy.

2) My first Agile environment was/is the single most comfortable/natural coding environment in which I've worked. For me, there's an attraction on an instinctual level.

3) Not only do I think pair programming is a good idea - I think it's the BEST idea. Apart from the inherent knowledge transfer and mutual code ownership aspects, pairing also makes me an order of magnitude more productive than when I work alone, since my pair can usually bring me back to task quickly when my mind starts to wander. Pairing also keeps open a constant trading of ideas on better productivity, testing, and design.

4) A highly-recommended Agile ritual that is not adequately practiced in our shop is the post-mortem or retrospective, which is essentially the same as your idea of "lessons learned", but perhaps a bit more formalized.

5) No comment necessary; you know my organization about as well as I do. ;)
Left by matt on Jul 21, 2008 1:32 PM

# re: Scrum / Agile Development: A Renaissance of Culture Through the Eyes of Levi-Strauss
Requesting Gravatar...
Question 3. YES YES YES Pair programming is the most powerful tool to me. I found this in college, and it continues to be true in my professional life. It is hard to convince people who have not experienced it though.
Question 5. Code reviews are a key component to solving the "code ownership" problem. It becomes a product of the whole team instead of just an individual or a pair. It is also an excellent way to bring new team members up to speed quickly, and maintain consistent development practices.

One ritual I have found very useful in the past is design diagramming. I think it serves much the same purpose as test driven development in that is encourages one to look at the big picture and interaction between components. With diagrams, everyone seems to have a clearer view of what needs to be done, and how to get there.
Left by Eric on Jul 22, 2008 11:08 AM

# re: Scrum / Agile Development: A Renaissance of Culture Through the Eyes of Levi-Strauss
Requesting Gravatar...
Good article. To your chickens/pigs analogy: I think it's a weakness of our organization that we don't have more Chickensian involvement in the rituals of our Agile shop.
Left by Mark on Jul 28, 2008 3:42 PM

Your comment:
 (will show your gravatar)


Copyright © Jonathan Starr | Powered by: GeeksWithBlogs.net | Join free