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!

Project Management

Six Times Two Plus One Equals a Good Project Cadence

Mike Cohn's Blog - Thu, 02/20/2014 - 15:00

In last month's newsletter I wrote about the idea that everything happens within a sprint. There is no "outside a sprint" during which team members might do things like design, bug fixing, or anything else. In this newsletter I want to share one possible exception to that. 

Something I've been doing for years is called 6x2+1. This stands for six two-week sprints followed by a one-week sprint. The idea for this came about many years ago when I was a VP of Software Development and in a meeting with the company's CEO and VP of Marketing.

We were discussing the coming quarter and what functionality my teams could deliver. The VP of Marketing asked me if we would have six or seven sprints in the coming quarter. He knew with two-week sprints we always finished six or seven sprints depending on when the quarter started.

To answer his question I started counting the sprints by thinking about the ending Friday of each: October 8, October 22, November 5, November 19, I counted. Then I had to figure out if November had 30 or 31 days. As I named each month on my knuckles, I decided from that point on each quarter would have exactly six sprints.

But six two-week sprints left me an extra week in the quarter. What to do with it? I decided I'd let the teams have that week to do whatever they want. Teams had been clamoring for more time to work on refactoring or any technically oriented thing they wanted but couldn't quite convince their product owners of. This would allow them one week each quarter in which to do whatever they wanted.

Selling the idea to product owners wasn't hard. I told them the team would still be adding value to their products during those weeks, it was just the teams would decide what was most valuable. To really sell the idea to product owners, I let them know one week per quarter the teams wouldn't need them as much, freeing them up for the bigger picture thinking and research the product owners had said they needed.

This was brilliant. I told the teams I was doing this for them. I told the product owners I was doing it for them. I was really doing it at first to get myself out of having to do date math on the fly.

There was one further benefit: This also gave each project one week per quarter that wasn't typically part of the plan when considering release dates. Whenever a project got into trouble and couldn't meet a planned date, we could use the thirteenth week as part of any normal sprint. We'd then give the team the seventeenth week, or any other later week.

Teams didn't care if they got the thirteenth or seventeenth week. They did care that they got a week sometime about once a quarter or so and very much looked forward to "their week."

Tying this back to last month's newsletter: Some of the teams with which I've done this 6x2+1 approach will treat the thirteenth week as outside of any sprint. Most teams will continue running Scrum for that one week. They'll do very simple planning and review meetings. Most will even conduct daily scrums just to hear what each other is working on.

But, some teams will do without Scrum altogether during that week. I'm OK with that although I'll admit my preference for doing a one-week sprint with extremely lightweight (short) meetings. So, this is the one time I'd consider some work to be "outside" a sprint.

Software Development Linkopedia February 2014

From the Editor of Methods & Tools - Wed, 02/19/2014 - 14:39
Here is our monthly selection of interesting knowledge material on programming, software testing and project management.  This month you will find some interesting information and opinions about coding in Java, project planning, Scrum and Kanban, debugging, user interface quality,  diversity in programming, agile metrics and software testing in a continuous deployment context. Web site: Google Java Style Guide Blog: Long-Range Planning with User Stories Blog: Why Contrasting Scrumban and Kanban Belies a Lack of Understanding of Both Blog: Finding Bugs: Debugger versus Logging Article: Save Your Software from the Start: Overcoming Skewed Thinking in the ...

My Book Tour Comes to UK and Bulgaria

NOOP.NL - Jurgen Appelo - Wed, 02/19/2014 - 11:00
UK and Bulgaria

The priorities for my new Global Management 3.0 Workout Book Tour are based on a backlog of countries, which is in turn based on the subscribers of my mailing list. Two companies in Bulgaria have lobbied to get people registered on the mailing list, which caused this country to climb from #19 to #5 on the priority list. That’s is great! It means they are committed to get me to travel to Bulgaria.

I have rewarded this enthusiasm by planning a trip to Bulgaria in July.

The post My Book Tour Comes to UK and Bulgaria appeared first on NOOP.NL.

Categories: Project Management

Cost of Delay: Why You Should Care, Part 6

I’ve outlined five potential costs of delay in the previous five posts:

The real problem is this: Why should you care? Maybe you have a “sweet spot” in the way you start your projects or release them. “It just takes that long here.” (That’s the sign of a system impediment.)

Cost of Delay, Back of the Napkin

Cost of Delay, Back of the Napkin

Let me show you two pictures. The first you’ve already seen, the back of the napkin, where you see the effect on your potential maximum revenue.

