Dhaval Panchal’s – Agile Blog

This is a variation of “Value Flow” exercise that Sanjeev Augustine did at Scrumgathering 2009 in Orlando. I found this exercise very useful to demonstrate the benefits of prioritization and lower batch sizes. I have facilitated a variation on this exercise with different learning objectives. Below is a detailed description of how I run this exercise.

Time:

15 – 20 minutes

Input:

• 20 coins of different kinds (1,5,10,25 etc)
• Secret stash of 20 coins of different kinds (1,5,10,25 etc)
• Table large enough for 4 persons
• Stopwatch (1)
• Participants (5)
• Facilitator (1)
• Time keeper (1)
• Flip Chart or Whiteboard
• Chart or Whiteboard markers

Setup:

• Create a table as shown below on a flip chart or White Board

• Participant roles
  • Delivery Team member (4)
  • CEO/Portfolio Manager/Product Owner (1)

Exercise Steps:

Round 1: Batch Size ALL

1.       Ensure all team members can flip or toss a coin.

2.       The first delivery team member flips a coin until it turns heads. Repeats this step for all the 20-25 coins.

3.       Only after the first person is done with all the coins, the second delivery person works on the first coin in the batch until (s)he is done is with all the coins.

4.       The third person picks up the entire batch and then the fourth.

5.       Time keeper records the time taken for the first coin to be flipped to heads by the last team member.

6.       Time keeper records the time taken for all the coins to be flipped to heads by the last team member.

7.       CEO/Product Owner calculates the sum total of monetary value represented by the coins.

Facilitator sets up context that the organization is facing stiff competition and they have to deliver much faster that they did in Round 1.

Round 2: Improve Time to Market!

1.       Facilitator removes the restriction that one person has to complete all the coins before the next person can pick any of the coins. Team members do have to follow the sequence of processing through team members.

2.       Facilitator asks for the delivery team to do a quick 2 minute retrospective on Round 1and plan for the how they will approach the same problem without the restriction of flipping all coins before passing to next step.

3.       Facilitator kicks off round 2, at the end of time box. Delivery team members may ask for more time for retrospective, but it’s important that facilitator holds the 2 minute time box sacred.

4.       Delivery team begins flipping coins

5.        Time keeper records the time taken for the first coin to be flipped appropriately by the last team member.

6.       Time keeper records the time taken for all the coins to be flipped appropriately by the last team member.

7.       CEO/Product Owner calculates the sum total of monetary value represented by the coins.

Facilitator sets up the context, that although the time to market was okay, competitors have gained parity and the organization has to focus on delivering higher customer value. They need to improve on that!

Round 3:  Competitive Threat!;Prioritize and fix release date

1.       Facilitator asks for the delivery team to do a quick 2 minute retrospective on Round 2 and plan for the how they will approach the problem this time.

2.       While the team is doing a retrospective, facilitator asks the CEO/Product Owner to prioritize coins based on their monetary value.

3.       Facilitator declares a time box for round 3. This time box should be the lesser of 4 minutes or the time taken to flip all coins by everyone in Round 2.

4.       Delivery team begins flipping coins.

5.       When the first dime comes off the line, tell the team “customer feedback, dimes have no value”

6.       Facilitator hands secret stash, another random collection, of coins to the CEO/Product owner.

7.       CEO/Product owner can reprioritize the new collection with other coins that have not yet been picked up by the first person.

8.       At the end of declared time box, time keeper declares time. Out.

9.       CEO/Product Owner calculates the sum total of monetary value represented by the coins.

Debrief:

Facilitator debriefs participants and other witnesses on the exercise. This will vary significantly depending on people’s experiences. The intention of the three rounds is thus:

Round 1, sets up the organization to deliver fixed value (total monetary value of coins). Team members usually are working at a frantic pace to get most through put with the CEO/Product owner cheering them on.

Round2, is still about delivering fixed value however after the retrospective team members intuitively reduce the batch size. So instead of passing 20 coins at a time, they hand off 2 to 3 coins at a time to the next person in line. I have observed that as compared to round 1, the team takes much lesser time to deliver on the same. Improved time to market!

Round 3, is delivering about maximum value with in fixed time box. This is significantly different than Round 1 and Round 2 since in this case the product ship date is fixed. Somewhere in round 3 by injecting customer feedback that “all dimes are useless”, induces additional uncertainity since no one can predict customer behavior/trend.  At the end of round 3 time box, team often delivers higher value than round 2 and round 1 even with the uncertainity induced through customer feedback.  Debrief points are around product owner prioritization, injection of customer feedback and fixed release dates.

