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. I was sent to the Belgian team to help them using 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 did:

figure 1: TimeLine for this Delivery

  1. 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.
  2. Mark the project Deliveries
    We added the project Delivery, in this project Friday 11:00.
  3. 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.
  4. 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").
  5. 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 this 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.
  6. 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. He changed the time for these Design Tasks to 0, because he didn't even know what he would have to do.
  7. 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 they 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 5).
One week later, Serge and Gregory delivered. No stress. They said 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 delivery?

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 about preflection.