Teams: White space and slack

---

One of the big differences between a team and a group is cohesiveness around the goal:

There's no success individually unless there is success collectively

Don't let idle ruin cohesiveness

Inevitably, keeping the team together to promote cohesiveness raises the question: 

How to keep everyone busy all the time -- other than 'painting rocks' (which is the way the Army used to do it)?

In theory it's simple: keeping everyone productively busy means actively managing their downtime, aka the 'white space', between and amongst their planned activities.

White space and the matrix

In organizations that are aggressively matrix managed, one approach to 'white space' management is to reassign people to another project with the intention of just a short assignment to 'keep them off the overhead' and always on 'billable hours'.  Of course, such practice breaks up the team for a short time so it kind of flies in the face of cohesiveness, team accomplishment, and team metrics.

And, aggressive matrix management assumes the F.W. Taylor model of management science: jobs can be filled by anyone qualified for the job description... interchangeable parts, as it were. In the era of team work where teams recruit their members, Taylorism is an anathema. Thus, aggressive matrix management is likewise seen as anti-team.

Backlog and whitespace

That all brings us to another approach -- more popular these days -- which is: manage the white space by managing the team backlog.

• Make sure that the backlog has all the technical debt and low priority requirements present and accounted for so that they can be fit to the white space opportunity.
• Develop and maintain a "parking lot" for off-baseline opportunities that might fit in the white space
• So also bring in mock testing, special event prototyping, and, of course, that bane of all:
• Maintenance of team records.

Running cost of teams

One big advantage of managing by teams: the cost is relatively fixed. Each team has a running cost, and so the total cost closely approximates the sum of the number of teams x the running cost of each. 

Of course, many PMs are NOT comfortable with the project staff being a fixed cost. They would much rather have more granular control. I get it, but the here's the main point about cost:

The cost of a project is not its value; in a "good project", value as judged by users and customers greatly exceeds cost

Here's the memo: Manage for value! (Oh!, did I say I wrote the book?)

---

Like this blog? You'll like my books also! Buy them at any online book retailer!

Teamwork: managing the whitespace

---

One of the big differences between a team and a group is cohesiveness around the goal:

There's no success individually unless there is success collectively

Don't let idle ruin cohesiveness

Inevitably, keeping the team together to promote cohesiveness raises the question: 

How to keep everyone busy all the time -- other than 'painting rocks' (which is the way the Army used to do it)?

In theory it's simple: keeping everyone productively busy means actively managing their downtime, aka the 'white space', between and amongst their planned activities.

White space and the matrix

In organizations that are aggressively matrix managed, one approach to 'white space' management is to reassign people to another project with the intention of just a short assignment to 'keep them off the overhead' and always on 'billable hours'.  Of course, such practice breaks up the team for a short time so it kind of flies in the face of cohesiveness, team accomplishment, and team metrics.

And, aggressive matrix management assumes the F.W. Taylor model of management science: jobs can be filled by anyone qualified for the job description... interchangeable parts, as it were. In the era of team work where teams recruit their members, Taylorism is an anathema. Thus, aggressive matrix management is likewise seen as anti-team.

Backlog and whitespace

That all brings us to another approach -- more popular these days -- which is: manage the white space by managing the team backlog.

• Make sure that the backlog has all the technical debt and low priority requirements present and accounted for so that they can be fit to the white space opportunity.
• Develop and maintain a "parking lot" for off-baseline opportunities that might fit in the white space
• So also bring in mock testing, special event prototyping, and, of course, that bane of all:
• Maintenance of team records.

Running cost of teams

One big advantage of managing by teams: the cost is relatively fixed. Each team has a running cost, and so the total cost closely approximates the sum of the number of teams x the running cost of each. 

Of course, many PMs are NOT comfortable with the project staff being a fixed cost. They would much rather have more granular control. I get it, but the here's the main point about cost:

The cost of a project is not its value; in a "good project", value as judged by users and customers greatly exceeds cost

Here's the memo: Manage for value! (Oh!, did I say I wrote the book?)

---

Like this blog? You'll like my books also! Buy them at any online book retailer!

Is trust essential? Is the answer obvious?

---

"They say" that trust is essential to any project team working effectively. To not trust is to layer on ineffective and non-value add efforts at surveillance, double checking, micro-management, etc and so on.

Yet, if there was universally trust everywhere you do business, you would not need nearly all the structure that goes along with people working in groups. But the fact is that projects of any significant scope are organized with hierarchical structure (minimum trust required):

• Some one is in charge
• Others "report to ..."
• Rules are a tool; they can substitute for face-to-face encounters
• Trust is not really required because 'rules' enforce acceptable behaviors
• Break the rules, and there are consequences. But, the consequences are usually time-limited. You get out of the dog house after you've served your time
  

Not so fast!

Hierarchies may be the on-paper way of organizing, but 'getting things done' requires networks; and networks are definitely not hierarchical. 

But networks run on trust, not rules. No trust ... no network, or least no network membership.

• Oh, yes, there are consequences, but, no, there are no time limits. 
• You may be in the dog house a very long time.

 And so here we are:

