Saturday, April 21, 2018

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

Wednesday, April 18, 2018

The Project Balance Sheet

If you follow this blog you've read several references to the project balance sheet. So, is this about accounting? Yes, and no: Yes, it's about a double entry tool to keep track of "mine" and "yours", but no, it's not the accountant's tool used in your father's accounting office.

Take a look at this figure:

What have we got here?

First, the business and the project; but also what's mine -- the project stuff -- and what's yours -- the business stuff. Mine and yours!

On the left side of the balance sheet is the sponsor's investment in the project. Investment need not be all monetized, and it need not be all tangible. Sometimes 'good will' -- the accountant's name for the intangible gut feeling that this thing is worth more than book value (market-valued assets) -- counts for a lot. (Think: sponsor commitment, even when the going gets tough)
'Yours' simply means it's resources and commitments owned and given by others to the project. It's the 'your's side of the balance sheet that's somewhat akin to the right side of the financial balance sheet (money owed to creditors and money invested by owners).

On the right side is the 'mine' side of the project balance sheet, akin to the left side of the financial accounting sheet (assets of the enterprise). The right side is the project side:
  • Estimates and evaluations of the project manager
  • Uses for the investment and resources to be entrusted to the project manage -- in effect deliverables and other artifacts, and perhaps some intangibles as well*
All about facts
 And, take note: the left side, the sponsor's side, is the fact-free zone: it's a top down allocation of resources to the vision. It is the ultimate utility expression of the sponsors: what's valuable, and how valuable, even if not entirely objective.

And on the right side, it's all about facts (benchmarks) and estimates (benchmarks applied to project circumstances). It's bottom up.

The gap
Of course, there's the inevitable gap where utility collides with facts and fact-based estimates. The gap is the risk between expectations and capacity-capability. And how large is the gap (risk): only as large as needed to create a balance--that is, a deal with the devil--so that the project can go forward.

 In other words, the gap (risk), shown on the project side, is only as large as it needs to be to close the gap. Usually, it's a matter of negotiation, but once the PMB is set, the risk is the PM's responsibility to manage.

Oops! the PM is the ultimate risk manager.

In a real world example, I had this situation:
  • We bid a job competitively in a firm fixed price environment. 
  • We offered a price that was equal to our cost; in other words, no fee (profit).  We just wanted to keep the lights on and keep barriers to competition with our customer as high as possible. 
  • We won! 
  • And, in  the next moment, my general manager said: "Your bonus depends on making 4% net margin".  I had my gap!  (oh yes, I made the margin and the customer was satisfied)

* Yes, indeed! Projects produce intangibles, even good will, but it makes for an accounting of project value all the less objective.

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

Sunday, April 15, 2018

If you can't draw it, ..... (can you build it?)

Many creative people will tell you that new ideas begin -- often spontaneously -- with a mind's sketch that they then render in some kind of media.

Fair enough -- no news there. We've talked about storyboards, etc before.

But then the heavy lifting begins. How to fill in the details? Where to start?

My advice: Draw it first.
If you can't draw it, you can't build it!

And so the question is begged: What's "it"

Three elements:
  1. Narrative
  2. Architecture
  3. Network

And, one more for the PM:
  • Methodology

Digression: My nephew reminds me that now we have 3-D printing as a prototype "drawing" tool. Indeed, that's his job: creating 3-D prototypes.

Narrative: (an example)
Bridge stanchion with strain sensor and sensor software

Let's start drawing: Actually, I like drawing with boxes. Here's my model, beginning with the ubiquitous black box (anyone can draw this!):

Black Box

Of course, at this point there is not much you can do with this 100% opaque object, though we could assign a function to it like, for example: bridge stanchion (hardware) or order entry shopping cart (software)

And so given a function, it needs an interface (blue); some way to address it's functionality and to enable its behavior in a larger system context:


And then we add content (white):


Except, not so fast! We need 'room' for stuff to happen, for the content to have elasticity for the unforeseen. And, so we add a buffer (grey) around the content, but inside the interface, thus completing the model:

  • Black: Boundary
  • Blue: Interface or API
  • Grey: Buffer
  • White: functional content

