Agile Complexification Inverter

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:

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 St

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.

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

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 nu

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 t

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)

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 the

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