• On paper: hierarchies and no trust required. Rules are all that is needed; and consequences if the rules are broken
• In fact: networks are how people work; rules aren't need. But, if trust is broken, there are consequences. And those consequences are very long term.  

---

Like this blog? You'll like my books also! Buy them at any online book retailer!

The 2nd Law ....

---

Did you heat a cup of coffee in the office microwave, and then walk away and leave it there?

Sometimes you just forget.

And when you returned to get the cup, what did you find?

Crap! The coffee is cool again. In fact, the average temperature of all the elements in the microwave are about the same: the coffee, cup, and surrounding air. Whereas after first heating, the averages were quite distinctively different; the coffee was hot; the air was not so much. But after a bit, all discriminating differences are lost. 

Said another way: Over time, and in isolation, "waste" increased, where, in this case, "waste" is the heat (energy) that was usefully in the coffee, but is now wastefully distributed throughout the microwave. The former distinctly organized sources of energy have become homogenous, bland, without contrast and shades of complexion. In effect: disorganized and wasteful; almost without value.

What's happened?
Physics took over.
Yes but ..... Actually statistics is the underlying explanation for the increase in waste, and that idea will take us to project management (which constantly opposes waste)

So read on; I'll get to project management shortly. 

So, what do we make of this?

At the outset, there was order, structure, and organization to the energy in the container. 

But over time, this orderly organization disappeared.

Inexorably, over time, and in isolation (that is: no outside influences or help), "disorder" (as opposite of "order") always increases until some equilibrium is reached. Distinctive differences degrade, becoming homogeneous.

And, by the way, value is lost .... The utility of the disordered is usually less than the ordered. Keep that in mind, project people!

Don't forget the living:

And this phenomenon applies to biological sources also: Without some stimulus from time to time, when in isolation, biological systems all tend toward a low-energy minimum maintenance state.

Statistical formulation

I mentioned statistics.

Hardly was the ink dry on the thermodynamics explanation of the cooling coffee than others grasped the idea that there's a statistical explanation as well: 

The probability of a well ordered configuration is hugely less than a disordered one. Even for the coffee cup situation, there are very few ordered configurations; there are effectively infinite disordered configurations for the distribution of energy. 

Disorder is the more likely end-state.

Generally speaking, given isolation, the probability that disorder increases and order decreases is very high. 

And never the other way around!

The 2nd Law:

All of the above is a layman's explanation of the 2nd Law of Thermodynamics (*), originally conceived as a law of physics to explain the distribution (and redistribution) of energetic molecules in a container. 

But given that there are many more useful concepts that arise from the statistics of disorder, perhaps the 2nd Law should be the Disorder Law.(**)

 

Maximize throughput ... project objective 

Another interesting tidbit, arising from the statistical interpretation, is that it is improbable for a system to be completely disordered or completely ordered. 

The 2nd Law predicts that statistically -- as things are approached asymptotically -- there will always be something missing; something lost; something wasted. 

Minimizing waste and lost value, and maximizing throughput thus becomes an exercise in working with the 2nd Law.

Isolated projects

You probably saw this bit coming: 

Projects that are highly isolated by security protocols, or physical remoteness, or by uninterest and lack of attention are vulnerable to the inevitability of  the 2nd Law. 

If external stimulus, energy, and interest are cut off, then the 2nd Law predicts blandness; lack of innovation, productivity, and morale; an increase of waste; and a general race to the bottom where a minimum effort is maintained. 

And, by the way, who among us have not seen such in the corners of large bureaucracies, oversized project offices, and similar locations? We're likely to say: Does anyone care?

.

Counter measures:

The only avoidance tactic for this decay into mediocrity and blandness is to selectively apply new energy from the outside. 

• In project terms, this means re-energizing individuals, individually. (Giving everybody a new T-shirt or coffee cup won't restore individual leadership, energy, and innovativeness). 
• This means aggressively combating wastefulness, non-value add activity, and a general acceptance of 'shit happens'
• This means allocating time and space, away from the project, for recharging.
• This means that selective (and genuine) attention to the project by outsiders is mandatory.
• And, this may require rotation to an outside activity to spark new behaviors.
• Not least: mitigating some physical remoteness and isolation.

---

(*) There is a First Law: Energy is never destroyed; it may change form, but in total it is conserved. This is a handy bit of information, but for PM purposes the way in which energy distributes itself is where the action is; and that is the domain of the 2nd Law.

"Entropy" is the word physicists use for "disorder"

 

And, there is a Third Law: The 3rd Law says that there is actually a limit to how disorderly things can become. That's actually good news for PM! But this limit is so remote that it's of no practical consequence in projects, unless you are trying to squeeze the last bit from an information channel. 

(**) There is more about this topic as it affects human situations in Steve Pinker's book, "Enlightenment Now". Pinker uses the term "Law of Entropy" instead of 2nd Law

 

---

Like this blog? You'll like my books also! Buy them at any online book retailer!

Mixed methodologies: Agile and ....

---

There comes a point where more planning can not remove the remaining uncertainty, instead execution must be used to provide data and remove uncertainty.

This quote comes from a nicely argued case -- from the agile blog 'leading answers' -- for mixing agile methods in rather traditional businesses, like the oil and gas exploration/production business

If ever there was a business that benefits from Boehm's Spiral Model, OGM (oil, gas, minerals) is certainly one. (Disclosure: I hold some OGM leases in Texas, so I've a bit of personal experience with this)