You could call this an architecture-driven approach and you would not be wrong:

1. First, come the boxes:
  • Define major functional "boxes"... what each box has to do, starting with the boundary (black): what's in/what's out. This step may take a lot of rearranging of things. Cards, notes, and other stories may be helpful in sorting the 'in' from the 'out'. If you've done affinity mapping, this boundary drill will be familiar.
  • Our example: three boxes consisting of (1) bridge stanchion (2) strain sensor (3) sensor software
Then comes the interface:
  • Then define the major way into and out of each box (interface, I/F, blue). If the interface is active, then: what does it do? and how do you get it to do it?
And then comes the "white box" detail:
  • The buffer, grey, captures exceptions or allows for performance variations. In effect, the buffer gives the content, white, some elasticity on its bounds.
  • And then there is the actual functional content, to include feature and performance.

2. Second big step: networks of boxes

  • Think of the boxes as nodes on a network
  • Connect the 'black' boxes in a network. The connectors are the ways the boxes communicate with the system
  •  Define network protocols for the connectors: how the interfaces actually communicate and pass data and control among themselves. This step may lead to refactoring some of the interface functionality previously defined.
  • That gets you a high-level "network-of-boxes" . Note: Some would call the boxes "subsystems", and that's ok. The label doesn't change the architecture or the functionality.
3. Third big step: white box design.

Define all the other details for the 'white box' design. All the code, wiring, and nuts and bolts to build out the box.
  • Expect to refactor the network as the white box detail emerges
  • Expect to refactor the white box once development begins. See: agile methods
And, not last: Methodology:

The beauty of this model is that each box can have its own methodology, so long as interfaces (blue) and boundaries (black) are honored among all boxes. In other words, once the boundaries and interfaces are set, they are SET!

The methodology can then be chosen for the white box detail: perhaps Agile for the software and some form of traditional for the hardware. This heterogeneous methodology domain is workable so long as there is honor among methods:

Interfaces and boundaries are sacrosanct!

Now What?
Estimate the work (yes, estimate: you really can't start off spending other people's money without an estimate); segment and sequence the work; and then build it, deliver it, and you are DONE!

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

Thursday, April 12, 2018

Friction -- a consequence of debt

And, so now we've all come to the point in the art and science of project management that not only do we have a myriad of biases that have been listed and explained and examined over the past 30 years, but now we have debts. The new one (for me) is social debt, as described by Philippe Kruchten

He tells us:
Damian Tamburri, from VU in Amsterdam, has introduced the notion of social debt, as a counter part of technical debt [ICSE2013 workshop].

Social debt is .... the accumulation over time of decisions about the way the development team (or community) communicates, collaborates and coordinates; in other words, decisions about the organizational structure, the process, the governance, the social interactions, or some elements inherited through the people: their knowledge, personality, working style, etc

Now, put social debt together with technical debt -- all the myriad of little things left undone -- and you get the idea of the friction in the project -- that is: impediments to velocity; inefficiencies in productivity. And, like friction in the physical world in which energy is wastefully converted to heat, only to dissipate without adding value, these debts absorb project energy.

So, what price -- actually, for the PM: cost -- is non-value-add of friction? First, friction spreads the tails of the Monte Carlo simulation of cost and schedule, and potentially shifts the mean cost and schedule to the right. Second, and certainly a root cause of the first point, friction holds back productivity and gives rise to lost energy (to overcome friction) and lower velocity (less throughput)

Fair enough. But, what do we do about it?
  • New project? Take a look at the history of overcoming debt and make adjustments to the knobs and switches of your project model
  • Got flexibility? Reorganize, retrain, change environment or tools, or add SMEs (or dismiss the high-friction nemesis)
  • On-going project? Rebaseline. That may cancel a lot of the social debt built up in the existing project. In effect: reboot
  • Risk management? Sure, think of both technical and social debt as a risk to be managed

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

Monday, April 9, 2018

One generation back

It's been a whole generation?

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

Friday, April 6, 2018

Expert forecasts, or not

More from Nate Silver:
"The more fundamental problem is that we have a demand for experts in our society but we don’t actually have that much of a demand for accurate forecasts.”

