Comments on: Does Agile work for bug squashing and software maintenance? http://www.fuzzylizard.com/archives/2007/05/30/884/ My thoughts on Agile, Java and Ruby on Rails (mostly) Fri, 21 Nov 2008 07:01:25 +0000 http://wordpress.org/?v=2.6.2 By: Chris Johnston http://www.fuzzylizard.com/archives/2007/05/30/884/#comment-13019 Chris Johnston Thu, 31 May 2007 17:13:21 +0000 http://www.fuzzylizard.com/archives/2007/05/30/884/#comment-13019 I think I forgot to mention a few key points in my post. First, the team is highly distributed with the senior developers/domain knowledge holders in location A, a few relatively newbie developers in city B and the rest of the team on site with the client in city C. In addition, we are set to deliver the product to the client in a few months and will then hand the maintenance over to the client. It makes more sense to me to have some of the client developers start pairing with us and bring them up to speed as opposed to having two new team developers start learning the domain only to leave in a few months. But maybe I am missing the point here. I think I forgot to mention a few key points in my post. First, the team is highly distributed with the senior developers/domain knowledge holders in location A, a few relatively newbie developers in city B and the rest of the team on site with the client in city C.

In addition, we are set to deliver the product to the client in a few months and will then hand the maintenance over to the client. It makes more sense to me to have some of the client developers start pairing with us and bring them up to speed as opposed to having two new team developers start learning the domain only to leave in a few months. But maybe I am missing the point here.

]]> By: Nate http://www.fuzzylizard.com/archives/2007/05/30/884/#comment-13018 Nate Thu, 31 May 2007 14:05:55 +0000 http://www.fuzzylizard.com/archives/2007/05/30/884/#comment-13018 One of the best functioning agile teams I've ever participated in was solely working on fixing bugs. It sounds like you have a communication problem for starters. You state that there is no self organization, but you don't touch on why. You're all sitting there together. If someone knows the domain really well, bring them in to pair with you. Later, when another bug comes in the same area, you'll be better equipped to handle it. I recall switching pairs multiple times a day in some cases. Of course, there may be a nasty bug that requires a pair to stick with it for more than a day. In a team that communicates and trusts each other, that message will be conveyed. One of the best functioning agile teams I’ve ever participated in was solely working on fixing bugs.

It sounds like you have a communication problem for starters. You state that there is no self organization, but you don’t touch on why. You’re all sitting there together. If someone knows the domain really well, bring them in to pair with you. Later, when another bug comes in the same area, you’ll be better equipped to handle it. I recall switching pairs multiple times a day in some cases. Of course, there may be a nasty bug that requires a pair to stick with it for more than a day. In a team that communicates and trusts each other, that message will be conveyed.

]]> By: j http://www.fuzzylizard.com/archives/2007/05/30/884/#comment-13016 j Thu, 31 May 2007 12:53:14 +0000 http://www.fuzzylizard.com/archives/2007/05/30/884/#comment-13016 Obviously a lot of it depends on the organization/structure of your workplace, but it's working fine where I'm at. regarding your example, what we do is have that developer with domain knowledge explain to who's working on the bug what to do and check in with them at the end of the day to see 1) if it's done and 2) if they're heading in the right direction. This typically only takes 10-15 minutes to review what they did, and while it's not ideal for the client to have someone without direct domain knowledge working on it, there is oversight and it works towards getting them up to speed. YMMV Obviously a lot of it depends on the organization/structure of your workplace, but it’s working fine where I’m at.

regarding your example, what we do is have that developer with domain knowledge explain to who’s working on the bug what to do and check in with them at the end of the day to see 1) if it’s done and 2) if they’re heading in the right direction. This typically only takes 10-15 minutes to review what they did, and while it’s not ideal for the client to have someone without direct domain knowledge working on it, there is oversight and it works towards getting them up to speed.

YMMV

]]>