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

/ one.hundred.acorns / Leave a comment

This article is the third 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:

Event Storming

In the previous post you read how Impact Mapping gives you the goal to reach and what are your options to do so, now it’s time to get more into how the system works.

An Event Storming session will involve almost the same people as for an Impact Mapping’s one but the aim is quite different!

Event Storming is about to find out all the events that occur in the system -> the business processes.

As Alberto Brandolini says:

Ideally, one would like to have participants coming from two fields: people with questions and people with answers. They provide the perfect mix of curiosity and wisdom.

Domain experts, the business people, know the system by heart and their job here will be to answer to a lot of questions! Those questions will be asked by a mix of different people (including developers, team leaders, testers, …), bring the curious ones!

After an ES session, everyone should be able to share the same vision on how the system behaves and the icing on the cake: everyone should share the same language to describe this (see the Ubiquitous Language).

First of all, you’ll need to find a big wall that you’ll cover with plotter paper or electrostatic sheets in order to be able to put sticky notes and maybe draw some lines and write text. Get some markers and different colors sticky notes. Decide to focus on a particular part of the domain (unless this could last more than a day!) and start by asking this simple question to your domain experts: “What’s the most important event that should occur in the system?”. If you’re working for a company that sells things on the Internet, and that you’re focusing on the ordering process, the answer should sound like “Cart checked out” or something similar. Now that you have that specific event, act as a time machine and try to find out together with the domain experts, what happened before this one. Write every single event on sticky note and put them in the right order.

Follow Alberto’s advice: Here’s the dogmatic color coding for #eventstorming follow it or perish!  :-) (source)

eslegend

This first part of an ES session really focuses on outcomes. Here’s a simplified version of what you should have:

CustomerLoggedIn->ItemSelected->ShoppingCartValidated->DeliveryAdressConfirmed->PaymentAccepted->CartCheckedOut

Now that you know everything that happens before a cart is completely checked out you can focus on the causality: the corresponding commands that lead to those events. Put another color – blue if you don’t want to perish ;-) – sticky note on every events and write the command name (you can also draw the actor that fires the command – User/Job/Time/…). Here’s another simplified version of what you should have:

LogCustomerIn->SelelectItem->ValidateShoppingCart->ConfirmDeliveryAddress->ValidatePayment->ConfirmOrder

Look what we have here? The method names of the not yet written application code! How could you be more close to business people if even your code speaks business? ;-) That’s the point where your code really brings business value!

And where the magic happens is when the QA tester can even start to write BDD styled tests during the ES session:

Given a Customer Logged In
When he Selects an Item
Then the Item should be selected in the Cart

I must admit this is a too simplistic example but you get the point, right?

At the end of an ES session every people involved knows exactly how the system works and behaves, what are the events that should occur and their corresponding command (and actor). You should be able to point out potential conflicts or missing concepts but new opportunities as well! Last but not least, everyone shares the same language and did speak together!

Mission accomplished!

Bonus: If you’re into DDD, Event Storming can even bring more than that as you’ll be able to find out the Bounded Context and Aggregate Roots of your system.

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

Embrace ravines and get out of your comfort zone!

/ one.hundred.acorns / Leave a comment

I recently finished the book “Notes to a Software Team Leader: Growing Self Organizing Teams” by Roy Osherove.

This book has been advised by Simon Brown during his “Agility and the essence of software architecture” ‘s talk at the Craft Conference in Budapest (you can find an abridged feedback here).

Simon was referring to this book as it contains useful recipes and tips on how to move from the survival to the self organizing team phase and what kind of leadership style you need to adapt during this multi steps process. The final goal being having a team that did learn how to learn and which is mature enough to bring software architecture back to its developers.

Even if all this was very interesting, what was really inspiring for me in Roy’s book, was something I did not expect to find in it. It took me by surprise ;-)

Throughout the book, Roy speaks about the comfort zone. That zone where we are taking no risk, avoiding the changes. That zone we don’t want to go out because we have fear of the unknown.  The fact is that we’ll never grow that much staying there…

In the Learning to learn chapter, Roy wrote something that really striked home:

I think the true power of learning is to realize this simple fact: ravines eventually end and you are left with new knowledge. If you know this, you can start doing something incredible: you can begin plotting out future ravines that you might choose to fall into. You can plan your life as a series of learnings through ravines that you have carefully calculated to benefit you.

Climbing those ravines might hurt a bit but I’m quite sure that what you’ll see when you’ll look back where you were before, is worth the look!

