Warning: Table './devblogsdb/cache_page' is marked as crashed and last (automatic?) repair failed query: SELECT data, created, headers, expire, serialized FROM cache_page WHERE cid = 'http://www.softdevblogs.com/?q=aggregator/sources/19' in /home/content/O/c/n/Ocnarfparking9/html/softdevblogs/includes/database.mysql.inc on line 135

Warning: Cannot modify header information - headers already sent by (output started at /home/content/O/c/n/Ocnarfparking9/html/softdevblogs/includes/database.mysql.inc:135) in /home/content/O/c/n/Ocnarfparking9/html/softdevblogs/includes/bootstrap.inc on line 729

Warning: Cannot modify header information - headers already sent by (output started at /home/content/O/c/n/Ocnarfparking9/html/softdevblogs/includes/database.mysql.inc:135) in /home/content/O/c/n/Ocnarfparking9/html/softdevblogs/includes/bootstrap.inc on line 730

Warning: Cannot modify header information - headers already sent by (output started at /home/content/O/c/n/Ocnarfparking9/html/softdevblogs/includes/database.mysql.inc:135) in /home/content/O/c/n/Ocnarfparking9/html/softdevblogs/includes/bootstrap.inc on line 731

Warning: Cannot modify header information - headers already sent by (output started at /home/content/O/c/n/Ocnarfparking9/html/softdevblogs/includes/database.mysql.inc:135) in /home/content/O/c/n/Ocnarfparking9/html/softdevblogs/includes/bootstrap.inc on line 732
Software Development Blogs: Programming, Software Testing, Agile, Project Management
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
warning: Cannot modify header information - headers already sent by (output started at /home/content/O/c/n/Ocnarfparking9/html/softdevblogs/includes/database.mysql.inc:135) in /home/content/O/c/n/Ocnarfparking9/html/softdevblogs/includes/common.inc on line 153.
Syndicate content
Expert in Managing Product Development
Updated: 1 hour 36 min ago

How Long Are Your Iterations? Part 1

Thu, 11/19/2015 - 16:08

I spoke with a Scrum Master the other day. He was concerned that the team didn’t finish their work in one 2-week iteration. He was thinking of making the iterations three weeks.

I asked what happened in each iteration. Who wrote the stories and when, when did the developers finish what, and when did the testers finish what? Who (automated tests, testers or customers) reported defects post-iteration?

He is the Scrum Master for three teams, each of whom has a different problem. (The fact that he SMs for more than one team is a problem I’ll address later.)

Team 1 has 6 developers and 2 testers. The Product Owner is remote. The PO generates stories for the team in advance of the iteration. The PO explains the stories in the Sprint Planning meeting. They schedule the planning meeting for 2 hours, and they almost always need 3 hours.

Staggered_dev_testingThe developers and testers work in a staggered iteration. Because the developers finish their work in the first two-week iteration, they call their iterations two weeks. Even though the testers start their testing in that iteration, the testers don’t finish.

I explained that this iteration duration was at least three weeks. I asked if the testers ever got behind in their testing.

“Oh, yes,” he replied. “They almost always get behind. These days, it takes them almost two weeks to catch up to the developers.”

I explained that the duration that includes development and testing is the duration that counts. Not the first two weeks, but the total time it takes from the start of development to the end of testing.

“Oooh.” He hadn’t realized that.

He also had not realized that they are taking too much work (here, work in progress, WIP). The fact that they need more time to discuss stories in their planning meeting? A lot of WIP. The fact that the developers finish first? That creates WIP for the testers.

Sequential work makes your iterations longer. What would it take for you to work as a team on stories and reduce the lag time between the time the development is done and the testing is done?

The next post will be about when you have a longer duration based on interdependencies.

Categories: Project Management

Creating Great Estimates as a Team

Mon, 11/16/2015 - 15:18

I’ve been teaching workshops these last few weeks.¬†A number of the participants think that they need to create great estimates. I keep hearing, “I have to create accurate estimates. My team needs my estimate to be accurate.”

I have found that the smaller the work, the better the estimate. If people work as a team, they can provide more accurate estimates than they can alone. And, if they work as a team, the more likely they are to meet the estimate.

The people in my workshops did not want to hear this. Many of them wanted to know how to create an estimate for “their” work, accounting for multitasking.

