How Big Is Your Bucket?

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.

I'm 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.

Over 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?

Subscribe to Leading Agile

How to Own a Really Big Complex Product #agile2010

Hey folks... here is the deck I am doing this morning at Agile2010. I am pretty excited to do this talk... I finally feel like I've got the slide sequence and story right. It's amazing what a good night sleep will do for you! My talk is in E-2 on the Ballroom level, hope to see you guys there!

How to own a really big complex product v3

View more presentations from Mike Cottmeyer.

Subscribe to Leading Agile

Interesting Post... 7/31/2010 through 8/7/2010

Okay… we are going to do a Saturday evening edition of Interesting Post… Tomorrow I am going to get up early, do a little hike through the woods, bring home bagels for Kimi and the kids, toss the football with Noah, and then head to the airport for a week in sunny Orlando and the Agile 2010 conference. I'm totally geeked heading to Orlando as an independent agile coach. Did I say I'm geeked ;-)

There are so many people that I want to talk to and so many things I want to do and see while I am in town. I'm am looking forward to having one heck of a week. If you are going to be at the conference… give me a call, shoot me an email, or DM me and let's find a few minutes to get together. I'm doing my talk on How To Own a Really Large Complex Product… so come see me there too!

Travel safe and I'll see you in Orlando.

Interesting Post... Process: friend and foe http://dlvr.it/3WFjb

Interesting Post... Agile Conference - Speakers - Don Reinertsen http://dlvr.it/3VtlW

Interesting Post... What is Test-Driven Development? http://dlvr.it/3TsNz

Interesting Post... Kanban for Service Desks http://dlvr.it/3Tg81

Interesting Post... What's next for the agile community? http://dlvr.it/3TZT9

Interesting Post... 30 Days of Getting Results the Agile Way http://dlvr.it/3S085

Interesting Post... Kanban Experience Complete – Thank You LSSC10 http://dlvr.it/3S084

Interesting Post... PMBOK and detailing leadership http://dlvr.it/3Ryvj

Interesting Post... Agile Rollout Warning Signs http://dlvr.it/3Ryvd

Interesting Post... One Size Does NOT Fit All! http://dlvr.it/3QcGN

Interesting Post... Creating an Agile Environment Fit for a Marketing Team http://dlvr.it/3QbCC

Interesting Post... I won’t be staying late with you http://dlvr.it/3QbCB

Interesting Post... Bob Payne and the Art of Agile Philanthropy http://dlvr.it/3QbC9

Interesting Post... Re-Think Transactions http://dlvr.it/3QbC8

Interesting Post... Yes You Kanban! http://dlvr.it/3QbC7

Interesting Post... What Should Done Mean? http://dlvr.it/3Pqf0

Interesting Post... Scrum Butt and the Nokia test http://dlvr.it/3PpVP

Interesting Post... Can Agile Work If Some Of My Development is Outsourced? http://dlvr.it/3PmsC

Interesting Post... Agile Software Requirements: We Have a Foreword and a Cover – Can a Book be Far Behind? http://dlvr.it/3PlnJ

Interesting Post... The Gordon Pask Award http://dlvr.it/3PlnG

Interesting Post... DZone RefCard Update http://dlvr.it/3PlnC

Interesting Post... The Difference between Lean and Agile http://dlvr.it/3M1XT

Interesting Post... Agile 2010 Talk: Agile Transitions- Cannonball and Stealth Approaches Exposed/Compared http://dlvr.it/3KWGb

Interesting Post... Minimum Concepts for Earned Value Management http://dlvr.it/3KTlL

From Leading Agile: On Leading Agile... Change... The Only Constant http://dlvr.it/3GLFX

Interesting Post... Top Excuses Why Automatic Builds Suddenly Fail http://dlvr.it/3GCc1

Interesting Post... Agile Communications http://dlvr.it/3FGZZ

Interesting Post... Project Management Definition - Part Three http://dlvr.it/3FCJs

Interesting Post... If your dev team jumped off an agile bridge, should your marketing team jump too? http://dlvr.it/3FCJt

Interesting Post... Keeping in Tune http://dlvr.it/3FCJv

Interesting Post... Good Agile software team looking for an agent to represent us! http://dlvr.it/3F6Zs

Interesting Post... If It's Painful, Do It More Often http://dlvr.it/3F6Zj

Interesting Post... The painful reality of many meetings http://dlvr.it/3Dzpb

Interesting Post... Are We Agile Yet? http://dlvr.it/3DzpS

Interesting Post... Agile Coaches Gathering UK 2010 http://dlvr.it/3DzpR

Interesting Post... Getting unstuck: solving the perfect problem http://dlvr.it/3DzpN

Interesting Post... Ten Principles for Agile Testers http://dlvr.it/3DzpJ

Interesting Post... Design what you know http://dlvr.it/3Dzp9

Interesting Post... Fire everybody! How to start transitioning your marketing team. http://dlvr.it/3Dzp1

Interesting Post... Agile: It’s a Healthy Lifestyle Choice http://dlvr.it/3Dznw

Interesting Post... Every Team Must Be a Value Unit http://dlvr.it/3Dzns

Interesting Post... Do architects define the software development process? http://dlvr.it/3Dznm

Interesting Post... Traditional versus Agile — false war? http://dlvr.it/3Dzng

Interesting Post... A Pattern for Using Scrum and Kanban http://dlvr.it/3Dznf

Interesting Post... The Lean Product Backlog – Limit Variation and Prevent Overburden http://dlvr.it/3DznW

Subscribe to Leading Agile

Should Agile Teams Have to Call Their Shots?

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.

Any 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 at best.

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 business.

Do what do you think? Is it important for agile teams to be able to call their shots? I think it's essential.

Subscribe to Leading Agile

Change... The Only Constant

Sorry to be so quiet lately... lot's going on with me, both personally and professionally.

I need to bring you guys up to speed on a pretty big announcement. As of last Friday, I've left Pillar to go out as an independent agile coach. Pillar was a great learning experience for me, and I am thankful to Bob Myers and the great team of folks at Pillar for everything they've done over the past year. In trying to spin this thing up in Atlanta, I found myself spending most of my time doing sales and business development... and not working hands-on with teams and organizations.

I'm going to try to flip that around a little and try to spend most of my time on the ground coaching teams, and maybe if all goes well, I'll get to spend less time on the sales side... we'll see. What was cool about this whole thing, is that the guys at Pillar totally understood and supported me through this transition. We've decided to maintain a partnership... and a friendship... and where it makes sense, Pillar will help me scale some deals that would be tough to scale as an independent.

So... where does that leave me now? I've incorporated LeadingAgile and managed to find enough work to keep me afloat for the next few months. While I'd love to work close to home, I've got no geographic limitations. I need to fill my calendar through the end of the year and am interested in working with interesting people, solving interesting problems... where ever they happen to be. If you think my brand of agile is interesting to you and your organization, give me a call.

I'd love to talk about working together.

(PS - My contact information is at the top of this blog ;-)

Subscribe to Leading Agile