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: 2 hours 58 min ago

The Product Roadmap is Not the Project Portfolio

Wed, 08/26/2015 - 14:38

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.

Teamsandvalue

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 are complete, the product owner team can replan for this product and the project portfolio team can replan for the organization. Everyone wins.

That’s why the product owner team is not the project portfolio team. (In small organizations, it’s possible people have multiple roles. If so, which hat are they wearing to make this decision?

The product roadmap is not the project portfolio. Yes, you may well use the same ranking approaches. The product roadmap optimizes for this product. The project portfolio team optimizes for the overall organization. They fulfill different needs. Please do not confuse the two decisions.

Categories: Project Management

My Agile 2015 Roundup

Mon, 08/24/2015 - 14:06

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.

 

Categories: Project Management

How to Use Continuous Planning

Mon, 08/17/2015 - 16:17

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:

  1. 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.
  2. A person who is not yet registered can create a new id and password.
  3. After the person creates a new id and password, that person can log in. You might think of the database schema now. You might not want the entire schema yet. You might want to wait until you see all the negative stories/features. (I’m still thinking flat file here.)
  4. Now, you might add the “parse-all-possible-names” for login. You would refactor Story #2 to use a parser, not copy names and emails into a flat file. You know enough now about what the inputs to your database are, so you can implement the parser.
  5. You want to check for people that you don’t want to log in. These are three different small stories. You might need a spike to consider which stories you want to do when, or do some investigation.
    • Are they from particular IP addresses (web) or physical locations?
    • Do you need all users to¬†follow a specific name format?
    • Do you want to use a captcha (web) or some other robot-prevention device for login (three tries, etc.)?

Maybe you have more stories here. I am at the limit of what I know for secure login. Those of you who implement secure login might think I am past my limit.

These five plus stories are a feature set for secure login. You might not need more than stories 1, 2, and 3 the first time you touch this feature set. That’s fine. You have the other stories waiting in the product backlog.

If you are a product owner, you look at the relative value of each feature against each other feature. Maybe you need this team to do these three first stories and then start some revenue stories. Maybe the Accounting team needs help on their backlog, and this feature team can help. Maybe the core-of-the-product team needs help. If you have some kind of login, that’s good enough for now. Maybe it’s not good enough for an external release. It’s good enough for an internal release.

Your ability to change what feature teams do every so often is part of the value of agile and lean product ownership—which helps a program get to done faster.

You might have an initial one-quarter backlog that might look like this:

Example.AgileRoadmapOneQuarter

Start at the top and left.

You see the internal releases across the top. You see the feature sets across just under the internal releases. This part is still a wish list.

Under the feature sets are the actual stories in the details. Note how the POs can change what each team does, to create a working skeleton.

The details are in the stories at the bottom.

This is my picture.You might want something different from this.

The idea is to create a Minimum Viable Product for each demo and to continue to improve the walking skeleton as the project teams continue to create the product.

Because you have release criteria for the product as a whole, you can ask as the teams demo, “What do we have to do to accomplish our release criteria?” That question allows and helps you replan for the next iteration (or set of stories in the kanban).¬†Teams can see interdependencies because their stories are small. They can ask each other, “Hey can you do the file transfer first, before you start to work on the Engine?”

The teams work with their product owners. The product owners (product owner team) work together to develop and replan the next iteration’s plan which leads to replanning the quarter’s plan. You have continuous planning.

You don’t need a big meeting. The feature team small-world networks help the teams see what they need, in the small. The product owner team small-world network helps the product owners see what they need for the product over the short-term and the slightly longer term. The product manager can meet with the product owner team at least once a quarter to revise the big picture product roadmap.

You can do this if the teams have small stories, if they pay attention to technical excellence and use continuous integration.

In a program, you want smallness to go big. Small stories lead to more frequent internal releases (every day is great, at least once a month). More frequent internal releases lead to everyone seeing progress, which helps people accomplish their work.

You don’t need a big planning meeting. You do need product owners who understand the product and work with the teams all the time.

The next post will be about whether you want resilience or prediction in your project/program. Later :-)

Categories: Project Management

Reasons for Continuous Planning

Mon, 08/10/2015 - 17:58

I’m working on the program management book, specifically on the release planning chapter. One of the problems I see in programs is that the organization/senior management/product manager wants a “commitment” for an entire quarter. Since they think in quarter-long roadmaps, that’s not unreasonable—from their perspective.

AgileRoadmapOneQuarter.copyright-300x223There is a problem with commitments and the need for planning for an entire quarter. This is legacy (waterfall) thinking. Committing is not what the company actually wants. Delivery is what the company wants. The more often you deliver, the more often you can change.

That means changing how often you release and replan.

