Warning: Table './devblogsdb/cache_page' is marked as crashed and last (automatic?) repair failed query: SELECT data, created, headers, expire, serialized FROM cache_page WHERE cid = 'http://www.softdevblogs.com/?q=aggregator/sources/19' in /home/content/O/c/n/Ocnarfparking9/html/softdevblogs/includes/database.mysql.inc on line 135

Warning: Cannot modify header information - headers already sent by (output started at /home/content/O/c/n/Ocnarfparking9/html/softdevblogs/includes/database.mysql.inc:135) in /home/content/O/c/n/Ocnarfparking9/html/softdevblogs/includes/bootstrap.inc on line 729

Warning: Cannot modify header information - headers already sent by (output started at /home/content/O/c/n/Ocnarfparking9/html/softdevblogs/includes/database.mysql.inc:135) in /home/content/O/c/n/Ocnarfparking9/html/softdevblogs/includes/bootstrap.inc on line 730

Warning: Cannot modify header information - headers already sent by (output started at /home/content/O/c/n/Ocnarfparking9/html/softdevblogs/includes/database.mysql.inc:135) in /home/content/O/c/n/Ocnarfparking9/html/softdevblogs/includes/bootstrap.inc on line 731

Warning: Cannot modify header information - headers already sent by (output started at /home/content/O/c/n/Ocnarfparking9/html/softdevblogs/includes/database.mysql.inc:135) in /home/content/O/c/n/Ocnarfparking9/html/softdevblogs/includes/bootstrap.inc on line 732
Software Development Blogs: Programming, Software Testing, Agile, Project Management
Skip to content

Software Development Blogs: Programming, Software Testing, Agile Project Management

Methods & Tools

Subscribe to Methods & Tools
if you are not afraid to read more than one page to be a smarter software developer, software tester or project manager!

Managing Product Development - Johanna Rothman
warning: Cannot modify header information - headers already sent by (output started at /home/content/O/c/n/Ocnarfparking9/html/softdevblogs/includes/database.mysql.inc:135) in /home/content/O/c/n/Ocnarfparking9/html/softdevblogs/includes/common.inc on line 153.
Syndicate content
Expert in Managing Product Development
Updated: 2 hours 37 min ago

Product Owners and Learning, Part 3

Thu, 06/23/2016 - 15:32

Part 1 was about how the PO needs to see the big picture and develop the ranked backlog. Part 2 was about the learning that arises from small stories. This part is about ranking.

If you specify deliverables in your big picture and small picture roadmaps, you have already done a gross form of ranking. You have already made the big decisions: which feature/parts of features do you want when? You made those decisions based on value to someone.

I see many POs try to use estimation as their only input into ranking¬†stories. How long will something take to complete? If you have a team who can estimate well, that might be helpful. It’s also helpful to see some quick wins¬†if you can. See my most recent series of posts on Estimation for more discussion on ranking by estimation.

Estimation talks about cost. What about value? In agile, we want to work (and deliver) the most valuable work first.

Once you start to think about value, you might even think about value to all your different somebodies. (Jerry Weinberg said, “Quality is value to someone.”) ¬†Now, you can start considering defects, technical debt, and features.

The PO must rank all three possibilities for a team: features, defects, and technical debt. If you are a PO who has feature-itis, you don’t serve the team, the customer, or the product. Difficult as it is, you have to think about all three to be an effective PO.

The features move the product forward on its roadmap. The defects prevent customers from being happy and prevent movement forward on the roadmap. Technical debt prevents easy releasing and might affect the ease of the team to deliver. Your customers might not see technical debt. They will feel the effects of technical debt in the form of longer release times.

Long ago, I suggested that a specific client consider¬†three backlogs to store the work and then use pair-wise comparison with each item at the top of each queue. (They stored their product backlog, defects, and technical debt in an electronic tool. It was difficult to see all of the possible work.)¬†That way, they could see the work they needed to do (and not forget), and they could look at the value of doing each chunk of work. I’m not suggesting keeping three backlogs is a good idea in all cases.¬†They needed to see—to make visible—all the possible work. Then, they could assess the value of each chunk of work.

You have many ways to see value. You might look at what causes delays in your organization:

  • Technical debt in the form of test automation debt. (Insufficient test automation makes frictionless releasing impossible. Insufficient unit test automation makes experiments and spikes impossible or quite long.)
  • Experts who are here, there, and everywhere, providing expertise to all teams. You often have to wait for those experts to arrive to your team.
  • Who is waiting for this? Do you have a Very Important Customer waiting for a fix or a feature?

You might see value in features for immediate revenue. I have worked in organizations where, if we released some specific feature, we could gain revenue right away. You might look at waste (one way to consider defects and technical debt).

Especially in programs, I see the need for the PO to say, “I need these three stories from this feature set and two stories from that other feature set.” The more the PO can decompose feature sets into small stories, the more flexibility they have for ranking each story on its own.

Here are questions to ask:

  • What is most valuable for our customers, for us to do now?
  • What is most valuable for our team, for us to do now?
  • What is most valuable for the organization, for us to do now?
  • What is most valuable for my learning, as a PO, to decide what to do next?

You might need to rearrange those questions for your context. The more your PO works by value, the more progress the team will make.

The next post will be about when the PO realizes he/she needs to change stories.

If you want to learn how to deliver what your customers want using agile and lean, join me in the next Product Owner workshop.

Categories: Project Management

Product Owners and Learning, Part 1

Wed, 06/22/2016 - 17:05

When I work with clients, they often have a “problem” with product ownership. The product owners want tons of features, don’t want to address technical debt, and can’t quite believe how long features will take. ¬†Oh, and the POs want to change things as soon as they see them.

I don’t see this as problems.To me, this is all about learning. The team learns about a feature as they develop it. The PO learns about the feature once the PO sees it. The team and the PO can learn about the implications of this feature as they proceed. To me, this is a significant value of what agile brings to the organization. (I’ll talk about technical debt a little later.)

AgileRoadmap.copyright-1080x794One of the problems I see is that the PO sees the big picture. Often, the Very Big Picture. The roadmap here is a 6-quarter roadmap. I see roadmaps this big more often in programs, but if you have frequent customer releases, you might have it for a project, also.

