Latest Entries »

Mark Lawler in his post about story points, says he wants to “raise a glass of Champagne to toast the folks who came up with the concepts of ‘story points’.  You know that way of estimating work without actually saying anything useful or making any commitment to your business customers?”

I can certainly see how the whole idea of stories and story points can be confusing, especially to new teams and certainly to business customers.  But, I would like to offer a counterpoint and say story point estimation is a very useful, and efficient technique. 

Teams are asked to make a binding estimate, generally, at the beginning of a project, when they have the least amount of familiarity and information about a project.  Here is how Scott Adams illustrates this point through Dilbert:
 
 
Let’s look at what a story is.  A story is a bite-sized, digestible “requirement” that can be completed in a time-boxed interval.  It is stated from a perspective of a real user.  A story is just enough information written down and a promise between the product owner and the delivery team to have a future conversation about the rest.  Both the product owner and the team understand that there is some amount of uncertainty involved.  The product owner is not expected to know every detail of the story upfront, and the team doesn’t always know how they are going to produce that work.
The alternative used to be a detailed business requirements document or a product requirements document.  The PM and the business stakeholder then use these documents to obtain an estimate from the delivery team.  Or many times, engineering managers or leads arrive at these estimates, even though, they might not actually do this work themselves.  Teams are then held to this estimate, no matter what new information the team learns about themselves and about their project as it unfolds.
So how good are humans at estimating in absolute terms?  See if the following conversation sounds familiar to you:
An engineer’s significant other is preparing tacos for dinner.
Significant Other: How many tacos should I prepare for you, 3 or 4?
Propeller-head Engineer:  Well, let me see, I am a little hungry.
Significant Other: So 4?
Propeller-head Engineer:  I am not sure.  I had a smaller breakfast than usual.
Significant Other: So you are really hungry?  Make 5?
Propeller-head Engineer:  But, then I had this big lunch when I went out with my friends.
Significant Other: So then…3?
Propeller-head Engineer:  But, see I then went to the gym in the evening?
Exasperated Significant Other: So you’re hungry again?
Propeller-head engineer:  But, see my workout was really “light”.
Angry Significant Other: Then you are not that hungry?  Darn it, Propeller-head, will you just tell me how many tacos do you want to eat?
Propeller-head Engineer:  Tell me what kind of beans are you using?  Are you using sour cream, or guacamole?  How caloric is the salsa?
So when it comes to estimating and committing, we tend to over-analyze and take too much time to arrive at a precise answer.  On the other hand, we are actually good at comparing.  Back to the Significant Other and Propeller-head Engineer:
Significant Other: Damn it. Propeller-head, why do you always have to be so difficult?  Tell me, are you hungrier compare to last Friday, when we had tacos?
Propeller-head Engineer:  Yes I am.
Significant Other: You ate 3 tacos then.  How much hungrier are you compare to then?
Propeller-head Engineer:  I am little more hungrier than that, so let’s go with 4.
Bam, having a reference point helped speed things along (that or it must have been the wrath of the Significant Other)!  Estimating is relative sizing, so a team compares one story to others and arranges in generally like-sized groupings.  The story points are just a numeric values we assign to these piles.  Three considerations go into sizing a story:  effort, complexity and doubt.  So along with effort and complexity, uncertainty is built into these estimation.  What was the alternative in the past?  As other agilists have pointed out – the delivery teams were trained  in stating precise inaccuracies.  At the inception of a project, when the agile team and the business partners have the least amount of information for their projects, if we ask them to be prescient and produce accurate estimates; they will produce estimates, and precise ones, at that.  Just not accurate ones!
 
For example, I was just reminded, at a recent training, regarding the concept of accuracy and precision.  If I state that the value of Pi is 3.7909430, it is very precise, but it isn’t very accurate.  If I say 3, I am accurate, but not very precise.  When we are doing newer things, we are not always so good at them at first.  We, in the software business, to use an analogy, are more like chefs, and less like short-order cooks.  Chefs concoct new recipes, so it is hard in beginning to accurately and precisely figure out how long it will take to come up with a winning recipe.  A short order cook on the other hand, is handed a recipe and has a pretty good idea of how much time it will take to cook up the recipe.  Software engineers, if they are more familiar with their problem domain, can become more accurate as well as precise.
Picture a conversation between a PM and a delivery team:
PM: We need to produce an estimate to develop an integration with our business partner.
Delivery Team: Ok, do you have the integration specs? Do you have API Specs from the partner?
PM: No we don’t, but assume that we will communicate via FTP.
Delivery Team: And how many “functions” do you think we are going to need.
PM: Assume about 10 functions.
The delivery team talks amongst themselves.
A Dev Type: Let me look at our existing code for an hour – and I will tell you.  He returns two hours later.
Dev Type: Look, we already have done this type of work.  The existing sFTP protocol we  developed has about 15 functions, which took us about 6 weeks to develop and test,  So I think, we can turn this around in 2 weeks.
A test type:  And it will take me 2 weeks to test.
Delivery Team to the PM: We can do it in 4 weeks.
PM: Well guys, sorry to break this to you, but we need this within 3.5 weeks, otherwise, we will be off our critical path.
Two weeks later.
PM: Hi guys, the specs came in, our communication is via a web service.
A stunned Delivery Team: But, we haven’t done any web services development, and certainly not with this partner.  What’s more, the infrastructure folks alone are going to need a week to open up the firewall and communicate with our partners.
PM: I know guys, this is tough.  Oh and one other thing – since we got the specs a little later than expected, we will need you to get this done within next 3 weeks.  Sound good?  Thank you guys, you are the best team I have worked with.  I know you will come through.
 