So, what have you got here?

• A lot of risk acknowledged up front (can't know everything -- thus the opening quote)
• A need to run with pilot projects before committing to production
• A need to tie into legacy systems (in the OGM case, distribution systems)
• A lot of deliverables that can be done incrementally and then integrated
• Small (it's all relative re small) teams, co-located (or the virtual version thereof), personally committed, with risk hanging on every move.
• A degree of local autonomy -- even if virtual -- required to meet the challenges of the moment

Sounds like an environment that needs agility, if not agile methods, on a lot of the stuff.

Of course, there's "one big thing":

You can't go around self-organizing (agile speak) willy-nilly! There are regulatory constraints everywhere and safety-first doctrine hanging on every move.

So, yes, there is a big bureaucracy that watches over... it's certainly more intrusive than a coach or a servant-leader (more agile speak)  (I'm sure they never heard this stuff in an oil field or an offshore rig!). In fact, I'll bet the rig boss is a force to be reckoned with!

---

Like this blog? You'll like my books also! Buy them at any online book retailer!

Trust, but not trusting

---

"They say" that trust is essential to any project team working effectively. To not trust is to layer on ineffective and non-value add efforts at surveillance, double checking, micro-management, etc and so on.

Yet, nearly all projects of any significant scope are organized hierarchically:

• Some one is in charge
• Others "report to ..."
• Rules are a tool; they can substitute for face-to-face encounters
• Trust is not really required because 'rules' enforce acceptable behaviors
• Break the rules, and there are consequences. But, the consequences are usually time-limited. You get out of the dog house after you've served your time
  

Not so fast!

Hierarchies may be the on-paper way of organizing, but 'getting things done' requires networks; and networks are definitely not hierarchical. 

But networks run on trust, not rules. No trust ... no network, or least no network membership.

• Oh, yes, there are consequences, but, no, there are no time limits. 
• You may be in the dog house a very long time.

 And so here we are:

• On paper: hierarchies and no trust required. Rules are all that is needed; and consequences if the rules are broken
• In fact: networks are how people work; rules aren't need. But, if trust is broken, there are consequences. And those consequences are very long term.  

---

Buy them at any online book retailer!

Risking the team

---

Are you on one of those death march projects about to burn out. Want some time off? Perhaps it's in the plan

Formula  solution
Google among others -- Microsoft, etc -- are well known for the "time off, do what you want toward self improvement and personnel innovation" model; formulas like that lend objectivity to the process (not playing favorites, etc). Note: more on this in the "6x2x1" model discussed last

Productivity drop
Of course, the real issue is one that agile leader Scott Ambler has talked about: the precipitous drop in productivity once you reach about 70% throughput capacity of the team. Up to this point, the pace of output (velocity) is predictably close to team benchmarks; thereafter, it has been observed to fall off a cliff.

Other observers have put it down as a variation on "Brooks Law" named after famed IBM-370 project leader Fred Brooks: "Adding people to a late project makes it later" . In this case, it's too many people on the team with too many interferences. It's been observed that to raise productivity, reduce staff!

Wave bounces
In the physics of wave theory, we see the same phenomenon: when the "load" can not absorb the energy applied, the excess is reflected back, causing interference and setting up standing waves. This occurs in electronic cables, but it also happens on the beach, and in traffic.

Ever wondered why you are stopped in traffic miles from the interference while others up ahead are moving? Answer: traffic load exceeds the highway's ability to absorb the oncoming cars, thereby launching reflections of standing waves that ebb and crest.

So it is in teams: apply energy beyond the team's ability to absorb and you simply get reflected interference. Like I said: the way to speed things up is to reduce the number of teams working and the number of staff applied.

WIP Limits
In agile/lean Kanban theory, this means getting a grip on the WIP limits... you simply can't have too many things in play beyond a certain capacity.

Sometimes the problem arises with sponsors: their answer is universally: Throw more resources in, exactly opposite the correct remedy

6x2x1 model
One of my students said this:

"Daniel Pink  has an excellent book called Drive, the surprising truth about what motivates us. In the book, Pink talks about inspiring high productivity and maintaining a sustainable pace.

One of the techniques is the 6x2x1 iteration model. This says that for every six two week iterations the development team should have a 1 week iteration where they are free to work project related issues of their choice.

You can also run a 3x4x1 model for four week iterations. Proponents of this approach have observed that the development teams will often tackle tough problems, implement significant improvements and generally advance the project during these free play periods. Without the time crunch to complete the story points the team also refreshes itself."

I don't know, but Pink's thesis may have been the genesis of the Google and Microsoft "time off" plans I've already mentioned, or maybe the experience of those plans found their way into Pink's thesis. Either way, time off matters!

---

Buy them at any online book retailer!

Let them figure it out

---

"Let them figure it out" is the mantra for small team management at its best.
I'm constantly amazed at how fast and successfully small teams converge to a local optimization, finding a methodology for doing whatever they are doing that maximizes their interests.

Local optimization
In several recent situations I was an observer and a participant as 20 or teams of anywhere from 2 to 6 people were given the same task, given the same instructions, given the same resources, and had the same strategic goal.

What happened?

There were about a half dozen unique methods that were synthesized in real time, tested, and the most advantageous selected. What I noticed were several dynamics working nearly simultaneously:

• Self organization: who is going to do what -- mostly, a volunteer thing as to who does what, though informed by task, skill, and capability of the team members
• Convergence: fail quick, fix, and retry til it's working well. You can feel it when the non-value add stuff dissipates and it's all about value-add
• Local interests: Local interests are both personal and team oriented. Each person tends to maximize their own interests to the extent that they fit in the overall team envelop; and the team optimizes to max out their contribution to the strategic goal

And the PMO?
The PMO was there to set the strategic goal; put the resources in place, having recruited the teams; and knock down the issues that were not foreseen. And, lest it not be forgotten: to provide feedback during and after -- both a real-time incentive, and a after-action atta-boy

This stuff actually works!

Not so fast! Is virtual local?
But, did I mention virtual teams?
Virtual teams have less bandwidth and so their velocity is correspondingly less.
Convergence times are greater, etc. But, the principles apply

---

Buy them at any online book retailer!

Approaching team burnout

---

Are you on one of those death march projects about to burn out. Want some time off? Perhaps it's in the plan

Formula  solution
Google among others -- Microsoft, etc -- are well known for the "time off, do what you want toward self improvement and personnel innovation" model; formulas like that lend objectivity to the process (not playing favorites, etc). Note: more on this in the "6x2x1" model discussed last

Productivity drop
Of course, the real issue is one that agile leader Scott Ambler has talked about: the precipitous drop in productivity once you reach about 70% throughput capacity of the team. Up to this point, the pace of output (velocity) is predictably close to team benchmarks; thereafter, it has been observed to fall off a cliff.

Other observers have put it down as a variation on "Brooks Law" named after famed IBM-370 project leader Fred Brooks: "Adding people to a late project makes it later" . In this case, it's too many people on the team with too many interferences. It's been observed that to raise productivity, reduce staff!

Wave bounces
In the physics of wave theory, we see the same phenomenon: when the "load" can not absorb the energy applied, the excess is reflected back, causing interference and setting up standing waves. This occurs in electronic cables, but it also happens on the beach, and in traffic.

Ever wondered why you are stopped in traffic miles from the interference while others up ahead are moving? Answer: traffic load exceeds the highway's ability to absorb the oncoming cars, thereby launching reflections of standing waves that ebb and crest.

So it is in teams: apply energy beyond the team's ability to absorb and you simply get reflected interference. Like I said: the way to speed things up is to reduce the number of teams working and the number of staff applied.

WIP Limits
In agile/lean Kanban theory, this means getting a grip on the WIP limits... you simply can't have too many things in play beyond a certain capacity.

Sometimes the problem arises with sponsors: their answer is universally: Throw more resources in, exactly opposite the correct remedy

6x2x1 model
One of my students said this:

"Daniel Pink  has an excellent book called Drive, the surprising truth about what motivates us. In the book, Pink talks about inspiring high productivity and maintaining a sustainable pace.

One of the techniques is the 6x2x1 iteration model. This says that for every six two week iterations the development team should have a 1 week iteration where they are free to work project related issues of their choice.

You can also run a 3x4x1 model for four week iterations. Proponents of this approach have observed that the development teams will often tackle tough problems, implement significant improvements and generally advance the project during these free play periods. Without the time crunch to complete the story points the team also refreshes itself."

I don't know, but Pink's thesis may have been the genesis of the Google and Microsoft "time off" plans I've already mentioned, or maybe the experience of those plans found their way into Pink's thesis. Either way, time off matters!

---

Buy them at any online book retailer!

Manage the white space

---

You've got a team to manage; until you don't
Keeping the team together promotes cohesiveness, intra-team loyalties, and productivity (no investment required to introduce new players and relationships). But, if there's too much slack -- i.e. downtime or "whitespace" --  you might lose your team.

But, keeping you team begs the question: How to keep everyone busy all the time so as to fend off raiders looking for resources?  In the popular vernacular of project management, keeping everyone productively busy means actively managing their downtime, aka 'white space', between and amongst their planned activities.

Whitespace methodologies
In organizations that are aggressively matrix managed, one approach to 'white space' management is to reassign people to another project with the intention of just a short assignment to 'keep them off the overhead' and always on 'billable hours'.  Of course, such practice breaks up the team for a short time so it kind of flies in the face of cohesiveness, team accomplishment, and team metrics.

And, aggressive matrix management assumes the F.W. Taylor model of management science: jobs can be filled by anyone qualified for the job description... interchangeable parts, as it were. In the era of team work where teams recruit their members, Taylorism is an anathema. Thus, aggressive matrix management is likewise seen as anti-team.

That all brings us to another approach -- more popular these days -- which is: manage the white space by managing the team backlog.

• Make sure that the backlog has all the technical debt and low priority requirements present and accounted for so that they can be fit to the white space opportunity.
• Develop and maintain a "parking lot" for off-baseline opportunities that might fit in the white space
• So also bring in mock testing, special event prototyping, and, of course, that bane of all:
• Maintenance of team records.

What does it cost?
One consequence of managing by teams: the cost is known, predictable, and relatively fixed. Each team has a running cost, and so the total cost closely approximates the sum of the number of teams x the running cost of each.

Affordable value
Of course, is the team affordable? Many PMs are not comfortable with the project staff being a fixed cost. They would much rather have more granular control. I get it, but the here's the main point about cost:

The cost of a project is not its value; in a "good project", value greatly exceeds cost

---

Buy them at any online book retailer!

Burning up the team

---

Are you on one of those death march projects about to burn out. Want some time off? Perhaps it's in the plan

Google among others -- Microsoft, etc -- are well known for the "time off, do what you want toward self improvement and personnel innovation" model; formulas like you suggest lend objectivity to the process (not playing favorites, etc).

Losing productivity
Of course, the real issue is one that agile leader Scott Ambler has talked about: the precipitous drop in productivity once you reach about 70% throughput capacity of the team. Up to this point, the pace of output (velocity) is predictably close to team benchmarks; thereafter, it has been observed to fall off a cliff.

Brook's Law -- it's not been repealed
Other observers have put it down as "Brooks Law" named after famed IBM-370 project leader Fred Brooks: "Adding people to a late project makes it later" . Read: "Mythical Man-month" for more from Brooks

Did I mention Physics?
In the physics of wave theory, we see the same phenomenon: when the "load" can not absorb the energy applied, the excess is reflected back, causing interference and setting up standing waves. This occurs in electronic cables, but it also happens on the beach, and in traffic.

So it is in teams: apply energy beyond the team's ability to absorb and you simply get reflected interference.
Many have told me: the way to speed things up is to reduce the number of teams working and the number of staff applied.

WIP Limits
In agile/lean Kanban theory, this means getting a grip on the WIP limits... you simply can't have too many things in play beyond a certain capacity. The problem arises with sponsors: their answer is universally: throw more resources in, exactly opposite the correct remedy

6x2x1, or other
One of my students said this: "Daniel Pink  has an excellent book called "Drive: The surprising truth about what motivates us" that talks about inspiring high productivity and maintaining a sustainable pace.
One of the techniques is the 6x2x1 iteration model.
This says that for every six two week iterations the development team should have a 1 week iteration where they are free to work project related issues of their choice.

You can also run a 3x4x1 model for four week iterations.
Proponents of this approach have observed that the development teams will often tackle tough problems, implement significant improvements and generally advance the project during these free play periods. Without the time crunch to complete the story points the team also refreshes itself."

And now, we rest!

---

Buy them at any online book retailer!

To self-organize, or not?

---

I like headlines that have a simple message

This one--No more self-organizing teams--caught my eye for three reasons:

• I agree with the sentiment
• It was written by Jim Highsmith, who rights some good stuff
• I have an interest in leadership per se

Now, to be fair, Mike Cohn more or less supports the thesis we present here when he (Mike) quotes Philip Anderson who writes in "Biology of Business"

Self-organization does not mean that workers instead of managers engineer an organization design. It does not mean letting people do whatever they want to do. It means that management commits to guiding the evolution of behaviors that emerge from the interaction of independent agents instead of specifying in advance what effective behavior is. (1999, 120)

But, back to the headline: What did Mr. Highsmith tell us? (Of course, he said more than these bullets, but these are the highlights)

• There is just too much experience and management literature that shows that good leaders make a big difference
• There is a contingent within the agile community that is fundamentally anarchist at heart and it has latched onto the term self-organizing because it sounds better than anarchy. However, putting a duck suit on a chicken doesn’t make a chicken a duck.
• Delegating decisions in an organization isn’t a simple task; it requires tremendous thought and some experimentation
• Leading is hard. If it was easy, every company would be “great,” to use Jim Collins’ term (Good to Great ).

What did he not tell us?

• Dominance is a human trait not easily set aside; thus the natural leaders will come to the fore and the natural followers will fall-in thankfully. There's no need and no practical way to rotate the leadership once dominance is established
• Like it or not, positional authority counts for something in all but the smallest enterprises. Thus, senior managers are senior for a reason. It's hard to establish credibility with the stakeholdes that hold the key to resources if the team is being led from the bottom of the pecking order.
• Self-organization may deny biases and bully the nemesis off the team. Group think, anyone?
• Delegation is a tricky matter: do only those things that only you can do

And the answer is: according to Highsmith, something called "light touch", but in reality it means leading and managing from a position of trusting the team, but mentoring the "self-organization" towards a better day.

---

Buy them at any online book retailer!

Teamwork -- managing the white space

---

One of the big differences between a team and a group is cohesiveness around the goal:

There's no success individually unless there is success collectively.

Inevitably, keeping the team together to promote cohesiveness raises the question: how to keep everyone busy all the time -- other than 'painting rocks' (which is the way the Army used to do it). In the popular vernacular of project management, keeping everyone productively busy means actively managing their downtime, aka 'white space', between and amongst their planned activities.

In organizations that are aggressively matrix managed, one approach to 'white space' management is to reassign people to another project with the intention of just a short assignment to 'keep them off the overhead' and always on 'billable hours'.  Of course, such practice breaks up the team for a short time so it kind of flies in the face of cohesiveness, team accomplishment, and team metrics.

And, aggressive matrix management assumes the F.W. Taylor model of management science: jobs can be filled by anyone qualified for the job description... interchangeable parts, as it were. In the era of team work where teams recruit their members, Taylorism is an anathema. Thus, aggressive matrix management is likewise seen as anti-team.

That all brings us to another approach -- more popular these days -- which is: manage the white space by managing the team backlog.

• Make sure that the backlog has all the technical debt and low priority requirements present and accounted for so that they can be fit to the white space opportunity.
• Develop and maintain a "parking lot" for off-baseline opportunities that might fit in the white space
• So also bring in mock testing, special event prototyping, and, of course, that bane of all:
• Maintenance of team records.

One big advantage of managing by teams: the cost is relatively fixed. Each team has a running cost, and so the total cost closely approximates the sum of the number of teams x the running cost of each. Of course, many PMs are NOT comfortable with the project staff being a fixed cost. They would much rather have more granular control. I get it, but the here's the main point about cost:

The cost of a project is not its value; in a "good project", value greatly exceeds cost

Here's the memo: Manage for value! (Oh!, did I say I wrote the book?)

---

Read in the library at Square Peg Consulting about these books I've written
Buy them at any online book retailer!

Read my contribution to the Flashblog

Scale down, or "too small to succeed?"

---

What about scaling down?
Most of the posts I read are about scaling up to ever larger projects, but what about scaling down? What if you are doing bug fixes and small scale projects with just one or two people? Is a methodology of any help, and if you're working with software, can Agile be helpful scaled down?

To the first point, my answer is: Sure! A methodology -- which is just a repeated way of stringing practices together -- can help. Why invent the 'string' (methodology) each time you do something? Just follow the same practices in the same sequences each time. Thus, you can have a methodology for just driving your car... perhaps the ultimate team-of-one.

Small scale Agile
Re agile and small scale: Really, the agile manifesto does not inherently break down at small scale; nor do the agile principles. It's actually easier to go smaller than to go larger.

But, not so fast! What about:...

• Teams and all the stuff about team work if you are only one or two people?
• Pair programming?
• Redundancy and multi-functionalism?
• Collaboration and communication by osmosis with others?

Admittedly, you give up a few things in a team-of-one situation -- perhaps pair programming and redundancy -- but there's no reason to give up the other ideas of agile:

• close coordination and collaboration with the customer/user
• a focus on satisfying expectation over satisfying specification
• quick turn around of usable product
• personal commitment and accountability
• collaboration with peers and SMEs on a frequent and informal basis
• lean thinking
• Kanban progression and accountability

Got redundancy?
The hardest thing to deal with in a too-small team is lack of redundancy -- or not being anti-fragile -- and lack of enough skill and experience to work over a large domain. It's pretty obvious that one person team has a single point failure: when you're away, the team is down. Such a failure mode may not tolerable to others; such a failure mode is obviously fragile, unable to absorb large shock without failing.

And, one person's experience only extends so far... thus limiting the domain and extent of possible solutions (leading, sometimes, to: "if all you have is a hammer, then everything is a nail" misuses and abuses of whatever your skill set is. I once had a person who was a loner and also an expert with MSAccess... no matter the problem, he seemed to solve it with Access!)

Management challenges
As managers we are responsible for making it work. So in the situation of really small teams, there can still be, and we should insist upon:

• an opening narrative
• a conversation about requirements and approach (to include architecture)
• peer review by other experts
• code inspections and commitment to standards
• rotation of assignments among context to drive broadening
• reflection and retrospective analysis

---

Read in the library at Square Peg Consulting about these books I've written
Buy them at any online book retailer!

Read my contribution to the Flashblog

Can agile teams be virtual?

---

Somebody asked: can a virtual team do Agile?

• 15 years ago, the answer might have been no. 
• Seven years ago, more less pre smart phone and smart-phone networking, the answer was probably yes, but with reservations. 
• Now, the answer is "Of course", with some adjustments. 

Here are my thoughts on this.

The communications channel:

Virtual teams often begin by emulating the behavior and circumstances of real teams. But can they?

The first thought is communications. Real teams can handle a much greater N2 communication intensity because much communication is person-to-person, and much of person-to-person communication is non-verbal.

What is N2? It's really N-squared. It's the approximate number of ways objects can communicate. The real formula is N(N-1). There are 5*4 ways 5 people can talk among themselves.

Non-verbal face-to-face is a very high bandwidth channel -- speed of light really -- capable of communicating a large information message instantly, although the messages are often highly encoded and subject to inaccurate decoding among strangers or nearly strangers. Nonetheless, it's much easier to sort out the cacophony of discussion if you can put face and voice and context together. (Anyone who's participated in a large video conference knows the difficulty of segregating voices and getting them associated correctly)

