Boundaries
People like to draw boundaries. A boundary enables the description of elements that lie within and without the boundary. Drawing boundaries also has other effects:
Brian Maricks recent exposition on testing metaphors includes a boundary, that between the Agile team and the rest of the world. He uses the following image
and says:
They - programmers, testers, business experts - are in the business of protecting and nurturing the growing work until it's ready to face the world.
I thinks the choice of boundary is interesting, Brian's choice is large, solid, horned defenders of the growing work. This team looks independent, defends its young and I imagine it would survive outside of its current host organisation. That doesn't sound like the software projects I'm familiar with. In my experience (which includes software consultancy/service companies and niche product houses), projects tend to not have an existence outside their host organisation. Occasionally teams move to a new host, but it is uncommon. I don't think Brian intends for the team to be independant from its surroundings, but I can see how people may interpret it in this way. This is the problem with drawing boundaries and not discussing the nature of the boundary.
Maybe the testing metaphor (which is really a team metaphor) needs to acknowledge the interconnectedness of the team with the host organisation. I think the metaphor needs to conflate team identity, interconnectedness and symbiosis (though it has to be admitted, some projects are parasites that kill the host). Maybe neurons work as a metaphor, they have a strong centre, they are connected via fine tendrils into the host, communications down particular links reinforces communication paths and they work to form a whole that is greater than the sum of the parts. Initially attracted to that idea, I don't see it as very successful. Brian's desire seems to be to bring independance, critical thought and error seeking behavior inside rather than outside the team is laudable, and isn't addressed. However, the dinosaur ring metaphor chosen is akin to protecting the child against all comers, seeking to nurture it but not allowing it outside until it is grown. Is this really the right way? Shouldn't the child be encouraged into the open early, supported but not closeted, exposed to new people and ideas and encouraged to explore? Social networks are a better metaphor for software teams. There can be a place for independence, critical thought, error seeking and cohesiveness within social networks. Social networks also capture the lumpy nature of teams and cohesion, within large teams there are clumps of high cohesion and within those clumps there are other clumps, it's fractal in nature (to some extent anyway).
Maybe the dinosaur ring is born from the statement that independance and - to some extent - error-seeking are not a natural fit for Agile projects, which thrive on close teamwork and trust. This statement is based on an assumption, that independance and, to some extent, error seeking, restrict close teamwork and trust. I think this assumption is incorrect. Team members can be part of a gelled team and yet have independance of thought and desire to find and fix defects. One of the developers I respect is extremely independant of thought, focuses in on defects with a laser accuracy, but can be seen pulling in the same direction as the other team members. If I had an agile team, there would be a place for this person, I don't want 'yes men', group polarisation and group think. Despite the pro group-think article, most teams that attempt it will fail. The effect on both the teams judgement and the host will be too detrimental.
So, I'd like to see a better metaphor, but agree entirely with the article when it talks about testing and Is there an alternate metaphor that we can build upon? One that works with trust and close teamwork, rather than independently of them? Can we minimize the need for the independent and critical judge?. I see trust, close teamwork and independance and critical thought working well in teams already, we don't need to abandon those things, just nurture them at the same time as we nurture the product.
- Boundaries can frame thoughts and hence lead to consideration of the inner or the outer without considering the whole. (are you with us or against us?)
- Boundaries allow you to characterise the nature of the boundary, i.e. permeable, semi-permeable, flexible, fixed, etc.
Brian Maricks recent exposition on testing metaphors includes a boundary, that between the Agile team and the rest of the world. He uses the following image
and says:
They - programmers, testers, business experts - are in the business of protecting and nurturing the growing work until it's ready to face the world.
I thinks the choice of boundary is interesting, Brian's choice is large, solid, horned defenders of the growing work. This team looks independent, defends its young and I imagine it would survive outside of its current host organisation. That doesn't sound like the software projects I'm familiar with. In my experience (which includes software consultancy/service companies and niche product houses), projects tend to not have an existence outside their host organisation. Occasionally teams move to a new host, but it is uncommon. I don't think Brian intends for the team to be independant from its surroundings, but I can see how people may interpret it in this way. This is the problem with drawing boundaries and not discussing the nature of the boundary.
Maybe the testing metaphor (which is really a team metaphor) needs to acknowledge the interconnectedness of the team with the host organisation. I think the metaphor needs to conflate team identity, interconnectedness and symbiosis (though it has to be admitted, some projects are parasites that kill the host). Maybe neurons work as a metaphor, they have a strong centre, they are connected via fine tendrils into the host, communications down particular links reinforces communication paths and they work to form a whole that is greater than the sum of the parts. Initially attracted to that idea, I don't see it as very successful. Brian's desire seems to be to bring independance, critical thought and error seeking behavior inside rather than outside the team is laudable, and isn't addressed. However, the dinosaur ring metaphor chosen is akin to protecting the child against all comers, seeking to nurture it but not allowing it outside until it is grown. Is this really the right way? Shouldn't the child be encouraged into the open early, supported but not closeted, exposed to new people and ideas and encouraged to explore? Social networks are a better metaphor for software teams. There can be a place for independence, critical thought, error seeking and cohesiveness within social networks. Social networks also capture the lumpy nature of teams and cohesion, within large teams there are clumps of high cohesion and within those clumps there are other clumps, it's fractal in nature (to some extent anyway).
Maybe the dinosaur ring is born from the statement that independance and - to some extent - error-seeking are not a natural fit for Agile projects, which thrive on close teamwork and trust. This statement is based on an assumption, that independance and, to some extent, error seeking, restrict close teamwork and trust. I think this assumption is incorrect. Team members can be part of a gelled team and yet have independance of thought and desire to find and fix defects. One of the developers I respect is extremely independant of thought, focuses in on defects with a laser accuracy, but can be seen pulling in the same direction as the other team members. If I had an agile team, there would be a place for this person, I don't want 'yes men', group polarisation and group think. Despite the pro group-think article, most teams that attempt it will fail. The effect on both the teams judgement and the host will be too detrimental.
So, I'd like to see a better metaphor, but agree entirely with the article when it talks about testing and Is there an alternate metaphor that we can build upon? One that works with trust and close teamwork, rather than independently of them? Can we minimize the need for the independent and critical judge?. I see trust, close teamwork and independance and critical thought working well in teams already, we don't need to abandon those things, just nurture them at the same time as we nurture the product.
posted by Andy S at 9:54 PM
<< Home