Culture and Agile Adoption

Its a Punch and Judy Show

Beach Hut - By Martin Harris

More and more I have been thinking about the effect of culture on Agile adoption. Then a friend tweeted this article on Agile Culture by Michael Sahota. Its a real eye opener and one key message is that it might be quicker to fit your process to the culture rather than the other way around.

There is some evidence to suggest that trying to introduce and Agile Development system into a culture that won’t naturally accept it is a recipe for failure.

For me its more complex that this. I am not 100% sure I am anywhere near a solution but these thoughts arise.

Evolution v Revolution and mandate
Without going into the detail which can be found on other posts the cultural fit is probably more important if you can’t change the culture. Most of the time we are somewhat restricted by our mandate. Its rare that someone senior wants this bad enough that they are prepared for the risk of revolutionary change.

If you were about to move in that direction, perhaps you can change the culture to fit. This path is also easier if your scope is small. i.e. if your dealing with a small group of people and not a multinational.

Otherwise perhaps initially selection of technique and Agile process should be culture driven.

The Kanban / Control argument
Its interesting to see Michael point out that Kanban is not Agile. At least by cultural definition. It occurred to me also that successful open source cultures might not be Agile either, they seem to fall into the “Craftsmanship” section.

Yet, were you to take a controlling culture and conduct Kanban with XP practices might it not over a long period of time begin to change. Perhaps towards craftsmanship as an appreciation of quality evolves?

So what now then Agile Coaches and CTO’s?
Well I for one have found the diagrams very useful. Just an awareness of this idea helps bring people to a higher view of what might be going on in their Agile Adoption process and that is no bad thing. Its too easy to get wrapped up in the daily Punch and Judy show forgetting about the bigger picture.

Digg This
Reddit This
Stumble Now!
Buzz This
Vote on DZone
Share on Facebook
Bookmark this on Delicious
Kick It on DotNetKicks.com
Shout it
Share on LinkedIn
Bookmark this on Technorati
Post on Twitter
Google Buzz (aka. Google Reader)

InfoQ: Chet Hendrickson on the Need for Good Technical Practices

Excellent interview that parallels some of my experiences.

InfoQ: Chet Hendrickson on the Need for Good Technical Practices.

Digg This
Reddit This
Stumble Now!
Buzz This
Vote on DZone
Share on Facebook
Bookmark this on Delicious
Kick It on DotNetKicks.com
Shout it
Share on LinkedIn
Bookmark this on Technorati
Post on Twitter
Google Buzz (aka. Google Reader)

Tumble dried BDD from Studio Pragmatists

On the 18th of May, 2010, the very new tumbler-glass project by Studio Pragmatists uploaded Tumbler 0.2.1 to Maven.  Having recently written about JBehave I found myself really liking the concept of behavior driven development.  So I decided to write a similar article about Tumbler. If you want the project code its available in my example project.

4 hour time box in 20 minutes!

Once again I decided to time box the work to 4 hours.  This time though the whole process only took about 20 minutes.  The product owner and testers produce a story file.  The Tumbler format allows for multiple stories each containing scenarios, so its possible to cover a complex set of requirements in one file.  This allows for flexibility when breaking down the work into tasks.  As per the usual behavior driven approach, a scenario contains the Given, When and Then sections which describe the behavior. Continue reading

Digg This
Reddit This
Stumble Now!
Buzz This
Vote on DZone
Share on Facebook
Bookmark this on Delicious
Kick It on DotNetKicks.com
Shout it
Share on LinkedIn
Bookmark this on Technorati
Post on Twitter
Google Buzz (aka. Google Reader)

Bad or Good? Behavior Driven Development within Scrum.

I wanted to explore the possibility of using JBehave to formalise scrums definition of done. The idea being to encapsulate a definition of done as a JBehave scenario. So in true scrum style I decided to timebox 4 hours of work dedicated to JBehave.

From a scrum point of view BDD can be used to turn the definition of done into a test artifact. The team produces scenarios for each task. With JBehave a scenario file describes the required behavior and test steps it will need to pass to be considered done. I.e Given some prerequisites, perform some action and expect some results. See the JBehave project for more detail as this is only a simple example. Continue reading

Digg This
Reddit This
Stumble Now!
Buzz This
Vote on DZone
Share on Facebook
Bookmark this on Delicious
Kick It on DotNetKicks.com
Shout it
Share on LinkedIn
Bookmark this on Technorati
Post on Twitter
Google Buzz (aka. Google Reader)