Good managers try to measure important aspects of their business with leading metrics (aka “key performance indicators”) that precede desired outcomes. Managers seeking agility often try to measure behavioral compliance to agile practices, but can inadvertently create a lying culture. When people don’t understand the metrics or can’t provide feedback, they perceive metrics as bureaucratic nonsense that gets in the way of “real work”. Trust-building lies at the heart of good metrics programs, particularly those that involve self-reporting. Managers can promote honesty by revealing their own personal motivators (their “internal metrics”), by researching others’ personal motivators, and by working to align business goals with all those motivators. Managers build understanding by collaboratively developing and retrospecting on measurement efforts. This honesty and understanding improves the accuracy and utility of the metrics.
“It’s not about money. It’s about the willingness to outwork and outlearn everyone.”
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