We performed a similar exercise to the one we did when Olaf Lewitz and Michael Sahota visited us as they passed through for Agile Coach Camp 2012; you can see details of that prior exercise here: http://hhgttg.de/blog/2012/09/20/krismaporganisation-persona/

The change we did to their exercise/games was to focus on what we thought an Influencer means from a personification.  What are the characteristics?  


Here were the top ones (in priority order based on 2 rounds of dot-voting):

  • Experienced or Fluent in what is being influenced (which we felt was a given if we were going to hire someone).
  • Persuasive or Vocal so that she ensured issues that came up were handled.
  • Brave so that she could face countering conventional wisdom.
  • Encouraging so that she could help people in their progress in a constructive manner.
  • Observant so that actions and nuances would be noticed.
  • Humble so that she recognizes she can’t be the source of all information.
  • A Challenger with an Inquisitive nature that would run Experiments to help discover what was best for the people she is trying to influence.
  • And Persistent and Consistent in their nature to see what ever the influence is trying to make happen through.


As a  Persona, this is something to strive for…  We also asked the question, “What traits would be the ones you would find difficult, to use with an organization, particular if you were hired as a consultant/coach/change agent to fill this Influencer role?”

Experienced/Fluent was a give (as mentioned before). 

Persuasive and Challenger/Inquisitive/Experimental were the next two

Observant and Humble were the next. 


To complete the list of other characteristics or traits we came up with that didn’t make the top ones, here they are in no particular order…

  • Someone who follows-up.
  • Analytically minded (to take observations and now how to dig into them)
  • Open-minded to see things that may work that are not what they have in their experience.
  • Supportive (closely relates to Encouraging)
  • Protective of (working) relationships
  • A Good Listener (also goes along with being Observant)
  • A Planner
  • A Leader or willing to step as a leader and model desired behaviors.
  • And a Visionary, to be able to describe the direction in an inspiring manner.

It was a GREAT discussion!


Filed December 5th, 2012 under agile

This past Friday, 11 May 2012  we held a session on Sustainability.  We first tried to determine what we meant by sustainability and this was the list we came up with:

  • Team sustainability (ability to continue delivery)
  • Sustainability of purpose/community
  •  Preventing burnout (related closely to the first bullet)
  • Sustainability of a product feature
  • Sustainability for continual improvement


This list generated a bit of discussion.  Siraj and I have been a bit concerned that the group isn’t quite sustainable yet (perhaps self-sustainable is what we are really meaning?).   This led to us discussing a bit abut the purpose of AID, and hopefully I’ll recap thissuccessfully that we formed shortly after Agile Coach Camp 2010 to bring together those that need to influence others in adopting and continuing practices of Agile through peer-based sharing.  These may be coaches, managers, or technical personnel.


To ensure we were on the same page, we decided to create a definition of Sustainability and we used a mind map.  Here was our initial version (with some minor tweaks):


 We developed 4 primary characteristics: Sustenance, Tension Pace, and Feedback.  Each of these had characteristics as well…  The only tweaks I made to this diagram is the addition of conversations in the Feedback area as measures and metrics have an assumption of precision that may not be there and renaming “Throttle” to Tension as we moved more completely to a motor vehicle metaphor when we began reorganizing the mind map.  (Bio-)Physics means not only what is against the known laws of the universe, but also violating people’s downtime and ability recover.

Later we decided that the mind map was a bit different…  And this was the refined mind map:


 In this map, we saw Pace as the point between Fuel and Throttle (what moves you forward and what holds you back).  In the ideal situation, Pace would be close to Fuel meaning you are churning through the factors (Demand, Need, etc.) as quickly as possible.  Realistically though you have a Throttle holding you back so the Pace is reasonable.  Feedback effects the Pace you maintain as well as the Fuel and Throttle itself. (BTW, I’d consider adding De-motivation to Throttle personally, but I didn’t add it to the diagram as I am not sure that would have much buy-in from our group. I think conversations would have gained considerable buy-in based on how our discussion went.)

