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
Syndicate content
Expert in Managing Product Development
Updated: 6 hours 29 min ago

Great Review of Predicting the Unpredictable

Wed, 07/29/2015 - 13:31

Ryan Ripley “highly recommends” Predicting the Unpredictable: Pragmatic Approaches to Estimating Cost or Schedule. See his post:¬†Pragmatic Agile Estimation: Predicting the Unpredictable.

He says this:

This is a practical book about the work of creating software and providing estimates when needed. Her estimation troubleshooting guide highlights many of the hidden issues with estimating such as: multitasking, student syndrome, using the wrong units to estimate, and trying to estimates things that are too big. — Ryan Ripley

Thank you, Ryan!

PredictingUnpredictable-small See Predicting the Unpredictable: Pragmatic Approaches to Estimating Cost or Schedule for more information.

Categories: Project Management

7 Tips for Valuing Features in a Backlog

Thu, 07/23/2015 - 14:37

Many product owners have a tough problem. They need so many of the potential features in the roadmap, that they feel as if everything is #1 priority. They realize they can’t actually have everything as #1, and it’s quite difficult for them to rank the features.

This is the same problem as ranking for the project portfolio. You can apply similar thinking.

Once you have a roadmap, use these tips to help you rank the features in the backlog:

  1. Should you do this feature at all? I normally ask this question about small features, not epics. However, you can start with the epic (or theme) and apply this question there. Especially if you ask, “Should we do this epic for this release?”
  2. Use Business Value Points to see the relative importance of a feature. Assign each feature/story a unique value. If you do this with the team, you can explain why you rank this feature in this way. The discussion is what’s most valuable about this.

  3. Use Cost of Delay to understand the delay that not having this feature would incur for the release.

  4. Who has Waste from not having this feature? Who cannot do their work, or has a workaround because this feature is not done yet?

  5. Who is waiting for this feature? Is it a specific customer, or all customers, or someone else?

  6. Pair-wise and other comparison methods work. You can use single or double elimination as a way to say, “Let’s do this one now and that feature later.”

  7. What is the risk of doing this feature or not doing this feature?

Don Reinertsen advocates doing the Weighted Shortest Job first.  That requires knowing the cost of delay for the work and the estimated duration of the work. If you keep your stories small, you might have a good estimate. If not, you might not know what the weighted shortest job is.

And, if you keep your stories small, you can just use the cost of delay.

Jason Yip wrote Problems I have with SAFe-style WSJF, which is a great primer on Weighted Shortest Job First.

I’ll be helping product owners work through how to value their backlogs in Product Owner Training for Your Agency, starting in August. When you are not inside the organization, but supplying services to the organization, these decisions can be even more difficult to make. Want to join us?

Categories: Project Management

Product Manager, Product Owner, or Business Analyst?

Thu, 07/16/2015 - 18:44

Do you have a title such as product manager, product owner, or business analyst?

We hear  these titles all the time. What does each do?

Here is how I have seen successful agile projects and programs use people in these positions. Note that I am discussing agile projects and programs.

The product manager creates the roadmap. She has the product vision over the entire life of the product. Typically, what’s In the roadmap are larger than epics—they are themes or feature sets.¬†

Product management means thinking strategically about the product. You might require several projects or programs to achieve what the product manager wants as a strategic vision.

Product owners (PO) work with agile teams to translate the strategic vision into Minimum Viable Products. The PO decides when the team(s) have done enough to release. See the release frequency image to understand the cost and value of releasing.

The business analyst¬†may do any of these things. In my experience, I have seen business analysts focus on “what does this requirement/feature/story really mean to the team and/or the product?” I have seen fewer BAs do the strategic visioning of the product over its lifetime. I have seen BAs work with POs when the PO was not available enough for the team. I have seen BAs do great work breaking stories into smaller components of value, not architectural components.

Your team might have different names for these positions. Each team needs the strategic lifetime-of-the-product view; the tactical view for the next iteration or so and the knowledge of how to re-rank the backlog; and the ability to translate stories into small valuable chunks. 

Can one person do each of these things? It depends on the person. I have found it difficult to move quickly from the tactical to strategic and back again (or vice versa). Maybe you know how. For me, that is a form of multitasking. 

The more important questions are: do you have the roles you need, at the time you need them on your team? If you are one of these people, do you know how to perform these roles? If you are outside the organization in some way, do you know what you need to do, to perform these roles?

