Let's stop doing the wrong thing because we can't get past an impediment

August 31, 2015 — Posted by Al Shalloway
I've been watching the Agile community since 1999.  A pattern I've seen is that when we can't get the right behavior, we just back off and redefine things. The first time I saw this was the Scrummaster.  In my mind, the Scrummaster is simply a new role we made because few knew how a project manager should act.  Quick fix - eliminate the role and make a new one.  Then we saw the creation of the product owner since we didn't know how to have a business analyst do their job when multiple people were asking for different things to happen. Now I keep hearing that commitment is a bad thing and undermines trust.  I disagree.  You build trust by making promises and keeping them. Do you know any other way?
 
Commitments are necessary and estimates are necessary if you want predictability of what is going to happen. We don't need to have accurate estimates of the individual items, just a general velocity. In other words, some items can be wrong one way, the others wrong the other way, all in all the average can be reasonably close.  We call this the law of large numbers. 
 
Eliminating commitments, estimations and velocity because we can't get people working together will keep us stuck. The problem isn't that commitment is bad, it's that what we think about commitments is wrong.  A commitment is not something you keep or you are a bad person if you don't.  A commitment is something you make every effort to keep while being responsible if you can't.  I jokingly tell the story of what would happen if I promised my wife I'd be home at 6pm after a course so we can have dinner.  I come home and tell her that one of the students asked me to have dinner with them to close a million dollar contract.  However, since I had promised her I'd be home at 6 I told him I couldn't do it. Let me tell you, she'd be pissed.  On the other hand, if I came home at 10pm with a million dollar contract and explained I didn't make 6pm because of going to dinner to get the contract, she'd still be pissed.  I mean, why didn't I call?  The point is the commitment sets the stage for what the intention is and within that understanding we have agreements in place as to what to do if we can't keep them. This builds trust.
 
In the Agile space, a commitment of how much work can be done within a sprint is what we are saying will happen and that we will communicate not reaching this goal as soon as it appears it won't.  It also means we won't get distracted and work on other things that we've not committed to.  We are agreeing to stay focused on our promises. Bottom line, we are agreeing to how we will work together.  This builds trust. 
 
In mentioning some of the contrivances of the past, I am reminded of my favorite quote from Buckminster Fuller:

I am enthusiastic over humanity’s extraordinary and sometimes very timely ingenuity. If you are in a shipwreck and all the boats are gone, a piano top buoyant enough to keep you afloat that comes along makes a fortuitous life preserver. But this is not to say that the best way to design a life preserver is in the form of a piano top. I think that we are clinging to a great many piano tops in accepting yesterday's fortuitous contrivings as constituting the only means for solving a given problem. Our brains deal exclusively with special-case experiences. Only our minds are able to discover the generalized principles operating without exception in each and every special-experience case which if detected and mastered will give knowledgeable advantage in all instances. Because our spontaneous initiative has been frustrated, too often inadvertently, in earliest childhood we do not tend, customarily, to dare to think competently regarding our potentials. We find it socially easier to go on with our narrow, shortsighted specialization's and leave it to others primarily to the politicians to find some way of resolving our common dilemmas.

 

Subscribe to our blog Net Objectives Thoughts Blog

Share this:

About the author | Al Shalloway

Al Shalloway is the founder and CEO of Net Objectives. With over 40 years of experience, Alan is an industry thought leader in Lean, Kanban, product portfolio management, SAFe, Scrum and agile design.



        

Blog Authors

Al Shalloway
Business, Operations, Process, Sales, Agile Design and Patterns, Personal Development, Agile, Lean, SAFe, Kanban, Kanban Method, Scrum, Scrumban, XP
Cory Foy
Change Management, Innovation Games, Team Agility, Transitioning to Agile
Guy Beaver
Business and Strategy Development, Executive Management, Management, Operations, DevOps, Planning/Estimation, Change Management, Lean Implementation, Transitioning to Agile, Lean-Agile, Lean, SAFe, Kanban, Scrum
Israel Gat
Business and Strategy Development, DevOps, Lean Implementation, Agile, Lean, Kanban, Scrum
Jim Trott
Business and Strategy Development, Analysis and Design Methods, Change Management, Knowledge Management, Lean Implementation, Team Agility, Transitioning to Agile, Workflow, Technical Writing, Certifications, Coaching, Mentoring, Online Training, Professional Development, Agile, Lean-Agile, SAFe, Kanban
Ken Pugh
Agile Design and Patterns, Software Design, Design Patterns, C++, C#, Java, Technical Writing, TDD, ATDD, Certifications, Coaching, Mentoring, Professional Development, Agile, Lean-Agile, Lean, SAFe, Kanban, Kanban Method, Scrum, Scrumban, XP
Marc Danziger
Business and Strategy Development, Change Management, Team Agility, Online Communities, Promotional Initiatives, Sales and Marketing Collateral
Max Guernsey
Analysis and Design Methods, Planning/Estimation, Database Agility, Design Patterns, TDD, TDD Databases, ATDD, Lean-Agile, Scrum
Scott Bain
Analysis and Design Methods, Agile Design and Patterns, Software Design, Design Patterns, Technical Writing, TDD, Coaching, Mentoring, Online Training, Professional Development, Agile
Steve Thomas
Business and Strategy Development, Change Management, Lean Implementation, Team Agility, Transitioning to Agile
Tom Grant
Business and Strategy Development, Executive Management, Management, DevOps, Analyst, Analysis and Design Methods, Planning/Estimation, Innovation Games, Lean Implementation, Agile, Lean-Agile, Lean, Kanban