We then decided to apply the measures/metrics to understand the Pace of our AID group a bit better and determine if any changes needed to be made.  Here is what we recorded:


Pace Measures  Fuel  Throttle

Frequency: 1x/month 

Mtg length: 2 hours

Consistency: 11 times/year planned (we normally skip December), but 10 times/year actual (each year one meeting didn’t have enough show to make it worth it).

Timing: 2nd & 3rd Friday of the month at 5pm socializing, 5:30pm start 

2nd Tuesday, beginning 12 June, new start: 5:30 socializing, 6pm mtg start.

Back Channel communication: amount of mailing list chatter and individuals talking to one another between mtgs

# members on site: ~40

# members attending meetings: 7-8 normally, sometimes 10-12

That means we get roughly 20-25% of our members. 

New measure: Frequency of new attendees joining us

Topics: prioritized list of themes



Ease of Attendance


Special Events 

Competing Stuff


We arrived at some of the changes annotated above after a brainstorm (again using a mind-map).  Here’s what we came up with…


So with that, look for an email changing things a bit…  Lastly, here was the list of themes we developed (look for dot poll sometime soon):

  • Retrospectives
  • Leadership
  • Interfaces 
  • Mindset
  • Career Development/Mentoring
  • Learning/Outreach
  • Overcoming Resistance 
  • Active Listening
  • Providing Feedback
  • Tech Topics (though we realize due to the diversity of languages and such that this may need to be more generalized)
  • Games/Workshop Day

 I’ll close in that with the above, we will probably try and divide each topic into something more focused on a technical team and then something more generalized that managers/leaders may want.  Example, what forms of technical feedback can be developed and how would it be implemeneted (e.g. unit testing) while also discussing more general feedback  (e.g. customer satisfaction).

We’re looking at a having a picnic/BBQ as well; please hold aside 30 June to join in…

- Paul 

Filed May 14th, 2012 under techniques, Purpose, Vision

The US Agile Coach Camp just completed and several people asked what my play list was that I had running as people gathered. Well, here you go!

30 Minutes - Tatu (Russian album, not the English translation)
Harem - Sarah Brightman
Computer Love - Glass Candy
Hairy Trees - Goldfrapp
Breathe - Telepopmusik
Downward Pull of Heaven’s Force - Babble
Tribe - Babble
Miserei Mei - Sarah Brightman
Beautiful - Sarah Brightman
Suave Suave - B-tribe
Astral Hymn - Solar twins
Face in the Crowd - Kosheen
Perezagruzka (Robot’s Outro) - PPK
Opening Credits - Hybrid
If I Survive - Hybrid
Smokebomb - Ursula 1000
Flying to Frisco - Flying Pops
Jim Clark Theorem - grand Tourism
Circles - Adam F)
Lost in Love (Dj Taucher Radio Edit) - Legend B
What’s on Your Mind (Pure Energy) - Information Society
Big Time - Peter Gabriel
Watch us Work It - Devo

This is about 2 hours of music and we never got through it, but if i were going to have a longer time, there are a few tunes I’d think about adding to this -

Silent Fish - Jens Buchert (insert between Flying to Frisco and Jim Clark Theorem)
Microscopic - Gas
The Smell Of Wet Rocks - Mind Soup
(insert both of these in this order at the beginning)


Filed September 27th, 2011 under agile, Other Groups

No, not one to replace the Agile Manifesto, but one for Project Leaders to utilize that can be applicable to any type of project.


Until I get the website to contain this up I present you the Manifesto for Project Leadership!



After reading some books recently and reflecting on what I have learned from them and my experiences thus far, I realized that one thing that does not seem to exist in the world of project leadership is a Manifesto, something equivalent to the Agile Manifesto.  I did some searching and didn’t find anything that was both general and simple enough to serve as guidance for Project Leaders to use as a framework.  Thus, I have tried to create oneBeing biased towards an Agile approach, it will appear to bear great similarity to the Agile Manifesto (originally focused on Software Development only), but I have named it the Manifesto for Project Leadership; I personally believe it should apply to any Project Leader and can apply to any project.