Consequently, when planning for virtual teams, bear in mind that virtual teams don't have the luxury of infinite bandwidth. Even with up to date video, the non-verbal is communicated in a lossy channel. And here's the thing: you don't know how much is lost. Thus, more time is needed in the schedule to compensate for the bandwidth constraints.

Velocity impacts:

Some teams relish the hub-bub of real time communications, and others do not. Good practice is to benchmark the virtual velocity before beginning the first iteration. Look for virtual velocity to be slower, and productivity less. 

Perhaps the virtual team needs to be larger, or given smaller bites to work on. (Ooops: Adding people to a slow team makes it slower ... Read: "The Mythical Man month, 20th anniversary edition")


Assigning team work:

Assigning work to virtual teams should follow this simple rule: partition work according to its natural boundaries that minimize and simplify interfaces.

Albert Einstein has been quoted to the effect: "Make everything as simple as possible, but not too simple".

But over simplification is hazardous also. Who's got the "big picture" in mind? The solution can lose cohesion and the bigger picture becomes so obscured that effective solutions are not possible to build from the too-small parts.

Iteration Planning and tracking:

The iteration planning meeting is the agile mechanism for assigning work. All the team's complement attends. The same applies to a virtual team.

Tracking progress and identifying problems:

Only the daily stand-up meeting is affected by the communications unique to virtual teams. The less efficient electronic channels may have to be compensated by extending the time-box of the daily stand-up.

