I debated writing this post.
I considered Jean a friend.
Even though we didn’t talk often, I think she considered me a friend.
I’m sad she passed away this week.
I’d like to share a story with you guys.
When I wanted to start LeadingAgile, I was scared. I didn’t have the 100K in the bank Mitch Lacey told me I needed to start. I didn’t have space on my credit cards to fund myself for a few months. What I had were a few good relationships.
Jean was one of them.
I called Jean one day and told her what I wanted to do. She gave me good counsel. I wanted to see if I could get on Rally’s subcontractor list. I had worked for VersionOne so that was complicated. Jean went to bat for me.
Getting on Rally’s subcontractor list gave me the confidence to step out.
Even thought I never did any work for Rally, having that option in my back pocket created sufficient safety for me that I was able to be brave. Jean helped me be brave. For that I will be forever in her debt.
Who knows how things would have turned out had Jean not helped me.
I like to think I could have done it without anyone’s help.
But Jean helped.
I’ll miss Jean Tabaka forever.
Thank you Jean.
May you rest in peace.
The talk is about Spotify’s current approach to getting aligned as a company. It covers:
- what problem we’re trying to solve, and how we’ve gone through two other models (OKR and Priorities & Achievements) before arriving at our current model
- how we define “Bets” using the DIBB framework (Data-Insight-Belief-Bet)
- how we prioritize bets using stack-ranking based on company beliefs and north star goals
- how we visualize bets on a kanban-like company level board, and group them into Now – Next – Later columns
- how different parts of the company visualize their own bets and align with higher level bets, using interlinked bet boards.
- how we synchronize and prioritize our work using different cadences at different levels of the company.
- how this model is used to support squad autonomy
- our challenges and learnings with this so far
Holy crap how did I manage to cover all that in 10 minutes?! Guess I talked fast
Some sample slides below.
In the first part of this series, I said I liked order-of-magnitude estimates. I also like targets in lieu of estimates. I’ll say more about how estimates can be useful in part 3.
In this part, I’ll discuss when I don’t like estimates.
I find estimates not useful under these conditions:
- When the people estimating are not the people doing the work.
- When managers use old estimates for valuing the work in the project portfolio.
- When management wants a single date instead of a date range or confidence level.
There are more possibilities for using estimates in not-so-hot ways. These are my “favorite” examples.
Let me take each of these in turn and explain how agile specifically helps these. That’s not because I think agile is the One and Only Answer. No, it’s because of the #noestimates discussion. I have used #noestimates in a staged-delivery project and on agile projects. I have not been able to do so on iterative or serial (waterfall/phase gate) projects. Of course, with my inch-pebble philosophy, I have almost always turned an iterative or serial project into some sort of incremental project.People Estimate on Behalf of the Project Team
We each have some form of estimation bias. I have a pretty good idea of what it takes me to finish my work. When I pair with people, sometimes it takes longer as we learn how to work with each other. Sometimes, it takes much less time than we expected. I expect a superior product when I pair, and I don’t always know how long it will take us to deliver that product. (I pair-write with any number of people during the course of the year.) Even with that lack of knowledge, we can pair for a short time and project to a reasonable estimate. (Do a little work and then re-estimate.)
When people who are not part of the project team estimate on behalf of other people, they don’t know at least these things: what it will take the real project team to deliver, how the people will work together, and how/if/when the requirements will change. I have my estimation bias. You have yours. We might learn to agree if we work together. But, if we are “experts” of some sort, we don’t know what the team will encounter and how they will handle it.
I too often see experts ignore requirements risks and the potential for requirements changes. I don’t trust these kinds of software estimates.
Now, when you talk to me about construction, I might answer that we know more about construction. We have dollars per sq. foot for houses. We have dollars per road mile for roads. And, I live in Boston, the home of the Big Dig. Every time we remodeled/rebuilt our house, it came in at just 10% over the original number. We worked hard with the builder to manage that cost.
Those projects, including the Big Dig, were worth it.
How do we make software projects worth it? By delivering value as often as possible and asking these questions:
- Is there still risk to manage?
- Is there more value in the backlog?
- How much more do we want to invest?
Software is not a hard product. It is infinitely malleable. What we deliver on Monday can change the estimate for what we want to deliver on Tuesday, Wednesday and Thursday. We can’t do that with hard products.
When other people estimate, we can’t use what we learn by working together and what we have learned already about this domain. Agile helps this specifically, because we deliver often and can re-estimate the backlog if we need to do so. We understand more about the remaining risks because we deliver.Managers Use (Old) Estimates for the Project Portfolio
I have seen managers use estimates to value projects in the project portfolio. I wrote a post about that years ago: Why Cost is the Wrong Question for Evaluating Projects in Your Project Portfolio.
Here’s the problem with old estimates. Estimates expire. Estimates are good for some time period. Not forever, but for some number of weeks. Depending on how you work, maybe the estimate is good for a couple of months. Estimates expire because things change: the team might change. The codebase and the requirements have certainly changed.
However, project cost is only one part of the equation. Value has to be another part when you think about the project portfolio. Otherwise, you fall prey to the Sunk Cost Fallacy.
You might say, “We use ROI (return on investment) as a way to value projects in the project portfolio.” Now you depend on two guesses: what it will take for you to complete the project and the sales/adoption rate for the release.
ROI is a surrogate measure of value. When I have measured the actuals (what it actually took us to finish the project and the actual revenue at three, six, nine and twelve months out, we almost always did not meet the projected ROI. And, because we chose that project with great-looking ROI, we incurred a cost of delay for other projects. “If we don’t release this project because we are doing something else, what is the effect on our revenue/adoption/etc?” (See Diving for Hidden Treasures to read about the different costs of delay.)
People often say, “These two projects are equal in terms of project cost. If I don’t use ROI, how can I decide between these projects?”
I have never seen this to be true, and it’s quite difficult to predict which project will be shorter. Here are some options:
- Use Cost of Delay as a way to value the projects in the project portfolio. See Diving for Hidden Treasures for ways to see Cost of Delay. See Manage Your Project Portfolio for many other ranking ideas for the project portfolio.
- Determine the first releasable deliverable of value for each project. How long will that take? If you do one project, release something, does that provide you enough revenue so you can go to the other project and release something there?
- Make all the deliverables small, so, if necessary, you could flow work from both projects through one team. The team can finish a feature/deliverable and move to the next one. I recommend using a kanban board and swarming over each feature so you get maximum throughput. Once the team has finished “enough” features, decide which project to spend more time on.
Agile helps the entire project portfolio problem because we can all see progress on an agile project: demos, product backlog burnup chart, and retrospective results. We know a lot more about what we finish and where we are headed. We can stop working on one project because we don’t leave work in an unfinished state.Management Wants the Comfort of a Single Estimation Date
I supply a range of dates for my projects: possible, likely, pessimistic. I sometimes supply a confidence range. I have met many managers who do not want the reality of estimation. They want a single date: September 1, 2pm.
The problem is that an estimate is a guess. I can only know the exact duration or cost when I’m done with the project. I can get closer as we finish work, but I can’t know for sure months in advance. For a year-long project, I can guess as to which quarter/three month period. As we finish the project, I can spiral in on a date. By the last quarter, I can be within a couple of weeks of knowing.
Managers get paid the big bucks to manage the organization with assumptions, risks, and unknowns that we explain to them. When we work on projects, it’s our job to manage our risks and deliver value. The more value we deliver, the fewer unknowns our managers have.
Agile (and incremental approaches) help us manage those unknowns. Nothing is perfect, but they are better than other approaches.
I’ve worked with several managers who wanted one date. I gave them the pessimistic date. Sometimes, I provided the 90% confidence date. Even then, there were times we had more problems than we anticipated. Meeting that date became impossible.
A single-point estimate is something we like. Unfortunately, a single-point date is often wrong. Management wants it for any number of reasons.
If one of those reasons is assurance that the team can deliver, agile provides us numerous ways to get this result without a single-point estimate: set a target, see demos, see the product backlog burnup chart.
I have nothing against estimation when used properly. These are just three examples of improper estimate use. Estimates are guesses. In Part 3, I’ll talk when estimates might be useful.
(Sorry for the length of this post. I’ll stop writing because otherwise I’ll keep adding. Sigh.)
Dates: Thursday, June 30, 2016
Location: McKimmon Center, 11101 Gorman St., Raleigh, NC
Event URL: http://triagile.com
VersionOne is proud to be a gold sponsor of TriAgile 2016. This conference is a wonderful opportunity to bring people together from all disciplines to share their knowledge, experience, and passion about agile. More than 500 agile practitioners are expected to attend this year’s conference which includes over 30 sessions on agile related topics spanning leadership, value, culture, technical practices, scaling, and more.
This year’s opening keynote features Jurgen Appelo, an internationally acclaimed author and speaker, who is pioneering management to help creative organizations survive and thrive in the 21st century. The closing keynote is Andy Hunt, an award winning author, thought leader, and Agile Manifesto signer.
TriAgile 2016 attendees will walk away with practical and pragmatic strategies and tactics for furthering agile in their teams and organizations.
Connect with VersionOne
We’re looking forward to seeing you at TriAgile 2016!
A few weeks ago, I spoke at the Heart of Agile conference up in Philadelphia. The conference was a two-day event dedicated to educating attendees on Alistair Cockburn’s new methodology, The Heart of Agile.
The Heart of Agile is focused on getting back to the basics of Agile. In the last 15 years, Agile has been weighed down with frameworks and practices of many shapes and sizes. At the Heart of Agile are 4 key concepts: Collaborate, Deliver, Reflect and Improve. From this center, we can branch out to all of the principals, practices, skills, and tools.The two-day event offered:
Opening and closing keynotes by Alistair Cockburn focused on the “Heart of Agile”
Speakers – presentations and discussion tracks for Collaborate, Deliver, Reflect, and Improve:
Tutorials – Speakers provided presentations and facilitated conversations on hot topics and key trends on Agile principles and practices. This was an opportunity for experienced practitioners to demonstrate and share their knowledge in a specific topic, solution, or technique.
Collaborative Conversation – Joint problem-solving with other experienced participants in a topic. A facilitated peer-to-peer event, where everyone had something to contribute to the topic, though may not have been an expert at the topic. The coordinator proposed a topic and a facilitation structure, the attendees worked in small groups (typically 4-8 people), and mutually exchanged and collaborated their outputs.
Experience Reports – Experience reports contained first-hand information and reflection: “We saw this…,” “Our team did that…,” or “We learned the following from our experience…” Experience reports served as an exchange opportunity for practitioners to learn from others. Focus of these discussions was to share successes, failures, and lessons learned.
Open Space – Ongoing facilitated discussions of topics that were suggested by the attendees.Experience Report
I was asked to present a report on one of my recent experiences.
Instead of presenting the below embedded deck about the correct context for an Agile transformation, I drew everything on a flip chart. If you know your content, you don’t need a PowerPoint deck! I wanted to make the original presentation available for others who were not in the room (and those who were).Correct Context for an Agile Transformation
If there is one question I would ask, to know if you should view/download this presentation, it would be: Are you exactly like Spotify? If you are not Spotify or your company business goals do not align with Spotify, then this would be a good presentation to view or to talk with me about.
Get a free copy of the presentation from Derek Huether
If I ask people who facilitates the agile retrospective, most tell me that it’s their Scrum master. Some even look surprised, as if their could be anybody else who leads their retrospectives? Yes there can be. In some situation it’s even better if somebody else than the Scrum master facilitates the agile retrospective.
Let’s get one thing out of the way. I don’t care much about what specific frameworks or processes such as Scrum or SAFe say about who is “responsible”for the agile retrospective, or who’s “task” it is to do it. For me it is not about “who’s work it is to manage the meeting”. What matters are the results! How can you make your retrospective valuable: have a effective meeting and get good actions that help teams to improve.
Basically anyone can facilitate the agile retrospective. The main guidelines that I use are:
- If it is a mature team with experienced team members, then any team member (including the Scrum master) can facilitate the retrospective next to their team member role.
- If the team is new or just started with agile, and doesn’t have much experience with reflecting and facilitation, then I suggest to have an independent facilitator.
For a new team the retrospective should not be facilitated by a team member, and certainly not by the Scrum master. Why you might ask? Because this team is on a journey to discover how to work in an agile way, and that means changing the way people work together. This change impacts everybody on the team, and in the beginning mostly the Scrum master. Having to lead the retrospective, and reflect and learn at the same time is hard. My advice is for the team to focus on the learning and get someone else to facilitate the meeting.
Retrospectives Exercises Toolbox - Design your own valuable Retrospectives
An independent facilitator for the agile retrospective
So who can facilitate the agile retrospective for a new team, if it isn’t the Scrum master of the team? Whoever is does, that person must have the proper skills to do it. It can be a team member from another team, be it that team’s Scrum master or anybody else from that team who knows how to lead a good retrospective. Or it can be an agile coach, process responsible, quality manager, or even somebody from HR or a line manager. The position or role that the facilitator has is irrelevant, what matters is that the person can act as an independent facilitator and has the right skills.
In a comment on an earlier version of this post Kasia Ziemba mentioned the danger in having the retrospective facilitated by a line manager by stating “Until managers understand that their role is to support, not command and control, it might block the learning process in a team.” I second that, and adding to it, I’ve seen situations where the manager truly tried to support the team, but due to the history of the company team members didn’t trust managers enough to be fully open an honest when their where in a meeting. Past performance and perception can work against managers when they want to adopt an agile management style, it’s hard. On the other hand, I have seen managers with very good facilitation skills who helped teams tremendously on their agile journey. Team perception is crucial, if the team doesn’t feel safe with a facilitator then have somebody else facilitate the retrospective.
Becoming a servant leader of a self-organizing team isn’t easy for new Scrum masters. The focus in the retrospective for a new team (actually, for any team) is to reflect and learn. That works better if someone outside the team facilitates the agile retrospective for them. Someone who knows how to lead the meeting, and what it takes to adopt an agile way of working. Recognizes barriers and impediments and helps the team to find a solution.
Who facilitates your agile retrospective?
After the article I referenced in Moving to Agile Contracts was published, there was a little kerfuffle on Twitter. Some people realized I was talking about the value of estimates and #noestimates. Some folks thought I was advocating never estimating anything.
Let me clarify my position.
I like order-of-magnitude estimates. I don’t hire people without either a not-to-exceed or an order-of-magnitude estimate. I explained how to do that in Predicting the Unpredictable: Pragmatic Approaches to Estimating Project Cost or Schedule. That’s because I have to manage the risk of the money and the risk I won’t get what I want.
Notice there are two risks: money and value. When I need to manage both risks, I ask for order-of-magnitude estimation and frequent demos. When we did the remodel for the house we are living in now—almost a rebuild—we had an estimate from our builder. Our builder was great. He encouraged us to see the house every day to see their progress. The builder was transparent with problems. Was he truly agile? In order for him to create an estimate, we iterated on the designs for each room before he broke ground.
Construction, hardware development, mechanical products—all those “hard” products require iteration on the design before implementation. That’s because the cost of change is so high when you move to physical form. In my experience, the cost of not iterating before you go to physical form is prohibitive.
So, what is the value of estimation for software? I have said (In Predicting) that software is learning, innovation. We learn from every software project. That makes estimation tricky, if not impossible. Can you estimate? Of course. The problem I see is in the value of the estimate. That value changes for the domain and customer.
If you have a reluctant-to-agile customer, you might want to do more estimation as you work through the project. That was the point of the Moving to Agile Contracts article. You might not even convince a customer that agile is good for them. If you get the value out of working in an agile way, great. You still get the value, even if the customer doesn’t.
If you have a regulated domain or a complex project that you might want to cancel, you might need more estimation as you proceed. I still like using my deliverable-based roadmaps and a not-to-exceed project cost. I would ask, “How much change do we expect?” If the deliverables are going to change every day or week, I don’t see how you can estimate and believe it. You can do a not-to-exceed for a date or cost.
In software, most of the cost is in the run rate for the project.
The image here is an example one-quarter roadmap from Agile and Lean Program Management. In a program, people often need to see further into the future than a backlog or two. I often see organizations requiring six-quarter roadmaps. That’s fine. The roadmap is a wish list. Why? Because it’s not possible to provide a reasonable estimate of that much work that far out without doing some work.
Here’s the tricky part: how much work do you need to do for estimation? I don’t know.
In the Twitter conversation, Glen Alleman mentioned that Raytheon is doing a project using agile. I am pretty sure the agile Raytheon guy I know (socially) is on that project. Yes, they do 4-week iterations. They work feature-by-feature. I believe, although I am not positive, they started that project with a significant investigation period. To me, that project looks a lot more like staged delivery. On the other hand, does it matter??
Does that mean it’s not agile? Well, staged delivery does not require the same transparency and culture change that agile does. On the other hand, does it matter? Remember, I am not religious about what you do. I want your project to succeed.
So what about #noestimates? How does that figure into this conversation?
Here are times when you might not want to bother estimating:
- You have a fixed target. Management said, “We need this project done by that date.” In that case, get a ranked backlog and get to work. Why fight with people or waste time estimating when you have no idea what you can do? In Predicting, I say something like this, “Get a ranked backlog. Get to work. Get some data. Show progress. If you can’t deliver what they want when they want it, you now have data for a discussion.”
- You think things will change every day or every week. Management/your sponsor says, “Here’s the ranked backlog. We want to see what you can do so we know what we want to change.” Inviting change is why we use agile. Otherwise, we could used staged-delivery. Why estimate? I would use a not-to-exceed date or cost.
- You are on the project to save the company. Get a ranked backlog and get to work. Determine how often you can release to get revenue.
I have been on all these kinds of projects. I have gotten a ranked backlog and gotten to work. I have succeeded. Oh, in one case, the company management started the project to save the company too late to make a difference. I didn’t succeed then. We needed four weeks to make a difference and had two.
I like delivering small chunks often. Yes, I use deliverables in my work that are small, often an hour or less. I can stop when I get to the end of them and not worry about the next chunk. I am sure I do different work than you do.
That is why, as Glen says, the domain is critical. I think it’s also the customer. Maybe there are more things to consider.
In my next post, I will discuss when estimates are harmful.
Marcus Blankenship and I wrote a follow-up piece to our first article, mentioned in Discovery Projects Work for Agile Contracts. That article was about when your client wants the benefit of agile, but wants you to estimate everything in advance and commit to a fixed price/fixed scope (and possibly fixed date) project. Fixing all of that is nuts.
The next article is Use Demos to Build Trust.
That post prompted much Twitter discussion about the purpose of estimates and trust. I’ll write a whole post on that because it deserves a thoughtful answer.
Planning Poker relies on relative estimating, in which the item being estimated is compared to one or more previously estimated items. It is the ratio between items that is important. An item estimated as 10 units of work (generally, story points) is estimated to take twice as long to complete as an item estimated as five units of work.
An advantage to relative estimating is that it becomes easier to do as a team estimates more items.
Estimating a new item becomes a matter of looking at the previously estimated items and finding something requiring a similar amount of work. This is easier to do when the team has already estimated 100 items than when they’ve only estimated 10.
But, relative estimating like with Planning Poker suffers from a bootstrapping problem: How does a team select the initial estimates to which they’ll compare?
My recommendation is that when a team first starts playing Planning Poker, team members identify two values that will establish their baseline. They do this without playing Planning Poker. They do it just through discussion. After the baseline is established, team members can use Planning Poker to estimate additional items.
Ideally, the team is able to identify both a two-point story and a five-point story. There is evidence that humans estimate most reliably when sticking within one order of magnitude.
Identifying a two-point product backlog item and a five-point item does a good job of spanning this order of magnitude. Many other items can then be more reliably compared against the two and the five.
If finding a two and a five proves difficult, look instead for a two and an eight, or a three and an eight. Anything that spans the one to 10 range where we’re good estimators will work.Avoid Starting with a One-Point Story
I like to avoid starting with a one-point story. It doesn’t leave room for anything smaller without resorting to fractions, and those are harder to work with later.
Additionally, comparing all subsequent stories to a one-point story is difficult. Saying one product backlog item will take two or three times longer than another seems intuitively easier and more accurate than saying something will take 10 times longer.
I made this point in my 2005 “Agile Estimating and Planning” book (now also a video course). In 2013, it was confirmed by Magne Jørgensen of the Simula Research Lab. Jørgensen, a highly respected researcher, conducted experiments involving 62 developers. He found that “using a small user story as the reference tends to make the stories to be estimated too small due to an assimilation effect.”Why Use Two Values for a Baseline?
Establishing a baseline of two values allows for even the first stories being estimated to be compared to two other items. This is known as triangulating and helps achieve more consistent estimates.
If a team has established a baseline with two- and five-point stories, team members can validate a three-point estimate by thinking whether it will take longer than the two and less time than the five.
Citing again the research of Jørgensen, there is evidence that the direction of comparison matters. Comparing the item being estimated to one story that will take less time to develop and another that will take longer is likely to improve the estimate.Don’t Establish a New Baseline Every Project
Some teams establish a new baseline at the start of each project. Because this results in losing all historical velocity data, I don’t recommend doing this as long as two things are true:
- The team members developing the new system will be largely those involved in the prior system. The team doesn’t need to stay entirely the same, but as long as about half the team remains the same, you’re better off using the same baseline.
- The team will be building a somewhat similar system. If a team is switching from developing a website to embedded firmware, for example, they should establish a new baseline. But if the systems being built are somewhat similar in either the domain or technologies used, don’t establish a new baseline.
Whenever possible, retain the value of historical data by keeping a team’s baseline consistent from sprint to sprint.How Do Establish Your Baseline?
How do you estimate your baseline and initial estimates for a new team? Please share your thoughts in the comments below.