Tailoring Agile and Recognizing Dysfunctions

LYSSA ADKINSFEBRUARY 20, 2008

Ken Schwaber says something I believe wholeheartedly:

“Whenever an enterprise modifies or only partially implements Scrum, it is hiding or obscuring one or more dysfunctions that restrict its competence in product development and management.”

Ken goes on to say that, “Scrum is not a methodology that needs enhancing. That is how we got in trouble in the first place, thinking that the problem was not having a perfect methodology.”Instead, “effort centers on the changes in the enterprise that are needed.”

In my experience, all this is true.Agile is not a methodology that needs tailoring.

But, we also know that Agile shows you the elephants in the room.The positive stress it puts on the organization reveals all that was there before, especially the dysfunctions.What organization, what family even, doesn’t have dysfunctions, though?They exist for us all in some form or another.We can thank Agile for calling them out.Often, we will say, “Wow! I didn’t know that was there.Well, let’s not do that anymore” and the dysfunction goes away.The organization is better for it.Sometimes we look at it and say, “Whoa! That’s a biggie. I don’t think that one is going away anytime soon.”

In the latter case, I suggest a 2-step process.Step 1: Use the structure of Agile and raise the dysfunction as an impediment.Raise it clearly, with unwavering voice to the highest level person that will hear you.Step 2: If the answer from the impediment-raising doesn’t come back as “Wow! I didn’t know that was there.Well, let’s not do that anymore” then consider tailoring Agile.

Basic rules for tailoring Agile:

1.First and foremost, preserve the Agile Manifesto.Whatever you change or decide not to do, ensure the Manifesto remains valid.This is what Agile is all about, so if you are doing these things, even differently than what the “pure Agile” is, you are still Agile.

2.Preserve the inspect-and-adapt loop.

3.Ensure the whole team is involved in the discussion and agrees.They need to know what they are giving up.

4.Ensure the team’s management also clearly understands that tailoring is happening to get around an organizational dysfunction (aka impediment).Make sure they know what they are giving up.

5.As you work with your altered Agile practice, ensure you are getting the benefits originally intended by the practice.What follows is a list of those benefits.If your team is not getting the intended benefits from a practice then press the pause button.Inspect and adapt.If you cannot true-back to the intended benefits, then STOP doing it.Little feels worse to an Agile team than an empty ritual.

Here are the practices and benefits:

Product Backlog

• All stories known at a given time are included
• Product owner has “sliced” business intent by prioritizing stories according to business value
• A main prioritization driver is delivering first business value as fast as possible
• The backlog is alive, changing and continuously updated and reprioritized
• Work is aligned with leadership’s direction

Sprint Planning

• Planned in order of story priority
• All work is transparent
• Team only works what has been agreed to

Sprint Backlog/Burndown

• All work is represented in sprint backlog
• Burndown is updated daily
• Burndown is used by team to spur conversations when it indicates they are not on track to “make it to zero” or they will burn to zero before the end of the sprint

Story/Task Board

• Actively used by the team to indicate status
• Actively used by the team to spur coordination and sequencing

Standup

• Effective, supportive, constructive peer pressure
• Fine-grain coordination
• Raise impediments & ensure they get resolved

Impediment Removal

• Things to be fixed now; impediments don’t sit

Timeboxed Sprint

• Sense of beginning and ending
• Time period team can control
• Sense of time pressure
• Chance for leadership to change priorities or direction without jerking the team around (because this only happens between sprints)

Retrospective

• Well-designed and facilitated meeting for the team to continuously improve
• Team thinks of themselves as a “well-oiled machine” that they want to tune each time

Sprint Review

• Low tech, high impact
• ‘Own up’ to results with customer

Release Planning

• Clear on incremental value
• Ability to talk to the future via the release plan
• Customer commitment done via release, rather than sprint by sprint
• Shift in customer interaction from schedule-driven to value-driven

This is drawn from my experience and has been used with teams, so I know it has value.It is also a work in progress.So, please, add your thoughts and corrections.I look forward to hearing them.