Clothes for cognition

---

Clothing makes the person... read on, this is not 1950 stuff

Now comes a study (with real data and observations, of course) that cognition -- our ability to think, innovate, understand, and present our ideas -- is a function of our clothing.

Cognition = f(clothing), in calculus terminology

(There may be a functional discontinuity when Clothing = 0, but that's a matter of context.)

Did you see this coming? I did not
We learn this about that here

“Putting on formal clothes makes us feel powerful, and that changes the basic way we see the world,” says Abraham Rutchick, an author of the study and a professor of psychology at California State University, Northridge. Rutchick and his co-authors found that wearing clothing that’s more formal than usual makes people think more broadly and holistically, rather than narrowly and about fine-grained details. In psychological parlance, wearing a suit encourages people to use abstract processing more readily than concrete processing.

And, there's more:

As casual attire becomes the norm in a growing number of workplaces, it would seem that the symbolic power of the suit will erode in coming years. [Co-author Michael] Slepian thinks the opposite. “You could even predict the effect could get stronger if formal clothing is only reserved for the most formal of situations,” he says. “It takes a long time for symbols and our agreed interpretations of those symbols to change, and I wouldn't expect the suit as a symbol of power to be leaving us anytime soon.”

Ok! I guess it's off to buy a suit, something I've not done in some years. I guess this means a tie (for men) also?

---

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

Project management the Agile way

---

Here's a question I address in my book: "Project Management the Agile Way:Making it work in the enterprise"

Why plan, why schedule? Indeed, the question might even be: Why estimate? It’s all going to change anyway.

The answer is quite clear:

If there are no plans, any outcome is acceptable; if there are no plans, there is nothing to estimate; without estimates, there is no reason to measure. Without measurements, there will be no benchmarks, no improvement, and no answer to the questions of where are we? and what are we doing?
In fact, without a plan, anywhere and anything will 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

Statistics: what you may not know

---

Do you buy this?

"Statistics does not require randomness. The three essential elements of statistics are measurement, comparison, and variation. Randomness is one way to supply variation, and it’s one way to model variation, but it’s not necessary. Nor is it necessary to have “true” randomness (of the dice-throwing or urn-sampling variety) in order to have a useful probability model." Andrew Gelman 

How about this one?

" ... the #1 neglected topic in statistics is measurement "

All this, and the image, are what Andrew Gelman asserts in his posting here.

Statistics does not require randomness (just variation) --- an arresting statement to be sure. It's what caught my eye.

Gelman is on to a different agenda, however. His point is that in his experience -- which may be more academic than empirical -- measurement is given a back seat, almost neglected in some respects. (Measurement occurs here; lets press on)

But of course, if you are going to stand in front of your team or sponsor and spout statistics, it would be good if you had real observations to back you up. And, shocking as it may seem, you have to take measurements of real events and phenomenon in order to have back-up data

Of course, that leads toward accuracy and precision, cause and effect, and correlation. Perhaps all that is a bridge too far for one posting. I am leaving the building now...

---

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

Reach vs grasp re Software

---

Does everyone in Agile-land grasp the point here:

“Software temptations are virtually irresistible. The apparent ease of creating arbitrary behavior makes us arrogant. We become sorceror’s apprentices, foolishly believing we can control any amount of complexity. … We would be better off if we learned how and when to say no ”

G.F. McCormick

When Reach Exceeds Grasp

The embedded customer or product owner could drive the project off the cliff, not understanding as they might not how change effects pile up, leading potentially to unsafe, insecure, or chaotic behavior. It's the role of the architect and the project manager to put down the constraints, and just say No.

---

 

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

Maturity model

---

Yuk! No one wants to read about a maturity model. Isn't that a tool from 30 years ago?
Nonetheless, over at herdingcats, there is an image of a model that captured my attention for a couple of reasons

• The image itself is an attractive presentation
• The substance is clear enough that most can see some advantage of every step

This model, like models, is a simple and abstracted view of real life so that we focus on the substantive points. That is, no one works in an organization that is exclusively on one level or another. The points being:

• In some things, we're level 1 or 2, making it up as circumstances emerge -- Innovation may occur here.
• In other things, we've advanced to level 4 or 5 because we know exactly how to do it, and we're committed to making it even better --- Productivity (and profitability) may occur here.

And, so having read this far:

• Is there something useful here, or
• What's the utility?
• What's the action item for a project office?

Answer:

• Maturity models are checklists, on the one hand -- stuff we should be doing. Are we doing them?
• Maturity models can serve as strategic objectives (to climb the steps), giving a glimpse of a differentiated future. Do we have a plan to get to one step or another? After all, who wouldn't be striving for the fifth step, always focusing on improvement?

---

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

Agile V&V

---

Have you thought much about this? Two of the conceptual conundrums of the hybrid methodology project are:

1. How do you verify that which is incomplete and
2. How do you validate the efficacy of that which is yet to be conceived?

Verification and validation (V&V) are traditionally held to be very important project practices that are difficult to map directly into the Agile domain. Traditionally, V&V has these practices:

• Validation: Each requirement is validated for it’s business usefulness, in effect its efficacy toward project objectives. Validation is usually not later than the last step in gathering and organizing requirements
• Verification: When development is complete, and when integration of all requirements are complete, the roll is called to ensure that every validated requirement is present and accounted for.

Placed into an Agile context, validation is applied both to the project backlog and to the iteration backlog, since changes are anticipated to occur. Validation is typically first applied at the story or use case level, validating with conversation among the interested and sponsoring parties that the functionality proposed is valid for the purpose.

 

One can imagine validating against external rules and regulations, perhaps internal standards, and of course validating against the business case. Verification is generally a practice at the iteration level, verifying that iteration backlog matches the iteration outcomes, and logging any differences

 

Depending on the project paradigm, V&V can be carried into integration tests and customer acceptance tests, again testing against various benchmarks and standards for validity, and verifying that everything delivered at the iteration level got integrated at the deliverable product level.

---

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

Of chalk and axes

---

Recall this little ditty about precision and accuracy among process errors:

Measure it with a micrometer
Mark it with chalk
Cut it with an axe!

Well, there is a nice video on TED-Ed more or less along this line. "What's the difference between accuracy and precision?".

Watch it to the end. There's a few project things to think about.

If you watch it on TED-Ed (instead of youtube) there are other lesson resources clickable on the right panel that add to the experience.

---

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

Protecting the integrity of software

---

Breakdowns, security, hazards, etc are all over the place these days, and so Matthew Squair's presentation on Software Partitioning Integrity is very timely. He subtitles it "A short tutorial on the basic architectural principles of integrity level partitioning"

You'll learn pithy things like this:

If You Can Keep Them Separate (Partitioning)
Then You Can Bring Them Together (Composition)
Greve & Wilding HCSS 03

Of course in the world of system engineering, we talk about decoupling and coupling, the former to manage the propagation of risk and provide for independence of action; the latter to create a means for integrating actions.

And, at an even higher level, these principles are applicable to portfolios, and the way projects, scope, and security is partitioned among portfolio constituents.

A few definitions are helpful, especially when looking at the system either in terms of safety or security (perhaps attention to aircraft cockpit security could benefit by this):

Strict Protection
– Component X can be said to be strictly protected from Y if any behavior of
Y has no effect on the operation of X
Safety Protection
– Component X can be said to be safely protected from Y if any behavior of
Y has no effect on the safety properties of X
 Two-way (symmetric) protection
– Component X is protected from Y, and Y is protected from X
 One-way (asymmetric) protection
– Component X is protected from Y, but component Y is not protected from
X

Beyond software
This presentation actually goes beyond software to the very top of the architecture, to include hardware, and the interactions of hardware and software vis a vis safety, isolation, and protection.

If you're in this business (and actually who is not thinking of security these days) this is a good read.

---

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

Risk register psychology

---

Ever done a risk register? It's usually a matrix or table of three elements of information

1. risk impact on the one side, and
2. risk probability (or frequency) on the other side, with
3. some assessment, either qualitative or quantitative at the intersection of (1) and (2)

Fair enough.

But, as we all know, the effectiveness of just these three elements of information in driving a decision about risk -- the risk register really having no other purpose but to drive action -- is all in how the information is presented.

Enter: psychology. (The doctor will see you now)

Say it as frequency
I recently threaded though some articles on the psychology of talking about probability.

It seems that empirical studies have repeatedly shown that people are more comfortable with, and seem to accept circumstances better, when you say "5 chances in a hundred" rather than saying the probability is 5%.

"Five chances in a hundred" is a frequency construct of probability. Now, of course, if you do the math, frequency is just a ratio: 5 per 100, 5/100, .05, 1/20

But, it's not altogether just math in the mind's eye. "Five chances in a hundred" sounds 'iffy'; sounds like it might not work out; sounds like there is some risk to the outcome.
Whereas: 5% sound precise, even accurate (gasp!, there's no real accuracy in predicting the future).

And, here's the other thing: We can easily grasp an image of 5 outcomes in a "large set" of possibilities -- who's not held 5 cards from a deck of 52, etc? But, there's no real image of 5% (can you draw me a picture of 5%?)

Scale matters
It's easy to keep an image of 5 or ten items in mind; much less so when the numbers get large, so the effectiveness of the frequency image tends to break down with really large numbers

And, a 50 - 50 chance seems ok when you think about it, but 1 chance in 2 raises suspicion's that the sample is too small, whereas 50 out of 100 seems ok and in accord with experience. But, 50% seems too precise for my thinking.

Conclusion: if you want to be an effective communicator, say it with frequency

---

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