I See Scared People

Starting a team new to agility on their first sprint is one of my favorite and most rewarding things to do.  The enthusiasm,  newness,  sense of accomplishment,  teamwork, and the communication displayed in just the first sprint is usually enough to leave most folks happily surprised.  

“Wow, I never thought our team could work like that.  And we got so much done and without all the waiting and waste.  Wow!"

Of course that’s not what I hear at first.  Well before the first sprint what I usually hear is this:

“We’re all working on 6 projects at once, I can’t be on the Scrum team too."
“We can’t have features all the way done, because they have to go through UAT and be approved by the quality review board, you can’t do that in 2 weeks."
“We have to have an approved architecture before we can get a development environment setup"
“I don’t think our offshore vendor will work this way."
*These are are real quotes from real people

A long time ago when I first started in management consulting, what I would hear when people said these things was logical arguments and problems that needed solving.  And I’d go about my job and help them solve these problems.  This typically resulted in passionate arguments and heated debates.  I was only marginally successful. 

What I hear now is fear.  I hear people scared to try new things.  Afraid of what will happen if it fails.  Unsure about how the new process fits in with the old.  Fear that they could be held personally responsible if things go south.  

And this is far more useful a conversation starter.  People can more easily be coached around fear than argued with logically.  Especially when it comes to “the way we’ve always done it here” issues. 

Do you want you team to think about it, or build it?

One of the Agile Manifesto principles says we should “build projects around motivated individuals – give them the environment and support they need – and trust them to get the job done.”

Recently I was reminded of how powerful a Scrum team can be when we simply trust they can solve a problem.  We were looking at using some new technology - something the business wasn’t familiar with and the team had only limited training on.  As is common in large companies we got stuck in an analysis loop for quite a while.  The business wasn’t really comfortable moving ahead with this new technology until a swath of questions were answered.  How will it work when it’s done?  How long will it take?  Are you sure the team can handle it?  We need to know what the plan is!  What if it doesn’t work, what are our contingency plans?

All of these types of questions make for good discussion, and team and business should talk about them, don’t get me wrong.  The problem comes in when these types of questions stifle exploration and creativity.  We have a whole team of highly skilled developers just waiting to tackle this problem, and we’re holding them up by only talking about it!

The team decided to dig in and do some investigation while the business was still talking through their questions.   Soon we had something to show, something to demo, and something to have a real conversation about: working software.  This is the game changer.  It’s much easier to have a conversation about all the risks and concerns of the business when talking over working software. 

Too often we try to centralize decisions and get buy-in up front.  When in fact, the best way to develop a complex product in a complex environment is to distribute decision making authority to the lower responsible level – in the case of product development with Scrum, this is the Scrum team.  Trust your team, give them freedom to explore and learn.  Always trust that the smart people you’ve hired to build your product can do just that – build a product.

 ”Intelligent control appears as uncontrol or freedom and for that reason it is genuinely intelligent control”
~Loazi, 600BC.