Cloud + IoT + Devices + Mixed Reality

Conversations about Forming an Agile Team: Part I

I had a really interesting conversation with a customer in Shanghai. In terms of taking on an agile transformation, let’s just say that they’re on the edge. They know what they are doing now isn’t making them competitive in the marketplace but they are concerned. They’re concerned about how things will change. Will they be able to incentivize the right behaviors and disincentivize the wrong behaviors? Basically, the age old ‘carrot and the stick’ dilemma.

Like my other customer they are building what I call Cyber-Physical Systems. Basically, a mash of software, firmware, and hardware. Soup to nuts. They are a rather small operation. They have about eight (8) hardware/firmware engineers. They are currently building four peripherals that attach to another vendor’s device and augment it in someway. That’s about all I can give you about their use case (without killing you).

They are currently structured in such a way that their eight (8) people are divided into four (4) teams of two (2) people. That is some nice clean math right there. Each team has a project manager that tracks their progress.

The work, naturally, requires a certain level of specificity—in that, certain members of their team can only work within a certain technical domain. These technical domains are usually isolated by the peripheral in question. In short, the peripherals are composed of a unique combination of hardware components that require specialized skillsets to master their development both from a hardware and firmware stand point.

Imagine if you were a peripheral manufacturer for the iPhone and you had a whole bunch of different peripherals that you marketed to iPhone owners. You had a credit card swiping machine, you had a bar code scanning machine, you had a smart card reader machine, etc. It takes specialized knowledge to know how to build a credit card swiper vs. a smart card reader, right? Totally makes sense.

I asked three questions:

1. How concerned are you about (voluntary) attrition?

2. What percentage of the work is relatively similar in nature?

3. How much latency is there today?

The answers I got were:

1. A lot. We don’t really cross train our people so if our smart card reader gets hit by a bus we are in deep trouble.

2. It’s mostly the same. Firmware development. Same language, same development environment. There is a lot of plumbing that works pretty much the same way. It’s just there are highly specialized components based on hardware that require specialized skills.

3. Lots. Hardware fabrication takes time so the teams will find themselves waiting for hardware to test against on a regular basis.

I then asked a radical question:

What would happen if you had one team that worked on four peripherals?

The answer?

Most of their technical skills are shared but each just has their own specialization in a particular peripheral (and in some cases peripherals). They could all work on the the parts of the peripheral that they could given their skillset.

And when in doubt they could pair up with that subject matter expert to start to get up to speed in technical domains they had limited exposure to. In short, cross training would start to happen because work wouldn’t be siloed by a particular peripheral. Ok, so maybe we wouldn’t all of sudden turn the bar code scanner guy into the smart card reader guy but they would get a lot more knowledgeable about how each of their peripherals worked and gradually transform from ‘I’-shaped people into ‘T’-shaped people.

We’d also be able to tolerate that latency a bit better and while we probably couldn’t eliminate wait time we could drastically reduce it. Instead of waiting on the hardware fabrication process we could swarm on the next highest priority item.

But wait, how will we be able to measure their performance? Ah-ha. That one we will save for Part II.