Dev & Business Teams - How have you successfully bridged the gap?

Question

I'd hope some healthy discussion will come out of this more so than a specific solution so I'll Community Wiki it as it is a fairly subjective topic. Appreciate if it can be left open as a helpful resource.

Recently I've taken over as Dev Manager with a small Technical Team.

The Business/Marketting/Design Teams out number the technical team by roughly 4:1 so as you can imagine there's a lot of work involved trying to insulate the technical team from the flurry of requirements.

To that end, we've put some proper processes in place, using SCRUM for project development, requiring business team members to fill out proper requirements documents, use cases etc...

In the coming weeks after our first major release we'll be introducing the business team to proper UAT process, issue reporting & change request processes & ourselves improving our issue triage and bug fix procedures. But as you can imagine it's a pretty steep learning curve and mindset change for all involved.

Just looking for some general feed back from the technical community (dev's, team leads & dev managers) who've experienced similar and how they approached any particular snag points.

Answer 1

A key issue is how to prioritise requests, every user wants their request done first. The solution is some sort of pricing mechanism. If your department is treated like an all you can eat buffet, they will want everything yesterday and there will be no limit to their requests. If on the other hand they need to submit a request and a price is assigned to it before work is begun they will think twice before making frivilous and trivial requests.

Answer 2

Here's the number 1 snag point.

My requirement is too important for your piddly-little hurdles and hoops. I can't be bothered to navigate your baffling "processes" and "documents". I just have a simple thing and I just need to tell a developer about it RIGHT NOW.

That snag point is almost impossible to avoid. Everyone knows that their requirements transcend process, engineering, discipline, governance and quality assurance.

The point of Agility is to allow this to happen in a controllable way.

Encourage the conversations. Let them vent. Create, update and prioritize the backlog aggressively.

By focusing on the backlog, you can -- to an extent -- circumvent the marketing guy running into a developer's cube to make an "emergency surgical fix" to production code RIGHT NOW. It's A CRISIS. EVERYBODY PANIC!

War Story.

We're bidding on re-engineering a quagmire of badly-done code. During a meeting with the users, a user wanted to know if the new application would allow immediate fixes.

I wanted to say "Hey dingbat! You're in the mess now because of immediate fixes!"

Instead I said, "consistent with best quality assurance practices, we'll make the changes as quickly as we can. We want to be responsive. But..."

Culture is hard to change.

Answer 3

First thing is do not ever make an exception and do something that hasn't been correctly submitted to the new system. They will never learn to use the new system unless you enforce it. Firmness especially at the start of a process is really needed. It is also amazing how many fewer requests there are once they actually have to do more work than just a phone call.

Second publish the priority list. If something needs to move up the priority list, a client (internal client in this case)can move it up over his own stuff only (and of course assuming it can be done if task A isn't done first). If he needs it to go to the top over someone else, he must get the agreement of all the other people whose work is ahead of his. It is not for you to do this but for him. This will cut way down on shifting of priorities. It will also save you time and argument. Each internal client can talk to you individually to set their own priorities, but you control the overall list. Once a developer has started a task, if at all possible (and for nothing short of a production problem taking down the system), make sure he finshes that task before moving to the next highest priority. Starting and stopping the same task repeatedly makes for code that takes longer to do and is in my experience more likely to be buggy.

You should retain the right to determine there is a genuine emergency that requires a shift in priorities. This should only happen if production is down and the system can't be used by many people (one person not being able to log in is not such an emergency unless it's the CEO of course!). In this case, make sure you tell the internal clients that their work is being delayed. Communication is the key.

Answer 4

I'm an engineer that's been on the business side for a while.

The key is allowing the commercial folks to engage with you OFTEN. Listen, ask questions, internalize the value of what' they're discussing. You want to make each person feel like you're their personal concierge to helping Shepard their requirements through the process.

Armed with this information you can work the agile development process more effectively - and your business teams will feel energized and confident in the process and feature pipeline development.