That "trust" thing... again!

---

Here's a point about trust that recently arose in my agile class.  A student said traditional methods lack trusting relationships, whereas agile teams are more likely to embrace trust.

Maybe/probably so; history would be seem to be on the side of the student

Consider the  theory of "Management Science", as developed in the early industrial age around 1915 by Fredrick Taylor.  Taylor -- and his disciples -- held that all jobs could be described by a "job description" and that any qualified person could be plugged in -- so long as they were not "a square peg for a round hole" Thus: plug and play staffing.

(Aside: I took the name of my company -- Square Peg Consulting -- from the problems I observed trying to be a good "Taylorist" in the Defense and Intelligence domains in the 80's)

And, because these plugs were largely anonymous to management, bureaucracy was invented to contain and direct work, more or less anonymously, via protocols and policies -- No trust required!

Just follow the rules, or perish.

Along comes agile and replaces large scale bureaucracy with trust!  What a concept! Now, admittedly, trust is hard to scale -- requires personal knowledge in the main. So, as scale increases, trust and bureaucracy trade places.

The trend du jour is "flat" organizations and open space. Why? To get back to the virtues of a small scale -- trust and agility -- with a large organization. If everyone has to gather by a common water cooler, by and by people will get to know one another.

Steve Jobs famously put the only rest room at Pixar in the Atrium... everyone had to go there by and by. Agilist Alistair Cochburn calls this communication by "osmosis"... absorption due to being the same place.

---

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

Writing a proposal -- a checklist

---

Most of us don't write books -- this blogger excepted -- but many of us have to write a proposal to win business, or even win a job. And then, if you're on the job, there may be myriad presentations and documents to deal with.

Smart PMOs put some of us on red teams -- the independent reviewers. So, how about a checklist to guide the work along?

At Jurgen Appelo's NOOP.NL I recently saw just the thing -- though it was presented as a checklist for writers generally -- presumably books, but certainly applicable -- with a few modifications -- to almost anything you're writing.

Appelo posits four stages:

1. Brain dump for what you want to say -- Let me add: draw up some storyboards... If you can't draw it, you probably can't write it!
2. Shaped version for sharing with only your best friends
3. Polished version used for tweaking
4. Final version -- here, I offer a suggestion from my own experience: put the whole thing away for a couple of weeks. Come back to it and tweak/rewrite... you'll be surprised how different it looks from the vantage of a few weeks

If it's a paper your writing, then you'll need an abstract. And, I like to lead with an executive summary.  Add these to the checklist under Stage 1 of Jurgen's list

If it's a proposal, then you have to follow the sponsor's guidance or direction about what's to be in the proposal, but I can't imagine a proposal without an executive summary for the executive reader

And, if it's a proposal or a book, the publisher/sponsor may have author guidelines, style guides, trademark requirements, etc.... Add a look at these as a step in Stage 1.

If you're on your own, I still argue for the executive summary -- some call it a preface -- but thereafter, Jurgen's list is a good guide.

---

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

Team agile bloopers

---

Team agile bloopers from a practitioner's notebook:

We had 6 agile teams working to build a product. Each team was responsible for their component but they all needed to be integrated for the product.

1. We didn't get buy-in from 1 team to run agile. We had a team that agreed to follow agile but decided to go their own way. This caused many issues when we tried to do early integration as they were not ready. The remedy is to be more disciplined and bet buy-ins from all teams.

2. Didn't do a good enough job at task breakdowns. This is actually fine at the individual team level but needed a lot more work at the scrum of scrum level. The remedy is to develop a clear architecture and be more discipline to develop to the architecture.

3. Not discipline in our daily stand-ups. Not all teams followed this - those teams tend to have the most communication issues. The remedy is to require more disciplined adherence to daily stand-ups and complete buy-in of the agile process.

4. Inadequate time for reflection - I should have done a better job of adding buffer time for integration activities and for reflection. We were able to do reflection in some of the teams but not at the product level. This was due to some teams missing their iteration release. The remedy is to do better planning for system level integration.

5. Lack of product owner involvement - we had two customer development teams working along our teams. I thought that those customer teams would represent the interests of their product owners. It turns out that there was little communication between the real product owners and the customer's development teams. We were able to get to the real product owners but it was too late. The remedy is to identify who is responsible as product owners and require their involvement throughout the project.  

---

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

Hub and Spoke

---

On the HBR Blog Network, Andrew Shipilov has a eye-catching post on "hub and spoke" project networks, or alliances between project partners, as he describes them.

(Say "network" to me, and as an EE, I always jump first to a mind's-eye image of a "mesh", but actually that's one of several general ways to think of networks, and in most situations not a good general model for governance.)

Shipilov posits that simple hub-and-spoke arrangements in truly complex and challenging systems, with the prime contractor and an SI (system integrator) at the hub, inhibits critical interactions between the other partners, each of which is on a spoke. He attributes some project failures to this governance model.

What to replace it with? After all, hub-and-spoke is the essence of prime contractor command-and-control over the myriad partners, to say nothing of the legal details of who has privity of contract.

Shipilov recommends the "alliance network" wherein there are multi-lateral relationships for innovation, data exchange, and cooperation, not necessarily under the watchful eye of the SI (though, if the SI is on the ball, all the consequential stuff is known at the PMO)

About the alliance network, we are told there are these advantages:

"First, alliance partners are more likely to deliver on their promises.  If information flows freely among interconnected partners, how one firm treats a partner can be easily seen by other partners to whom both firms are connected. So if one firm bilks a partner, other partners will see that and will not collaborate with the bilking firm again.

Second, integrated networks facilitate fine-grained information exchanges because multiple partners have relationships where they share a common knowledge base. This shared expertise allows them to dive deep into solving complex problems related to executing or implementing a project."

Fair enough. But one caution: You can't be a control freak and sleep nights with an alliance network!

---

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

About complexity

---

Shim Marom has interesting post on complexity wherein he says this:

"A lack of an intellectual capacity to grasp a complex system is not a sufficient argument or drive for simplification.

If you artificially simplify a complex system you end up with a different system that, while simpler, is fundamentally and conceptually different from the one you started with and thus, simplification ends up with destruction."

So, what are we to do about a system we don't understand? Should we:

• Get a smarter guy to understand it for us? Possibly; we can't all understand the particle collider
• Design in some fail-safe stuff so that even a chaotic outcome is contained? Yes, fail-safe is always a good idea if you have the right assumptions (See: Fukushima, March, 2011)
• Design a different system altogether -- one that we can understand? Yes, that might be a good idea (See: HAL in 2001: A Space Odyssey)
• Do the destructive simplification Marom talks about?

A system engineer would say: "Yes" to all of the above, situationally, as required.

About destruction
I suggest that "destruction" could be the intended end-game insofar as if you can't understand a system you may not be able to control it, and certainly can't predict its behavior. So, "destruction" to a simpler device may be an important and required objective. Lord knows, we have enough stuff we don't really understand!

CAS is not for everyone:
Also, when discussing complexity, especially adaptive complexity, one must be careful not to cross domains: CAS in biological and chemical systems, and others like weather systems, is not a phenomenon we have to deal with in man-designed physical systems that operate within reasonable physical limits. To impute CAS properties improperly is one of the common errors I see.

---

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

Another entry for the agile practice dictionary

---

Jim Highsmith has defined CD -- continuous delivery cycle time -- this way, a practice you can add to your GAAP -- Generally Accepted Agile Practices:

Finally, the newest perspective, brought about in great measure by the advent of Continuous Delivery (CD), is that of cycle time. Furthermore, there are at least three versions of cycle time:

• Deployment frequency (days, weeks, x times per day),
• Feature cycle time (release from backlog to delivery), and
• Project cycle time (similar to planned versus actual).

Deployment frequency and feature cycle time are becoming very important performance metrics in our current era of CD. In fact, value and cycle time are rapidly replacing the Iron Triangle (scope-schedule-cost) as the critical metrics to use in building responsive systems responsively .....

Brother Jim may be a bit ahead with his last statement about critical metrics for "responsive systems". On that last term, I'm not sure it's made it to mainstream yet, but in an unrelated posting, my attention was drawn to this missive on building out a "responsive site":

---

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

What price complexity?

---

Complexity: the myriad interactions and influences between pieces and parts that gives rise to performance and functionality not discernible from just an examination of the pieces and parts

As an aside, keep the idea of complexity and complicated separated: Complicated is a bunch of stuff, but if the interactions are minimal, then something really complicated may not be too complex.

Three questions that should come to mind:

1. Are the effects of complexity in this project predictable?
2. Should we -- the PMO -- count on some effects always being amongst the unknowable -- and thus, unknowable risks? If so, how much reserve to set aside? 
3. How do we -- the PMO -- plan for the effects of complexity?

Fair enough: It's all well and good to have three questions, but here's the important point: You can't just end it here... Some action required! And, as you might imagine, this stuff doesn't come free.

So, here are a few answers:

To point #1:

• The only way to predict complexity is to build it or simulate it -- presumably at moderate cost and effort. Build it: prototype, or some such; simulate it: various action models, like a Monte Carlo, for dynamic behavior.
• Of course, in any simulation, some calibration is required, especially if a model is involved -- to wit: you don't want to have model artifacts mixed in with the real predictions.
• If the system is biological or chemical, then complexity may include dynamic adaptation, popularly called "complex adaptive systems" (CAS). Probably nothing but a small scale but fully functional prototype is going to do the trick
• If the system includes a "human-in-the-loop", then some of the CAS behavior may be in the offing... humans are very adaptive and quite unpredictable when not scripted. This where testing for error traps is really critical, because we humans do the damnest things! 

To point #2:

• In a word: Yes, especially if your project and its deliverables are complicated. Latent complexity is likely lurking! Of course, you can't be lazy about this. You should expend effort trying shed light on latent effects. Again, prototypes and simulations are the best tools.

To point #3:

• First, you don't want the project or the system to be fragile -- that is, unable to absorb shock. So, you need some redundancy
• Second, you don't want all the eggs in one basket where there could be catastrophic damage: thus, diversity (distribution of risk into independent containers or to independent actors -- and the stress in on "independent")
• Third, if the bad stuff happens, you want it contained: thus, loose coupling! (In the sailboat racing analogy, sailors build sails with "rip-stop" seams that contain a failure to one section of the sail. See also: Titanic, for watertight compartments, an example of the violation of the "independence" principle... there was coupling between compartments that was unforeseen)
• And last: there's a hidden cost: integration cost arising from complexity

There's not much point in raising these questions if PM's can't deal with them in some practical way day-to-day.  Recall my favorite way to get started with both architecture and estimates: the Box Model

---

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