In order to avoid other organizations from simply “absorbing” or morphing this work and then charging for it; I am applying a Creative Commons license that simply states “Attribution, No Commercial Use, Share Alike”.  I welcome participants/partners in refining this and making this widespread in the Project Leadership community.  So far this is the thoughts of one person, but expecting more, I have placed an attribution of my name et al so it immediately will recognize “others”.  As others participate and we come close to an agreement on how we think this should actually read, then I expect to have a set of “signatories” just as the Agile Manifesto has.


So without further ado, here’s the first draft of the Manifesto…


Manifesto for Project Leadership

In the planning and execution of projects, we are uncovering better ways of leading project delivery.  Through this work we have come to value:


Serving the Project Team[1] over serving deadlines, cost constraints, or project scope

Being Open and Truthful over delivering information with a political spin

Interacting in Person over using communications that limit interactions

Responding to Stakeholder[2] Needs over adhering to negotiated, established, or imposed scope

Delivering Usable Improvements, Products, or Services over non-useful interim deliverables


That is, while there is value and potential need for the items on the right, we value the items on the left more.


Principles behind the Manifesto (written from the perspective as the Project Leader)

I exist to serve the Project Team and the delivery of the improvements, products, or services to the customer; I will do all in my power to remove obstacles, obtain needed resources and training, and clarify the customer’s vision and needs for the members of the Project team.

The health and welfare of the Project Team’s people matters.  As a project leader I will not over commit the people of the team to something they cannot deliver.

I will work with all Project Stakeholders to define and prioritize the project vision, goals, and objectives and means to measure the effectiveness of these,  as well as plan and design the project delivery to meet the constraints imposed on the project by the environment in which it exist[3].

I will work with the Project Team members to deliver something useful to the customer as quickly as possible so that the customer may provide feedback to the Project Team.

I will provide honest, earnest, and timely feedback to members of the Project Team in a respectful, but direct manner.  Where feedback is negative, I will afford the appropriate members privately.

I recognize conflict and diversity of opinion will exist and will assist the Project Team in navigating this in a manner that strengthens the relationships within the Project Team.

I recognize my Project Team has a limited capacity to deliver and will ensure I respect this limit as a constraint.  I will work with the team to plan excess capacity into the project delivery ‘system’ so that a ‘critical path’ does not exist and when one appears, I will work with the necessary project Stakeholders to minimize or eliminate its impact.  Adding capacity in the form of additional people to the Project Team will be a last resort for minimizing or eliminating a critical path.

I recognize that the act of planning is useful, but that any plan produced will be almost immediately obsolete.  I will work with the Project Team to constantly assess current progress[4] and to identify areas for improving project delivery and minimizing or eliminating risks.  To the greatest degree possible, I will assist the Project Team in identifying and selecting useful delivery improvement options.  The concept of a baseline is there only for the Project Team to assess progress for possible improvements.

To the greatest extent possible, I will assist the Project Team members to grow in their skills and delivery capabilities; thus improving their value to the organization.

I recognize that there are no best practices; there are suitable practices that may work in my Project Context and only by experimentation can I find these.  I will keep practices that work and throw out practices that don’t.  I will maintain a record of the experiences over the project delivery so that I and others may learn what may potentially work in similar contexts.


Project Leaders Mantra

Serve the project team

Coach the project team

Assist the team in improving project delivery

Locate and obtain needed resources for the team

Engage the project stakeholders collaboratively


I’d like to invite people to join in refining the above.  I’m in the process of setting up a domain and website; in the mean time, I invite people to contact me via my Twitter ID: @paul_boos

[1] A Project Team consists of all members that define and execute delivery of a project from initiation to completion; these are usually cross-functional in nature.

