Friday, December 20, 2013

Magic Feedback Technique

A technique for increasing performance by using a simple (perhaps magical) recipe when giving feedback.

Read the study, understand the method of investigation; ask yourself if this is similar to your work environment - just enough such that the technique might be generalized across the two different situations.
Breaking the Cycle of Mistrust: Wise Interventions to Provide Critical Feedback Across the Racial Divide  by David S. Yeager, et. al.

If you just want to cheat, read the "cliff-notes" version (it's what I did) - but I promise myself to go back after writing this post and read the study.

Try This One Phrase to Make Feedback 40% More Effective  by Jeff Haden - INC.

Jeff is quoting Daniel Coyle, author of The Talent Code which references the study.  Now I'm referring to Jeff -> Daniel -> Yeager et al.  And you are at the front of the line of referral - maybe you should jump the line - read the original work.

But you just want the MAGIC:

I'm giving you these comments because I have very high expectations and I know that you can reach them.

Breaking it down:  create an IN Group mentality, set high expectation to belong within this group, extend trust that they have what it takes to belong and meet the high standards.

Try that in the upcoming round of performance reviews.

See Also:
Employee feedback: How to make it less painful - How Lee Burbage, the Motley Fool HR leader changed their employee feedback program.

HBR:  Why Your Brain Hates Performance Reviews by Gretchen Gavett

Performance Appraisals what have we learned in 50 years?


20 Years Ago, Steve Jobs Demonstrated the Perfect Way to Respond to an Insult, Inc. by Justin Bariso
In 1997, Steve Jobs was answering developers' questions when one audience member took a shot at him. What happens next is remarkable.



Thursday, December 19, 2013

Transparency of Price in Health Care

Does it exist?

Health care in the USA is under great pressure to change these days.  So regardless of which pole of the political sphere you personally are drawn toward, the landscape underneath your view point will be changing.  One could ask why.  It is an interesting line of inquiry.  Will the fact that health care is just too costly, increasing at exponential rates, and leaving an ever enlarging number of americans out of the "care" system suffice for the moment?

So this domain of the american system is being pushed off a proverbial cliff into a turbulent troubled sea of change.  I wonder - do we have any system models that would describe what might help in these situations?

Here's a case in point, a CEO announce a spur of the moment policy change, a move toward transparency.  Why?  Perhaps he was frustrated with the ill-rational behavior of "the system".  And decide that a move toward transparency was a rational behavior.

Florida Hospital Takes a Step Toward Price Transparency
Miami's Mount Sinai Medical Center has pledged to publicly disclose its price contracts with insurers
By Kate Pickert June 03, 2013 TIME.com

Speaking in May on a local public radio affiliate, WLRN, Steve Sonenreich, CEO of the Mount Sinai Medical Center in Miami Beach, FLA, said, “We’d be willing to put our prices to all the insurance companies out in public and we would welcome that kind of transparency of everyone in the marketplace.”

More articles on the money issue:  Follow the money with Time's Steven Brill.
Steven Brill - The Daily Show
Watching Jon Stewart's interview you may realize that the health care industry is not like any industry you are familiar with -- let's say one that you work in, where reasonable people do things with reasonable cause and effect correlation.  So how do we model this rather chaotic (Alice in Wonderland) world such that we can make reasonable decision about how to tame the beast?  If you are from another domain (say regular world) you may be tempted to apply regular world logic to a small subset of the problems and be surprised by the systems behavior.  A case in point, almost every other industry has some level of price transparency.  Customers have choices before they purchase a good or service and may choose to shop around based upon price.  So what happens when some nut job suggest that health care do the same?  Well you can bet the chaotic system does not react like your normal world system.

If only there was a general model of this meta system of systems - some which behave sanely, and some which are just too difficult to understand.  A model that could give us some guidance as to how to behave when we knew which land we happen to be in at any one moment.

Do you know of such a model?  Let me see, here's a few:

Reagan's Trickel-down economics (Supply-side)
Keynesian economics
Various economic models compared to scientific models
Wonderland model

I don't think these models will work for our problem.  Why?  Because they do not model insane systems very well.  They all seem to assume the rational mind exist within the system.  And I think we can agree -- there is no rational control within the health care system.

Perhaps if we go a bit more abstract... maybe a weather system model will work.  Those model really weird system that produce erratic behaviors like hurricanes and tornados and even sharknados.

Or maybe we are barking up the wrong tree... perhaps we should simplify our models...  try to make sense of the meta information, apply some common sense to the problems instead of getting inside the tornados of data and assuming that every thing moves in a counter-clockwise direction (talk about getting wrapped around the axel).

Try this simple model... based on the classic two dimensional four quadrant model... but with a dimensional twist out of the page... kinda like MC Escher would do...  So it is a bit like a model that fits wonderland.  Cynefin framework by David Snowden.




Back to the health care price transparency issue now.  Which Cynefin domain is health care pricing?  Hum... oh I fear answering because I could get it wrong...  well there's only 4 domain, I've got a 25% chance just by guessing.  WRONG!  There are 5 domains and the fact that I don't know which domain I'm in tells us the answer, we are in the disordered domain (the 5th one - the one we are most likely to be in most of the time).  Damn, I think Mr. Snowden may be on to something here.

So if health care pricing is in a discorded domain, what's the model tell us we should do?  I think (and I may be wrong - and wouldn't that be FUN) it doesn't matter - we act, then sense.  So was Steve Sonenreich, CEO of the Mount Sinai wrong to just act?  To suggest that price transparency may be a good thing for the system.  Then to sense what the system does with this new input.  Certainly the people in his organization had a bit of panic in their throats and had to change lots of things to make his decision a reality.  We might not see the cause and effect for some years to come.  So be very careful when we sense.  We might not sense the ripple effect.

