Who Should be Your Product Owner?

In agile, we separate the Product Owner function from functional (development) management. The reason is that we want the people who can understand and evaluate the business value to articulate the business value to tell the people who understand the work’s value when to implement what. The technical folks determine how to implement the what. Separating the when/what from how is a great separation. It allows the people who are considering the long term and customer impact of a given feature or set of features a way to rank the work. Technical teams may not realize when to release a given feature/feature set. In my recent post, Product Manager, Product Owner, or Business Analyst?, I discussed what these different roles might deliver. Now it’s time to consider who should do the product management/product ownership roles. If you have someone called a product manager, that person defines the product, asks the product development team(s) for features, and talks to customers. Notice the last part, the talking to customers part. This person is often out of the office. The product manager is an outward-facing job, not an internally-focused job. The product owner works with the team to define and refine features, to replan the backlogs, and to know when it is time to release. The product owner is an inward-facing function. (Just for completeness, the business analyst is an inward-facing function. The BA might sit with people in the business to ask, “Exactly what did you mean when you asked for this functionality? What does that mean to you?” A product owner might ask that same question.) What happens when your product...

Trust, Accountability, and Where Does the Time Go?

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

Why Managers Ask for Estimates and What They Need to Know

In many of my transitioning to agile clients, the managers want to know when the project will be done. Or, they want to know how much the project will cost. (I have a new book about this, Predicting the Unpredictable: Pragmatic Approaches to Estimating Cost or Schedule.) Managers ask for estimates because they want to know something about their ability to recognize revenue this year. How many projects can they release? What is the projected effect on revenue; customer acquisition and retention; and on service revenue (training, support, all that kind of service). We pay managers big bucks so they can project out for “a while” and plan for the business. You need to know this in your life, too. If you are an employee, you know approximately how much money you will make in a year. You might make more if you get a bonus. You might make less if you get laid off. But, you have an idea, which allows you to budget for mortgages, vacations, and kid’s braces. Remember, in waterfall, there was no benefit until the end of the project. You couldn’t realize any benefit from a project until it was complete: not revenue, not capitalization, not any effect on what customers saw. Nothing. When you use agile, you have options if you can release early. Remember the potential for release frequency? If you can do continuous deployment or even release something more often, you can realize the benefits of the project before the end. If you are agile, you don’t need to estimate a lot to tell them when they can first receive value from your work....

Agile Misconceptions: There Is One Right Approach

I have an article up on agileconnection.com called Common Misconceptions about Agile: There Is Only One Approach. If you read my Design Your Agile Project series, you know I am a fan of determining what approach works when for your organization or project. Please leave comments over there. Thanks! Two notes: If you would like to write an article for agileconnection.com, I’m the technical editor. Send me your article and we can go from there. If you would like more common-sense approaches to agile, sign up for the Influential Agile Leader. We’re leading it in San Francisco and London this year. Early bird pricing ends...

What Development & Test Managers do in Agile Organizations

Is there room for functional managers, such as development and test managers, in agile organizations? Maybe. It depends on whether they take the role of an agile manager. If you have organized as a feature teams-based organization, the functional managers (development, test, analysis, whatever) can take these responsibilities: Develop trusting relationships with the people on the project team, and in their function. Provide coaching and mentoring opportunities for people. Provide communities of practice for the people. Remove obstacles for the people and team. Start and nurture the hiring effort whenever you need to hire new people. Help people with career development. Provide feedback to people, and help people learn how to provide feedback (meta-feedback). Provide coaching and meta-coaching when people want it. Help the organization understand its capacity and make decisions about the project portfolio. Help influence the rest of the organization with the agile culture. Functional managers are champions for the team, and shepherds for the process. They are servant leaders. Here’s what functional managers do not do: Have status conversations. If the team is agile, the team understands its status. If you need help seeing their board, that’s a problem the team needs to solve. If they need help seeing their status, they need to change their board or their process for updating each other. Move people on or off teams, once you or the team establishes itself. Ask people to do something the team has not committed to, or that the product owner has not added to the kanban board. That’s right. “Your” team doesn’t work for you; the team works for the product owner. Micromanage any...