RSS

Tag Archives: Collaboration

Do you believe in magic?

Recently, I had the good fortune of seeing Sonny Rollins in concert. Any one member of Sonny’s band would hold the stage on their own.

Sonny Rollins was the drawcard but the concert was not just about him; the band collectively made it about the music, together as a whole, not any one individual. Obvious solos abound but mini-solos and subtle by-lines ran through the various cuts and all throughout you could see musicians seeing, feeling, expressing in response to the others. Two hours flew by like it was only 20 minutes – no breaks, very little jabber, just pure enjoyment.
Watching them reminded me how we strive to bring together our various operational and project teams.

At this point, you’re probably thinking, “Huh? I thought you were talking about Sonny Rollins? What does Jazz have to do with teams?”

Watch a good jazz band and you’ll see a team collaborating and sharing the whole. Watch a tight, outstanding, mind-blowing group and you’ll see magic happening and the outcome is on a whole different level.

How do some groups achieve magic? Watch and learn from the greats… you’ll see they LISTEN to each other and their whole blend. The spotlight is SHARED and they aren’t afraid to TRY. Innovation is part of their nature; dare I say habitual. They display emergent behaviour – complex patterns arising from simple interactions.

Jazz is characterised by improvisation, syncopation tied together by regular underlying rhythm(s). As the team lead or manager, we do whatever is needed to help maintain the underlying directional beat while the overall team contributes their various melodies, counter-melodies and rhythms. We don’t insist on keeping the spotlight or insist on being the only one driving the beat, but work alongside those that we lead. And like a jazz group, a well performing team adapts as the situation morphs and different voices emerge.

Magic doesn’t happen often enough and never happens on its own but the magic is there.

I believe in magic.

 
Leave a comment

Posted by on June 16, 2011 in Culture, Uncategorized

 

Tags: , , , , , ,

Why so little good Agile?

Today I gave a talk at the  Government Test Professionals Forum conference in Wellington.

I presented a case study about how the Farm Systems Division of Livestock Improvement Corporation have adopted Agile methods.
I told the story of Team Awesome (they choose the name themselves), how their practices have changed and the measurable benefits that have resulted from their new way of working:

  • Massive reduction in residual defects
  • Increased team satisfaction
  • Shorter time to market
  • Increased customer satisfaction

I told the story of how the team collaborates, how all the roles work together. How testing is fully integrated into the flow of work and how the whole team (developers, analysts, product manager, testers) coordinate their activities starting with expressing the detailed requirements for user stories as test design specifications using the Behavoural Driven Development model. They have adopted Agile well, and gained the benefits that all the books talk about.

After the talk I was chatting with one of the attendees and she said that my story was unusual – her experience as a tester on “agile” projects has been uniformly negative – testers as victims of development teams who use “going agile” as a excuse for hacking and not bothering with requirements.

This saddened me; surely we know how to apply these practices properly, don’t management in our organizations understand that agile is about applying the practices in a disciplined way, you can’t just pick the pieces that seem easy? Agile works when the combination of practices are applied together – for example: user stories are a good technique for identifying features and prioritizing the work to be done, but they must then be supplemented by some technique to define the detailed requirements on a just in time basis, just ahead of when the story will be developed. You can’t just adopt user stories and ignore the detailed requirements and testing – that is truly Tragile, but seems to be oh-so-common.

Building software is hard work; building good software takes a concerted team effort, irrespective of the methodology being used. We know this, and have known this for the last 40 years.

Please stop calling these half-hearted implementations Agile – it’s not, it’s just a continuation of the bad practices that many organizations have followed over the years, just with a different brand.

 
1 Comment

Posted by on May 3, 2011 in Agile, Testing

 

Tags: , , , , , , , , , ,

It is more important to deliver value than to deliver on-time and within budget

I have placed a link below to an article written by Tom De Marco.  It raises some very interesting issues.  I think one of the most important issues it raises is pertinent to my thoughts on how important it is to have a proper, and is far as is practicable quantified, business case for any software project.   Please please please establish the business case before attempting to estimate the cost/effort of a project.  I also feel the article presents a strong argument for agile approaches (please note the small a) to the development process ….. processes that are nimble, flexible, collaborative, non-bean-counter-driven, focussed on delivery of value

Check out this article from Computing Now:

http://www2.computer.org/portal/web/computingnow/0709/whatsnew/software-r

Also: a reminder … have a look at this link (first posted by Shane)  http://www.cio.com.au/article/205313/why_projects_fail_part_three_wrong_targets

Posted by John Watson

 
 

Tags: , , , , ,