Change bandwidth

---

Author Jason Bloomberg wrote: "It's human nature when faced with a chaotic environment ... to filter out most of the noise to focus on a single trend. The resulting illusion of stability gives us a context we can understand. But it's still an illusion."

Others have said that to permit innovative change, particularly destructive innovation, the filters must come off to permit rapid and "out of the box (filter) responses"... you can't work change (or see enough context) through a straw, as it were.

It's a matter of physics: if you put a sharp change through a somewhat narrow filter, then what you get out is somewhat smeared bell-shaped response with gradually changing shoulders, thus damping the effect of the change. And, you get a delay as the input energy has to move through the filtering effect.

Consequently, the output is a poor facsimile of the input, and it's late!

The problem we see in the organizational change business is that if there is a sudden big shift in the business environment (or public attitudes that could affect the public or non-profit sectors), the business sees the big shift after it's exited the filter. If the filter is narrow, the delay will be significant (inverse to the bandwidth) and, if the filter is really narrow, the information at the filter output will be distorted. The effect, as Jason describes, is to continue the status quo (an illusion due to filter delay) ...  [and] miss the outset of a big change.

Consequently, the business may be too late, and  may even bring a basketball to the football game: (distortion effects). See "Microsoft misses the mobile revolution" for an example. 

---

Bookmark this on Delicious

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

Product owner's council

---

I got this idea from a student; I think it has merit, so I'll pass it along here:

Our backlog is managed by our Product Owners Council, made up of 7 voting members representing the users in the global markets. The voting members are responsible for translating their constituent user requirements into user stories for review by the council.

The council members bring their user stories to council meetings where they are reviewed using a specified criteria before admission to the backlog. We have a large backlog that is prioritized by the POC for each release based on the velocity the development team can deliver, usually 100 points per sprint per scrum team - there are multiple sprints and scrum teams per release.

.... in our case, there are constant trade offs taking place in what gets developed from the backlog. When functional requirements are the focus of a release, the POC meetings become very political with each member arguing for their backlog of stories. The final vote includes a consolidated view from each POC member on the user story's impact on our customer, regulatory environment and user productivity along with a hi, medium, low ranking.

When the global deployment was in progress, all user stories that enabled the countries to go-live on the system where prioritized ahead of functional requirements, including some less critical defects.

Our current direction from executive stakeholders is to standardize our cloud based systems and any requirement that enables the standardization will have precedence over functional requirements.

---

Bookmark this on Delicious

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

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).

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 "Brooks Law" named after famed IBM-370 project leader Fred Brooks: "Adding people to a late project makes it later" . Read: "Mythical Manmonth" for more from Brooks

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. Many have told me: 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. The problem arises with sponsors: their answer is universally: throw more resources in, exactly opposite the correct remedy

One of my students said this: "Daniel Pink  has an excellent book called "Drive" 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."

---

Bookmark this on Delicious

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 agile kitchen project

---

A traditionalist asked me: can you build a new house, and deliver the kitchen with agile methods?

Hmmm, how about this plan?

You could break up a house delivery into major constituents that could be agile deliverables.

Of course, the first thing is to architect the narrative (vision), then apply reasonable rules of system engineering to ascertain where the best interfaces should be between modules. And then separate backlog by non-functional and functional, honoring common sense sequencing rules/constraints like walls before roof.

Only then should you apply an agile method to something like a kitchen. First, there would likely be storyboards rather than text stories on cards to illustrate the look and appeal of the kitchen... counter tops, cabinets, appliances, lighting, etc. Then, with look-and-feel and interfaces specified, you could have a cabinet team, counter top team, appliance team all go off and do their thing... In the physical domains, work segregation is common because of capital facility requirements. Take a look at any cabinet factory and you would get the idea.


The "user" or product manager could certainly weigh in during the kitchen development, changing some things like wall color. But if the cabinetry is to be changed, then the whole house backlog has to be in the trade space... give up a bathroom to get the cabinets changed, etc. Anyone who has built a custom home has gone through this trading process... .