I don’t know how to create great estimates when people assume they work alone, or if they multitask.

In all of my experience, software is a team activity (especially if you want to use agile or lean). For me, creating an estimate of “my” work is irrelevant. The feature isn’t done until it’s all done.

When we create solo estimates, we reinforce the idea that we work alone. We can work alone. I have discovered I have different ideas when I pair. That’s one of the reasons I ask for review, if I am not actively pairing. I have also discovered that I find problems earlier when I pair or ask for frequent review. That changes my overall estimate.

Multitasking creates context switching, with built-in delays. (See¬†Cost of Delay Due to Multitasking, Part 2¬†or Diving for Hidden Treasures.) I don’t know how to account for the context-switch times. For me, the context-switching time varies, and depends on how many switches I need to do.

PredictingUnpredictable-smallIf you want to create great estimates, estimate as a team. For hints, see Predicting the Unpredictable: Pragmatic Approaches to Estimating Project Cost or Schedule.

I urge you to make the thing you estimate small, you consider how you work with other people to deliver this thing, and you do one chunk of work at a time. All of those ideas will help you create better estimates. Not for “your” work, but for the work you deliver to your customer.

Categories: Project Management

People: Resilience Creators, Not Resources

Mon, 11/02/2015 - 13:38

I’ve been traveling, teaching, speaking and consulting all over the world. I keep encountering managers who talk about the “resources.” They mean people, and they say “resources.”

That makes me nuts. I blogged about that in¬†People Are Not Resources. (I have other posts about this, too, but that’s a good one.)

I finally determined what we might call people. People are “resilience creators.” They are able to recognize challenges, concerns, or problems, and adjust their behavior.

People solve problems so the project can continue and deliver the product.

People fix problems so that customer support or sales can make the user experience useful.

People deliver products and/or services (or support the people who do) so that the company can continue to employ other people, deliver the company’s work, and acquire/retain customers.

We want resilient companies (and projects and environments). When we encounter a hiccup (or worse) we want the work to continue. Maybe not in the way it did before. Maybe we need to change something about what we do or how we do it. That’s fine. You hired great people, right?

People can solve problems so that the company can be resilient. To me, that means that the people are resilience creators, not “resources.”

People create resilience when they have the ability to solve problems because you asked them for results.

People create resilience when they understand the goals of the work.

People create resilience when they have the ability to work together, in a holistic way, not in competition with each other.

What would you rather have in your organization: resources or resilience creators?

Categories: Project Management

Agile in Large Enterprises Panel

Mon, 10/12/2015 - 15:17