The PM, in the above example shorten the duration, but did not take into consideration the effort involved.  This generally happens when stories are express in ideal days – effort or duration get enmeshed.  Or at least, effort gets overlooked.  in which case earth days, become just as arbitrary as story points.  Comparing one team’s estimate against another becomes just as problematic as with story points.
Extending Mark Lawler’s airlines example, if say you were giving an estimate of 30 minutes delay, both times.  But say, by two different airlines – Southwest Airlines and United Airlines, which one would you trust?  Most people would probably pick Southwest as they have a stellar on-time record.  With United, who knows?  Unit of measurement is still hours, but Southwest and United Airlines estimates aren’t comparable as United doesn’t have a comparable on-time record.
 
With story point, if our customers have another key piece of data – the team’s velocity, they can also start getting better predictability.  Even when plans change, which we know, they inevitably, do.  Let’s say for example, an agile team estimates its release backlog contains stories worth 100 story points.  After sprinting for 3 sprints, they establish their average rolling velocity to be 10 story points per sprint.  Now based on this, the product owner will know that it will take another 7 sprints to exhaust the backlog (70 remaining points).  But, let’s say if the product owner estimates her “must have” story cut line is at 60 points.  She can now see that her team can achieve this with 3 more sprints (30 story points achieved and 30 more expected).  If she thinks of adding 5 more story points of “must have” scope.  She can also predict that it will take 4 more sprints (65 total must have story points).  Or say, if she wants to de-scope 10 must have story points, she can predict that the team can deliver this in 2 more sprints (20 remaining must have points).  What’s more, she doesn’t need to go back and worry about the fact that Ralph is taking a 3-week vacation or that Sally has a series of 2-hours doctor’s appointment.
 
Credit Clark and Vizdos
 
Story points, combined with team velocity, can produce fairly accurate estimates, faster.  In order to get better at estimating, more often than not, the contributing factors are that a delivery team stays constant, understands their problem domain, establishes a rhythm, and constantly inspects and adapts.  They can get better at estimation, irrespective of whether they use points, “gummy bears”, earth or martian days!  But, estimating in story points, has an advantage of not spending a whole lot of time in arriving at precise but inaccurate estimates, and avoid the trap of confusing effort and duration when contrasted with estimating in days.
 
And one last thing, just the other day, the cable guy promised he’ll be there to repair cable service, some time between 8-12pm (not very precise) and showed up at 130pm (not very accurate, either)!

Just One More Level

TaeKwonDo Practitioners (© Aashish Vaidya)

As transition goes, shedding the old ways and adopting new ones are fraught with doubt and confusion.  This is true of any large organization transition effort as it is for scaling agile practices across the enterprise.  One of the challenges for enterprise transition community leading this change effort is figuring out how to move people with different understanding and different needs from novices to experts.

Many times, a model or a construct of learning helps us classify how to approach people with different levels of understanding and teach them new techniques.  Alistair Cockburn introduced the concept of Shu-Ha-Ri to software development.  Shu-Ha-Ri is borrowed from the martial art practice of Aikido.

Here is how Martin Fowler describes it:

Shu-Ha-Ri is a way of thinking about how you learn a technique. The name comes from Aikido, and Alistair Cockburn introduced it as a way of thinking about learning techniques and methodologies for software development.

The idea is that a person passes through three stages of gaining knowledge:

  • Shu: In this beginning stage the student follows the teachings of one master precisely. He concentrates on how to do the task, without worrying too much about the underlying theory. If there are multiple variations on how to do the task, he concentrates on just the one way his master teaches him.
  • Ha: At this point the student begins to branch out. With the basic practices working he now starts to learn the underlying principles and theory behind the technique. He also starts learning from other masters and integrates that learning into his practice.
  • Ri: Now the student isn’t learning from other people, but from his own practice. He creates his own approaches and adapts what he’s learned to his own particular circumstances.

One of the common refrain you hear from many people who have learned some basics about agile methodologies is to say, ” see we understand the agile practices, but how are we going to do this differently here?”  The questioners, here might presuppose that certain practices just won’t work in their environments and want to start tailoring things right out the gate.  Especially, when they have learned that agile is all about adaptability and change.  So there is this predisposition to jump to the Ri stage.  But, agile practices are supposed to be an experiential process.  You do things, reflect on what worked and what didn’t , in short you inspect and then you adapt.

But, many balk at directive practices in the Shu state as it run contrary to the agile manifesto, itself.  Here is Rachel Davies, co-author of Agile Coaching who takes on other agilists, in a post  called Shu-Ha-Ri Considered Harmful:

I’m uncomfortable with approaches that force students to follow agile practices without questioning. These approaches seem to violate the first value of the Agile Manifesto “Individuals and interactions over processes and tools.” I question whether introducing agile software development techniques to people is anything like martial arts training. Software development is knowledge work and our aim is to build a team of reflective practitioners. To do this we need to engage with how people think about their work. Are techniques from physical arts that build muscle-memory really applicable here?

For me, agile Boot Camps and Shock Therapy approaches lack basic respect for the team’s unique context and the experience of people on the team. Agile software development is a much looser discipline than a martial art like Aikido. Organizational culture and nature of the product being built are major factors in what agile techniques the team will benefit from most. If we establish a sensei-novice model, we’re not fostering the independent thinking and reflection that will take the team beyond the Shu level.

To some extend this is a valid argument.  You have to respect the individuality of the team members and allow them to question the practices they are supposed to be following.  And invariably boot camps and shock therapy approaches will only have an ephemeral effect like a motivational speech would.  You are pumped up for a while and get a boost of energy, but the sugar high wears off quickly.