[2] Stakeholder is anyone that is paying for, is impacted by, or participates on the project delivery or uses (or will use) the resulting improvements, products, or services of the project.

[3] The environment that the Project exists is known as the Project Context.

[4] Progress can be defined in a number of dimensions based on the Project Context; some examples are delivery schedule, budget, readiness to fullfill a need, or measures of improvement. 

Filed September 1st, 2011 under Uncategorized

Because it fell during the week of 4 July, the meeting for 8 July was moved to 15 July.  We’re also starting at 5:30pm instead of 5pm to give folks more time to get there.  For July, we’re still at Argia’s, but we’ve had offers for both in Tyson’s and Downtown and we’ll probably move to rotating around to allow folks to attend.  If you sign up on Eventbrite, while it still says the 8th, we’ll consider it the 15th.


Filed July 7th, 2011 under Location, Attendee


 Folks, Decided we would give registering with EventBrite a chance.  It provides an ability for folks to see who is coming or not, but more importantly an ability for me to let teh restaurant know exactly how many plan to attend.  As our membership in AID grows,  this could become important for us to also know when we need to grow into a new space.


You also have a handy tool embedded within the EventBrite widget to Tweet to folks about your attendance!


Thanks and look forward to seeing all of you at the meetings!



PS - For those interested in posting jobs - 

We have a specific mailing list  for AID members to post jobs or related information. You must be a member and contributor to our AID community. Job postings must be from the principal posting the job and NOT a head hunter or job matching service. Job postings may be permanent positions or temporary gigs and for any level of work. Archived messages will not preserve any attachments, only the text. 

Filed January 25th, 2011 under agile, Location, Who is invited, Attendee

I normally don’t comment much when luminaries have debates (I’ll call them debates as they aren’t arguments, but there is disagreement and a desire by each side to win those to other sides), but I think I’ll weigh in…


The debate is over whether the concept of Software Craftsmanship as a (separate) Community/Movement is helpful or hurtful to the Agile Community and more importantly how those of us in Software Development serve our customers  It all stems from comments made by various members that are well respected taking up sides so to speak.  Bob Martin (@unclebobmartin) sees making the distinction as helpful as it shows that programmers are focused on quality and commitment to doing a good  great job.  Martin Fowler (@martinfowler) sees it as pulling the overall Software Development Community and Business apart to some degree.


Here’s my take….

The comments seems to be stemming from the fact that many non-software development domains are latching onto the concept of Agile as the Agile Software Development Community is using it (notice I added Software Development into this…) and it is diluting it.  This is not a legitimate concern IMHO.  Why shouldn’t other groups take advantage of the principles, practices, and techniques we have come up with…  So it’s filled with PMs?  Well, you need them on board! (see Note I added below)  If you don’t get them on board, you’ll have them (with generally more clout) resisting.  You want them becoming proponents (there is one thing that could be talked about more and that is Servant Leadership, but that will be a topic for another day).  The point is there is an Agile Community that has grown to become a superset of the Agile Software Development Community.   The issue is that people aren’t drawing that distinction when they toss around the word Agile.  

We need to…

Some conferences should serve both.  Some should be specific to their domain (e.g. Agile HR, Agile Marketing, Agile Manufacturing, and Agile Software Development). And all communities could learn from one another as we are all linked in the real business world.  Just as the PMBOK started with one basic domain and then became domain specific, so is the Agile Community.  It just started more from a set of grassroots developer-leaders and not from a management perspective. Let’s emphasize that the Agile Software Development Community also focuses on sets of practices; practices that the other domains will develop in time.  Some in existence are directly applicable, like  creating acceptance tests before going off and doing work.  Others less so….