How does Snowden suggest we sense?

I'll leave that you to you to answer.

Wednesday, December 18, 2013

Lean-Kanban Brickell Key Award

Best quote:
"Significant Impostor Syndrome"
2013 Brickell Key Award nominations video.



Published on Oct 24, 2013
Nominee recognition video for the Brickell Key awards, presented at LeanKanban North America 2013 in Chicago IL, USA. Video by Derek Wade.  Music: Thomas Newman - "American Beauty"

Spollier Alert!!!

The winners were Yuval Yeret and Troy Magennis.

See Also:
http://leankanban.com/brickell-key/  the award page.

Wednesday, December 11, 2013

The Hidden Benefits of Keeping Teams Intact

December's issue of Harvard Business Review creates a compelling case for the concept of persistent teams. And hey, if they do it in the operating room, then there must be good science behind it. But heck, we don't need no stinking science, we just know it works, right?

http://hbr.org/2013/12/the-hidden-benefits-of-keeping-teams-intact/ar/1

Harvard Business Review - Dec 2013


ICEpocalypse Impediment

Our company just discovered an interesting impediment this past week.  The Dallas ICEpocalypse of 2013 resulted in many companies shutting their offices, ours did this also, both Friday and Monday (Dec. 6th & 9th) - someone even opened an outdoor ice skating rink in Dallas.  Yet many team members worked from home, and to do this many had to use the Virtual Private Network (VPN) to access secure systems.  Guess what impediment a few thousand employees all working from home the same day causes?  The VPN is a licensed infrastructure with a license limit.  Yep! only a fraction of the people working from home could access the limited licenses of the software VPN.

So I wonder if there is a system, known to mankind, that is designed to deal with this sort of constraint and surge in usage....  isn't that new fangled cloud computing environment designed to handle this very sort of on demand scalability?

So I understand the need of the company IT department to purchase a limited number of licenses.  I understand the VPN vendor to limit the users of the system.  I understand the workers wanting to stay within the safety of their warm homes and use those new high tech remote computing platforms and networking that we are so famous for creating.

I understand that we as a company have spent millions of dollars on fail safe redundant data centers to server our customers.  We have fault tolerant fail over systems, disaster recovery systems.  But we don't have them fool proof.  And one weather system proves it.  While I'm sure the customer systems continued to hum during the ICEpocalypse of 2013.  The support and development groups got taken out by a VPN license agreement.

