Thursday, December 22, 2016

Mean Time between Disruptions (MTD) a leadership Metric

A rant on Metric's I wish I had written...  so I'm going to just include it by reference and call it my own.

One thousand Words on Metrics

Here's a quote to get you even more interested in clicking that link...


In short, I find most grasping for metrics to be a reliable metric for lack of understanding of human behavior, not only that of those who would be measured but that of those who would do the measuring.
If a higher-up wants a metric about a team, say, as an input to their judgment about whether the team’s work is satisfactory, oughtn’t there be some other way to tell?
And if I choose nearly any metric on someone else’s behalf, doesn’t that reveal my assumption that I know something about how they do their good work better than they do?
Or worse, that I prefer they nail the metric than do something as loose and floppy as “good work”? 
Well - will you look at that!  Yareev's even willing to apply his own metric to his work.  What a great example of a leader...

Let’s try that again

New metric (expiration = next subhead, privacy = public): I’m 0 for 1 on satisfying conclusions to this post.
I’m hardly an expert on human behavior. If I were one, rather than being passive-aggressive and obstructive, I’d have a ready step to suggest to metrics-wanters, one that they’d likely find more desirable than metrics.
Instead I have to talk myself down from passo-aggro-obstructo, by which time they’ve chosen what they’ll observe and the ready step I can offer is limited to encouraging them to observe the effects of their observation.
Can you give me some better ideas?
Here's my very special response to his request for comments.

   I'm wanting to +1 your whole rant, I'd like to nail it to the front doors, I'm thinking about a tattoo, but unsure where on my leader's body it should go...

   I have sometimes fantasied about asking the VP that want's a new metric, if it would be good for us to add one that measured their leadership of our group - I'll call this metric Mean Time between Disruptions (MTD).  MTD is calculated much like the old factory sign that said:
 "its been 1023 days since we killed someone at this factory, please be safe."
   So let's start counting (I suggest in weeks) the time between a major disruption to the team.  For this basic metric we are looking at team formation dynamics (your familiar with Tuckman's Forming, Storming, Norming, Performing) and you Mr. VP desire the P word - but it comes after 3 stages of development beyond the F word).

   Let's start at the beginning and count weeks between Forming and ReForming.  You know like when you move a person on/off a team.  When you move the team's physical location, or when you give the team a new objective, then let's reset the clock.

   The metrics I've seen range from MTD = 0 to about 20 weeks for many teams I've worked with.  And Mr. VP says they desire persistent teams.

I would have put it on his site in the comments but I got a very dissatisfied error message from the system when I posted it... (wonder if he has a metric for failed comments?).

Agile in 3 Minutes  a podcast that discusses a journey toward agility (each episode in exactly 3 minutes).  I'm pondering... why does the magic number 3 come up in the Agile community so often?  Personally I feel it has to do with the Book of Armaments, chapter 2, verse 9 to 21; because 5 is right out!

See Also:
Team Metrics - Case Study
How could we measure Team Happiness?
Metrics for a Scrum Team  but don't confuse that post with Scrum Team Metrics which discusses the necessary and sufficient metric Velocity.
Do you really need a Project Management Office? (PMO effectiveness metrics)

Tuesday, December 13, 2016

Cycle Time and Lead Time

Our organization is starting to talk about measuring Cycle Time and Lead Time on our software engineering stories.  It's just an observation, but few people seem to understand these measurement concepts, but everyone is talking about them.  This is a bad omen...  wish I could help illustrate these terms.  Because I doubt the measurements will be very accurate if the community doesn't understand when to start the clock, and just as important - when to stop it.

[For the nature of confusion around this terms compare and contrast these:  Agile Alliance Glossary; Six Sigma;; Lean Glossary.]

The team I'm working with had a toy basket ball goal over their Scrum board...  like many cheep toys the rim broke.  Someone bought a superior mini goal, it's a nice heavy quarter inch plastic board with a spring loaded rim - not a cheep toy.  The team used "Command Strips" to mount it but they didn't hold for long.

The team convinced me there was a correlation between their basketball points on the charts and the teams sprint burndown chart.  Not cause and effect, but correlation; have you ever stopped to think what that really means?  Could it mean that something in the environment beyond your ability to measure is an actual cause to the effect you desire?

I asked the head person at the site for advice, how could we get the goal mounted in our area?  He suggested that we didn't need permission, that the walls of the building were not national treasures - we should just mount it... maybe try some Command Strips.  Yes, great minds...  but what about getting fired after putting holes in the walls scares one from doing the right thing?  How hard is it to explain to the Texas Work Force Commission when they ask why you were fired?

The leader understood that if I asked the building facilities manager that I might get denied - but if he asked for a favor... it would get done.  That very day, Mike had the facilities manager looking at the board and the wall (a 15-20 minute conversation).  Are you starting the clock?  It's Dec 7th, lead time starts when Mike agreed to the team's request.

The team was excited, it looked like their desire was going to be granted.  Productive would flourish again.