(Side note on Acceptance tests: I had the opportunity to work on a recent engineering project with a fabric manufacturer thanks to some Navy Reserve work where the guy was applying TDD, to manufacturing fabrics - it was amazing to realize.  He didn’t call it TDD though, but the first thing he thought of and conveyed to me as the program manger was how he would approach making a test that shows he would pass the criteria being articulated.  This is why I am confident other domains can take advantage of what we are doing.)

So talking about (and obviously believing in) craftsmanship I think is useful; trying to make it a separate movement less so as we are JUST starting to get traction in many businesses on Agile Software Development.  We don’t need to obfuscate with additional language.

Revised 1/22/11 to correct some grammar issues and add my note

NOTE: In my talk about getting success with Agile in the Federal Government, I talk about the intrinsic motivation at least most developers have when they get their degrees (or start programming for those that don’t get degrees).   They have a passion for doing what they think is right and want to become better at it.  I also discuss that programming is a craft - it has both skills and creativity (it is supported with engineering practices, but as a pure knowledge domain, I wouldn’t call it an engineering).  It takes this intrinsic motivation for the craft (a desire for good craftsmanship) and top down support of management (the business) for Agile, specifically Agile Software Development, to succeed IMHO.

Filed January 19th, 2011 under methods, techniques, comparison, agile

I had the opportunity to both give a couple of talks as well as host an open Space talk on Product Ownership in the Government. I opened the discussion for the group to discuss the “why” for wanting to have a product owner when in most places in the Government this isn’t very high on the priority for standing up a project. We captured 3 reasons:

1) Ensuring the team delivers value to the Government business users.
2) Providing new features that have been prioritized and reviewed as they are implemented; this lowers the surprise factor.
3) Providing a vehicle for the business to participate in the needed continuous improvement for software delivery.

We next tried to capture some ideas that we felt should be used to get the business to provide the product owner in the first place; something that particularly in the Government gets ignored.

One is to rely on a project charter and to spell out that role explicitly in the charter so that the business knows they are signing up to it. Preferably IT/management could use this as a leverage that if the business is unwilling to provide the product owner, the project must not be important enough to fund/develop.

Another option is to have the traditional PM rile transition to becoming the Product Owner, but often the PM also would become the Scrum Master, so some conflict of interest could occur if the roles are not decoupled. A business analyst could be used as well. The primary issue though for either of these is that analysts and PMs come from the IT side and not the business, so there is some conflict of interest as well as just not knowing the business as well.

In a fee-for-service arrangement, it could work that who ever the sponsor providing the money for the project is, they could name any trusted agent to be the product owner if they didn’t want to take on that role themselves.

Another option is for IT to create temporary details that business people get slotted to fill. These could have a temporary promotion to encourage a desire to participate. Because the folks are from the business, they come with the needed knowledge; they also gain an appreciation of the IT world as well. When they come over, their job can now be dedicated as being nothing but the product owner. This eliminates the usual problem of it being a collateral duty for most business folks.

We then moved to discussing how to scale this arrangement and often you here of a Scrum-of-Scrums (in the Scrum world) for scaling Scrum up for larger projects; these could include the product owners as well so that th priorities could be reviewed and perhaps juggled a little for cross-project dependencies.

A few things specific characteristics about the projects the Product Owners are to support should be articulated to them (if they are not the sponsor); the goals, constraining budgets, and any particular schedule demands (need by dates) should clearly be provided (probably in the charter as well). Then the Scrum Master/Team should articulate to the Product Owner when subject matter experts beyond the knowledge of the Product Owner are need and the time required so they can be made available at the appropriate time in the Sprint/iteration. This should be done in the Sprint planning session, but at also the Product Owner should be made aware of the need to talks within someone with subject knowledge during release planning. Schedules can then be adjusted if a subject matter expert isn’t available at a specific time or a back-up individual can be found. the Product owner needs to understand they are expected at the Sprint Review, Sprint Planning, Retrospectives, and Daily Stand-ups and should be available to handle questions in realtime from developers.

