Everything you need to know about this transformative approach to software development.
You are in a tight spot. You told the board that you’d get 3 product initiatives done this quarter, and with a month left it looks like you may go 0 for 3. Your product team is burned out by an avalanche of noise and is in hair-on-fire mode. Your tech team is frustrated and looking for the exit. Your CRO is screaming for features he asked for last year and sold 6 months ago. Your designers are redoing the style guide for the 10th time because it’s the only thing they can do by themselves. You have a roadmap, but no idea if it will ever happen or whether it will solve your business problems.
Clearly something is wrong with your product and delivery process. But how do you fix it?
When I talk to teams like these, it feels like all is lost. They’ve got big ideas — there’s work queued up for months (and revenue tied to it), but they can’t seem to give birth to anything. They’ve usually invested in Agile but gave up or scaled back on it because it didn’t feel efficient enough, so they’ve reverted to Gantt charts in the hopes of pushing code out the door. They have strong people but can’t or won’t empower them to make tough decisions, which makes everyone feel weak. But the heart of the problem is that your team can’t operate effectively because they don’t trust each other, and goals aren’t being realistically set or met.
Trust is the backbone of good product development, and once it has been lost, it’s tough to earn back. But it can be done!
The road to recovery looks like this:
Rhythm. Focus. Vision.
When things have gotten bad enough to need a reset, it can be tempting to call an offsite and rededicate yourselves to the vision of the founders, or the CEO, or the company’s mission statement. In my opinion that is the worst thing you can do. A team in a pickle like this needs a win, and better yet a string of wins that light the way. Getting into a rhythm of delivering small wins is the best way I know to pull a frustrated team off the ledge.
It doesn’t really matter if the small wins are addressing your most important business problems, although it’s nice if they do — the ideal backlog is a string of little things which have value on their own and add up to a much more valuable big picture. But in the short term, all you need to do is remove impediments — by proving that they can do these small things and work well together, you will show your team that they can accomplish anything.
Celebrate the wins as they pile up. Make your backlog a mix of tech debt payments, new features, and design experiments, so you can spread a little joy to developers, designers and customers. Make a big deal of your sprint demos (food always helps), and ensure the whole company knows your sprint rhythms — what days they happen, when devs are most likely to be holed up in conference rooms with fingers or cards in the air, etc.
Build a track record of delivery — publish your burndown charts and talk up positive trends in velocity as the team acclimates. You should also introduce your teams to real, live customers -- nothing gets devs and UXers excited like a direct connection to the people using the product. Make sure that product, tech and UX have the space to find their optimal way to work together, and that the business understands why they need that space. Even more, a happy, productive team radiating good energy will rub off on their stakeholders.
Notice that I am not claiming you’re building the “right things” at this point. Hopefully some of them are the right things, because you’re borrowing from your existing backlog, but don’t stress about that. Building only the right things comes later.
Interested in more ways to help your team succeed? For Agile teams, leveraging your sprint retrospective is a great place to start. Our free eBook shows you how to properly facilitate these meetings to get results. Download it today by clicking here.
Agile development isn’t just a series of principles or procedures: it’s a mindset that every team must foster in their...
Posted February 12, 2016
By Dan Mason
Posted February 12, 2016