I like knowing where the product is headed. I like knowing when we think we might want releases. (Unless you can do continuous delivery. Most of my clients are not there. They might not ever get there, either. Different post.)

Here’s the problem with the big picture. No team can deliver according to the big picture. It’s too big. Teams need the roadmap (which I liken to a wish list) and they need a ranked backlog of small stories they can work on now.

Example.AgileRoadmapOneQuarter In Agile and Lean Program Management, I have this picture of what an example roadmap might look like.

This particular roadmap works in iteration-based agile. It works in flow-based agile, too. I don’t care what a team uses to deliver value. I care that a team delivers value often. This image uses the idea that a team will release internally at least once a month. I like more often¬†if you can manage it.

Releasing often (internally or externally) is a function of small stories and the ability to move finished work through your release system. For now, let’s imagine you have a frictionless release system. (Let me know if you want a blog post about how to create a frictionless release system. I keep thinking people know what they need to do, but maybe it’s as clear as mud to ¬†you.)

The smaller the story, the easier it is for the team to deliver. Smaller stories also make it easier for the PO to adapt. Small stories allow discovery along with delivery (yes, that’s a link to Ellen Gottesdiener’s book). And, many POs have trouble writing small stories.

That’s because the PO is thinking in terms of feature sets, not features. I gave an example for secure login in How to Use Continuous Planning. It’s not wrong to think in feature sets. Feature sets help us create the big picture roadmap. And, the feature set is insufficient for the frequent planning and delivery we want in agile.

I see these problems in creating feature sets:

  • Recognizing the different stories in the feature set (making the stories small enough)
  • Ranking the stories to know which one to do first, second, third, etc.
  • What to do when the PO realizes the story or ranking needs to change.

I’ll address these issues in the next posts.

If you want to learn how to deliver what your customers want using agile and lean, join me in the next Product Owner workshop.

Categories: Project Management

Product Owners and Learning, Part 2

Wed, 06/22/2016 - 17:03

In Part 1, I talked about the way POs think about the big picture and the ranked backlog. The way to get from the big picture to the ranked backlog is via deliverables in the form of small (user) stories. See the wikipedia page about user stories. Notice that they are a promise for a conversation.

I talked about feature sets in the first post, so let me explain that here. A feature set is several related stories. (You might think of a feature set as a theme or an epic.) Since I like stories the team can complete in one day or less, I like those stories to be small, say one day or less. I have found that the smaller the story, the more feedback the team gets earlier from the product owner. The more often the PO sees the feature set evolving, the better the PO can refine the future stories. The more often the feedback, the easier it is for everyone to change:

  • The team can change how they implement, or what the feature looks like.
  • The PO can change the rest of the backlog or the rank order of the features.

I realize that if you commit to an entire feature set or a good chunk for an iteration, you might not want to change what you do in this iteration. If you have an evolving feature set, where the PO needs to see some part before the rest, I recommend you use flow-based agile (kanban). A kanban with WIP limits will allow you to change more often. (Let me know if that part was unclear.)

Now, not everyone shares my love of one-day stories. I have a client whose team regularly takes stories of size 20 or something like that. The key is that the entire team swarms on the story and they finish the story in two days, maybe three. When I asked him for more information, he explained this it in this way.

“Yes, we have feature sets. And, our PO just can’t see partial finishing. Well, he can see it, but he can’t use it. Since he can’t use it, he doesn’t want to see anything until it’s all done.”

I asked him if he ever had problems where they had to redo the entire feature. He smiled and said,

“Yes. Just last week we had this problem. Since I’m the coach, I explained to the PO that the team had effectively lost those three days when they did the “entire” feature instead of just a couple of stories. The PO looked at me and said, “Well, I didn’t lose that time. I got to learn along with the team. My learning was about flow and what I really wanted. It wasn’t a waste of time for me.”

“I learned then about the different rates of learning. The team and the PO might learn differently. Wow, that was a big thing for me. I decided to ask the PO if he wanted me to help him learn faster. He said yes, and we’ve been doing that. I’m not sure I’ll ever get him to define more feature sets or smaller stories, but that’s not my goal. My goal is to help him learn faster.”

Remember that PO is learning along with the developers and testers. This is why having conversations about stories works. As the PO explains the story, the team learns. In my experience, the PO also learns. It’s also why paper prototypes work well. Instead of someone (PO or BA or anyone) developing the flow, when the team develops the flow in paper with the PO/BA, everyone learns together.

Small stories and conversations help the entire team learn together.

Small features are about learning faster. If you, too, have the problem where the team is learning at a different rate than the PO, ask yourself these questions:

  • What kind of acceptance criteria do we have for our stories?
  • Do those acceptance criteria make sense for the big feature (feature set) in addition to the story?
  • If we have a large story, what can we do to show progress and get feedback earlier?
  • How are we specifying stories? Are we using specific users and having conversations about the story?

I’ve written about how to make small stories in these posts:

The smaller the story, the more likely everyone will learn from the team finishing it.

I’ll address ranking in the next post.

If you want to learn how to deliver what your customers want using agile and lean, join me in the next Product Owner workshop.

Categories: Project Management

The Case for and Against Estimates, Part 5

Mon, 06/13/2016 - 17:01

If you’ve been following the conversation, I discussed in Part 1 how I like agile roadmaps and gross estimation and/or targets for projects and programs. In Part 2, I discussed when estimates might not be useful. In Part 3, I discussed how estimates can be useful. In Part 4, I discussed #noestimates. ¬†Let me summarize my thinking and what I do here.

This series started because Marcus Blankenship and I wrote two articles: Stay Agile With Discovery, which is how to help your client see benefit and value early from a small project first, before you have to estimate the whole darn thing; and Use Demos to Build Trust, how to help your client see how they might benefit from agile in their projects, even if they want an upfront estimate of “all” the work.

Let me clarify my position: I am talking about agile projects. I am not talking about waterfall, iterative, or even incremental approaches. I have used all those approaches, and my position in these posts are about agile projects and programs.

In addition, I have a ton of experience in commercial, for-profit organizations. I have that experience in IT, Engineering, R&D. I have very little experience in non-profit or government work. Yes, I have some, but those clients are not the bulk of my consulting business. As with everything I write (or anyone else does), you need to take your context into account. I see wide project and program variation in each client, never mind among clients.

