Paul decuded to use 30 minutes of Backlog refinement time to report out what, he and Sherry-Anne had done. They were ready to lay out what they had found and presented a workflow they feel will be do-able for the team.
“What we found is escalation paths, metrics, and time-boxes are widely used in our industry and inside our company. Just not so much at the Scrum Team level. Although, many of the scaling and enterprise efforts have put this in the leadership efforts,” Paul began. Sherry-Anne continued, “It seems the closest we get to metrics is tracking the time we get pulled off our backlog, sent to work on production problems, address critical customer issues, and/or the all too many all hands meetings.”
Someone mutters “Escalation equals death marches and weekends.”
Milana pulls everyone back into the conversation by asking if metrics is another conversation. Sherry-Anne wrote ‘metrics’ on a stickie and put it on the ‘Impediments backlog board’.
“Did anyone get a chance to look at the Slack messages we shared on the findings?” Everyone had to check their phones for some reason, OK.” Sherry-Anne said. She and Paul then put up a PowerPoint that showed hierarchies, escalation matrices, and focused on management issues they found in their research gathered during the Spike. Everyone kept glancing at the clock. Milana, the Scrum Master, asked what Paul and Sherry-Anne about their Spike outcome.
Paul steps in. “It begins with understanding the acceptance criteria that clearly define what needs to be developed at the user / chooser level. Scrum expects this to come from the P.O. and for the P.O. to work with the business to divine that. Then the team is supposed to figure out how to validate the expectations.”Sherry-Anne began. “Paul and I think we can’t wait for a top down, crisis driven resolution. We all know how the trail of blame goes. In our talks the biggest issue we have is getting verifiable acceptance criteria, as this is what is needed to deliver effective and efficient outcomes each sprint.”
Pat shrugs. “I’m sorry, this whole thing is starting to sound like another Monty Python Grail Hunt. We are the Knights and business is the French in the castle. If we are going to make this work, we need to use this escalation process to engage and close the gap between what is being asked for and how much we can validate.”
Donna pipes in. “Pat, I have no idea what you are talking about . . .” Aleem’s laugh interrupts her and he casts the YouTube Pat referred to. “OMG Pat”, Donna exclaims, “That is so cruelly accurate. It is not funny.” Fredric jumps in, suggesting that as soon as there is an issue with validation, it is brought up and tracked on an issue board. Because Fredric followed the Slack thread, he puts some of the pieces together. “If the development team resolves it within a day, then we cross it off the list, if not then it is brought up at the daily standup. Depending on the issue, the P.O. will use their network to get a resolution. If it is business, the SM will take the lead, and if it is technical, the team will pick a point person to work with the SM or PO. Problems stay at this level for another day. If not resolved either the PO or the SM will take it to our Management.”
Dan leverages Fredric’s synopsis. “That is a great idea Fredric and should work in most of the situations we face. My concern is that we will spend all of our time on this and not enough time getting the product done.”
“Well we can spend our time productively, getting usable information, or we can run away from wooden rabbits being catapulted at us,” Milana pipes in. “Let’s continue.”
“Why such a short time at each level?” Praveed asks. “Good question Praveed,” Milana replies. “Our sprints are 10 days long. Each day a problem stays open equals 10% of a sprint. Any problem that isn’t resolved in 3 days has at least a 30% chance of impacting not just that story but the capacity to meet our forecast.”
Fredric chimes in, “So what does “resolved” consist of?” “Now that is the real heart of the matter”, Paul responds. “Since I am on the line for productivity and what we deliver, as well as the budget, there will be a lot of work on that. I know that we will continue to stop work on an undeliverable and now we will be able to show how much effort in time and people was put into trying to get a resolution. I also know that when we talk this way it is easier to get people to work on the resolution.”
Pat, the most experienced TDD in the company adds. “So, this escalation pattern just reverses that, with a twist. Given your slack messages about top down escalation models, we have to speak about problems in language that business listens to. From my experience, the only successful, relevant, issue to business is reduction of risk. From what we read and heard, risk is talked about through costs, waste, and loss of customer confidence. So, we need to communicate that when we move an issue up the escalation path. Good thing you and Milana speak fluent MBA, Sherry-Anne.”
Sven asked, “This could mean a lot to the UX and UI work. Where and when and how do we start?” “You, Pat and Donna were the source of our experiment, Sven. I experimented with Product Marketing on the ‘Sneak Preview’ Epic we have been stressed about,” Paul revealed. “In the Daily Standup, you, Pat and Donna reported you were blocked and were moving onto another PBI. It seems Product Marketing had missed the meeting to discuss the updated Sneak Preview Acceptance Criteria. As you know, Milana and I stood up on this and escalated the situation. I talked with the Product Marketing people to see what we could do to help them when we realized part of the problem was Product Marketing’ belief it was an all or nothing delivery. We agreed and showed them how far we could get when they collaborated on just a few of our concerns about verifying the outcome. What we did was agree on the case statement that if ‘x’ happened, then ‘y’ would be the outcome, as they added more conditions we just added in the acceptable outcomes on the wall.” Pat added, “It was great. It got so complex, their boss Kevin, asked that we help them sort this stuff out.”
Paul related how Prod Marketing felt the story couldn’t be smaller or clearer so he explained how working with us can break this story up into smaller deliverables. The turning point came when one of their recent hires mentioned this sounded like presentation on the impact Design Thinking had on the 900 million dollar IPO that “Blow their Minds” just did. We wished that Milana could have been there for that, but she was dealing with something and was late to the session. Fortunately, she took away enough to talk about the situation with us.
Milana continued, “After the meeting Paul, Pat, and Donna brought Sven and I up to speed. I had a separate meeting with Kevin, the Product Champion, to talk about how we could help him get us what we all needed. The three of us met with the sponsors and found their biggest concern is that the ‘little things’ that make or break a product are almost impossible to predict and that is why they need to have a big picture approach. We showed them how quickly things got clarified with the incremental nature of our work. When Product Marketing said it was willing to try based on the efficient and effective outcomes from our experiment, the sponsors saw it as a way to improve time to market, reduce stress, and build confidence with the users/chosers. They also want to see how we can make it happen. Don’t get too excited, they also want more miracles, sooner.”
Dan piped up. “Does this mean we can use some of the Design Thinking approaches? That would be great. I really enjoyed that on my last product at QizBag.”
The team, mindful of the time box. Wrapped up with an agreement they would have to mindful of their use of time and fascination with ‘new toys.’
Just before they broke, Milana asked about the Audibles spike. “We will get back to you on that,” was the mumbled response.
Agilest At Large 