Can We Transform Agile Rules to Guidelines?

Posted by Vikas Hazrati on Jan 27, 2010

Sections

Process & Practices

Topics

Agile ,

Agile Techniques

Tags

Complementary Practices

A rule generally refers to the defined standards for an activity. It is required to be adhered to. In other words, a law, may informally be called a "rule". Guideline on the other hand attempts to streamline a particular process according to a set routine. By definition, a guideline is never mandatory. Often we hear stories which mention rules for Agile teams like rules for a standup, rules for retrospectives etc.

Should Agile teams talk about rules or can we just have guidelines?

Most Agile teams are driven by a set of ground rules and these have been pretty effective too. Robert McGeachy shared his set of ground rules for Agile teams as

• Everyone has an equal voice
• Everyone’s contribution is valuable
• Attack issues, not people
• Keep privacy within the team
• Respect each other and your differences
• Everyone participates

He mentioned that these rules are not meant to cage the team, instead they help the team in a positive way. Likewise Bob Hartman mentioned that there are multiple moving parts in an Agile project.

Because all of these things add up in a hurry, I encourage teams to put together a rules of engagement document to make clear some of the most basic rules and interactions.

Bob has created a rules of engagement template which can be used by Agile teams.

Steven M. Smith, however challenged the notion of rules and suggested how some of the rules can be easily converted to guidelines. According to Steven,

• Rules trip up both individuals and teams causing unintended consequences.
• We learn rules about such things as what we can do, what we can question, and what we can say.
• A rule dictates behavior. But when transformed into a guide, it enables you to choose appropriate behavior.

He takes an example of a few rules,

Rule: We must never force a teammate off the team – This rule propagates trust and loyalty. However, this rule also undermines the productivity of the team which could be suffering due to a wrong team member.

Here he suggested that the guideline instead of this rule could be

Rule might be transformed into a guide like — we can sometimes force a teammate off the team when their behavior is destroying productivity; or when we have insufficient funds; or when their skills no longer fit our mission.

Rule: We must always be fully transparent with our clients – This rule again encourages being open and honest. However, Smith argued that being transparent to the client can only be done to a certain extent. According to him a team would almost never be able to tell a client that they missed the deadline because a member on the team was an alcoholic and he went on a bender. Instead Smith suggested transforming the,

Rule into a guide like — we can sometimes be fully transparent with our client when the disclosure helps the client; or when we analyze and accept the risk of our communication; or when our conscious won’t allow any other alternative.

Hence, though rules often make life simpler and give a standard direction, however many a times they also fence the team into a situation which can be both non productive and threatening. As Smith quoted,

Listen for the telltale words I/we must never… or I/we must always… When you detect they are in play, you’ve discovered a rule. State it precisely and transform it into a guide. Remove the tripwires that are limiting productivity and threatening your team. Give your team choices rather than dictates.

1. Back to top

   Don't Bother

   by Bruce Rennie

   This is a complete non-problem:
   
   1. "Good" agile teams made up of critical thinkers already understand that the rules are guidelines. And they wouldn't hesitate to break the rules even if you told them not to.
   
   2. Less mature teams/developers aren't more likely to do the right thing just because we change the label from "rules" to "guidelines".
   
   I don't see other professions/trades wringing their hands over calling things rules. I'm pretty sure if I were to start as an apprentice carpenter, I'd be told to do things pretty much by the book. Only as I grew more experience/capable would the master show me the shortcuts and tricks.
   
   And, anyway, I don't know about you, but in my experience getting developers to break the rules has never really been a problem.

   Reply

2. Back to top

   Re: Don't Bother

   by Mr Magoo

   How about this:
   
   Every rule you come across in life (regardless of context) is a guideline.
   
   Rules are not made to be broken. There are no rules...

   Reply

3. Back to top

   Declarative vs Procedural

   by Francisco Jose Peredo Noguez

   It is the old Declarative vs Procedural problem.
   The "Declaration" is the easy part, for example: "Make software with no bugs", "Find out if P!=NP", "Walk in water while drinking plutonium", "Love your neighbor as yourself".
   That is the easy part. The hard part is live up to those declarations. Reality is messy, what if you neighbor wants to kill you? The hard part of living is the procedural part, the part that has to react to the current situation with series of steps that are the best for that situation.
   That is why it is so much easier to describe what a system is supposed to do "Find the last digit of PI", than actually build it (it might not even be possible).

   Reply

• Older >