Jeff's Blog
Musings about software development, Java, OO, agile, life, whatever.Don't let this happen to you!
I saw this classic comic book cover and couldn't resist. There could be a whole True Coding Crime series. (Click image for larger version.)
I've been feeling a little dirty recently from dealings with people who might most kindly be called duplicitous. "I'm agile," they state at the same time their ass backs up into a cave-cube, looking to grab an ugly stick with which to beat down team members.
My wish is greedy and unreasonable: I want nothing more than to expect that if people say they are supportive of something, then they actually understand what they're supporting and actively try to do so. (It's asking a lot, given that millions of US citizens just did otherwise.)
On days when I feel like Catbert, I want to use a personality-profile-based litmus test for agile attitude. Does the use of personality profiles in business derive from mistrust, from people being burned? Are they a tool for evil when used as a factor in hiring?
Employing such a test would require sufficient data demonstrating a correlation between personalities and agile. Is there correlation? A study is warranted; what would that look like? I imagine in its simplest form there are two questions.
- What is your Meyers-Briggs type indicator?
- Do you really buy into agile? (... or however you ask this and get an honest answer)
Tim Ottinger and I are working on a new project, an agile agile reference guide. (Yes, that's supposed to be two "agile"s in a row.) One of the things we're debating is a list of pairing smells. Here's what we have so far:
- Unequal access to keyboard and/or screen
- Keyboard domination
- Pair marriages / no switching during story
- Worker/rester pairing
- Second computer
- "Everyone does their own work"
- 90% of stories 90% done
- Reluctant pairings
- Debates lasting longer than 10 minutes with no new code
Thoughts welcome, and incorporated ideas will be rightly attributed. What might we remove from or add to this list? What could be worded better?
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.)
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.)
- 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
Archives
February 2004 March 2004 May 2004 September 2004 October 2004 January 2005 February 2005 September 2005 October 2005 November 2005 December 2005 January 2006 February 2006 March 2006 June 2006 August 2006 January 2007 February 2007 March 2007 April 2007 September 2007 October 2007 November 2007 December 2007 January 2008 February 2008 March 2008 April 2008 May 2008 June 2008 July 2008 August 2008 September 2008 October 2008 November 2008
