Jan

26

Is it Agile, or Chaos?

Posted by Keith McMillan

January 26, 2010 | 4 Comments

Every so often I’ll run  into a product owner, project manager or other stakeholder who thinks that “agile” is the best thing since sliced bread. But it’s not really for the reasons you’d consider healthy. “We can change what we want at any time, because we’re being Agile!” they say. As I’ve probably mentioned before, agile is a reaction to heavyweight, prescriptive processes that focus more on documentation and hand-offs than on collaborating to actually get the work done.  But, there’s another type of project team out there, one that doesn’t really have a process, and sometimes doesn’t seem to feel the need for one.  They’re also used to changing direction on a dime.  Are they being agile?

One of the ways that agile is different from other processes that preceded it is the value of “harnessing change for the customer’s advantage.”  With Scrum, that usually means that the product backlog can be added to at any time, and the product owner is free to re-prioritize the items within the product backlog whenever they see fit.

But there’s also the sprint backlog, which is used by the team to manage the work their doing within a sprint.  The items (typically user stories) are added to the sprint backlog at the beginning of a sprint, and typically don’t change.  (As an aside, keeping your sprints short, on the order of 1-3 weeks makes it easier not to change what’s in the backlog.)  The idea here is to allow the team to focus their attention on getting something done, rather than distracting them with a change of priorities.  If circumstances change so much that the items in the sprint backlog are no longer valuable, or a new priority is discovered that changes everything, what do you do?  In Scrum, you cancel the sprint, and plan a new one.

I’ve been working with Scrum and other forms of agile for, depending on how you count, between 6 and 12 years.  I’ve seen exactly one team cancel a sprint.  I also have to say it was probably one of the most dysfunctional teams I’ve had to work with. In short, it’s pretty rare that a new priority arises that’s so important we need to cancel the sprint.

So what’s my point?  There are teams that approach agile from the side of not having any process.  They frequently think that changing their priorities on a daily basis is “being agile,” but in fact they’re not empowering the team to get the job done: they’re just frustrating them by redirecting them frequently.  That results in a team that’s uninspired, because they have no ownership of their work, they never have a sense of getting anything done, and they don’t know what they’re going to be asked to do next. There’s also no way to measure progress in this sort of environment. Because the team is running from one fire to the next, it’s impossible to predict where they’re going next.

Sometimes, it’s necessary for teams to work this way: start ups seem to have this sort of thing happening in spades.  You just don’t know what you’re going to do next, and the teams are so small, that everyone’s a generalist.  Just don’t mistake this for using an agile approach.  I’ve frequently called agile “controlled chaos,” but without some controls, it’s not agile, it’s just chaos.


Comments

RSS feed | Trackback URI

4 Comments »

Comment by jack milunsky
2010-01-27 18:23:06

But Scrum does just that. Scrum through the iteration tames the chaos that is happening outside. During the iteration as you have stated nothing is supposed to change. That gives the team the much needed time to produce and increment of functionality

Perhaps your point is that companies should beware not to fall into the agile trap where welcoming change is misunderstood

Jack
blog.agilebuddy.com
twitter.com/agilebuddy
http://www.agilebuddy.com

Reply to this comment
Comment by Keith McMillan
2010-01-28 08:08:29

Hi Jack,

Yes, as you point out, companies, and teams in particular, need to be careful not to mistake a free-for-all for using agile. Agile, and Scrum, give us just enough structure to work effectively without creating a bunch of make-work.

Chaos, on the other hand, robs the team of self-direction (because they never know what they’re going to be doing), doesn’t allow for any sort of predictability, empirical or otherwise (since we have no backlog, and thus no way to measure), and I think has no good way of evaluating all the priorities the team is being asked to satisfy (because we can’t see them all in one place without a backlog).

I’m not being critical of agile here, I’m being critical of chaos-called-agile, because it really gives agile a bad name.

Thanks for your comments!

– Keith

Reply to this comment
 
 
Comment by Melody Locke
2010-01-29 08:26:15

I totally agree. I’m weary of hearing, “we’re agile” as an excuse for chaos. Agile is a methodology, not a free-for-all. I’ve worked on some very successful agile teams that were not chaotic.

Melody

Reply to this comment
 
Comment by Bryan Jacobs
2010-01-29 21:06:53

Thanks for posting this. It’s refreshing to hear this type of thinking again, and again, and again.

So often agile/scrum becomes we can do whatever we want and change at any time. That just doesn’t work. That is a formula for getting nothing done, or something done poorly.

Admittedly, sometimes major course corrections are required mid-way through a sprint, but with good communications, and sticking to short sprints those problems can be managed without falling into too much chaos.

Reply to this comment
 
Name (required)
E-mail (required - never shown publicly)
URI
Your Comment (smaller size | larger size)
You may use <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong> in your comment.

Blogroll