09.27.07
Posted in Agile, Teams at 8:39 pm by Pablosan
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?
Permalink
09.22.07
Posted in Agile, Iterative Development at 5:21 pm by Pablosan
As I was doing research for my star analogy, I was surprised to find that gravity was a key component in the birth of a star. The role that gravity plays in a star is a great analogy for the role that “very short cycles” plays in the Agile process.
Gravity is a star’s regulator: It is what compensates for changes in the stars density as it burns off it’s fuel. In order for fusion to continue, a star’s plasma has to remain at the right temperature. The force of gravity works along with the star’s density to regulate it’s temperature as it burns off it’s mass (you can find the gory details here, and here. Because of the force of gravity, the star is kept in a steady state; burning neither too fast nor too slow. Without gravity, the star could not even form!
Agile teams use the concept of very short cycles as their regulator. “Very short” is measured in weeks, and is the same every cycle (iteration). The goal of each iteration is a “release” (this should not be confused with the traditional idea of a release that is made available to the public – think of it more as the next working version of the project, which should at least be able to be used in a demo, but may also be a final-release candidate). Why is this important?
Very short cycles is a discipline that is fundamental to the Agile process. It allows the team to lock in on the highest priority features, and guarantees that the priorities stay the same for the duration of the iteration. It allows the project to progress at a steady, maximum rate without burning out the team. It provides regular, timely feedback on how the project is progressing. It gives the team a chance to tweak the process along the way as necessary. Finally, it allows problems to be caught early, before they have spiraled out of control. Without very short cycles, there is no regulation: without regulation, the process oscillates wildly out of control.
To me, in order for a principle to be considered “Agile” it must fall in line with at least one of the four values of the Agile Manifesto. If I had taken the time to cover all the details of the Iterative approach, I think you would find that this principle falls in line with all four! But even in this brief overview of the iterative approach we can definitely see a direct connection to the fourth Agile value of “responding to change over following a plan.” Since we are evaluating the project frequently, we can respond to change. Responding to change is an agile characteristic in any environment! Remember: this does not mean that there is no plan, but that the the ability to respond to changing requirements is more valuable than following a plan. Planning is most definitely an integral part of the Agile Process, and is actually a core component of the Iterative approach. To quote the great Dwight D. Eisenhower: “Plans are nothing. Planning is everything.”
Here is a challenge: how might you take a small step toward an iterative approach in your current project? Is there something you could implement today that would provide a little more feedback on a regular basis? If you’ve already been doing this for a while, what are you doing better this iteration as a result of evaluating your last iteration?
Permalink
09.13.07
Posted in Agile at 8:58 pm by Pablosan
I am a fairly recent convert to Agile software development. It all started about three years ago when I ran across the book, The Pragmatic Programmer
, and the timing could not have been better. That book changed my attitude about my career in software development from “how do I get out of this mess?!” to “are people really going to PAY me to do this?!”
While the “PragProg” book is not specifically about Agile, it was definitely the spark that rekindled an “always learning” attitude toward my craft. Over the past few years I have consistently moved toward Agile and, much like the toddler in the back seat of the car, I keep asking “are we there yet?”
As is often the case, I find myself backing into discoveries. I have been so busy implementing Agile practices that I never really stopped to ask the question: “What is Agile?” And, while I am glad that I have plunged head-long into Agile, I still recognize the value in refining my understanding of this revolutionary approach to software development.
A long time ago (August of 2005 to be exact), the Agile Toolkit podcast’s Bob Payne interviewed Robert Martin (you can find the podcast here). It was a short but poignant interview and in it “Uncle Bob” outlines four core principles of Agile Development:
- Very short cycles
- An Open Office
- Test Driven Development
- The Planning Game
Much like the birth of a star requires the basics of fuel, proper mass, gravity and fusion, Agile requires these basic elements to jump-start the process. Once a star’s building blocks are in place and balanced, it’s nuclear furnace kicks on for the first time. In the same way, a successful Agile approach which begins with these four core principles in the proper balance lays a solid foundation on which all other Agile practices are built.
I know that using a snazzy analogy does not validate an assertion, so over the next several installments, I will be looking at each one of these four principles individually. My goal is threefold: to show that each of these are indeed core elements, to demonstrate how each of these fits into the four values of the Agile Manifesto, and to use this study as the springboard for this, my first crack at blogging.
The Agile process is a journey; one that I am enjoying immensely. I’m looking forward to continuing conversations and making new friends along the way. Oh… and no, we’re not there yet!
Permalink
