- Consulting / Coaching
- Jeff’s Blog
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.)
A1. (a manager) = 14
A2. (everyone else) = 10
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.
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.)
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.
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.
Definitely tool should make it possible to disable task tracking, but it brings value as well.
Spread-out tasks are also a violation of lean principles.
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.