Could this be the issue? (Silver continues:)

"As [many] see it, [project] forecasters face three fundamental challenges.
  • First, it is very hard to determine cause and effect from [project] statistics alone.
  • Second, the [project circumstance] is always changing, so explanations of [project] behavior that hold in one [ ] cycle may not apply to future ones.
  • And third, as bad as their forecasts have been, the data that [project analysts] have to work with isn’t much good either."
Is this the justification for "no estimates?"

Nope, it's a caution about the real world. Other people with the money expect an estimate before work begins.

Have you ever had work done on your car or home without asking for an estimate? I hope your answer is No; and I hope you understand: stuff happens, even so.

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

Tuesday, April 3, 2018

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

Friday, March 30, 2018

Eric vs Erica

A study I read about started this way:
  • Draw a picture of an effective leader

Almost without exception, the picture was of a man.  Ooops: what about the lady leaders? There's certainly no lack of role models in both politics and business, from Angela Merkel -- CEO of Germany -- to  Meg Whitman -- CEO of HP Enterprises

Another study had people listen in to a business meeting where actors, Eric and Erica, among others, were discussing strategy, issues, business details, etc
  • Invariably, Eric was given high marks for leadership, even if the script for Erica was nearly identical 
Indeed, we learn this:

“It didn’t matter whether women spoke up 1) almost never, 2) rarely, 3) sometimes, 4) often, or 5) almost always,” Kyle Emich, a professor at Alfred Lerner College of Business and Economics at the University of Delaware, and one of the authors, wrote in an email.
“Women did not gain status for speaking up, and subsequently were less likely (much less) to be considered leaders.” 

The conclusion of those who study this stuff is that we're very much influenced by stereotypes learned from an very early age. In a word: culture. And, only time and performance will change culture significantly

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

Tuesday, March 27, 2018

Prediction -- signal and noise

Are you a predictor or a predictee?
Actually, for this posting it doesn't matter
This is about the qualities of a prediction, for which I am drawn to the book "The Signal and the Noise: why so many predictions fail -- and some don't" by Nate Silver

Silver lays out three principles to which all prediction should adhere:
  1. Think probabilistically: all predictions should be for a range of possibilities. This, of course, is old hat to anyone who is a regular reader of this blog. Everything we do has some risk and uncertainty about it, so no single point is credible when you think about all that could influence the outcome.
  2. Todays' forecast is the first forecast for the rest of the project: Silver is saying: don't be fixed on yesterday's forecast: stuff changes, especially with the passage of time. So must predictions. It's all fine to hold a baseline, until the baseline is useless as a management benchmark Then rebaseline!
  3. Look for consensus: Yes, a bold and audacious forecast might get you fame and fortune, but more likely your prediction will benefit from group participation. Who's not played the management training game of comparing individual estimates and solutions with the estimates and solutions of a group
 Now, take these principles and set them in context with chaos theory: the idea that small and seemingly unrelated changes in initial conditions or stimulus can be leveraged to large and unpredicted outcomes.  Principle 1 and 2 are really in play:
  • Initial conditions -- or the effect of initial conditions -- decay over time. The farther you go from the time you made your forecast, the less likely it remains valid. Stuff happens!
  • The effect of changes along the way are only statistically predictable, and then only if there is supporting data to make a statistical distribution; else: black swans --  the infrequent and statistically unpredictable observable effects chaos theory appear
And lastly, what about the qualities of a prediction:
  • Accurate: yes, most would agree accuracy is a great thing: Outcomes just as predicted. But if it turns out to be not accurate, was it nonetheless honest?
  • Honesty: this should be obvious, but did you shave the facts and interpret the edge effects to obtain the prediction you wanted? Was the prediction a "best judgment" or did politics enter?
  • Bias-free: Nope; all predictions made by project people are biased. It's only whether the bias was honest or dishonest 
  • Valuable: is the prediction useful, value-adding, and consequential to the project management task? If not, maybe it's just noise instead of signal

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

Saturday, March 24, 2018

Culture from the bottom up