The coins in this exercise may represent features or projects within a portfolio. It is very hard to kill projects/features even after we know that they are not worth the effort. There is tremendous value in killing low value high cost projects. Have fun! I’d appreciate if you provide feedback  or tell me how it went for your team.

Facilitation Exercises, Product Backlog Add new tag, coaching, exercise, product owner, release, scrum, value

The role of a Product Owner with in Scrum teams or that of a Customer in XP teams is critical to the success of the product. What to do? – when they take vaction. What are your options? Say your product owner is going on a planned vacation for a couple of weeks, effectively unavailable to the team for an entire sprint. Based on my experience at coaching and working with Agile teams, I have found following options that do not work:

1. The business owner (PO’s boss) takes the solo role of the product owner over.

 Pro: Business Owner is the single representative voice of customer. Business Owner has the authority and the responsibility to make product decisions.

 Con: S/He is not available for much of the time, delaying decisions.

 Con: Business Owner does not have detailed knowledge of the domain.

 Your PO’s boss most often will not have time to spend with the team and lack of domain knowledge renders the business owner dangerous to provide direction for a sprint. Also, given his seniority he  may  have other important stuff to take care, like assuming non-PO responsibilities that your PO was fulfilling within the organization.

2. Hybrid: UX Questions go to Interaction Designer, Reporting Questions go to Business Intelligence Analyst, Strategic Product Questions go to the Business Owner. Scrum master is quarter back for these questions – ensuring they are routed to the right place. When there are unresolved questions, they are decided by Business Owner.

 Pro: Balances workload among contributing experts

 Con: More workload on the scrum master

 Con: Communication may break down between different members

 Con: Who accepts stories?

Too many people wearing the virtual PO hat with the real PO in vacation and the real-temporary PO behind the scenes. Too much confusion for anyone’s taste. 

3. The product owner postpones vacation.

 Pro: Team doesn’t loose their product owner

 Con: Delay in vacation causes trip prices to climb in the summer

 This option is really not sustainable, people ought to be able to take vacation and not penalized for doing a good job.

4. Get another analyst to come up to speed. Someone comes on the project two weeks earlier to understand the domain and serves as proxy during the sprint.

 Pro: Keeps the single decision maker.

 Pro: Availability of analysts is more realistic than Business Owner taking this over

 Con: Unfamiliar with the domain.

Startup time/cost to get a proxy product owner ready means effort spent by current PO and other team members during prior sprint which may cause drop in delivery of valuable functionality that would have been delivered otherwise. 

5. Product Owner answers emails from Europe with 1 day time lag

 Pro: Single decision maker is kept

 Con: Time delay for questions, reducing velocity

Then it is not a vacation and true product owners take vacations!

What can you do?

One of the team member assumes a dual role of Product Owner and Team member. Ensure that this is not the scrum master.

Sooner or later, the PO has to trust the team to make domain level/product level decisions. Hopefully during these previous sprints the team has had an insight into PO’s thinking process and gained insight into PO’s implicit knowledge about how the product should work and feel. There may be some Subject Matter Expertise, like biz rules, that they need from other Analysts and they can ask these SME’s for guidance however the responsibility of final product should not seep out of the Scrum team (SM + PO + Dev team). Also, having a team member play this dual role is better than

i. Training a new person to play proxy role. (option 4)

ii. Getting a less domain knowledge person make decisions (option 1)

iii. Causing identity crisis for the rest of organization (option 2)  ;)

The worst that can happen is that the person who is playing the dual roles, blows-up a two week sprint.  On the bad side, 2 – weeks’ worth time and effort is lost. However on the good side, the PO will know how well the development team has so far understood PO’s product vision and incremental steps so far (previous sprints) towards that vision. A great learning opportunity! (Above mentioned worst case can also happen with option 1, 2 and 4 however there can be tendency to cop out and blame the “outsider” rather than look inwards and see where a team can learn.) 

There are two characteristics that I seek in my suggested solution:

1. Learning opportunity

2. Avoid diffusion/confusion of responsibility 

Many thanks to Ed Kraay, my collegue and friend at SolutionsIQ, who recently helped one of our client product owner’s to fulfill his vacation commitment.

Experience Good Practice, product owner, team, velocity

Couple of years ago, my good friend Subhayu was visiting me in Seattle. In India we would often hike together through remote hills in Western Ghats. So it seemed appropriate that I sign up myself, Subhayu and one other friend of mine from Seattle, Ben, for a day of adventure. Whitewater rafting seemed appealing at that moment. My friends had no prior experience with whitewater rafting. My adventurous self had only once been through the Skykomish river Class IV and Class V rapids, wherein my group avoided some of the dreaded Class V rapids and walked our rafts along the shore. This time however, I wanted the real deal and signed with a professional guide who would coach and guide us through Class IV and Class V rapids on the White Salmon River. To my excitement White Salmon River rafters have an option to paddle through air while falling fourteen feet over Husum Falls. 