That said, in agile, we want to work according to the agile principles (look past the manifesto at the principles). How can we welcome change? How can we show value? How can we work with our customer?

Many people compare software to construction. I don’t buy it. Here’s a little story.

In my neighborhood, the gas utility is replacing gas mains.The project is supposed to about three months or so. We received a letter in May, saying which streets they expected to work on and when. The reality is quite different.

They work on one street, and have to go around the corner to another street? Why? Because the mains and lines (water, gas, electric) are not where the drawings said they would be. Instead of a nice grid, they go off at 45-degree angles, cross the street, come back, etc. Nothing is as the plans suggested it should be. During the day, I have no idea what streets will be open for me to drive on. The nice folks put everything back to some semblance of normal each night. They patch the roads they work on during each day.

And yet, they are on budget. Why? Because they accounted for the unknowns in the estimate. They padded the estimate enough so that the contractor would make money. They accounted for almost everything in their estimate. How could they do this? The company doing the work has seen these circumstances before. They knew the 50-year-old plans were wrong. They didn’t know how, but they’ve seen it all before, so they can manage their risks.

The learning potential in their work is small. They are not discovering new risks every day. Yes, they are working around local technical debt. They knew what to expect and they are managing their risks.

Here’s another story of a software project. This is also a three-to-four month project (order of magnitude estimate). The product hasn’t been touched in several years, much to the software team’s dismay. They have wanted to attack this project for a couple of years and they finally got the go-ahead.

Much has changed since they last touched this product. The build system, the automated testing system, the compiler—all of those tools have changed. The people doing the work have changed. The other products that interact with this product have changed.

The team is now working in an agile way. They deliver demonstrable product almost every day. They show the working product every week to senior management.

They are learning much more than they thought they would. When they created the estimate, they had assumptions about underlying services from other products. Well, some of those assumptions were not quite valid. They asked what was driving the project? They were told the date to release. Well, that changed to feature set. (See Estimating the Unknown, Part 1 for why that is a problem.)

They feel as if the project is a moving target. In some ways, it is. The changes arose partly because of what the team was able to demonstrate. The PO decided that because they could do those features over there and release those features earlier, they could reduce their Cost of Delay. Because they show value early and often, they are managing the moving target changes in an agile way. I think they will be able to settle down and work towards a target date once they get a few more features done and released.

Why is this team in such project turmoil? Here are some reasons:

  • Their assumptions about the product and its interactions were not correct. They had spent three days estimating “everything.” They knew enough to start. And, they uncovered more information as they started. I asked one of the team members if they could have estimated longer and learned more. He said, “Of course. It wasn’t worth more time to estimate. It was worth our time to deliver something useful and get some feedback. Sure, that feedback changed the order of the features, so we discovered some interesting things. But, getting the feedback was more useful than more estimation.” His words, not mine.
  • The tooling had changed, and the product had not changed to keep up with the tooling. The team had to reorganize how they built and tested just to get a working build before they built any features.
  • The technical debt accumulated in this product and across the products for the organization. Because the management had chosen projects by estimated duration in the past, they had not used CoD to understand the value of this project until now.

The team is taking one problem at a time, working that problem to resolution and going on to the next. They work in very small chunks. Will they make their estimate of 3-4 months? They are almost 3 months in. I don’t think so, and that’s okay. It’s okay because they are doing more work than they or their management envisioned when the project started. In this case, the feature set grew. It partly grew because the team discovered more work. It partly grew because the PO realized there was more value in other features not included in the original estimate.

In agile, the PO can take advantage of learning about features of more value. This PO works with the team every day. (The team works in kanban, demos in iterations.)

The more often we deliver value, the more often we can reflect on what the next chunk of value should be. You don’t have to work in kanban. This team likes to do so.

The kinds of learning this team gains for the software project is different that what the gas main people are learning in my neighborhood. Yes, the tools have changed since the gas mains were first installed. The scope of those changes are much less than even the tools changes for the software project.

The gas main project does “finish” something small every day, in the sense that the roads are safe for us to drive on when they go home at night. However, the patches are just that—patches for the road, not real paving. The software team finishes demonstrable value every day. If they had to stop the project at any time, they could. The software team is finishing. (To be fair to the gas people, it probably doesn’t make monetary sense to pave a little every day to done. And, we can get to done, totally done, in software.)

The software team didn’t pad the estimate. They said, “It’s possible to be done in 3 months. It’s more likely to be done in 4 months. At the outside, we think it will take 5 months.” And, here’s what’s interesting. If they had completed just what was in their original estimate, they might well be done by now. And, because it’s software, and because they deliver something almost every day, everyone—the PO, management, the team—see where there is more value and less value.

The software team’s roadmap has changed. The product vision hasn’t changed. Their release criteria have changed a little, but not a lot. They have changed what features they finish and the order in which they finish them. That’s because people see the product every day.

Because the software team, the PO and the management are learning every day, they can make the software product more valuable every day. The gas main people don’t make the project more valuable every day.

Is estimation right for you? Some estimation is almost always a good decision. If nothing else, the act of saying, “What will it take us to do this thing?” helps you see the risks and if/how you want to decompose that thing into smaller chunks.

Should you use Cost of Delay in making decisions about what feature to do first and what project to do first? I like it because it’s a measure of value, not cost. When I started to think about value, I made different decisions. Did I still want a gross estimate? Sure. I managed projects and ran departments where we delivered by feature. I had a ton of flexibility about what to do next.

Are #noestimates right for you? It depends on what your organization needs. I don’t need estimates in my daily work. If you work small and deliver value every day and have transparency for what you’re doing, maybe you don’t need them either.

Estimates are difficult. I find estimation useful, the estimates not so much. I find that looking at the cost and risks are one way to look at a project. Looking at value is another way.

I like asking if what my management wants is commitment or resilience. See When You Need to Commit. Many organizations want to use agile for resilience, and then they ask for long commitments. It’s worthwhile asking questions to see what your organization wants.

Here are my books that deal with managing projects, estimation, Cost of Delay and program management:

For me, estimates are not inherently good or bad. They are more or less useful. For agile projects, I don’t see the point of doing a lot of estimation. Why? Because we can change the backlog and finish different work. Do I like doing some estimation to understand the risks? Yes.