The burn-down and trending data is part of the team scorecard posted electronically as opposed to marking a whiteboard in a team space.

I end where I started:  "Of course", with some adjustments.

---

Read in the library at Square Peg Consulting about these books I've written
Buy them at any online book retailer!

Read my contribution to the Flashblog

Organization by coercion

---

"It is impossible to organize an army solely by coercion. At least some of the commanders and soldiers must believe in something ...."

From the book "Sapiens" by Harari

Fair enough

Now, consider that wisdom rewritten in project team terms:

It is impossible to organize a team, and expect productive outcomes, solely by top-down direction. At lease some of the team leaders and team members must believe in the team's mission and the leader's vision

 And, I submit, to be believed begins with being believable. A play on words, to be sure, but somewhere between the banal and "pie in the sky" an innovative vision and reasonable path forward must be evident:

• In pictures for the visualists
• In words for the readers
• In person for those that are attracted by charisma to a cause

If there's to be sacrifice, then an appeal to and wrapping in a higher calling--'duty, honor, country' in the military--not just money, will be in the mix. I think we all know that money speaks, but only so loudly. After a certain volume, it's "the other stuff" that makes up the culture and value system that motivates.

---

Read in the library at Square Peg Consulting about these books I've written
Buy them at any online book retailer!

Read my contribution to the Flashblog

