Thursday, May 28, 2015

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?
Read in the library at Square Peg Consulting about these books I've written
Buy them at any online book retailer!
http://www.sqpegconsulting.com
Read my contribution to the Flashblog

Monday, May 25, 2015

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.

Read in the library at Square Peg Consulting about these books I've written
Buy them at any online book retailer!
http://www.sqpegconsulting.com
Read my contribution to the Flashblog

Thursday, May 21, 2015

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

Read in the library at Square Peg Consulting about these books I've written
Buy them at any online book retailer!
http://www.sqpegconsulting.com
Read my contribution to the Flashblog

Monday, May 18, 2015

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!
http://www.sqpegconsulting.com
Read my contribution to the Flashblog

Thursday, May 14, 2015

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?



Read in the library at Square Peg Consulting about these books I've written
Buy them at any online book retailer!
http://www.sqpegconsulting.com
Read my contribution to the Flashblog

Monday, May 11, 2015

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.

Read in the library at Square Peg Consulting about these books I've written
Buy them at any online book retailer!
http://www.sqpegconsulting.com
Read my contribution to the Flashblog

Thursday, May 7, 2015

Of chalk and axes


Recall, we discussed this about precision and accuracy 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.



Read in the library at Square Peg Consulting about these books I've written
Buy them at any online book retailer!
http://www.sqpegconsulting.com
Read my contribution to the Flashblog