Class V Rapid - Husum Falls, WA

Subhayu, Ben and I reached rendezvous point on time. Parked our car, checked into wet suites, and signed release forms. We drove in a shuttle to the launch site where we were provided very important safety talk by our guides. Which, and I blame it on too many airplane flights, I did not pay much attention to. The agency that I had signed us up with had many professional guides and many other people like us, so we were divided into groups of six with one guide per raft. My group had my friends and three other guys who I had never met before.

First hour on our trip was as gentle as whitewater rafting can be. During this period, our guide patiently explained how we should position ourselves on the raft and how to paddle through water. She explained some voice commands and we practiced steering our raft as per her guidance. Initially we struggled a lot with our raft practically going nowhere, however as we practiced and practiced our group got a hang of it.

The next hour and half was far more challenging, full of excitement with twists and turns often spinning our raft 360 degrees. We soon realized that unlike typical boats, rafts in choppy whitewater do not have a fixed bow and stern. It changes all the time where in once you are in the front and the next moment you are at the steer end of the situation. Over the crash of the waves, screams, big boulders and near misses we stayed tuned to voice commands from our guide. She did a great job of keeping her head above the fear and thrill of the moment to harness our energy towards an exciting ride, so far. During brief moments of lull she would tell us stories of other trips that she had taken through these waters. These ranged from pleasant stories of wildlife sightings and terrifying rescues of overturned rafts. We had our first scare while navigating around a big boulder. Subhayu lost balance and was hanging upside down with only one of his feet in the raft and the rest of him getting tossed around in water. Through combined effort from a couple of group members we were able to pull him back up into the boat – disaster averted! We played with a few minor scares wherein later Subhayu grabbed me just in time to save me the experience of chilled water head first.

In retrospect, these scares prepared us well for what Husum Falls had in store. Husum Falls, with its fourteen feet drop is the cherry on top this cake. This is why I had dragged my friends along. Prior to negotiating the falls, we rested our raft on the shore, walked a bit to visually inspect the falls and pep talk each other to sign up for the adventure. Having secured our agreement our guide coached us for the specifics of rafting over this insane drop. We were to paddle until we catch the current, then we steer to get the right angle of approach for the falls and when she yells, we all crouch down with our paddles rested to cling as close to the floor of the raft as possible. This last bit about crouching was very important because as the raft hits the bottom of the falls it behaves as compressed spring. First bending and then springing open to regain its shape, and this rubber band effect is strong enough to flip people overboard.

And she said, “you don’t want that” – in a tone reflecting her motherly meanness.

So we earnestly practiced a couple of dry runs to get the crouching part right. She observed and corrected us. We were now ready and just in time, since the current was now pulling us rapidly.

To see what its like to raft through Husum Falls (See Video Link)

Our guide, she steered our raft, just as she said she would. She positioned us for the angle of approach, just as she said she would. We couched to the bottom of the raft, just as we said we would. We hit the bottom of the drop, just as she said we would and then our guide, our coach fell overboard.

Joyous rapture of our accomplishment was soon terror stricken by the realization that our commander was rapidly drifting away from our raft. I remember the deer in the headlights look on the faces of the guys in the boat, I remember people from the shore yelling something at us.I also remember one of guys on the boat throw the “Hail Mary” towards our coach.

Throw Bag - Safety Rope

This was a joke that our coach had shared with us a few hours ago when we were in calmer waters. She was talking about a throw bag that is shaped like a football that you throw towards a person who is overboard hoping that they can catch on to the rope and have a chance to get back into the raft. Fortunately the throw was good or the gods took mercy, our guide was able to fight the undercurrent of the falls and get to the bag. Crisis one averted.

Crisis two and this had all of us gripped in fear. We were without our guide in the boat and were drifting rapidly downstream with no experience to navigate the rest of the course. Something happened at that moment of crisis. Without a word being exchanged we all realized the gravity of our predicament, we picked a direction, we all paddled in unison and like a single self-organized unit put into practice everything that we had learned over the last couple of hours to get to one of the shores. Having secured a stationary position on mother earth, we reeled in our coach from choppy waters into our raft.

Much of what happened next is a blur. The experience shadowed rest of my journey down the river. I remember feelings of bitterness and abandonment, for if our guide was really good, really professional, she would not have flipped overboard in the first place and I would not have had to fight for life and limb at the bottom of Husum falls. Our guide on the other hand was very complimentary, saying that she was very proud of us and that we pulled it all together just like a great team would.