Over the next few days I would see various people looking up at the wall and down at the basketball goal on the floor.  There were about 4 of these meetings each very short and not always the same people.  Team members would come up to me afterwards and ask...  "are we still getting the goal?"... "when are they going to bring a drill?"...  "what's taking so long?"

Running the calendar forward a bit... Today the facilities guy showed up with a ladder and drill.  It took about 20 minutes.  Basketball goal mounted (Dec 13th) - which clock did you stop?  All of the clocks stop when the customer (team) has their product (basketball goal) in production (a game commences).

I choose to think of lead time as the time it takes an agreed upon product or service order to be delivered.  In this example that starts when Mike, the dude, agreed to help the team get their goal mounted.

In this situation I want to think of cycle time as the time that people worked to produce the product (mounted goal) - other's might call this process time (see Lean Glossary).  And so I estimated the time that each meeting on the court looking at the unmounted goal took, plus the actual time to mount  the goal (100 minutes).  Technically cycle time is per unit of product - since in the software world we typically measure per story and each story is some what unique - it's not uncommon to drop the per unit aspect of cycle time.

Lead time:  Dec 13th minus Dec 7th = 5 work days
Cycle time:  hash marks //// (4)  one for each meeting at the board to discuss mounting techniques (assume 20 m. each); and about 20 minutes with ladder and drill;  total 100 minutes

Lead Time 5 days; Cycle Time 100 minutes

This lead to a conversation on the court - under the new goal with a few team members about what we could do with these measurements.  How if one's job was to go around and install basketball goals for every team in the building that a cycle time of 100 minutes with a lead time of 5 days might make the customers a bit unhappy.   Yet for a one off, unusual once a year sort of request that ratio of 100 minutes to 5 days was not such a bad response time.  The customer's were very happy in the end, although waiting for 5 days did make them a bit edgy.

