This happened on a recent trip to Headwall Lakes where our car pooling group got delayed by one pair who were waiting at the wrong PetroCan gas station. However the good news is that on hikes, throughput capacity (hiking speed) is very visible and people use their common sense at elevating the constraints to maximize group velocity.

If someone is obviously a much slower hiker, then the group can elect to put them out in front to set the pace, or if time constrained, send them back with someone so that the rest of the party can continue at a faster pace. This is what happened on a recent hike over Yamnuska mountain, along with some less drastic optimizations of lightening the packs of a slower hiker to speed them up a bit.

 
While hiking this is all obvious, normal behaviour. On projects however, we might find it harder to go and help the BA, QA or developer, also perhaps we do not have the skills to help them. Yet even before that stage are you really sure where your bottlenecks are? Reducing the work in progress is the classic way to uncover bottlenecks in a process. Inventory in the form of large requirement documents or having lots of developed (but not acceptance tested) code, etc hides the constraints within the system. Lowering work in progress and switching to smaller batch sizes is like draining the water from a river, it reveals all the rocks and bottlenecks to progress since now downstream consumers are starved of work. Once these rocks are uncovered we can set about removing them.

While there is safety in numbers, sometimes you just want to go travel fast and light. Recently a friend and I did a great hike called Northover Ridge as a long day hike. Normally a 3 day backpacking trip we set off early (6:30am) and hiked the thing in one (14 hour) day. Above the treeline for 15km and traversing the Continental Divide for much of the way, the 35km trip was a blast. We passed a couple of parties doing the route as the normal 3 day backpacking trip, and their packs looked very big and heavy, yet had the weather changed they could have hunkered down in a tent and made warm food while we just had bivvy bags and some extra energy bars as our back-up so an extra night out would not have been much fun.

 
Agile teams mirror this speed/risk protection trade off also. A barely sufficient pack of processes is what you are ideally aiming for. If it is a short hike in a park then just a bottle of water might be all you need, if it is a hike in the mountains you should probably take bear spray, and some warm clothes too.

The trouble with blanket recommendations is that they are environment and ability agnostic. Most of the time you would be fine without extra warm clothes, but the impact of not having them when required could be high. Likewise, the effort of a 10km hike for me might be very different than one for you. A friend of mine, Carl Pryce, recently completed the Canadian Death Race as a solo competitor placing 5th overall. It is an insane 125km (78 miles) race with over 17,000 feet of elevation gain in extreme terrain and he ran the whole thing in 15 hours. Giving him a full pack for a 10km hike seems a bit redundant!

That’s the problem I have with generic process recommendations. Project conditions change from company to company and the ability of the team members is the biggest determinator; yet process suitability filters only consider experience rather than ability.

So what about team size and specialization? This last weekend I climbed Temple Mountain near Lake Louise with 5 friends. The approach is through known grizzly bear breeding areas and so the parks service require people travel in groups of 6 for protection. Actually this year they have relaxed it to groups of 4, but we had 5 and then picked up two other people who were looking for a group to join up with. I am not sure if there is a project equivalent of team size for bear protection. Perhaps enough critical mass to warrant taking over a board room for team space?

 
Anyway, we also had some team specialization going on. Mount Temple is more a scramble than a hike and a couple of the cliff bands sometimes trouble people scared of heights. Luckily we had two experience climbers in the group who had climbed it before. One brought a rope in case we needed to belay anyone and both helped find the easiest way up. Having these skills on the team reduced our risk exposure and provided a good level of contingency for unexpected events.

 
A couple of times we had to wait while everyone climbed a particular gully or notch.  Being a group of 7 this caused some minor delays (maybe 20 minutes in total) but in the scheme of the whole trip (9 hours return) this bottleneck was insignificant. Our individual speeds were very well matched and for once it never felt like we were waiting for people (perhaps I was the constraint!).

To me this shows that individual throughput rate (speed) matching is more important than parallelization or buffering. By ensuring the constraints are removed, individual events that interrupt flow are usually minimal and quickly overcome. (Last year an earthquake in Japan interrupted the flow of materials to Toyota that operate with minimal stocks of materials. As predicted the production lines ran out of materials and stopped, but the disruption was short and as a whole Toyota gains much more by having minimal inventory.)

Anyway, it was a great day, and felt like a high performing team, we had some specialists but they role was almost invisible. Quietly carrying much heavier packs (ropes are heavy to carry for 9 hours on top of all your other gear) and pointing the way we got their much quicker. The group dynamics worked really well and some of the slower members actually added the most to team morale with their wit and good nature.

Agile methods often recommend staffing teams with generalizing specialists who can wear many hats and help out in a number of roles. This is a valuable skill to help with throughput smoothing, but as Bernie Thompson writes specialists have their benefits too and rarely do blanket recommendations work universally.

I see lots of parallels between hiking and team work, I just need to find a way to bill for going hiking and then I will be truly happy!
Also, “Dear Agile Alliance, Please move the Agile Conference away from prime hiking season!”