Now, let’s try to calculate that cost of delay.

The longer your delay, the more your cost of delay moves your curve to the right. The more sales you lose out of the Maximum potential sales.

The longer it takes for you to release, the more sales you lose from the maximum potential sales. You wait a month to release? You lose a month of max sales. You wait a year to release? You lose a year of max sales.

Cost of Delay, Showing Effect of Delay on Sales

Cost of Delay,
Showing Effect of Delay on Sales

That’s right. Do those numbers start to look big and scary now?

You not only have aggravation and impediments in your current project from the delays from multitasking, technical debt, indecision, slowdowns from other teams, you lose the potential revenue from maximum potential sales, every week you don’t release.

Now, I am not saying you should release horrible product. Goodness knows, we have enough of horrible product that barely works or doesn’t work at all out in the field. I want to see great products! The idea behind this picture is so people understand that it is worth their while to consider change.

You can change to shorter projects and release something useful faster. (See Manage It! Your Guide to Modern, Pragmatic Project Management)

You can change to agile or incremental lifecycles so they can see progress and release something useful faster. (See What Lifecycle? Selecting the Right Model for Your Project and Manage It! Your Guide to Modern, Pragmatic Project Management for an in-depth discussion of lifecycles. You have more options than just waterfall and agile.)

You can adopt a more reasonable approach to the project portfolio, and make decisions more frequently. (Does anyone really think project portfolio decisions last a year? Come on.) (See Manage Your Project Portfolio: Increase Your Capacity and Finish More Projects)

You can consider paying off some technical debt. I used the build system in my example. I could have used automated tests or the thousands of defects some of you have in your defect tracking systems. It’s whatever prevents you from knowing you could release on a “moment’s” notice. I would like that moment to be under an hour. I bet for many of you, less than a day would be a huge improvement.

You can optimize for the entire project or program, not their feature or team. Too often, I hear, “My part is done.” That does not matter. It matters what the entire team, project, or program finishes.

In my talks about project portfolio management, I am fond of saying, “It doesn’t matter how many projects you start, it matters how many you finish.”

With cost of delay, it matters when you finish them. Because until you finish them, no one pays you.

I have taken a high level approach to cost of delay in these posts. I wanted to simplify it so you and I could understand it, a zeroth approach, if you will. If you want more information, start here:

Cost of delay is why you cannot take an ROI or use date or budget estimates to manage the project portfolio. This is why you must use value. I look forward to your comments.

Categories: Project Management

User Stories & Back-End Systems

Mike Cohn's Blog - Tue, 02/18/2014 - 15:00

In my Keeping the User in User Stories, I described the benefits of the following user story template: As a , I want so that .” In this blog entry, I want to describe how you can use the same template to address back-end functionality.

Back-end systems are those without direct users. One good example is a financial back-end system. Imagine we are creating a financial system that takes in a lot of daily data and produces files that will be sent to banks and other partners at the end of the day. Some of the files are simple formats. Other files are in more involved formats with multiple record types within the file and possibly with multiple lines for some of the transactions.

One of the first things we need to do to start developing this system is to write user stories. To do that, we'll need to figure out the user for our stories. In our example situation, the user is probably a bank or business partner. This will let us write stories like “As a bank, I want…”

  • As a bank, I want to receive a file showing all checks to be cleared so that I can debit and credit the right accounts.
  • As a bank, I want to receive a correctly formatted 5300 file so that I can adjust balances as appropriate.
  • As a bank, I want to receive a file showing the status of all resubmitted transactions so that I can update the database with new information.

First, notice it is OK to humanize the bank with “As a bank, I want…” Programmers do this all the time in conversation. “OK, suppose I'm the bank and you send me a 5300 file with a bad record. In that case, I'll…”

Also notice that these stories are just examples. They likely would have to be broken down into smaller stories that could be completed in a sprint. And the users might have to get more specific, too:

  • As a commercial bank, I want….
  • As a savings & loan, I want…
  • As the Bank of America, I want… (assuming we have some specific business partnership that provides BofA with unique functionality)

But my point is that the user doesn't have to be an actual person staring at a computer screen. The user can also be the entity that needs the functionality.

For more details on how to write user stories for a back-end system, you can read this blog post.

Why Managers Are Smarter, and Management Isn’t

NOOP.NL - Jurgen Appelo - Mon, 02/17/2014 - 13:58
Managers Are Smarter

I got involved in an interesting email discussion about the question whether the work of managers requires smarter people. This is what someone told me (summarized):