But now what would happen if we measured our software development cycle time and lead time - would our (business) customers be happy?  Do we produce a once in a year product? (Well yes - we've yet to do a release.) Do our lead times have similar ratios to cycle time, with very little value add time (process time)?


Well it's January 5th and this example came up in a Scrum Master's Forum meeting.  After telling the tale we still did not agree on when to start and stop the two watches for Lead Time and Cycle Time.  Maybe this is much harder than I thought.  Turns out I'm in the minority of opinions - I'm doing it wrong!

Could you help me figure out why my view point is wrong?  Comment below, please.

LeanKit just published an article on this topic - it's very good but might also misinterpret cycle time.  I see no 'per unit' in their definition of cycle time.  The Lead Time and Cycle Time Debate: When Does the Clock Start? by Tommy Norman.

An Experiment in measuring the team's cycle time:
After a bit of time reflecting, debating, arguing with colleagues and other agilitst online I've decided to publish a little experiment in measuring cycle-time on a scrum team.  Here's the data... what does it say?  How do you think the team should react?  What action should be next?  What should the team's leadership feel/think/do?

The Story:  This team has been working together for a while.  The sprints are numbered from the start of the year... an interesting practice, this team uses 2 week sprints, is practicing Scrum.  Took a nice holiday and required some priming to get back in the swing of things after the first of the year (you see this in the trend of stories completed each sprint).  Cycle Time for a story on trend is longer than the sprint, this correlates with typical story "carry-over" (a story started is not finished in one sprint and is carried over to the next sprint).  Generally a story is finished in the sprint but not in sequence or priority - they all take at least the full sprint to get to done.  There is no correlation of story size to cycle time.

Now those are the facts more or less -- let us see what insights we might create from this cycle time info.  With no correlation of story size to cycle time AND little consistency of number of stories finished in a sprint (trend of # of stories: 1, 6, 7, 2, 2). The question arrises - what is the controlling variable that is not being measured that effects the time it takes to get from start to finish with a story?  Now that the team can see that the simplest things we could track do not have a strong effect on the length of time (or the through-put) a story requires... and that means the process is not under good control - we can start to look around for some of the uncontrolled (invisible factors) -- if we a courageous enough!

We reflected that many of the stories that carry over and are virtually unpredictable in size/time/effort appear to have large delays or multiple delays within their implementation phase.  So we devised a quick and dirty way to track this delay.  The assumption that this delay inherent in the work will perhaps be the unmeasured / uncontrolled variable that throws the correlation of story size with cycle-time out of kilter.

Our devised technique for tracking delay per story - a yellow dot on the task with a tick mark for every day the task is stuck in-process (delayed).

See Also:

LeanKit published this excellent explanation of their choices in calculating cycle time within their tool:  Kanban Calculations: How to Calculate Cycle Time by Daniel Vacanti.
LeanKit Lead Time Metrics: Why Weekends Matter
Elon Musk turns a tweet into reality in 6 days by Loic Le Meur
The ROI of Multiple Small Releases

The Hummingbird Effect: How Galileo Invented Timekeeping and Forever Changed Modern Life
by Maria Popova.  How the invisible hand of the clock powered the Industrial Revolution and sparked the Information Age.

Wednesday, December 7, 2016

A Light Bulb Moment

A few months ago Michele of Sliger Consulting, Inc. asked about my first Agile Light Bulb moment, I've had a few of them but one that easily came to mind was this one with the Washington State Appellate Clerk court case management systems people back in 2005.

In just two months our newly delivering Scrum team had put into production the "undoable" feature - BAM! - value delivered, trust confirmed, transformation successful.
"My light bulb moment was during the product demo in the Sprint Review Meeting, when the state of Washington Appellate Clerk of Court told me he and the courts had been waiting 20 years for the feature that our team had just delivered. In just two months our newly delivering Scrum team had put into production the "undoable" feature - BAM! - value delivered, trust confirmed, transformation successful. He later sent me the requirement spec for the 20-year-old feature and it read just like our epic story and its children we discovered. Yes, this was a completely different system than the previous retired system - yet it had the same customer needs. We had transitioned from a deadlocked in analysis paralysis development group to a Scrum team in under 3 months, delivering into production every month new features, bug fixes, and tested working software."  -- David Koontz

See other Light Bulb Moments at Sliger Consulting Light Bulb Moments

Have you seen in other collections of Light Bulb Moments?  Please comment below.

Tuesday, November 22, 2016

A look at Six Years of Blogging Stats

What do you get from six years of blogging about Agile/Scrum and your continued learning experiences?

Stats from Agile Complexification Inverter blog site

Well the stats are just one insignificant measure of what one gets from writing about their experience.

The bad artist imitate, the great artist steal.The more meaningful measures have been seeing some of these articles and resources put into practice by other colleagues, discussion that have happened (off line & sometimes in comments or twitter, etc.) with readers that require me to refine my thinking and messaging of my thinking.  Interestingly some times seeing a resource that you have created being "borrowed" and used in another persons or companies artifact without attribution is both rewarding and a bit infuriating.  I like that the concept has resonated well with someone else and they have gone to the trouble of borrowing the concept, and repeating or improving or repurposing the concept.

Let me borrow someone else's concept:  "The Bad Artist Imitate, the GREAT Artists Steal." -- Banksy

Most of all the collection of articles are a repository of resources that I do not need to carry around in my 3-4 lbs of white & grey matter.  I can off-load the storage of concepts, research pointers and questions to a semi-perminate storage.  This is a great benefit.

Monday, November 21, 2016

Book Review: The Wisdom of Teams

Introduction:  What We Have Learned

Originally written in 1993, this edition written in 2003 has additional insights from 10 years of working with teams.  The authors see more pragmatism on the subject, less thoughtless rushes to a fad movement.  Top leaders are seeing that teams also apply to themselves, at the top of the business.  They see the core aspect as discipline, not the management fad du jour.  The discipline for team performance has 6 basics: team size, complementary skills, common purpose, performance goals, commonly working agreements, and mutual accountability.  The desire to be a team is not sufficient - one must have performance centric outcomes as the objective.  Leadership is more important at the beginning - but not the primary determinant of success.  Most organizations have untapped potential in team performance.  The organizations performance ethic makes the difference between one-off success and widespread organizational team performances.

The authors develop an explicit terminology, to distinguish commonly misunderstood phrases when discussing groups and teams.  The Y-Chart (p. XXI) helps explain the taxonomy of groups (Effective Group vs Performance Units; Single-Leader Unit vs Real Team).  They define an abstract Team Performance Curve, noting time as the major factor in achieving high (extra-ordinary) performance.  The decision of which type of team; single-leader unit vs team is dependent upon 3 factors: need for collective work products integrated in real time by two or more people, shifting leadership roles for situational awareness, need for mutual accountability in addition to individual accountability.  Setting outcome-based goals is essential to achieving high performance (as apposed to activity-based goals).  Real teams require more time and leadership capacity than single-leader units.  Process support for multiple team opportunities across broad programs is essential to scale the team success from one-to-many.

Prologue:  A Note About What to Expect

The book notes the obvious concepts but also the subtle nature of language used to describe the concepts are required to be precise in defining the discipline.  The authors find that it is difficult to apply common sense to teams.  Expect failure when: building the team for its own sake is the goal (rather that demanding performance challenges), the discipline of “team basics” is overlooked, many areas for teams are left unexplored in organizations (teams: recommend things, do things, run things), teams at the top of organizations are the most difficult, individual accountability is the norm (as apposed to team/group accountability).

Uncommon-sense findings: strong performance standards seem to spawn more teams than teaming-for teaming sake; high-performance teams are extremely rare; hierarchy and teams go together well; teams naturally integrate performance and learning; “teams are the primary unit of performance for increasing numbers of organizations” (p. 5).

Part One:  Understanding Teams

Focusing on Team Basics - figure 1-1 (p. 8)

Apex:  Performance Results; Collective Work products; Personal Growth
Sides:  Skills (Performance results - Collective work products)
Accountability ( Performance results - Personal growth)
Commitment ( Collective work product - Personal growth)
Internal:  Skills - Problem solving, technical function, interpersonal
Accountability - Mutual, team size, individual
Commitment - Specific goals, common approach, meaningful purpose

Chapter 1:  Why Teams?

The authors have learned that although many executives understood the argument for using teams many didn’t extract the real potential from the teams or the opportunities to use teams.  Many times because of unwarranted assumptions and poor knowledge.
Key lessons:
  • “Significant performance challenges energize teams regardless of where they are in an organization.”  Performance is the primary objective.  A team is the means - not the end.
  • “Organizational leaders can foster team performance best by building a strong performance ethic rather than by establishing a ream-promoting environment alone.”  Focus on customer satisfaction performance rather than teamwork performance.
  • “Biases toward individualism exist but need not get in the way of team performance.”  Turn individualism, self-preservation, and self-centered objectives to the benefit of the team.
  • “Discipline - both within the team and across the organization - creates the conditions for team performance.”  “Groups become teams through disciplined action.  They shape a common purpose, agree on performance goals, define a common working approach, develop high levels of complementary skills, and hold themselves mutually accountable for results.”

Teams are made up of individuals with complementary skills - build on strengths, not to cover weakness.  Define clear goals, via team communication. Build real-time problem solving skills and initiative, allow adaptive behavior.  Provide social dimension to enhance work - teams fundamental nature are people interactions.  Fun is part and parcel of the process - encourage it.

Resistance to teams come from 3 primary concerns: ”lack of conviction”, “personal discomfort and risk”, and “weak organization performance ethics” (p 21-23). 

Teams do not solve all problems, they are not the answer to every problem.  They require discipline and practice.  Organization culture may be opposed to teams if a strong individualistic performance is reward in spite of team performance.

Chapter 2:  One Team: A Story of Performance

As a basic unit of performance a team blends the knowledges, skills and abilities of several people strengthening the overall performance of individuals.  Many people having once experienced the power of a high performing team long for the experience again.  Burlington Northern launched the Intermodal Rail era after deregulation in 1981.  Largely the result of a core team of 7 individuals, with an extend group of 45 people.  This team was largely self selective, all were interested in the new prospects of intermodal rail and saw the value even in face of large corporate resistance and hostility.   The team started small and grew as needed, bringing in and fostering the required skills.  A positive attitude that the goal was possible was shared by all.  Hard work and long hours were the norm for the group.  When the group’s proposal was approved but with the worst pilot project locations the group saw the opportunity to prove the concept and jumped right into it.  The core group shared leadership roles and had strong affinity of tacit information on specific skill sets.  They assumed a ask for forgiveness rather than permission attitude, and resolved impediments quickly.  The results was a change in the business model for the industry, intermodal rail is now common place and well established business process for the rail industry. 

Ch 3 Team Basics A Working Definition and Discipline

Teams are a “powerful vehicle for performance” (p. 43)  many companies are embracing teams as a unit of performance.  There are differences in understand of what a team is and what constitutes a performant team.   Teams work well when they have specific results to achieve, and the performance ethic of the organization demans those results.

“A team is a small number of people with complementary skills who are committed to a common purpose, performance goals, and approach for which they hold themselves mutually accountable.” (p. 45)

Small number - in the Agile community we say 7 +/- 2  ( 5 - 9 members).  Reasoning is the tacit knowledge of each other (the group) and the intercommunication of the team.  The larger the number the lower the accountability for success.  Large numbers have logistical problems not seen in smaller groups (space to meet, etc.).  See Also: Choosing the Team Size in Scrum by Agile Pain Relief

Scrum (software development process) offers a way to scale teams to very large (hundreds) numbers.

Complementary skills - we call this a cross-functional team.  A team must have a person with the required skills to solve the problem, and it will take many skills to solve most any complex problem.   Many successful teams realize they lack certain skills, and become self reliant on learning or acquiring the skill set.

Committed to common purpose and performance goal.  Teams must see the purpose for their existence, be motivated to achieve the goal.  The best teams spend significant time discussing their purpose, reshaping it and refining that purpose over their lifetime.

Committed to a common approach.  Agreement on the approach, process to solve the problems is a key,  they may spend considerable time on this issue also. 

Mutual accountability.  Teams must hold each other accountable for the achievement of the goal, the quality of the products, and the process.  They must be capable of defining their own standards for performance and encouraged to raise the bar.  

Ch 5 The Team Performance Curve

A team does not start out at super high performance, it takes time to reach this goal.  Many teams never reach their potential.  Experts say that if a team does reach high-performance that it should not be disbanded but kept together, and given a new purpose.  The performance curve describes this growth to high-performance.

Work groups are not teams, though they may develop into a team.  One difference is the focus either on team performance or individual performance & accountabilities.

Pseudo-teams never agree on purpose, or accountability of the group, they get stuck in rituals and avoid rather than engage each other.

Ch 8  Teams, Obstacles and Endings:  Getting Unstuck

Every team will encounter obstacles, high-performing teams develop tools for overcoming these obstacles.  Teams lower of the performance curve may need help to over come obstacles of all natures.  Teams may become stuck, and not develop the tools to resolve their obstacles, then it is time for serious help.  Stuck teams: lack energy, or enthusiasm, have a sense of helplessness, lack identity, lack purpose, members are cynical, and have a high degree of mistrust.

A weak sense of direction - the team needs to create common goals, take joint responsibility.

Insufficient commitment to performance - team needs accountability for the problem and the solution, based in performance measures.

Critical skills gaps - team needs to hire experts or develop skills.  They must be capable of admitting they need help - identify the type of help and go get it.

Getting unstuck:  - 1) revisit the basic of teams, 2) build on small successes, 3) inject new information and techniques, 4) get facilitation skills & training, 5) change team membership or leader