Square pegs; round holes -- the HR problem

---

Donald Rumsfeld -- former Secretary of Defense -- was criticized widely for his statement: "You go to war with the army you have, not the army you might want ..."

Substitute "project" for 'war' and "project team" for 'army' in there and it might appear more familiar than many of us want to admit.

I've always maintained: "You organize according to the staff you have, not the staff you might want"

Now, I find no less an eminence than the team of Reisman and Glazer, who wrote the HR classic "The Lonely Crowd", called by some a landmark study of the American character, said something similar to what both myself and Rumsfeld have said, only they wrote it many years ago:

" .... [Although] different kinds of characters can be used for the same work within an institution, a ‘price’ is paid by the character types that fit badly as against the release of energy provided by the congruence of character and task."  As quoted by Doris Kearns Goodwin in "Lyndon Johnson and the American Dream"

By that team Reisman and Glazer mean what?

• "Character types that fit badly" are those staff or team members who can't do the job you have assigned them to do. They will either spend a lot of their energy getting nowhere, or they will suck up a lot of your energy trying to get them to do it 
• "Congruence of character and task" is their speak for "the job you've asked them to do"

It's no coincidence I've named my consultancy "Square Peg". The organization chart, like staffing plans, and every other type of plan, rarely survive the collision of plan with reality.*

