Our team kept solving the easy stuff, the big deliverables seemed to take forever, and would inevitably come out with major bugs. Do the right things right… Why not just do that? For any one product, a number of people and processes come together. We automatically operated by priority, and this turned out to be the central problem. The chart below shows a 66% reduction in our severe bug rate since then.
Severe Bugs: Quality (priority 1-2)
It seemed to be the right thing: when a customer reports a bug of high priority, jump on it. When a server crashes, jump on it. When the senior person finds a critical bug, jump on it.
In our meetings, the teams decided that instead of “Priority” being our call to action, we should “order” our work, always consuming our backlog from first to last. Yet, we kept jumping on it. Continue reading
You may be interested in what Senex Rex does. Our mission is to help clients become highly profitable long term. When our clients make more money, they have greater freedom to innovate and their employees and shareholders have more freedom to enjoy life. We happen to think agility helps in many cases, so we often teach and coach agile theory and practice. Few contractors teach clients how to sustainably retain and improve agility; we specialize in that. We have many other tools in our tool box. Here’s a snapshot of the work Senex Rex did in February 2014. Continue reading
Senex Rex case studies help clients better understand the benefits and challenges of agility. Here is a perspective from Pablo Martin Rodriguez-Bertorello, Chief Innovation Officer of Exponential. Senex Rex trained Exponential’s executives, managers, engineers and product management staff to deeply understand agile theory and practice, so Exponential could stand alone with no further external training or coaching. Our mission is to effect permanent change, not maintain change. We are proudest when we leave the building and our clients advance rapidly on their own. —Dan Greening, Senex Rex Managing Director
Exponential adopted Scrum in July 2014, and rapidly achieved three great outcomes. We dramatically increased the rate we completed features, reduced our bug density and reduced our release duration. These outcomes followed a mass company training by Senex Rex, and deep executive commitment. No external coaching following Senex Rex training was required. Continue reading
The Goal by Eliyahu Goldratt is a business novel that recounts how a factory manager shakes off complacency and isolation to save his factory and its employees. Many MBAs, system scientists and agilists have read it.
I read The Goal 7 years ago. I was so excited I sent our CEO an email. “Have you read it? It has so many messages for us!” I said, breathlessly. “Yep. I’ve read it. Great book,” he said.
My coach friends and I have lately been trying to inspire executives and managers to sustain agile practices, to become competent agile coaches themselves. To help managers understand organizational agility, we have distributed copies of The Goal, foisting it on managers and begging them to read it. I felt I had to refresh my memory of it. On this, my second reading, I am inspired again, but for different reasons. Continue reading
Good communication between product manager and team, between value appraisal and product development, leads to success. It helps you build the right thing at the right time. When the Product Owner and Development Team communicate well, the Product Owner can forecast feature delivery dates with a statistical likelihood. It promotes great architectures. The Development Team can build, but not over-build, a resilient architecture suitable for likely future needs.
I developed the Forecast Horizon metric to measure team communication. Forecast Horizon is the sum of work estimates from the top of the backlog through the first unestimated Product Backlog Item. Since many Product Owner put unestimated Backlog Items at the top of a Backlog, you may choose to skip unestimated backlog items that have been modified since the last Sprint Planning or Grooming meeting. Forecast Horizon can be expressed in team-time, by dividing by a recent average velocity and multiplying by sprint duration. In my work, I usually talk about Forecast Horizon in weeks. Continue reading
Four-part user stories improve communication between Product Owner and Development Team. They include context about the user and the sponsor of the work, which inspires creativity and better architectures from the team. They also make Grooming and Sprint Planning meetings faster, they yield more successful outcomes, and they facilitate Product Owners making better trade-offs. Are they better than sliced bread? I’ll let you decide.
User stories are a short, structured format for Product Backlog Items in Scrum; descriptions of the functionality a Product Owner wants implemented. Explicitly naming the user and the value the user obtains forces Product Owners to consider users and helps developers rapidly understand what needs to be built. Historically, user stories have had three-parts: a stakeholder, a description of the functionality and a description of why the user wants it. I’ve found that adding a fourth part greatly improves ordering in the Product Backlog. Continue reading
I have a little mantra I say to myself whenever I walk in the door of an employer.
“How will I save or gain at least 10 times my daily salary for my organization today?”
This question challenges us, especially if we are buried in the beast of a large organization. We might not even know how we add value. But the confusion just points out that we have a responsibility to figure it out.
Once you figure out how you contribute, you should say to yourself, “Well how do I measure that?”
Once you measure yourself, you might wonder how you can do better. You start experimenting with what you are doing, and measuring outcomes. Continue reading
Product Backlog Item (PBI) writing in Scrum is best done by pairing a Product Owner with an architect or team member. The Product Owner brings a stakeholder perspective to the table, and PBIs should include that “value perspective” in every case. When the PO is not “primary”, you get PBIs that have no demonstrable stakeholder or business value.
However, some POs think they are the only people who can initially author PBIs. They think they must wait to talk to the whole team to get them into better shape. As a result, the whole team must edit confusing PBIs tied to an uncertain architecture.
When the Product Owner waits for the whole team to meet to incorporate developer insight, Product Planning slows, at very high cost to the organization. Continue reading
January is “New Years Resolution Month” for me. I plan what I’ll improve in the rest of the year and how I’ll do it. Roughly 88% of people who make New Years Resolutions fail [Lehrer 2009]. Twenty years ago, software projects had extremely high failure rates like this. The software industry started adopting “agile” management practices, bringing project failure rates down to less than 50%.