On our return car trip back to Seattle, my friends and I talked about our guide. Initially we questioned her effectiveness and ability. But as long road trips go, there are sober moments of reflection where the truth dawns upon you. We realized that we probably had the best coach we could have ever asked for, she trained us on the basics of navigation, she trained us on working together, and she trained us on dealing with crisis. She prepared us enough that when it mattered most, we delivered. This realization that coaches are humans too and do err, told us that her moment of coaching greatness was realized when she was not in the raft guiding us.

My rafting experience can probably be related to coaching software teams; I however will not attempt to draw lengthy parallels. Having coached many software development teams, I tend to value my contribution by what a team does when I’m not with them over what the team does when I’m with them.

Experience coaching, self-organization, team

The term “bottleneck” refers to a point where after the flow or velocity perceptively reduces. It is metaphorically derived from flow of water through a narrow mouthed bottle where the flow of water is constrained by its neck. For drinking purposes it is a good thing as it regulates the flow of water through the bottle to the drinker, preventing wasteful spillage. Bottleneck’s though constraining can be both a good thing and a bad thing, depending on desirability from the system.

The scrum framework contains product backlog  which is essentially a queue (stack ranked, one after the other) of product backlog items (PBI’s) that the scrum team has to complete. Queue’s/backlog’s don’t feel good. Think about the last time you were in a rush and had to go to a bank where you stood in a queue behind fifteen people before the teller addressed your needs. Or the time you had to stand in queue to board your daily commute bus – uncertain whether you will get a chance to board this bus before the driver declares “its full” and rides on. There is the frustration of waiting in a line and the uncertainty of whether you will make it. If  PBI’s could feel, then I guess they would empathize with people stuck in queues. 

IMO, inherent assumption within complex software product development efforts is that

the business will always have more concepts or requirements than the team’s capacity to transform these into potentially shippable product increments.

If this assumption holds true for you then your product backlog expresses the aggregate effect of bottlenecks that exists downstream in your system. In other words, if there were no bottlenecks or team had infinite capacity then the all the PBI’s will be transformed into potentially shippable product increments within a sprint. Velocity metric represents this constrained capacity of a scrum team. In scrum terms these bottlenecks and other blockers are commonly referred to as impediments. Impediments being a broad generic term, I’m focusing on bottlenecks – which are impediments that specifically cause reduction in flow at a systemic level over multiple sprints.  (Nothing too revolutionary!)

Here are a few of such bottlenecks:

1. Ill-defined product backlog items

Top priority product backlog items are not well defined for the team to fill up at least their next sprint and start working.Too often this results in lengthy sprint planning meetings, and delay in terms of days before a scrum team makes sprint commitment and get going. In such cases the team spends the first few days of the sprint analyzing requirements, holding design sessions etc prior to making a sprint commitment. Sprints in this case go in fits and starts with a significant gap in software development efforts between the end of previous sprint and the start of new sprint. In this case the bottleneck is recognized as gaps between sprint end and start dates.

2. No product backlog items

In most cases, this situation is not an invalidation of the assumption that the business has more work than the team can do in a sprint. In fact too often the business has a pressing need to get many features out of the door. Flood of information, lack of agreement, “have to get it right the first time” has a paralyzing effect effectively boxing them in a state of limbo where PBI’s are not defined and the scrum team is left out to dry. Often the bottleneck in this case is upstream of the scrum development team causing either an abrupt end to sprint rhythm or a false start with frequently extended ’sprint 0′.

3. Not-Done product backlog items within a sprint

It is common understanding that PBI’s within a sprint are either Done or Not-Done as measured against their definition of done. PBI’s that get Done are counted towards team’s sprint velocity and the rest don’t. Teams that end their sprints with some or many Not-Done PBI’s find that their ability to pull in new PBI’s next sprint is bottle-necked.  Following the mechanics of good scrum practices these teams present Not-Done PBI’s to Product Owner and estimate remaining work for prioritization in Product Backlog. In my observations it is most likely occurrence that the Product Owner will ask  for Not-Done PBI’s to be completed in following sprint. Effectively the team carries forward Not-Done PBI’s from last sprint into the next sprint. In cases like these, it may feel like that there is a smooth flow from concept to realization however it ain’t true. Look at the worst case scenario, no new PBI’s are pulled from product backlog and the team spends the next sprint finishing up not-done work from previous sprint. In this worst case example it is easy to call out such a bottleneck, in real teams there are variations along the continuum of getting all committed PBI’s Done to getting none of committed PBI’s Done. It takes an experienced scrum team and/or ScrumMaster to recognize this pattern while its happening for real.

4. Insufficient infrastructure

