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: 3 hours 41 min ago

Team Size Matters, Reprise

Thu, 04/13/2017 - 17:47

Several years ago, I wrote a post for a different blog called “Why Team Size Matters.” That post is long gone. I explained that the number of communication paths in the team does not increase linearly as the team size increases;  team communication paths square when the team increases linearly. Here is the calculation where N is the number of people on the team: Communication Paths=(N*N-N)/2. 

  • 4 people, (16-4)/2=6
  • 5 people, (25-5)/2=10
  • 6 people, (36-6)/2=15
  • 7 people, (49-7)/2=21
  • 8 people, (56-8)/2=24
  • 9 people, (81-9)/2=36
  • 10 people (100-10)/2=45

Here’s why the number of communication paths matter: we need to be able to depend on our team members to deliver. Often, that means we need to understand how they work. The more communication paths, the more the team might have trouble understanding who is doing what and when.

When team members pair, swarm, or mob, they have frequent interconnection points. By working together, they reduce the number of necessary communication paths. Maybe you can have a larger team if the team mobs. (I bet you don’t need a larger team then

Categories: Project Management

Thinking About Cadence vs. Iterations

Wed, 04/05/2017 - 16:42

Many people use an iteration approach to agile. They decide on an iteration duration, commit to work for that iteration and by definition, they are done at the end of the timebox.

I like timeboxing many things. I like timeboxing work I don’t know how to start. I find short timeboxes help me focus on the first thing of value. Back when I used staged-delivery as a way to organize projects, we had a monthly milestone (timebox) to show progress and finish features. The teams and I found that a cadence of one month was good for us. The timebox focused us and allowed us to say no to other work.

A cadence is a pulse, a rhythm for a project. In my example above, you can see I used a timebox as a cadence and as a way to focus on work. You don’t have to use timeboxes to provide a cadence.

A new reader for the Pragmatic Manager asked me about scaling their agile transformation. They are starting and a number of people are impatient to be agile already. I suggested that instead of scaling agile, they think about what each team needs for creating their own successful agile approach.

One thing many teams (but not all) is a cadence for delivery, retrospectives and more planning. Not every team needs the focus of a timebox to do that. One team I know delivers several times during the week. They plan weekly, but not the same day each week. When they’ve finished three features, they plan for the next three. It takes them about 20-30 minutes to plan. It’s not a big deal. This team retrospects every Friday morning. (I would select a different day, but they didn’t ask me.)

Notice that they have two separate cadences for planning: once a week, but not the same day; and once a week for retrospectives on the same day each week.

Contrast that with another team new to agile. They have a backlog refinement session that often takes two hours (don’t get me started) and a two-hour pre-iteration planning session. Yes, they have trouble finishing the work they commit to. (I recommended they timebox their planning to one hour each and stop planning so much. Timeboxing that work to a shorter time would force them to plan less work. They might deliver more.)

A timebox can help a team create a project cadence, a rhythm. And, the timebox can help the team see their data, as long as they measure it.

A project cadence provides a team a rhythm. Depending on what the team needs, the team might decide to use timeboxes or not.

For me, one of the big problems in scaling is that each team often needs their own unique approach. Sometimes, that doesn’t fit with what managers new to agile think. I find that when I discuss cadence and iterations and explain the (subtle) difference to people, that can help.

Categories: Project Management

Agile Leadership Newsletters Posted

Wed, 03/29/2017 - 16:43

If you only read my blog, you might not know I publish a monthly newsletter, the Pragmatic Manager. The last two issues have been on agile leadership. Take a look at Being An Agile Leader and Own Your Leadership, Part 1. Those newsletters in addition to this 5-part series culminating with Becoming an Agile Leader, Part 5: Learning to Learn may help you with your agile changes.

I wrote them so you could envision the value Influential Agile Leader might have for you. Take a look at my writing and do join us in Toronto in May. Early-bird pricing ends this week.

As always, email me if you have questions. Or, let’s have a quick chat. See Book a Meeting With Me.

Categories: Project Management

AgilePath Podcast Up

Mon, 03/27/2017 - 17:42

I’ve said before that agile is a cultural change, not merely a project management framework or approach. One of the big changes is around transparency and safety.

We need safety to experiment. We need safety to be transparent. Creating that safe environment can be difficult for everyone involved.

John LeDrew has started a new podcast, I had the pleasure of chatting with John for the podcast. He wove a story with several other interviewers and it’s now up, In search of Safety.

I hope you enjoy it.

Categories: Project Management

ProjectManagementParadise Podcast Up

Wed, 03/22/2017 - 16:51

Johnny Beirne over at projectmanagementparadise podcast interviewed me, specifically about my post, Visualize Your Work So You Can Say No. See Episode 38: “How to visualise your work so that you can say no” with Johanna Rothman.

Hope you enjoy it!

Categories: Project Management

Becoming an Agile Leader, Part 5: Learning to Learn

Mon, 03/20/2017 - 19:38

To summarize: your agile transformation is stuck. You’ve thought about your why, as in Becoming an Agile Leader, Part 1: Define Your Why. You’ve started to measure possibilities. You have an idea of who you might talk with as in Becoming an Agile Leader, Part 2: Who to Approach. You’ve considered who you need as allies and how to enlist them in Becoming an Agile Leader, Part 3: How to Create Allies. In Becoming an Agile Leader, Part 4: Determining Next Steps, you thought about creating win-wins with influence. Now, it’s time to think about how you and the people involved (or not involved!) learn.

As an agile leader, you learn in at least two ways: observing and measuring what happens in the organization. (I have any number of posts about qualitative and quantitative measurement.) Just as importantly, you learn by thinking, discussing with others, and working with others. The people in the organization learn in these ways, too.

The Satir Change Model is a great way of showing what happens when people learn. (Learning is a form of change.) Here’s the quick intro to the Change Model: We start off in Old Status Quo, what we did before. Along comes a Foreign Element, where someone introduced some kind of change into the environment. We have uneven performance until we discover our Transforming Idea. Once we have an idea that works, we can continue with Practice and Integration until we have more even performance in New Status Quo.

In the Influential Agile Leader, you have a chance to think alone with your pre-work, by discussing together such as when you draw your map in Part 1, and by working together as in coaching and influence and all the other parts of the day. One of the most important things we do is to debrief all the activities just after you finish them. That way, people have a chance to articulate what they learned and any confusions they still have.

Every person learns in their own way, at their own pace. With interactions, simulations, and some thinking time, people learn in the way they need to learn.

We don’t tell people what to do or how to think. We suggest options we’ve seen work before (in coaching). We might help supply some options for people who don’t know of alternatives. And, the participants work together. Each person’s situation is a little different. That means each person has experiences that enrich the entire room.

Learn to be an agile leader and help your agile transformation progress. Please join us at the next Influential Agile Leader, May 9-10, 2017 in Toronto.

Categories: Project Management

Becoming an Agile Leader, Part 4: Determining Next Steps

Fri, 03/17/2017 - 13:04

To summarize: your agile transformation is stuck. You’ve thought about your why, as in Becoming an Agile Leader, Part 1: Define Your Why. You’ve started to measure possibilities. You have an idea of who you might talk with as in Becoming an Agile Leader, Part 2: Who to Approach. You’ve considered who you need as allies and how to enlist them in Becoming an Agile Leader, Part 3: How to Create Allies.

Now, it’s time to think about what you will do next.

You might be thinking, “I know what to do next. I have a roadmap, I know where we want to be. What are you talking about?”

Influence. I’m talking about thinking about discovering the short-term and longer-term actions that will help your agile transformation succeed with the people who hold the keys to your transformation.

Here’s an example. Patrick (not his real name) wanted to help his organization’s agile transformation. When he came to the Influential Agile Leader, that was his goal: help the transformation. That’s one big goal. By the time we got to the influence section, he realized his goal was too big.

What did he want, right now? He was working with one team who wrote technical stories, had trouble getting to done, didn’t demo or retrospect, and wanted to increase the length of their iteration to four weeks from two weeks. He knew that was probably going in the wrong direction. (There are times when it’s okay to increase the length of the iteration. This team had so much change and push for more delivery, increasing the time was not a good option.)

He thought he had problems in the management. He did, but those weren’t the problems in the team. When he reviewed his why and his map, as in Part 1, he realized that the organization needed an agile approach for frequent delivery of customer value. If this team (and several others) could release value on a regular basis, the pressure from the customers and management would lessen. He could work with the managers on the project portfolio and other management problems. But, he was sure that the way to make this happen was to help this team deliver frequently.

He realized he had two influential people to work with: the architect and the QA lead. Both of those people looked as if they were “resisting.” In reality, the architect wanted the developers to refactor to patterns to keep the code base clean. The QA lead thought they needed plans before creating tests and was looking for the “perfect” test automation tool.

He decided that his specific goal was to “Help this team deliver value at least as often as every two weeks. Sustain that delivery over six months.” That goal—a subset of “go agile”—allowed him to work first with the architect and then with the QA lead and then both (yes, he practiced all three conversations in the workshop) to achieve his small goal.

Patrick practiced exploring the short-term and long-term deliverables in conversations in the workshop. While the conversations didn’t go precisely the same way back at work, he had enough practice to move between influence and coaching to see what he could do with the people in his context.

It took the team three more iterations to start delivering small stories, but they did. He spent time enlisting the architect in working in the team with the team members to deliver small stories that kept the code base clean. He asked the architect for help in how to work with the QA lead. The architect showed the lead how to start automation and refactor so the testers could test even before the developers had completed the code.

It took that team three more months to be able to regularly deliver value every week, without waiting for the end of the iteration.

Patrick’s original roadmap was great. And, once he started working with teams and management, he needed to adjust the deliverables he and the other coaches had originally planned. The influence conversations allowed him to see the other people’s concerns, and consider what small deliverables all along the way would help this team succeed.

Some of what he learned with this team helped the other teams. And, the other teams had different problems. He used different coaching and influence conversations with different people.

If you want to experience learning how to influence and who, in the context of helping your agile transformation continue, join us at the next Influential Agile Leader, May 9-10, 2017 in Toronto.

My next post is about our participants learn.

Categories: Project Management

Becoming an Agile Leader, Part 3: How to Create Allies

Wed, 03/15/2017 - 15:13

To summarize: your agile transformation is stuck. You’ve thought about your why, as in Becoming an Agile Leader, Part 1: Define Your Why. You’ve started to measure possibilities. You have an idea of who you might talk with as in Becoming an Agile Leader, Part 2: Who to Approach. Now, how do you create allies so you can unwedge your agile transformation?

First, here’s a big question: do you have a relationship with this person? If so, terrific. You have options as below. if you don’t have a relationship yet, it’s time to build a relationship.

Let’s assume you have some sort of relationship with this person. In that case, you might ask for coaching.

You might say, “Hey, wait a minute, Johanna. I’m the coach (or leader in some way). Why would I ask for coaching?”

When you ask for help, as in coaching, you offer your other person (often called a client) a gift. You offer explicit permission to explore options with the other person’s support. This is especially helpful if the other person is your peer or is senior to you in the hierarchy.

I know, this is turning the normal definition of coaching around. Many people think that if they are one of the agile transformation leaders , they have to have all the answers. No, you don’t. You might not know what the smallest possible change is. You might not be aware of the forces that prevent change (I’m assuming good intentions on everyone’s part). You might not know what this person might gain or lose with an agile transformation.

Asking for help is a sign of strength, not weakness. Asking for help shows transparency and a willingness to consider other options.

You might “lead” the coaching conversation by saying something like this: “Here’s what I’m seeing. We’ve done this and that and gotten these results. Do you see the same things?” If the person has different data, wow, that’s great to learn. If you have the same data, you might continue, “I’m concerned we’re stuck. I see these options to solve these problems. Do you see something else?”

When you ask for other options, you open the conversation (and your brain) to possibilities you might not have seen before.

This coaching conversation is very different from, “I’m the agile expert and I’m here to help.” You might be the agile expert. You are definitely there to help. And, you need to enter the other person’s context to understand what’s going on for that person.

You might be thinking, “Oh, this is going to take time.” Well, it will. These are one-on-one conversations. You might have to wait a week to get on someone’s calendar. And, what have you got to lose? What’s the worst thing that can happen?

If you want to experience this kind and other kinds of coaching conversations in the context of helping your agile transformation continue, join us at the next Influential Agile Leader, May 9-10, 2017 in Toronto.

My next post is about exploring how you use influence aside from coaching to achieve win-win scenarios.

Categories: Project Management

Becoming an Agile Leader, Part 2: Who to Approach

Tue, 03/14/2017 - 14:36

To summarize: your agile transformation is stuck. You’ve thought about your why, as in Becoming an Agile Leader, Part 1: Define Your Why.  You have some idea for measurements. Maybe you’ve even started to measure to capture the data.

Now, it’s time to talk to people across the organization. The question is this: Who do you talk with, to unwedge your agile transformation?

You know that the org chart is one way of seeing the system. And, there are many other ways to see your system. One way is an organizational map.

The organizational map helps you see who might have interests, pain, or power in different areas of the organization. You can then decide who and how to approach each of those people. Given their interests, you have some idea about how they might respond.

Every single time I’ve worked with people to create their organizational maps, they have learned something. Most often, they realize that someone else in a corner of the organization has key information for agile success. Sometimes, the transformation advocate realizes that another person has less or more power than we expect. Sometimes, the agile advocate realizes that if they supply some key measurements, they might be able to unlock the agile transformation.

Sometimes, people are surprised that developers or testers are the people with power and help. Sometimes, it’s people across the organization, such as someone in Finance or HR. Your transformation allies can be anywhere in your organization.

The organizational map helps you see who is helping your agile transformation, who is neutral, and who is not helping. This map, with names blacked out, is from participants at last year’s Influential Agile Leader.

In my experience, the people who are neutral or not yet helping are not “resisting change.” They are not skeptics, although they may act skeptical.  Here’s what I have found most often: they haven’t discovered the usefulness of agile to achieving their goals.

If I understand the why for agile and understand their interests, power, and pain, I have an entry into asking them what their goals are, especially if the map didn’t make that obvious.

Nurturing and maintaining an agile transformation is hard work. I like knowing who I should talk to, to make sure I’m gaining the most benefit from all of my work. I can gain allies in my measurement-gathering and in the actions I want to take for the agile transformation. I might even consider a change for how to transform the organization.

If you want to learn how to create an organizational map, join us at the next Influential Agile Leader, May 9-10, 2017 in Toronto.

My next post is about how to approach these people, especially peers and people senior to you.

Categories: Project Management

Becoming an Agile Leader, Part 1: Define Your Why

Mon, 03/13/2017 - 16:18

Your agile transformation isn’t proceeding the way you thought. People use the right agile words, but they’re not changing how they work. Teams aren’t collaborating, managers still talk about “resources,” and the projects aren’t delivering finished value. Your agile transformation is stuck.

Maybe it’s time to return to your why. Why is your organization moving to agile? Do you know?

Ask the people who wanted agile these questions:

  • What is valuable to us?
  • How will we measure what is valuable?
  • What is the first deliverable we can achieve to provide value?

When you ask these questions,  people start to remember why they wanted agile in the first place. I’ve heard answers like these:

  • We want to release something more often than once a year (or longer).
  • We want to increase the quality of our products.
  • We don’t want to hear customer complaints as often, for releasing or bug reports.
  • We want to have fun.
  • I want to master this code base.
  • I want to learn how to automate which tests.
  • I want to feel as if I’ve done a great job.

Managers often want to see revenue increases, customer happiness, and a decrease in the cost of providing customer support and project cost. Teams often want more satisfaction with their work and a feeling they have done right by the customers.

If you are an agile leader, you can develop measurements to help both sides see what they’re aiming for and how to get there. These measurements help people see why they are changing and if they are accomplishing the change—the why. But, first you have to know the why. (And, don’t be surprised if everyone has a different why!)

In my next post, I’ll address how you define who to talk to. It might not be obvious.

I’m writing this series of posts so you might consider joining us at the next Influential Agile Leader, May 9-10, 2017 in Toronto.


Categories: Project Management

Virtual Workshops Registration Open

Sun, 02/26/2017 - 18:56

I offer three online workshops for your writing and product ownership pleasure. All three are open for registration.

Any questions? Email me or post a comment. I would love to work with you.

Categories: Project Management

Highlight Risks When Reporting Defects

Fri, 02/24/2017 - 18:40

A reader asked me this question:

“How do I report on the 1000 (or so) defects in our system? I have 10 minutes on the status call.”

If you are working on a legacy application where the team was not able—for any number of reasons—to maintain technical excellence, you might have a problem like this. So many defects, so little time to discuss.

Let’s take the status-reporting problem. You could report the defect trends: number open last week, number closed and number remaining. See Figure 8 in Are We There Yet? That chart (and most of those on the page) are for the project team, not management.

When managers want to know about defect status, they actually want the answers to these questions, the impact of the defects:

  • Will this problem affect our customers’ perception of the product, enough so they would not buy or recommend this product?
  • Will this problem affect our ability to gain revenue?
  • Will this problem affect our ability to retain or attract customers?

If you can frame the problems as answers to these questions, you can provide a reasonable status in 10 minutes (or less).

Here’s how this might work in four scenarios:

Scenario 1: You have hundreds of typos, inconsistent-looking screens, and general sloppiness. You think that the team should fix all of these, and it might even take a couple of weeks to do so. You say something like this:

“We have x number of problems, none of which is a real issue by itself. However, when we take them all together, the customers appear concerned by our inconsistent look-and-feel. Can we live with this? Maybe. I am worried about customers willing to be reference accounts or even having them look for another alternative.”

Scenario 2: You have two horrible problems, and they occur rarely. The consequence of occurrence is total loss of customer data. You don’t think you should let the product near the customers with these problems, even if they are a rare occurrence. Here’s what you say:

“We have 2 big problems, aside from a number of small ones. I’m going to focus on problems 1 and 2. If a customer encounters either of these, they will lose their data. We can’t recover the data. They will be quite angry. The possible outcomes are revenue loss from these kinds of customers, and worse, possible reviews that tell other people about our problems.”

Scenario 3: You and your folks are transitioning to agile. You have build and test automation debt, as in the build takes hours and you don’t have enough test automation. You are worried that you haven’t tested enough, even though the team marked everything as done. You might try something like this:

“We have unknown risks in these areas (the places where you have insufficient test automation). Yes, we marked features in these areas as done, and we don’t know what we don’t know. Unknown risks have a habit of creating problems. (Remind them of the last time this occurred.) I recommend we release this as a beta release and spend the next two weeks working on our backlog of test automation and build time reduction so we know faster what’s really going on. That way, we don’t have a problem with customer acquisition or retention. And, we don’t have potential customer problems with data loss and therefore losing that customer.”

Scenario 4: Your team is not getting to done on features. Maybe that’s because you have staggered iterations, or your team depends on other people or teams to finish features.  In that case, you might say this:

“Although we are finishing our work, we can’t finish the features because we don’t have the necessary people integrated into our team. (Say who those people are.) I’m not blaming them—I am sure they want to finish this work, also. However, I am worried about the risk of release without the testing being done (or whatever the risk is that you see). I am worried we will lose customers and therefore revenue. I’m worried we won’t get reference accounts. I’m worried we will miss our release date and lose potential revenue.”

In each of these scenarios, you’ve done your job. You explained the impact of the problems. It’s up to your managers to decide what to do.

When you want to influence people—which is what you’re doing with a project status report—you explain how the problem affects them. You offer possibilities that you can then discuss.

If you want to learn how to do this, especially in the context of an agile transformation, please join us at the Influential Agile Leader.

Categories: Project Management

How Agile Creates and Manages WIP Limits

Thu, 02/16/2017 - 17:13

As I’m writing the agile project management book, I’m explaining how agile creates and manages WIP (Work in Progress) Limits.

Iteration-based agile manages WIP by estimating what you can do in an iteration. You might count points. Or, you use my preference, which is to count the (small) stories.

If you use flow-based approaches, you use kanban. You set WIP limits for the columns on your board.

In this image, there’s a limit of eight items in the Ready column, three in Dev and unit test, two in System test. The interesting question is how did this team decide on these limits?

This is a large-ish team. They have eight people aside from the PO: six developers and two testers. They decided to use a reasonable approximation for deciding on WIP limits:

  1. Take the number of people who work on a given column. That’s the numerator. Here, for the Dev and unit test column, it’s 6.
  2. Divide that number by 2. That gives you 3 as the WIP.

This team happens to have a policy of “No one works alone on the code,” so their approximation works well. You might have a product that requires a front-end, middleware, and back-end developer for each feature. You would have a WIP limit of 2 on the Dev and unit test column because you need three people for each feature.

Now, there are only two testers on this team. How did they get to a WIP limit of 2?

The testers do not work together. They each work independently. That means they can each work on a story. They can’t work on more than two stories at a time because they each take one story. This team agreed to work on stories until the story is done. There is no “Stuck” or “Waiting” column.

Every so often, the testers need help from the developers to complete a story. That’s because the developers didn’t realize something, or implemented something not quite right. In that case, the testers walk over to the developers and negotiate when the developer is available to help. Often, it’s right away. Yes, the developers stop what they are doing, because finishing something they thought was done is more important than starting or completing something new.

If you need a Stuck or Waiting column, you might add WIP limits to that column also. Why? Because you don’t want that column to turn into a purgatory/limbo column, where partly finished stories go and never emerge. You might call it Urgent, although I tend to reserve Urgent for support issues.

If you use iteration-based agile, and you have unfinished work at the end of the iteration, consider using a kanban board so you can see where the work in piling up. You might have a problem with “Everyone takes their own story.”  (See Board Tyranny in Iterations and Flow.)

If you have read Visualize Your Work So You Can Say No, consider adding WIP limits to your board. You might have noticed I say I don’t use WIP limits on my paper board because the paper, the size of my board, limits my work in progress.

Categories: Project Management

Why I Use a Paper Kanban Board

Fri, 02/10/2017 - 16:37

My most recent post about how to Visualize Your Work So You Can Say No showing a couple of different kanbans was quite popular. Several people ask me how I use my personal kanban.

I use paper. Here’s why I don’t use a tool:

  • I am too likely to put too much into a tool. I put all this week’s work, next week’s work, next month’s and next year’s work, even though I’m not going to think about anything that far out. Paper helps me contain my To Do list.
  • When I collaborate with others, they want to break down the stories (large as they may be) into tasks. No!! I can’t take tasks. I need to see the value. See my post about From Tasks to Stories with Value.
  • I change my board, depending on what’s going on. I often have a week-based kanban because I retrospect at the end of the week. I often—not always—have a “today” column.

This is what my board looks like this week. it might look like this for a while because I’m trying to finish a book. (I have several more books planned, so yes, I will have a bunch of work “in progress” for the next several months/rest of the year.)

I have several chapters in This Week. I have two chapters in “Today:” That helps me focus on the work I want to finish this week and today. As a technical editor for and as a shepherd for XP 2017, I have work in “Waiting to Discuss.” I will discuss other people’s writing.

Earlier this week, I had interactions with a potential client, so that work is now in Waiting for Feedback. Sometimes, I have book chapters there, if I need to discuss what the heck goes in there and doesn’t go in a chapter.

I haven’t finished much yet this week. I am quite close on two chapters, which I expect to finish today. My acceptance criteria is ready for my editor to read. I do not expect them to be done as in publishable. I’ll do that after I receive editorial feedback.

Could I do this on an electronic board? Of course.

However, I limit my WIP by staying with paper. I can’t add any more to the paper.

Should I have WIP limits? Maybe. If I worked on a project, I would definitely have WIP limits. However, the fact that I use paper limits what I can add to my board. If I notice I have work building up in any of the Waiting columns, I can ask myself: What can I do to move those puppies to Done before I take something off the Today or To Do columns?

I’ve been using personal kanban inside one-week iterations since I read Benson’s and Barry’s book, Personal Kanban. (See my book review, Book Review: Personal Kanban: Mapping Work | Navigating Life.

I recommend it for a job search. (See Manage Your Job Search and  Personal Kanban for Your Job Hunt.

You should use whatever you want as a tool. Me, I’m sticking with paper for now. I don’t measure my cycle time or lead time, which are good reasons to use an electronic board. I also don’t measure my cumulative flow, which is another reason to use a board.

I do recommend that until you know what your flow is, you use paper. And, if you realize you need to change your flow, return to paper until you really understand your flow. You don’t need a gazillion columns, which is easy to do in a tool. Use the fewest number of columns that help you achieve control over your work nad provide you the information you need.

Question for you: Do you want to see a parking lot board? I have images of these in Manage Your Project Portfolio, but you might want to see my parking lot board. Let me know.

Categories: Project Management

Visualize Your Work So You Can Say No

Thu, 02/09/2017 - 21:43

Most people I know—even the people supposedly using agile—have too much work to do. You have project work. You have support work, formal for customer support or sales, and informal for your colleagues. You have reports to write or file, time cards to fill out, or other periodic events.

You need a way to say no to more work.

I wrote an article for Better Software, which is now online. See Saying No to More Work. (You need to register for the site to see the article. No charge for registration.)

One person wanted to see the kanban boards I referred to in the article. I am happy to show them to you here.

These are two potential kanban boards. The one on the left is the basic personal kanban board. Note that there are no WIP (Work in Progress) limits (yet) on this board. I would add WIP limits. Especially if I wanted to convince my manager I was doing too much work.

On the right,  you can see a disaster of a personal kanban board. There are many items To Do, three in Progress and a total of six stuck in various Waiting states. Yes, I had a board that looked like this many years ago. Then, I made a picture on a piece of paper and explained to my boss I was just one person. What did he want me to do and not do?

Now, given what I know, I would add WIP limits to each column.

If you want to see the project portfolio images for how I start at the organization level: the calendar view and kanban view, see Manage Your Project Portfolio at the Prags. At the end of the blurb, there’s a link to the quick start guide, which has just two of the images in the book. (I included many possible ways to visualize the project portfolio in this edition of the book.)

Here’s the key idea: Don’t take on more work than you can complete in a reasonable amount of time. Don’t multitask. Instead, see what your work is and how you might discuss it with your manager.

Categories: Project Management

From Tasks to Stories with Value

Wed, 02/08/2017 - 18:06

I’m almost at the end of the January Practical Product Owner workshop. One of the participants has a problem I’ve seen before. They have a backlog of work, and it’s all tasks. Not a story in sight.

I understand how that happens. Here are some ways I’ve seen the tasks-not-stories problem occur:

  • The technical people see the work they want to accomplish. They create a list of tasks to get there: design database, create infrastructure, fix these typos in the UI, and more.
  • Or, someone (such as an architect) is in charge of breaking down work, not team members. That person creates tasks.
  • Marketing or sales (or someone not in the product development team) says something like this: “I want a drop-down menu,” or a radio button or another report. They don’t remember to explain who the value is for, or why they want that value. Pretty soon, the idea of value is gone altogether, and only tasks remain.
  • Teams start to create stories, and the stories are so large, they create tasks to cover the stories. Pretty soon, they stop creating stories at all. They only create tasks.

Here’s a gotcha: When teams measure story points as opposed to features, they often feel pressure from management to do more points. (See Who’s Playing Agile Schedule Games?)

Your customers don’t buy points. They buy completed features.

Something clicked for the participant last week. He saw the feature chart, which explains how scope expands during the project and what the team(s) delivers.

This chart shows the features complete, added, and remaining to do. Because it measures features—what customers buy and use—there’s no confusion about work done or not done. Plenty of work might be done. But, if the work doesn’t add to a feature, the work is inventory (or possibly waste).

Here’s one value of this chart: Until tasks add up to features, you don’t count them.

My participant couldn’t articulate the problems before. The chart helped him see and discuss:

  • Tasks—by themselves—might not add up to a feature. He wants features.
  • When he counts features, he can describe what’s in a feature set—a collection of features that you might call an epic or a theme.
  • He can explain why he wants just this small feature, and not necessarily all of a feature set for now.

The chart helped him see how to separate stories and count them. He is moving from tasks and technical stories to features, real user stories.

I use this chart with cumulative flow diagrams and the product backlog burnup chart to see where our work is and how much progress we make over time for a given feature set.

I recommend you build and count features (stories). The smaller you can make a story, the faster you can get feedback and see the value in it.

If you’re interested in this workshop, I have just announced the May 2017 dates. See Practical Product Owner Workshop: Deliver What Your Customers Value and Need.

Categories: Project Management

Influential Agile Leader, May 9-10, 2017

Tue, 02/07/2017 - 17:41

Is your agile transition proceeding well? Or, is it stuck in places? Maybe the teams aren’t improving. Maybe no one knows “how to get it all done.” Maybe you’re tired and don’t know how you’ll find the energy to continue. Or,  you can’t understand how to engage your management or their management in creating an agile culture?

You are the kind of person who would benefit from the Influential Agile Leader event in Toronto, May 9-10, 2017.

Gil Broza and I co-facilitate. It’s experiential, so you learn by doing. You practice your coaching and influence in the mornings. You’ll have a chance to map your organizational dynamics to see where to put your energy. You’ll split into smaller sessions in the afternoon, focusing on your specific business challenges.

If you would like to bring your agile transition to the next level, or, at the very least, unstick it, please join us.

We sold out of super early bird registration. Our early bird registration is still a steal.

If you have questions, please post a comment or email me. Hope to work with you at The Influential Agile Leader.

(See the servant leadership tag for the Pragmatic Manager  and the leadership tag on this blog to see relevant articles I’ve written before.)

Categories: Project Management

What Agile Managers Do: Podcast

Wed, 02/01/2017 - 15:39

I had a conversation with Amitai Schleier last year. I told him how much I enjoyed Agile in 3 Minutes (the podcast). I learned something from each podcast.

He invited me to contribute one. Naturally, I chose management. My podcast, 34: Manage is up. If you like the podcast, you should check out the book, too. See

If you like the podcast, you should check out the book, too. See Agile in Three Minutes. In three minutes, I explain what agile managers do.

Teams can be agile, up to a point. If the managers are not ready to nurture the agile culture, agile won’t work. (See When is Agile Wrong for You?)

I hope you enjoy it the podcast and the book.

Categories: Project Management

Thinking About PMO Productivity

Fri, 01/27/2017 - 15:15

In Manage Your Project Portfolio, I’m agnostic about who manages the project portfolio. I prefer that the managers responsible for the strategy make the project portfolio decisions. And, I recognize that the PMO often makes those decisions.

I am doing a series of webinars with TransparentChoice. The first one is live. See How many “points” does your PMO score? We spoke about how you might know if you need a project portfolio and the major measure of successful decisions:

It doesn’t matter how many projects you start. It matters how many you finish.

Hope you enjoy it!

Categories: Project Management

What’s Minimum: Thinking About Minimum Viable Experiments

Mon, 01/23/2017 - 18:12

When I talk about Minimum Viable Products or Minimum Viable Experiments, people often tell me that their minimum is several weeks (or months) long. They can’t possibly release anything without doing a ton of work.

I ask them questions, to see if they are talking about a Minimum Indispensable Feature Set or a Minimum Adoptable Feature Set instead of an MVE or an MVP. Often, they are.

Yes, it’s possible you need a number of stories to create an entire feature set before you release it to your entire customer base. And, that’s not an MVP or an MVE.

Do you know about Eric Ries’ Build-Measure-Learn loop? Or the Cynefin idea of small, safe-to-fail experiments? Here’s the thinking behind both of those ideas:

  • You have ideas you could implement in your product. If you are like my clients, you have more ideas than you could implement ever. This is a good thing!
  • You Build an idea for one product.
  • You Measure the result with data.
  • You Learn from that data to generate/reduce/change your ideas.
  • Do it again until you’ve learned enough.

When I think about the Build-Measure-Learn loop and apply it to the idea of a Minimum Viable Experiment, I often discover these possibilities:

  1. We have an MVE now. We need to define how to measure it and use the data.
  2. We don’t have to do much to collect some data.
  3. We can ask this question: What do we want to know and why? What is the benefit of gathering that data?

Here’s an example of how this affected a recent client. They have an embedded system. They thought that if the embedded part booted faster, they could find more applications for the system. In embedded software, speed is often a factor.

They chose one client, who had systems now. The Product Manager visited the client and asked about other vertical applications within the organization. Did they have a need for something like this system?

Yes, they did. They were concerned about speed, not just boot speed, but application processing speed.

The Product Manager asked if they were willing to be part of an MVE. He explained that the team would watch how they implemented and used the embedded system. Yes, they would all sign non-disclosures. The client also had to know that the team might not actually implement for real what the experiment was.

The customer agreed. The team implemented four very small performance enhancements—only through the happy paths, no alternative/error paths—and visited the customer to see what would happen. It took the team three days to do this.

The team visited for one day to watch how the client’s engineers used the product.

They were astounded. Boot speed was irrelevant. One specific path through the processing was highly relevant. The other three were irrelevant for this specific customer.

This particular MVE was a little on the expensive side. It took a team-week to develop, measure, and learn. There was some paperwork that both sides had to manage. If you have a different kind of product, it might take you less time.

And, look how inexpensive that week was. That week taught the team what one vertical product line needed and didn’t need. They managed to avoid all those “necessary” features. This client didn’t need them. It turned out a different kind of vertical needed two of them, and no one appears to need the remaining one.

The Product Manager was able to prune many of the ideas in the backlog for this vertical market. The Product Owner knew and (knew why) which features were more important and how to write stories and rank them.

That’s one example of an MVE. Your experiments will probably look different. What’s key here is this question: What is the smallest thing you can measure that will provide you value so you can make a decision for the product?

Categories: Project Management