I'm not an expert on contractual license agreements - but when I was tasked with writing a license monitoring framework for our network infrastructure product many years ago - I chose to buy one from a company that's core competency was licensing.  We integrated it (FlexLM) with our software.  It had the capability to change license restrictions with the editing of a file and restarting a license manager service.  We could have easily given a client a thousand licenses for a week if asked, we could have charged them for this service or done it for free.  All because the license manager company had already solved these problems before.

So I wonder why that capability doesn't manifest itself today in core infrastructure, as part of disaster mitigation plans.


References:

FlexNet http://en.wikipedia.org/wiki/FlexNet_Publisher
OpenLM  http://www.openlm.com

Saturday, December 7, 2013

Intro to Refactoring with LEGOs

Practicing Into to Refactoring with LEGOs.

Refactoring is when a developer changes the structure of the code without changing the behavior.  To do this with little or no risk a craftsman will have a set of well maintained tests that prove the code still behaves exactly as before.

A simple way to visualize refactoring is to think of 12 eggs.  Most people will imagine a carton of eggs.  But it is possible to think of 2 cartons of 6 eggs; or even 6 packages of two hardboiled eggs.  Refactoring get's its name from the factorization of numbers.  Twelve has multiple factors (6 x 2), (3 x 4), (2 x 6), (1 x 12).  No matter which factorization the resulting collection is twelve eggs.  In TDD we have test to make sure we don't break the eggs.

Note:  Many IDE's claim to do refactoring, and many times they work just as expected; however not all IDE refactorings are reliable.  I suggest you test your IDE's refactoring before you trust it.

To introduce beginner developers to the basics of refactoring - start with a well understood class with many blocks of code.  First refactoring to practice is Extract Method.


But first make a program of blocks in this order:  white, red, blue, blue (again), red, yellow, green, red, yellow at the bottom.


Extract Method:  using the extract method refactoring - pull out the red block of code; replacing it with a call (the 4x2 red plate) to the extracted block.



Repeat the Extract Method operation on each red section of the program.



Now, a step of refactoring (or TDD) is to remove duplication.  All three of those red blocks of code are theoretically the very same, so we really only need one.  Set two aside and place the one remaining at the bottom of the program stack.


Good job!

Now let's use Extract Method operation on the two blue blocks of code.




And remove the duplication.  Remembering the one blue block remaining is place on the bottom of the program stack.


Practice, practice, practice.... the art of a craftsman.

Let's practice again with the yellow block;  perform the Extract Method operation on yellow blocks of code.




Well done.

Now the program looks a bit wonky... unbalanced by the large green block - let's extract it also.



There, good practice... and continue with the white block....



There all the in-lined class code has been extracted to methods and method calls.  That is well factored.  But let's do a bit of house keeping.  Clean up and reorder the methods and calls into a similar order.


When separated the blocks of code and the calling plates look like this:


Before and after refactoring images.














Required LEGOs

(1) Green 4x2 Plate;  (1) Green 4x2 Block
(1) White 4x2 Plate;  (1) White 4x2 Block
(2) Yellow 4x2 Plate;  (2) Yellow 4x2 Block
(2) Blue 4x2 Plate;  (2) Blue 4x2 Block
(3) Red 4x2 Plate;  (3) Red 4x2 Block



Reference:

Adapted from Bryan Beecham's (@BillyGarnet TDD with LEGOs presentations and PDF.


Friday, December 6, 2013

Best Scrum Stand-up Activity

The Spartan team at VHA has been doing t'ai-chi before their daily stand-up now for several months. Just a few minutes every day.  Lead by someone different every day.

Spartan's daily stand-up starts with t'ai-chi

I was floored the first time I attended.  It's introduction may have been the tipping point between team formation and performing.

See Also:

It's Not Just Standing Up Patterns for Daily Standup Meetings - Jason Yip
Neil Killick's advice on Stand-ups: Stand Up and Shut Up
the 24 forms of Tai Chi (youTube video)


Tuesday, December 3, 2013

It's not Technical Debt - it's Unclean Code

I hear lots of colleagues using the term 'technical debt' and the scenario that plays in my brain's cineplex is from The Princess Bride when Inigo Montoya remarks to Vizzini; "You keep using that word.  I don't think it means what you think it means."

