Home » Author Archives: Johanna Rothman (page 3)

Author Archives: Johanna Rothman

Johanna consults, speaks, and writes about managing product development. She helps managers and leaders do reasonable things that work. You can read more of her writings at jrothman.com.

Capacity Planning and the Project Portfolio

agile-logo

I was problem-solving with a potential client the other day. They want to manage their project portfolio. They use Jira, so they think they can see everything everyone is doing. (I’m a little skeptical, but, okay.) They want to know how much the teams can do, so they can do capacity planning based on what the teams can do. (Red ...

Read More »

People Are Not Resources

agile-logo

My manager reviewed the org chart along with the budget. “I need to cut the budget. Which resources can we cut?” “Well, I don’t think we can cut software licenses,” I was reviewing my copy of the budget. “I don’t understand this overhead item here,” I pointed to a particular line item. “No,” he said. “I’m talking about people. Which ...

Read More »

Hiring Trap: I’ll Wait for the Best Person

agile-logo

A senior product manager had a great interview the other day. “I know the industry. I worked on the first generation of their product. I know their customers. I could do this job. I understand their problems. I showed them how I’d solved their problems in the past. I can do this again. “It’s a little junior for me, but ...

Read More »

How Pairing & Swarming Work & Why They Will Improve Your Products

agile-logo

If you’ve been paying attention to agile at all, you’ve heard these terms: pairing and swarming. But what do they mean? What’s the difference? When you pair, two people work together to finish a piece of work. Traditionally, two developers paired. The “driver” wrote the piece of work. The other person, the “navigator,” observed the work, providing review, as the ...

Read More »

Do You Encourage People to Bring You Problems?

agile-logo

One of the familiar tensions in management is how you encourage or discourage people from bringing you problems. One of my clients had a favorite saying, “Don’t bring me problems. Bring me solutions.” I could see the problems that saying caused in the organization. He prevented people from bringing him problems until the problems were enormous. He didn’t realize that ...

Read More »

Scaling Agile? Think Out, Not Up

agile-logo

I taught the Influential Agile Leader workshop with Gil Broza last week in Edinburgh. (That’s why I was quiet. I was traveling and teaching. No time for writing, blogging or tweeting.) One of the participants asked me what I thought about scaling agile. Before I could explain about small-world networks, not hierarchies, he said, “I am sure the way you ...

Read More »

Design Your Agile Project, Part 5

agile-logo

This post is what you do when you are a program manager and not everyone knows what “agile” is, when you create a new product, when you are introducing that much cultural change? (In the book, I will talk more specifically about change and what to do. This post is the highlights.) Project management and program management are all about ...

Read More »

Are You Running from Problems or Solving Them?

agile-logo

Back when I was a manager inside organizations, I had many days that looked like this: Meetings at 9am, 10am, 11am. Working meeting through lunch (noon-1pm) Meetings at 1pm, 2pm, 3pm. I finally got a chance to check my email at 4pm. That’s when I discovered the world had blown up earlier in the day! (This is before cell phones. ...

Read More »

Estimation and the Sunk Cost Fallacy

agile-logo

I’m not a fan of using schedule or cost estimate as a way to value the projects in your project portfolio. If you do, you are likely to miss the potentially transformative projects or programs. In Manage Your Project Portfolio, I have an entire chapter devoted to ways to evaluate your project portfolio: business value points (not story points), waste, ...

Read More »

Design Your Agile Project, Part 4

agile-logo

If you are thinking of agile as part of a program, each team has to have its own approach to agile. Why? Because each team has its own risks and problems. You don’t need to standardize agile for anyone. If you treat people as if they are adults and explain the principles that you want (working software all the time ...

Read More »
Do you want to know how to develop your skillset and become a ...

Subscribe to our newsletter to start Rocking right now!

To get you started we give you our best selling eBooks for FREE!
Get ready to Rock!
To download the books, please verify your email address by following the instructions found on the email we just sent you.

THANK YOU!

Close