Almost everything written about leadership includes this idea: that leaders have the responsibility to set the cultural values of the organization and ensure such values are deployed widely.

Fair enough

But here's a case where it works in practice but not in theory:

Culture is what the organizations' disparate polity say it is, including, by the way, the ideas of the leadership. It's not exclusively given from on high. It's distributed, quite federalized, balkanized and local. In fact, it's not an "it" at all.

Here it's one thing; over there: it's another. Collectively, there are norms and themes that stitch all the differences into one large tent, and probably even a headline about the big tent could be written.

But there could be a problem: what if, as a leader, you see an imperative to change "the culture"? What then? How do you go about influencing a balkanized culture?

Not easy is the first answer.
  • You need influence(s), entire strategies, a corps of ambassadors; incentives; and a compelling narrative.(*)
  • You've got to get "street smart" and work the local issues, fashioning a value set that will attract a following but also be responsive to the greater narrative.
  • You probably need a lot of time and patience 
At the end of the day, you can be an autocrat -- basically illiberal -- or a democrat (small "d"). Only the latter is sustainable by it's own energy. All else is inefficient, consuming more than is returned.
(*) Narratives fall broadly into to fearful or optimistic. The latter is the easier sell. It fits well with our unthinking "flight or fight" instincts. And, our natural bias, as human beings, is to fear loss more greatly than we reach for opportunity.

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

Monday, March 19, 2018

Stage Gates and Agile

One of my Agile Project Management students asked me about stage gates and agile. My first response was this:
  • Agile is not a gated methodology, primarily because scope is viewed as emergent, and thus the idea of pre-determined gate criteria is inconsistent with progressive elaboration and emergence.
  • Agile does embrace structured releases; you could put a criteria around a release and use it as a gate for scope to be delivered
  • Re budget: agile is effectively 'zero base' at every release, if not at every iteration. You can call the question at these points of demarcation.
  • Agile is a "best value" methodology, meaning: deliver the 'most' and 'best' that the budget will allow, wherein 'most' and 'best' is a value judgment of the customer/user.
  • Of course, every agile project should begin with a business case which morphs into a project charter. Thus, the epic narrative (the vision narrative) is told first in the business case, and retold in more project jargon in the charter. Thence, there are planning sessions to get the general scope and subordinate narratives so that an idea of best value can be formed.
But, DSDM is one agile method, among others, that is more oriented to a gated process than say, SCRUM. To see how this could work, take a look at this slide from "Quality Assurance in Agile Methods"

And, you can follow-up with this:

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

Thursday, March 15, 2018

Agile and R&D

I was recently asked if Agile and "R/D" go together. The issue at hand: how do you reconcile agile's call for product delivery to users every few weeks with the unknowns and false starts in a real R/D project?

Good question! I'm glad you asked.

Let's start with OPM ... Other people's money ... And the first question: What have you committed to do? There are two possible answers: (1) apply your best efforts; or (2) work to "completion".

Of course, (1) may be embodied in (2) -- why wouldn't you always apply your best efforts? -- but in the R/D domain (2) is often not a requirement and may be a bridge too far: -- got a completion cure for cancer? "Completion" means more than just effort; it has elements of accomplishment and obtained objectives.

"Completion" is problematic in the R/D domain: completion implies a reasonable knowledge of scope, and that may be impractical depending on the balance of the "R" with the "D". Heavy "R" implies very limited idea of the means to accomplish; "D" is the flip of that.

The best example of "best effort" is "Time and Materials" -- T/M. If you're working T/M your obligation -- legally at least -- is best effort, though you may feel some higher calling for completion.

The most constraining example of "completion" is Firm Fixed Price -- whether by contract or just project charter. FFP is almost never -- dare I say never? -- appropriate for R/D

And so now let's layer on Agile ... what's in and what's out vis a vis R/D:
Among the agile practises that are "IN" (in no particular order)
  • Conversational requirements ("I want to cure cancer")
  • Prototypes, models, and analysis (even, gasp! Statistics and calculus, though some would argue that no such ever occurs in an agile project)
  • Periodic reflection and review of lessons learned
  • Small teams working on partitioned scope
  • Trust and collaboration within the team
  • Skills redundancy
  • Local autonomy
  • Persistent teams, recruited to the cause
  • PM leadership to knock down barriers (servant leadership model)
  • Lean bureaucracy
  • Emphasis on test and verification
  • Constant refactoring
  • Frequent CI (integration and regression verification with prior results)