I don’t use cost as a way to evaluate projects in the project portfolio. I¬†prefer to look at some form of value rather than only use an estimate. For agile projects, this works, because we can see demonstrable product soon. We can change the project portfolio once we have seen delivered value.

Remember. my context is not yours. These ideas have worked for me on at least three projects. They might not work for you. On the other hand, maybe there is something you can use from here in  your next agile project or program.

Please do ask more questions in the comments. I might not do a post in a while. I have other writing to finish and these posts are way too long!

Categories: Project Management

One Week Remaining for Super-Early-Bird Registration for Product Owner and Writing Workshops

Fri, 06/10/2016 - 17:55

I have two online workshops starting in late August:

If you have been reading the estimations posts and are wondering, “How do I help my project deliver something every day or more often,” you should register for the workshop. We’ll discuss what your role is, how to plan for the future and the present, how to decide what features to do when, how to know when a feature is done, and tips and traps. See¬†Practical Product Owner Workshop: Deliver What Your Customers Need¬†for more details.

If you like the way I write (regardless of whether you agree with me), and you need to write more for your job or to help your business, take my¬†Non-Fiction Writing Workshop: Write Non-Fiction to Enhance Your Business and Reputation. That workshop is about building a writing habit, learning the separate parts of pre-writing, writing, editing, and publishing. We’ll address your specific writing challenges, concerns, and fears. I’m the only one who will read your work, so no worries about other people seeing your writing.

Super-early-bird registration for both workshops ends June 17, 2016. I hope you decide to join us.

Categories: Project Management

The Case for and Against Estimates, Part 4

Thu, 06/09/2016 - 21:34

When we think about the discussion about estimates and #noestimates, I have one big question:

Where do you want to spend your time?

In projects, we need to decide where to spend our time. In agile and lean projects, we limit the work in progress. We prefer to spend our time delivering, not estimating. That’s because we want to be able to change what we do, as often as we can. That is not appropriate for all projects. (See When is Agile Wrong for You?)

In some projects, as in the domain that Glen Alleman has commented on in the first post in this series, it might well be worth spending enough time to generate reasonable estimates and to have an idea about how much the estimate might be off. 

In some projects, as in the gather-a-bunch-of-people-across-the-universe that David Gordon discusses in Part 2 of this series, you might need the exercise more of “who will deliver what” first, and then ask “when.”¬†

For both of those kinds of projects (I might call them programs), the cost of people going open-loop is too high. Of course, I would do an everyone-in-the-room planning session for the first month to iron out our deliverables. (When people tell me the cost of that is too high, I remind them about the cost of not delivering.) It’s possible¬†if people understand how to use agile and lean to deliver at least as often as once a month, we don’t need more planning sessions. (If you want to run a program in an agile and lean way, see my program management book.)

In my experience, many people work on one- or two-team projects. The organization has decided on those projects. If you use agile and lean,  you might not need to estimate, if you deliver something every day. The delivery builds trust and provides sufficient feedback and the ability to change.

Here’s the way I like to think about #noestimates:

Noestimates is not about not estimating. It’s about delivering value often enough so you don’t have to estimate. You can spend time on different activities, all leading to delivering product.

I don’t buy what some #noestimates people say, that estimation is a sign of dysfunction. I have found the estimation process useful, as I explained in part 3 of this series.

In both Glen’s and Dave’s examples, it’s quite difficult to deliver value often, especially at the beginning of a program. Sure, you might decide to limit work in progress, or work in one- or two-week iterations. But the value you can deliver? Wow, the projects are so large and dispersed, it’s quite difficult to see value that often. You might see pieces of value. One vendor produces a proof of concept. Maybe another integrates two small chunks. That’s probably not enough value for people to see the product evolve.

On the other hand, when I can use an agile and lean approach for programs, I have been successful in delivering working product across the program every day. If you have SaaS, you can do this. I have done this with the software part of the program for a software/hardware product. That was valuable for everyone on the program.

When I think in #noestimate terms, I think of showing value for the entire product.

Here’s an example from my work. I write in small chunks. Okay, these blog posts have been massive. Not what I normally do on a daily basis. Because I write in small chunks, I can make progress on several books in the same week. That’s because I only have to finish a few paragraphs and I can be done with that part.

When I develop new workshops, I often start with the simulation(s). Once I know the activities, it’s even easier to design the debriefs and the material. I might take several days to develop a simulation. I call them drafts. I can do a draft in about an hour. The draft has value because I can ask people to review it. It’s a small deliverable.

In general, I timebox my work to finish something valuable in an hour. That’s because I make my deliverable small enough to show value in an hour. That’s the same idea as having a size “one” story. For you, a 1 might be a morning, but it’s probably not an entire day.

Back when I wrote code for a living, I was not good enough to deliver in ¬†hour-long chunks. Maybe if I’d used TDD, I could have. I found estimation helpful. That’s why I worked in inch-pebbles. I could still show value, and it might not be several times a day. It was always at least every other day.

When I was a tester, I was good enough to write very small code chunks to test the product. That’s when I realized I’d been working in too-large chunks as a developer. When I was a manager, I tried to timebox all meetings to 50 or 55 minutes. I didn’t always succeed, but I was successful more often than not. Some meetings, such as one-on-ones, I timeboxed to 20 minutes.

In my work, I want to show value as early and as often as possible. ¬†When I work with teams and managers, that’s part of my work with them. ¬†Not because delivering something in an hour is the goal. It’s because the faster you deliver something, the more value you show. The faster you can get feedback and know if you are on the right track.

I have found it helpful to create an¬†order of magnitude estimate for a project, so we all understand the general size/cost/duration of the project. Then, I start to deliver. Or, if I’m leading the team in some way, the team delivers.

The smaller the deliverable, the more often  you can get feedback and show value. I have seen these benefits from working this way:

  • The project ended earlier than we expected. That’s because we delivered “enough” to satisfy the PO/customer. (I’ve seen this many times, not just a couple of times.) If we had spent more time generating a detailed estimate, we would not have delivered as quickly.
  • We learned enough about the deliverables that we were able to do more discovery (as Ellen Gottesdiener says) as we delivered. We made the whole requirements process continuous and just in time. We did not require hour-long pre-sprint planning meetings. (Okay, that’s only happened twice. I have hope for more experiences like this.)
  • We were able to fix things before they got too large. We’d started in one direction on a feature set, realized we were headed in the wrong direction and replanned what to do and how to do it.