Transitions and endings will also effect the team, may drop them back into lower stages of Tuckman model of development - allow for that, don’t expect no emotion for losses. 

Monday, October 31, 2016

The Halloween's MVP

Here's the 2016 Pumpkin decorating contest loser.  It's been a real LEAN year for the Scrum team.
Have you heard of a MVP - Minimal Viable Pumpkin?

Minimal Viable Pumpkin (MVP)

Thursday, August 4, 2016

Team Performance Model - by Drexler and Sibbet

Many of you have all heard of the Tuckman model of team dynamics (Forming, Storming, Norming, Performing).  It was created in 1966 and has become the most popular model for describing team behavior.  Is it time to level up in your mental model of team dynamics?  Are you ready for a richer more functional model?

Introducing the Team Performance Model by Drexler and Sibbet

Orientation - Why am I here?
"Orientation is about understanding the purpose of a team and assessing what it will mean to be a member.  you need to understand the reason the team exist, what will be expected of you and how you will benefit from membership.  In a new team, these are individual concerns, because the group is only potentially a team.  that is why these concerns are illustrated as occurring in your imagination at an intuitive level.  As a team leader it is important to provide time and space for people to answer these internal questions themselves."

Keys to when Orientation challenges are resolved:
 - Team Purpose
 - Team Identity
 - Membership

