Hey! Trust Your Engineers

0

The Agile process was developed by engineers, for engineers.  But at many of the companies I consult at, the process has been hijacked by management.  Rather than being a tool to minimize context switching on engineers, it is a tool to beat them into productivity – which never works.

Horror Story

Company A’s product management department converted the adjective ‘agile’ into a club.  “Hey, Steve you said your team is agile.  Then why can’t you add my change in 2 days!?” It took a while, but eventually they understood we could deliver on time.  We can’t deliver in 2 days, but we can deliver on sprint intervals.

What the product managers failed to realize is that Agile is a process, not just an adjective.  They didn’t trust engineers to deliver on their commitments.  I don’t blame them.  Prior to my arrival the deliveries were inconsistent at best.

Agile is actually the solution to this problem and does work, but engineering needs to earn that trust.  Once they do, all the corporate dynamics change and life becomes better for everyone.  I’ve turned around this perception before and there is a definite pattern to follow.

First, get ready for conflict

Your agile cycle defines when you can and cannot accept changes.  If this is a 2 week cycle, then engineers will not see any priority or functionality changes for 2 solid weeks.  That means those pesky product managers are going to go nuts.  Get ready for it.  Until you begin to deliver on schedule, they have every right to mistrust you.

Second, don’t over commit

Contrary to what product management thinks, engineers enjoy delivering product.  Because of this desire, we commit to more than we can do.  As a team-lead or manager, don’t bite off more than your team can chew.

“Under commit, over-deliver” is a great axiom.  However, I’d like to suggest you do something a little different: “Under commit, deliver early.”  If you finish your stories, seal up the branch and send it off.  Better still, if you finish early clean up some of those priority 3 bugs you’ve been wanting to clear up.

Third, they won’t believe you

I’ve experienced this more than once.  After a long period of screwing up delivery dates (doesn’t matter who’s to blame), product managers will think your first few successes are a statistical anomaly.  Oh well.  Just let the little comments roll off your back.  You have more important things to think about.

Finally, be prepared for praise

After you deliver 3 or 4 sprints with all the content intact they praise will flow.  Not only that, but everyone starts to relax.

I was amazed the first time I went thru this.  Managers that gave me the most grief, became the most pliable.

“Hey Steve, when can you get this priority change in?”

“Let’s see … we are mid-sprint right now.  I’ll move it to the top of the backlog, you can deliver to the customer in 3 weeks.”

“Great, thanks.  I’ll let them know.”

You see, most of the time product managers want to know ‘when’ and they can work with that.  But if your sprint commits are a mess then everything becomes a panic.  They believe that if they don’t press for NOW, it will never happen.

It’s up to you, engineering manager, to break the cycle.  Trust will follow trustworthiness.

 

 

Share.

About Author

Steve Sando

Steve works with successful software startups and tech companies throughout Silicon Valley. Most recently he has been developing content migration tools for large websites. He has a deep passion for all things software engineering, from design concepts, to team management, to final delivery.

Leave A Reply