For the introductory post, see https://www.scrum.org/resources/blog/client-reports-back-progress-one-year-after-professional-scrum-kanban-workshop
Let's call the client-contact Lucy to protect her anonymity.
Somewhere between the CEO and 1st line management level, "you do Scrum, just get it done, how much money you need, and what kind of people you need." "It's just another framework." Salespeople were saying, "you're doing Scrum magic and making it faster." Sometimes people don't want to change.
Lucy mused, "I don't know how you can change this." "Do that and that, no prioritization, you do your Scrum, and just let me know because I want them both done by the end of the year."
"We have great customers, but our challenge is getting feedback from customers. The mindset was developers don't need to know the noise from the customer. The salesperson is the voice of the customer, which is progress. It was just project management. "
"Then we had the PSK training with John Coleman." It helped that Lucy was in the right position, but she was still a junior manager. Lucy was wearing three hats, developer, manager, and scrum master. "I said I'm wearing the Dev hat now, the SM hat then, etc." and that worked. It came to a head when there was no time for Lucy to code anymore. That was the hardest decision in her life. "It was a struggle to figure out what makes me a good manager and how you measure your success; it used to be palpable when I was a developer - I delivered this code to production."
"It was tricky when working on top-secret stuff, doing spikes with the Development Team for one day, while not risking the Sprint Goal. The paying customer was used to the billing metric, which we felt was a bit stale, so we pitched this to Product Management, developed it we thought without affecting the Sprint Goal. But actually, it did affect the Sprint Goal. 'Hey, guys, the Sprint Goal is more critical,' so Lucy went back to the CEO and said, 'Hey, we have a problem.' Then Lucy flexed her development muscles to help deliver the sprint goal yet deliver the new idea also - that felt good. Lucy missed coding. For Lucy, it begged the question, what is the definition of done for a developer/manager/scrum master. "
In the PSK workshop, a light bulb moment went off when Lucy saw the Kanban system can go upstream and downstream. "Previously we tried pre-Sprint Kanban board, in-Sprint Kanban board, post-Sprint Kanban Board. We had pre-production, lots of protection of the environment." I also recognized that moment; it was a telepathic moment, a Eureka moment for Lucy. She still remembers that moment. Lucy now realized that the entire value chain could be in the Kanban system.
Lucy continued. "Some people were not at the course, so I had to pitch to others afters. It took five sprints to get rid of story points. WIP limits had an immediate impact. The urge to start new work was challenging to be understood; to learning, for example, to develop one's capability. It was counter-intuitive for other managers that a developer could be 'idle' for a day. We used to deliver everything on the last day of the Sprint. Now we were closing stories early on. We adjusted WIP limits for a couple of Sprints until we got equilibrium. For a team of four, we had a limit of two Product Backlog Items; this encourages people to collaborate rather than go back into their siloes. It's still Scrum (with Kanban)."
"For transparency, we had a wiki page on Confluence, for each Scrum Team. Each of those teams was a platform team. We had a 'proto-Nexus.' " I think Lucy meant a variant on Nexus, which I'll dig into in another post.
"There was a re-org that messed up the Nexus. We went to business verticals instead of platform verticals. But we didn't re-org the teams to match the business verticals. People were eager to learn, of course, but it was a bit confusing; no self-designing workshops, no team reorg whatsoever, just learning. Self-organizing teams need clear goals rather than detailed work plans."
"We had some Sprint reviews with feedback from Product Management. It's hard to do a Sprint Review with only APIs. Only a select few in the Sprint Reviews. It was very technical. Done was a new API call."
"Our approach was 'This is our CFD; this is our WIP.' Feedback was, 'this doesn't look right.'; The approach to the Sprint Review was to facilitate the adoption of Scrum with Kanban. We used the free Excel files from John's workshop, but they didn't have the 80th / 90th percentile. We used the equivalent of an SLE and throughput. It helped the expectation setting. We were showing how Scrum with Kanban worked for us rather than the done increment at the Sprint Review, to enable people to learn and grow together."
"The new process in Jira forced us to put story points, so we put five story points in all stories. We saved so much time in refinement and planning by not using story points. We focused on what we need to do. We would break down epics and then use forecasting tools from Troy Magennis. We talked in stories, but in the team, we understood we had work items with #noestimates. 85% chance based on our throughput, come back to us after one sprint, and we'll be more accurate. 'This is just a forecast.' It took six months for this language to be accepted. For the majority of epics, the forecasts were pretty accurate. In the beginning, we had some fluctuations. I remember what helped us was publicly showing the forecast with a burndown against the forecast. We could see after three sprints the probabilistic forecast could be trusted. The transparency helped and eased the adoption of letting estimating go. It was a game-changer. "
OK so focus helped Lucy and her teams. Counting "done" Product Backlog Items, use of Kanban statistical analysis and Monte Carlo probabilistic forecasting also helped.
What tricks do you think Lucy is still missing?
Answers on a postcard please, or just comment below :). Thank you.