If you don’t know what to do to help your team, consider participating in Product Owner for Agencies training. Marcus Blankenship and I will help you learn what to do, and coach you in real time as to how to do it best for your team. I hope to see you there.

Categories: Project Management

Three Tips for Product Owners

Tue, 07/07/2015 - 13:55

As I work with more clients on their programs, I see that what might work for a product owner for a team does not work for a program. In a program, if the product owner is shortsighted, does not take advantage of agile/lean for updates, and does not have small features, the program loses momentum. Here are my three tips:

AgileRoadmap.copyright-1080x7941. Take the big picture perspective.

When the product owner (or, in this case, a program product owner) creates a several quarter rolling wave roadmap the teams can see the product direction. This helps the teams see avoid bad product decisions that might inadvertently prevent the product from taking a direction the PO would like.

There is a challenge with this. Teams can rarely, if ever, commit to an entire quarter’s worth of work. That’s okay. The roadmap¬†is a wishlist. The roadmap informs and guides the product development. Teams need detailed backlogs.

AgileRoadmapOneQuarter.copyright-1024x7622. Use agile and lean to update the roadmap often, as in every couple of weeks.

I know of just a couple of teams who can plan for up to three iterations and not replan. Some teams can plan for two iterations, some for one. Even if you can complete features according to a one-quarter roadmap, the product owner needs the ability to change the ranking of the remaining features.

As the teams finish features, it’s the product owner’s job to accept the features, or not. And, it’s the product owner’s job to update the one-quarter roadmap—and maybe the multiple quarter roadmap.

  1. The bigger the product, the smaller the features/stories need to be.

I’m working with some programs who have only 5 or 6 teams. I’m working with some who have 20, 30, 40 teams. That’s a ton of people. How do those people stay in sync? By integrating and creating tests that test the product, end to end. If the stories are large, the teams have a ton of work in progress and lose the ability to collaborate easily. This can be a huge challenge for the product owners and teams.

For one-team projects, I like one and two-day stories. That way the product owner can see progress every day. (I’m happy if it’s even more often than that! Two days is my max story size.)

I know product owners who can barely make time for one meeting an iteration with their teams. That does not provide the product owner feedback about the story size, or what is in the stories. Stories tend to become more complex. Then, the team doesn’t finish the stories and everyone wants to know why.

When you have smaller stories, you see the value in what the team(s) do, all the time. The teams build momentum.

Making stories small requires you think about how little you can do, not how much. That’s a huge change, especially in a program.

Those are my three tips for today:

  1. Create a big picture rolling-wave roadmap.
  2. Update the roadmap often, as teams complete features.
  3. Create small stories so the team(s) can maintain momentum.

If you liked this post, you might want to join Marcus Blankenship and me for our Product Owner for Agencies training. These things are tricky enough when you are inside the organization. They are more difficult when you are an agency/consultant working for the client.

Categories: Project Management

Agency Product Owner Training Starts in August

Thu, 07/02/2015 - 15:42

We have an interesting problem in some projects. Agencies, consulting organizations, and consultants help their clients understand what the client needs in a product. Often, these people and their organizations then implement what the client and agency develop as ideas.

As the project continues, the agency manager continues to help the client identify and update the requirements. Because this a limited time contract, the client doesn’t have a product manager or product owner. The agency person—often the owner—acts as a product owner.

This is why Marcus Blankenship and I have teamed up to offer Product Owner Training for Agencies.

If you are an agency/consultant/outside your client’s organization and you act as a product owner, this training is for you. It’s based on my workshop Agile and Lean Product Ownership. We won’t do everything in that workshop. Because it’s an online workshop, you’ll work on your projects/programs in between our meetings.

If you are not part of an organization and you find yourself acting as a product owner, this training is for you. See Product Owner Training for Agencies.

Categories: Project Management

What Creates Trust in Your Organization?

Fri, 06/26/2015 - 16:16

