Designing a Delivery in a Distributed Environment
Several years ago I was coaching a project developing a large system consisting
of electronics, mechanics, firmware and software, with development teams in
several countries. The main development team was in the Netherlands and the
team in Belgium kept delivering late and unreliable results, causing trouble
to the regular deliveries to stakeholders. Therefore I was sent to the Belgian
team to teach them Evolutionary Planning, so that they would learn to promise
what they would deliver and then deliver as promised.
One Wednesday we started designing the next delivery and this is what we
figure 1: TimeLine for this
- Draw a TimeLine
We started by drawing the TimeLine for this DeliveryCycle. On a TimeLine
we put ticks on the line for days and weeks, depending on the scale. Weeks
for several deliveries. Days to detail actual work. In this case we put
ticks for the days of the TaskCycle we were planning.
- Mark the project Deliveries
We added the project Delivery, in this project Friday 11:00.
- Mark our own Deliveries
This was a TaskCycle for us as a sub-team, delivering
a Result to the main-team for integration into the project Delivery. We
decided that we should deliver by the end of Tuesday, so that our result
would be available to the main-team on Wednesday morning. This way, the
main-team could integrate and check the proper working and we would have
time to ease any hiccups if they would be there.
This meant that the TaskCycles for the sub-team would start Wednesday mornings.
As it happened, it was Wednesday morning.
- Determine the available time
We decided the gross available time for the team this week to be 36 hr rather
than 40 hr, because we were spending some time on learning that Wednesday
morning. If people work full time, this means 24 hr plannable time (remember:
default we plan 2/3 of the gross available time, see "Weekly Planning").
- Determining what to do and what not to do
We checked the Tasks already prepared by Serge and Gregory. Serge was Project
Lead for 4 more people in his sub-team, so he needed to plan time (figure
2) for Management by Walking Around (MbWA), and for preparing for the next
week for the team. The remainder of the time he planned for his share of
the development work. Project Management easily deteriorates when the PM
is also working. Rule: First manage. If you still have time left: manage
better. If you really have time left, you may do some work. In order to
get the Delivery on time Serge still had to do a lot of work himself, knowing
that he'd have to catch up on management the next week. But adding up his
estimates (they already had learnt to realistically estimate quite well)
showed exactly 24 hr, so his planning was done quickly.
- Weeding out unnecessary things
Then Gregory came in. He had planned 42 hours of "necessary" work (figure
3). This didn't fit the 24 hr, so even if he'd try, we now already knew
that he wouldn't succeed and the Delivery would fail. Failure isn't an
option, so we still had to do something about this. First we found out
that the first two Tasks in Gregory's list ("Draft design" and "Finish design")
were not for this Delivery and that the information to do the design wasn't
even sufficiently available from the main-team. So we moved these Tasks
to the future. We changed the time for these Design Tasks to 0, because
he didn't even know what he would have to do.
- Until you know you will succeed
Now we were at 30 hr (figure 4). Still 6 hours to move. The past week, Gregory
had been struggling with XML, actually spending more time on it than he liked.
Jerome knew XML better and had some time to spare. We called in Jerome
and decided to move the two XML tasks to Jerome. Because Jerome would be
quicker with XML, he said he'd need 3 hr per Task to do the work. This didn't
relieve Gregory completely from these Tasks, because he would have to explain
the Tasks to Jerome and integrate Jerome's result in his own result. So
Gregory planned 1 hr each for both Tasks, instead of the original 4 hr each.
Now he had 24 planned hr and he accepted the responsibility to deliver (figure
One week later, Serge and Gregory delivered. No stress. They even had a few
hours left to implement something extra that they decided was actually forgotten
in the design. On the Friday, Serge went to the Dutch team to be present at
the Delivery to the Stakeholders. I was there to see whether he would really
cause a smile on the Stakeholders' faces. He did. Everything simply worked
Can you imagine what would had happened if we wouldn't had designed this
For those people who like the "Lean" concepts:
Value Stream Mapping is used to find the wasted time in repeated activities:
we can see where we usually waste time and redesign the process to prevent the
waste. In development, there are many repeated activities where we can cut waste
using Value Stream Mapping, but there are also a lot of non-repeated, one-off
activities, where we only can prevent the waste by preventing to spend the time.
Preventing to spend the time we can only do by foreseeing that we are
going to do things we shouldn't do (or shouldn't do now). See the page