Managers have a “higher role” than other workers, because their work involves “more complexity”, which suggests the need for a higher “MPA (mental processing ability)” for managers.

Let me explain why this is complete nonsense.

The post Why Managers Are Smarter, and Management Isn’t appeared first on NOOP.NL.

Categories: Project Management

Quote of the Month February 2014

From the Editor of Methods & Tools - Mon, 02/17/2014 - 10:32
The maddening thing about most of our organizations is that they are only as good as the people who staff them. Wouldn’t it be nice if we could get around that natural limit, and have good organizations even though they were staffed by mediocre or incompetent people? Nothing could be easier—all we need is (trumpet fanfare, please) a Methodology. A Methodology is a general systems theory of how a whole class of thought-intensive work ought to be conducted. It comes in the form of a fat book that specifies in detail ...

Cost of Delay Due to Other Teams’ Delay, Part 5

Imagine you have a large program, where you have several teams contributing to the success of one business deliverable. You are all trying to achieve a specific date for release.

One team is having trouble. Maybe this is their first missed deliverable. Maybe it’s their second. Maybe they have had trouble meeting their deliverables all along—they have “delivered,” but the deliverables don’t work.

Now, say you’re halfway through the desired program time. You, as a program manager, can see that this program is in trouble. That one team is not going to make it. What do you do?

This us where you start talking to people and understanding what the value of everything is.

  1. Does the program need everything on that team’s backlog?
  2. Does the program need everything on other team’s backlogs?
  3. Does the program product owner understand the cost of delay?
  4. How about the sponsors for the program? Do they know what’s going on?
Cost of Delay, Back of the Napkin

Cost of Delay, Back of the Napkin

Take out your back of the napkin calculation and show it to anyone who will listen.

Does the team understand the problem of lateness, as we discussed in part 1? They might. They might be overwhelmed by the technical difficulty of what they are doing. Maybe their stories are huge. Maybe they aren’t so hot at agile. Maybe they aren’t working in an agile way. There are 1001 reasons for this problem. If you are a manager of any stripe, program manager, development manager, whatever, you are responsible for understanding first, not yelling. (I often see senior development managers, VP Engineering encountering this, not realizing that they are the program managers in this situation.)

Does the program product owner really need everything in their backlog? It’s time to consider how little can that team do, and still deliver something of value. Or, it’s time to consider how little other teams do and still deliver something of value. Or, it’s time to rejigger who is doing what. Otherwise, you are going to lose the money in the middle of the revenue stream.

Are the teams working by layer, front end, middleware, back end, instead of through the architecture?

Something has to change in this program. You are not going to make the desired date. This problem is a larger case of the not shipping on time problem, but it’s not just one team. It involves more teams. And, with a program, it involves more money. It’s almost always a bigger stake.

This is when you want to start considering cost of delay for features. Yes, not just for releases, but for features.

Each feature has value when you deliver it at a certain time. Before a certain time, it might have more or less value. After a certain time, it has less value.

Who knows when that time is? Who can make these decisions in your organization. Sometimes that person is called a product owner, a product manager, or, gasp, a customer. Sometimes, that person is called a Marketing Manager or Director, or even a CEO. Rarely is that person called a developer or tester, or even a development manager or test manager or an Engineering manager or CIO or VP of Engineering. Sometimes the product development side knows. Almost never does the product development team know by themselves.

If you make decisions as a cross-functional team, product development and marketing, you can get the best of both worlds. You can learn about the technical risks—especially good if the team is having technical problems. You can learn about the cost of delay risks—especially good from the customer perspective. Now, you can make a decision about what to do for the good of the program.

You have to optimize for the program’s throughput, not any one team’s throughput.

In my world, you work with the team: do they want to stay together? Are they working well together, and having a tough time technically? If so, the team has many options:

  • The team can ask for technical help from another team (get an architect/designer to work with the team)
  • The team can split their backlog among several other teams, to give them a fighting chance.
  • If the team is not working well together (and they will tell you if they are still storming), offer them a chance to split. Or, you can facilitate a better working relationship so they can work well together.

If you don’t ask the team, you don’t know what’s wrong.

The problem with this cost of delay is that it’s tricky to discuss, it’s tricky to estimate, and it’s tricky to fix. It’s real. I bet you’ve seen it.

I would take out the napkin and remind the team that their delay costs the entire program. I want to help them remove that delay.

If you are using a waterfall approach to your programs, this cost of delay is invisible until the end of the program, when testing occurs. Why? Because that’s when you start to see features emerge.