And, among the agile practises that are "OUT"
  • Definite narrative of what's to be accomplished (Nylon was an accident)
  • Product architecture
  • Commitment to useful product every period
  • Intimate involvement of the user/customer (who even knows who they might be when it is all "DONE"?)
There may be a longer list of "OUT"s, but to my mind there's no real challenge to being agile and doing R/D.

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

Monday, March 12, 2018

The risk matrix - yet one more time!

In 1711 Abraham De Moivre came up with the mathematical definition of risk as:

The Risk of losing any sum is the reverse of Expectation; and the true measure of it is, the product of the Sum adventured multiplied by the Probability of the Loss.

Abraham de Moivre, 
De Mensura Sortis, 1711
 Ph. Trans. of the Royal Society

I copied this quote from a well argued posting by Matthew Squair entitled Working the Risk Matrix.  His subtitle is a little more high brow: "Applying decision theory to the qualitative and subjective estimation of risk"

His thesis is sensible to those that really understand that really understanding risk events is dubious at best:

For new systems we generally do not have statistical data .... and high consequence events are (usually) quite rare leaving us with a paucity of information.

So we end up arguing our .... case using low base rate data, and in the final analysis we usually fall back on some form of subjective (and qualitative) risk assessment.

The risk matrix was developed to guide this type of risk assessments, it’s actually based on decision theory, De’Moivres definition of risk and the principles of the iso-risk contour

Well, I've given you De’Moivres definition of risk in the opening to this posting. What then is an iso-risk contour?

"iso" from the Greek, meaning "equal"
"contour", typically referring to a plotted line (or curve) meaning all points on the line are equal. A common usage is 'contour map' which is a mapping of equal elevation lines.

So, iso-risk contours are lines on a risk mapping where all the risk values are the same.

Fair enough. What's next?

Enter: decision theorists. These guys provide the methodology for constructing the familiar risk matrix (or grid) that is dimensioned impact by probability. The decision guys recognized that unless you "zone" or compartmentalize or stratify the impacts and probabilities it's very hard to draw any conclusions or obtain guidance for management. Thus, rather than lists or other means, we have the familiar grid.

Each grid value, like High-Low, can be a point on a curve (curve is a generalization of line that has the connotation of straight line), but Low-High is also a point on the same curve. Notice we're sticking with qualitative values for now.

However, we can assign arbitrary numeric scales so long as we define the scale. The absence of definition is the Achilles heel of most risk matrix presentations that purport to be quantitative. And, these are scales simply for presentation, so they are relative not absolute.

So for example, we can define High as being 100 times more of an impact than Low without the hazard of an uncalibrated guess as to what the absolute impact is.

If you then plot the risk grid using Log Log scaling, the iso-contours will be straight lines. How convenient! Of course, it's been a while since I've had log log paper in my desk. Thus, the common depiction is linear scales and curved iso-lines.

Using the lines, you can make management decisions to ignore risks on one side of the line and address risks on the other.

