Posts tagged coaching

Walk the dog

This is a simple technique with a marketing twist to its name. This title came to me while coaching a team that was struggling to behave cross functionally and were paralyzed at delivering working software at the end of their sprint. It is a simple mental discipline that I have often used in crafting good user stories and I wanted them to walk their user stories with me.

Everyone is not an expert at analyzing business requirements against technical complexity, but most have had practice walking a dog. So lets ‘walk the dog’, plus this is much cooler than ‘lets walk the user stories’.
Metaphors only go thus far, but a cool title goes much farther. For me, a fancy title, acts as a trigger that allows me to break from the ongoing chain of discussions and engage in an exploratory exercise.
I have used this technique a few times to address primarily two types of challenges, here are these stories:

Stories ‘not-done’ at the end of sprint:

This team was formed of team members that were experts at their part of the code. This was their second sprint as a team and they were struggling to cross-train. To their product owner’s credit, he was creating user stories that were truly vertical slices of functionality that represented end-to-end implementation of features. Their main challenge was that in their two week sprints they were unable to meet ‘definition of done’  (fully integrated & tested) on these user stories.
.
In response the team was asking the product owner to further split these user stories in two to three horizontal slices that could be integrated in later sprints. The product owner, was rightly pushing back since that would mean that none of his features would be developed end-to-end in a sprint. As their coach, while I was supportive of the Product Owner’s judgement, I was not sure whether I truly understood the team’s problem. I wanted to try an exercise of discovery with the group, and was concerned whether the group would allow for space and time to go with it.
.
So I christened ‘walk the dog’ technique. “sounds like its time to walk the dog” – I said.
‘Sounds cool’ said some one in the group, others looked perplexed and few others perked up.
.
So I asked the team to bring all their user stories from the current sprint. Starting with the first one, I asked them to walk me through the changes in code base that they will have to make in order to implement this story. I clarified that changes were considered only at the component level and not at the individual class file level. Then we picked another user story and did the same for that user story. At the end when we were done with all the user stories in the sprint, the picture looked like this.
Walk the dog stories in sprint

Crude copy of white board diagram

We all stood back and after a few private moments of reflection, one of the teammembers asked why we are modifying on so many components in the same sprint? – bingo!

After this short diagraming exercise where the team literally walked each user story (the dog) through the changes in our components, the team was able to realize that the problem was not with the way user stories were split, but it was the lack of focus created by too many moving parts. The team was then able to rationalize why they were still trapped in their silo’s and why they were facing so many integration problems.

Earlier the team was asking the PO to split user stories along components so that they could manage complexity within their sprint. This exercise revealed another approach for the team. By limiting technical diversity for their in-sprint user stories the team was able to reduce complexity within their sprint and also deliver vertical slices of valuable functionality for their product owner.

Vertical Slices of functionality! – Not in my world

Another context where ‘Walk the dog’ was useful to me as a facilitation technique was when a team was locked into splitting stories horizontally across components.

Their architectural component environment was tremendously complex. Because of NDA’s with this client, I cannot reproduce their high level architectural diagram, but imagine a bunch of boxes interacting with each other. Some thing like this:

Their working context was further complicated. The team members were doing scrum and working on components A1, A2 and B. Other components X’s and Y’s were already developed by other projects. This is not to say that changes were not expected on component’s X & Y’s.

So we played ‘walk the dog’. This time however, I presented this technique as a game.

The Game:

Imagine that you have a pet dog and you are new in town. You take your dog to a park for a walk. You have never walked through this park but you have seen pictures and have seen the layout at the entrance to this park. Your objective is to enjoy your stroll through the park and get home before it gets dark.

The Park:

The actual diagram was printed and pasted next to a white board. Next we drew all the boxes (components) on the whiteboard and I purposely asked them not to draw connecting lines between the components. So the diagram on the white board looked like this:

The Dog:

Next we talked about end user functionality and picked a few functional cases.

The Walk:

We picked one end user functionality and charted its walk through all the components that would be affected.

Getting home before dark:

I then asked the team to do a quick round of planning poker style estimation, to decide whether this end-user functionality can be completed within one sprint.

In the case of our first end user functionality, the team quickly came to consensus that the end user functionality could not be delivered in one sprint.

We talked about why it is not possible to develop this slice of functionality. Over some conversation, it transpired no one in the team was confident that services exposed by component X2 will work. They said that although their platform teams have developed functionality that ‘should’ work for them, their prior experience with that group has not been good.

I asked ‘what if’ the component X2 worked as expected, would this end-user functionality still be unattainable at the end of a sprint?.

They said, there is no issue if the platform works as expected. We will be home with the dog before supper. No worries.

So for this particular end-user functionality, lack of knowledge about exposed services was the issue. Our conversations turned to how we can gain sufficient get-your-hands-dirty type learning. Reintroducing special story types such as research, spike & tracer bullets helped to stage a spike that will allow them validate functionality in their platform and deliver end user functionality for their sprints.

Same Park, New Dog:

Methodically we walked each end user functionality through the architectural component park. Along the way, we split many stories into thin slices of end to end functionality. This exercise resulted in a product backlog with enough vertically sliced user stories for the next 2-3 sprints. Valued byproduct of this was a list of immediate project risks, action items and shared understanding.

For this team’s case, the issue was not that they were technically unable to deliver vertical slices of functionality. It was their inability to work through organizational impediments. For them all external components represented a big department that had to be wrestled with.

Focusing on thin slices of functionality, exposing component uncertainties one at a time and a good walk in the park helped them reveal impediments. Prioritization of vertically sliced user stories by the PO helped the team and ScrumMaster to prioritize their impediments against the product backlog. Products developed in increments of features/functionality as opposed to the ones developed in increments of components allow for early realization of returns on product investment. Many teams resist this path since the overhead of dealing with all organizational impediments all at once often seem unsurmountable. This exercise helps reveal and prioritize these impediments. It takes courage and tenacity on part of the scrum team to then relentlessly pursue resolution of these organizational impediments – one at a time.

Coin toss exercise

coin-toss

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
Round 1 Round 2 Round 3
All Coins
1st Coin
Total Value
  • 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.

My favorite Coaching Experience

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. 

18772254husumfalls

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

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.