If you are using an agile approach or at least an incremental lifecycle, you will start to see this much sooner, and you can do something about it.

The posts in this series so far are:

Cost of delay due to not shipping on time, part 1

Cost of delay due to multitasking, part 2

Cost of delay due to indecision, part 3

Cost of delay due to technical debt, part 4

Categories: Project Management

Cost of Delay Due to Other Teams’ Delay, Part 5

Imagine you have a large program, where you have several teams contributing to the success of one business deliverable. You are all trying to achieve a specific date for release.

One team is having trouble. Maybe this is their first missed deliverable. Maybe it’s their second. Maybe they have had trouble meeting their deliverables all along—they have “delivered,” but the deliverables don’t work.

Now, say you’re halfway through the desired program time. You, as a program manager, can see that this program is in trouble. That one team is not going to make it. What do you do?

This us where you start talking to people and understanding what the value of everything is.

  1. Does the program need everything on that team’s backlog?
  2. Does the program need everything on other team’s backlogs?
  3. Does the program product owner understand the cost of delay?
  4. How about the sponsors for the program? Do they know what’s going on?
Cost of Delay, Back of the Napkin

Cost of Delay, Back of the Napkin

Take out your back of the napkin calculation and show it to anyone who will listen.

Does the team understand the problem of lateness, as we discussed in part 1? They might. They might be overwhelmed by the technical difficulty of what they are doing. Maybe their stories are huge. Maybe they aren’t so hot at agile. Maybe they aren’t working in an agile way. There are 1001 reasons for this problem. If you are a manager of any stripe, program manager, development manager, whatever, you are responsible for understanding first, not yelling. (I often see senior development managers, VP Engineering encountering this, not realizing that they are the program managers in this situation.)

Does the program product owner really need everything in their backlog? It’s time to consider how little can that team do, and still deliver something of value. Or, it’s time to consider how little other teams do and still deliver something of value. Or, it’s time to rejigger who is doing what. Otherwise, you are going to lose the money in the middle of the revenue stream.

Are the teams working by layer, front end, middleware, back end, instead of through the architecture?

Something has to change in this program. You are not going to make the desired date. This problem is a larger case of the not shipping on time problem, but it’s not just one team. It involves more teams. And, with a program, it involves more money. It’s almost always a bigger stake.

This is when you want to start considering cost of delay for features. Yes, not just for releases, but for features.

Each feature has value when you deliver it at a certain time. Before a certain time, it might have more or less value. After a certain time, it has less value.

Who knows when that time is? Who can make these decisions in your organization. Sometimes that person is called a product owner, a product manager, or, gasp, a customer. Sometimes, that person is called a Marketing Manager or Director, or even a CEO. Rarely is that person called a developer or tester, or even a development manager or test manager or an Engineering manager or CIO or VP of Engineering. Sometimes the product development side knows. Almost never does the product development team know by themselves.

If you make decisions as a cross-functional team, product development and marketing, you can get the best of both worlds. You can learn about the technical risks—especially good if the team is having technical problems. You can learn about the cost of delay risks—especially good from the customer perspective. Now, you can make a decision about what to do for the good of the program.

You have to optimize for the program’s throughput, not any one team’s throughput.

In my world, you work with the team: do they want to stay together? Are they working well together, and having a tough time technically? If so, the team has many options:

  • The team can ask for technical help from another team (get an architect/designer to work with the team)
  • The team can split their backlog among several other teams, to give them a fighting chance.
  • If the team is not working well together (and they will tell you if they are still storming), offer them a chance to split. Or, you can facilitate a better working relationship so they can work well together.

If you don’t ask the team, you don’t know what’s wrong.

The problem with this cost of delay is that it’s tricky to discuss, it’s tricky to estimate, and it’s tricky to fix. It’s real. I bet you’ve seen it.

I would take out the napkin and remind the team that their delay costs the entire program. I want to help them remove that delay.

If you are using a waterfall approach to your programs, this cost of delay is invisible until the end of the program, when testing occurs. Why? Because that’s when you start to see features emerge.

If you are using an agile approach or at least an incremental lifecycle, you will start to see this much sooner, and you can do something about it.

The posts in this series so far are:

Cost of delay due to not shipping on time, part 1

Cost of delay due to multitasking, part 2

Cost of delay due to indecision, part 3

Cost of delay due to technical debt, part 4

Categories: Project Management

Cost of Delay Due to Technical Debt, Part 4

