What is Agile? Part Two

July 31, 2013

In last week's post I outlined some thoughts on how agile development parallels Bruce Lee’s Jeet Kune Do (JKD). This week, I’ll conclude my thoughts, beginning with how Bruce Lee created confusion with JKD.

The Confusion Factor
Martial arts styles tend to emphasize one type of combat, such as kicking and punching in Karate or grappling in Judo. However, when it came to Jeet Kune Do, Bruce Lee was adamant that he hadn’t created a new style. He hoped, he said, “…to free my followers from clinging to styles, patterns, or molds.” (Bruce Lee in Liberate Yourself From Classical Karate, September, 1971, Black Belt Magazine)

Think about that for a moment. If Jeet Kune Do wasn’t a style, what was it? What exactly would you expect to learn? And how did Lee going about freeing people from the limitations of existing styles? How does this relate to agile?

Well, I tipped my hand at the beginning of last week’s post: JKD is a system for change.

What is Agile? Part One

July 24, 2013

Since I’ve been posing and answering questions lately, I thought that I would tackle a broader topic. Before reading on, what is your definition of agile? How do you explain it to people who are new to agile and want to understand more?

Agile development can be difficult for people to initially wrap their heads around because it is not a single, prescriptive process that can be mechanically followed to success. This makes it difficult to define what it means to be truly agile in a succinct, meaningful way. This in turn creates confusion about what agile is.

Interestingly enough, the confusion about what agile is parallels something that has been seen before. While the parallel is from an unexpected source, the similarities are striking (if you will excuse the pun): Bruce Lee’s method of fighting he called Jeet Kune Do (JKD). The similarities include what drove Bruce Lee to create JKD in the first place, what JKD is really all about, selling/marketing change, and something that what we need to be mindful of as we move forward with agile.

What Does a Scrum Team Commit To?

July 17, 2013

I mentioned in last week’s post that teams commit to a Sprint. The context of this statement involved tasking out User Stories so that the team understands the nature of the work and what need to be performed, the skills required, and an estimate on how much time it will take to complete that work. My point was that the team’s confidence in meeting its Sprint commitment by tasking out the work.

There are two things wrong with this:
  1. The most current Scrum Guide changed its wording from prior versions. What was a Sprint commitment is now a forecast. (My memory failed me on this point as I wrote last week’s post. Old habits die hard!)
  2. It was misleading for me to strongly associate tasking User Stories with achieving a Sprint forecast because in practice I favor committing to a Sprint Goal, which is in alignment with the current Scrum Guide.

Should We Task Out User Stories?

July 10, 2013

Since I addressed the question Can We Skip the Retrospective? last week, I thought I would tackle another issue this week. This time I’m exploring whether teams should task out User Stories and estimate the hours it will take to complete those tasks.

Before reading on, what would your immediate response be to this question?

One argument is that tasking User Stories creates unnecessary overhead. If teams are working on small, Sprint-sized User Stories, then these stories are all that the team needs to track, progress-wise.

Another argument is that tasking the work and estimating the time it will take to complete those tasks is a step backward, because time-based estimation techniques are we’re trying to get away from with agile.

Finally, there is the point that tracking time spent on tasks does not add any value.

Can We Skip the Retrospective?

July 3, 2013

This question seems like it has been surfacing more lately, perhaps because agile (Scrum) adoptions are increasing. This happens to involve one of those timeless qualities of an agile organization: continuous improvement.

Asking a team what it means for them to be agile and guiding them back to the Agile Manifesto is helpful in these situations. As one of the principles states: “At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.”