improve my => 'code' 
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)
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