Cost of delay part 1 was about not shipping on time. Cost of delay part 2 was due to multitasking. Cost of delay part 3 was due to indecision. This part is the cost of delay due to technical debt.

One of the big problems in backlog management is ranking technical debt stories. It’s even more of a problem when it’s time to rank technical debt projects. You think product owners have feature-itis problems? Try having them rank technical debt projects. Almost impossible.

But if you really want the value from your project portfolio, you will look at your impediments. And, if you are like many of my clients, you have technical debt: a build system that isn’t sufficiently automated, insufficient automated system tests, too many system-level defects, who knows what else.

If you addressed the build system, and maybe some of the system tests, if you created a timeboxed technical debt project, you could save time on all of the other projects in this code base. All of them.

Imagine this scenario: you have a 2000-person Engineering organization. It takes you 3 weeks (yes, 21 calendar days) to create a real build that you know works. You currently can release every 12-18 months. You want to release every 3-6 months, because you have to respond to market competitors. In order to do that, you have to fix the build system. But you have a list of possible features, an arm and a leg long. What do you do?

This client first tried to do more features. They tried to do features in iterations. Oh, they tried.

By the time they called me, they were desperate. I did an assessment. I asked them if they knew how much the build system cost them. They had a group of  12 people who “supported” the build system. It took at least 10 days, but closer and closer to 20-25 days to get a working build. They tried to estimate the cost of the build in just this group of people: 12 people time 21 days. They did not account for the cost of delay in their projects.

I showed them the back of the napkin calculation in part 1, and asked, “How many releases have you postponed for at least a month, due to the build system?” They had an answer, which was in the double digits. They had sales in the millions for the maximum revenue. But they still had a sticking point.

If they funded this project, they would have no builds for four weeks. None. Nada. Zilch. And, their best people (whatever that means) would be on the build project for four weeks.

So, no architecture development, no design, no working on anything by the best people on anything other than the build system. This company was convinced that stopping Engineering for a month was a radical step.

Does it matter how long your iterations are, if you can’t build during the iterations and get feedback?

They finally did fund this project, after about six months of hobbling along.

After four weeks of intense work by 16 of their smartest people, they had an automated build system that anyone in Engineering could use. It still took 2 days to build. But that was heaven for everyone. They continued the build system work for another month, in parallel with regular Engineering work to reduce build system time.

After all the build system work, Engineering was able to change. They were able to transition to agile. Now, Engineering could make progress on their feature list, and release when it made sense for their business.

What was the payback for the build system work? Almost immediate, Engineering staff said. When I asked one of the VPs, he estimated, off the record, that they had lost more than the “millions” of dollars of revenue because they did not have the features needed at the time the market demanded. All because of the build system.

People didn’t plan for things to get this way. They got that way a little at a time, and because no one wanted to fund work on the build system.

This is a dramatic story due to technical debt. I bet you have a story just like this one.

The cost of delay due to technical debt is real. If you never look at your technical debt and see where it impedes you, you are not looking at the value of your entire project portfolio.

If you eliminated a technical debt impediment, would that change one of your costs of delay?

Categories: Project Management

Unfinished Work at the End of a Sprint is Not Evil

Mike Cohn's Blog - Wed, 02/12/2014 - 17:59

I guess I angered a few Scrum purists recently when I said that it's OK for an experienced team to occasionally show unfinished work in a sprint review. I'm probably going to anger them further this week, as I want to again raise the issue of unfinished work.

I occasionally hear a bold statement like, "Unfinished work at the end of a sprint is evil and should never be allowed."

While I understand the dangers of unfinished work, and while I would never contradict the Agile Manifesto's valuing of working software, this statement is wrong.

It is not unfinished work that is evil, but rather, the accumulation of unfinished work.

By unfinished work, I am referring to product backlog items that are started in a sprint but not finished.

To prove my claim, consider a programmer on a team who finishes his work with a few hours left on the last day of the sprint. As a good team member, he asks his teammates if any could use any help in finishing what they are working on. All are in good shape and will finish without his help.

