Achieving Test Driven Nirvana

Car Cuba

Cuban Car: Martin Harris

Well perhaps not Nirvana then, but at least having a suitable level of test coverage.  ;-)

I wanted to write an article around the uptake of test driven development. Scrum and agile are hard to do well. If you break these down, you often find that the components are pretty challenging too. TDD is difficult but it has gained widespread recognition at the intellectual level.  On the ground though the practice can be patchy. Why?

Before writing this article I had a look around to see what else had been written.  This article on Geiger’s Counterpoint sums up my thoughts exactly.  Its such a good article that I hardly have anything left to say.  In fact neatly I can just provide some bullet points!

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)

Influencing self organised teams

Fragile, Pink Rose, Beijing: Martin Harris

Pink Rose, Beijing: Martin Harris.

I have been reading chapter 12 of Succeeding with agile by Mike Cohn.  The chapter title is Leading a Self-Organising Team. I have been reading it in the following context:

Strive for technical excellence and Improving technical practices is not optional.

Why is it that improving technical excellence is sometimes neglected on a project?  Why do developers think its ok to check in classes with warnings, leave essential and easily written tests out or add to messy code.  You must of heard the phrase “nobody cares about a building with broken windows.”  One more broken window will not matter. The same applies to software. Often you will find developers harboring some kind of guilt for not fixing things.
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)

Scrum, where exactly do the managers go?

Two friends helping with a load of dried fish.

Goa State, India, Lifting the load: Martin Harris

Project Management Offices really serve no purpose in scrum. You are either a product owner, (not a manager), scrum master (not a manager either) or your in the team, (no technical leaders here either). So what about all that useful controlling and reporting stuff they used to do?

  • Program management functions should be moved into the team.
  • Team support comes from Agile coaches, or scrum masters.  They are not managers, they guide and do not tell the team what to do.
  • Responsibilities of release, budget, tracking reporting etc, are the Product Owners domain, once again the Product Owner is not a manager.

Its a bad idea to keep the PMO and attempt to re-brand it under Scrum.  Keeping the unit and asking people to be scrum masters is a recipe for disaster.  Its hard to change team culture over to scrum.  Teams find it a big challenge to throw off the old and become self directed.  If you have your old manager coming to your team the roles stay right where they were.  So if you want to keep members of the PMO and they are technical, make them part of the team or remove them from the process.

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)

Standing up at your scrum

The scrum stand up meeting, is sometimes renamed to “the scrum”.  This is fine but remember you are supposed to stand up.  The reasoning behind this is it keeps the meeting short.  People do not become too comfortable.  The idea is very simple.  Quickly broadcast any information from the scrum master, then whizz around the team collecting status and blockers.  Each member outlines what they are working on that day.  No design discussions or protracted dialog on anything else.  Take discussion offline.  Keep screens and software products tracking tasks out of it too.  Its not a bad idea to have the visual indicators available.  People can then point to the task card, this helps other interested parties keep track of what is going on.

Beware all yea who let the stand-up slip into longer formats, your wasting company money and time.  Possibly you could end up on this new social site Meet or Die!

I have been in scrums with established teams, where extraneous dialog started to creep in.  My scrum master introduced a speaking ball.  The ball is passed around.  You can only speak if you have the ball.  Anyone speaking out of turn is marked on a board.  When you gather enough marks you have to buy food for the team.

Sounds silly, but it did make the meeting fun…chucking the ball around, and kept it short.

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)