Lack of staging environments, insufficient QA infrastructure and/or production ready environments stops the flow of developed features at some point before these features can be deemed production ready or ‘potentially shippable’. All these features pile up and aggregate until a sprint or two prior to release date. Then the teams make a major ‘push’ to release all of the developed functionality out of the door.

These last sprints are often called as ’stabilizing sprints’. And I have to say, I will start liking the term ‘Stabilizing sprint’ under the condition that all of the previous sprints are called destabilizing sprints. Each one of the previous sprints was destabilizing the product increment unpredictably. Sadly for me, most people interpret the term ‘Stabilizing Sprints’ as a good thing .

Tricky thing with all the hard stuff, like performance testing, regression testing etc, that could not be done within regular sprints is that the hard stuff does not get simpler if its left for last sprint. It gets even  more harder. Causing a snowball effect. Take regression testing for example, if regression testing was not done in previous sprints then in the last stabelizing sprint potentially a lot of regression bugs can show up. If these bugs cannot be fixed in the last stabelizing sprint,  these will then ideally fuel addition of PBI’s in product backlog. Leading to either lower quality product release or a delayed release date. In either case, there in lack of objective perception regarding both quality and predictable release date. This bottleneck is obvious to everyone, for there are features piling up every sprint waiting to be production ready however the exponential negative impact is still underappreciated.

Experience, Product Backlog, Uncategorized Definition of done, product backlog grooming, release, scrum, scrummaster, velocity

As an Agile coach I enjoy the opportunity to learn from people implementing scrum framework and incorporating Agile values and principles. In this process I come across interesting stories and metaphors. After an introductory training session with one team and some follow up coaching during sprint planning, Paul (team member) shared his impression of the situation the team was put-in with this new scrum and Agile thing - 

Back on the farm, if a cow isn’t producing more milk than cost of the feed she eats, unless someone really likes scratching her between the ears as a pet, sooner or later she ends up as hamburger.

I must admit that when I heard of it for the first time, I felt very uneasy. It is a very blunt analogy getting straight to the primary design benefit of scrum – Maximize Return on Investment (ROI). If at the end of every sprint the organization does not believe it can get sufficient ROI over the cost of development, then there are “Or Else …” scenarios that the organization can pursue.  Scrum does not tell you about what you should do, it simply brings transparency into the system and provides opportunities for early adjustments.  The thing that concerned me was that the team had likened the “or else…” scenario with Betsy ending up on organization’s menu. At that time I expected the team to get over their initial fears and move forward with a more positive outlook. It was not to be so, a sprint later I saw a picture of cow-cuts on top their team task board. 

Had this team drifted deeper and darker with Betsy’s supposed fate? 

Successful cross-functional teams that I worked with,  have a sense of identity that is separate from their job titles or departmental affiliations or other organizational chart bindings.  As a coach, the simplest thing that I have done to trigger such a sense of identity, is to facilitate scrum teams through an exercise to help them create their team name. Although I floated this idea of creating a team name to the team described above, they did not feel it was necessary for them to do so. Instead this team  had adopted Betsy as their team mascot and coalesced around the notion of saving Betsy from her predicament sprint after sprint after sprint. 

Over the last 10 or so two week sprints, I have had the pleasure of working with this team intermittently and I have observed the team adopt Betsy into everything they do and innovate along the way.

Before I delve further, some context about this team is due. Each of the team members has a minimum of at-least 15 years of  software industry experience. The team works for a well known insurance provider and does sustainment engineering for all business processing applications. They interact with customer account managers that are transferring big organizational health care insurance benefits to be managed by their company, customer service personal that are serving individual insurance beneficiaries and operations support that manages changes to production systems. Like many scrum teams they are in a very complex environment. Their complexity is compounded by the urgency of fixes requested from the business side and from the necessity of their operations and DBA group to ensure quality of fixes. They are not immune from challenges associated with organization silo’s wherein the DBA group cannot dedicate any member to the scrum team so as to form a truly cross-functional scrum team. On the plus side they have an excellent scrum team very well supported by their ScrumMaster and ably directed by their Product Owner, who is from the business side of the organization.

So what does it mean to save Betsy within their context? There are many dimensions to addressing this question.

