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

Advertisements

The Ubiquitous Language

Project Manager: -"Hey, I found a bug on that page"
Developer: -"mmm, where exactly?"
PM: -"There, the market is not displayed correctly"
Dev: -"The what? Oh, you mean the football match name?"
PM: -"Yes..."
Dev: -"I see, I'm gonna warn the tester"
Tester: [BUG2435 Status: Reported] The event name is not displayed correctly on homepage

Here’s the kind of familiar example you might hear every week. This short dialog illustrates one of the most common problems we experience in software development: people do not share the same vocabulary. In this brief example the different characters have used 3 different ways to name things. It’s easy to imagine that business people have their own way to name that too, and members within the same development team could have different naming as well!
This might not look like something really important here, but think about a more complex system that deals with concepts ways more complicated than a single football match. What would happen if people do not share the same vocabulary?

I had a colleague that had a 2 columns sticky note he uses as reminder where he wrote on the left side the word his team is used to use and on the right side the corresponding business term. Well, this might help but wouldn’t be easier to share one common way to name things?
The worse thing I saw was that brilliant developer. He was that guy in the corner. The less he was dealing with business people and the less he was bothered by someone else, the more he was happy. This guy was so away from the reality that he was inventing his own terms! This kind of behavior is extreme of course, but it illustrates quite well the problem. If people don’t share the same vocabulary, the code will be very hard to read and understand thus maintenance costs will increase… just for a matter of vocabulary.

I recently participated in an Event Storming workshop animated by Jef Claes & Tom Janssens at NCrafts conference. First aim of Event Storming is to talk with a domain expert and try to find out all the events that occurs in the system (Event Storming has many other benefits, but that’s a bit off-topic, have a look at Alberto Brandolini‘s  blog here to learn more). We wrote the first events just after a short description of the subject by the expert. Those events were looking like “Shop Keeper Registered” or “Shop Keeper Account Updated”. After having talked a little bit more with the domain expert, it appears that the “Shop Keeper” term was not correct. The expert was using the “Partner” term instead. What if this was real life and that developers were keeping on using “Shop Keeper” instead of “Partner”? Let’s imagine the developer that needs to fix a bug on the Partner Registration process: he will search for any “partner” occurrence in the code and this will produce no result! He will need to struggle a bit to find the right place to fix the bug and then, he might add “Shop Keeper” = “Partner” on his 2 columns reminder sticky note ;-)

How could your code bring value if it doesn’t speak business?

Uncle Bob said that names in code “are the most powerful tool that programmers have to communicate with each other” and that “developers should use names to Reveal Their Intent and Avoid Disinformation“. Makes pretty much sense!

People often neglect the need to share the same vocabulary, they simply do not care.
Won’t you think that it would be easier for every person involved in a project to share a common way to name things?
What if the same vocabulary would be use from the business requirements to the software code or even the test code? Wouldn’t it ease the communication and the understanding of every one involved?

People always complain about communication between business guys and developers. Start by speaking the same language!

The Ubiquitous Language is the term used by Eric Evans in his Domain Driven Design book. The idea is to build a common language shared by everyone involved. As Martin Fowler said: “the language needs to be rigorous, since software doesn’t cope well with ambiguity” :-)

There are several ways to build the Ubiquitous Language, model storming and event storming workshop are one of them. But the successful ingredients of Getting-The-Ubiquitous-Language recipe are always almost the same:

  • find out the domains experts
  • put them in a room
  • ask a couple of colleague to join (another developer, a tester, …)
  • ask as much as you can about one specific part of the domain
  • put everything on sticky notes
  • it should not take more than 30mim
  • repeat until you think you’re done!

You don’t have to know about DDD in order to start Event Storming workshops.

One of the nice side effects of Event Storming session is that the more you’ll go deeper in details, the more you’ll see different part of the system naturally appear. You will get a pretty good idea of what components you’ll have to build (DDD speaking you’ll find out Bounded Context and Aggregate Root).
You will also be able to define your GivenWhenThens. As sticky notes are chained as events that must occur to get from one state to the other, it’s kinda easy to write your BDD styled tests! And that’s where having a tester in the loop is becoming interesting! Sounds like we have our 3 amigos meeting here ;-)

Hope all this gave you some ideas about things to try on your side in order to let you and your code speak business!

There are obviously other pretty good techniques to bring business and dev people close to each other but enough for now, I’ll have surely the opportunity to talk about this later in another post!