Tools & Artifacts

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.

Velocity

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

The amount of product backlog in the definition above is often expressed in terms of “story points” or “ideal days”. Fully Implement implies that the product increment built during the sprint is accepted by Product Owner and is potentially shippable or at-least meets the definition of done.  Also, velocity measurements are made only at the end of every sprint. 
.
Track Record
The purpose of taking velocity measurements is to capture team-system’s track record at translating product backlog items into acceptable working software. This track record is typically expressed in total number of story points (velocity). Traditionally projects have been estimated prior to the start of the project. Estimates at their best are educated guesses. Guesses – none the less, based on assumptions that need validation from reality. In traditional project management this aspect of validating assumptions, made during the start of the project, is severely lacking during project execution. Project management is then reduced to protecting the planned estimates as opposed to achieving desired goals. Iterative delivery of software every sprint and taking velocity measurements for every sprint has negated the need to make large inaccurate estimates for the entire project. Instead small inaccurate estimates are made for each sprint.  And that is a good thing! velocity works with the fact that estimates are inherently inaccurate (cone of uncertainty).
.
Velocity acts as a correction factor. 
This is how: Say a team estimates (makes an educated guess) that they can fully implement 40 story points of work in a sprint. At the end of the sprint if only 20 story points are fully implemented and accepted then the team’s velocity for that sprint is 20. Velocity is informed by reality. Going forward, in the next sprint, if the team is consistent with their estimating technique then they can reasonably expect to complete about 20 points of work. Disciplined velocity measurement provides correctional ability to re-estimate amount of work that can be reasonably expected to be done in the next sprint. Thus allowing for reliable commitments for a given sprint. 
.
Velocity and commitment.
It is important to note that velocity does not imply commitment. Most of us understand this however we behave at odds with our understanding. Too often I have observed product owners and other managers demand that a team commit to 20 points of work this sprint since their velocity previous sprint or average velocity was 20 points. Velocity is a tool to make reliable commitments, not a substitute for team judgement at making these commitments. Velocity does not imply commitment for the upcoming sprint and it definitely does not imply commitment over the next bunch of sprints. 
.
Peering into the future:
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 ;)
.
Velocity directly depends on:
Reliable velocity  measurement are based on consistent sprint length, same team members, similar product domain, similar product technology and consistent relative estimating. These are the direct cause and effect links with velocity. Changes to any of these factors make velocity unreliable. There are numerous other indirect factors which affect velocity. Understanding these requires understanding the relation between velocity and team. 
.
Velocity and team:
The most common misconception is that velocity is an attribute of a team. This is understandable since changes to team members directly impacts velocity. This link of cause and effect is frequently yanked where in team members are changed thus impacting velocity thus re-enforcing our belief that velocity is an attribute of team. When in-fact velocity is an attribute of the system which includes both the team and the organizational environment surrounding the team. An example of organizational environment impacting velocity is evident through the dramatic increase in velocity observed in teams after they are collocated. There are various other organizational factors that affect velocity of a team system. Organizational culture and management’s response to team impediments are the biggest contributors to velocity improvements.
.
Velocity and team productivity:

Velocity is often mis-used to express team productivity. There are two common ways of mis-using velocity to express productivity

  • MisUse 1. Velocity used to comparatively express productivity of one team over that of another team. This is when Team A is deemed more productive than Team B since Team A velocity in story points is greater than that of Team B.  
  • MisUse 2. Velocity from previous sprints is used to express relative gains in productivity. In other words if teams velocity in sprint 1 was 10 and then in sprint 4 it is 20 then it is incorrect to state that team doubled its productivity in Sprint 4. Let me share an example of a real team. This team had a consistent velocity in the range of 70-80 story points. In one of their sprints the team created an automation script that effectively made testing data inconsistencies a breeze. Stories that were initially estimated at 8 were now being estimated at 2. The level of effort involved with these stories decreased dramatically and so did their relative estimates. Their total velocity however remained at 70-80 story points. Now you will agree with me that the automation script did improve team productivity however it didnot change overall velocity. This is one example of why velocity is a bad measure of productivity. For an excellent article on productivity; see Martin Fowler’s article here.

What is Definition of Done (DoD)?

DoD is a collection of valuable deliverables required to produce software.

Deliverable that add verifiable/demonstrable addition of value to the product are part of the definition of done. Such as writing code, coding comments, unit testing, integration testing, release notes, design documents etc. Definition of done helps frame our thinking to identify deliverable that a team has to complete in order to build software. Focusing on value added steps allows the team to eliminate wasteful activities that complicate software development efforts. It is a simple list of valuable deliverable.

DoD is the primary reporting mechanism for team members.

My favorite agile manifesto value is “Individuals and interactions over processes and tools”. Would it not be effective reporting to say, “Feature’s done”? DoD is a simple artifact that adds clarity to “Feature’s done” statement.  A feature or Product Backlog Item is either done or it is not-done. Using DoD as a reference for this conversation a team member can effectively update other team members and product owner. Kindly note that by primary reporting mechanism I do not intend that DoD is the only reporting mechanism used.

DoD is informed by reality.

Scrum framework sets a very high bar of delivering “Potentially Shippable Software” at the end of every sprint. To me, potentially shippable software is a feature(s) waiting on product owner’s discretion to be released to end-users. Teams that are able to release to end-users within a maximum of 2 days can be reasonably said to have their product in potentially shippable state. For such teams: Potentially Shippable = Definition of Done.

For other teams working to achieve potentially shippable state, their DoD contains only a subset of deliverable necessary to release to end users. Such teams have DoD at various levels:

§   Definition of Done for a Feature (Story or Product Backlog Item)

§   Definition of Done for a Sprint (Collection of features developed within a sprint)

§   Definition of Done for a Release (Potentially shippable state)

There are various factors which influence whether a given activity belongs in DoD for a feature or for a sprint or for a release.

The most important is for the team to realistically answer:

Can we do this activity for each feature? If not, then

Can we do this activity for each sprint? If not, then

We have to do this activity for our release!

For activities that cannot be included for a sprint/feature: “Discuss all of the obstacles which stop them from delivering this each iteration/sprint” - (Building a Definition of Done)

Some of the common root causes for impediments that I have observed:

a.   Team does not have the skill set to incorporate activities into the definition of done for a sprint or for a feature.

b.   Team does not have the right set of tools. (Example: continuous integration environment, automated build, servers etc.)

c.   Team members are executing their sprint in mini-waterfalls. Aha! Opportunity to be more cross-functional. Sharing of responsibilities across functional silos.

DoD is not static

DoD changes over time.  Organization support and team’s ability, to remove impediments, enables inclusion of activities into DoD for feature/sprint.

DoD is an auditable checklist.

Task break down for a feature/story happens during sprint planning and also within a sprint. DoD is used to validate whether all major tasks are accounted (hours remaining) for. Also, after a feature or after a sprint, is done, DoD is used as a checklist to verify whether all necessary value added activities were completed. It is important to note that the generic nature of the definition of done has some limitations. Not all value added activities will be applicable to each feature since the definition of done is intended to be a comprehensive checklist. The team has to consciously decide about applicability of value added activities for each feature. For example following user experience guidelines for a feature that provides integration point (eg: web service) to another system is not applicable to that particular feature, however for other features within the system that interface with a human being require user experience guidelines to be followed.

Summary:

Definition of done is orthogonal to user acceptance criteria (functional acceptance) for a feature. It is a comprehensive collection of necessary value added deliverables that assert the quality of a feature and not the functionality of that feature. Definition of done is informed by reality where it captures activities that can be realistically committed by the team to be completed at each level (feature, sprint, release).