There are two common problems with risk matrix practises:
  1. What do you do with the so-called "bury the needle" low probability events (I didn't use 'black swan' here) that don' fit on a reasonably sized matrix (who needs 10K to 1 odds on their matrix?)
  2. How do you calibrate the thing if you wanted to?
 For "1", where either the standard that governs the risk grid or common sense places an upper bound on the grid, the extreme outliers are best handled on a separate lists dedicated to cautious 360 situational awareness

For "2", pick a grid point, perhaps a Medium-Medium point, that is amenable to benchmarking. A credible benchmark will then "anchor" the grid. Being cautious of "anchor bias" (See: Kahneman and Tversky), one then places other risk events in context with the anchor.

If you've read this far, it's time to go.

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

Thursday, March 8, 2018

Time zone bubbles

Sometimes, it's the simplest ideas that are the most effective. In the IT production control world, "bubble charts" are a common artifice to show the workflow of various scripts, user/operator interactions, and programs that have to run in sequence, or with dependencies, or a particular time (scheduler), or "on demand".

Fair enough, but no news there.

Then I read a blog post by agile guru Johanna Rothman about time zone bubble charts. So simple, but so effective as a communications device for the distributed team. It's a simple image, suitable for the war room or the background on some far flung work station.

Johanna offers six ideas for dealing with the myriad issues of time zones and teams. She writes:
  • Show the timezone bubble chart to your managers so they understand what you are attempting to manage.
  • Share the timezone bubble chart, so all the team members can participate in selecting planning and standup times.
  • Share the timezone pain. Do not make only one person or only one timezone delegate always arise early or stay late.
  • Know if everyone needs to participate.
  • Ask people if they will timeshift. Make sure you ask in advance, so people can make arrangements for their personal lives.
  • Make sure people either have necessary bandwidth to participate at home or food and beds to participate at work, if they need to participate outside of normal work hours
My experience was [India west coast (UTC +5:30)] to [US East coast (UTC -5)]. That's 10:30 hours difference in time, and not all that uncommon among software teams.

Here's what we did:
  • Dedicated phone room with open line for about 4-6 hours per day (anyone could walk in and talk or set up an offline conference)
  • Time shift (mostly by the India workers)
  • Alternate early/late conferences so that both US and India shared the inconvenience
  • Real-time document sharing via shared resources
  • Teleconferences by video on a case by case basis. (We didn't have Skype or Facetime at the time)
  • More care with documentation to compensate for ESL (English as second language)
Hey! you can make it work

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

Monday, March 5, 2018

Stoy-splitting mistakes

Mike Cohn is a guy I respect for his practical experience which he uses to leaven (*) the theory of agile methods. To that end, consider his approach to not being too slavish to the construct of stories the first time they are written, to wit: it's sometimes necessary to split a story.

But: mistakes can be made. To avoid the most commonly made mistakes, Cohn's advice:

" ..... story splitting should be viewed as a whole-team activity. That doesn’t mean the whole team has to be involved in every split. Rather it means that splitting isn’t delegated to one or two people on the team who do it for every story."

Story splitting boundaries should be functional rather than technical in order that there be user value in the split story. Cohn: "A good story is one that goes through an entire technology stack. Or at least as much of that technology stack as is needed to deliver the feature. Stories split along technical boundaries gives us stories that don’t deliver any value to users on their own."

Stay functional. Focus on the functional "what" and not the technical "how" in stating the story narrative.  "Including the solution within a story tends to happen when stories are being split too small. Once a story gets to a certain small size, there isn’t much more to say about the story and implementation details start to creep in when they shouldn’t."

Don't overuse the spike. " ... the mistake some teams will make is becoming over-reliant on spikes. ...
Spikes are most useful when a story includes an excessive amount of uncertainty, and when the team and product owner agree that uncertainty should be reduced before implementing the story."
(*) leaven:
an agency or influence that produces a gradual 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

Thursday, March 1, 2018

When Normal is normal

This posting by Jurgen Appelo, "The Normal Fallacy", takes on both misconceptions and lazy thinking, and reinforces the danger of thinking everything has a 'regression to the mean'.

Before addressing whether Appelo's explanation of a fallacy is itself fallacious, it's worth a moment to review:
Complex systems differ from simple systems from the perspective of how we observe and measure system behaviour. 

It's generally accepted that the behaviour of complex systems can not be predicted with precision; they are not deterministic from the observer's perspective.

[I say observer's perspective, because internally, these systems work the way they are designed to work, with the exception of Complex Adaptive Systems, CAS, for which the design is self-adapting]

Thus, unlike simple systems that often have closed-form algorithmic descriptions, complex system are usually evaluated with models of one kind or another, and we accept likely patterns of behaviour as the model outcome.  ["Likely" meaning there's a probability of a particular pattern of behaviour}

Appelo tells us to not have a knee jerk reaction towards the bell-shaped Normal distribution.  He's right on that one: it's not the end-all and be-all but it serves as a surrogate for the probable patterns of complex systems.

In both humorous and serious discussion he tells us that the Pareto concept is too important to be ignored. The Pareto distribution, which gives rise to the 80/20 rule, and its close cousin, the Exponential distribution, are the mathematical underpinnings for understanding many project events for which there's no average with symmetrical boundaries--in other words, no central tendency.

Jurgen's main example is a customer requirement. His assertion: 
The assumption people make is that, when considering change requests or feature requests from customers, they can identify the “average” size of such requests, and calculate “standard” deviations to either side. It is an assumption (and mistake)...  Customer demand is, by nature, an non-linear thing. If you assume that customer demand has an average, based on a limited sample of earlier events, you will inevitably be surprised that some future requests are outside of your expected range.

In an earlier posting, I went at this a different way, linking to a paper on the seven dangers in averages. Perhaps that's worth a re-read.

So far, so good.  BUT.....

Work package picture
The Pareto histogram [commonly used for evaluating low frequency-high impact events in the context of many other small impact events], the Exponential Distribution [commonly used for evaluating system device failure probabilities], and the Poisson Distribution, which Appelo doesn't mention, [commonly used for evaluating arrival rates, like arrival rate of new requirements] are the team leader's or work package manager's view of the next one thing to happen.

Bigger pictureBut project managers are concerned with the collective effects of dozens, or hundreds of dozens of work packages, and a longer time frame, even if practicing in an Agile environment.  Regardless of the single event distribution of the next thing down the road, the collective performance will tend towards a symmetrically distributed central value. 

For example, I've copied a picture from a statistics text I have to show how fasts the central tendency begins.  Here is just the sum of two events with Exponential distributions [see bottom left above for the single event]:

For project managers, central tendency is a 'good enough' working model  that simplifies a visualization of the project context.

The Normal curve is common surrogate for the collective performance.  Though a statistician will tell you it's rare that any practical project will have the conditions present for truly a Normal distribution, again: It's good enough to assume a bell shaped symmetric curve and press on.

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

Monday, February 26, 2018

Process breakdown structure

A coffee shop discussion on process redesign and process improvement led me to state the obvious to my caffeine-charged debaters:

Managers responsible for the business buy results [and outcomes], not process. Process, by itself, does not sell well; what sells is results.

Process per se is a tool.  For the most part, business people hire experts for their ability to deliver results; what tools they use are somewhat immaterial [to the business person]. The same for process redesign: the design per se is not the objective; the objective is better business results.

To help the discussion along, I postulated a "process breakdown structure", an obvious play on the WBS (Gasp! WBS! I can hear the agiliers running away .... come back! It's ok)

Of nouns and verbs
Just like a WBS is an organization of 'nouns' [outcomes or deliverables] that beget 'verbs' to explain the "how" of it, so also in a PBS

The PBS is fundamentally 'nouns'....outcomes of the process....arranged  like a WBS.  The PBS has elements of hierarchy--parent/child--and relationship [example: we all have a temporary relationship to each other because we are all engaged in this blog...I wrote it and you're reading it]

The first process improvement is to do away with nouns that aren't valuable.  Lean out the clutter and reduce the complexity

And just like for a WBS, for every noun there is a verb: the activities of the process.

Sequencing the verbs
We all know there is no schedule or time dimension to a WBS.  It's as if the WBS is the 'present value' of the schedule results; all deliverables brought back to the present.  Thus, sequencing has to be done elsewhere, and that is usually in the schedule

So also in a PBS: for each noun there is a verb, but the repository for verbs is the process activity list.  Take the nouns from the PBS and verbs from the process list, and you can just about write the narrative of the process.

Just add to the nouns and verbs the sequencing, durations, and dependencies that are properties [adverbs and adjectives] of the activities in the list.  String them out in a network and you then have the process in the usual format.

Resource the verbs
Verbs require resources. Minimizing the resources; leaning out the non-value verbs and sequences that consume resources; and resolving dependencies that add more friction than value is the way to improve the process.

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

Friday, February 23, 2018

C.R.A.C.K. customers

Barry Boehm on the C.R.A.C.K. Customer

Dr. Barry Boehm, a noted software methodologist with a long and illustrative career at TRW, DARPA, and USC, and author of the COCOMO model and Sprial methodology, writes about the ideal customer for agile projects. They are:

-- Collaborative: they will engage with their customer peers and with the development team
-- Representative: they know the product or system requirements and can represent their constituents accurately
-- Authorized: they can make the decisions needed to keep velocity up, and their decisions stick!
-- Committed: they take their job seriously and make every effort to advance project success
-- Knowledgeable: they can understand what the developers are telling them in the context of the business or market situation.

Take a look at other Boehm'isms on agile in his book, with Richard Turner, "Balancing Agility and Discipline: a guide for the perplexed", published by Addison-Wesley in 2004

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

Tuesday, February 20, 2018

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

Friday, February 16, 2018

Illuminating the path

Here below I shamelessly reprint a posting from herdingcats.
Why? Because Glen's point about the purpose of plans is to illuminate possibilities; not to constrain critical thinking, common sense, and accommodation for changing facts, is profound.  Everyone who practices project management or team management should understand that.

From herding cats:
In the space of two days I had evolved two plans, wholly distinct, both of which were equally feasible. The point I am trying to bring out is that one does not plan and then try to make circumstances fit those plans. One tries to make plans fit the circumstances 
George Patton
General, U.S. Army

"Any suggestion that plans and planning are not part of project management, no matter the approach - agile or traditional - wilfully ignores the purpose of a plan. That purpose is not the force the team to follow a path, but to illuminate the possible paths that can be followed to reach the goal."

end quote (emphasis added)

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

Sunday, February 11, 2018

Organization v management

We organize with hierarchies; we manage through networks
 More or less, that idea is the theme of historian Niall Ferguson's book "The Square and the Tower".

Simply said, the orgainizing principle of bureaucracy is the hierarchy  -- span of control; process flow-down; interchangeable people (to an extent) such that no one is indespensible -- everyone ages out!

But effective management more or less ignores the organization chart. Effective management reaches and influences any and all who can make a difference.

Hierarchy is way too restrictive for effective management; it promotes stovepipes and "we/they" stresses that are not value-additive. And, it's one dimensional: command and control. Networks, on the other hand:
  • Are multidimensional: cultural, financial, personal, professional, political (and, all of the above)
  • Are fluid with circumstances
  • Respond to multiple cultures -- virtual, domestic, foreign, business
  • Convey power in multiple ways: real power (hierarchy); associative power (who you know, and how well you know them); cultural or personality power
  • Facilitate promotion: way more people get to know you  
"They" say: if you can't effectively network, you can't expect to be influential and consequential. "They" are probably right

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

Thursday, February 8, 2018

Accurate v Fairness

Do you use a lot of data in your project? Most everyone does.
Things to keep in mind:
  • All data has some bias(es) built in
  • Because it's objectively accurate doesn't make it acceptably fair
Bias in data
There are library shelves full (or virtually full at library websites) of papers explaining biases that get built into data, even if unwittingly. Kahneman and Tversky probably have some of the best reading on this subject. Factors:
  • (Planning) Experiment design flaws
  • (Collection) Measurement and counting method error sources
  • (Collection) Expectations influences on observations
  • (Analysis) Statistical errors and data selection errors (bias)
  • (Interpretation) Framing to make a point
Accuracy v Fairness
You probably ran into this in school: grading on the curve. Grades were objectively one thing, but in fairness--we are told--grades posted were something else.

What's fair isn't what's accurate, necessarily
Fairness is about impact--what the downstream causation and consequences are for having applied data results to an issue. When people are in the loop, all the harder: race, class, win-lose, antimosities.

In the project office, the first instinct is (or should be) objectivity.

Risk management
But then objectivity meets management goals (*), and before you know it, we're back to "grading on the curve". If "fair" and "accurate" are not the same, then there is a gap. And, what is the nature of this gap? Risk! And, who is the risk manager? The PMO, naturally

(*) Political, humanitarian, economic, social justice, or competitive factors enter the picture.

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