Hatching an Egg — A story about Cross Functional Teams and Agility

Randy Keyers

Working Agile and Cross functional teams are commonly used in correlation with each other. Working Agile has to do with focusing on Customer (and thus Business) value, transparency, continuous improvement and adapting to change.

There are a lot of theories on what a cross functional team is. Is a cross functional team a team where all team members are able to pick up any task for the team? Or is a cross functional team a team that has every discipline represented to complete the task or mission they are assigned for? If you would go even deeper you could argue on what a team is? Is a team the group of people that works fulltime together or is a team a group of people that share the responsibility to work on a certain solution, which might even have sub teams?

This story is not about that discussion, but it is about why it is worth considering to de-silo and work with teams that can have a shared responsibility for the end-to-end solution to foster the ability of working truly Agile.

What is seen regularly

What I see in- and hear about a lot of organizations is that a solution or project is executed in silos, and sometimes looks more like a waterfall process, executed in two-week sprints:

First a lot of time is spent on preparation of the project: The project and requirements are thought out by the business (analysts and architects) upfront. The why, the how and as many as possible edge cases and details. The requirements and architecture are defined completely before they are handed over to the teams. Because the business tries to get a clear fixed scope, so they can determine upfront how long the project will take.

If the requirements are incomplete, the teams will hand the work back to the business asking for additional requirements, or deliver something that is not completely valid. And that will cause the project to run over time and over budget.

Next to that, multiple technologies and systems are involved, which means that multiple specialized teams work on their part of the solution and are dependent on other teams who are responsible for their part of the solution. If a team stumbles upon (technical) difficulties, or an incoming missile where they need to temporarily focus on something else, other teams down the line are delayed as well. This also has a negative impact on the project’s time and budget.

Hatching an egg

If you would compare this to the production of little chicks, it would look like this:

We have a number of groups of chickens. Some of them are responsible to lay all the eggs. Let’s call them the Layers. Other groups of chickens are responsible for part of the hatching process. Let’s call them the Hatchers.

So, in the previous example, the Layers would try to lay all possible eggs they can think of for the project upfront. Then they would try to estimate how much time it would take to hatch all these eggs. After that, you are ready to start hatching.

Now a big increment planning is organized where hatching teams get together to decide on how many eggs they can sit in the upcoming period, in sprints of 2 weeks, and which team has to sit on certain eggs first before the next team can sit on the egg.

During the hatching some eggs appear to be sheer-eggs and some have been laying around too long and have gone bad over time. So, the Hatchers hand these eggs over to the Layers and request them to lay new eggs. Causing delay.

Besides that, every now and then, although the Layers have done their outmost best to lay all the eggs upfront, a new unforeseen (but really necessary) egg is laid and added to the basket to hatch. And then there is the Cuckoo, every now and then putting some -top priority for the board- eggs between the project eggs for the hatchers to hatch.

Unfortunately, some eggs take longer to hatch than expected. Maybe some of the Hatchers caught the chicken-flu, or the shell of the egg was thicker than anticipated on.

And so, it happens that these disturbances cause a team of hatchers is still sitting on the egg while, according to planning, it was the next team’s turn to sit on the egg. This team picks other eggs to sit on, while they wait. Unfortunately, they are still sitting on these alternative eggs, when the eggs they should be sitting on are finally handed over to them by the previous team, causing further delay for the teams down the line and cooling down those eggs.

The Hatching project is running out, so a few Leader Chickens are urging the Hatchers to hatch harder and the Layers to lay faster. Unfortunately, without the desired result.

But then eventually the final stage of hatching is reached, the shell cracks and the little chicks come out of their eggs.

Now this raises next question: Who are the parents of these chicks? Who is responsible for the end result? Who are going to raise them and look after them?

The Hatchers say: “we have only hatched the eggs for our part, so we can’t be responsible”. The Layers say “we only laid the eggs, so we can’t be held responsible”.

Scrum Teams that work in silo’s

Cross functional teams

Now what would happen if the Hatchers and Layers, each with their own knowledge field would engage in laying and hatching the egg together within a single cross-functional team? Teams where everything needed to lay and hatch the egg together is represented and everybody is continuously involved in the process of reaching the business goal.

This vision and mission, and the most important information is thought about upfront. Then the cross-functional teams work towards that goal, while having feedback and progress/planning moments on a regular bases.

Some Layers or Hatchers may be needed more than others, because of that some may be participating in more teams, but these teams care about the overall process and thus can take responsibility for this process.

At first it might look like the process of involving Hatchers in the Laying process and vice versa would take more time, but actually it is the other way around.

Teams who understand their combined value and continuously improve their ways on producing a steady stream of great little chicks.

Little chicks will come out pretty early in the process, because hatching already starts after the first few eggs are laid, and the laying continues while other eggs are being hatched. There will be less overhead afterwards, because the overhead of sheer-eggs, eggs that have gone bad over time and dependencies on other teams is greatly reduced.

Besides that, the quality of the produced chicks can be checked way earlier so adjustments to produce better chicks can be made early in the process.

The little chicks produced by these teams will have great parents, who have everything needed to raise it in the best way.

Cross-functional teams (Business & IT) working end-to-end

The evolution

Thankfully an evolution towards this way of working can be seen already in more and more places. Although it is not always be easy to make this evolution.

If Layers are used to only lay the eggs for the past years, and they are involved in the hatching process, which at first might be none of their business, that really takes some time to get used to.

For the Hatchers, who were only hatching eggs provided to them for the past years, to start being involved in the process of laying the egg, that will surely hurt at first…

And then there are the Leader Chickens, who are shifting from urging chickens to lay faster or to hatch harder, into helping the Layers and Hatchers through this evolution and facilitating the them in good parenting.

Randy Keyers

Written by

Agile enthusiast, trainer, coach and mentor with over 15 years of experience. Helping organisations with their Agile growth.

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade