Bridge the gap between dev team and business people! – Idea #2

This article is the second out of an unlimited series (let’s say at least 5!) where I’m gonna try to give you some ideas and easy things to put in place in order to bring your team closer to business people so that you can work collaboratively and efficiently with them.

Written so far:

Impact mapping

One of the worst things about specifications is that they are boringly linear. They just tell you what to do, from point A to point B, no alternative. Have you ever seen specifications with options in them? nah!

Smart as they are, business people are nonetheless error-prone. Well, to be honest I would not want to do their job. It would be impossible for me to know exactly how the future will be and write this into documents weeks before any project start. Even if I’m currently working for a betting company I’m not used to place bet on what should coming on!

Impact Mapping is no crystal ball, it won’t tell you the right path to follow to reach success, but it will give you options! Impact Mapping is like a real roadmap, not the kind of roadmap that gives you only one way to go from point A to point B (as specifications do) but the kind of real roadmap that will tell you what are your options based on the current traffic jam and potential road works ahead.

But who’s gonna find those options? Everybody!

First interesting thing Impact Mapping brings, is that every people involved will share the same goal! With the development team having the same goal to reach as business have, is a key success factor. Think about a military unit engaged on a mission without having the main goal in mind, what would happen if something comes up that specifications had not anticipated? –> Fail!

Sharing the same goal will help people to find out options on how to reach it and one of the best way I know to do it is to make an Impact Map.

As Gojko Adzic says:

An impact map is a visualisation of scope and  underlying assumptions, created collaboratively by senior technical and business people. It is a mind-map grown during a discussion facilitated by answering the following four questions: WHY? / WHO? / HOW? / WHAT?

The WHY? is obviously the goal I was talking about. The WHO? are the actors that can influence the outcome. The HOW? are the impacts, the options. And finally, the WHAT? are the deliverables, all the features that we might deliver.

Of course, everything should be measurable in order to be able to switch from one option to another if we see quickly that it won’t reach the goal. Like if your project management was switching from working with commitments on a linear plan to GPS navigation system that reacts to unexpected events!

Keep in mind that your options must be on a survivable scale, meaning that if it fails the project must stay alive! That’ why they must be measurable, achievable, realistic and timely!

When do you need to do Impact Map? Well, obviously before the project start so that you can define all the different goal-to-deliverable paths – the assumptions. But you should do Impact Map during the project as well to check if the chosen option is producing the expected impact!

When you do Impact Map, the first thing to focus on is the goal. If it’s too big or if it contains sub-goals, then cut it into milestones. Do not spend to much time on the What part, focus on the actors and impacts instead (and stay tuned for the next idea to come that will focus more on the What and how Business people could help there)

At the end, Business people will share their goal and everyone involved will think about the best ways to reach it. As Ron Jeffries said:

It shortens the communication lines between the people who want things and the people who do things.

Mission accomplished!

Advertisements

Bridge the gap between dev team and business people! – Idea #1

This article is the first out of an unlimited series (let’s say at least 5!) where I’m gonna try to give you some ideas and easy things to put in place in order to bring your team closer to business people so that you can work collaboratively and efficiently with them.

It’s no secret; one of the reasons why many projects fail is caused by the lack of communication and the weak relationship between business people and development teams. This often ends up with an application that do not look like what the stakeholders wanted at the beginning and it’s even truer if you work in an non-Agile environment (reinforced by the tunnel effect in traditional software development methodologies)

The main way, via which development team communicates with business, is through the holy specifications document.

But specifications, as holy as they are, suffer from one big problem. Theo Schlossnagle explained it during its “Responsibly maximizing craftsmanship in software engineering”‘s talk at the Craft Conference:

Specifications themselves are incredibly difficult to get right. […] Specifications are not written in computer language. They’re written in a horrible, horrible, language to describe something explicitly, and that would be… English! Or any other language that humans use to communicate. If you can write poetry and have two people feel different things when they read your poetry then it’s obviously not the right language to write specifications that are supposed to produce always the same output!

In addition to not being understood the same way by different people, they are often written weeks before the project starts and that obviously won’t help either…

As often, it will be up to the development teams to rolls up its sleeves and bring changes!

By the way if someone knows the reasons why business people are frequently reluctant to change, I’m interested to know. My two cents is that we’re moving faster wearing sneakers than formal shoes ;-)

Specifications seem not to be the magic recipe, so what else could we do?

Let’s discuss!

The first idea is the simplest to put in place. It might seem a pretty obvious one, but guess what? It rarely occurs! This idea came to me while reading the very inspiring “Notes to a Software Team Leader: Growing Self Organizing Teams” book by Roy Osherove:

One way to refuse stakeholder requests is by letting the requesting party realize for themselves that there are better ways to spend the team’s time. […] If your stakeholder wants feature X, bring them up to the walled task board with Post-it notes and say “OK, which feature do you want to move down in order to build this?” Ask them to take down a feature from the in-progress column or the to-do column. This usually leads to an interesting conversation with the stakeholder about what each task means and how much time it was estimated for. By the end of the conversation, either the stakeholder realizes where the task fits in or you will. Either way, what wins is the value generated for the company.

Easy! ;-) By simply asking the business girl/guy to come and discuss about priority, both parts will see things from each other’s perspective. This is a really simple technique but should really open your minds. Lead without being aggressive this should reduce frictions and tension pretty quickly! (and this will obviously work with any kind of backlog, you don’t need sticky notes!)

This is just one example, you should easily find other opportunities to discuss and exchange with business, collaboration is the key here.

This first idea is quite easy and straightforward to put in place, stay tuned for a few others to come, that might require more energy :-)