English | EN HOW TO TEACH INTEGRATION DEVELOPMENT TO MANAGEMENT WITH LEGOS
May 27, 2016
The old saying goes: “a chain is only as strong as its weakest link”. In that sense it’s rather strange that a lot of the IT projects I’ve witnessed have skirted around the combined integration testing between two teams.
Usually this becomes apparent when the product is being demoed for the first time. The teams show how the two systems connect with each other. Then it’s time for the questions. I’ve got a pre-selected bundle of questions that I ask:
- What happens if the system A tries to send information to system B but the system B is down? Is the message queued or is it lost?
- What happens if the system A is sending information to system B but the data connection breaks during the send? Is the entire message resent? Is there a possibility that some of the data has reached system B and for instance the message’s unique id number is already filled?
- Does system B send back any confirmation to system A? What if this confirmation is not sent? Will system A retry its message?
- Does the system A allow system B to change anything? Is the integration push or pull or does it work with queries?
These questions might seem obvious and the answers to them should be obvious as well. If the development team can answer them right away with good arguments, the situation is good. However if any of them are answered with a blank stare and “well…I don’t really know” then the situation is bad.
more–>
A lot can go wrong even if all the components of the system are tried and tested but the integration hasn’t been thought of. But who should think of these things? The team leaders, the architects, the product owners.
As so, I present you with a quick workshop for management to understand the importance of integration planning.
What do you need?
- Two boxes of Legos. They don’t necessarily _need_ to be Legos, they can also be Duplos or any other type of blocks.
- Either two rooms (one for the other team and one for the other) or a big room with corners for both teams
- A whiteboard and markers for requirements
- Some post-its and pencils
- A stopwatch (or an alarm clock)
- 4-8 people
- A couple of hours for doing and discussion
How to do the exercise
The first flight
Divide the group into two. Preferably put together people that don’t know each other yet as this depicts the development team that has been hand-picked by management.
Give a box of Legos to both teams.
Write on the whiteboard the assignment: let’s build a spaceship! Write requirements on the whiteboard. They can be eg.
- The spaceship must be able to carry 8 legopersons and a 5 cm x 5 cm x 5 cm Lego block.
- The spaceship must fit into a certain area drawn on a grid paper
- The spaceship must have 4 engines
- You have to be able to “fly” the ship by keeping it in one hand
You can think of other ones as well.
Now, send the other team into the other room and let the other one stay in the first room.
Go to the teams separately. Assign the front half of the spaceship for the other team and the back half to the other.
Give the teams 10 minutes to build their components and then bring them back into the first room. Let them then attach the two parts together in two minutes so that the spaceship can be flown by taking it into your hand and swooshing it around the space.
Chances are that the two minutes timespace is not enough for the teams to be able to connect the two parts together.
So there’s your lesson one: Communication. Dismantle the spaceship and go to the next phase.
The Waterfall phase
Wipe the whiteboard and make new requirements. They can be anything, just keep the “swoosh around the room with one hand” requirement.
After writing down the requirements let the two team plan their approach together for five minutes. Give them the pencils and post-its so they can agree on things. Then after five minutes divide the teams again.
Now go and throw a wrench in their works. Write down on post-its some specific requirements for both teams that the other team doesn’t know about.
The back half team could for instance get a requirement that the company doesn’t have a big enough hall to house anything that’s bigger than 10 x 10 on a grid paper.
The front half team could have a requirement that they need to incorporate the “government-approved control system” into their half that is a bulky and weird contraption of Legos you just happened to whip up.
Then after 10 minutes let the teams again try to connect the two pieces together. It might be a bit easier but the unspoken private requirements will probably create problems.
That’s the lesson number two: there are usually more stakeholders in the project than just the two
Dismantle the spaceship and go to the final phase.
The Agile phase
Once again wipe the whiteboard and rewrite the requirements, all except the “swoosh!” one. Let the teams discuss for two minutes and then send them to their own rooms. Give both again the unexpected private requirements.
This time let the teams use a “quick meeting” option. After three minutes they have the option to meet with each other for a minute, glance at each other’s product and make required changes to their plans. The development clock stops during the meetings, so the time is 3+1+3+1+4 = 10 minutes of “development” time and short meetings.
Now even though the teams have received their mystery requirements, they can tell these things to the other party and they can plan accordingly. Yes, one minute is a short time, it keeps the exercise hectic.
The importance of communicating everything to the other party in order to work for the final product should now be a bit clearer than before. Discuss how the exercise might have changed the viewpoint of the participants.
What else?
This exercise is something that has been rolling around in my head for quite a while now. I’ve never run it on any group but probably will in the near future. As such, the time constraints might be a bit off. If anyone is inspired and wants to run it, let me know how well the exercise went and what changes you would make to it. I would really appreciate it!
About the author