I hear this a lot.

“We want to be smarter and more innovative, give the Dev team something to stir up their creative juices. Impossible though, we’re all too busy”.

It might be true, at least it might appear to be true. Interestingly it usually isn’t, it’s often about not being fully aware of what’s really going on. The question that I immediately ask is;

“What is everyone doing then?”

Of course, everyone’s working at full capacity slamming [well structured, top quality] lines of code into the product, to meet that scary release date, and simply haven’t got time to come up for air. Quite often these innovation crippling demands on our teams are seemingly too much to manage, typical approaches to the problem can be;

• Trawling through timesheet data to see where there’s any slack. “Right, it’s 15:30 on a Friday afternoon, you have 2 hours, get innovating”.
• Encouraging out of hours work for pet projects.
• Fitting in time between customer commitments, not wasting critical project hours.

A lot of these issues are down to visibility, and motivation of the team. Parkinson’s law suggests that “Work expands so as to fill the time available for it’s completion”, so sifting through potentially inaccurate, retrospectively populated timesheet data will not only be a waste of life, but a rather fruitless excercise. It won’t tell you anything that will help, it will just prove that you’re all scurrying around doing the stuff you should be doing, not want to be doing.

I have had the pleasure of leading several teams working with bleeding edge, exciting technologies, and in my opinion the only way innovation can truly emerge is when it’s treated as a first class citizen. Here’s how I’ve managed to get time to innovate with teams;

• Pull your development work out of electronic systems, cover your walls with who’s doing what so you all know whether something’s taking longer than it should. Basic agile stuff, visibility is essential when the “too busy” card is played. There is no other way!
• When an opportunity to innovate arises, grab the people who are most passionate about it and make it their thing, go off on a branch and spike it. Treat this like R&D, this is not production code. If it proves beneficial, awesome, job done. Otherwise, bin it.
• Time-box the activity, and make sure you factor this into planning. That way, ‘failing fast’ is the worst that can happen.

The last point (time-boxing) is critical, and one I’ve learned from bitter experience can have disastrous consequences in self-managing teams, going off on a branch of doom, never to return. Hugely damaging, kill it off quickly.

Once you embrace innovation you’ll find that the guys who join your team will have more fun than they’re used to, and whip through the mundane to be rewarded with something impressive for their CVs. In my experience, team members that work this way generate a buzz, and are quite happy to demo the spike and it’s benefits to the rest of the team, encouraging more innovation to emerge and productivity to increase. Recently a new addition to one of my teams, having been there for only a few months stated;

“This is the best team I’ve worked in, we meet aggressive delivery dates and still have time to implement cool stuff, I love it!”. Thank you Alan, cheque’s in the post ;o)

About Rich

Rich Lewis has worked in software delivery for 20 years. He first discovered Agile practices in 2004 and moved to Kanban in 2012. Rich knows how to balance productivity and fun, and is no stranger to leading teams through difficult challenges.

This post was originally published on Rich’s blog Small and Swift.