We closed with a brief discussion about the sustained agility concept of using a Kanban to feed Sprint teams “ready requirements” to be finalized in the individual Sprints. This has been useful for regulated environments (of which the Government is one). If this is being done, the Product Owner should own this pipeline. This concept was originally brought to my attention by David Bulkin of Lithespeed.

This was a great conference and the open space type of talks tend to be very informative as you learn from other practitioners about the trials and successes they are having in implementing Agile practices.

Filed November 15th, 2010 under agile, Other Groups, Session notes

For our 10 September meeting, we discussed around a theme of estimation.  We started with some lightning talks that progressed into heavier discussions on Estimation.  These lightning talks were as follows:


Paul - A review of sorts of Dan Roam’s book, “Unfolding the Napkin”, which is about solving and communicating complex problems with simple pictures.  These often can be used in estimation or to communicate a plan with its estimates as opposed to more complicated diagrams such as Gantt charts which are more difficult to follow. 

Manoj - discussed estimations around the inability to see the future; he titled his talk “You’re going to be wrong, so be wrong quick”.  In it he discussed how estimation is of course very hard, few teams use evidence based information in estimating and take a bottoms up approach to making estimates.  This produces quite a few errors and the point is to get started on the work so that these errors can be discovered and resolved quickly.

Ken - he had the discussion around “It’s in your genes!” essentially discussing the human side of estimation and that our brains are wired for pessimism, optimism, or any other form of error when we simply have to give estimates.  Ways to help resolve this is looking at evidence, anecdotal or statistical evidence from previous work and then using it as a starting point for the team developing estimates.  Additionally, having the team participate even in a bottoms up approach removes some error as a single person isn’t providing input which would be more error prone than several people.


Afterwards we discussed some of the estimation techniques we use.  While some teams are doing planning poker, it seemed more were doing a relative ranking (still based around the Fibonacci sequence) on a wall with stickies.  The team determines an average story and then ranks all other stories as being easier or harder.


Another technique is to decouple the requirements readying, breaking down epics and stories and qualifying them to be ready for a Sprint.  This makes the estimation easier if an assumption is that the story will be ready.  Thanks to David Bulkin for introducing this technique at the 2010 US Agile Coach Camp.

Tere was one more discussion, but I am out of time for typing at the moment, so will add it later. 

Filed September 30th, 2010 under methods, techniques, agile, Session notes

To me, Agile software development approaches feel very natural.  It got me to thinking why…  I believe it may be because it has some similarities with what we experience in nature every day.  So this posting is to compare and contrast what feels natural in Agile.  While I recognize I am describing this in more or less an ideal fashion, it can help obtain some clarity by doing so.

What’s natural… 




Like streams, agile development flows to deliver value.  That value may be increased throughput of a process or an increase of sales, improvement in communications, or a myriad of other things.  

Even the lightweight processes we put in place are like flows.  Short feedback loops are like eddies in the stream.  Continuous integration is all about making this cyclical flow of feedback get shorter still.  Techniques like Kanban help us visual this flow, identify blockages that we need to keep the flow from backing up, and setting work in process limits help us make the flow continue smoothly.  

While some techniques or methods may seem more flow-oriented than others, I’d say that all of them try to identify and help flow become smoother. Whether it used only internally by the team to get feedback or to continuously create value, this usually comes down to emphasis only.  


Rhythms: sunset.jpg

In nature we see rhythms all around us, the rotation of the earth to give use the sunrise-sunset cycle, our heart pumps our blood with a regular beat, the regular change of seasons, and so on. 

Many of the techniques we use in Agile are to identify and help sustain team rhythms.  We have daily stand-ups to feel the pulse of the team.  We do regular just in time reviews and planning to help maintain the rhythm of work we are doing.  We measure velocity to understand if our cadence is being effective.  All of these is not necessarily about speeding up the rhythm of our team, though on occasions this may be desirable; it is more likely to identify, amplify, and understand what the team’s drumbeat is.  

