This post originated from an RSS feed registered with Agile Buzz
by Dave Churchville.
Original Post: Organics and Mechanics in Agile Development
Feed Title: Agile Project Planning
Feed URL: http://feeds2.feedburner.com/AgileProjectPlanning
Feed Description: Thoughts on agile project planning, Extreme programming, and other software development topics
Do XP and other agile methods appeal to some people because of their organic nature? And do others mistrust or actively denounce these methods for the same reason?
I recently read an article from Rands In Repose, titled Organics and Mechanics. A fun read, which to summarize, says that Organics are more intuitive people who gather information somewhat chaotically (at least to outside observers), and are more focused on the big picture than the pixels. Mechanics, by contrast, prefer to understand how things are structured down to the bits, and will ask detailed questions until they get this understanding. Organics and mechanics, therefore, are constantly annoyed by one another.
To apply this to software processes, I think one of the draws of XP is it's emphasis on people. Ideas like "40 hour work week", "pair with others", "close communication", "onsite customer", etc. have strong pull for those with the need to feel connected to the people on a project, not just analyze bits and bytes.
As an admitted Organic with traces of Mechanic, I see software development as a creative endeavor intended to solve people's problems. However, this process also needs some structure applied to make it consistent and reliable, key attributes when you need to deliver to customers. Agile methods allow the creativity, personal contact, and focus on communications that us Organics love, but also applies rigor in the form of prescribed practices.
XP, for example, insists on adhering to the disciplines of fixed iteration timeframes, merciless refactoring, test-driven development, and maybe most important, not working on things that have not been prioritized and approved.
So these practices, along with project tracking and metrics, can satisfy the Mechanics need for hard numbers. What are the detailed tasks for this story? Where are the unit tests for this feature? How many running, tested features have been completed? What work is remaining, and how likely are we to finish it?
The ideal development team has a blend of both Organic and Mechanic mindsets. This captures both the big picture and vision, as well as the small details that need to be worked out before you can deliver useful, reliable software with consistency.
So why is this so hard? Too often, Organics are drawn to only the Organic parts of agile methods. The warm, fuzzy communication, the daily customer contact, the pair programming, the rapid feedback are all like honey-flavored butter on Organic bread. The lure of running a project in the Organic way, without all of those annoying rules can seduce a team into forgetting that there is freedom in discipline.
Similary, a Mechanic-heavy team can forget that they are building software for people, and fall prey to over-analysis and over-engineering of solutions. They often say things like "Well, it's more in keeping with my architecture to build it this way, even though it's not really what the customer wanted."
Detractors of agile methods correctly criticize pure Organic implementations of agile methods for their lack of rigor and discipline, and call it "code and fix" development. When correctly applied, Agile methods have both Organic and Mechanic side in balance. Ying and yang. Dogs and cats playing together in harmony.
What are some telltalte signs of inbalance? You'll hear a lot of noise about "lack of visibility". Or maybe something about how people aren't working hard enough. These are very dangerous signs. It means that the Mechanics on the team aren't getting what they need. If you're customers are Mechanics, this could spell doom for project. Same applies to your boss, CEO, or investors.
So let balance be your guide to running an agile project. To Organics, try to think like a Mechanic every now and then. Get a little structure going. Measure your progress once in a while.
And Mechanics, get out of the details and meet your customers. Understand your business better. Maybe even add some pizazz to your software.
How can you tell if your Agile team is balanced? It's pretty simple really. Both the development team and the customers will be happy. Not just for a month or two, but over a sustained time period. You could even put up a "happy meter" on your wall (to keep the Mechanics happy). But make it attractive and maybe a little abstract for the Organics among you.
Previous Topic
