Sunday, 18 September 2011
As engineers we like to speak in tickets and stories and bugs IDs etc - those units of currency we find easy to grok; they're usually finite, easy to define, narrowly scoped, and uniquely identifiable.
Our customers - for the most part - like to speak in outcomes and business plans and commercial objectives and projects. The longer term, more vague, abstracted-from-the-work things that we like to digest by breaking them down into those stories etc that we're so comfortable with.
This can lead to a weird situation where you have all your iterations scoped out and your releases forecast (with painstaking detail in every story) yet the business still lacks clarity about what's being delivered by who and when. Hmmm.
I think a bit of generalisation can help us to understand this. Lets appreciate that engineers, for the most part, are deeply practical people who are comfortable handling actionable tasks. Since we're also geeks - again for the most part - this descends quickly into technical details. You'd be surprised how unintelligible this can all be when you're not a developer.
What I've learned over the years is that stakeholders are interested in the meta problem, the commercial plans and outcomes, not the tangible problem, the technical tasks and code which need to come together to solve it. As technical leaders we need to talk about the meta problems with the business, and the technical problems with the engineers.
This comes with two obvious challenges - whenever we're talking about the same things but using different currency we rely on a degree of interpretation and some things can be lost in translation. This most commonly surfaces as that old "unclear requirements" thing. The other challenge is making sure that, as we solve our technical problems, we're solving our meta problems. This isn't easy and this is why great product managers are so crazy hard to find!
This kind of interpretation of work - the aggregation of agile units into bigger picture project plans - is usually an early casualty of agile adoptions. It is reminiscent of waterfall so we label it bad. But it is a helpful mechanism which bridges the gap between agile execution and regular business planning. It gives you both currencies.
Get awesome product people - they are the only other ones who live in this gap with you and have to speak both languages.
Monday, 12 September 2011
As a technology manager there is almost unlimited discourse you can read about how to successfully manage delivery and control projects. The real secret here is you don't manage projects, you manage the circumstances around a project...
This assumes that you have a team of talented engineers, a project manager as strong of character as he is on process, and an architecturally sound plan with some slack in your estimates. If you don't already have this then don't worry, you're not about to fail, you've already failed. What you're about to experience is you doing your best to mitigate the consequences of poor leadership. Good luck with that.
But let's just say that you've got the structure right - now what? If that's true, then the best contribution you can make as a leader is managing the environment around the project. Provide a vision and simple insight into what moves the dial for the business and then move the obstacles, keep the distractions away, make sure the priorities don't change, and protect the productivity of the team members. Keep the project fed and watered; get it the budget and skillsets it needs, get it the right visibility and attention from external teams who may be dependencies. You're usually on the hook for the whole thing, so the temptation to dive into the details is often overwhelming. Do it if you must but know that you probably aren't helping. Your guys won't feel trusted and you won't be encouraging them to take ownership of their own space. If you have a good plan on a sensible horizon, don't fiddle with it. Every time you do you increase the chances of things not working out.
That doesn't mean you should be disinterested or uninvolved - quite the opposite. Be there 100% for every engineer every day and give them everything they need to give you what you need. Be easily accessible and take on any potential problem, consequence-free, that your team feels like raising. They don't want to waste your time any more than you want to waste theirs, so if they come to you with something, it will usually be because there is a genuine risk that you're not going to get what you planned and there is something you can do to put things back on track.
I love technology. We all do. That's why we got into this business. I love what my guys do, and I love to talk to them about it, but I am always aware of when prudent interest in the organization's deliverables crosses the line and becomes micromanagement and interference.
The most important thing you can give to any project is certainty. Make a good plan based around people better than you are and then defend them.