Complete Stories, Not Iterations. Again.

No matter how hard I try, there’s always a hammer in my life. Sure, I try to use all those other new-fangled tools that are perhaps more appropriate to the problem, but I find that my hammer is a versatile tool that helps me bang my way out of many trouble spots. My recent agile hammer is “complete stories, not iterations.” In other words, collaborate! I’ve made a few blog posts and written at least one article on the topic.

Everything seems to keep coming back to this. A focus on completing stories as a team, and not moving on until the story is “done done,” tends to eliminate many of the questions that otherwise exist.

For example, “Should we create stories for defects?”

The glib answer is of course, “Well, if you’re doing agile properly, you don’t have defects.” But the more satisfying and less annoying answer is, “Well, if you’re collaborating to get stories completed, you don’t have many defects that survive the iteration.” If you can deliver a story every day or two through an iteration, the story can move into preliminary testing, and odds are that you’ll uncover many defects before the iteration completes. That means you can either fix them before the iteration completes, or you haven’t finished the story (it’s not “done done”), and the story is slotted wholesale into a subsequent iteration.

Voila. Concern over whether or not to create defect stories? Poof! (If you still have the question, the answer is “yes,” because they can be estimated, and because they take development effort that adds into team velocity.)

Q. How Many Days Are There in a Two-Week Iteration?

A1. (a manager) = 14
A2. (everyone else) = 10

Contrarians

Should we ever “give up” on someone? Agile or not, development or normal life, people are always the biggest challenge. Difficult people are obvious targets, since by definition they do things that most people don’t want to deal with on a day-to-day basis. But can we help them become less difficult?

Just what is a difficult person? I actually welcome a healthy level of skepticism. If you’re not skeptical about things, you’re probably not pushing boundaries as often as you should. I can help a skeptical but open-minded person by answering their questions and guiding them through necessary self-discovery and acceptance of a new idea. With some people, however, skepticism instead grows into a potentially unhealthy attitude, whereby they resist differing ideas at all costs. Stated from their point of view, “I’m right and you’re wrong.”

Sure, if you’re absolutely right in your reasons to avoid something, it’s an appropriate response. But that’s almost never the case, particularly when we’re talking about something like TDD or automated testing. People have achieved good levels of success with diametrically opposed ideas, strategies, and tactics. What that means is that someone who wants to argue every last point against their presumed opposition is being close-minded. Sometimes they cross over the boundary into pure contrarian–even if you agree with them on a point, they still find a way to argue against it!

I felt regret most of this weekend about a post I made to one of the agile lists last week. After an exchange of a few nit-picky posts, I stated that I wasn’t going to waste my time any more. It was soon apparent that the other poster was going to shred virtually every line I wrote, never mind trying to find any common ground. Now I don’t feel bad at all–blowing hard at brick walls is a huge waste of time.

Comments:

What do you do in order to deal with this people? Do you have any advices?

Once you’ve (really, really) established that they will not budge, then the best thing is to find somewhere else for them to be. I think at that point you just have to be direct. If they’re in the midst of your team, ask them: “Do you plan on trying to work like the rest of this team has chosen or would you prefer to work differently?” Sometimes they can educate you on valuable changes you can make to improve the transition. But most of the time, they just need to find a more compatible team.

Five Violations of Agile

(aka Five Core Reasons Why Your Attempts at Agile are Failing)

  • Developers work as individuals, not a team, and refuse to collaborate on stories
  • Emphasis on iterations over stories, instead of trying to deliver “done done” stories every day or two
  • Automated ATs are not the focal point of negotiation and completion
  • Unwillingness to adapt the process as a result of retrospectives
  • Acceptance of incomplete work at the end of an iteration

Task Tracking Is an Agile Smell

We’re looking at tools to help manage agile projects. This is a large, globally distributed enterprise, and that’s not going to change, so I suppose some sort of expensive tool is a necessary evil.

Many people are involved with reviewing the tools (which include things like Mingle, ScrumWorks, Agile on Demand, VersionOne, and eXPlainPMT). Everyone comes from a different perspective, of course, and I have nothing against how other people choose to work. But one request keeps coming up that bugs me: the insistence that the tool support the ability to do task tracking.

The desire to manage tasks in an agile process is evidence that a team is not collaborating. They are instead using silo-mode development: 1 story -> 1 developer. In lieu of tracking progress by marking off completed stories, they look at progress in terms of what tasks have been completed. May as well go back to waterfall.

It’s all about delivering the story. If you work in a collaborative mode that promotes this, there’s no need for tracking at the task level. (I’m not even going to mention the ludicrous idea that tasks ever outlive an iteration.)

Comments:

couldn’t agree with you more. We use scrumworks and you assign a point person to a story/pbi.

Then you add or delete tasks as needed.

we went to a csm class with danube too. the trainer said “are you in the business of keeping people busy or producing product?” I think this is the point of your blog postings.

definitely agree.

Our VersionOne tool met both requirements for us. We could start with task tracking if absolutely necessary and turn off at any point in the future with the click of a single check box. We actually started with task tracking turned off and never looked back.

I don’t agree that task tracking is an evil. For example, we at TargetProcess use tasks as Definition of Done. We have tasks for each user story like Implementation, Create Acceptance Tests, Testing, Code Review, etc.

Definitely tool should make it possible to disable task tracking, but it brings value as well.

Note that I didn’t say “task tracking was evil.” It’s one way of working, and if it works for you, go for it. However, the better way is to structure things so task tracking becomes irrelevant. If you feel like you have to track tasks, your stories are probably taking too long to complete within the iteration.

Spread-out tasks are also a violation of lean principles.

I believe it is okay to make task tracking a requirement for tool selection since it is useful. I also understand where you are coming from that if the whole culture “requires” it, there might be a problem.

We use VersionOne because it handles both. We use task tracking heavily. As we work towards appropriately sized stories, we may need this less… but for now it helps us compensate for some other issues.

Atom