Mike is a certified PMP project manager and a certified ScrumMaster. Mike was involved with the creation of the DSDM Agile Project Leader certification, holds this certification at the Foundation, Practitioner, and Examiner levels. Mike was named an honorary member of the DSDM consortium and served on the board of APLN and the Lean Software and Systems Consortium. He currently co-leads the PMI Agile Community of Practice. Mike is a DZone MVB and is not an employee of DZone and has posted 147 posts at DZone. You can read more from them at their website. View Full User Profile
What do I look for day-one coaching an agile team? The first thing I
want to know is if the team is really a team? Do they have everything
(and everyone) they need to deliver an increment of working software?
Do they plan together, do they work together, do they deliver together?
I'm generally of the mind that if you aren't going to recognize the
team as the fundamental unit of value creation, you will struggle with
almost everything else agile has to say about product delivery. You
might be doing something... it might even produce working products...
but it probably won't look very agile.
Once I have the team in
place... the next thing I want to know is if they can make and meet a
commitment. I want to know if they can be predictable. Right out of
the gate, I am not all that concerned if the team can deliver fast... I
might go so far as to say, I don't even care that they deliver value.
To me, the most important thing is that the team gets good at
establishing some sort of baseline velocity metric. I want them to be
able to break down work into small chunks, put some sort of reliable
point estimate on their work, and get good at doing what they say they
are going to do.
Making and meeting commitments on a regular cadence is the heartbeat of an agile team.
of you guys ever play pool with your kids? When my kids were younger,
they'd just walk up the table, quickly eyeball their shot, and do what
they could to get the ball in the pocket. Every now and again they'd
actually make a shot, but they'd never beat me playing an entire game.
They were doing their best, but they never won. To really be successful
playing pool, you have to be able to sink the ball you are trying to
sink... and do your best to set yourself up for the next shot (or two...
or three). Unless you are able to call each shot, you really don't
have any idea how you are going to win the game. Success is accidental
If the team can't call their shot... in other words, if
they can't predict their velocity at the beginning of the sprint, there
is no point doing any kind of forward thinking, any kind of release
planning, or even trying to make a guess at what you are going to put in
market when. Your product delivery dates are nothing but fiction.
Having a stable velocity is the fundamental prerequisite for managing
the expectations of the business. It's essential if you are
coordinating with other teams to deliver the release, and essential for
making tradeoffs when things don't go exactly as planned. Stability
builds trust with your product owner and it builds trust with your
Do what do you think? Is it important for agile teams to be able to call their shots? I think it's essential.