09.27.07
Mass Interaction
Of the four, core Agile principles outlined by Robert Martin his second, “An Open Office”, was the one that surprised me the most. I understand the value, but is it really a core value? More importantly, which of the four basics required for the birth of a star aligns with that?!
Of the three basic building blocks for a star, three became quite obvious analogies for three of these core Agile practices. So it really came down to a process of elimination, and I was left with “An Open Office” and mass. Pretty scientific, huh?
I decided to turn to Google’s “define” function (go to Google and type in “define:mass” without the quotes) and, from the resulting list, chose the following for our purposes:
- the property of a body that causes it to have weight in a gravitational field
- an ill-structured collection of similar things
- a body of matter without definite shape
In the context of physics, the first definition is the correct one, though I found it interesting that the other two could be applied to a star as well. A star is a collection of similar things; “ill-structured” might be a little strong, but a star is a very chaotic place in many regards. It is also a body of matter without definite shape: yes, stars are roughly spherical, but as studies of our own Sun have shown, stars are constantly throwing their weight around, resulting in some amazing displays such as Solar Flares, Sunspots, and Coronal Mass Ejections. While a star has a more defined shape than, say, a cloud, it is not a solid.
Mass alone is somewhat bland. The “stuff” that makes up a star is pretty basic (the vast majority of matter in a star is Hydrogen and Helium – the simplest elements). What makes a star interesting is how it’s stuff interacts, creating something much more than the basic components on their own.
Consider the interplay of mass and density: too little density and an object’s mass never congeals (think of clouds, steam, fog), and too much density and the object’s mass becomes incredibly resistant to change… almost stagnant (concrete, granite, diamonds). Agile development teams, like stars, require a good balance. We cannot afford to be aimless, and we cannot afford to be rigid: we need to exhibit elasticity. Stars grow and shrink, gain and lose mass, all within a given set of constraints. They are dynamic systems that must continually adjust and reconfigure their mass in response to changing demands.
So how does all of this relate to “An Open Office”? Well, it doesn’t… directly. More importantly, I think focusing on an open office is stopping short of the core principle. I’m sorry Uncle Bob, but I’m going to have to disagree with you on this one: I don’t think “An Open Office” is a core Agile principle. Is it valuable to an Agile team? Absolutely! But only as one practice that supports the core principle of “self-organizing teams.”
An Open Office is a great idea: tear down the walls (cubicle or otherwise) and create an atmosphere that encourages collaboration; that encourages ad-hoc, spur-of-the-moment, just-in-time communication between all members of the team. This is a good thing, and it is most definitely agile! It is one way to encourage a team to self-organize, along with things like daily, stand-up meetings and pair programming. But, to me, all of these are good principles based on the core principle of self-organizing teams.
Why is self-organization a core principle? It is a core principle because; it maximizes the team’s ability to respond to change, it improves the ability of the team to deal with deficiencies (in both processes and people), it forces the team to collaborate, it eliminates dead weight, it helps the team maintain inertia, and it encourages the team to “own” the project. Self-organization keeps a team’s mass from becoming dead weight.
How does the principle of a self-organizing team adhere to the Agile Manifesto’s four core values? Very obviously, this principle aligns with “Individuals and interactions over processes and tools”. Self organizing teams value each individual, by striving to insure everyone is working together toward the same goal and to the best of their ability.
As a practical exercise, you might consider the following questions:
- Who is the most experienced member of my team?
- Is there a significant gap between the least experienced and most experienced team members?
- Does my team have any dead weight?
View most/least experienced as a continuum. If you are closer to the most experienced side of the continuum, what have you done to help your teammates with less experience become experienced team members? If you find yourself more toward the least experienced end of the continuum, are you seeking to gain a better understanding of your responsibilities from those with more experience? What is something your team could do today that would narrow the gap between the team’s most experienced and least experienced members?