But at another level, this is a very shallow read of martial arts and the sensei-novice model.  Even cursory look at history of martial arts would suggest that they are not merely about physical activity, but means to develop deeper connection to moral and spiritual dimensions.  Just as you wouldn’t confuse the practice of yoga to be only about physical well-being.  That is just an aspect called hatha yoga , but in larger context yoga has much more to do with “knowledge work” than building simple muscle memory.  Albeit, the knowledge is different, not software development variety.

The issue isn’t necessarily with the Shu-Ha-Ri construct, but how it might be used within the context, and it is more about its understanding and its implementation.  Further on in the post, Davies calls out the real peril:

Installing a basic set of agile practices by force can be done quickly so the organization starts getting benefits from new ways of working faster. Teams are superficially at the Shu level in the space of a few weeks. Often, the management team considers the agile rollout is now complete. It’s assumed that teams will continue to apply what they’ve learned. But without any experts around to enforce agile practice, pretty soon a team falls back to their old ways or sometimes worse carries on with agile practices that don’t make sense for their project.

I was pleased to see “cargo-cult agile” called out in the new book “Practices for Scaling Lean & Agile Development” by Craig Larman and Bas Vodde. They say “Avoid forcing–When coaching we encourage: volunteering; do not force any agile or lean approach onto people; people should be left the choice to think and experiment…with concentrated long-term, high quality support. The best, the most sticky adoptions we have seen had this approach.”

In a large organization, there is rare chance that you will encounter people who do not fall into all three categories of learning: the complete novice, who just wants to be told what should he do next; the intermediate, who knows agile practices well enough to start digging into deeper underlying theory and principles; and experts, who are adept at reading the context and tailoring their own practices to continually achieve business goals.  For enterprise transition community leading adoption of agile in their enterprise, the goal is obviously to encourage people to think critically, experiment and continuously learn, and deftly deal with people at all 3 levels.  Anders Ericsson, a cognitive psychologist, who developed the popular “ten thousand hours” theory of mastery has a second prerequisite for expertise – “the notion of deliberate practice, which describes the constant sense of self-evaluation and a consistent focus on one’s weaknesses rather than playing on one’s strengths (ref Maria Popova’s blog post).  This notion is something the enterprise transition community and agile coaches need to be aware of, and one which our software brethren who design video games understand real well:

[The “zone of proximal development” is] the idea that learning works best when the student tackles something that is just beyond his or her current reach, neither too hard nor too easy. In classroom situations, for example, one team of researchers estimated that its’ best to arrange things so that children succeed roughly 80 percent of the time; more than that, and kids tend to get bored; less, and they tend to get frustrated. The same is surely true of adults, too, which is why video game manufacturers have been known to invest millions in play testing to make sure that the level of challenge always lies in that sweet spot of neither too easy nor too hard.”

The challenge, then is to figure out a mix of practices that you know the teams will be able to take on, and add that 20% “stretch” practices, which allow the teams to flex and get to another “level”.  And hopefully soon, they will internalize what gamers who are hooked – they beg for that 5 extra minute to complete one more level!

Rachel Davies continues:

Learning new ways of working takes time.  As Ron Jeffries once said “They’re called practices for a reason.  You have to have done them. Practice makes perfect.” If you base an agile adoption on Shu-Ha-Ri model, the trick is to remember the goal is beyond the first-level. Your teams need more than training. Allow plenty of time and on-going coaching support for teams to get them into the Ha phase and beyond.

The constant care and feeding of agile teams will be needed at least till the organization moves through the Ha stage.  After all, you come across many agile teams, who have practiced agile for years, but are stunted in their growth.  These teams are upper bound to their organization’s proficiency in new techniques and inextricably linked to its culture, its inertia and change aversion, which doesn’t allow continuous improvements to take place.  So then the Shu-Ha-Ri model can still be useful model, provided that the community understands that you have to look beyond the rollout of initial agile training and project kickoffs.

PS: A parting note, though this was much before my time, if you want to see Ri practitioners in action, then watch the video of these two cats, who delivered a 90% improvised piece, but still based on an underlying musical framework.  They are still grounded in the principles and theory of their craft, but their uniquely tailored performance fits the context, and with their virtuosity, they transcend the rules to create a masterpiece – in essence, they make their own rules.

You Might Not Be Agile if…

At a Software Association of Oregon presentation in Portland this month (Feb, 2012), Frank D’Andrea, Product Owner, Studio D at Waggener Edstrom Worldwide presented an entertaining and informative presentation on Agile Sucks: Why Everyone Should Use Agile.  You can also watch Frank’s 5 minutes version of the presentation delivered at IgniteSAO last fall.

During the Q&A session, one questioner asked whether he had a list of agile anti-patterns that he can share?  Frank jokingly suggested whether she was looking for a list along the lines of Jeff Foxworthy’s routine, “you might be redneck, if….”.

So along those lines, here is my quick list of agile anti-patterns:

You Might Not Be Agile if…

  • you think daily scrums are optional
  • you think daily scrums are colloquiums
  • you come across impediments and not raise them
  • you raise an impediment and your ScrumMaster ignores it
  • your Product Owner tells you to commit on more stories, and you do, even though your team has never acheive that high velocity, ever
  • you have zombie stories that keep coming alive every iteration
  • the lonesome development team member with testing expertise has nothing to do for 8 days in 2 week iteration and he has 60 hours of work  to complete on the last day of the iteration.
  • your retrospectives are turning up same issues over and over again
  • you have pluses and minuses list from your retrospective but not an action items list
  • you are not experimenting with something new or different every iteration