A couple of weeks ago, I had a great time participating in the Agile in Large Enterprises panel, a part of the Continuous Discussions (#c9d9) that Electric Cloud hosts.

Here’s the recording:

We discussed these questions:

  • Why agile in large enterprises and what are the challenges?
  • Where should you start?
  • Centralized? Decentralized? Where should agile live?
  • What is the one thing enterprises should do?

I had a number comments, which you should watch to see the entire context:

  • Agile requires cultural change.
  • Start with the people who want to change.
  • Agile should “live” everywhere.
  • Automate everything. And, retrospect to learn from what you have done and what you could do.

I had a terrific time along with my fellow panelists.

Categories: Project Management

Resource Efficiency vs. Flow Efficiency, Part 5: How Flow Changes Everything

Sun, 09/20/2015 - 22:15

The discussion to now:


When you move from resource efficiency (experts and handoffs from expert to expert) to flow efficiency (team works together to finish work), everything changes.


FlowEfficiencyThe system of work changes from the need for experts to shared expertise.

The time that people spend multitasking should decrease or go to zero because the team works together to finish features. The team will recognize when they are done—really done—with a feature. You don’t have the “It’s all done except for…” problem.

Managers don’t need to manage performance. They manage the system, the environment that makes it possible for people to perform their best. Managers help equip teams to manage their own performance.

The team is accountable, not a person. That increases the likelihood that the team will estimate well and that the team delivers what they promised.

If you are transitioning to agile, and you have not seen these things occur, perform a retrospective. Set aside at least two hours and understand your particular challenges. I like Agile Retrospectives: Making Good Teams Great, Getting Value out of Agile Retrospectives РA Toolbox of Retrospective Exercises, and The Retrospective Handbook: A Guide for Agile Teams for creating a retrospective that will work for you. You have unique challenges. Learn about them so you can address them.

I hope you enjoyed this series. Let me know if you have questions or comments.

Categories: Project Management

Resource Efficiency vs. Flow Efficiency, Part 4: Defining Accountability

Sun, 09/20/2015 - 21:46

This is the next in a series of posts about resource efficiency vs. flow efficiency:

Managers new to agile often ask, “How do I know people will be accountable?” Let’s tease apart the pieces of accountability:

  • Accountable to the project for finishing their own work
  • Accountable to their team for participating fully by doing their work
  • Accountable to help other people learn what they did by documenting their work
  • Accountable for meeting their estimates
  • Accountable for how the project spends money
  • … There might be more accountabilities

Let’s take¬†the first two together:

Accountable for finishing their own work and by doing their work

I suspect that managers mean, “How do I know each person does their work? How do I know they aren’t asking other people to do their work? How do I know these people are learning to do their own work?”

Those are good questions. I have yet to see a single-person feature. At the least, a developer needs someone to test their work. Yes, it’s possible to test your own work. Some of you are quite good at that, I bet.¬†Many people are not. If you want to prevent rework, build in checking in some form or another: pairing, design review, code review, unit tests, system tests, something.

So the part about “own work” seems a little micro-managing to me.

The part about doing their work is a little trickier. When people get stuck, what do they do? Often, they ask someone else for help. The help might be: talk to the duck, an explanation about what is going on in that area of the product, pairing on solving the problem, or even talking to more people.

There is no such thing as “cheating” at work. Managers are right to be concerned that people work to their capabilities. And, if those people are stuck, I don’t want them mired in the problem. We want people to learn, not be stuck.

Here’s the answer: You can’t know as a manager. You never did know as a manager.

The team knows who is hardworking and who slacks. The team knows how people are learning and if they are stuck. Even in waterfall days, the team knew. Managers may have had the illusion they knew, but they didn’t. Managers only knew what people told them.

Accountable for documentation

For me, the question is who will use the documentation? I am always amazed at how many managers want documentation other than end-user documentation and how few teams find this useful. In agile, you could make it part of the definition of done.

If people build documentation time into their estimates and the team finds the internal documentation useful, the team will pressure each person to deliver their documentation. The team knows whether the person documents their work.

Accountable for living up to estimates

When I ask managers if they want good estimates or completed features, they almost always say, “completed features.” Too often, the people multitask on fixing defects or production support work while they are supposed to work on a feature. I do understand the need for estimates, but holding people to their estimates? Sometimes, that’s about money.

Accountable for how the project spends money

Of all the accountabilities, this one makes the most sense to me. However, it doesn’t make sense in agile, where the customer/product owner is the one responsible. As long as the team completes features, the PO determines when either there is no more value in the backlog, or there is no more money for the project. With any luck, the team has met the release criteria by this time.

For me, the idea of accountability is a team-based idea, not a person-based idea. In flow efficiency, you can ask the team to be accountable for:

  • Finishing features
  • Knowing where they are with respect to the features in progress
  • Helping the PO understand the value of features and how long features will take
  • Providing an estimate, if necessary
  • If the team works in iterations, committing to work and not overcommitting to too much work

When you look at accountability like this, it looks pretty different than a single person’s accountability.

Part 5 is the summary post for this series.

Categories: Project Management

Resource Efficiency vs. Flow Efficiency, Part 3: Managing Performance

Sun, 09/13/2015 - 20:54

Resource Efficiency vs. Flow Efficiency, Part 1: Seeing Your System¬†explains resource efficiency and flow efficiency. Resource Efficiency vs. Flow Efficiency, Part 2: Effect on People explains why flow efficiency helps you get features done faster. Here, in part 3, I’ll address the performance management question.

New-to-agile (and some experienced) managers ask, “How can I manage performance? How will I know people are accountable for their work?”

These are good questions. Performance management and accountability are two different things in flow efficiency.

Here are some ways to manage performance:

  • Ask for the results you want.
  • Ask the team to work together to produce features.
  • Create communities of practice to help people learn their craftsmanship.
  • Provide the team members with the knowledge of how to provide feedback and coaching to each other.
  • As a manager, you provide meta-coaching and meta-feedback to team members. (The team members provide each other feedback and coaching, managing their daily performance.) (See also Four Tips for Managing Performance in Agile Teams.)

If you do these things, you will discover that people are accountable to each other for their work. The point of a standup is to help people vocalize their accountabilities. If the team works as a swarm or as multiple pairs/triads/whatever, they might not need a standup. They might need a kanban board with WIP (work in progress) limits. If your organization likes iterations because it provides boundaries for decision-making or providing focus, that works. It can work with or without a kanban board.

Here’s a question I like to ask managers, “Have you hired responsible adults?” The managers almost always say, “Yes.” They look at me as if I am nuts. I then ask, “Is there a reason for you to not trust them?”

Now we get to the real issues. If the managers have encouraged/enforced resource efficiency, the people often multitask. Or, they have to wait for other people to finish their work. People have a difficult time finishing their work “on time.” Managing “performance” is a function of the system.¬†The system of resource efficiency requires someone to check up on people, because the expertise bottlenecks can become severe.

Instead, if you manage the system by focusing on what you want—features—instead of tasks, you don’t have to do much performance management. Will you make a mistake and hire someone who doesn’t fit? Maybe. The team can tell you.

What if you hire a superstar? Maybe you’re worried that person won’t have enough to do. My experience is that the team will ask the so-called superstar to help them with other things, making her even more of a superstar. In addition, this superstar can help with everyone learning more.

If you don’t rub people’s noses in the fact that someone might be “better” than they are, they will use that person well. Yes, sometimes, I was the person who learned from the superstar. Sometimes I was the superstar. I never noticed. I noticed I got better when I worked with certain people and asked to work with them more often.

Think about what makes people happy at work. Once you take money off the table by paying people enough, it’s all about mastery, autonomy, and purpose.

As managers, you create the system to provide mastery, autonomy, and purpose. You don’t have to manage what people do all day. If you think you do, why would you want to use agile?

BTW, managing for results isn’t new. Peter Drucker first published Managing for Results in 1964.

In part 4, I’ll address accountability and what it could mean in flow efficiency as opposed to resource efficiency.

Categories: Project Management

Resource Efficiency vs. Flow Efficiency, Part 2: Effect on People

Sun, 09/13/2015 - 20:39

If you haven’t read Resource Efficiency vs. Flow Efficiency, Part 1: Seeing the System, ¬†I explain there about optimizing for a given person’s work vs. optimizing for features. Some people (including managers) new to agile have questions about working in flow vs. optimizing for a person.

The managers ask:

  • How do I know the work won’t take longer if we move to flow efficiency?
  • How do I do performance management if a single person isn’t responsible for his/her work? (What’s the accountability, etc.?)

This post is about the length of the work and how people feel when they can’t finish work.

When you have experts, as in resource efficiency, the work queues up behind the expert. Let’s say you have three senior people with these separate expertise areas:

  • Cindy has deep knowledge of the internals of the database and how to make things fast. (I think of this as the platform.)
  • Brian has deep knowledge of the transaction layer and how to move data from one place to another in the product. (I think of this as the middleware.)
  • Abe has deep knowledge of how to present data to the customers and how to create a great customer experience. (I think of this as the UI layer.)

You want Features 1 and 2, which have significant UI impact. Abe is a master at iterating with all the necessary people to get the UI just right. In the meantime, Cindy and Brian go on to Features 3, 4, and 5 because they aren’t needed (yet) on Features 1 and 2.

If you measured cumulative flow, you would see that all five features are open for a while, because these three people have started on them and not finished anything.

Abe encounters a problem with the UI. The customer doesn’t respond or the product management people are not available. Something impedes his progress. So, he starts Feature 9, which is the next feature with significant UI design.

Notice that he doesn’t start the next ranked feature. He starts the next one he can work on.

Cindy and Brian also encounter delays because the test automation isn’t there, or the build takes too long (or something). Choose whatever happened to you last week as an impediment.

They need to stay busy, so they see that Feature 6 needs them both. They start on it. They realize there is a need for UI work. They ask Abe if he is available. No, Abe is working on Feature 9, not Feature 6. Now, Cindy and Brian have another feature in progress.

If this sounds like your project, you are not alone. This is a result of resource efficiency.

The human effect of resource efficiency is multitasking, a feeling of impending pressure because you can see the deadline but you’re not getting closer. You wonder if you will ever finish the work.

Instead, imagine if Cindy, Brian, and Abe along with a tester took Feature 1. They might prepare their platform and middleware parts of the work. They might help Brian with the prototype generation and iteration. They might be able to bang on doors if Abe needs to concentrate on something specific. “I’ll be done with this in a couple of hours. Can you reserve a conference room and ask the product manager to be there? She always gives me a hard time on the UI. I want to know what she thinks of it now.” Or, “Can you call Customer A and get ready for a walkthrough in a couple of hours?”

You might think of this reserve-a-room or call-people work as something a project manager should do. In reality, these actions are servant leadership actions. Anyone can do them.

We often have lead-time for some parts of development. Even if we want to work in flow, we might need other people to finish.

Even if Cindy and Brian can’t directly help with the UI, they can make it easier for Abe to succeed. And, if the tester¬†is involved at the beginning, the tester can create automated tests that don’t depend on the GUI. Maybe the developers not working on product code can help with an automated test framework. (I find that testers new to data-driven ¬†or automated testing don’t always know how to start. Developers might be able to help.)

Imagine if Cindy, Brian, and Abe are not the only people on their team. They are the most senior, and there are two or three other developers on the team. What happens when those more junior developers have a question? Cindy, Abe, and Brian have to stop working on their stories to work with the other people. Or, maybe they don’t and the other people are stuck. I see this in teams all the time. I bet you do, too.

When we optimize for resource efficiency, we have people with unfinished, open work. The more work they have not done, the more they have new work queuing up behind them. They work hard all day and don’t feel as if they accomplish anything, because nothing gets to done.

When we optimize for flow efficiency, people finish things, together. They have less work in progress. They feel a sense of accomplishment because they can point to what they have completed.

I can’t guarantee a team can finish faster in flow because I am not an academic. However, you’ve heard, “Many hands make light work.” That’s the idea. When we help each other move a chunk of work to done, we all succeed faster.

Part 3 will talk about what managers perceive as performance management.

Categories: Project Management

Resource Efficiency vs. Flow Efficiency, Part 1: Seeing Your System

Sun, 09/13/2015 - 20:22

I’ve been working with a number of people who want to work in a more agile way. These nice folks have one stumbling block: resource efficiency vs. flow efficiency. This is partly because of how they see the system of work.

If you ever used phases or a waterfall approach, you might have tried to optimize resource efficiency:

ResourceEfficiency In this image, you see that the work flows from one person to another. What this picture does not show is the fact that there are delays in the workflow.

Each person is a specialist. That means they—and only they—can do their work. The more senior and the more specialized they are, the more they need to do the work and the less capable other people are (for that work). Think of a UI designer or a database admin. I often see teams who don’t have those necessary-for-them roles.

With resource efficiency, you optimize for each person along the way. You get the feature when you get it. Each person is “fully utilized.” This leads to a cost of delay. (See Diving for Hidden Treasures to see more costs of delay.) It also leads to problems such as:

  • “It takes forever to bring people up to speed around here.”
  • “Only Fred can work on that. He’s the only one who knows that code (or whatever).
  • “You can’t take a vacation. That’s just before we want to ship and you’re the only one who knows that part of the product.”
  • Many features are partly done and too few are complete. (The work in progress is quite high.

Contrast that with flow efficiency:


In flow efficiency, the team takes the feature. The team might specialize in that feature area (I see this a lot on  programs). If anyone needs to be away from work for a day or a week or two, the team can continue to do the work without that one person. Yes, the team might be a little slower, but they can still release features.

In flow efficiency, it doesn’t matter what each person “knows.” The team optimizes its work to get features done. You can see this when teams limit the backlog coming into an iteration, when they pair, swarm, or mob to finish features. If the team uses kanban and they keep to their work in progress limits, they can see flow efficiency also.

Resource efficiency is about optimizing at the level of the individual. Flow efficiency is about optimizing for the feature.

If you are transitioning to agile, ask this question, “How do we optimize for features? It doesn’t matter if we keep everyone busy. We need to release features.” This is a mindset change and can challenge many people.

Here’s why you should ask this question: Your customers buy features. They don’t buy your busy-ness.

When I tell managers about resource vs. flow efficiency, they often react, “Yes. But how do we know the features won’t take more time?” and “How will we know how to do performance management?” I’ll address that in parts 2 and 3.

Categories: Project Management

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.


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:


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.


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