Backlog blocked?

---

Yikes! My backlog is blocked! How can this be? We're agile... or maybe we've become de-agiled. Can that happen?

Ah yes, we're agile, but perhaps not everything in the portfolio is agile; indeed, perhaps not everything in the project is agile.

In the event, coupling the culprit

Coupling? Coupling is system engineering speak for transferring one effect onto another, or causing an effect by some process or outcome elsewhere. The coupling can be loose or tight.

• Loose coupling: there is some effect transferrence, but not a lot. Think of double-pane windows decoupling the exterior environment from the interior
• Tight coupling: there is almost complete transferrence of one effect onto another. Think of how a cyclist puts (couples) energy into moving the chain; almost none is lost flexing the frame.

In the PM domain, it's coupling of dependencies: we tend to think of strong or weak corresponding roughly to tight or loose.

The most common remedy is to buffer between effects. The effect has to carry across the buffer. See Goldratt's  Critical Chain method for more about decoupling with buffers

But buffers may not do the trick. We need to think of objects, temporary or permanent, that can loosen the coupling from one backlog to another (agile-on-agile), or from the agile backlog to structured requirements (agile-on-traditional).

With loose coupling, we get the window pane effect: stuff can go on in environment A without strongly influencing environment B; this is sort of a "us vs them" approach, some might say stovepiping.

Obviously then, there are some risks with loose coupling in the architecture that bear against the opportunity to keep the backlog moving, to wit: we want to maintain pretty tight coupling on communication among project teams while at the same time we loosen the coupling between their deliverables.

There are two approaches:

• Invent a temporary object to be a surrogate or stand-in for the partner project/process/object. In other words, we 'stub out' the effect into a temporary effect absorber.
• Invent a service object (like a window pane) to provide the 'services' to get from one environment to another.

Of course, you might recognize the second approach as a middle layer, or the service operating system of a service-oriented-architecture (SOA), or just an active interface that does transformation and processing (coupling) from one object/process to another.

With all this, you might see the advantages of an architect on the agile team!

---

What more on agile? Available now! The second edition .........

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

Program success probability

---

Glen Alleman has a posting that links to John Higbee's presentation about "Program Success Probability".

On page 5 of Higbee's slides, you'll find this image:

I find this cognitively satisfying: all is in order as my German friends would say. It's a risk register of sorts. On the right are all the external factors/metrics that have material impact; on the left side are the internal risks and issues.

This presentation is intended as a dashboard. The colors are dynamic on a Red-Green-Yellow-Gray (not evaluated) scale. The scale has to be defined (calibrated) for each program in order for management to be able to get a proper take-away.

Trends are shown in each block with arrows. Again, trends must be defined for each program, i.e. what is the meaning for an up-pointing arrow?

Of course, Higbee goes on in the presentation with more detail and more examples of dashboard presentations, for example the more-or-less standard presentation of sliding bars to show progress vs plan

Since this presentation is for a government audience, it includes dashboards for contractor performance and even contractor business success (P/E ratios, for goodness sake... does the market really affect contractor performance?  If the P/E is in the tank, there are probably other more pressing problems)

Bottom line: an interesting suggestion for dashboards are in this presentation, along with at least one gov'y's idea of what's important.

---

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

The Change Curve

---

I ran into a blog item on change the other day, at a blog site called Rule of Thumb.

The posting entitled "The Change Curve", depicts a project management adaption of the change model proposed by Elisabeth Kubler-Ross in her book "On Death and Dying" when she described the "Five Stages of Grief"

Rule of Thumb proposes this adaptation for project management of the Five Stages into these six ideas:

•Satisfaction: Example – “I'm happy as I am.”
•Denial: Example – “This isn’t relevant to my work.”
•Resistance: Example – “I’m not having this.”
•Exploration: Example – “Could this work for me?”
•Hope: Example – “I can see how I make this work for me.”
•Commitment: Example – “This works for me and my colleagues.”

Of course there are many other models of both change and change resistance. One useful model of change (not change resistance) is by Kurt Lewin; I like it because it's similar to Deming's PDCA (plan, do, check, act). Lewin's model is three steps:

1. Unfreeze previous ideas, attitudes, or legacy
2. Act to make the change
3. Freeze the new way in order to institutionalize the change.

And, A.J. Schuler, a psychologist, has his 10 reasons about why change is resisted in a paper entitled "Overcoming Resistance to Change: Top Ten Reasons for Change Resistance". His lead-off idea is "doing nothing" is often perceived as less risky than "do something"--in other words, Plan A (do nothing) trumps Plan B (do something). 