I published my most recent newsletter, Creating Trustworthy Estimates, this past week. I also noted on Twitter that one person said his estimates created trust in his organization. (He was responding to a #noestimate post that I had retweeted.)

Sometimes, estimates do create trust. They provide a comfortable feeling to many people that you have an idea of what size this beast is. That’s why I offer solutions for a gross estimate in Predicting the Unpredictable. I have nothing against gross estimates.

I don’t like gross estimates (or even detailed estimates) as a way to evaluate projects in the project portfolio¬†because estimates are guesses. Estimates are not a great way to understand and discuss the value of a project. They might be one piece of the valuation discussion, but if you use them as the only way to value a project, you are missing the value discussion you need to have. See Why Cost is the Wrong Question for Evaluating Projects in Your Project Portfolio.

I have not found that only estimates create trust. I have found that delivering the product  (or interim product) creates more trust.

Way back, when I was a software developer, I had a difficult machine vision project. Back then, we invented as we went. We had some in-house libraries, but we had to develop new solutions for each customer.

I had an estimate of 8 weeks for that project. I prototyped and tried a gazillion things. Finally, at 6 weeks, I had a working prototype. I showed it to my managers and other interested people. I finished the project and we shipped it.

Many years later, when I was a consultant, I encountered one of those managers. He said to me, “We held our breath for 6 weeks¬†until you showed us a prototype. You had gone dark and we were worried. We had no idea if you would finish.”

By that time, I had managed people like me. I asked them for visual updates on their status each week or two. I had learned from my experiences.

I asked that manager why they held their breath. I always used an engineering notebook. I could have explained my status at any time to anyone who wanted it. He replied, “We so desperately wanted your estimate to be true. We were so afraid it wasn’t. We had no idea what to do. When you showed us a working prototype, that’s when we started to believe you could finish the project.”

They trusted my initial estimate. It’s a good thing they didn’t ask for updated estimates each week. I remember that project as a series of highs and lows.

That’s the problem with invention/innovation. You can keep track of your progress. You can determine ways to make progress. And, with the highs, your meet or beat your estimate. With the lows, you extend your estimate. I remember that at the beginning of week 5 I was sure I was not going to meet my date. Then, I discovered a way to make the project work. I remember my surprise that it was something “that easy.” It wasn’t easy. I had tracked my experiments in my notebook. There wasn’t much more I could do.

Since then, I asked¬†my managers, “When do you want to know my project is in trouble? As soon as it I think I’m not going to meet my date; after I do some experiments; or the last possible moment?” I create trust when I ask that question¬†because it shows I’m taking their concerns seriously.

After that project, here is what I did to create trust:

  1. Created a first draft estimate.
  2. Tracked my work so I could show visible progress and what didn’t work.
  3. Delivered often. That is why I like inch-pebbles. Yes, after that project, I often had one- or two-day deliverables.
  4. If I thought I wasn’t going to make it, use the questions above to decide when to say, “I’m in trouble.”
  5. Delivered a working product.

PredictingUnpredictable-smallEstimates can be useful. They can show you the risks. And, I’m sure that only having estimates is insufficient for building trust. If you want to learn more about estimation, see Predicting the Unpredictable: Pragmatic Approaches to Estimating Cost or Schedule.

Categories: Project Management

Predicting the Unpredictable is Available

Wed, 06/24/2015 - 14:27

PredictingUnpredictable-smallI’m happy to announce that Predicting the Unpredictable: Pragmatic Approaches to Estimating Cost or Schedule is done and available. It’s available in electronic and print formats. If you need a little help explaining your estimates or how to use estimation (even #noestimate), read this book.

 

Categories: Project Management

Management, Humanity and Expectations

Mon, 06/22/2015 - 14:11

There’s a twitter discussion of what people “should” do in certain situations. One of the participants believes that people “should” want to learn on their own time and work more than 40 hours per week. I believe in learning. I don’t believe in expecting people to work more than 40 hours/week. My experience is that when you ask people to work more than 40 hours, they get stupid. See ¬†Management Myth 15: I Need People to Work Overtime. If you want people to learn, read Management Myth #9: We Have No Time for Training.

One participant also said that people should leave their emotional baggage (my word) at home. Work supposedly isn’t for emotions. Well, I don’t understand how we can have people who work without their emotions. Emotions are how we explain how we feel about things. I want people to advocate for what they feel is useful and good. I want to know when they feel something is bad and damaging. I want that, as a manager. See Management Myth #4: I Don’t Need One-on-Ones.

People are emotional. Let’s assume they are adults and can harness their emotions. If not, we can provide feedback about the situation. But, ignoring their emotions? That never works. It’s incongruent and can make the situation worse.

I have a problem with “shoulds” for other people. I cannot know what is going on in other people’s lives. Nor, do I want to know all the details as a manager. I need to know enough to use my judgement as a manager to help the people and teams proceed.

When managers build trust with people, those people can share what is relevant about the way they can perform at work with their manager, and maybe with their team. If they have a personal situation that requires time off, depending on the team, the person might have to talk to the team before the manager. (I know some agile teams like this.) The team might manage the situation without management help or interference.

If you are in a leadership position, don’t impose your “shoulds” on other people. You cannot know what is happening in other people’s lives. You can ask for

You can ask for the results you want. You want people to learn more? Provide time during the week for everyone to learn together. You want people to work through a personal crisis? Provide support.

Don’t expect automatons at work. Expect humans and you’ll get way more than you could imagine.

Categories: Project Management

Trust, Accountability, and Where Does the Time Go?

Wed, 06/17/2015 - 07:56

As more of my clients transition to agile, many of them have a fascinating question:

How do I assess who is doing what on my team?

When I ask why they want to know, they say it’s all related to reviews, rewards, and general compensation. They are still discussing individual compensation, not team compensation.

When I ask why they want to reward individuals instead of the team, they say, “I am sure some people do more work than others. I want to reward them, and not the other people.”

Interesting idea. And, wrong for agile teams. Also wrong for any innovation or learning that you want to happen as a team (regardless of whether you are agile or not).

Agile is a team-based approach to work. Why would you want to reward some people more than others? If the team is not sure that they are working well together, they need to learn to provide each other feedback. If the team doesn’t know how to manage team membership, a manager can facilitate that membership discussion and problem-solving. Then, the managers can transition team membership issues to the team, with manager as backup/facilitator.

What I see is that the managers want to control team membership. Instead, why not let the team control its membership?

I often see that the managers want to control feedback: who provides it and who receives it. Instead, why not train everyone in how to provide and receive feedback?

When managers want to reward some people more than others, they imply that some people are less capable than others—something agile is supposed to fix with teamwork. Or, they wonder if some people are wasting time.

If managers trust their teams, managers don’t need to worry about accountability. They don’t have to worry about people “wasting time.” Agile creates transparency, which helps people to learn to trust each other and know when they are working on relevant work or not. If you encourage the team to add pairing or swarming (or both), you have the recipe for whole-team work and team momentum.

I don’t know anyone who goes to work thinking, “How can I waste my time today?” Do you? (If you do, why is that person on your team?)

I know plenty of people who do waste their time, because of technical debt, or experts creating bottlenecks, or team members who don’t want to work as part of a team. I bet you know many of these people, too.

But I don’t know anyone who wants to go to work to waste time and collect a paycheck without doing anything. Sure, there might be some people like that. I don’t know any.

In an agile team, the team members know who works hard and who doesn’t. A manager could trust the team to handle their compensation.

And, that would mean the manager has to relinquish control of much of what managers have done recently.

  • The manager would have to provide feedback and meta-feedback to people who want to learn how to provide and receive feedback.
  • The manager might provide coaching as to how to work in a team effectively. (This can be tough if a manager has never been part of a team that worked well.)
  • The manager would allow the team to control their compensation.

There’s more, and I’ll stop there.

What would managers do? They would stop interfering with the team’s progress. The manager might read “If Managers Don’t Give Performance Reviews, What Happens?

Managers control much less in agile. Managers enable more. They have to trust the teams. This is a culture change.

If you can’t trust your agile team or its team members, there is something wrong. You can investigate and either fix (manage the project portfolio) or ask the team to fix it (maybe with retrospectives as a first step). If you need to know who is accountable for what, you are asking the wrong question. The answer might be you.

If you are managing an agile team and you want to know about individual work or accountability, ask yourself what you really need. Ask yourself if there is another way to obtain the results you want. Maybe you won’t waste quite as much time.

Categories: Project Management

Trust, Accountability, and Where Does the Time Go?

Wed, 06/17/2015 - 07:56

As more of my clients transition to agile, many of them have a fascinating question:

How do I assess who is doing what on my team?

When I ask why they want to know, they say it’s all related to reviews, rewards, and general compensation. They are still discussing individual compensation, not team compensation.

When I ask why they want to reward individuals instead of the team, they say, “I am sure some people do more work than others. I want to reward them, and not the other people.”

Interesting idea. And, wrong for agile teams. Also wrong for any innovation or learning that you want to happen as a team (regardless of whether you are agile or not).

Agile is a team-based approach to work. Why would you want to reward some people more than others? If the team is not sure that they are working well together, they need to learn to provide each other feedback. If the team doesn’t know how to manage team membership, a manager can facilitate that membership discussion and problem-solving. Then, the managers can transition team membership issues to the team, with manager as backup/facilitator.

What I see is that the managers want to control team membership. Instead, why not let the team control its membership?

I often see that the managers want to control feedback: who provides it and who receives it. Instead, why not train everyone in how to provide and receive feedback?

When managers want to reward some people more than others, they imply that some people are less capable than others—something agile is supposed to fix with teamwork. Or, they wonder if some people are wasting time.

If managers trust their teams, managers don’t need to worry about accountability. They don’t have to worry about people “wasting time.” Agile creates transparency, which helps people to learn to trust each other and know when they are working on relevant work or not. If you encourage the team to add pairing or swarming (or both), you have the recipe for whole-team work and team momentum.

I don’t know anyone who goes to work thinking, “How can I waste my time today?” Do you? (If you do, why is that person on your team?)

I know plenty of people who do waste their time, because of technical debt, or experts creating bottlenecks, or team members who don’t want to work as part of a team. I bet you know many of these people, too.

But I don’t know anyone who wants to go to work to waste time and collect a paycheck without doing anything. Sure, there might be some people like that. I don’t know any.

In an agile team, the team members know who works hard and who doesn’t. A manager could trust the team to handle their compensation.

And, that would mean the manager has to relinquish control of much of what managers have done recently.

  • The manager would have to provide feedback and meta-feedback to people who want to learn how to provide and receive feedback.
  • The manager might provide coaching as to how to work in a team effectively. (This can be tough if a manager has never been part of a team that worked well.)
  • The manager would allow the team to control their compensation.

There’s more, and I’ll stop there.

What would managers do? They would stop interfering with the team’s progress. The manager might read “If Managers Don’t Give Performance Reviews, What Happens?

Managers control much less in agile. Managers enable more. They have to trust the teams. This is a culture change.

If you can’t trust your agile team or its team members, there is something wrong. You can investigate and either fix (manage the project portfolio) or ask the team to fix it (maybe with retrospectives as a first step). If you need to know who is accountable for what, you are asking the wrong question. The answer might be you.

If you are managing an agile team and you want to know about individual work or accountability, ask yourself what you really need. Ask yourself if there is another way to obtain the results you want. Maybe you won’t waste quite as much time.

Categories: Project Management

Early Release of Agile and Lean Program Management Available

Tue, 05/26/2015 - 13:28

 Scaling Collaboration Across the OrganizationI have finished integrating comments from the early review of Agile and Lean Program Management: Scaling Collaboration Across the Organization. I decided that the book was good enough to release to the general public.

I find it difficult to release books in progress. The in-progress part challenges my perfection rules. I also know that some of you who want this book will wait until it’s done, or worse, available in paper.

However, since this is an agile and lean book, it seems nuts to not release it, even though it is not quite done.

If you get the book, please send me comments about what confused you, what you thought was crazy, and anything else.

Thanks so much!

 

Categories: Project Management

Is Agile Working for Your Project?

Mon, 05/18/2015 - 14:59

My column is up on projectmanagement.com. It’s called Is Agile Working for Your Project?

I hope you enjoy it.

Categories: Project Management

Thinking About #NoEstimates?

Fri, 04/24/2015 - 12:32

I have a new article up on agileconnection.com called The Case for #NoEstimates.

The idea is to produce value instead of spending time estimating. We have a vigorous “debate” going on in the comments. I have client work today, so I will be slow to answer comments. I will answer as soon as I have time to compose thoughtful replies!

This column is the follow-on to How Do Your Estimates Provide Value?

If you would like to learn to estimate better or recover from “incorrect” estimates (an oxymoron if I ever heard one), see Predicting the Unpredictable. (All estimates are guesses. If they are ever correct, it’s because we got lucky.)

Categories: Project Management

Thinking About Estimation

Tue, 04/21/2015 - 15:06

I have an article up on agileconnection.com. It’s called How Do Your Estimates Provide Value?

I’ve said before that¬†We Need Planning; Do We Need Estimation?¬†Sometimes we need estimates. Sometimes we don’t. That’s why I wrote Predicting the Unpredictable: Pragmatic Approaches for Estimating Cost or Schedule.

I’m not judging your estimates. I want you to consider how you use estimates.

BTW, if you have an article you would like to write for agileconnection.com, email it to me. I would love to provide you a place for your agile writing.

Categories: Project Management