Blocked teams at stage 1 Orientation may show...
 - Uncertainty
 - disorientation
 - Fear

Trust Building - Who are you?
"Trust is a measure of your willingness to work together with others for something important.  Because team members have to depend on each other to be successful, trust is essential in direct relation to how much cooperation is needed to get the job done.  In the beginning of a new team's live, trust involves some risk and uncertainty about dealing with strangers.  This is why the key question is "Who are you?"  An unstated aspect of this question is wondering, "What will you expect from me?"  For a team to work well, you need to accept that you can depend on team members to work together to accomplish the team's purpose."

Keys to when trust challenges are resolved:
 - Mutual regard
 - forthrightness
 - Reliability

When a team is Blocked at stage 2, members may show...
 - Caution
 - Facade
 - Mustrust

Goal Clarification - What are we doing?
Sometimes teams have precise charters that specify what they are responsible for accomplishing.  More often, they are given a broad mandate and nee to make choices about how they will pursue that mandate and translate it into goals.  "What are we doing?"  is a more specific question than the larger question of purpose asked during Orientation.  During this stage of a new team's life, it will need to do research and develop clear understanding of the job that is required, as well as generate agreements about goals and specific deliverables."

Keys to when goal clarification challenges are resolved:
- Explicit Assumptions
- Clear integrated goals
- Shared vision

Blocked at stage 3, members may show....
- Apathy and skepticism
- Irrelevant competition

Commitment - How will we do it?
"When goals are clear and options are identified, your team is probably eager to act.  Attention moves to the question, "How will we do it?"  this stage occurs at the bottom of the "V" in the TPM, the point of the greatest constraint.  This means committing to a specific course of action, making decisions about resources, and being clear about roles.  These are also the indicators of having addressed the "turn".  Remember that the initial stages of team performance involve a good bit of trial-and-error.  Embracing these questions might require backtracking to goals, investing more in trust development, and revisiting initial purpose before you can fully resolve commitment issues."

Keys to when commitment challenges are resolved
- assigned roles
"As your team turns toward implementation everyone will want to be clear about roles and responsibilities. You may have considered these during stage three planning, but now need to commit to what your function, authority, and responsibilities will be in practice.  Role definitions have to be complete enough to cover all the tasks that must be done to accomplish your team goals while minimizing overlaps and role conflicts.  A big part of your job if you are the team leader is to help match goals to competencies, and help people step into roles that will develop their abilities and improve results for the team."

- allocated resources
"In addition to role clarity, your team must deal with another constraint - how to provide for and deploy its limited resources, including time, money, and so forth.  These hard choices usually involve setting aside some useful tasks because the resources are not available to support them.  Indecision in this area breeds confusion and stalls work.  For virtual teams, decisions about tools and communication platforms are essential at this stage.  Teams may have to negotiate with the larger organization to get the kind of tools and support they need.  This is why the TPM intersects the organization "platform" at this stage."

- decision made
"Finally, a team needs to get clear about how members will handle decision making.  Will authority be shared?  How will you stay in touch with one another?  Who can spend what funds?  In a dynamic work environment where plans can change frequently, decision about course corrections are common.  Thinking through in advance how these will be handled moves the team's focus more productively toward implementation and high performance."

Challenges at stage 4, members may show...
- dependence
- resistance