Read that book and go where the magic happens!  :-)

where-the-magic-happens

Thanks Houssam for the picture!

#CraftConf – Abridged feedbacks

/ one.hundred.acorns / Leave a comment

You might ask, why did I stop writing feedbacks on Craft Conference sessions?

It’s just because I post them on my company’s blog! :-)

Here there are: Abridged feedbacks.

By the way, as a foreign Craft Conference ticket winner, the guys at Prezi (one of the organizer company) asked me if I was ok to do an interview with them. The fact is that it changed a bit and it moved to I had to film myself during the conference.

It was real fun and here’s the result:


Broadcast live streaming video on Ustream

The Ubiquitous Language

/ one.hundred.acorns / Leave a comment

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!

 

#CraftConf – Jonas Bonér – Go Reactive!

/ one.hundred.acorns / Leave a comment

Jonas is CTO of TypeSafe a company that provides a Reactive Platform which helps to deliver responsive, resilient and event-driven applications. Typesafe spearheaded the Reactive Manifesto which defines a common vocabulary for reactive applications.

Unsurprisingly, Jonas presentation was about why and how to build a reactive application!

We’re entering a new era. When building an application we now often have to deal with mobile devices, cloud computing, distributed components. We need to build softwares that are real-time, responsive…

IMG_20140424_121241

As Jonas said, our applications now have to react to:

  • events -> being event-driven
  • load -> being scalable
  • failure -> being resilient
  • users -> being responsive

In one word, they need to be reactive!

First of all, we need to go async! (see Amdahl’s law). We do need to avoid blocking processes (which kills scalability). An event-driven system makes use of asynchronous message passing which gives lower latency, better throughput and bring more loosely coupled components.

Our applications need to be scalable, meaning being able to be expanded on demand. Better scalability comes with systems that are built of isolated components that share nothing with loose coupling and that communicate asynchronously. We need to minimize contention and maximize locality of reference. One thing that need to be kept in mind while dealing with distributed computing is the 8 fallacies of Peter Deutsch: the network is inherently unreliable!

We also need to build resilient systems that are capable of recovering quickly in case of problems. We need to avoid defensive programming where errors are mixed with business logic and disseminated everywhere in the code. Our clients should only deal with validation errors, not with applications’ ones. Our services should be built both with a dedicated supervisor which role would be to handle things in case of issues. It should be up to the supervisor to decide what to do (kill, suspend, resume, …) and so business logic and error handling are decoupled!

Last but not least: responsiveness! We need to keep the latency consistent. We need to make asynchronous and non blocking requests and responses and switch from pull to push so that our UI’s are interactive and always synchronized!

Reactive

Links:

#CraftConf – Gojko Adzic – Flexible scope

/ one.hundred.acorns / Leave a comment

First of all, I’m a big fan of Gojko’s work. I’m constantly trying to contaminate people around me and ask them to read Impact Mapping which I think might be a super duper solution to lesser the gap between IT and business people (and this is just one advantage amongst others! Just read it :-) ).

This presentation was not (only) about Impact Mapping, though, but more on how to write better User Stories. Gojko showed us how by spending 10 minutes more on writing user stories, they could be 10.000 times better  :-)

gojko2

The fact: our systems lack on flexibility. And that’s pretty strange, because this is always something people are searching for. Most of the time they’re even OK to pay more for flexibility (think about train of flight tickets that are much more expensive with some flexible options).

Systems are often built with a lack of flexibility and when their limits are reached people get into a crisis situation where the only possible option to keep the business alive is to Think & Redesign the whole system (and Measure if they’ve built it the right way this time!). But why wait for a crisis or chaos to do things the right way? Wouldn’t it be simpler to do it from the beginning? Make sense, uh? Jez Humble wrote about “Does Systemic Change Require a Crisis?” in his Lean Enterprise book. He quoted “The Corporate Culture Survival Guide” book by Edgar Schein. Pretty interesting.

Ok, so we should think about flexibility sooner. But keep in mind that trying to have a flexible scope is impossible without having a big picture of the goal to reach. User Stories are often disconnected from real business needs. Why? Because business people like to write what they would like to have on Power Point slides, not by saying things like “as a user I want this or that”.

gojko1