Consider these challenges for a one-quarter commitment:

  1. Even if you have small stories, you might not be able to estimate perfectly. You might finish something in less time than you had planned. Do you want to take advantage of schedule advances?
  2. In the case of too-large stories, where you can’t easily provide a good estimate, (where you need a percent confidence or some other mechanism to explain risk,) you are (in my experience) likely to under-estimate.
  3. What if something changes mid-quarter, and you want more options or a change in what the feature teams can deliver? Do you want to wait until the end of a quarter to change the program’s direction?

If you “commit” on a shorter cadence, you can manage these problems. (I prefer the term replan.)

If you consider a no-more-than-one-monthly-duration “commit,” you can see the product evolve, provide feedback across the program, and change what you do at every month milestone. That’s better.

Here’s a novel idea: Don’t commit to anything at all. Use continuous planning.

AgileRoadmapOneQuarter.copyright-1080x804

If you look at the one-quarter roadmap, you can see I show  three iterations worth of stories as MVPs. In my experience, that is at least one iteration too much look-ahead knowledge. I know very few teams who can see six weeks out. I know many teams who can see to the next iteration. I know a few teams who can see two iterations.

What does that mean for planning?

Do continuous planning with short stories. You can keep the 6-quarter roadmap. That’s fine. The roadmap is a wish list. Don’t commit to a one-quarter roadmap. If you need a commitment, commit to one iteration at a time. Or, in flow/kanban, commit to one story at a time.

That will encourage everyone to:

  1. Think small. Small stories, short iterations, asking every team to manage their WIP (work in progress) will help the entire program maintain momentum.
  2. See interdependencies. The smaller the features, the clearer the interdependencies are.
  3. Plan smaller things and plan for less time so you can reduce the planning load for the program. (I bet your planning for one iteration or two is much better and takes much less time than your one-quarter planning.)
  4. Use deliverable planning (“do these features”) in a rolling wave (continue to replan as teams deliver).

These ideas will help you see value more often in your program. When you release often and replan, you build trust¬†as a program. Your managers might stop asking for “commits.”

If you keep the planning small, you don’t need to gather everyone in one big room once a quarter for release planning. If you do continuous planning, you might never need everyone in one room for planning. You might want everyone in one room for a kickoff or to help people see who is working on the program. That’s different than a big planning session, where people plan instead of deliver value.

If you are managing a program, what would it take for you to do continuous planning? What impediments can you see? What risks would you have planning this way?

Oh, and if you are on your way to agile and you use release trains, remember that the release train commits to a date, not scope and date.

Consider planning and replanning every week or two. What would it take for your program to do that?

Categories: Project Management

Who Should be Your Product Owner?

Tue, 08/04/2015 - 13:01

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 manager is your product owner? The product development team doesn’t have enough time with the product owner. Maybe the team doesn’t understand the backlog, or the release criteria, or even something about a specific story.

Sometimes, functional managers become product owners. They have the domain expertise and the ability to create a backlog and to work with the product manager when that person is available. Is this a good idea?

If the manager is not the PO for his/her team, it’s okay. I wonder how a manager can build relationships with people in his/her team and manage the problems and remove impediments that the team needs. Maybe the manager doesn’t need to manage so much and can be a PO. Maybe the product ownership job isn’t too difficult. I’m skeptical, but it could happen.

There is a real problem when a team’s manager is also the product owner. People are less likely to have a discussion and disagree with their managers, especially if the organization hasn’t moved to team compensation. In¬†Weird Ideas That Work: How to Build a Creative Company,¬†Sutton discusses the issue of how and when people feel comfortable challenging their managers.¬†

Many people do not feel comfortable challenging their managers. At all.

We want the PO and the team to be able to have that give-and-take about ranking, value, when it makes sense to do what. The PO makes the decision, and with information from the team, can take all the value into account. The PO might hear, “We can implement this feature first, and then this other feature is much easier.” Or, “If we fix these defects now, we can make these features much easier.” You want those conversations. The PO might say, “No, I want the original order” and the team will do it. The conversations are critical.

If you are a manager, considering being a PO for your team, reconsider. Your organization may have too many managers and not enough POs. That’s a problem to fix. Don’t make it difficult for your team to have honest discussions with you. Make it possible for people with the best interests of the product to have real discussions without being worried about their jobs.

(If you are struggling with the PO role, consider my Product Owner Training for Agencies. It starts next week.)

Categories: Project Management

Embracing the Zen of Program Management

Thu, 07/30/2015 - 13:47

The lovely folks at Thoughtworks interviewed me for a blog post, Embracing the Zen of Program Management.  I hope you like the information there.

 Scaling Collaboration Across the OrganizationIf you want to know about agile and lean program management, see Agile and Lean Program Management: Scaling Collaboration Across the Organization. In beta now.

Categories: Project Management

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