• From a software delivery perspective, the team commits to delivering software product fixes and enhancements to production environment every sprint. I remember this interesting conversation where the team was discussing their definition of done. Question arose, whether they should commit against a definition of done when elements of done-ness, such as production database updates, are beyond the authorized scope of the team members (DBA group owns production updates). At the end of their dialogue every one in the team agreed that only software that is in use by end-users constitutes valuable software. Although they do not directly manage production updates, they believe it is their responsibility to shepherd updates into production environment. In effect, every sprint they committed against a definition of done that required product backlog items to be implemented in production environment. This required them to engage representative from DBA during their daily stand-up, working with the DBA group to work with their constraints, such as no production updates on Wednesdays & Fridays. Also building automation test scripts to validate quality prior to review by DBA’s, effectively reducing rework cycles.
• Engaging sustained participation from business. Prior to their scrum implementation customer issues and requests from business side were some times, lost in the ether. It was not unusual for the team to come across requests or tickets that were more than a year old. Through regular prioritization by the product owner the team was able to focus on the highest priority fixes that needed to be addressed. The ScrumMaster was very effective at challenging the team to change long held organizational-cultural habits.  One such behaviour of their silo-ed environment was that of communicating ticket status through the bug tracking system. All too often tickets that were resolved and ready for functional acceptance were not looked at by the business person for closure. This resulted in delayed production updates for several resolved issues. Team members started interacting in face-to-face conversations with business people to better understand their tickets and following up with them to confirm functional acceptance. Such proactive steps drastically reduced wait times involved.
• Complete transparency. Here’s a snapshot of their task board :

• Being the only scrum team in their organization, sustaining healthy relationships within the team and with others who interact with the team is critical. One of their approaches is to manage this through recognition: Every sprint the team recognizes people who have contributed to save Betsy. This cute little award
        is given to people within the team or outside the team for their contribution towards saving Betsy.       
• Addressing root cause for recurring issues. The team routinely analyzes commonly recurring issues and implements fixes that addresses the root cause for these issues. 
• Having fun! team members flex their creative muscle every sprint by chronicling events of their sprints in news print format themed around Betsy, astutely weaving their sprint happenings with current affairs of the world at large.  Hear are a few examples,      . The team ScrumMaster, Stan’s favorite is this one where Betsy takes to skies. . The entire success with scrum is really due to his efforts and leadership. He has been very open minded and very smart, to let the team run with Betsy and see how it would play out with the team and the rest of the organization. Its one thing to float an idea, and quite another to really figure out what is going to work, and what might not be a good idea to fit in with the bigger picture. 

This approach at recording sprint facts and events is sooo innovative/cool/awesome that my team used this technique to do our sprint retrospective. During our retrospective we formed pairs and spent 30 minutes each to create our own version of scrum times. After that we shared our impressions of the sprint via the news-prints that we had created. It was a fun exercise and the discussions were so much richer as each pair accentuated aspects of sprint dearer to them.

There are many other things that directly or indectly relate to saving Betsy.The thing I find most interesting is the emergence of a unique and compelling purpose within this team. It enables them to innovate in all areas: people, process, tools, software delivery.  To sum it up in the words of Paul Opryszek 

Betsy was born in rustic King county in mid 2008. Her dairy farmer was Paul Opryszek who was fortuitously struck by a bolt of Agile lightening that restored Vision as well as Belief in Truth, Beauty, and Resource Allocation sanity

Experience Betsy, culture, emergence, purpose, scrum, self-organization, team

A Best Practice is a collection of tools/techniques/approaches/methods when applied in prescribed order delivers desired results effectively and efficiently. “Best” in the term “Best Practice”, to me, implies that there is no further room for improvement, ever! There seems to be an implied sense of finality, why use anything less than the best? There also seems to be an implied sense of universality, wherein application of Best Practices under all circumstances will yield desired results most effectively and efficiently.

These Best Practices have come from well minded people who have shared their successes at solving problems in a given domain. People have either intuitively found certain practices to be superior and best suited to solve some problems or they have iterated over and tried multiple solution paths, to solve a problem over and over again and optimized their approach until Best Practices for their context has emerged. This is not to say that there exists a Best Practice for all problems. In HBR’s Nov 2007 Article: Leadership Framework for Decision Making, the authors assert that Simple Contexts are the domain of Best Practices.  As per the article, the characteristics of a Simple context;

Simple contexts are characterized by stability and clear cause-and-effect relationships that are easily discernible by everyone. Often, the
right answer is self-evident and undisputed. In this realm of “known knowns,” decisions are unquestioned because all parties share an
understanding. Areas that are little subject to change, such as problems with order processing and fulfillment, usually belong here.

Best practices are suited only with in a simple context. Take for example the case of stolen/lost credit cards. The banking and credit card industry has faced this problem over and over again. Solution to this problem for both the credit card holder and the credit card company has been codified into best practices. This has been possible through simplification of the context through technical improvements in supporting infrastructure and collaboration between various credit agencies to simplify their domain. And not the other way around. Best Practices have not enabled simplification of the context, actually because of simplifications in the context Best Practices have emerged/formulated.  I believe that instead of seeking Best Practice solutions for one’s operational context, one should instead focus on simplifying the context towards achieving effective and efficient means (practices).