Implementation - Who does what, when, where?
"Implementation involves scheduling and sequencing work over time.  The key question is "Who does what, when, and where?"  A visible schedule, strategy, and / or process liberates the team to move into action confidently.  Conflicts and confusion arise when there is commitment but no clear way forward."

Keys to when Implementation challenges are resolved:
 - clear processes
 - alignment
 - disciplined execution

Team's blocked at stage 5, member may show...
- Conflict
- Nonalignment
- missed deadlines

High Performance - WOW!
"High performance is a WOW state, as a team masters its processes and begins to experience the ability to change goals as well as achieve them.  You can feel when it happens and observe its effects, buy not necessarily control it.  Teams achieve a flow state when trust is high and people have mastered their roles.  In a state of high performance, boundaries and individual limits soften, everything moves together, and everyone responds as if they are part of the whole.  The indicators of that having happened are spontaneous interaction, synergy, and a team that is surpassing their expectation on results.  WOW symbolizes how high performance teams transcend rational processes by working with all the human faculties - spirt, soul, mind, and body."

keys to when High Performance challenges are resolved:
- spontaneous Interaction
- synergy
- surpassing results

When a team is blocked at stage 6, members may show...
- Overload
- Disharmony

Renewal - Why continue?
"Over time the conditions that initially set your team in motion will change.  High Performances is demanding.  Don't be surprised if people ask, "Why continue?"  this key question reminds us that team performance is an ongoing process, and must be renewed by returning to Stage 1 and reassessing if the work is still needed, worthwhile, and has some personal value and meaning.  Spending time on renewal puts your team back in touch with meaning and purpose and refreshes everyone's commitment to keep going.  It also includes learning from what you have accomplished, and building a repertoire of best practices for the next journey on this or other teams.  If your team's work is completed, Renewal is the time to wrap things up, freeing members to move on to new challenges."

Keys to when renewal challenges are resolved:
- recognition and celebration
- managing change
- staying power

When team's are blocked at stage 7, members may show...
- boredom
- burnout


This is just a taste of the awesomeness of Sibbet's book on visualizations and exercises to build great teams.  Want to know more - read the book.  You will learn lots about how team move forward and backward toward performance.  And the exercises to work with teams to help them share their understand of where they are, where they are going and what might set them back are very well explained.

    Reference:  Visual Teams - Graphic tools for commitment, innovation, & high performance by David Sibbet.

See Also:

Jay W. Vogt of Peoplesworth explains the Drexler Sibbet Model of team building and how it can result in a positive outcome. YouTube

Wednesday, June 22, 2016

Team Metrics - Case Study

Let's look at an info-graphic of a beginning team's metrics and use this as a case study in Scrum Team Metrics.

Description of charts:

Burndown chart - a daily count of the number of task units (aspirin is this teams selected units for task estimation) not done.  This includes the task yet to be started, and task in process.

Tasks in Process - a daily count of the number of tasks in process.

Tasks Done - a daily count of the number of tasks that are done.

Stories Done - a daily count of the number of Stories that are done.

Velocity - the empirical measure of Stories that are considered done by the team and accepted as done by the Product Owner during the Sprint Review.

The Back Story on this team:

This team had been attempting to do some form of ad-hoc Scrum / Kanban with little guidance and understanding of the process.  The Kanban aspect came from the company's tooling (RTC) template - not from any real practices the team was implementing.   After some weeks of observations and workshops with the team - they decided to "hit the reset button" on doing Scrum.  Sprint One in the info-graphic is the first sprint right after a week long workshop on learning Scrum practices and principles.  Key to this team's adoption of Scrum is their adoption of a physical task board (see also Elements of an Effective Scrum Task Board).

Observations on Sprints:

Sprint One - Started with many stories from past sprint that were not yet done - as the team had no empirical data of velocity we guessed at how many stories we could complete in the 2 week sprint, and chose 15 stories.  At this point we had 4 product silos where people we working within the silo to deliver the stories - very little cross team collaboration.

Rules silo
Sprint Two - Tear down the silo walls - the team decided that the original silos of working was harming a long term desire of cross-functional team members - so a removal of the silo walls (tape on the scrum task board) happened.

Sprint Three - Enforced the use of empirical data to constrain the team's selection of how many stories to bring into the sprint (team select top 5 stores and finished all of them).

Sprint Four - Team planed for 30 points of stories but finished early and pulled in additional stories and finished them within the sprint.

Objectives for the Team:

This teams objectives for hitting the reboot button on a scrum implementation was to achieve a consistent level of reliability to deliver value (stories) to the business.  Also to maintain and supporting the existing 4 products line internal organizational clients, and transitioning tacit knowledge from several remote employees to the team and increasing cross-functional capabilities of the team members.

Commentary on Metric Charts:

Burndown - Sprint 1 and 2 task burndown charts show that the team started with around 100 aspirin and discovered between 50 and 100 aspirin more by doing the work - but didn't finish the 15 stories and left lots of stories started but incomplete at the end of the sprint.  In sprint 3 and 4 the team had developed the ability to forecast the proper amount of work to pull into sprint planning and were able to deliver the completed stories.