To me, the idea of #noestimates is tied up in small chunks of value.

#Noestimates is not for everyone. Just as detailed estimation is not for everyone. Think about what is right for your context: your team, your project, and yes, your management.

The posts to now:

  • Part 1 talked about targets and order of magnitude estimates.
  • Part 2 discussed when estimates are not that helpful. I did not include bad management in this post. Managers who treat estimates as commitments are not helping anyone.
  • Part 3 is about when estimates are helpful.
  • Part 4, this post, is about #noestimates.

I’ll do a summary post, including a pointer to the original article in part 5.

Categories: Project Management

The Case for and Against Estimates, Part 3

Thu, 06/09/2016 - 21:14

In Part 1, I discussed order-of-magnitude estimates and targets. In part 2, I said how estimates can be misused. In this part, I’ll discuss when estimation is useful. Here are several possibilities:

  • How big is this problem that we are trying to solve?
  • Where are the risks in this problem?
  • Is there something we can do to manage the risk and explain more about what we need to do?
Estimates can be useful when they help people understand the magnitude of the problem.

One of my previous Practical Product Owner students said, “We use story size to know when to swarm or mob on a story.” People tackle stories up to 5. (They use Fibonacci¬†series for story size.) They might pair or swarm on stories starting at size 8. Even if they have a 21 (or larger) size story, they swarm on it and finish it in a couple of days, as opposed to splitting the story.

They use estimates to understand the size and complexity of the feature. (I would call their features “feature-sets,” but they like to call that one big thing a feature.)

You might not like that approach. I think it’s a¬†fine way of not fighting with the PO to split stories. It’s also helpful to work together to solve a problem. Working together spreads knowledge throughout the team, as a team.

My experience with estimation is that it’s easy for me to not understand the magnitude of the work. We manage this problem in agile/lean by estimating together, or working together, or with timeboxing in some way.

The first time we solve a particular problem, it takes longer. The first time I worked on a control system (embedded software), I had to learn how things worked together. Where did the software interact with the hardware? What were the general risks with this kind of a product? The first time I self-published a book, everything took longer. What were the steps I needed to finish, in what order?

I worked on many control systems as a developer. Once I understood the general risks, my estimates were better. They were not sufficiently accurate until I applied the rules of deliverable-based planning. What deliverables did I need to deliver? (I delivered something at least once a week, even if it was data from what I now know is a spike.) What inch-pebbles did I need to create that deliverable?

The more I broke the work down into deliverables, the better the estimate was. The smaller the chunks, the better my estimate was. The more I broke the problem down, the more I understood what I had to do and what the risks were.

One of the things I like about agile and lean is the insistence on small chunks of value. The smaller my chunk is, the more accurate my estimate is.

Estimates can help people understand risks.

You’ll notice I talked a lot about risks in the above section. There are general project risks, such as what is driving the project? (See Manage It! or Predicting the Unpredictable, or a series I wrote a few years ago, Estimating the Unknown.) We optimize different work when we know what is driving the project. That’s the project view.

We have possible risks in many deliverables. We have the general risks: people get sick, they need to talk the duck, they multitask. But, each deliverable has its own risk.

I’ve said before software is learning, innovation. You may have done something like this project before, so you have domain expertise. But, you have probably not done this new thing here.

When I estimate, I start thinking about what I need to do, how to solve this problem. Then, I start thinking about the problems I might encounter in solving those problems.

I can’t get to the problems unless I have inch-pebbles. I am a big-picture person. I see the whole problem, possibly even the whole solution, and I skip some of the steps in my head. I estimate top-down as a start. Unless I create my inch-pebbles, I am likely to gloss over some of the risks because I start top-down.

You might not be like me. You might estimate bottom-up. You might see all the details. You might not miss any steps in solving the problem as you think about it. (I wonder about people like you: do you see the big picture at the beginning, or does it evolve for you?)

I have met some people who estimate inside out. They tell me they see part of the big picture and part of the small steps. They iterate on both parts until they see and can estimate the whole thing.

I have taught a number of estimation workshops. Most of my participants are top-down people. They see the result they want and then envision the steps to get there. I have met some small number who start bottom up. I have met two people who are inside-out. I don’t know if that’s a normal distribution, or just the people who participate in my workshops.

Estimates can help people understand possible first steps.

When people think about the first thing that can provide value, and they think about how to make that first thing small (either inch-pebbles or agile stories), they can more easily see what the first deliverable could be. They can discuss the deliverable progression (in agile with a product owner and in a more traditional life cycle with a project manager or a product manager).

I have found the discussion of deliverable progression very helpful. Many years ago, I was the lead developer for a gauge inspection system (machine vision on an assembly line). I asked the customer what he wanted to see first. “Can you see the gauge enough to give us some kind of an answer as to whether it’s a good gauge?” was his answer.

Notice he said “enough,” not “a perfect inspection.” We did a proof of concept in a couple of days. In the lab, with the right lighting, we had an algorithm that worked well enough. You might think of this as a discovery project. Based on that deliverable, we got the contract for the rest of the project. If I remember correctly, it took us close to 6 months to deliver a final system.

For that project, I acted as a cross between a project manager and what we now call a product owner. We had release criteria for the project, so I knew where we were headed. I worked with the customer to define deliverables every two weeks, after showing a demo of what we had finished every two weeks. (This was staged delivery, not agile. We worked in week-long timeboxes with demos to the customer every two weeks.)

This is in the days before we had project scheduling software. I drew PERT diagrams for the customer, showing date ranges and expected deliverables.

A few years ago, I coached a project manager. She was the Queen of the Gantt. She could make the Gantt chart do anything. I was in awe of her.

However, her projects were always late—by many months. She would work with a team. They would think it was a six-month project. She would put tasks into the Gantt that were two-, three-, and four weeks long. That’s when I understood the problem of the estimation unit. “If you measure in weeks, you’ll be off by weeks.” Her people were top-down thinkers, as I am. They glossed over some of the steps they needed to make the product work.

I explained how to do deliverable-based planning with yellow stickies. The people could generate their tasks and see their intersections and what they had to deliver. She and the team realized they didn’t have a 6-month project. They had a project of at least a year, and that was if the requirements didn’t change.