The solutions all are simple…after you have arrived at them. But they’re simple only when you know already what they are.

Zen and the Art of Motorcycle Maintenance – Robert M. Pirsig

My take of why Best Practices are believed to be so great is because  Best Practices carry a sense of assurance to provide, consistently, most effective and efficient results. Desirability for these benefits trigger transfer of Best Practices from one organization to another. This transfer happens via cross-pollinating agents, most likely to be consultants.

Richard Dawkins, 1976 in his book “The Selfish Gene” coined the term “meme” as an analogy to the concept of gene. A meme is any unit of cultural information, such as a practice or idea, that is transmitted verbally or by repeated action from one mind to another. Examples include thoughts, ideas, theories, practices, habits.

Within today’s corporate culture, the notion of Best Practice is a meme.

Richard Dawkins:

“If a meme can get itself successfully copied, it will”.

The Best Practices meme has a strong pull from receivers (demand), after all who doesn’t want the best. And I would argue that there is much stronger push from the suppliers (consultants) to sell Best Practice solutions in order to satisfy receiver’s need.

Richard Dawkins:

“Effective memes will be those that cause high fidelity, long lasting memory,” and not necessarily the ones that are “important or useful.”

Best Practices meme have high fidelity between both receivers and suppliers when they are simpler. Meme’s do not replicate exactly as the original when they get complex. For it to be memorable it hinges on simplified core elements that stick in the minds of people, easy to be mimicked for further replication. Either that or in the melee of buying & selling services, quick fixes to long standing problems and trivialization of complex contexts into simpler ones, unwittingly or purposely people have creatively oversold Best Practice solutions. In this process activities/practices that have no demonstrable track record for betterment have been tagged to be “the best” and effective practices are stripped of their contextual elements making them sell-able to wider domain of problem statements.

So, are there any Best Practices? – I think not. I am firmly in the camp with many others who have suggested to get rid of the term Best Practice. Few alternatives that I’m aware of are – “Good Practice”, “Current Thinking”, “Contextual Practice”. For now, as an alternative, I will personally settle for “Good Practice” since it does not carry the sense of finality and allows room for improvement. Conceptually I do believe that with in simple contexts certain Good Practices can provide effective and efficient results. However, I strongly urge that Good Practices should not be blindly accepted for its apparent goodness. All practices need to be tried out atleast once with in your own context to determine whether a given practice is good for you or not. A good practice in essence does not carry with it the assurance that what worked for me will also work for you. I am comfortable accepting practices and judging their “goodness” against my objectives and not benchmarking these against others who have apparently the best implementation of a best practice.

Uncategorized Best Practice, emergence, Good Practice, Meme

Def: Velocity is the amount of product backlog that a team can fully implement through product owner acceptance with in a given sprint.

Future can not be predicted. However one can arguably say that project release date based on velocity measurements is many times more probable to be true than the probability of releasing on a date arrived from purely educational guess work. I’m not aware of a scientific study that will prove my assertion but I’m confident that the probability of my assertion being true is greater than it being wrong

Tools & Artifacts future, productivity, release, team, velocity

Most of us have to pay a visit to the scissor man/lady every couple of months. Others who don’t have to or choose not to, I envy you. As a kid, my visits to the barber shop were scary ritual. The thought of someone using scissors, clippers and other sharp pointed tools a few millimeters from my scalp and ears was terrifying. After surviving many close calls with sharp objects I was fairly certain that the worst that could happen would be a couple of cuts, minor scrapes and a hideous hair style. Over the years what gave me courage to go to our neighborhood barber shop was our barber’s technique/skill and relaxed friendly conversation that always ensued at his place. (That and my mom and lately my wife :).

I have not completely overcome my fear of visiting barbershops yet. There is always the possibility of getting bruised or a bad haircut. However I find it reassuring that it is in the nature of my fur to grow back and warrant another shot at presentable appearance.  Scrum teams & PO’s that appreciate this emergent characteristic of product backlog find themselves engaging in healthy dialogue during backlog grooming sessions . As a coach, helping product owner & team to groom their backlog I seek to use tools and techniques that foster collaboration, allowing them to acknowledge the emergent nature of product backlog items. I have often found myself playing the role of that friendly neighborhood barber, armed and ready with agile tools to help product owners and teams groom their product backlog.

Collection of techniques

1. User Story format: (As a [type of user] I want [some goal] so that [some reason])
2. Three C’s (Card, Conversation and Confirmation)
3. INVEST model
4. Special story types – Research, Spike & Tracer bullet

Collection of Tools

1. Index cards or Sticky Pads (lots of them)
2. Sticky dots
3. Sharpies
4. Poker Planning cards
5. Whiteboard/Flipcharts.
6. Scissors