So yes, you could deliver the kitchen while the rest of the house is still less developed, given that all system and interface constraints are observed: power, water, etc. foundation backlog in place.

Now, could the user actually use the kitchen: No, permitting requires certificate of occupancy, and that requires a good deal more of the house to be delivered.

But, the kitchen is DONE, if it not operational for actual cooking

---

Bookmark this on Delicious

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

Muscular risk management

---

Muscular risk management:

"Long experience has taught me to evaluate and assess. When the unexpected gets dumped on you, don't waste time.  Don't figure out how or why it happened. Don't recriminate. Don't figure out whose fault it is. Don't work out how to avoid the same mistake next time. All of that you do later.... Identify the downside. Assess the upside. Plan accordingly. Do all that and you give yourself a better chance of getting through to the other stuff later"

Jack Reacher, Major, Military Police

as written by Lee Child

---

Bookmark this on Delicious

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

A world without Statistics?

---

A world without statistics? Can you imagine it? Probably so, because most of the PMs I run into my advanced risk management course have no knowledge of statistics beyond a coin toss.

So, along comes this article from a learned organization, entitled "A world without statistics", and I had to take a minute to breeze through it. And breeze through you can... it's actually  light reading... and no math!

We get this kind of stuff:

• Science would be pretty much ok. Newton didn’t need statistics for his theories of gravity, motion, and light, nor did Einstein need statistics for the theory of relativity.
• Thermodynamics and quantum mechanics are fundamentally statistical, but lots of progress could’ve been made in these areas without statistics. 
• The A-bomb and, almost certainly, the H-bomb, maybe these would never have been invented without statistics, .....
• Without statistics, we could forget about discovering the Hibbs boson etc, but that doesn’t seem like such a loss for humanity.
• Without statistics, we wouldn’t have most of the papers in “Psychological Science,” but I could handle that
• Polling. Can’t do it well without statistics. But, would a world without polling be so horrible?
• Could governments and large businesses be managed well without statistics? I’m not sure. .... it’s not clear than any agreement on the numbers will have much to do with political action

My nickel on this? No, we need statistics to make projects work, even if we don't understand why. Start with the lowly average... can you imagine doing without the concept of an average? And, it goes on from there... Monte Carlo simulations, 3 point estimates, sampling large data... etc and so on. Statistics: yes we do!

---

Bookmark this on Delicious

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

Release sign-off in Agile?

---

Should there be a release sign-off when applying agile methods? Sure, perhaps even: of course!
But.. doesn't this taint agile with bit of bureaucracy (gasp!)

Actually, yes. But here's how it happens as lean as possible.

First, of course, we've got the backlog which has emerged in some ways... partly planned (see agile business case), partly consequential (as in technical debt) and partly by epiphany (OMG! that's it; I see it now)

Second, we've assembled the team which includes a product manager or customer/user surrogate to parse the backlog into some number of chunks, commonly called iterations, and we've planned to assemble all the deliverables pertaining thereto into a common release. Note at this point we got ourselves a release plan: Scope, schedule, and resource needs

Now the tricky part: who needs to approve this (aka, sign off)?
It depends...
And, here's where the (value added) bureaucracy comes in:

• Is it just going into the code base, or going into business production
• If going into business production, it is just a bug fix or new functionality?
• If new functionality, is it user facing?
• And, if user facing, is it intuitive or is training and formal rollout needed?

Now, you might guess that I'm leading you to the sign-off manager.

• For the first bullet: perhaps only a team leader or section leader or CM person who coordinates all the supporting scripts.
• For the second, perhaps an IT manager
• For the third: perhaps a business manager and an IT manager
• For the fourth: now we get a bigger dose of sign-off: HR for training, business managers for processes and rollout, and IT for code base.
• And, their might be regulators! -- medical systems come to mind, but so also banking, safety systems, etc.

You ask: is this agile; is this lean? Yes, actually it is. It's the way agile marries up the real organization

---

Bookmark this on Delicious

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