When they started thinking about estimating the bits, as opposed to a gross estimate and applying a fudge factor, they realized they had to spend much more time on estimating and that their estimate would be useful. For them, the estimation time was the exploration time. (Yes, I had suggested they do spikes instead. They didn’t like that idea. Every project has its own culture.)

How do your estimates help you?

Maybe your estimates help you in some specific way that I haven’t mentioned. If so, great.

powerlawdistributionThe problem I have with using estimates¬†is that they are quite difficult to get right. See Pawel Brodzinski’s post,¬†Estimation? It‚Äôs Complicated‚Ķ¬†In

In Predicting the Unpredictable, I have a chart of how my estimates work. See the Power Law Distribution: Example for Estimation. (In that book, I also have plenty of advice about how to get reasonable estimates and what to do if your estimate is wrong.)

In my measurements with my clients and over time, I no longer buy the cone of estimation. I can’t make it work for agile or incremental approaches. In my experience, my estimates are either off by hundreds of %, or I am very close. We discover how much I am off when the customer sees the first deliverable. (In Bossavit’s Leprechauns of Software Engineering, (or on leanpub)¬†he says the cone of estimation was never correct.)

For me, deliverables are key to understanding the estimate. If, by estimating, you learn about more deliverables, maybe your estimation time is useful.

Since I use agile and lean, estimating time for me is not necessarily useful. It’s much more important to get a ranked backlog, learn if I have constraints on the project, and deliver. When I deliver, we discover: changes in requirements, that we have done enough, something. My delivery incorporates feedback. The more feedback I get, the more I can help my customer understand what is actually required and what is not required. (I often work on projects where requirements change. Maybe you don’t.)

I realized that I need a part 4, that specifically talks about noestimates and how you decide if you want to use noestimates. Enough for this post.

Categories: Project Management

The Case for and Against Estimates, Part 2

Tue, 06/07/2016 - 22:33

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.)

Categories: Project Management

The Case for and Against Estimates, Part 1

Mon, 06/06/2016 - 15:56

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.

Example.AgileRoadmapOneQuarterIf 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.

StagedDeliveryIn 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.

Categories: Project Management

Moving to Agile Contracts

Mon, 06/06/2016 - 15:04

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.

Categories: Project Management

Tell Your Problems to the Duck

Fri, 06/03/2016 - 17:51

Linda Rising gave a great talk last night at Agile New England. Her topic was problem-solving and decision-making.

One of her points was to discuss the problem, out loud. When you talk, you engage a different part of your brain than when you think. For us extroverts, who speak in order to think, this might not be a surprise. (I often say that my practice for my talks is almost irrelevant. I know what I’m going to say. And, I feed off the energy in the room. Things come out of my mouth that surprise me.)

If you’re an introvert, you might be surprised. In fact, since you think so well inside your head, you might scoff at this. Yes, speech and problem-solving both work in your frontal lobe. And, your¬†brain processes thought and speech differently.

Rubber ducks

Long ago, I was stuck on a problem. I went to my boss and he told me to talk to the duck.

“The duck?” I asked. I thought he’d lost his mind.

“Yes, this duck.” He pulled out a yellow rubber duck off his shelf. “Talk to the duck.”

I looked at him.

“What are you waiting for? Do you want to take the duck back to your office? That’s okay.” ¬†He turned back to his computer.

I sat there for a few seconds.

“You don’t pray to the duck. You talk to the duck. Now, either start talking to the duck or take the duck. But, talk to the duck.”

I am happy to say that talking to the duck worked for me. I have used that technique often.

Sometimes, I talk to a person. All they have to do is say, “Oh,” or “Uh huh,” or some other acknowledgement that they still live and breathe. If I use one person too often, I suspect they prefer if I talked to a duck.

If you are stuck on a problem, don’t do the same thing you did for the past 20 minutes. (That’s my maximum time to be stuck. Yours might be longer.) Talk to the duck.

If you want the wikipedia reference, here it is: Rubber Duck Debugging. Talk on.

Categories: Project Management

When is Agile Wrong for You?

Tue, 05/24/2016 - 15:04

People often ask me, “When is agile¬† right or not right for a project?” I’ve said before that if the team wants to go agile, that’s great. If the team doesn’t, don’t use agile.

That answer is insufficient. In addition to the team, we need management to not create a bad environment for agile. You might not have a great environment to start. But a bad environment? That’s a horror show.

I had a coaching conversation recently. My client¬†has a typical problem. He sees multiple ways to accomplish the work. He’s taking ideas from agile and lean, and smashing them together to create a project approach that works for them, at their company. It’s not quite agile. And, that’s the sticking point.

His management wants to “go agile.” They have no idea what that means.They think agile is a way to get more good stuff faster with less cost. It’s possible that with agile approaches, they can achieve that as a by-product. To be honest, any approach that stops people from waiting for phases to finish will help. That’s not necessarily agile.

The management team does know about one of the well-known approaches. They want everyone to go through that training. My client doesn’t think this will work. He has a number of concerns:

  • Management wants to control how people work at the project level. Management wants to define the iteration duration, what the standup questions will be, who will be on which team, and what the teams will do. (That’s enough right there, but there’s more. They are geographically dispersed across the globe. Going with an out-of-the-box solution does not make sense.)
  • Management wants to use team measurements for personal compensation. Specifically, they want to use personal velocity as a way to compensate people. (This is stupid, dangerous and wrong.)
  • Every manager my client has spoken with thinks that he or she does not need to change. Only the tech people need to change. (They could not be more mistaken.)

If you work in an agile organization, you know the problems with these assumptions.

Teams manage their own work: their intake is via the Product Owner. They decide how to work, flowing work through the team. Hopefully, the team focuses on their throughput, not who does what.

Remember,¬†Velocity is Not Acceleration. When managers abuse velocity and use it to measure the team members (not even the entire team!), they create schedule games and a toxic team environment. At best, a manager’s abuse of velocity leads to people taking shortcuts and incurring technical debt. At worse, it destroys teamwork.

Managers can create the environment in which people can succeed. Especially in agile and lean, managers do not have to “incent” people, or push people to do well. People will do a good job because they get feedback often and they want to. When managers attempt to manipulate an environment to deliver more with less work (what they think agile is), I’m not sure if anyone can succeed.

