Loyalty and Trust

---

From time to time, a profound thought strikes here at Musings. Today, it's a question:

Is it necessary for there to be trust in order that there be loyalty?
Can there be loyalty and simultaneously mistrust?

Spoiler alert: there's no right answer. It's a matter of your values and beliefs, for which there is no proof, validation, or algorithm.

So, where did this come from?

1. In my agile classes, we discuss the desirable/essential elements of leadership in the agile environment. The word trust comes up in almost every student reply; I don't recall 'loyalty' ever coming up (though I did search the archives), either as a quality looked for in a leader or expected to be given to a leader
2. I'm reading a new Winston Churchill biography. The biographers -- William Manchester and Paul Reid -- describe Churchill's relationship with Josef Stalin -- from 1942 onward when the USSR allied with the U.S. and Britain in WW II -- as mistrustful but loyal. I was really struck by that assessment.

So, back to the questions posed above; I think this:

•  I can be loyal to an institution (team, project, business unit, agency) without being trustful of its tactical leadership. However, if the mistrusted leadership is then strategic and becomes the strategy of the institution, then you lose me.
• At a personal level, I can't be distrusting and loyal to a person at the same time. At a personal level, trust and loyal have to go together.
• I think, without knowing, that WSC was loyal to the cause represented by the alliance with the USSR without being trusting of its leadership. I get it; it can work.

And, Mike Clayton has an excellent piece on 10 qualities of leadership -- but loyalty (given or expected) is not among them. So, another point of reference for those looking.

(Disclosure: I resigned an executive position in a large company when I could no longer trust a more senior executive and felt I could not be loyal to him, so that experience probably colors my thinking)

And, ONE MORE THING: you don't get the word 'respect' on leadership attribute lists. I wonder if trust-respect and loyalty somehow go together... could you possibly trust someone that you don't respect? Perhaps, one begets the other.

---

Bookmark this on Delicious

Check out these books I've written in the library at Square Peg Consulting

Agile in fragments

---

I've offered my opinion on "agile in the waterfall", but I'd not thought too much about agile in fragments, to wit: no co-location; little client participation; disjointed work; and low priority outcomes.

Sounds like a recipe for project failure for sure

However, along comes leadinganswers (a prominent agilist) with a piece entitled "agile for fragmented part-time teams". I had to read this one!

The main point of the article is that the backlog management ideas in agile can serve many project situations quite well, even those in which the project is part-time people doing "white space" tasks -- tasks of opportunity that fit in where they can.

There's hardly any commitment to schedule but that doesn't mean that there can't be a commitment to quality in whatever is delivered. And, it need not be software... backlogs work on hardware as well.

And, the agile idea that the team has to get together, even if virtually, on some periodic (schedule driven) or event driven occasion to review the bidding, progress, and problems also drives progress, albeit slowly.

There's more in the article, but the point is made: many agile practices can be used to good effect even if not in a contiguous and conventional project scenario.

---

Bookmark this on Delicious

Check out these books I've written in the library at Square Peg Consulting

The CIA looks at 'big data'

---

Following up on the meme of the day, to wit: 'big data', I came across the GigaOM conference on livestream.com. (free login required) The conference is long over, but they posted videos of all their sessions dedicated to 'big data'.

If you're an old hand at (intelligence) collection, you'll see the differences immediately between the cold war era and today.

However, the main point here is to look at this through the lens of project management, particularly those of us who've done a data sensor/processor, data warehouse, or a large scale ERP. You'll see some of your project technical and functional issues nicely illustrated.

First, the "never throw anything away" data issue -- bigger gets ever bigger:

And this -- Tom Friedman's "The world is flat" platform idea writ large:

And finally about "sensors", this snip -- think of a sensor as anything that can gather business data, business intelligence, or business metrics -- and you'll get a feel for the scope of the idea:

It's a 30min video; if you don't have that much time, the slides are at businessinsider.com:

---

Bookmark this on Delicious

Check out these books I've written in the library at Square Peg Consulting

Managing for value

---

One of my agile project management students said this:

My company will not allow us to start a job until we budget the revenue and plan for all costs. We are judged by how closely our projects come to the original planned budget.

To which I said this:

Being judged by the budget is being judged by input rather than output. Your sponsor will be disappointed often, even if you don't spend more than planned. Agile shifts the management to the value of the output which is far greater than the value of the input. Afterall, projects are a value multiplier: spend $10 on the project and get $1000 in business return, for example.

This whole idea of projects as a value multiplier -- as evidenced on the balance sheet if nowhere else -- is the theme of my most recent book (available in Kindle, ebook, and, of course, paper)

---

Bookmark this on Delicious

Check out these books I've written in the library at Square Peg Consulting

Agile and the System Engineer

---

When we're talking about system engineering, we're generally talking about "The big three ideas for System Engineering":

• Requirements
• Architecture
• Validation

There's certainly nothing incompatible with the Agile Principles or the Agile Manifesto among those three.

