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 141 posts at DZone. You can read more from them at their website. View Full User Profile
A few posts back, I asked if an agile team should be expected to call
their shots. In other words, should we expect that over time, an agile
team should be able to accurately predict what they'll be able to
deliver at the end of the iteration? My assertion was that
predictability at the iteration level is the only thing that separates
an agile project from total chaos. Without the ability to make small
commitments on a regular cadence, we have no ability to forecast what we
can get done.
I'm working with one team right now that has
gotten really good at calling their shots... but... people keep getting
pulled in and out of the team. Having a stable velocity is predicated
upon the team working together, staying together, and learning how to
estimate and plan together. The constant churn at the team level is
making it really tough to establish a consistent velocity iteration over
iteration. While the team is great at calling their shots, they are
still not able to really say what they can get done... and by when.
a big believer that if we can't get some idea of what we are going to
deliver, and when we are going to deliver it... pretty quickly after
spinning up a team... agile is almost a non-starter for most companies.
Many of the companies I work with are not prepared to make an
indefinite investment, with no idea of what they are going to get in
return. Sure... agile teams fix time and cost, and vary scope to meet
iteration objectives... but we have to have some ability to look ahead
and manage the expectations of our customers. We have to have good data
to help them make good decisions.
What I am really saying here,
is that while calling your shots is essential, calling your shots isn't
really enough. You also have to get good at understanding the size of
your bucket. What does that mean? It means that iteration over
iteration, I need to establish some kind pattern for how much feature
functionality I can deliver back to the business. Out of the gate, I
don't really care what the team delivers... or even how much they
deliver... I want to know their delivery capacity over time. Not a hard
fixed number, but a stable trend that I can base product decisions.
time, we will remove the teams blockers and help them deliver more
effectively, but initially... they need to get good at calling their
shots... and establishing the size of their bucket. So please... let me
know what you think. Am I expecting too much from our agile teams?
Should teams just be able to do what they can with no expectation of
committed delivery? Even at the iteration level?