I asked my client if the managers understood what agile might mean for them, as managers. He was sure the managers had no idea.

I suggested that trying agile in this environment would give agile a bad name in the organization. I suggested these alternatives:

  • Ask about the three questions that might help the managers articulate their goals. See Define Your Agile Success.
  • Do a simulation with management to have them feel what agile is like.
  • Explain the system of agile and how the ideas that management have is not helpful.
  • Request a reasonable environment for a short-ish timebox (I was thinking about a month, maybe two months) to show management that their ideas are not the only ideas that could work. I suggested a number of measures my client could suggest to his management.

Don’t start agile in a toxic environment. It’s not worth it. Agile is wrong for you. Remember that Agile is Not a Silver Bullet and Agile is Not for Everyone.

Remember, agile is a cultural change, not merely a project management framework. Instead of agile, consider using all the ideas of agile to show steady progress and decide how to influence your managers.

Instead of agile, consider using all the ideas of agile ( for example, teamwork to deliver small chunks of value) to show steady progress and decide how to influence your managers. Don’t ask teams to be collaborative when management wants to stay command-and-control.

Categories: Project Management

When is Agile Wrong for You?

Tue, 05/24/2016 - 15:04

People often ask me, “When is agile¬† right or not right for a project?” I’ve said before that if the team wants to go agile, that’s great. If the team doesn’t, don’t use agile.

That answer is insufficient. In addition to the team, we need management to not create a bad environment for agile. You might not have a great environment to start. But a bad environment? That’s a horror show.

I had a coaching conversation recently. My client¬†has a typical problem. He sees multiple ways to accomplish the work. He’s taking ideas from agile and lean, and smashing them together to create a project approach that works for them, at their company. It’s not quite agile. And, that’s the sticking point.

His management wants to “go agile.” They have no idea what that means.They think agile is a way to get more good stuff faster with less cost. It’s possible that with agile approaches, they can achieve that as a by-product. To be honest, any approach that stops people from waiting for phases to finish will help. That’s not necessarily agile.

The management team does know about one of the well-known approaches. They want everyone to go through that training. My client doesn’t think this will work. He has a number of concerns:

  • Management wants to control how people work at the project level. Management wants to define the iteration duration, what the standup questions will be, who will be on which team, and what the teams will do. (That’s enough right there, but there’s more. They are geographically dispersed across the globe. Going with an out-of-the-box solution does not make sense.)
  • Management wants to use team measurements for personal compensation. Specifically, they want to use personal velocity as a way to compensate people. (This is stupid, dangerous and wrong.)
  • Every manager my client has spoken with thinks that he or she does not need to change. Only the tech people need to change. (They could not be more mistaken.)

If you work in an agile organization, you know the problems with these assumptions.

Teams manage their own work: their intake is via the Product Owner. They decide how to work, flowing work through the team. Hopefully, the team focuses on their throughput, not who does what.

Remember,¬†Velocity is Not Acceleration. When managers abuse velocity and use it to measure the team members (not even the entire team!), they create schedule games and a toxic team environment. At best, a manager’s abuse of velocity leads to people taking shortcuts and incurring technical debt. At worse, it destroys teamwork.

Managers can create the environment in which people can succeed. Especially in agile and lean, managers do not have to “incent” people, or push people to do well. People will do a good job because they get feedback often and they want to. When managers attempt to manipulate an environment to deliver more with less work (what they think agile is), I’m not sure if anyone can succeed.

I asked my client if the managers understood what agile might mean for them, as managers. He was sure the managers had no idea.

I suggested that trying agile in this environment would give agile a bad name in the organization. I suggested these alternatives:

  • Ask about the three questions that might help the managers articulate their goals. See Define Your Agile Success.
  • Do a simulation with management to have them feel what agile is like.
  • Explain the system of agile and how the ideas that management have is not helpful.
  • Request a reasonable environment for a short-ish timebox (I was thinking about a month, maybe two months) to show management that their ideas are not the only ideas that could work. I suggested a number of measures my client could suggest to his management.

Don’t start agile in a toxic environment. It’s not worth it. Agile is wrong for you. Remember that Agile is Not a Silver Bullet and Agile is Not for Everyone.

Remember, agile is a cultural change, not merely a project management framework.

Instead of agile, consider using all the ideas of agile ( for example, teamwork to deliver small chunks of value) to show steady progress and decide how to influence your managers. Don’t ask teams to be collaborative when management wants to stay command-and-control.

Categories: Project Management

Discovery Projects Work for Agile Contracts

Fri, 05/20/2016 - 16:50

Marcus Blankenship and I wrote an article, Stay Agile with Discovery, to discuss how to help your clients see the benefits of working in an agile or more agile way.

We have seen too many clients want “agile” and not want all the responsibilities that being a Product Owner or customer involves. If your client asks you to be agile and then demands you estimate “everything” and provide a fixed cost, fixed scope “agile” contract, you don’t have to say, “NO.”

You can say, let’s try a discovery project so we (as the provider) can explore what it would take to do “everything.” As we finish this first discovery project, where we will provide working product, you can provide us feedback. Based on that feedback, we might do another discovery project. In fact, you can work in month-long (or two-week long) discovery projects all the way through. Your client can ask for changes that you incorporate into the next discovery.

That’s just one way to help people learn about collaboration and resilience over contracts and guarantees.

If you are a Product Owner or a person who represents the customer, you might like our Practical Product Owner workshop.

Categories: Project Management

Velocity is Not Acceleration

Thu, 05/19/2016 - 14:44

I see a lot of confusion around velocity in new-to-agile teams.

Too many people treat velocity as an acceleration measurement. That is, they expect velocity to increase to some large number, as a stable state.

Velocity is a rate of change coupled with direction. When managers think they can measure a team with velocity, they confuse velocity with acceleration.

As I enter a highway, I have a higher rate of acceleration. As I continue to drive, I achieve a stable state: I get into a lane¬†and maintain a constant speed. (Well, with any luck.) I stay stable¬†with¬†respect to the road (my direction). My velocity stays the same—especially if I use my cruise control. With a reasonable velocity—that might change a little with traffic—I can get to my destination.

