I delivered a webinar called Agile Metrics for Team and Product Progress last week, thanks to the nice folks at Innovation Roots.
I had fun and so did many of the participants. One person gave me a new saying about metrics (at the end, during the Q&A):
Are you data-driven or data-informed?
It's such a great saying. I told her I was stealing it.
Here's why. If you want predictions and targets, you use data to drive the decisions and work. If you want the ability to replan you use data to inform your next steps.
Note: data-informed does not mean you don't create broad-stroke plans, such as roadmaps and gross estimates. You may still do so. I do. I find both the roadmap and my estimate (smaller or larger than a breadbox) helps me decide which products to deliver and when. And, I use the data about my cycle time to inform my replanning. (I don't use velocity as a personal piece of data.)
You've seen people who want to use velocity as acceleration or a target. However, Velocity is not acceleration; it's a measure of capacity. Those people think of data as a driver.
I have a suspicion about this mindset. Gantt charts and detailed WBS create the mindset that if we have a target, we will get there in the time and at the cost we specified. We can, for certain kinds of products or services. (For example, construction folks have specifications at a specific cost per square foot. And, the local garage knows how long it takes to change the oil so they can provide a flat fee for the service.
If we use agile approaches, we are inviting change, which means we can't estimate everything at the beginning. And, we want to understand our progress, so we can readjust because we are responsible for our use of the organization's money.
If we use agile approaches, does that mean we never have a target? Nope, I have target dates all the time. I break my work into small chunks so I can learn as I proceed if I will make that target date. I use my data to inform me about my pace. Sometimes, I can change how I work to meet my target date. Sometimes, I drop work. Sometimes, I'm early.
I loved that question about mindset: Are you data-driven or data-informed? The mindset helps you consider what to measure. And, yes, that's why I separated team measures from project status measures in Create Your Successful Agile Project. Teams might do as I do, and create targets to see how they are doing. However, managers need to see product status, which uses data to inform and replan.
WBS and Gantt charts are “deterministic” artifacts for the projects. In any mature project management method, the probabilistic representation of the work is needed and in many places Mandated.
Those probabilistic models provide date that “informs” the decision making process. That “data” has precision and accuracy to provide “confidence” in the data used to make those informed decisions.
Glen, exactly. You and I have agreed to disagree on this before 🙂 In my experience, and with my clients, the Gantt chart is a great way to show how the project will not work. That’s not because the people are stupid. It’s because they need to change the work, or the teams learn, or the PO (used to be the product manager) learned as the project proceeded.
If you can use a WBS and Gantt that doesn’t change (much), that’s great. In fact, in Manage It!, I actually said that waterfall was a great approach if you could meet the conditions for it.
You and I work in different domains. In mine, teams and projects often learn so much as they proceed, that creating a detailed WBS is a useless task. I’ve long been a fan of rolling wave deliverable-based planning, so we could see finished features as we proceeded through the project. I suspect you haven’t read Manage It! (which is okay!). In that book, I described using yellow-sticky planning, the equivalent of a WBS, for the next deliverable. I recommended that deliverable be not more than a month away.
Is a WBS for the next small time period helpful? It can be, depending on the time duration.
Is a WBS or other primarily predictive (data-driven) approach helpful in a project where we expect change? Where we want to use agile approaches? In my experience, no. That’s where using data to inform a small amount of planning, do the work, and the replan is helpful.
As I said in the post, I use targets for myself. I keep a detailed word count spreadsheet because I have a word count I want to hit for my writing, every week, month, and year. I don’t use the targets to beat myself up if I miss them. I look at the data and say, “Oh, I was with a client that week,” or, “I was preparing for a big dinner” (as I did last week). I use the data to inform my next steps.
The probabilistic approach you recommend is something I use, also. I now use it for roadmapping to inform the backlogs. See the summary post, https://www.jrothman.com/mpd/2017/09/alternatives-for-agile-and-lean-roadmapping-part-7-summary/.
My projects usually have a lot of senior stakeholders with very different business functions and different interests in the result. I need to be able to tell a story about the project and the product so that the stakeholders will understand the flow of activities and when they and their folks will need to be engaged. Gantt developed his bar charts to be a communication tool, and that’s how I use them.
My projects are never about “new physics,” as Glen likes to say, but about transitioning from old ways to new ways. But for any project, we need to set business expectations. Part of that is the expected degree of change in schedule and cost due to current uncertainty, and we need to communicate that clearly.
“We have a 70% confidence in being ready to transition to production by October 1 and a 90% confidence for November 1.” Business people typically grok language like that, and if yours don’t, it doesn’t take much to improve their understanding. They might tell you that November 1 isn’t an acceptable timing for them because it’s the middle of the quarter, and they’d prefer January 1. Those are among the most productive conversations you will have for a lot of projects.
I love conversations like that. I never happened to use Gantt charts because we didn’t have the tools back when I started to manage projects. I did use PERT charts and probabilistic scheduling. I have to admit, I don’t think anyone ever told me to hold off for a month, but we did have the conversation about what we did not need to include in the release to get the product out earlier.
I had it happen last year, so it was top of mind. I’ve also had ‘pruning’ conversations. It’s amazing what folks realize they can live without, after you’ve tied oak trees in knots to get it for them. C’est la vie!