Let it be said: We're from System Engineering, and we're here to help.....



Really? What can SE do for we agilists?

• Requirements: It's true that SEs are accustomed to structured analysis, decomposition, and lots of 'shalls' and 'wills'. Nonetheless, motivation to do requirements -- to develop not only a narrative from the many disparate statements, but to also fashion an architecture that supports the whole collection of requirements -- fits the agile need nicely.
  
  The big transition for SEs is making the move from a traditional 'shall and will' project to an agile project of conversational style requirements. Now admittedly, some SE can't/won't make the transition, but others will, and their skills are very applicable
  
  SEs are good at elicitation, modeling, risk assessment, and logic... all necessary ingredients when working with use cases and user stories. Hopefully, you're familiar with some of Scott Ambler's stuff on agile modeling, etc... all system engineering, all day.

• Architecture: A close cousin to requirements is architecture -- structure, interfaces, large scale design, and interrelationships. The big deal here is allocating requirements to the major objects, defining the object relationships, and adjudicating conflicts that would compromise coherence, cohesion, redundancy, and diversification.
  
  
• Validation: Validation -- checking things with the customer -- is not that much different, except for timing: more early and more often in agile compared to the traditional. But why SEs in the validation? Mostly, to bring the big picture and largest scale to validate the architecture (lower level validation is largely a team effort with various layers of release tests and integration tests). Such big picture stuff reassures the sponsor, gets marketing fully on board, and if there's to be manufacturing or post release support, then those entities can get on as well.
  
  You've probably seen this V-model if you're a regular reader. It's basically the SEs view of how the project comes down. Validation just completes the loop with the original narrative (shown here as the Concept of Operations)

---

Bookmark this on Delicious

Check out these books I've written in the library at Square Peg Consulting

Lean in Orlando

---

Here in my hometown, they've discovered lean principles applied to construction:

The SkyHouse high-rise will top out in just a few weeks at 23 floors. If it stays on track, the building's 320 units will open ... only 13 months after the first dirt was shoveled aside. It takes that long just to build some custom homes.

The tower's builder, Batson-Cook Co., isn't pushing workers to rush; the job has gone quickly because of something called the "Lean" method, which is dedicated to ridding the construction process of waste, especially wasted time. Work schedules have been drawn so that nobody is left waiting on someone else

As the newspaper quote says, this project is going along in remarkably short time; and, the cost is reasonably under control.

And so what is the "lean method" applied to hi-rise construction? In this case the project manager adopted a unique schedule sequence for both task and resource.

The way we've always done it
The usual approach is to schedule each floor in a trade-craft driven sequence: first all the steel workers come in; then all the cement guys; followed by the plumbing and electrical, glass workers, and the like.

Another way to do it
In general, what they did was build each floor with parallel time boxes that align with different physical spaces, each time box/space centered on a particular trade. So, while the cement guys were working in one space on a floor in one time box, the electrical or plumbing guys were working on the same floor but in a different space in the same time box.

As one block was finished, the tradesmen (mostly men, but some ladies) rotated to the next block, and then up to the next floor. This makes for somewhat of a spiral planning method

The idea is that no trade is idled waiting for another. Each is fully engaged, so there's little loss to marching army expenses. The newspaper didn't say whether some Kanban system was incorporated for parts and supplies, but the supply chain had to be adjusted.... lot's of small lot deliveries. That may have driven the cost a bit, depending on how deals were struck.

Maybe Bent Flyvbjerg should come to town, take in the theme parks (no small feat of engineering, given the swamps they started with), and then see how downtown is done also

---

Bookmark this on Delicious

Check out these books in the library at Square Peg Consulting

Haptics: the technology of touch

---

Got six minutes to spare for viewing a TED video? Here's one that will add new words to your technology vocabulary, starting with 'haptics', the technology of touch.

Katherine Kuchenbecker is a mechanical engineer practicing at the University of Pennsylvania. She does experiments in haptics.

What's the big idea here?  To add a heretofore unavailable human factor to what we can already see and hear, to wit: synthesized touch.

This can be used to train those that work with their hands, like doctors and artists, about what something is going to feel like when they encounter it for real. So also rehabilitation of those with artifical limbs

And, ever stared through glass case in a museum and wonder what the object felt like? Just put you and on a senor pad to 'feel' the object. (Hand cleaner supplied separately)

If you're running an engineering project, you might hear words like these from your SME's
Tactile: referring to contact location, pressure, shear, slip, vibration, temperature
Kinesthetic: referring to position, orientation, force

If you like this TED video, you might also follow-up with this TED video, materials and technologies you might see in your next project (Caution: risk mangement required!)

• Building blocks that blink, beep and teach: (5:27) TED Fellow Ayah Bdeir introduces littleBits, a set of simple, interchangeable blocks that make programming as simple and important a part of creativity as snapping blocks together.
  For project prototypes, human factor experimentation, and putting down options, these may be a project winner    

---

Bookmark this on Delicious

Check out these books I've written in the library at Square Peg Consulting