---

*Planning is good; it turns up a lot stuff that heretofore was under the rock. It's just that plans themselves often have to change
 

---

Read in the library at Square Peg Consulting about these books I've written
Buy them at any online book retailer!

Read my contribution to the Flashblog

"Right kind of Crazy"

---

Have you read this book?
Spoiler alert: No math! And, it's only 225 pages in hardcover

• If you are a mechanical engineer, it's a must
• If you are any kind of an engineer, it's a should-read
• If you are a project manager looking for leadership lessons, it's a must read (but you can skip the engineering detail)

It's an amazing story of the project team at Jet Propulsion Lab (JPL) that conceived the skycrane for the last Mars rover landing.

That's a fascinating tale by itself, but the leadership and teamwork insights are worth the price. Indeed, the subtitle is:

Teamwork, leadership, and high-stakes innovation

The chapter titles are major themes developed in the context of the JPL systems and mechanical engineering context, but really applicable all around. A few to ponder:

• "Hold onto the doubt" meaning continuing doubt about that what you are doing is a good thing and that doubt will often keep you out of the disaster area 
• "Self-authorization" meaning act when others won't or can't or are paralyzed by analysis
• "Systems engineers" meaning step back and get a holistic view; the parts, when assembled, are sometimes destructive rather than constructive
• "Dark room" meaning sometimes you wander into a black hole from which there seems no escape... now what?

