communication

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

/ one.hundred.acorns / Leave a comment

This article is the fourth 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.

Written so far:

Value Stream Mapping

First time I discovered Value Stream Mapping was when reading the very interesting “Lean Enterprise” book by Joanne Molesky, Barry O’Reilly and Jez Humble. The final version of the book will be released in December but the early release version is available for download at a lower price since a few months now.

A Value Stream Mapping is a method from lean-management that allows you to quickly visualize the flow of value delivered from the genesis of a project until the customer delivery. It has originated from manufacturing but it can easily be applied on software development as explained in “Lean Enterprise“.

The exercise is pretty straightforward, you just have to write down all the stages that are necessary to bring an idea to its delivery and write under each steps the Lead Time (LT) and Value Added Time (VA). The Lead Time is the elapsed time needed to arrive from a stage to another and the Value Added Time is the amount of time really spent on that step where value has been added (the real work)

When working with huge companies where there are a lot of processes and departments, the exercise might take some time to accomplish as you’d need to meet people from all the different department involved in order to collect all the data. For us it was quite easier as it took us only one and a half hour to end-up with this:

vsmBlog(Pink post-it notes represent process stages, LT and VA are written under each)

First thing to do is to select a recent representative project (the kind of project your company is used to do in terms of size, people involved …) and obviously one that has been released to the customer! Invite enough people to be able to determine all the steps and find out corresponding LT and VA. We were only 3 to perform the Value Stream Mapping (a Business Analyst, the Head of Development and myself). As soon as all the steps have been found out, we used time tracking and reporting tools to get the exact amount of time spent on each steps (the VA) and when exactly those started. Some of the steps might be done in parallel and iteratively, that’s why some sticky notes are under other ones (in that case the corresponding VA is the sum of the whole column).

As soon as you have written down everything, just sum up all the VA’s and LT’s (some conversion might be needed here as some figures might be in days and other in weeks or months) and divide the total VA by the total LT to find out the Value Stream efficiency rate. The lower it is, the bigger is the chance to easily find some process improvement ideas!

The very interesting part starts at the end of the exercise! Well, you know, everyone might have in mind where usually things are stuck and where you might need some improvement to speed the value flow. But having the Value Stream in front of you clearly helps to focus.

The Value Stream is the perfect medium to start collaborating. Invite a couple of key people to join (from development and business side) and talk together in order to find out what could be improved in order to speed up the flow of value delivered and avoid wasting precious time. List out all the ideas and try them! Redo the exercise later on and check if the efficiency rate increased!

You will get a better understanding between all the stakeholders of how work moves through the company. People from different departments and having different point of views join together and collaborate to improve the whole company’s efficiency.

Mission accomplished!

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

/ one.hundred.acorns / Leave a comment

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!

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

/ one.hundred.acorns / Leave a comment

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 :-)