Jeff's Blog
Musings about software development, Java, OO, agile, life, whatever.(See also Stories and the Tedium of Iteration Planning Meetings.)
Doling stories out to individual developers not only makes for more boring iteration planning meetings, but it also impacts the system's overall quality.
One of the most overlooked practices in software development today is review. If you don't pair, then you really must find a way to consistently review work product. Unfortunately, most companies pay the cost of not doing this: code that is increasingly more difficult to maintain, and solutions that are questionable at best.
Insisting that a team finish a story every couple of days or fewer will often mean that two or more developers must collaborate on a story. In order to collaborate, they must agree on some part of the design and a plan to implement it. The developers will need to continue talking as the implementation progresses. That's a good thing. Much of the resulting design won't be one developer's wonderfully clever or woefully inadequate brainchild.
Such collaboration brings a bunch of siloed developers one step closer to being a true team. Initially, velocity will decrease a bit: developers will have to learn how to talk to each other and coordinate things. Developers will learn more about other parts of the system, increasing their value to the project as well as their personal worth. It's not quite as good as pairing, but it does go to the heart of agile.
In "Tools, Iterations, and Stories," I said you should "focus on implementing and completing stories, not iterations. If your iteration is 10 days, and you have 10 stories of 1 point each, you should have delivered one story by the end of the first day, and two stories by the end of the second day, and so on."
Then, in a blog post titled "Stories and the Tedium of Daily Standups," I talked about how a focus on completing stories, not tasks and iterations, would make daily stand-ups interesting enough to bother with (anew--since many teams that initiate daily stand-ups often find them boring and thus slowly stop doing them).
There's another important side-effect of organizing an iteration around incrementally completing stories: Iteration planning meetings are more interesting.
Implicitly, to be able to complete stories as an iteration progresses requires team members to actually collaborate on a story. Imagine that. It's at the heart of the emphasis on continual communication in agile, yet many teams tend to miss this key point. In my next blog posting I'll talk about the side-effect of improved quality. For now, I'll restrict my thoughts to the impact of story planning on iteration planning meetings.
If an iteration planning covers four stories to be implemented by a team of four developers, there are two primary ways this meeting could go: 1) The customer details each story by focusing on each individual that will work it, or 2) The customer details all stories, discussing them with all four team members. The downside of option #2 is that it will probably take a little longer to work through all the stories. In fact, if you went with option #1, you really wouldn't need a team meeting. The customer could just meet individually with each developer.
Effectively, what you have with option #1 is a meeting in which 3 out of 4 developers have little interest in the story discussion at any given point in time. Information about other developers' stories is mental clutter, and consciously or subconsciously, each developer will tune out to some extent for 75% of the meeting. They will view iteration planning meetings as mostly a waste of time.
In contrast, option #2 requires everyone to be attentive. We all have to understand every story, and we most certainly have to start figuring out how each one breaks up. We probably need to do a little bit of design. People attending these sorts of iteration planning meetings are engaged. They leave the meeting with the impression that it held considerable value for them.
Jerry told me about frustrations at his new company. Here's a possible conversation from my next interview (if there ever is one):
Jeff: Do you block web sites or other things like IM?
Interviewer: We filter on naughty words, we block web mail, and we also disallow use of instant messaging.
Jeff: Interesting. Why do you block web mail and IM?
Interviewer: Because we've found that some people tend to abuse it at the office. They also raise some concerns with respect to security.
Jeff: So you also block phone calls, then?
Interviewer: Of course not.
Jeff: Why not?
Interviewer: Well, people have legitimate business reasons to make phone calls.
Jeff: OK, first, there are legitimate business reasons to use IM. Second, you could block calls to individuals' homes if you really wanted to.
Interviewer: Sometimes employees have legitimate need for personal calls. We find that's ok if they don't abuse the "privilege."
Jeff: So, if talking on the phone all the time was a problem, a manager might intervene and have a discussion with the employee. That seems reasonable. It also seems reasonable that an employee might have a similar, legitimate need for personal emails from time to time.
Interviewer: But we block webmail.
Jeff: Thank you, and have a nice day.
Let's face it, companies rarely change abusive policies like these. Sometimes, the best we can do is voice our disapproval and vote with our feet.
I submit two articles per month to Developer.com. It's often tough coming up with new article ideas, so coming up with a theme that will produce a long stream of ideas is always a good idea (as long as the publisher is willing to accept it). Design patterns is something I've done about a dozen articles on.
Over the nice, long Christmas holidays (vacation for me), I started writing an article featuring the memento design pattern. For me, the hardest part of writing any of these articles is coming up with a good example. I try to avoid the common examples that are already out there, and I don't think abstract examples are very useful. In any case, once I've thought of and coded an example, the article almost writes itself.
Right now, I'm on my third example attempt for memento, which for me is a fiasco. I've probably burned eight hours on something that usually only takes me a few. Memento is not something I've (explicitly) used, so that's not helping.
Each example attempt has been centered around the typical use of memento, to support undo/redo capability. I floundered through two examples, discarding each in turn when I decided that it wasn't a good representation of "real" use of memento.
The other real problem was that I figured I'd wing it. I've coded the examples for every other design pattern article using TDD. But over the holidays, I guess I got lazy. For memento, I banged out a solution and figured I'd refactor to something that I could easily unit test after the fact if I felt compelled to.
It's been a while since I've lazed off and not done TDD. As usual, it was a good reminder that it's just a crappy, less-effective way of working. The code I produced was a mess, with logic entwined in the UI class, as tends to happen when there's no interest in unit testing. Worse, I kept getting stuck on a problem with BigDecimal and scaling that wouldn't have given me such trouble had I used TDD.
Maybe I'm just not a very good developer, after all. Or maybe, just maybe, test-after is a less mature way to code.
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
