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

Mayhem
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 may 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.


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


See Also:


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.


Tuesday, February 2, 2016

Q: What is an Agile Transition Guide?

I was at the Dallas Tech Fest last week and was asked several times what an Agile Transition Guide was (it was a title on my name tag)... it's surprising to me how many people assume they know what an Agile Coach is, yet there is no good definition or professional organization (with a possible exception coming: Agile Coaching Institute).

So naturally the conversation went something like this:

Inquisitive person:  "Hi David, what's an Agile Transition Guide?  Is that like a coach?"

David:  "Hi, glad you asked.  What does a coach do in your experience?"

Inquisitive person: "They help people and teams improve their software practices."

David:  "Yes, I do that also."

Inquisitive person: "Oh, well then why don't you call yourself a coach?"

David:  "Great question:  Let's see...  well one of the foundational principles of coaching (ICF) is that the coached asks for and desires an interaction with the coach, there is no authority assigning the relationship, or the tasks of coaching.  So do you see why I don't call myself a coach?"

Inquisitive person: "Well no, not really.  That's just semantics.  So you're not a coach... OK, but what's is a guide?"

David:  "Have you ever been fishing with a guide, or been whitewater rafting with a guide, or been on a tour with a guide?  What do they do differently than a coach?  Did you get to choose your guide, or were they assigned to your group?"

Inquisitive person: "Oh, yeah.  I've been trout fishing with a guide, they were very helpful, we caught a lot of fish, and had more fun than going on our own.  They also had some great gear and lots of local knowledge of where to find the trout."

David:  "Well, there you have it... that's a guide - an expert, a person that has years of experience, has techniques to share and increase your JOY with a new experience."

Inquisitive person: "Yes, I'm starting to see that difference, but can't a coach do this also?"

David:  "No, not unless the coach is willing to switch to a different modality - to one of mentoring, teaching, consulting, or protecting.  Some times a guide must take over for the participant and keep the person/group within the bounds of safety - think about a whitewater river guide.  A coach - by strict interpretation of the ethics, is not allowed to protect the person from their own decisions (even if there are foreseen consequence of this action."

Richard FeynmanAnd now the conversation start to get very interesting, the Whys start to flow and we can go down the various paths to understanding.  See Richard Feynman's dialogue about "Why questions"

So, I'm not a Coach

I've been hired as a coach (largely because the organization didn't truly understand the label, role, and the ethics of coaching).  This relationship was typically dysfunctional from the standpoint of being a coach.  So I decide to study the role of coaching. I've done a few classes, seminars, personal one of one coach, read a lot and drawn some conclusions from my study - I'm not good a coaching within the environment and situation that Agile Coaches are hired. I've learned that regardless of the title that an organization uses (Agile Coach, Scrum Master, etc.) it doesn't mean coaching.  It intends the relationship to be vastly different.  Since I'm very techie, I appreciate using the correct words, and phrase for a concept.  (Paraphrasing Phil Karlton: In software there are two major challenges: cache invalidation and naming things.  Two Hard Things)

So to stop the confusing and the absurd use of the terms, I quit referring to my role and skills as coaching.  Then I needed a new term.  And having lots of friends that have been Outward Bound instructors and understanding their roles, the concept of a river guide appeals to me in this Agile transformational role.  Therefore I coin the term Agile Transformation Guide.  But many organization do not wish to transform their organization, but they do wish for some type of transition, perhaps from tradition development to a more agile or lean mindset.  So a transition guide is more generic, capable of the situational awareness of the desire of the organization.



See Also:

Where Agile goes to Die - Dave Nicolette - about those companies that are late adopters or laggards in the innovation curve and the challenges that "coaches" have when engaging with them.
The Difference Between Coaching & Mentoring

Scrum Master vs Scrum Coach by Charles Bradley

Agile Coach -or- Transition Guide to Agility by David Koontz; the whitewater guide analogy to agile coaching.

Academic paper:  Coaching in an Agile Context by David Koontz

What is the ROI of Agile Coaching - Payton Consulting

Interesting Twitter conversation about the nature of "coaching" with Agile42 group.



Monday, October 26, 2015

HBR:: Why Organizations Don't Learn

A nice article on HBR - "Why Organizations Don't Learn", by



  • Francesca Gino and 
  • Bradley Staats; take a look.
    They list these reasons:

    • Fear of failure
    • Fixed mindset
    • Over reliance on past performance
    • Attribution bias


    The authors then give some strategies for overcoming these reasons for the lack of learning.  Many of these will be familiar to the agile community.


    See Also:
    Pitfalls of Agile Transformations by Mary Poppendieck
    Knut Haanaes - Two reasons companies fail - TED Talk AND how to avoid them:  Exploration & Exploitation