The Product Roadmap is Not the Project Portfolio

I keep seeing talks and arguments about how the portfolio team should manage the epics for a program. That conflates the issue of project portfolio management and product management. Several potential teams affect each project (or program). Starting at the right side of this image, the project portfolio team decides which projects to do and when for the organization. The product owner value team decides which features/feature sets to do when for a given product. That team may well split feature sets into releases, which provides the project portfolio team opportunities to change the project the cross-functional team works on. The product development team (the agile/lean cross-functional team) decides how to design, implement, and test the current backlog of work. When the portfolio team gets in the middle of the product roadmap planning, the product manager does not have the flexibility to manage the product backlog or the capabilities of the product over time. When the product owner value team gets in the middle (or doesn’t plan enough releases), they prevent the project portfolio team from being able to change their minds over time. When the product development team doesn’t release working product often, they prevent the product owner team from managing the product value. In addition, the product development team prevents the project portfolio team from implementing the organizational strategy when they don’t release often. All of these teams have dependencies on each other. The project portfolio team optimizes the organization’s output. The product owner value team optimizes the product’s output. The product development team determines how to optimize for features moving across the board. When the features...

Interview with FogCreek About Hiring for Technical Fit

Several weeks ago, the nice folks at FogCreek interviewed me. It’s here: Technical Hiring and Cultural Fit – Interview with Johanna Rothman. The interview ranged over many topics: Cultural fit Diversity What to do when you look for a job Much more I hope you enjoy it. If you want to read more about how to hire, check out Hiring Geeks That Fit. To read more about how to find a job, see Manage Your Job...

My Agile 2015 Roundup

Agile 2015 was the week of Aug 3-7 this year. It was a great week. Here are the links to my interviews and talks. Interview with Dave Prior. We spoke about agile programs, continuous planning, and how you might use certifications. I made a little joke about measurement. Interview with Paul DuPuy of SolutionsIQ. We also spoke about agile programs. Paul had some interesting questions, one of which I was not prepared for. That’s okay. I answered it anyway. The slides from Scaling Agile Projects to Programs: Networks of Autonomy, Collaboration and Exploration. At some point, the Agile Alliance will post the video of this on their site. The slides from my workshop Agile Hiring: It’s a Team Sport. Because it was a workshop, there are built-in activities. You can try these where you work. My pecha kucha (it was part of the lightning talks) of Living an Agile Life. I hope you enjoy these. I had a great time at the conference....

Differences Between Hiring a Contractor or Consultant

In my session at Agile 2015, (Agile Hiring: It’s a Team Sport) one participant asked me if I hire contractors the same way I hire employees. I do. I use the same approaches for reviewing resumes, phone screens, interviews and decisions. The one difference is the offer—instead of a yearly salary paid in some form of incremental approach, contractors get a dollar/hour over a timeboxed period. One of the people in my session called contractors “consultants” and tweeted about it. She wanted to make sure the contractor had the same respect as a consultant. That concern goes to why the hiring manager hires a contractor or a consultant. If I need an extra pair of hands for a limited period of time, I hire a contractor. If I need guidance—which might include some hands-on work—I hire a consultant. You might like this perspective on how consultants work, from Choosing a Consulting Role: Principles and Dynamics of Matching Role to Situation, by Champion, Kiel and McLendon: What’s important to me is who has the responsibility for client growth. I expect a consultant to help me (or my team or organization) grow in some way. I expect a contractor to provide extra pair-of-hands services. I do not expect them to help me grow. I might get that, but I definitely don’t expect it, especially when hiring a developer, tester, project manager, Scrum Master, or some other individual contributor position. To me, that is a big difference between contractors and consultants. I don’t expect contractors to contribute to anyone’s growth. I do expect consultants to contribute to growth. That’s why I expect to...

How to Use Continuous Planning

If you’ve read Reasons for Continuous Planning, you might be wondering, “How can we do this?” Here are some ideas. You have a couple of preconditions: The teams get to done on features often. I like small stories that the team can finish in a day or so. The teams continuously integrate their features. Frequent features with continuous integration creates an environment in which you know that you have the least amount of work in progress (WIP). Your program also has a steady stream of features flowing into the code base. That means you can make decisions more often about what the teams can work on next. Now, let’s assume you have small stories. If you can’t imagine how to make a small story, here is an example I used last week that helped someone envision what a small story was: Imagine you want a feature set called “secure login” for your product. You might have stories in this order: A person who is already registered can login with their user id and password. For this, you only need to have a flat file and a not-too-bright parser—maybe even just a lookup in the flat file. You don’t need too many cases in the flat file. You might only have two or three. Yes, this is a minimal story that allows you to write automated tests to verify that it works even when you refactor. A person who is not yet registered can create a new id and password. After the person creates a new id and password, that person can log in. You might think of the database schema...