Comic strip credit: Michael Vizdos and Tony Clark (http://www.implementingscrum.com/)

There are probably innumerable anti-patterns you can think of.  As a matter of fact,  I came across an hilarious anti-pattern video called Sh*t Bad ScrumMaster Say .  The video creator Adam Weisbart looks to be putting out a book on agile antipatterns, soon.

Nick Crocker gave a TEDx presentation on Change titled “Floss the Teeth You Want to Keep”.  This talk makes a good companion piece to the 3 of the previous posts:

Willpower to Change is an Exhaustible Resource; Resistance is Futile…; and, Shape the Path to Make Change Stick.

Nick notes 10 things that make change easier:

1. It is easier to add a new behavior than stop an old one

2. Single changes, for a fixed time (Don’t overload your change muscle).  A habit needs 21 days to form (give it 42 days)

3. Baby steps.  Turn goals into activities

4.  Chains of change

5. Create  triggers

6. Measure the change (external)

7. Never change alone

8. Don’t forget the sticks

9. Change your environment

10. Change takes patience

Here is the talk:

Corn Field, Sauvie Island, Oregon (© Aashish Vaidya)

Back in 1930s, the Great Depression and the Dust Bowl – the dual economic and environmental degradation – caught small family farms into its vicious grip.  To reverse this devastating effects on farmers, the federal government enacted farm subsidies “aimed at helping small family farms”.

Fast forward decades later, the well-meaning policy that sought to help small farms is now producing unintended consequences and counter-productive outcomes.  An USDA publication notes that over those last decades, the total number of the farms has declined from its peak of 6.8million to 2.1million by 2002.  Increasingly, large operations make up to 73% of the production value, even though; they constitute only about ten percent of 2.1million farm operations.  These small number of operators controlling a higher concentration of agriculture production value also produce political clout.

Mike Russo of U.S. PIRG Education Fund in his white paper Apples to Twinkies: Compare Federal Subsidies of Fresh Produce and Junk Food, notes:

Since 1995, taxpayers have spent over $260 billion on agricultural subsidies. Reflecting the political clout of the biggest producers, the lion’s share of the dollars go to a very small number of larger operations – roughly 74% of subsidies go to 4% of U.S. farmers. These large operators, who are recipients of federal subsidies may then turn around and use the money to buy out more small farms.

So, now you have a situation of the original intent of incentive completed subverted and turned upside down. Instead of helping smaller farms, it actually hurts them!

USDA is responsible administering subsidies and making nutritional recommendations for a healthy diet. USDA has replaced the food pyramid with a food plate, which now shows that a balanced diet should be equal parts fruits and vegetables and equal parts grains and proteins. However, USDA doesn’t quite distribute its aid in accordance with its own food plate recommendations. States Mike Russo, USDA “distributes considerable federal financial support for the [grains and proteins], and virtually none for the [fruits and vegetable].” Since 1995 to 2010, the US taxpayers have put up $260 billion in agriculture subsidies.  Notes Mike Russo:

…by far the lion’s share of taxpayer dollars go to subsidizing a few commodity crops. Of the $260 billion spent since 1995, a full $77 billion went to subsidize corn; wheat and cotton growers received just over $30 billion apiece; soybeans were subsidized to the tune of $24 billion. Commodity crops are not unhealthy (not counting tobacco or sorghum – which type of grass-fed to cattle). But, with large subsidies, the commodity crops find a different path to our tables: But most of the corn and soybeans we grow do not go to Americans’ plates as-is. For example, only about 1% of U.S. –produced corn is the sweet corn that is usually directly eaten by humans. Instead, most commodity crops are fed to livestock, turned into biofuels, or processed into additives like high fructose corn syrup and hydrogenated vegetable oils.

So where do Twinkies come into all of this? Mike Russo writes:

Take the Twinkie: of its 37 ingredients, at least 14 of them are made with federal subsidies, including corn syrup, high fructose corn syrup, corn starch, and vegetable shortening. Twinkies are sweet, fatty, and calorie-rich but utterly lacking in nutritional value. And they’re cheap, too, in part because consumers have already made a down payment on many of the ingredients with their tax dollars.

And what about those apples?  Well it turns out that “only one of the top twenty federal subsidy programs directly supports a fresh fruit or vegetable: apples.” Since even that subsidy is very tiny. In fact so tiny that Mike Russo says, it is as if “each of the America’s 144 million taxpayers would be given $7.36 to spend on junk food and 11 cents with which to buy apples each year.”

Though, there are many complex reasons for the obesity epidemic, “one of the simplest is also among the most significant: junk food.  Between 1977 and 1994, Americans increased their daily caloric intake by 206 calories.” That is equivalent to 1.25 Oreo cookies (my own calculations using information from Nabisco website). It is expected that health expenses related to obesity and related co-morbidities will increase from $150 billion a year to $216 billion by 2030, and with projected half of the Americans meeting the definition of obese.

Junk food brand display at grocery store (photo credit: aashish vaidya)

What we can surmised is that a well-meaning incentive is put in place (US farm subsidies to affected small family farmer) which then over time is subverted and actually hurts the very people it was supposed to incentivize (large farm operators get the giant share of the subsidies, which they in turn use it to buy out more small farmers).  Then, the institutionalized incentive gets misdirected  and produces unintended consequence (USDA directs vast majority of the subsidies to few commodity corp and those cash crops make junk food cheaper and ends up directly or indirectly contributing to obesity and vastly increases, amongst other things, health related expenses).

Is this is a pattern unique to government entities only, or do we see an equivalent in the corporate world as well?  I will  pick up this line of inquiry in a future post.

In an ironic twist, Hostess Brands Inc., the makers of Twinkies and Wonder bread, amongst other products, filed for bankruptcy earlier this year, citing pensions and a soft economy.  The reasons conspicuously don’t include that perhaps the American consumer may already be turning away from unhealthy products to healthier ones.

References:

Department Store - Mall (© Aashish Vaidya)

Last month, like millions of other shoppers, we headed to a department store.  We noticed that the associates were little more cheerful than in the past.  Maybe this was new a crop of temp workers who took to their jobs with gusto or just existing employees, who were spurred on by new spirit of customer service.  Within minutes, an associate greeted us warmly and moments later another one engaged us directly.  Not content with just a friendly hello, he went on to mentioned items that were on sale, especially the wool jackets, which we noticed we were passing by.  When I mentioned that I already had a short wool jacket and a long overcoat, he looked at my wife and said “well, he can always add a third in his wardrobe, right?”  Unlike typical mall-store employee, it seemed like this guy actually knew to appeal to the real decision maker.  Well, the power of suggestion was already at work and we figured that it might actually make an appropriate gift for someone on list.

As I was trying out a jacket, a third associate came by.  “Wow, ” she said, “this really looks good on you.”   When I told her that we were looking for a jacket for someone else, someone older.  She immediately went on to recommend a more conservatively styled, but a considerably less costly jacket.  This was refreshing, she was really trying to help us come up with a gift that suitable, instead of trying to power selling.

We did like the jacket she suggested, but, the store did not have it in the size we wanted.  No problem, the associate assured us, she’ll just look one up in the system and have it shipped.  She was able to locate a jacket, and we proceeded to make payment, partially with their store issued gift certificate and the rest with a credit card.  And this where things got little more interesting with a seemingly ordinary transaction.  Her system would not accept the gift certificate as a partial payment.  No problem, the associate consulted with her teammate and figure out, she can exchange the gift certificate for a gift card.  And then she processed the payment.  Nice, it was admirable to see the associate and her teammate being resourceful and making the extra effort to complete a sale.

But, the very next day, we got an email simply stating that the order was canceled and no money was charged to the credit card and the value of the gift card was reverted back to the card.  Hmmm, hello, that’s a problem!  As the gift card was fully used, so as we generally do in this situation, we had already handed the gift card back to the store associate to recycle it.

Groan – that meant having to deal with the Customer Service department.  After the usual dreadful shuffle of getting through the labyrinthine IVR system, about 30-40mins later, we got a live rep.  This rep, though, had none of the warmth and the level of engagement that the store employees exhibited.  Instead of expressing any type of regret, he told us  that a new gift card to replace our old one should make its way to us in 7-10 days.  And if we were still interested in buying a jacket, we can pick it up at a store that was about 20-25miles away, but it was no longer on sale.  And if we wanted it shipped, there would be additional shipping charges.  None of the compelling reasons of value or convenience existed for us, so we declined his offer of having the nearby store hold the item for us.

About 10 days elapsed, when the gift card didn’t show up, another call to the customer service had to be placed.  Good 45 minutes later, a “friendly” CSR,  said she couldn’t find any record that we had talked to someone about 2 weeks back in the system.  But she would revert the value on the original gift card.  Umm, deja vu, didn’t we just go through this before!  After patiently explaining to her that we no longer have the said gift card, she asked us if we can contact the store to see if they had the card.  Uhh, does she really think the store clerks would really have that particular gift card on their hands after 2 weeks?  We leaned on her, and had her finally agree to send a replacement gift card.

I recount this experience in some what details,  as this  raises a few interesting IT related systems and management questions:

  • Why would the POS (point of sale, not the other type!) system not work with the store issued gift certificate, but work with a gift card?  Did someone put in a weird business rule that no one can fathom and the frontline sales associates are left to fend for themselves?
  • Why did the system allowed overselling an item when it showed there were plenty of units available at the time of purchase?  Was the inventory not real time?  And if so, was this a usability issue where the system should have alerted the sales associate not to make the sale and have a problem until the actual inventory count is confirmed?
  • Why wasn’t the system handling a gift card related cancellation differently?  Did it always presumed that the customers will keep their spent gift card, on which the value could be restored?  Or did a product owner did not hand a properly written acceptance criteria or acceptance tests to the software IT team?  Or that the software implementation team never bothered asking?
  • Was customer service department cluelessness, a vendor management issue (if it was an outsourced vendor)?  And why wouldn’t the company properly empower their CSRs  to actually make a sale when they are in a live, high touch customer interaction?  Many other retailers have already figured this out, their store clerks or their CSRs can ship products from their warehouses or from any stores either to a convenient store location or directly to the customer.  So this was a lost opportunity.

The net effect of this was a dissatisfied customer, who lost a lot of their time and use of gift card for days.  And it was a huge waste of effort for the frontline sales staff, which worked diligently and creatively to problem-solve and make the sale.  And for the retailer, this is still a revenue sapping transaction, as it still might generate more customer service calls (the replacement gift card is yet to arrive at the end of the promised delivery window).

As IT and software professionals, many times we are so removed from actual users of our systems that we don’t provide the type of support the frontline associates need, or we don’t ask the right questions from our business or product owners.  In this particular instance, the value chain wasn’t aligned from front to back.  The system wasn’t aligned with a single focus – make a sale with least waste and satisfy the customer.

But, lest you think this is just another rant (which it is!) on usual poor customer service of a big department store, I will close with a very interesting observation we made at the store.  While we were waiting for the transaction to complete, we saw a few store associates in an impromptu “huddle”, where one of the teammates reminded others to keep restacking clothes and tidying up all the floor space.  There was even a mention to balance the engagement with customers, while at the same time flowing around so other customers feel just as welcomed.  Nice, a wonderful example of inspect and adapt.  Now only if the frontline staff can extend this spirit to their CSR and IT departments.  And if the CSR and IT departments really learn to have their spirited frontline’s back, they will be on to something!

Shape The Path

We embrace change all the time

Humans are not averse to change.  Some changes we embark on gleefully, but with some changes – we struggle mightily.  This is true whether the change is at personal, organizational, or at community level, or whether it is big or small.  We don’t shy away from big changes, as a matter of fact, those types of changes happen all the time.  For example, a decade ago, I decided to change jobs, change states, while expecting our first son.  We decided to take on three huge changes simultaneously.   And yet, small change like getting to the gym 3-4 times a week, confounds me.  This is despite learning from books like Brain Rules which shows that exercise is the closest thing we have to fountain of paradise.  Exercise not only keeps us physically fit, but it reduces diseases, increases life expectancy, and keeps us mentally sharp.

The book, Switch, provides a simple framework, which can make change stick.  Of these, I looked at 2 ideas  – one to direct the Rider, the rational side of our brains (see blog post: Resistance is Futile) .  The other is to motivate the Elephant, the emotional side of our brains (see blog post: Willpower to Change is an Exhaustive Resource).  To this, the Heath brothers add a third idea – Shape the Path.

Wretched is, as Wretched does

The brothers recount a study in their book, done by Brian Wansink, who runs the Food and Brand Lab at Cornell University.  Moviegoers are handed a free bucket of popcorn and a drink in exchange for answering some questions after the movie.  What the unsuspecting moviegoers didn’t know was this:

There was something unusual about the popcorn they received.  It was wretched.  In fact, it had been carefully engineered to be wretched.  In fact, it had been popped five days earlier and was so stale that it squeaked when you ate it.  One moviegoer later compared it to Styrofoam packing peanuts, and two others, forgetting that they’d received the popcorn for free, demanded their money back.

(Did researchers actually had to produce wretched popcorn, isn’t theatre popcorn generally wretched to begin with?).

The moviegoers got either of two size buckets – the so called medium or large.  But these sizes were so huge that there was seemingly inexhaustible supply of popcorn.  Everyone got their own bucket so they did not have to share.  The question the research was trying to answer was “would somebody with a larger inexhaustible supply of popcorn eat more than someone with a smaller inexhaustible supply?”

As part of research protocol, the researchers had weighed the before and after weight of the bucket.  So what were the results? Surprise, surprise:

People with the large buckets ate 53% more popcorn than people with the medium size.  That’s equivalent of 173 more calories and approximately 21 extra hand-dips into the bucket.

Brian Wansink changed other details, like cities, or the kind of movie they were watching, but that didn’t change the outcome.  People were eating stale popcorn, whether they were hungry or not.  And they were eating more popcorn, if they had a bigger bucket.

The Heath brothers conclude that if you want the moviegoers to eat less popcorn, you can go the hard change route, which is to worry “about their knowledge or their attitudes”.  That is to say, you direct the Rider or motivate the Elephant.  Or you can make it an easy change by simply “shrinking people’s buckets”.  That is – shape the Path.

Shape the Path in software development

The Poppendiecks in their book, Lean Software Development state the importance of situation or environment, they paraphrase quality gurus Joseph Juran and Edward Deming:

It was once thought that factory workers personally caused quality defects, and if they would only be more careful, there would be fewer defects.  Then, we learned from the quality movement in the 1980s that less than 20 percent of all quality defects are under the worker’s control; the rest are rooted in the prevailing systems and procedures, which are under management control, not worker control.

In software development the same probably holds true.  The root cause for the defects in our software has less to do with individuals and more to do with our processes and procedures.  What we tend to think of a people problem is usually an environment or situation problem.  As part of agile process, then  the emphasis is placed on removing impediments.  And that is why, one of the three questions in daily Scrum is “what is getting in my way”.  This is an attempt to constantly shape and reshape the Path, so it bypasses having to constantly worry about the knowledge and the attitudes of the team members.  ScrumMasters know very well, that to make people more productive, impediments have to be constantly identified and removed.

The Heath brothers say, ” when you shape the Path, you make change more likely, no matter what’s happening with the Rider and Elephant.”

Change is possible, but, you have to approach it from 3 angles: “direct the Rider, motivate the Elephant, and shape the Path“.  And if all 3 elements are present at one time than “dramatic change can happen even if you don’t have lots of power or resources behind you.”

Resistance is Futile…

The Rider Spins his Wheel (photo credit rykerstribe on flickr)

In my last post: Willpower to Change is Exhaustive Resource, I explored some ideas about change management. This topic is relevant for me and my team members, as we are going through major changes at work: reorganization, wider adoption of the agile practices, scaling the methodology outside of IT and in much larger context the market-place that we operate in. It helps to have some mental models to provide us with a framework to understand and adapt to these major changes.

Change Models

The model developed by Elizabeth Kubler-Ross and adopted to change management show that when change is introduced, we go through distinct reactions to it: shock, denial, frustration, depression, experiments, decisions and finally integration. It is important to know where we, and our team mates, are along this change curve.

Chip Heath and Dan Heath’s book Switch which uses the analogy of the Rider- the rational side of our brain, and the Elephant – the emotional side, as a short-hand to understand the dynamics of change efforts.  Behavioral economists Richard Thaler and H. M. Shefrin use a similar analogy – the farsighted Planner and the myopic Doer.

The Heath brothers explain that when we are looking to change, we are going up against “behaviors that have become automatic, and changing those behaviors requires careful supervision”, by our rational side. And depending on the size of the change we are making, the rational side simply gets overwhelmed and exhausts its willpower.

Many of us, have experienced this first hand. With good intentions, we embark on writing effective user stories, story tests, acceptance criteria, stories that fit a single sprint, have periodic retrospectives, write automated tests, demonstrate working software to our users, and so on. But under stress and schedule pressures, we abandon these good practices. We revert to writing technical user stories, coding only stories and testing only stories.  Sometimes, we resort to having an architecture-only sprint, data modeling sprint, analysis sprint, and then lots of coding sprints and in the end stabilization or “defects fixes” only sprints. We keep committing to stories, even though, we know we will barely finish coding, and then split stories across sprints. Automated unit tests or UI functional tests end up on the cutting floor. We cancel our demos and retrospectives, because we really need to use those 2 hours to do some more work on the stories we didn’t finish during the sprint. Sometimes, it gets so reductive, like this one candidate I was interviewing, who told me that on his agile team, the only practice they performed consistently was the daily scrum. The Heath brothers say, “anytime the six-ton Elephant and the Rider disagree about which direction to go, the Rider is going to lose. He’s completely overmatched.”  The Elephant will always seek out path of least resistance.

The Rider spins his wheels

If the elephant is hard to motivate and overwhelms the Rider, then the Rider has his own problems, too. In IT, we frequently succumb to analysis paralysis, or as one of my colleague calls it, “excessive navel-gazing”.

Jonah Lehrer, a journalist, was inspired to write a book How We Decide, precisely to understand why the Rider spins his wheels. Here is what he said during an interview on Amazon.com:

Q:Why did you want to write a book about decision-making?

A: It all began with Cheerios. I’m an incredibly indecisive person. There I was, aimlessly wandering the cereal aisle of the supermarket, trying to choose between the apple-cinnamon and honey-nut varieties. It was an embarrassing waste of time and yet it happened to me all the time. Eventually, I decided that enough was enough: I needed to understand what was happening inside my brain as I contemplated my breakfast options. I soon realized, of course, that this new science of decision-making had implications far grander than Cheerios.

Here are some examples of our own Rider. Which agile methodology should we use – Scrum, Lean, Kanban, DSDM, XP, FDD?  What agile techniques should we try first TDD, BDD, ATDD, CI, Pair Programming, Pair Testing.  What should we spend our energies automating – at the unit, component, integration, system level? What should we emphasis first, writing effective story cards, doing better demos, running honest and open retrospectives, fix bad team dynamics, and on and on.

The Heath brothers recount a story of two professors at West Virginia University. They are health researchers who were “contemplating ways to persuade people to eat a healthier diet?”  For something like that, where do you even began?

Which foods should people stop (or start) eating? Should they change their eating behavior at breakfast, lunch or dinner? At home or in restaurants? The number of ways to “eat healthier” is limitless, especially given the starting place of the average American diet. This is exactly the kind of situation in which the Rider will spin his wheels, analyzing and agonizing and never moving forward.

After much brainstorming, the two researchers arrived at this insight:

Most Americans drink milk, and we all know that milk is a great source of calcium. But milk is also the single largest source of saturated fat in the typical American’s diet. In fact, calculations showed something remarkable: If Americans switched from whole milk to skim or 1% milk, the average diet would immediately attain the USA recommended levels of saturated fat.

But, the next question was, how do you get people to drink low-fat milk and how do you get them to stock it in their refrigerators? After all, people will drink whatever’s available in the house (path of least resistance, no one’s going to run out to the store to buy whole milk – the Elephant is lazy).  Researchers figured out, “you don’t need to change drinking behavior. You need to change purchasing behavior.”

After an effective ad campaign, the two researchers were able to increase the market share of low-fat milk from 18% to 41% and it held steady after six months at 35%.  What we learn from this is:

If you want people to change, you don’t ask them to “act healthier.” You say, “Next time you’re in the dairy aisle of the grocery store, reach for a jug of 1% milk instead of whole milk.”

Many times, our reaction to change efforts is similar, for example, we might think, why can’t everyone just fall in line and just follow agile practices.  But contrary to what the trekkie-referenced title suggest it is isn’t even a question of resistance, because “what looks like resistance is often a lack of clarity.”

Oh and what happened to Mr Lehrer and his cheerios? Well, here is what he said in the same interview:

Q: What do you do in the cereal aisle now?

A: I was about halfway through writing the book when I got some great advice from a scientist. I was telling him about my Cheerios dilemma when he abruptly interrupted me: “The secret to happiness,” he said,”is not wasting time on irrelevant decisions.” Of course, this sage advice didn’t help me figure out what kind of cereal I actually wanted to eat for breakfast. So I did the only logical thing: I bought my three favorite Cheerios varieties and combined them all in my cereal bowl. Problem solved.

Sometimes, as our CIO says, it is better to “Ready, Fire, Aim”, instead of getting ready and deliberating endlessly on where to aim.  And then never getting around to firing.

So far, we have looked at 2 concepts from the Switch framework – direct the Rider and motivate the Elephant. In the next post, I will at look at the third concept – shape the Path.

Recently, at work, we have gone through some major organizational changes.  We have moved away from an IT organization that was a collection of functional silos – Architecture, Design and Analysis, Application Delivery, Release and QA, and so on –  to more integrated groups aligned with our business units.  As we move towards more cross-functional, self-organizing agile teams, colleagues have noticed that many of us feel a bit disoriented.  Many don’t know what to do, many have a negative reaction to the changes and then there are some who have already accepted the changes, and are impatient that there team mates are too slow to change.

Reactions to Change

As we experience change, Elizabeth Kubler-Ross defined and categorized our psychological reactions to it:

We find  that people react to change differently and they might be anywhere along this change spectrum, including in the “pit of despair”.  And each need different type of support.  For those in shock and denial need information and communication.  Those who have self-doubt and inching towards acceptance, need emotional support.  And those who are exploring and understanding, need direction and guidance.

The Rider and The Elephant

The Elephant and the Rider (credit aashish vaidya)

Another framework to understand and initiate change is developed by Chip Heath and Dan Heath in their book Switch.  They note that our brains have two independent systems at work:

First, there’s what we called the emotional side.  It’s the part of you that is instinctive, that feels pain and pleasure.  Second, there’s the rational side, also known as the reflective or conscious system.  It’s the part of you that deliberates and analyzes and looks into the future.

The Heath brothers adopt the terminology of the Elephant (the emotional side) and the Rider (the rational side) introduced by University of Virginia psychologist Jonathan Haidt in his book The Happiness Hypothesis.  This isn’t necessarily a new concept, as you find variations articulated by Plato, Freud and many others.

When we are in midst of change, like moving our software development from waterfall to agile methods, or getting better at adopting and refining agile methodology; or for that matter any other type of change effort, we need to understand both these aspects of our brains – The Rider and The Elephant.  This is how the Heath brothers define it:

The Rider provides the planning and direction, and the Elephant provides the energy.  So if you reach the Riders of your team but not the Elephants, team members will have understanding without motivation.  If you reach their Elephants but not their Riders, they’ll have passion without direction.  In both cases, the flaws can be paralyzing.  A reluctant Elephant and a wheel-spinning Rider can both ensure that nothing changes.  But when Elephants and Riders move together, change can come easily.

It is possible to get our rational side to exert control over our emotional side, but that can prove exhausting for the Rider.  To illustrate this point, Dan Heath in this FastCompany video and article, and also in the book, recount a study about radishes and cookies.

Will to Change is Finite

College students (the usual guinea pigs in these types of studies) were asked to fast for 3 hours and report to a study about food taste perception.  They were then led to a lab that smelled amazing from freshly baked chocolate chip cookies.  In the middle of the room were 2 bowls – one filled with cookies and another with radishes.  Half the participants were asked to sample the cookies but not radishes and another half to eat radishes only.  Then the researchers left the room.  The cookie eaters probably had no issues resisting the urge to eat the radishes!  However, despite the temptation, the radish-eaters showed amazing willpower and did not eat any of the cookies.  Here is where another set of wily researchers came in and declared that the taste perception study was over.  But, they were doing another study about problem solving.  At that point, they asked the participants to solve a puzzle.  Unbeknownst to the participants, the puzzle had no real solution.

What the researchers were trying to find out was whether there was difference in a way the cookie-eaters and the radish – eaters approached the puzzle?  Well, it turns out there was.  The cookie-eaters made 34 attempts at the puzzle and persisted for 19 minutes.  The radish-eaters made only 19 attempts and gave up in half the time.  Why is this?  Well, study shows that the radish-eaters who were tempted to eat cookies but did not, simply ran out of self-control.  So when another challenging task – solving an impossible puzzle was giving to them – they were simply exhausted.  Of course, your takeaway from study shouldn’t be , eat more cookies and not radishes.  But, it should be that the will to change is indeed finite.  The Heath brothers say, “what looks like laziness is often exhaustion.”

IT organizations, when they decide to change from traditional waterfall software development, or initiate any other major changes, find many team members, managers and business partners show reluctance to these change efforts.  In many instances, it is because their Elephants are genuinely spooked at the spectre of losing the clout they have built in an organization or potentially losing their jobs, or myriad of other real and imagined fears.  Change induces a fight or flight response.

Many times, we share information about changes, appealing to the rational brain, but we don’t really address “what is in it for me” part of the equation.  That is, we don’t engage the emotional side.  And so the changes simply don’t stick.  Our rational side tries hard, but in the end, the willpower dissipates. This is due to skittishness of  our emotional side, which is “often looking for the quick payoff”, at the expense of long-term gains.  Change management saps our willpower, if we don’t find a way to motivate our emotional sides.

In my next post, I will continue to explore more on the change management theme.

I have been revisiting the Popendiecks’ 2003 book: Lean Software Development: An Agile Toolkit.  One of the tools in the book is Set-Based Versus Point-Based approach.  This tool is based on Lean principle of amplifying learning. 

Point-Based approach is based on choices.  The authors represent this via the following an illustration:

 

 

Whereas, Set-Based approach is described as one about “constraints, not choices” and that it requires “significantly less data to convey far more information.”

I inadvertently stumbled on an opportunity to try out this tool, exactly in the way it is described in the book.  While facilitating a community of practice which has 9 team members, I had a need to schedule a meeting.  But, since we all work on different teams, coordinating simple schedules for this part-time effort is usually a challenge.  It would be simple to see everyone’s calendars and schedule a meeting.  However, many people don’t keep their calendars up to date.  Or they have blocked off time, but are actually available.

Even during face-to-face meeting, since people don’t have their schedules in front of them, they are reluctant to commit.  So it becomes hard to converge on a time.

My initial instinct was to use the point-based approach by letting everyone know the best time that worked for me.  But I decided to try the set-based approach.

Here is how I communicated the constraints via email to all the team members:

  • Apart from me, one particular team member needed to be present, as she had the key information on the topic
  • Additionally we needed 2-3 more team members
  • I provided 2 blocks of 2 hours each that I could meet for an hour long meeting

And lo and behold, within few minutes, I got the needed response.  What had in similar circumstances took a flurry of emails, and still no convergence; with this approach, we converged on time with just 1 email each from the team members.  Few let me know which time worked, others let me know they weren’t available.  And I was able to quickly pick a common hour that worked for half the team to meet.

It was great to see the tool in action.  Next, I am keeping my eyes open to use this on a development project.

%d bloggers like this: