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)

Estimates are not commitments!

Velocity, the new estimate

Cambodia, Phnom Penn, the water festival: Martin Harris

Probably one of the most common mistakes in Software Development is to allow Estimates to become Commitments.  I am sure you know the following scenario all too well.  The development team is called into a meeting room and asked the following question.  We (the management team) have had a look at the estimates, and your tasks on average are taking longer. The insinuation is that the development team is, stupid or perhaps lazy.  Worse still, an individual is called in because the stats show their work is “Behind Schedule” as judged by the estimates.  The problem is none of this though, the problem is believing that estimates are anything other than an educated guess.

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)

Dancing to the tune of the Scrum Demo

As you achieve more experience with the scrum process, you come to realise that there is very little if anything you can afford to leave out. If your conducting scrum and considering leaving out a practice, its worth considering what is to be gained and lost.  So continuing with the scrum and agile theme this year I plan review some of the scrum practices highlighting the benefits and some of the errors that are made.  The first of these focuses on the Sprint Review and within that in particular the Software Demo.

Craig Larman in Agile & Iterative Development, A managers guide describes it thus:

Sprint Review: At the end of each iteration, there is a review meeting. (maximum of four hours) hosted by the Scrum Master.  The team, Product Owner, and other stakeholders attend. There is a demo of the product.  Goals include informing stakeholders of the system functions, design, strengths, weaknesses, effort of the team, and future trouble spots.

Feedback and brainstorming on future directions is encouraged, but no commitments are made during the meeting.  Later at the next Sprint Planning meeting, stakeholders and the team make commitments.

“Power Point” presentations are forbidden.  Preparation emphasis is on showing the product.

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)