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.
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.
Stories ‘not-done’ at the end of sprint:
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.
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 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:
Next we talked about end user functionality and picked a few functional cases.
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.
Great article, Dhaval. I arrived here through a thread at LinkedIn where you had mentioned it to another CSP — I’m glad to have found it. 🙂
I love this & can’t wait to try it out! A nice metaphor to encourage teams to decompose work in order to make the risks and (self-inflicted) complications more visible. I’d like to put a pointer to this post in my training reference materials, if you’re OK with this…let me know!
you are most welcome to use this in your training reference material