Tasks in Process - this simple metric showed that the team of about 8 people were consistently task switching.  There are many "reasons" (excuses) for this behavior, and it is a hard habit to correct in this era of high utilization rate driven management.  Just tracking this metric had little effect on the teams behavior - however we had empirical data that other practices (avatars, re-estimating in process tasks, etc.) had a positive effect upon this metric over several sprints.

Tasks Done - this metric is redundant for a team using a traditional sticky note task board.  In general this reflects the sprint burndown.  It does point out for this team that tasks done stalls out when there support tasks flare up, as these support (maintenance and production, M&P) issues require task switching to the more urgent unplanned work.  Reflecting upon this metric lead the team to start tracking the planned tasks separate from the urgent support tasks in our burndown chart for sprint 5.

Stories Done - an interesting trend shows up in this simple to trend metric.  The team was capable of finishing 5 stories, regardless of how many they planned.  In sprint 3 when the team constrained the planning to the empirical evidence (~28 points, 5 stories) they had there first successful sprint (on time, on budget, with planned scope).

Capabilities developed by the Team not shown in these Metrics:

Tasking - working toward tiny tasks.  Within the first two sprints the focus was to develop the ability to task stories.  Several synergic practices lead to this capability - re-estimating each time the task is touched in stand-up; recognizing that task that last for several days are way-too-large;  learning to decompose tasks that are too large; realizing that doing work leads to discovery of new tasks that need to be recorded and added to the board.  See Also: What belongs on the TASKS board?

Single Piece Flow - working on a task until it is done.  Smaller task effect this behavior in a virtuous manner.  Re-estimating each day makes the antithesis of this pattern apparent, and also offers the opportunity for team members to recognize when help is needed.  The use of avatars on the story tasks reinforces the practice of lowering work in process and reducing task switching.

In Sprint 5 the team decided to move from a 2 week time box to a 3 week sprint. The charts also show the support (M&P) tasks tracking independently of the planned tasks and the new chart at the bottom (M&P task vs Planned task deltas per day) indicates the inverse relationship of the priority shifts the team has to deal with.

Next Objectives:

Develop the capabilities to deliver agile release plans and forecast feature release time frames for business coordination with other teams that depend upon the infrastructure product lines developed by this team.

At the team coaching level an objective is to measure cycle time of stories within scrum teams.

See Also:
Metrics for a Scrum Team - 10 suggested metrics and examples
Measuring Process Improvements - Cycle Time by Mishkin Berteig, June 2008

Monday, April 25, 2016

Exercise: Estimate Number of times you can Fold a Paper in Half

An Exercise in Estimation:  How many times can you fold a piece of paper in half & half again...

I do this exercise when beginning scrum teams start story estimation or task estimation.  While this exercise has a unique twist that is very different than task estimation or story estimation - very few people foresee this aspect of the exercise, so it adds to the ah-ha moment.