Tim Hartford wrote the Adapt book, where he tells us about the Palchinsky principles. As stated here: “Peter Palchinsky was born in 1875. He was a mining engineer who wished to take a more humanitarian approach to engineering […] He argued that Russian engineers did not approach problems in an “academic-dilettantish” way. Instead, they took on every problem as a purely technical one and assumed that if a solution incorporated the latest science, then it was the best solution”. Does this remember you something? Doesn’t it sound pretty familiar with what we’re experiencing today? Palchinsky said that linear plans never works because they do not consider Local, Time and Human dimensions. What would that mean? Well, did I tell you to read Impact Mapping yet? ;-)

So, how to take those dimensions into account? Think about:

  • Variation: search for ideas and try new things…
  • Survivability: …on a survivable scale, meaning where failure is survivable for your company….
  • Selection: … and get rid of those which do not work! (A/B test, monitoring, …), learn from your mistakes!

We somehow have to create a GPS for our apps! And as a GPS system would do, replan in case of problems! User Stories should somehow include the “excepted time for arrival” information!

How could we apply the 3 dimensions above in our User Stories? Here’s Gojko’s advice:

  • Variation: Plan to learn! US should not be commitments but options! We definitely need to change our mental perception of US.  Use what Tim Brown says in “Change by Design”: create options during what he calls a divergent phase and then make choices during the convergent phase.

divergentconvergent

© Tim Brown

  • Selection: Plan to discard mistakes: put a victory condition on your User Stories.
  • Survivability: Plan not to kill your company :-) Great User Stories are survivable experiments!

More links:

#CraftConf – BoÐil Stokke – Programming, Only Better – Keynote

/ one.hundred.acorns / Leave a comment

Bodil is a well-known conference speaker that works as a developer at Future Ad Labs, a London based company.

If you’re used to read her tweets, you should know that she has a pretty good sense of humor.  That one she tweeted about 2h before her keynote was quite funny:

bodil

…and gave the right tone before she talks :-)

What I have to say is that I was not disappointed. Some of her slides (My Littlle Pony, cats’ videos …) and the way she ran her presentation, were hilarious. She also piqued my curiosity: now I want to know more about Dijkstra!

Well, being funny is one thing, but more important, Bodil made also a pretty smart presentation.

bodil1

After spending some time describing computer history she ended up with this question:  Would processes or good project management bring great code? Is being Agile the answer? Well even with the picture of Bob Martin Showing The Way with Extreme Programming like Moses raising the 10 commandments, the answer is no! Simply because people are different! Some people love doing pair programming while shier ones would prefer being concentrated on TDD. Do code review everything would be a silver bullet? Sure no….

But wait, why is there so much bad code? Is that a matter of what language you’re using? No way! The reason is simple: complexity! There is too much complexity in our software. Would testing save us, then? Would it be the way to deal with complexity? Obviously not, it’s almost impossible to tests every case. You’ll always find a use case that is not covered by tests and thus subject to bugs. Bodil quoted Dijkstra, what he said about testing was one of my favorite: “Testing is hopelessly inadequate… it can be used very efficiently to show the presence of bugs but never to show their absence”

bodil2

The cause is that we’re trying to manage a code with way too much possible sates, our code deals with way too much mutable objects that can have their state changed by any kind of unexpected side effects behaviors.

So, what would help up? Are we doomed forever? Sure not ;-). First of all, have a look at “Out of the tar pit” paper by Ben Moseley & Peter Marks where they explain why complexity causes so much trouble in our software and what would be the right way to deal with it.

Well, it might be time to look at functional programming language or at least adapt a functional way of programming in our code! How? There are some good recipes, think about that one: if you think your object or any class member should be immutable, just put a sealed (or final) keyword in front of it! It will also help in a multithreaded environment where no lock will be needed anymore as share object can never change!

Nouhoum Traore said this one time: “functional programming style is a programming style that has style” :-) We can do nothing but agree!

Links:

#CraftConf – I was one of the lucky ones!

/ one.hundred.acorns / Leave a comment

It’s almost an impossible task to relate every single thing I’d like to, when trying to recap such an incredible conference.

The quality of the speakers and the talks were so great that the best solution would be for me to ask you to watch all the webcasts ;-) Ok; I know you might not do it, so I’ll try to summarize the best as I can.

First of all, I’d like to say that the place itself and the overall organization were perfect. Simply have a look at the tags every attendee received and you’ll understand!

tags

We had all the useful information in our hands: Wifi code, official twitter #hashtag, the schedule, conference map, city map, a little Hungarian language guide and even 4 free beers tickets for the party!

Oh, one last thing before telling you about the sessions: I was lucky enough to have a free entrance! Craft Conference organized a quiz on twitter, I participated and guess what? Yep, I won one of the 3 tickets!