Tag: Agile

The Value of Iterations

I often see comments in social media disparaging working in iterations. I’ve heard such comments in person at client sites in the past. Why do some people dislike iterations so much?

Sometimes they talk about the high overhead of repeated planning and tracking. This makes me suspect that their planning and tracking procedures are not aligned with their needs.

Estimating stories is a particularly sore point. People often try to estimate with a precision much greater than they need. If you’re working in iterations, there’s really only two needs for story estimation.

  1. Have we prepared enough work to keep us going for the duration of the iteration?
  2. Are we getting ahead of ourselves and preparing too far into the future?
Read More
No Comments

Categories: Tools and Techniques

Tags: , , ,

Relationship of Cycle Time and Velocity

I sometimes see clashes between Kanban proponents and their Scrum counterparts. Despite the disagreements, both of these approaches tend toward the same goals and use many similar techniques. Karl Scotland and I did some root cause analysis of practices a few years back and came to the conclusion that there were a lot of similarities between Kanban and Scrum [as the poster-child of iterative agile] when viewed through that lens. I also noticed that while Scrum explicitly focuses on iterations as a control mechanism, Scrum teams tend get into trouble when they ignore Work In Progress (WIP). Conversely, while Kanban explicitly focuses on WIP, Kanban teams tend to get into trouble when they ignore Cadence.

A twitter conversation I was in revolved around Cycle Time and Velocity. Since this is a topic that’s come up before, I thought it would be valuable to describe it more fully. Again, I find there to be more similarities than differences between Kanban (which uses Cycle Time) and Scrum (which uses Velocity) in terms of predicting when a given amount of work will be done, or how much work will be done by a given time. Read More

16 Comments

Categories: Tools and Techniques

Tags: ,

Best Practices

A colleague’s statement, “In fact my tip is NEVER do a MoSCoW prioritisation,” caught my eye. “The implied fixing of scope makes change very difficult. Order things instead.” That bold NEVER waves a red flag. The following exhortation to order the things to do is also troubling to me.

I don’t know what prompted the statement. I can certainly envision situations where I think the advice to order requirements or backlog items, rather than prioritize them in buckets, makes very good sense. There are other situations where MoSCoW prioritization (“Must have,” “Should have,” “Could have,” & “Won’t have) is good enough, and situations where linear ordering is inadequate. Let’s look at it more closely… Read More

No Comments

Categories: Responding to Change

Tags: ,

Avoiding Mini-Waterfalls

A lot of people and organizations, when transitioning from a serial software development lifecycle toward an Agile one, fall into the pattern of mini-waterfalls. They start doing iterations, but each iteration resembles the development lifecycle they already know. The programmers do some design work, then they write the code to implement the design, then unit test the code, and then they pass it to the testers for testing. To many people, this is the only way it can work. Their mental model only admits to this series of phases.

And they run into typical problems. Sometimes the design doesn’t fit the problem well, and patches are needed because there isn’t time to go back to design. The testers get squeezed for time at the end of the iteration, and no one knows how to accommodate the rework when a problem is found. More patches are added, because there isn’t time to redesign. And the next iteration starts the cycle over again.

Sure, doing this in two to four week cycles beats doing it in six to twelve month cycles. But only a little. Most of the time, it starts to fall apart if the team doesn’t learn to work differently.

But it’s inevitable, they say. Read More

5 Comments

Categories: Individuals and Interactions

Tags: , , ,

Agile Fluency

Diana Larsen first told me about the Where Are Your Keys language learning game that Willem Larsen and Evan Gardner were playing in early 2009. I was initially intrigued, but when I experienced it with Willem later that same year, I became enthusiastic. My interest lay not in learning languages, but in applying the same techniques and framework to teaching Agile techniques. I immediately began thinking how to make that application, and I’ve been thinking along those lines ever since.

Thus, it was with tremendous expectations when I saw that Diana and Jim Shore had published Your Path through Agile Fluency on Martin Fowler’s website. Having read it, I’m both greatly encouraged and slightly disappointed. Read More

3 Comments

Categories: Responding to Change

Tags: ,

Post-Agile?

Seen on Twitter

“Most people doing Agile today are actually doing Waterfall with Agile terms. Agile is dead.”

There are a lot of people talking about “post-agile” now that the word Agile has been taken up by the masses, including those selling products and services with the word without ever doing what some might consider to be truly Agile. Read More

11 Comments

Categories: Individuals and Interactions

Tags:

What is an Agile Coach?

Recently a friend asked about the definition of the title, “Agile Coach.” Googling “agile coach” informs me that there are about 205,000 pages with that term. Obviously the term is in widespread use.

I don’t typically call myself an Agile Coach, though I’ll use that term informally if it’s the term used by those with whom I’m having a conversation. Instead, I call myself a Software Development Coach. To me, the goal is developing software more effectively, not becoming Agile. Agile processes and practices happen to be excellent tools for effective software development, but lousy goals in themselves. Or so it seems to me.

This morning, I got a call from a recruiter looking for an Agile Coach for a client. They were a bit unhappy when I gave them my daily rate. “The client has a budget and will never pay that much.” When I asked what rate they were expecting, they said $50/hour, all inclusive.

I made more than that a decade ago as a contract programmer. I cannot imagine finding a competent experienced coach for that rate. I’m sure that you can find a body to sit at a desk, though. Is there value in that?

This low rate, and the fact that cost is a primary factor, but value isn’t even mentioned, makes me wonder about what this role of “Agile Coach” has come to mean to organizations looking to hire them. Read More

7 Comments

Categories: Customer Collaboration

Tags: , ,