Saturday, May 26, 2012

Are you imagining proper form?

Just imagine proper form and you can increase strength in your pinky finger 35%.

Imagine Increased Muscle Strength!-Experiment

In a fascinating experiment, researchers at the Cleveland Clinic Foundation discovered that a muscle can be strengthened just by thinking about exercising it.
For 12 weeks (five minutes a day, five days per week) a team of 30 healthy young adults imagined either using the muscle of their little finger or of their elbow flexor. Dr. Vinoth Ranganathan and his team asked the participants to think as strongly as they could about moving the muscle being tested, to make the imaginary movement as real as they could.

Compared to a control group – that did no imaginary exercises and showed no strength gains – the little-finger group increased their pinky muscle strength by 35%. The other group increased elbow strength by 13.4%.

What's more, brain scans taken after the study showed greater and more focused activity in the prefrontal cortex than before. The researchers said strength gains were due to improvements in the brain's ability to signal muscle. ( Society for Neuroscience, Annual Meeting, November 11, 2001 )


This might explain why form over function is so important in weight lifting.  Form is about getting the correct muscles to fire at the best time in the function of moving the weight from A to B via a path that is most likely not a straight line. Making sure your are firing the right muscles is the job of the brain - the mind controls the brain and it is the mind that imagines, predicts, and sees the future desired state.

Does this relate to other types of activities?  Could we receive a 35% increase in effectiveness just by disciplined practice of proper form in a thought experiment, rather than an actual experience.   I think we could see benefit in this way.  

Friday, May 25, 2012

The 21st century definition of TEST

What is the difference between a test and an experiment?


I propose that in the 21st century and the realm of software development that these definitions must morph to our needs.  There is little difference in the general definition. Yet many people in quality control or quality assurance departments appear to dislike the word experiment.   Defining actions a person takes to perform a 'test-case' as an experiment appears to rankle feathers.   I find this interesting.


Test - (verb) take measures to check the quality, performance, or reliability of (something), esp. before putting it into widespread use or practice.

Experiment - (verb) perform a scientific procedure, esp. in a laboratory, to determine something.


I would like to define that within the modern software world that the word test have a more specific meaning.  I propose:

Test - (verb) a highly repeatable measure to check the quality, performance or reliability of (something), esp. before (something) is created and then put into use or practice.

This definition would distinguish testing from experimenting within the domain of software engineering.  First, it separates testing from experimenting by the aspect of 'highly repeatable' measures.  In todays world of software development if we are not using the power of computers to make our measurements repeatable (which computers happen to be extremely good at) then we are not using the exponential leverage of our own industry.

Second, it suggest that a distinguishing feature of a test is that it can and should be conceived before the thing being tested is created. Well this is just good scientific practice in the first place.  One creates an experiment with a belief they know what will happen and the open mind to experiment and measure the actual results (true or false).  Therefore one must have a hypothesis first.  It may be proven false - at which point the scientist has learned something very valuable.  This aspect of experiment is understood in scientific circles; but in the software industry it needs to be explicitly stated.

These additional aspects of the definition of test when used within the software industry would imply that we could distinguish between a person running the software under development and seeing if the system had the expected behavior via an experiment (probe - sense - respond; Cynefin (video) Complex topology) versus a test in which the person executed a highly repeatable measure to check if the previously predicted behavior actually happened (sense - categorize - respond; Cynefin Simple topology).

Expanding our understanding of the terms we use within a technical field is part and parcel of our industry.  This is the Ubiquous Language activity of the Domain-Driven Design practice.


Thursday, May 17, 2012

7 Aspects of a GREAT Impediment Sticky

A typical impediment sticky
annotating the blocked task.
Just making an impediment list is not good enough.  Yes, it is a start.  But only the start.  Raising impediments at the daily stand-up meeting shows that a team is mature enough to recognize that all problems are better solved in the light of day.  Problems are easier to solve when more than one person is working on the issue.  One of the first steps to getting multiple people working on an impediment is to make it known to the team.

Yet this is the start, not the end of the process.  Yes many newbie teams believe that the Scrum Master's job is to resolve these impediments.  That is a wonderful misconception and will work for a while as the newbie team learns the power of an agile mindset.  But only the maturing teams learn that it is their job to remove these impediments.

So what are 7 aspects on a great impediment card living on the top of your impediment list?
  1. Title - this should be a short pithy phrase; not a dissertation title.
  2. Description - a few sentences that anyone reading the card will get context to the problem, and be interested enough to ask questions.
  3. Who - a name of the person effected by the impediment (should be the person raising it - but OK, if not include both - it is an indication that growth is needed).
  4. Date - the timestamp for the start of the resolution tracking.  If Impediments are resolved in a day then this field may be wasteful - in fact most of this info is waste.  Yet, I'm betting if you are read this far, you have the typical problem of impediments are stale and rarely resolved.  That's why you need the date!
  5. Shepherd - the person who will see this impediment through to resolution
  6. Current status - not a one word status - but a description of the progress, possible workarounds.  This is a log of the resolution process.
  7. Resolution date - a time stampe for the end.  The status above should indicate the resolution.

This is a list of aspects of a great impediment.  If your impediments are not being resolved and you have more that a handful (one for each finger) then you should treat them as more permeant citizens of your task board.   Make the life of the impediment visible.  I'm not going to discuss the resolution process, we'll save that for another day.  But with just this basic data you could start to track the cost of not resolving your impediments.  

Estimate in story points or task hours the amount of effort that would be reduced if the impediment were resolved per day.  Then apply that cost to the impediments life span.  Do this for a few dozen impediments and you may have a wonderful info-graphic to take to your leadership.

Most of the leader's that I've worked with say they understand the impediment resolution process, and why it is important.  Many also say no one ever tells them about the problems.  They say they are willing to help.  Few have trained themselves to go ask, or to question the teams.  Great scrum takes discipline, even at the leadership level.


See Also:
Top Ten Organizational Impediments - by Vodde and LarmanFive Tips of Impediment Resolution - by Stefan Roock