Experience
Product Owner takes Vacation?
May 12th
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.
My favorite Coaching Experience
Apr 23rd
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.
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.
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.
Recognizing Bottleneck's
Mar 24th
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.

