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

Sprint length - a fun debate. What is the best practice - a funny question. There is no best practice for sprint length.  But what factors should go into the decision? The team's ability to become predictable within the sprint duration. The Product Owner's ability to plan and to commit to the unknown of not changing the plan for the sprint's duration. The frequency of needed feedback on the direction the team is making toward the release goal. The ability of the team to create their sustainable pace. Many team's I've worked with have trouble defining their sustainable pace .  I've argued that this pace that allows the team to deliver both working software that is potentially shippable each sprint and to have high quality deliverables along with team learning is quite a bit below the teams typical sprint velocity. When teams are under extreme pressure to deliver they typically forget one of the 7 habits of effective people - to sharpen the saw .  S

What do the Thanksgiving and Christmas holidays do to your teams tempo and cadence? For most US teams this holiday period from mid November to after the first of January is hectic and disruptive in various ways.  This calls for a Holiday Stratagem.  A trick to allow the team to have some semblance of continuity and flow during these times. The Sontaran Stratagem - Doctor Who To discuss this stratagem let's first define some terms: Tempo - the rate of workdays to calendar days Cadence - the beat of the sprint events to fall upon the same calendar day of the week Sprint duration -  in work days (in this example I'll use 10 work days) Sprint length - the length of calendar days between two sprints (14 days for the example 2 week sprint) What do you value more?  The ability to deliver more work in the short term -or- the ability to predict long term the capability of the team to deliver that work?  Or perhaps something else, like teaching a new team the trade-off

Just bought the Craig Larman agile library collection on Amazon for our lending library at work . I first feel in love with Agile by reading Larman's Agile & Iterative Development: A Manager's Guide.   The organizational context that sets the stage for comparing and contrasting various agile (and non-agile) methods of software development is a powerful framework.  I find few managers choosing a method understand these concepts enough to make an informed choice.  Only a few hours with this book would raise their awareness to a much improved state. Here how I started a mini-movement... one email... I find an empty book shelf to be an aberration.  So I’m filling it up with techie books and some not so techie books.  Feel free to BORROW a book for a few weeks then bring it back for someone else to borrow.  Bring in those dusty books you found interesting and join me in creating a Tech Dev Lending Library.   Connector Breakout Lounge 5001. There is no check out sy

Leadership desires - Info Radiators  What are the individual elements that make a Scrum task board effective for the team and the leadership of the team?  There are a few basic elements that are quite obvious when you have seen a few good Scrum boards... but there are some other elements that appear to elude even the most servant of leaders of Scrum teams. Team desires - Info Radiators In general I'm referring to a physical Scrum board.  Although software applications will replicated may of the elements of a good Scrum board there will be affordances that are not easily replicated.  And software applications offer features not easily implemented in the physical domain also. Scrum Info Radiator Checklist (PDF) Basic Elements Board Framework  - columns and rows laid out in bold colors (blue tape works well)      Attributes :  space for the total number of stickies that will need to belong in each cell of the matrix;  lines that are not easy eroded,

Velocity Calculus  -- by David A. Koontz In the practice of Scrum many people appear to have their favorite method of calculating the team's velocity.  For many this exercise appears very academic.  Yet when you get three people and ask them you will invariability get more answers than you have belly-buttons.  That in its self is an interesting phenomenon, worthy of a blog post.  But this is not it. Calculus is the mathematical study of change. This video is a photo journal simulation describing how to calculate a Scrum sprint velocity.  It explains the calculus for one of the most difficult decision a team faces.  What to do with that first unfinished story.

Are your teams having difficulty understanding the relative nature of story points?  Try an analogy ... maybe one that is already well know... yet so often used that they have forgotten just how easy it is to use relative measures.  I'll bet they use it every day, multiple times per day.  That kind of practice makes usage very easy.  That is how easy story points will become for a team that practices. Here's your analogy - in less than 10 seconds.  But you might need to repeat it about 14 times... YouTube channel:  Minute Physics Don't mistake preception of temperature and the measurement of temperature.... see Derek's Veritasum experiment: Misconception About Temperature . Now... relate the misconception about temperature back to the topic of relative points...

Is this a trend in the industry?  Perhaps some of the first movers in the work-from-anywhere movement have had a chance to see the ROI on this policy. Perhaps they have some indicators that collaboration is a skill best practiced in person.  Practiced with full-body awareness, in sense-around environments with many of our more than 20 senses - rather than just a select few - online. How many people must practice the same behavior, concurrently for there to be a true movement?  Do you want to be on the front end of the last movement in your industry or the bleeding edge of this movement? Yahoo sees the ROI from canceling the work from home policy. There is definitely merit to the idea, however, that bringing its agile programming teams together in the same place at the same time can have a small but crucial impact on performance. In his book People Analytics, MIT visiting scientist Ben Waber discusses the role of dependencies for programmers, that teams must coordinate closel