Inconceivable!




So what does "Technical Debt" mean?  And what do my colleague's typically mean if it is not truly technical debt.

The first is easy; the definition of Technical Debt:

He who coins the term gets to define the term (that's Ward Cunningham).



Ward Cunningham on Technical Debt Metaphor 

OK, so to be truly technical debt one must negotiate the debt with the business.  The business should achieve some objective sooner and incur an obligation to repay the technical team the time and effort required to put the system back into a proper state of clean well factored code.

But, wait... what could my colleagues mean when they misuse the term technical debt?  I think they mean many things, but since there is no good word for what they mean they appropriate the popular term.  I've referred to the concept as:

  • bugs just waiting to be discovered
  • short cuts that will come to haunt us later
  • things we will fix one day
  • engineering done by the new guy
  • design choices that time permitted 

There appears to be a problem here; there is no good word or phrase for this concept.  So let's create one!  How about unclean code.  Inverting the concept from Robert Martin's Clean Code: A Handbook of Agile Software Craftsmanship.

Let's define the term 'unclean code'.  Software code that might work, has known deficiencies, needs to be thoroughly tested, and probably would make a master craftsman's nose turn up at the smell.

Let's see if the term can replace the misappropriated 'technical debt' in a sentence.  "We have some technical debt unclean code this sprint that will need to be added to the backlog, but the features are all done."


See Also:

A Product Manager's Take on Technical Debt by Kevin Binnie
A Technical Debit - Collateralized Debt Obligation you should not invest in - David Koontz
No Test - Inconceivable - Agile Complexification Inverter
Managing Software Debt - book by Chris Sterling
Doc Norton Sez You're Using "Technical Debt" Wrong - Agile Amped at Agile2016
Ward Cunningham's Debt Metaphor Isn't a Metaphor by Rob Myers
WSJ: What Buzzwords Would You Ban in 2014?
Crisp's Blog: The Solution to Technical Debt by H. Kniberg - he calls it "Crappy Code"
Misunderstanding Technical Debt by Niklas Bj√∂rnerstedt

The SQALE method is particularly devoted to the management of the Technical Debt (or Design Debt) of software developments. It allows:

  • To define clearly what creates the technical debt
  • To estimate correctly this debt
  • To analyse this debt upon technical and business perspective
  • To offer different prioritisation strategies allowing establishing optimised payback plan.
Martin Flower's Technical Debt quadrant model

The Technical Debt Trap - Doc Norton at NDC Conference 2016

Monday, December 2, 2013

Project Success Sliders

What do you do when the Product Solutions Director comes to you and suggest that she would like a product delivered within a 5% error on the delivery date?

One suggestion is to run through a thought experiment with her.  For example:  Let's assume this is a project that will take about 6 months.  Let's base the schedule on a 180 day time line.  So you desire us to hit that 180 day target from six months away to within 5%.  OK that's 0.05 * 180 = 9 days.  Now is that a plus or minus 5% or a 5% range?  Or in absolute terms for this example do I have to be within 171 - 189 days (+/-5%) or within 176 - 185 days (5%).  So to continue this example, consider a team doing 2 week sprints.  This would equate to 12 - 13 sprints with one sprint error.

by Mountain Goat Software
But perhaps more important is what this one prime aspect of project success says about the other aspects of the project.  So lets try to balance the project success aspects with the schedule being the one most important aspect.  Given that the aspects must balance (rules of the game), then one can choose only one other high important aspect and most leaders chose quality.  This will give a picture something like this.  Meaning that the four aspects of the typical iron triangle (schedule, cost, scope & the unchanging quality) with an emphasis on schedule will lead to cost and scope changes (increased cost and decreased scope).  And what happens when the leadership doesn't increase the cost and decrease the scope?  Well, that quality on the inside of the iron triangle that no one wishes to degrade is .... well, degraded -- while everyone says that it is not.  And that folks, is how one creates design-dead legacy applications in six months.


References:

Mike Cohn created the web based interactive project success sliders shown above; described in the book Radical Project Management by Rob Thomsett.