Start by giving everyone a sheet of typical paper (8.5 x 11 in the USA - although the size just doesn't matter).  Then tell them the exercise but ask that no one do any thing yet.  First we will estimate.  The task is to estimate how many times you could fold the paper in half and then again in half and repeat... without doing it what's your estimate of the number of folds?

Ask people to call out their estimate, write then on a board in no particular order or fashion.

Typical groups come up with estimate in the range of 5 - 20 folds.

If you want to do math... calculate an average estimate... or just circle the mean value.

Next have the group fold the paper in half and half again up to 4 times - then STOP and estimate again.  Same as last time - call out the estimates and write them down on the board.

Next - fold the paper until you are done.  How many folds did you get?

Now the debrief:  What did you learn in this exercise?  What happened to the estimates - why did this happen?  What generalizations of estimating can we learn from this example?  So when do we practice this re-estimation technique in Scrum?

For BONUS points - how many times do you need to fold paper to get to the Moon?
How Folding Paper Can Get You to the Moon
How Folding Paper Can Get You to the Moon

See Also:

MythBusters episode: Folding a large piece of Paper in Half - What's the Limit
Myth Busters

Moon Scoops - Buzz Aldrin on the things you do not know about the Moon Landings - Late Night

Saturday, April 23, 2016

How to lose customers via failure of your core business proposition

Just last month I receive a congratulatory letter from REI MasterCard - 10 years of a mutually beneficial business relationship ....  until .... chaos ensued (thank you Mr. Mayhem).  So I accepted the opportunity to communicate with my business lender on an incident that made me very dissatisfied with their policies.

Subject: Re: Congratulations on your REI World MasterCard anniversary! 
Thank you Robert,
     Just to let you know - I’m sure this will interest you - I will shortly be canceling my 10 year relationship with REI MasterCard, because of the quality of service you have just required me to deal with. I’ve got a great payment history and have been using our card to pay bills on line and automagically for years. Recently through my oversight, I forgot to pay my bill on time. So in response to this great customer who always pays his bills and once in 10 years paid late, your organization saw fit to block all payments, causing further confusion and customer / client dissections with your service level. When I called in to rectify the situation your senior rep. could not do anything to help - your policy prevented customer satisfaction. Said policy created even more denied automatic payments for my accounts, creating a snowball of unpaid bills. All from a company that is in the business of extending credit. This is unacceptable. So I will be canceling my relationship and moving to VISA. 
David Koontz, very unhappy customer.
Here is the response I received from the Office of the President, US BANK Cardmember Service

One technique for losing customers is to make the very nature of your core business proposition an oxymoronic meme.  Let's use this US Bank - REI Credit Card issue as a case study.

The back story:  I've been a REI Credit Card user for around 10 years, I've built up a very good customer relationship, paying bills on time for those year, sure there may have been a slip through the cracks from time to time, yet my credit score reflects that I'm a very sound risk for credit.

So when a job transition happened in the sprint of 2016 there was much confusion with cash flow and various credit cards transition from one service vendor to another (seems as if Master Card is losing clients to VISA) and Costco moved away from Am Ex.  Lots of changes in the card industry.  These had various impacts upon my personal fincianal life...

Some few years ago I started moving auto pay bills to my REI card (US BANK) we loved the cash back rewards at one of our favorite shopping stores, REI.  So by 2016 almost every bill I get, from water bills to Amazon to Apple App Store to Netflix etc. is on the card.

Now in March, I missed the $30 min. payment to US BANK.  So in silence they blocked all debits and transaction to the card.  There was no communication to me about such a significant event.  However, I get plenty of alerts of various natures, such as payment due, minimal balances, large transactions, etc.  But, for unknown reasons explained by the Office of the President, they are just unable to communicate with customers about this type of event.

I've canceled the card.  Kinda hate to lose the REI relationship, but they have not responded to any inquiries either.  In today's credit industry there are plenty of reward programs to choose from and I've made other arrangements - did all the work to transition payments away from US BANK's card to a USAA Signature card.  Maybe I'll probe that system and see how they respond to a missed payment.

So what would US BANK needed to have done to keep a 10 year customer?  A simple alert - your account has been frozen because of late payment.  AND then been able to recognize a good customer and rectify the issue over the phone - by extending credit and reinstating the account with the promise of the check is in the mail.  After all their core business proposition is extending credit.

Full Disclosure:  I own MasterCard stock as well as Amazon, Apple, Costco, Netflix.

Thursday, April 21, 2016

the Failure Bow -or- how to love the experience of learning

I learned this technique from the facilitators of Language Hunting and Where Are Your Keys, they term the technique How Fascinating  and practice it quite a few times each game.

The purpose of the technique is to invert the physiology of failure into a learning moment to reflect upon what just went wrong and instead of cringing and curling up into a safe ball, we open up the body and the mind to learning and the experience of reflecting and allowing the universe to teach us something.

Try it a few times...

See Also:

Go Ahead, Take a Failure Bow by Beth Kanter at HBR

TED Talk:  The unexpected benefit of celebrating failure
"Great dreams aren't just visions," says Astro Teller, "They're visions coupled to strategies for making them real." The head of X (formerly Google X), Teller takes us inside the "moonshot factory," as it's called, where his team seeks to solve the world's biggest problems through experimental projects like balloon-powered Internet and wind turbines that sail through the air. Find out X's secret to creating an organization where people feel comfortable working on big, risky projects and exploring audacious ideas.

Psychometric Assessments - a peek inside the person

What do you think & feel about personality and behavioral assessments?  Are they useful to you?  Can you share them with others to help improve your relationships?  Do you have the courage to put your personality on display for your collaborators to inspect?

Well I thought I'd try to open the kimono to see if it helps me...

I've studied Psychometric assessments and some I find useful, some I feel are just a step to the left from astrology charting.  Yet might not be harmful for self reflection.  I've also found that it takes an expert to explain the tools and reports such that a layperson can understand and make positive use of the assessment and it's report.  And while I've been "certified" is some of these tools/technique I do not practice them enough to be competent - and my pitch is akin to a snake-oil salesman.

Here is my DiSC Classic profile:

DiSC Classic by Wiley
Here is my Trimetric assessment (DiSC, EQ, Motivation) by Abelson Group

DiSC Wheel
Motivators Wheel

Emotional Quotient Wheel

Here is my Myers Briggs Type Indicator - Level II assessment:
MBTI Level One
MBTI Level II reports

Here is my EQ 2.0 - Emotional Intelligence:

EQ 2.0 by

TalentSmart, Inc.
Here is my Action & Influence report:

Here is my Personalysis assessment:

Personalysis assessment
Here is my Strengths Finder 2.0 by Gallup (Tom Rath) assessment (2012):
  • Learner
  • Self-Assurance
  • Arranger
  • Ideation
  • Relator

See Also:
Authentic Happiness - resources in Positive Physiology - 20 assessments

Psychometric testing resources

British Psychological Society’s Psychological Testing Centre (PTC) provides information and services relating to standards in tests and testing for test takers, test users, test developers and members of the public.

National Cultural Studies - assessments at the meta level - the personality and behaviors of nations.