This is the blog of Brasten Sager, a software engineer, Mariners fan, guitarist, haphazard philosopher.
It’s already been noted by some, but Seattle has no idea how to handle snow.
The Fremont office was supposed to be completed a week ago, but it’s been delayed until later this week. It’s hard to skip work due to snow when you work from home!
Anyway, here’s a picture I snapped last night of Jess next to the fountain!
In his latest article, Joel Spolsky reacts to Dmitri Zimine’s hypothetical story on developer multitasking by concluding that Agile development should allow for those interruptions and the manager in the hypothetical story isn’t doing his job if he doesn’t consider both sides of the situation. I agree with the concept Joel’s trying to portray, but I believe he’s misunderstanding Dmitri’s point and the role of Agile in the story.
Joel states, “Agile is not supposed to be about swapping out one set of bureaucratic, rigid procedures for another equally rigid set of procedures that still doesn’t take customer’s needs into account.” Technically that’s true, but if you’re really talking about Agile development - not cowboy coding - then Agile does enforce various rules and procedures on the development process. Situations such as that being discussed by Joel are explicitly discouraged in Agile development precisely because of the harm it causes to the project timeline and ultimately the very customers we may be trying to help. Joel himself acknowledges the harmful nature of context switches on a developer and project, but then suggests we should be willing to do it anyway—within the scope of an iteration (perhaps by pushing back completion of the iteration). This nullifies one of the greatest advantages of iterative development, namely that customers notice missed deadlines before they notice missed features. It is largely for these reasons that Agile strongly protects the scope-cap and end-dates of in-process iterations.
But the spirit behind Joel’s article is valid. Agile should not be so rigid that it cannot handle these types of deviations. If you read Dmitri’s article closely, you’ll see he provides for an appropriate solution to this situation: implode the iteration. Remove the developer and the developer’s tasks from the iteration goals, allowing them to focus on the new tasks you’ve requested. The developer’s original tasks are then pushed off until the next iteration.
It’s very important to notice that Dmitri DOES provide that option to his managers—no doubt causing a lot of discomfort in the process. But if you miss the importance of that, then you’ve missed the point of his whole story. Dmitri isn’t saying that Agile won’t allow these things to happen, he’s merely saying that when they do it’s the development manager’s job to accurately convey the options. Context switching the developer likely will cause them to miss the iteration deadline. In that case, the best option (the only option the development manager will accept) is removing the developer’s tasks from the iteration goals (for all the reasons stated earlier). If the business feels the potential customer is worth making that choice, they are absolutely capable of doing so.
So, let me attempt to restate all of that in a sentence of two. Dmitri isn’t suggesting we ignore the potential needs of a customer, he’s simply correcting the business/sales manager’s beliefs on the ramifications of their request. By doing this, he’s simultaneously protecting his developer and his managers from unrealistic expectations. And Agile’s entire role in this whole thing is simply to provide the guidelines for making course corrections with the least amount of impact to team and project.
In this case, the development manager is doing his job very well.