But the one I like is that people fear the hidden agenda behind the reformers ideas! Amen to that one.

---

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

Leadership -- introverted

---

The introverted leader: is this an oxymoron? In my experience: definitely not. And, my experience aligns well with Susan Cain's popular book Quiet: The Power of Introverts in a World That Can't Stop Talking

And by introverted, we mean: Someone who gets more energy out of quiet time--loner time, even if in an open plan--than they do mixing in a group. Indeed, mixing in a group discharges an introvert. An extrovert is just the opposite: they discharge during loner times and charge up by absorbing the energy of the crowd.

My definition certainly doesn't mean an introvert is paralyzed by public speaking, can't socialize, or draw from a group/team/crowd. Far from it: some introverts are quite eloquent in public, very approachable, and get a lot from a group experience.

I like to talk about the professional extrovert and the private introvert. Extroverts are often the rewarded ones, the admired, and the influential. So, priviate introverts train themselves to be extroverts.

In the professional setting, you may be hard pressed to pick out the introverts until you notice who leaves first: they do. When they become discharged, they simply leave to get the recharge from the loner setting.

And, they can be good leaders. James T. Brown writes (in his book "The handbook of program managment") that to be a good leader, “a program manager needs to have an ingrained sense of organizational mission, must lead and have the presence of a leader, must have a vision and strategy for long-term organizational improvement, must be a relationship builder, and must have the experience and ability to assess people and situations beyond their appearances.

PM Brown says nothing about being a natural extrovert, a professional extrovert, or really anything of personality, except for "presence of a leader". In other domains, this is called "command presence", the aura of confidence that naturally attracts those looking for direction, safety, order, and back-up.

 "They" say that some of our most notable Presidents of the US  have been introverts....a job that requires an extraordinary public appeal--usually a bane of introverts--to get elected in the first place and remain politically popular and influential once in office. If so...my case is made.

---

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

Did I mention: no more self-organizing teams?

---

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 has an excellent counter-point blog, except he 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 nemisis 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.

---

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

Kano analysis and Agile

---

Kano analysis is a new product feature/function evaluation tool that gives visualization to feature/function relative merit over time as trends change. The usual presentation is a four-sector grid with trend lines that connect the sectors.