Perhaps he next considers the short list of desired refactorings the team maintains – but finds it empty. Perhaps even the defect database is empty. (These last two assumptions may be too extreme, of course, but they'll serve to make a point.)

The programmer then looks at the product backlog and picks a user story to begin. He knows he won't be able to finish it during the sprint, but he's got a few hours and this product backlog item is the most valuable thing to be worked on next.

Preferring to always pair program, this developer spends the remaining hours of the sprint in deep thought about the feature – perhaps sketching some ideas on a nearby whiteboard.

And with that, the sprint ends. And unfinished work is left at the end of the sprint. Where, you may ask, was the unfinished work? In the programmer's head and on the whiteboard.

Thinking is work just as much as typing is. I can't imagine any plausible argument against this programmer's behavior, and so it proves that unfinished work is OK.

What remains though is the need to answer the question: How much unfinished work should be allowed? And that's simple: As little as possible.

So, while I disagree with the oft-made claim that unfinished work is evil, I want to stress that the accumulation of unfinished work is, indeed, evil. When the situation above is repeated, a team could soon find itself where each team member is perhaps two hours into separate product backlog items.

That team would obviously be better off being done with one 1o-hour product backlog item than two hours into five of them.

If your team is leaving unfinished work at the end of sprints, consider whether it's the natural result of sprints punctuating the flow of work, or whether team members should be working more collaboratively to finish one product backlog item before moving onto the next.

Graphing the number of hours of unfinished work in each sprint can help reveal trends. And, the sprint retrospective is a wonderful time to discuss whether unfinished work is building up and what to do about it.

Virtual Kudo Box

NOOP.NL - Jurgen Appelo - Wed, 02/12/2014 - 14:10
Kudo Box

I already had a Kudo Box article, and physical kudo cards.

Now there is an online Kudo Box application to help you send a token of appreciation to anyone who deserves it, created by Happy Melly’s CTO Sergey Kotlov. The tool is so easy, I don’t even have to explain how it works!

The post Virtual Kudo Box appeared first on NOOP.NL.

Categories: Project Management

Register Now for the Management 3.0 Workout Book Tour Workshop!

NOOP.NL - Jurgen Appelo - Tue, 02/11/2014 - 16:29
Management Workout

I will celebrate the upcoming release of my new book by visiting cities all over the world with a brand new one-day workshop. It’s all brand new materials, and you can see it as a follow-up to the regular 2-day course.

The post Register Now for the Management 3.0 Workout Book Tour Workshop! appeared first on NOOP.NL.

Categories: Project Management

Quote of the Day

Herding Cats - Glen Alleman - Sun, 02/09/2014 - 14:49

This branch of mathematics [probability] is the only one, I believe, in which good writers get results entirely erroneous - Charles Sanders Pierce

When it is said - you can't estimate the future - or we don't know total cost, think of Mr. Pierce. All things project management are probabilistic drive by the underlying statistical processes of irreducible and reducible uncertainty. Rarely, if ever, are these uncertainties Unknowable, in the mathematical sense. 

Categories: Project Management

Cost of Delay Due to Indecision, Part 3

In Part 1, we discussed the cost of delay of not shipping on time. In Part 2, we discussed the cost of delay of multitasking. In this part, we’ll discuss a cost of delay due to management indecision.

Here’s a problem I encounter often. A middle manager calls me, and asks for an estimation workshop. I ask about the environment. The manager tells me these things:

  • The developers meet their dates and the testers never do (this is not an estimation problem)
  • The project starts on time, and the project staff comes in close, but not quite on time (this might be an estimation problem)
  • The project starts off late (this is not an estimation problem)

When the developers meet their dates but the testers never do, it’s almost always a couple of things: Schedule Chicken, or technical debt masquerading as done in a waterfall project.

If the project starts on time and it’s close, it might be an estimation problem, assuming no one is multitasking.

But if the project starts late, this is not an estimation problem. This is a cost of delay due to management indecision.

Wouldn’t it be nice if you could say,

A lack of planning on your part does not constitute an emergency on my part

to your managers? Well, just call me the Queen of the Career Limiting Conversation. This is why managers are supposed to manage the project portfolio.

When I hear the plea for the estimation workshop, it’s for these reasons:

  • The managers have received estimations for the work, and they don’t like the estimates they have received.
  • Someone other than the project team did the estimation two years ago. They know the estimate is out of date, and they need a new estimate.
  • The managers still can’t make a decision, because they are trying to decide based on ROI, date, or cost or some sort of hard to predict quantitative measure, rather than on value.

The managers are, ahem, all tied up in their shorts. The can’t decide, which is a decision. They don’t fund the potentially transformative projects or programs. They go with the safe bets. They do the same projects over and over again.

If they get lucky, they choose a project which is small and has a chance of success.

How do you discuss this cost of delay? You ask this question:

When did you first start discussing this project as a potential project? or When did this project first go on our backlog?

That provides you the first date you need. This is your next question:

When did we actually start working on this project?

You want to see how long it takes you to consider projects. It’s okay to consider some projects for a while. The difference between the time you first start discussing a project and the time you start working on it is your management cost of delay. I just made that up. I bet there’s a real name for it.

What is the difference in those two dates?

Project lead time is the time you started discussing a potential project and the time you finished it. Project cycle time is the time you started a project and the time you finished it. Yes, we normally discuss lead time and cycle time for features. But sometimes, it makes sense for projects, too.

If you release projects, not features, and you have managers who have decision problems, they need to know about this cost of delay. Because the project lead time will take time out of your maximum revenue. The longer that lead time is, the more it will take.

The worst part is this: how much value does the project have, if the project lead time is “too long?”

What can you do?

  1. Track your project lead times. Decide how much time a project can spend on the backlog in the project portfolio before you decide to transform or kill it. Yes, I am serious.
  2. Shorten all your projects, so you release something at least every six months, or more often. That provides you more capability in assessing your project portfolio and frees teams for more work.
  3. Move to an incremental lifecycle or an agile approach.

I didn’t say it was easy. It’s healthier for your organization.

Who do you think can measure this cost of delay in your organization? What do you think might have to change to make this cost of delay visible?

Categories: Project Management

Cost of Delay Due to Multitasking, Part 2

In Cost of Delay: Not Shipping on Time, Part 1, I introduced you to the notion of cost of delay. I said you could reduce the cost of delay by managing your projects: have shorter projects, using release criteria, or selecting a lifecycle that manages the risk.

Sometimes, you don’t have short projects, so projects get backed up, and your managers ask you to work on several things at once. Or, the managers can’t decide which project is #1. Somehow, you end up doing several things “at once.” This is the multitasking problem, and this is the cost of delay in this part.

You know me, I hate multitasking. The costs are significant. But those are just the costs of multitasking on the work you are doing now. That has nothing to do with the cost of delay to your projects.

In Manage It!, I have this nice picture of what happens when you try to multitask between two projects.

Two Tasks or Projects

Two Tasks or Projects

Imagine you have two projects. Each of them should take a week. Hey, they’re short projects. I’m trying to illustrate a point.

You can deliver one of them at the end of the first week. You can deliver the second one at the end of the second week.

But, imagine you have to multitask between them. Instead of being able to deliver anything at the end of the first week, you can’t deliver anything at all until the second week. And, depending on how much context switching you do, you might not be able to deliver anything until sometime during the third week. The blue boxes show the time lost due to context switching.

Effect of Multitasking Delay to Delivery

Effect of Multitasking
Delay to Delivery

This is a huge cost of delay due to multitasking.

How do you calculate this?

“Big” is not quantitative enough for some people. This is where using some of the tools from the people who do this for a living might be good.

I’ve always drawn a picture like this and explained, “I don’t know how to estimate the time in the blue boxes. The blue boxes are the delay times. I can’t estimate them, because everyone else is delayed by multitasking on their projects, too. Sometimes, it takes me an entire day to get an answer to a question that should only take me an hour to get an answer. All I know is that “ideal” time is irrelevant to actual time. And even calculating using relative estimation is hopeless. That’s because we are multitasking. All of our estimations are out the window because we are multitasking.

“The amount of time we spend working on a project might be accurate. It’s the wait time that’s killing us. I don’t know how to estimate that.”

What I’ve done before is take a two- or four-week window, and ask people to write down their predictions of what they thought some task would take. Then, I ask them to write down, as they spend their time on each task, how much time they actually spend on each task. Now you can compare the prediction to reality.

Remember that all of the context switching and wait time is the time you need to remove from the maximum sales revenue, had you released the product.

This is very difficult to do. It saps the morale of the people doing the work. They quickly realize how often they go back to the same thing, over and over and over again, making zero progress, trying to realize where they are. Do not do this for more than a four-week window. If you must do this, label this an experiment to obtain data. Explain you are trying to obtain actual work time, context switching time,  and wait time. Let people label the time as they will.

The managers will be astonished by how little time the technical staff spend on real work. They will be amazed by how much time the technical staff spend on context switching and wait time. This is why managers think technical staff are bad at estimation. Who can be good at estimation when they are multitasking?

The problem is this: the cost of delay due to multitasking is real. It’s invisible to most people, especially management. It’s not just the cost of the blue boxes in the picture above. It’s the fact that nothing gets out of your organization until the end of Week 2 or later. Remember the back of the napkin in Part 1? Even if you use that calculation, you can see you are losing revenue left and right due to multitasking.

Remind the managers: Remember that all of the context switching and wait time is the time you need to remove from the maximum sales revenue, had you released any of the products.

Can you use this as an argument for your managers to end the multitasking and manage the project portfolio?

Cost of delay due to multitasking is real. What would you need to know to calculate it in your organization?

Categories: Project Management

Cost of Delay: Not Shipping on Time, Part 1

Do you know about the Cost of Delay? It’s the way to think about the revenue you can lose plus the cost of continued development.

One of my managers many years ago had a back of the napkin approach to cost of delay.

Cost of Delay, Back of the Napkin

Cost of Delay,
Back of the Napkin

“Johanna, we want to ship this product in the second quarter this year. We estimate it will take us a quarter to ramp up sales. We think there is a lifetime sales of about five years for this product. Any delays in our shipment will not push our sales figures to the right. They will remove our max sales from the middle. Got it? We have to make our ship date.”

I got it.

There weren’t too many of us developers in that organization. We all knew what our job was: to release on time, and make sure the product was usable. The product didn’t have to be perfect. The product had to be usable, because we could release fixes if we needed to, but we had to climb that sales ramp to get to that max sales point.

We worked on one project at at a time, until it was done. Then we went to the next project. We worked on that project. None of our projects was very long. Why? Because we needed to realize revenue. You can’t realize revenue with a product-in-a-box if you don’t ship it.

We didn’t ship too many fixes. Oh, not because we were perfect the first time. We asked each other for review, and we found problems, so we fixed them inside the building. Before we shipped. Because the cost of not shipping on time was too great.

When you delay your release and don’t ship on time, you miss the revenue from the maximum sales times. Take your delay in weeks, and remove the revenue weeks. That’s your cost of delay, back of the napkin approach.

You can go through more serious calculations. Troy Magennis of Focused Objective talks about a “compounding impact” on other projects. I am sure he’s correct.

But even if you said, “Every week we slip, we lose at least a week of revenue from our maximum sales week of revenue,” do you think people would notice?

How do you release on time? You fix scope (ha!). You have release criteria. You have shorter projects, because they are easier to estimate and deliver. You use an incremental or an agile lifecycle, so you have more predictability about your release.

This post is the simple idea of not shipping on time. But what about when you have competing projects and not enough people? Look for Part 2, next.

P.S. After I wrote this post, I realized I was not living this post. (Why do you think I write? It’s not just for you. It’s for me too.) I published the incomplete Essays on Estimation. I have another essay or two to release. But if I don’t release it, you can’t read it and get any value from it, can you? The point: if you don’t release your products, your customers can’t get any value. Hat Tip to @jlottsen who said in a tweet, “you have to release it, or no one can use it, and you can’t realize any revenue at all”. Very true.

Categories: Project Management

Innovation Is Not Only in Your Code

NOOP.NL - Jurgen Appelo - Wed, 02/05/2014 - 12:48
Innovation Is Not Only in Your Code

I was invited to speak at an interesting company event in Gent two days ago, where I discussed running experiments with Exploration Days, Business Guilds and more. One employee asked me this interesting question:

How can the non-IT departments participate in Hack Days or Exploration Days? How can they help innovate?

Great question!

The post Innovation Is Not Only in Your Code appeared first on NOOP.NL.

Categories: Project Management

Performance-Based Project Management(sm) Released

Herding Cats - Glen Alleman - Tue, 02/04/2014 - 19:14

Performance-Based Project Management(sm) on Amazon

Here's the Table of Contents and Chapter 2. This chapter is the anchor for the Principles, Practices, and Processes of increasing the probability of project success.

Performance-Based Project Management(sm) from Glen Alleman Here's a quick overview of the rest of the book with Principles, Practices, and Processes 5 immutable principles and 5 processes in 60 seconds from Glen Alleman On a bit more detail about how the parts all come together

Performance based planning in a nut shell (V5) from Glen Alleman     Related articles Flaws and Fallacies in Statistical Thinking What is Project Management About?
Categories: Project Management

Eight Software Security Videos to Watch

From the Editor of Methods & Tools - Tue, 02/04/2014 - 15:39
If we could vote the most underrated area of software development, security might be an easy winner. In the past, it was considered as a side project where you would eventually manage a user and access rights feature in your application. Things started changing with the web and the concept of “cross site scripting” or “SQL injections” should be understood by every developer. In a context where devices running software are often open for everybody through the web or more local network protocols like wifi, bluetooth, etc, the possibility to attack ...