These are some tools & techniques that I find myself applying most frequently. The list above is a basic toolkit. (Good barbers always have a secret stash of innovative experimental contraptions, should the customer feel adventurous

Application of tools and techniques during product backlog grooming is highly contextual and it largely depends on the nature of product backlog prior to grooming session, comfort level of product owner and team with grooming techniques and other external factors that indirectly influence the backlog grooming session.

A well functioning agile team grooms its product backlog, at least once, every sprint to build a professional product that sports stylish curls with hints of highlighting.

Product Backlog emergence, product backlog grooming

My wife and I are blessed with a beautiful baby girl. She came to our world in the month of August. Since then blogging has taken a back seat. Over this period I have felt stretched on time to do some meaningful writing. It was my assumption that blogging would be fairly straightforward – A couple of hours each week, and I will be ready to churn out a blog. For me, it was not to be as simple.

When I started back in July, I was not sure Why? – I wanted to blog. After this hiatus I believe I have come to terms with my purpose behind this effort.

My intention with this blog is to journal my activities and thoughts as an agile coach. I hope others benefit from it.  Most important for me is to be able to look back at my writings in a future date and reflect at how I have evolved over a period of time. For the last couple of years I captured similar artifacts (notes, pictures, learnings) in physical notebooks, word docs and various other formats which to a large extent are beyond recognition. The thought that my posts may possibly be read by other people forces me to strive for clarity & helps me to be a better communicator. I believe that if at least one other person understands my posts then there is a better chance that I, in future, will understand it myself.

I have now abandoned my quest to be a prolific blogger. I am now comfortable with the notion that my posts will be far and between – there I said it! I hope to make them good enough for the future me

Uncategorized confessions, excuse, purpose

A few months ago, I was facilitating sprint retrospective for a multi-cultural team that had members of different national origins (UK, South Africa, Angola and United States). We started gathering information regarding their first sprint. I realized that this team was struggling to simply get along! We took a step back and created a focus for our retrospective. We elicited the following goal for our retrospective:

During the course of this retrospective, team members discussed how they can improve trust, respect & communication within the team. The fact that the team had individuals from different cultural background was not missed. The crowning moment during the retrospective came when one of the team members said:

“In my culture, we have to be friends, for me to do good work. In the western culture, I have to do good work, for us to be friends.”

These words have echoed in my head for a very long time. His insight has been a great learning experience for me. I have learned to acknowledge and appreciate differences in individual values. But what are these values?

Exercise: Sharing Values

Step I: Identify a pair (optional)

Ask your team members to identify someone within the team that they are comfortable with. Ensure all pairs have been identified and if there are odd numbers of people, the facilitator can pair with the lone individual. Ensure that every one has some index cards and a sharpie.

Step II: I don’t like it …

On a single index card, ask each team member to complete this statement:

“I don’t like it when someone/people …… “

Encourage each team member to write down 2-5 such statements on separate index cards.

I have found that it is easier for us to identify behaviors that we don’t like, especially when we have been at the receiving end.

Step III: Exchange Cards

After everyone is done writing, exchange all your cards with your partner.

Variation: If you have opted not to do Step I, then place all these cards in the basket/hat. Now randomly pick cards from the Basket/Hat. If you get a card that is yours, then place it back into the bucket/hat. Ensure all cards have been distributed.

Step IV: I like it …

On the back of each index card, write down a statement that will counter your partners “I don’t like it …” statement with

“I like it when someone/people….”

You will be amazed how your team member’s insight into your hot-button issue helps you recognize behavior that you will truly appreciate!

Step V: Share Values

Go around the table where each team member reads aloud a statement that begins with “I like it when …”. Take turns reading one statement per team member at a time until all statements are exhausted.

These are your team’s value statements. These statements provide a simple list of positive behaviors that are currently valued in your team.

Caution: As a facilitator/scrummaster refrain from vocalizing these statements yourself. I believe it is very important for everyone in the team to hear these positive behavioral statements from their peers.

Step VI: Team Values Chart

On a Big Visible Chart only capture statements, that begin with “I like it when …”. Radiate this information in your team area for the benefit of your team members and others who interact with your team.

This exercise takes less than 30 minutes to do. Try this exercise again after a couple of months; see how far your team’s values have evolved. As a manager/scrummaster/team member, if you feel tempted to dictate good behaviors to your team, take a deep breath and try this exercise with them. Maybe, just maybe, your team will self-organize to correct its own behavior.

ps: Suggest destroying index cards that were used for this exercise.

Facilitation Exercises culture, exercise, scrum, scrummaster, self-organization, team, value