A note on direction: ¬†I live in the Boston area, where roads curve. North, South, East, and West are useful to other people. We have highways that literally point south that have a designation of “North.” They curve. I don’t find these directions useful. I am more likely to talk about the exit number on a highway or the gas station on a side road. Direction is as contextual as is velocity.

Direction for a project is much more about finishing features. How close to “done” are you? More on that below.

When managers try to use velocity as acceleration, they create schedule games. See Double Your Velocity. That often leads to people taking shortcuts and incurring technical debt.

What can you use instead of velocity? The feature burnup/burndown chart and the product backlog burnup chart.

Program.Feature.Chart_ This chart is an example of a feature burnup/burndown chart.

You chart the total number of features (the green line that wiggles at the top), the features complete (the burnup red line that continues to increase), and the features remaining (the burndown in blue, the line that proceeds down). I like this chart because you can see if things get a little “wonky” during the project.

If you add too many features faster than the team can finish features, you will have a large gap between the green and red lines. The blue line will go up. This chart shows you that. You can see how close to done you are for the project.

Product Backlog Burnup Chart (several iterations/milestones)

Product Backlog Burnup Chart (several iterations/milestones)

I also like the product backlog burnup chart. This shows how much progress a team (or teams) make on all the feature sets. (That helps people realize they should define feature sets. Feature sets help the team see where the product is headed.)

In this chart, the team works on feature set 1 (FS 1) and feature set 2 (FS 2). Those stories are more valuable than anything in feature set 3.

You can see that feature set 2 increased in the number of stories for the 5th milestone/iteration. That also helps people understand when they can expect the project to be done.

Measuring velocity¬†can help a team see what’s happening. See Value of Burndown and Burnup Charts.

However, velocity is for a team. Velocity helps a team see its context over some time period. They get to decide how to show it and what to do about it. If management wants to see progress, the team can measure the features complete, remaining, total chart and the product backlog burnup chart. (I would also measure cumulative flow to see how much work in progress the team has.)

Don’t measure velocity to see progress. ¬†That’s not the measurement you want or need.

Categories: Project Management

Writing Workshop Starts on August 24, 2016

Thu, 05/19/2016 - 14:32

I had a great time with my previous version of the Non-Fiction Writing Workshop: Write Non-Fiction to Enhance Your Business and Reputation. I am offering it again, starting this August 24.

I added another week, so you have the chance to practice more. I am also offering a personal accountability option. If you want, you can track your writing (words or minutes) in a group spreadsheet.

If you want to improve your non-fiction, start with your non-fiction writing, or nudge yourself to writing that book, please join me in the workshop. I’d love to work with you.

Categories: Project Management

Podcast About Agile and Lean Program Management with Ryan Ripley

Wed, 05/18/2016 - 14:47

Ryan Ripley and I spoke on his Agile for Humans Podcast, Agile Program Management with Johanna Rothman.

 Scaling Collaboration Across the OrganizationWe had a blast. We spoke all about Agile and Lean Program Management: Scaling Collaboration Across the Organization, estimation, value, and much more. I hope you listen.

Categories: Project Management

New Practical Product Ownership Workshop Dates

Mon, 05/16/2016 - 16:56

I just posted the dates for the next Practical Product Ownership workshop: Deliver What Your Customers Need. It starts Aug 23, 2016.

You need this workshop if:

  • You are having trouble doing everything in your PO role, you might be trying to do too much. See Product Manager, Product Owner, Business Analyst?
  • You are having trouble deciding how to organize your backlog, roadmap, and everything.
  • How to value the items you do organize. We discuss Cost of Delay and seven other possibilities to rank the items.
  • How to help people articulate the problems they want the team to solve, not the solutions.
  • And much, much more.

We meet twice a week for six weeks. Our first meeting is a 90-minute teaching call, where I teach and you ask questions. We meet later that week for a 60-minute coaching call, where you bring your problems, concerns, and challenges.

I estimate you will have about 60-90 minutes of homework every week. Any other questions? Email me.

Categories: Project Management

Survey About Technical Managers

Thu, 05/12/2016 - 13:48

Marcus Blankenship and I are conducting a survey of technical managers. If you are or have been a technical manager, please take the survey here: Software leadership 2016 survey.

Oh, and I was so curious about how many female/male managers there were, we had to ask that question. Yes, I said to Marcus, “We have to ask!” He laughed and added that question.

It should take you less than 10 minutes to fill out the survey. We will leave the survey open for no more than a couple of weeks. We’ll send the results to people who asked for it, along with publishing the results in the article we are writing.

We will not add your name to any email lists. It’s safe for your mailbox to take the survey. The link is Software leadership 2016 survey.

Categories: Project Management

A Working Definition of Agile

Wed, 05/04/2016 - 15:49

In a recent workshop, a¬†participant asked me, “What does agile mean? How do you know if you are agile?” He wants to use kanban to see the flow of work through his group. Someone told him he needed to use iterations to be agile. (I had a little rant about this in¬†What Does Agile Mean to You?)

I suggested this could be his working definition:

  • You can deliver what you want (some form of value).
  • You can deliver that value ¬†when you want.
  • You can then change to the next most important chunk of valuable work.
  • You learn from the previous work you did, both about the work and the process of doing the work.

That’s not all agile is, but it might be a good working definition. If you work towards being able to deliver what and when you want, move to the next thing, and learn, you have the feedback cycles. (You might also look at the agile principles behind the Manifesto.)

These are practices that increase your agile capabilities:

  • Iterations, because they limit the work a team can commit to in a given time period.
  • Kanban with work in progress limits, because they limit the work a team can do, and show the flow of work.
  • Retrospectives because you learn from previous work. (Someone important said if they only did one practice it would retrospectives. I can’t remember who said that. Sorry.)
  • Standups because they reinforce micro-commitments to finishing work.
  • Technical excellence practices from XP, because they make changing the code and tests easier.

You don’t need any of these to be agile. They help. You might find other practices to be more helpful in your context.

I have some previous posts that might be interesting if you also are wondering what agile means for you:

For me, practices are interesting, especially if I choose to experiment with them. What could I do to increase my throughput and learning, and therefore, my ability to adapt? Agile is not about specific practices. It is about a mindset of finishing small valuable chunks, feedback, and change.

Categories: Project Management