And, there are others ....
Recommended reading for anyone in the leadership, team work, or technology domains
 

---

Read in the library at Square Peg Consulting about these books I've written
Buy them at any online book retailer!

Read my contribution to the Flashblog

Team overload -- burning out

---

Are you on one of those death march projects about to burn out. Want some time off? Perhaps it's in the plan

Formula  solution
Google among others -- Microsoft, etc -- are well known for the "time off, do what you want toward self improvement and personnel innovation" model; formulas like that lend objectivity to the process (not playing favorites, etc). Note: more on this in the "6x2x1" model discussed last

Productivity drop
Of course, the real issue is one that agile leader Scott Ambler has talked about: the precipitous drop in productivity once you reach about 70% throughput capacity of the team. Up to this point, the pace of output (velocity) is predictably close to team benchmarks; thereafter, it has been observed to fall off a cliff.

Other observers have put it down as a variation on "Brooks Law" named after famed IBM-370 project leader Fred Brooks: "Adding people to a late project makes it later" . In this case, it's too many people on the team with too many interferences. It's been observed that to raise productivity, reduce staff!

Wave bounces
In the physics of wave theory, we see the same phenomenon: when the "load" can not absorb the energy applied, the excess is reflected back, causing interference and setting up standing waves. This occurs in electronic cables, but it also happens on the beach, and in traffic.

Ever wondered why you are stopped in traffic miles from the interference while others up ahead are moving? Answer: traffic load exceeds the highway's ability to absorb the oncoming cars, thereby launching reflections of standing waves that ebb and crest.

So it is in teams: apply energy beyond the team's ability to absorb and you simply get reflected interference. Like I said: the way to speed things up is to reduce the number of teams working and the number of staff applied.

In agile/lean Kanban theory, this means getting a grip on the WIP limits... you simply can't have too many things in play beyond a certain capacity.

Sometimes the problem arises with sponsors: their answer is universally: Throw more resources in, exactly opposite the correct remedy

6x2x1 model
One of my students said this:

"Daniel Pink  has an excellent book called Drive, the surprising truth about what motivates us. In the book, Pink talks about inspiring high productivity and maintaining a sustainable pace.

One of the techniques is the 6x2x1 iteration model. This says that for every six two week iterations the development team should have a 1 week iteration where they are free to work project related issues of their choice.

You can also run a 3x4x1 model for four week iterations. Proponents of this approach have observed that the development teams will often tackle tough problems, implement significant improvements and generally advance the project during these free play periods. Without the time crunch to complete the story points the team also refreshes itself."

I don't know, but Pink's thesis may have been the genesis of the Google and Microsoft "time off" plans I've already mentioned, or maybe the experience of those plans found their way into Pink's thesis. Either way, time off matters!

---

Read in the library at Square Peg Consulting about these books I've written
Buy them at any online book retailer!

Read my contribution to the Flashblog

Adding staff -- slowly

---

First, we have "Brooks Law", as given in the classic case study "The Mystical Manmonth" by Dr. Fred Brooks:

"Adding staff to a late project makes it later"

I was no more thinking about that idea, than I read this missive in a history of the Civil War that I am engaged with:

“The veterans looked across the open ground at the newcomers with complete and unconcealed skepticism and hostility. In every line of their bearing—in the set of their jaws, the tilt of their heads, the look about their eyes peering out from under those valued hatbrims—they expressed for all to see the age-old, impersonal, unformulated feeling of the veteran for the recruit:

We have had it and you have not, and until you have been where we have been and have done what we have done we do not admit you to any kind of fellowship.”

Excerpt From: Catton, Bruce. “Glory Road.” This material may be protected by copyright.

OK, that might be tougher than the normal project team might be, but in my experience, until there is bonding over a common stress, there's not cohesion, and maybe not even functional integration.

So, as in war and most other things, to speed assimilation along, sometimes a bonding experience is needed. Thus, all the bonding games, etc, but it often works. Else, just put everybody in the deep end. Survival will do all that is necessary

And, did I mention virtual teams: there's really not a difference, not really.

---

Read in the library at Square Peg Consulting about these books I've written
Buy them at any online book retailer!

Read my contribution to the Flashblog