The grids are defined by the horizontal and vertical scales that are easily set up on a white boad in the war room (don't take the word 'scale' too seriously; for the most part this is uncalibrated opinion):

• Vertical: customer attitude
• Horizontal: some quality (or metric) of the feature/function that's important to the customer.

The trends need not be linear, and need not be monotonic, changing direction as customer/user attitudes change (Again, an equation can be defined for these lines, but the focus here is not on the exact formula of the line, just the general notion).

Agilists use the Kano board with sticky notes to show how feature/function in the form of stories might play out over time.

 And, we take the trouble to do this because:

• There's only so much investment; it needs to be applied to the best value of the project. Presumably that's the "ah-hah!" feature, but the "more is better" keeps up with competition; and, some stuff just has to be there because it's expected
• Trends may influence sequencing of iterations and deliveries. Too late, and decay has set in and the market's been missed.
• The horizontal axis may be transparent to the customer/user, but may not be transparent to regulators, support systems, and others concerned with the "ilities". Thus, don't forget about it!

Now, wouldn't you like to have been a fly on the wall in the Apple war room a few years ago when they debated doing away with the floppy drive; or, more recently, the spinning disc. I wonder how they drew the trend lines and made their investment decisions?

How far ahead of the trend can you be and not be too far ahead? Just a rhetorical question to close this out.

---

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

Only do what only you should do

---

"...He only does what only he should do"

Anonymous

The utter simplicity of this thought is its power: "He only does what only he should do". What else is there?

But, though simple as it is, this statement is a source of constant frustration to those being micro-managed. Why can't "he" (and, not to leave out 'she') just go away and let us get our job done? Perhaps he/she doesn't have enough to do, or worse: he/she doesn't know what to do.

Maybe we should make it more complicated so that "he" will pay more attention. Let's cite the Principle of Subsidiarity :

---

It is a fundamental principle of social philosophy, fixed and unchangeable, that one should not withdraw from individuals and commit to the community what they can accomplish by their own enterprise and industry

---

The 'community' in this case is the project office and the project manager; or the portfolio office and manager. Or worse: the project sponsor and (aghast!) the stakeholders. (Who among us wants to managed by the stakeholders? ... barbarians at the gate, to be sure!)

Here's the general idea and criteria of 'good' un-delegation:

• The action (un-delegation) must be necessary because actions of individuals or teams alone will not achieve the objectives of the action (the sufficiency criterion)
• The action must bring added value over and above what could be achieved by individual or teams alone (the benefit criterion).
• Decisions should be taken as closely as possible to the project team or individual (the close to the individual criterion)
• The action should secure greater freedoms for the individual (the autonomy criterion).

Sufficiency, benefit, closeness, and autonomy: Words to delegate by!

---

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

What is this Monte Carlo thing?

---

For many years, I've preached the benefits of the Monte Carlo simulation (MCS). For many reasons, it's superior to other analysis paradigms. In network analysis, for instance, it handles the parallel join or 'gate' as no other method will.

In fact, it's this very capability that renders the Monte Carlo superior to other risk adjusted ideas, like the PERT method in scheduling. PERT suffers from an inability to handle the 'merge bias' at gates because PERT does not handle the mathematics of multiplying distributions (required at gates); PERT only provides a means to calculate a statistic for each task.

Architecturally, gates are the weakest construct in schedules, so any failure to handle them is a show stopper in my mind

Quantitative methods schedule from John Goodpasture

But, my students ask me invariably: how can the MCS be any better than the 3-point estimates that go into it; if the 3-pointers are guesses, isnt' the whole MCS thing just a crap shoot?

And, the second thing they ask is: who's got the time to triple the estimating problem (from the most likely single point estimate to the trio of optimistic, pessimistic, and most likely) especially in a network of many hundreds, if not thousands, of tasks?

My answer is this: it depends; it depends on whether or not your are the work package leader concerned for a handful of tasks, or the project manager concerned for a network of hundreds (thousands in some cases) of tasks.

If the former, then you should not guess; you should take the time to consider each estimate, based on benchmarks, so that each estimate is has some auditable calibration to the benchmark.

But if the latter, then let the Central Limit Theorem do the work. A few bad estimates, indeed a lot more than a few in most cases, have negligle impact on the MCS results. In other words, the good, the bad, and the ugly tend to cluster around a central value--a phenomenon called central tendency. Thus, at the PM level, you can live without completely solid calibration. Only a few estimates need to be pretty well thought out vis a vis the O,P,ML triplett.

This may sound like heresey to the calibration crowd, but as a politician recently said: arithmetic! Actually, calculus is the better word, since we have to deal with functions. And it's calculus that gives us the tools to understand that a few bad estimates, even really bad estimates, are largely discounted for effect by the integrated effects of all the other estimates. So, let's not get uptight about a few bad eggs!

Nevertheless, to do a MCS, you do need estimates of O, P, and ML. Where do they come from?  All the tools allow for defaulting in a trio to every task. Is that a good idea?

Here's my counsel:

• Take the time to estimate the most likely critical path. The MCS tool will identify other near-critical paths, and may even find an alternate path that is critical (not the one you thought)
• Establish, in the risk management plan, a policy about the defaults values (for % of ML)
  The policy may have several elements: hardware, software, administration, and process tasks. Each of these will have hard, medium, and easy tasks.
  The policy can be a matrix of O, ML, and P defaults for each (Example: for hard software, the policy is to estimate O = 80% ML and P = 200% ML).
  These generally come from experience, and that means from actual results elsewhere, so the defaults are not just picking values out of thin air....there's usually back-up

---

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

Agile Phases

---

In the beginning, there was pre-history Agile, almost prehistoric era:

• Before 2000 and the meeting in Utah that birthed modern Agile
• Rogue developers trying various "light weight" and "rapid" prototyping and coding practices. In the SEI world, a ghastly level 1 operation of different strokes for different folks
• Everyone else slaving to command and control -- SEI maturity model uber alles!

And then came the 'our way or the highway' era

• Passionate, almost hysterical, disciples of the paradigm handed down from the Utah mountain
• There is no God but the one Agile God
• "You just don't get it" if you question us
• Push back from the money crowd: "I'm not going to put money into something that has no plan"

And now, the common sense era

• Distinguished Agilists are writing and coaching for the real world where every sprint does not put code into production (shocking!)
• Every deliverable with value is not necessarily code (imagine! other stuff has value-add)
• You're actually allowed to not have a retro session after every sprint; some stuff does not need to be completed after every sprint
• The product owner and customer/user can be surrogates for large organizations
• Plans can be drawn, and a business case for the money guys!
• Stories can be detailed out as requirements

What will they think of next?

---

What more on agile? Available now! The second edition .........

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