The heartbeat is probably the best metaphor.  We look to ensure it is there, measure to know it is healthy, and when irregularities occur, we try to correct them as quickly as possible before they become detrimental.


Small Batches: tomatoes.jpg

Nature gives us things in small batches.  The weather gives us periods of rain intermittently with sunshine and plants produce fruits for only a short period.

In Agile, many of the ways we approach things are to also try and deliver value in small batches.  We attempt to demonstratively develop a small number of features that are ready for release.  Using restrospectives, we attempt to identify and implement a small number of improvements to help the team. 



Ray with Remoras Photo by blondcavefish

Nature shows us many symbiotic relationships.  We’ll find remoras with rays or sharks for example; remoras help clean the sharks and the shark’s hunting provides the food the remoras need.  Sea anenomes will provide protection for the clownfish.  

In Agile, I identify this symbiosis as collaboration.   This could be our customers who provide requirements to the developers who build to these and demonstrate they achieved them back to the customer.  It could be the project manager (to use a generic term) that facilitates removal of barriers.  We use pair programming to ensure improve team collaboration.  We use techniques like team retrospectives to help us find ways to collaborate better.


Self Organization: ants.JPG

In nature teams organize to overcome threats or work together to hunt.  The insects or animals in these circumstances collectively understand the goal, the sense of urgency, and the required communication.  There isn’t large upfront planning by one animal, though one may take a leadership role and commit with the rest joining in.

Likewise, Agile teams self-organize to deliver working software, resolve issues, or make plans.  In the ideal, this is done with as little ceremony and overhead as possible.  It will involve the entire team when it makes sense (e.g. planning an iteration) or the right members (e.g. pair programming) at other times.  When a major obstacle is encountered, the entire team will swarm until it is removed.


So if I am making a comparison to what is natural, it probably behooves me to look at 


What’s not natural…


Checklists: checklist.jpg

Checklists are used to ensure things get done.  While one may use this as a tool in self-organization, it doesn’t feel natural; this is particularly true after you have tried Kanban and in particular Personal Kanban.  Checklists feel overly simple and hide some of the complexities that need to be discussed.  They tend to fall under control of one individual, which works well if it is intended to be used by only one person.  If however they are intended to be used by a team, they tend to fall apart, as only  one person is usually placed in control of the checklist. Often checklists aren’t tailored to the context of the project at hand either.

I’m not personally against using checklists, but they don’t feel natural.  So I am suggesting just ensure that the context and environment is considered carefully. 


Sameness: Manufacturing Line Photo by CHS Inc

In nature, nothing is identical; even identical twins aren’t truly identical.  Plants grow based on the environment; the same plant type may grow differently based on how much sun or water they get.  A stream meanders according to its terrain.

Software development is a craft. Craftsmen attempt to achieve perfection, but in context for what is being built.  Even a commercial off-the-shelf application packages (e.g. an office application suite like Microsoft Office) are used differently by different organizations; each are built to different goals.  

Contrast this with a manufacturing line; there if every item could be identical that would be a desirable process.  It would mean the process is producing goods within the desired tolerances.  


Big Upfront Design: Blueprint Photo by debbiedoescakes

And this probably the least natural.  Nature uses evolution to guide its designs.  Ants don’t lay out a huge plan to raid the picnic; they get sensory feedback, self organize, and attack.  Their planning is instinctive in nature and much like rolling wave planning.  Watermelon too big to move?  Bite and cut it into pieces for transportation.

Here is another example akin to rolling wave planning; evolution developed the sequoia trees to drop their cones around its base.  The seeds then start growing the young sequoias in a circle around the parent tree.  When the parent dies, it leaves a circle of trees called a druid circle.  This is a plan that as environment of the sequoias change they will slowly evolve to perhaps have seeds that are blown like maples, or roll, or a perhaps will become dependent on being dispersed by animals.


If you liked this article, please tweet it!

Filed August 22nd, 2010 under methods, techniques, comparison, agile
Next Page »