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

How Do You Do It? (A Job Like a Tailored Suit)

NOOP.NL - Jurgen Appelo - Tue, 11/18/2014 - 14:21
tailored-suit

I regularly get the question, “How Do You Do It?”

“How are you able to travel so much and not get sick of it?”

“How can you read 50+ books per year and also write your own?”

Gosh, I don’t know.

The post How Do You Do It? (A Job Like a Tailored Suit) appeared first on NOOP.NL.

Categories: Project Management

How Do You Do It? (A Job Like a Tailored Suit)

NOOP.NL - Jurgen Appelo - Tue, 11/18/2014 - 14:21
tailored-suit

I regularly get the question, “How Do You Do It?”

“How are you able to travel so much and not get sick of it?”

“How can you read 50+ books per year and also write your own?”

Gosh, I don’t know.

The post How Do You Do It? (A Job Like a Tailored Suit) appeared first on NOOP.NL.

Categories: Project Management

Measures of Program Performance

Herding Cats - Glen Alleman - Mon, 11/17/2014 - 14:29

In a sufficiently complex project we need measures of progress to plan beyond burning down our list of same sized stories, which by the way require non-trivial work to make same sized and keep same sized. And of course if this same size-ness does not have a sufficiently small variance all that effort is a waste.

But let's assume we're not working on a sufficiently small project where same sized work efforts can be developed, we need measures of progress related to the Effectiveness of the deliverables and the Performance of those deliverable in producing that effectiveness for the customer.

Here's a recent webinar on this topic.

Measurement News Webinar from Glen Alleman And of course we need to define in what domain this approach can be applied, what domain it is too much, and what domain it is actually not enough. Paradigm of agile project management from Glen Alleman Then the actual conversation about any approach to Increasing the Probability of Success for our work efforts can start. Along with identifying the underlying Root Causes of any impediments to that goal that exist today and the corrective actions needed to remove them.  Without knowing the root cause and corrective actions any suggested solution has little value as it is speculative at best and nonsense at worse.
Categories: Project Management

When the Solution to Bad Management is a Bad Solution

Herding Cats - Glen Alleman - Mon, 11/17/2014 - 01:40

SMartin_SB_PICS5Much has been written about the Estimating Problem, the optimism bias, the planning fallacy, and other related issues with estimating in the presence of Dilbert-isk style management. The notion that the solution to the estimating problem is not to estimate, but to start work, measure the performance of the work, and use that to forecast completion dates and efforts is essentially falling into the trap Steve Martin did in LA Story. 

Using yesterday's weather becasue he was too lazy to make tomorrow's forecast

By the way each of those issues has a direct and applicable solution. So next time you hear someone use them as the basis of a new idea, ask if they have tried the known to work solution to the planning fallacy, estimating bias, optimism bias, and the myriad of other project issues with knowing solutions?

All measuring performance to date does is measure yesterday's weather. This yesterday's weather paradigm has been well studied. If in fact your project is based on Climate then yesterday's weather is likely a good indicator of tomorrow's weather.

The problem of course with the yesterday's weather approach, is the same problem Steve Martin had in LA Story when he used a previously recorded weather forecast for the next day. 

Today's weather turned out not to be like yesterday's weather.

Those posting that stories settle down to a rhythm assume - and we know what assume means - that the variances in the work efforts are settling down as well. That would mean the word assume comes true Ass out of U and Me. That's a hugely naive approach, without actual confirmation that the variances are small enough to not impact the past performance. When you have statistical processes looking like this, from small sampled projects in the absence of actual reference class - in this case self-reference class - you're also being hugely naive about the possible behaviours of stochastic processes.

14_10_08_ItemsPerSprint

Then when you slice the work to same sized efforts - this is actually process used in the domains we work: DOD, DOE, ERP - you're actually estimating future performance base on a reference class and calling it Not Estimating.

So when you hear examples and Bad Management, over commitment of work, assigning a project manager to a project that is 100's of time larger than that PM has ever experienced and expecting success, getting a credible estimate and cutting it in half, or any other Dilbert style management process - and you start with dropping the core process needed to increase the probability of success.

This approach is itself contrary to good project management principles, which are quite simple:

Principles and Practices of Performance-Based Project Management¬ģ from Glen Alleman ¬†

 If we start with a solution to a problem of Bad Management, before assuring that the Principles and Practices of Good Management are in place, we'll be paving the cow path as we say in our enterprise, space, defense domain. This means that the solution will have not actually fixed the problem. It will have not treated the root cause of the problem, just addressed the symptoms.

There is no substitute for Good Management.

Inigo1And when you hear there is a smell of bad management and there is no enumeration of the root causes and the corrective actions to those root causes, remember Ingio Montoya's retort to Vizzini's statement

You keep using that word. I do not think it means what you think it means.

That word is dysfunction, smell, root cause - all of which are missing the actual innumerated root causes, assessment of the possible corrective actions, and resulting removal of the symptoms. 

I speak about this approach from my hands on experience working the Performance Assessment and Root Cause Analysis on programs that are in the headlines.

Related articles Should I Be Estimating My Work? Estimating Guidance Assessing Value Produced By Investments Basis of #NoEstimates are 27 Year Old Reports
Categories: Project Management

DON’T PANIC! (For Everyone Who Fears Failure)

NOOP.NL - Jurgen Appelo - Fri, 11/14/2014 - 09:45
Don't Panic!

It happened just after I told my friend Lisette never to panic. When something goes wrong during your presentation, your workshop, your travels, or in any other endeavor, DO NOT PANIC! Your panic is most likely to cause the thing that you fear most.

The post DON’T PANIC! (For Everyone Who Fears Failure) appeared first on NOOP.NL.

Categories: Project Management

DON’T PANIC! (For Everyone Who Fears Failure)

NOOP.NL - Jurgen Appelo - Fri, 11/14/2014 - 09:45
Don't Panic!

It happened just after I told my friend Lisette never to panic. When something goes wrong during your presentation, your workshop, your travels, or in any other endeavor, DO NOT PANIC! Your panic is most likely to cause the thing that you fear most.

The post DON’T PANIC! (For Everyone Who Fears Failure) appeared first on NOOP.NL.

Categories: Project Management

7 Articles On Risk Management in Software Development

From the Editor of Methods & Tools - Wed, 11/12/2014 - 16:20
While starting a new software development project creates some enthusiasm, the engineer part of the software developer and project manager will also see this event as a set of possible risks. These risks encompass many domains: business, project team, software architecture, technology… Besides being aware of the possible impediments to the project success, risk management is also used to make choices in the product and technology roadmaps and manage priorities when resources are limited. Here is a list of interesting articles that discusses approaches to risk in software development. Risk Management ...

My Offer to Book Resellers

NOOP.NL - Jurgen Appelo - Tue, 11/11/2014 - 18:48
cover-mockup 2

There are two great aspects to people complaining about the shipping fees of my book:

It shows that readers care. They want the book! Even the 15,000 people who already downloaded the free PDF. Within three days, I sold XXX copies of the #Workout book from the Management 3.0 web shop. Imagine how much more people we can reach when we slash distribution costs?

Already several people asked me if they can resell the book locally, which will cut shipping fees dramatically. The answer is: Yes, please! The less I have to do, the better. My goal is to be a writer, not a distributor.

The post My Offer to Book Resellers appeared first on NOOP.NL.

Categories: Project Management

Veterans Day

Herding Cats - Glen Alleman - Tue, 11/11/2014 - 17:04

Veterans-day-2009

Categories: Project Management

Agile Needs to Be Both Iterative and Incremental

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

The following was originally published in Mike Cohn's monthly newsletter. If you like what you're reading, sign up to have this content delivered to your inbox weeks before it's posted on the blog, here.

Scrum, like all of the agile processes, is both iterative and incremental. Since these words are used so frequently without definition, let’s define them.

An iterative process is one that makes progress through successive refinement. A development team takes a first cut at a system, knowing it is incomplete or weak in some (perhaps many) areas. The team then iteratively refines those areas until the product is satisfactory. With each iteration, the software is improved through the addition of greater detail.

For example, in a first iteration, a search screen might be coded to support only the simplest type of search. The second iteration might add additional search criteria. Finally, a third iteration may add error handling.

A good analogy is sculpting. First, the sculptor selects a stone of the appropriate size. Next, the sculptor carves the general shape from the stone. At this point, one can perhaps distinguish the head and torso, and discern that the finished work will be of a human body rather than a bird. Next, the sculptor refines her work by adding detail. However, the sculptor is unlikely to look on any one area as complete until the entire work is complete.

An incremental process is one in which software is built and delivered in pieces. Each piece, or increment, represents a complete subset of functionality. The increment may be either small or large, perhaps ranging from just a system’s login screen on the small end, to a highly flexible set of data management screens.

Each increment is fully coded and tested, and the common expectation is that the work of an iteration will not need to be revisited. An incremental sculptor would pick one part of her work and focus entirely on it until it’s finished. She may select small increments (first the nose, then the eyes, then the mouth, and so on) or large increments (head, torso, legs and then arms). However, regardless of the increment size, the incremental sculptor would attempt to finish the work of that increment as completely as possible.

Scrum and agile are both incremental and iterative. They are iterative in that they plan for the work of one iteration to be improved upon in subsequent iterations. They are incremental because completed work is delivered throughout the project.

To better illustrate the differences between iterative and incremental, let’s consider building a dating website iteratively but not incrementally. To do this, the team would build a little of every part of the site—profile management, searching, ads, etc. The team would then revisit all parts, improving each.

The team would then revisit all parts again, making further improvements. In this purely iterative way, the entire site is getting a little better.

Next, consider developing the same site with a purely incremental, but not iterative process. If a dating site were built incrementally, the team would build and perfect profile management before starting on any other part of the site. They would then build and perfect a second area, say searching, before moving onto the third area. Each functional area would be made perfect before the next area was started.

Neither iterative nor incremental is all that great alone. But together—as they are with Scrum—they are fantastic.

Agile Needs to Be Both Iterative and Incremental

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

The following was originally published in Mike Cohn's monthly newsletter. If you like what you're reading, sign up to have this content delivered to your inbox weeks before it's posted on the blog, here.

Scrum, like all of the agile processes, is both iterative and incremental. Since these words are used so frequently without definition, let’s define them.

An iterative process is one that makes progress through successive refinement. A development team takes a first cut at a system, knowing it is incomplete or weak in some (perhaps many) areas. The team then iteratively refines those areas until the product is satisfactory. With each iteration, the software is improved through the addition of greater detail.

For example, in a first iteration, a search screen might be coded to support only the simplest type of search. The second iteration might add additional search criteria. Finally, a third iteration may add error handling.

A good analogy is sculpting. First, the sculptor selects a stone of the appropriate size. Next, the sculptor carves the general shape from the stone. At this point, one can perhaps distinguish the head and torso, and discern that the finished work will be of a human body rather than a bird. Next, the sculptor refines her work by adding detail. However, the sculptor is unlikely to look on any one area as complete until the entire work is complete.

An incremental process is one in which software is built and delivered in pieces. Each piece, or increment, represents a complete subset of functionality. The increment may be either small or large, perhaps ranging from just a system’s login screen on the small end, to a highly flexible set of data management screens.

Each increment is fully coded and tested, and the common expectation is that the work of an iteration will not need to be revisited. An incremental sculptor would pick one part of her work and focus entirely on it until it’s finished. She may select small increments (first the nose, then the eyes, then the mouth, and so on) or large increments (head, torso, legs and then arms). However, regardless of the increment size, the incremental sculptor would attempt to finish the work of that increment as completely as possible.

Scrum and agile are both incremental and iterative. They are iterative in that they plan for the work of one iteration to be improved upon in subsequent iterations. They are incremental because completed work is delivered throughout the project.

To better illustrate the differences between iterative and incremental, let’s consider building a dating website iteratively but not incrementally. To do this, the team would build a little of every part of the site—profile management, searching, ads, etc. The team would then revisit all parts, improving each.

The team would then revisit all parts again, making further improvements. In this purely iterative way, the entire site is getting a little better.

Next, consider developing the same site with a purely incremental, but not iterative process. If a dating site were built incrementally, the team would build and perfect profile management before starting on any other part of the site. They would then build and perfect a second area, say searching, before moving onto the third area. Each functional area would be made perfect before the next area was started.

Neither iterative nor incremental is all that great alone. But together—as they are with Scrum—they are fantastic.

Estimating Guidance

Herding Cats - Glen Alleman - Sun, 11/09/2014 - 23:45

With the plethora of opinions on estimating - some informed, many uninformed - here's my list of books and papers that inform our software estimating activities for Software Intensive Systems. These books range for hard core engineering to populist texts 

  • Estimating Software-Intensive Systems: Projects, Products, and Processes, Richard D. Stutzke, Addison Wesley. For nontrival projects, this is the starting point. Stutzke provides in depth assessment of the processes and techniques for estimating complex System of Systems based on software.
  • Software Estimation: Demystifying the Black Art, Steve McConnell, Microsoft Press. McConnell, provides an in depth look at the problems of estimating software projects and solutions for each problem. The notion that

Screen Shot 2014-11-09 at 2.59.03 PM

is not actually true after you have read the book. So please read the book and see how McConnell provides step-by-step actions for producing credible estimates.

  • Software Cost Estimation with COCOMO II, Barry Boehm, et al, Prentice Hall - this is the basis of most parametric estimating tools today. CCOMO II can be¬†tuned for a wide variety of domains. Download the tool, try it out, see what it can do for you.
  • Software Engineering Economics, Barry Boehm, Prentice Hall - writing software for money, especially others peoples money is a Microeconomics problem. These class of problems consider descions about the impact of future outcomes as¬†opportunity cost decisions. Since these decision have future impacts, estimates are needed for both the cost and impact. Writing software for money requires making estimates.
  • The Discipline of Software Engineering, Watts Humphrey, Addison Wesley - this was one of the orginal texts on how to build software products and the processes needed to assure success. Agile came along later, but many of the principles found in Humphrey's book are still applicable. The reason is agile is mostly about coding and the development of incremental results. Above that level discovering requirements derived from capabilities is still a core process.
  • Forecasting and Simulating Software Development Projects, Troy Magennis - this book is the agile version of several of the books above. Monte Carlo Simulation is used and development of the needed capabilities follows the approach found in many enterprise domains.
  • Software Sizing and Estimating, Charles Symons, John Wiley - this is a handbook for estimating. Function Points are not a broadly used as they once were, but again the principles are still applicable.
  • Economics of Iterative Software Development: Steering Toward Better Business Results, Walker Royce, Kurt Bittner, and Mike Perrow, Addison Wesley - software development is Microeconomics. This is an immutable principle. This book explains how to apply this principle in an iterative domain.
  • Facts and¬†Fallacies of Software Engineering, Robert Glass, Addision Wesley - a must read to counter the fallacy that decisons can be made in the absence of estimating the outcomes of those decisions.
  • The Incremental Commitment Spiral Model: Principles and Practices for Success Systems and Software, Barry Boehm, Jo Ann Lane, Supannika Koolmanojwong, and Richard Turner, Addison Wesley - the current Software Intensive Systems world is moving toward this approach for government systems.

Estimating software development starts with understanding what the software system is supposed to be doing and how we're able to measure that. This process is based on defining the needed  capabilities, the measures of Effectiveness, Measures of Performance, Key Performance Parameters, and Technical Performance Measures all needed for the ultimate success of the project. Along with a Plan showing the increasing maturity of the delivered capabilities. If we don't these in some form, it's going to be a disappoiintment for those payinig for our efforts when they get to the end and the outcomes are what they were expecting.

Capabilities are not Requirements. Requirements implement Capabilities. Capabilities are pretty much fixed while the Requirements evolve. Capabilities Based Planning is the basis of project management in many Software Intensive Systems.

Capabilities based planning (v2) from Glen Alleman With Capabilities in hand, the development of the system moves to the Systems Engineering and Requirements process:

With the project's capabilities defined to a level needed to start the project - failing to do this results in a Death March at worse, and spending the customer's money to discover what should have been discovered before starting. With the capabilities, the project needs to be managed in a way that will increase the probability of success.

So when you hear of some new approach to project management, ask if there is any connection to a domain and a context in that domain. Because there any many ideas about how to improve the probability of project success. But without a domain and context it'll be hard to assess if they are applicable to your specific situation. Here's one way to think about this domain dependency. From solo projects to national assets, methods, processes, tools are different as is the value at risk. 

Paradigm of agile project management from Glen Alleman Related articles How to Estimate Software Development
Categories: Project Management

Vectors and Scalars

Herding Cats - Glen Alleman - Sat, 11/08/2014 - 11:55

In the mathematics of physics, there are two essential types of values in all calculations - Scalars and Vectors.

Scalars are isolated values, with no outside context. Indeed They remain the same regardless of any context. A common example would be mass. An object has a mass of 1 Kilogram no matter where it is, or how much physical space it occupies. The context of the object cannot change the scalar value of its mass.

  • The number of stories produced in the last iteration.
  • The number of database rows selected on average for a transaction.
  • The number of defects found in thise release to production.

Vectors are contexted values, and can change depending on that context. An object has weight, dependent on both the mass value and gravity context of the object. An object with high mass, may still have no weight in the corresponding context of gravity.

  • The change in the productivity of¬†value as a function of time and cost as the project moves through its maturation process.
  • The estimated productivity needed to complete the project on or before a need date, at or below the planned budget to achieve the needed Return on Investment on the need date, so the break even date can be announced to those paying for our work.

But most specifically, vector values allow the calculations of change over time. Numbers (scalars) without context (vectors) are not metrics.

It is meaningless to say that cost to operate the IT Service Desk has doubled within the last ten years, without also showing how the number of employees has tripled in the same time.

It is meaningless to say a self-selected 120 projects exceeded their estimated cost and duration without an assessment of the credibility of that original estimate and the determination of the Root Cause of that overage.

It is meaningless to say the end date and cost can be forecast with saying something about the underlying uncertainties in effort size, risk, inter-dependencies, changing requirements, defect rates, labor absorption rates, integration issues, performance issues, and complexities of emerging behaviours once the system starts to come together and applied to fulfill the needed capabilities.

When we hear about small sample sized forecasts of same sized work activities, or selecting the next priority item to work on without considering the inter-dependencies of past work items or future work items - we're speaking about Scalar numbers, not Vector numbers.

Vectors state magnitude and direction. Open Loop control only states magnitude. Use it at your own risk.

Categories: Project Management

Product Development Kaizen

Herding Cats - Glen Alleman - Fri, 11/07/2014 - 19:41

Much of the noise around agile is based on platitudes and words in the absence of a domain and a context in that domain. Here's a possible anchoring processes

Product development kaizen (pdk) from Glen Alleman And an example paper based on these principles. Screen Shot 2014-11-07 at 11.34.16 AM
So when you hear about the next big thing think of Carl's suggestion. Especially if that next big thing violates the principles of business and economics. Untitled
Categories: Project Management

‚ÄúYour Book Is Expensive!‚ÄĚ (Yes, and It‚Äôs Also Cheap)

NOOP.NL - Jurgen Appelo - Fri, 11/07/2014 - 16:30
mock-up-spread-4-wit-1024

I have started the pre-sales of Management 3.0 #Workout – Paper Edition.

The paper book looks amazing! :-)

Besides the regular print version, I offer an exclusive version with autograph, unique number, postcards, kudo cards, and a hand-drawn illustration. There are only 500 of those!

The post ‚ÄúYour Book Is Expensive!‚ÄĚ (Yes, and It‚Äôs Also Cheap) appeared first on NOOP.NL.

Categories: Project Management

The Four Whys

NOOP.NL - Jurgen Appelo - Wed, 11/05/2014 - 15:11
Why

I’m sure you recognize the problem. You’re nose-deep in some activity that takes ten times longer than expected, and suddenly you think, “Why on earth am I wasting my time with this nonsense?” Yes, I have that too sometimes! I had it yesterday when I was explaining to one of my customers how sales tax works in Europe. It took so long, I needed two coffee breaks.

The post The Four Whys appeared first on NOOP.NL.

Categories: Project Management

Why I Prefer Commitment-Driven Sprint Planning

Mike Cohn's Blog - Tue, 11/04/2014 - 15:00

Over the past two weeks, I’ve described two alternative approaches to sprint planning:

This week I want to address why I prefer commitment-driven sprint planning. First, though, here is a very brief refresher on each of the approaches.

Brief Summary of Sprint-Planning Approaches

In velocity-driven sprint planning, a team selects a set of product backlog items whose high-level estimates (usually in story points or ideal days) equals their average velocity.

In commitment-driven sprint planning, a team commits to one product backlog item at a time by roughly identifying and estimating the tasks that will be involved, and stopping when they feel the sprint is full.

Because “commitment” is often mistaken as “guarantee,” this approach is becoming more commonly referred to as capacity-based sprint planning.

Velocity is Variable

To begin to see why I prefer a commitment-driven approach to sprint planning, consider the graph below which shows the velocities of a team over the course of nine sprints. The first thing you should notice is that velocity is not stable. It bounces around from sprint to sprint.

The first big drawback to velocity-driven planning is that velocity is too variable to be reliable for short-term (i.e., sprint) planning. My experience is that velocity bounces around in about a plus or minus 20% range. This means that a team whose true velocity is 20 could easily experience a velocity of 16 this sprint and 24 next sprint, and have that just be random variation.

When a team that averages 20 sometimes completes 24 units of work, but sometimes completes only 16, we might be tempted to say they are accomplishing more or less work in those sprints. And that is undoubtedly part of it for many teams. However, some part of the variation is attributable to the imprecision of the units used to estimate the product backlog items.

For example, most teams who estimate in story points use a subset of possible estimates such as the Fibonacci sequence of 1, 2, 3, 5, 8, 13 or a simple doubling (1, 2, 4, 8, 16). When a team using the Fibonacci sequence takes credit for finishing a 5-point story, they may have really only finished a 4-point story. This tends to lead to a slight overstating of velocity.

In the long-term this won’t be a problem as the law of big numbers can kick in and things will average out. In the short term, though, it can create problems.

Anchoring

A second problem with velocity-driven sprint planning is due to the effect of anchoring. Anchoring is the tendency for an estimate to be unduly influenced by earlier information.

A good example of anchoring is coming up as we approach the Christmas season. Suppose you go into a store and see a jacket you like. There’s a sign saying $400 but that price is crossed out and a new price of $200 is shown. Your brain instantly thinks, “Awesome! A $400 jacket for only $200!” And, of course, this is why the store shows you the original price.

Who cares what that jacket used to sell for? It’s $200 today. That should be all that matters in your buy-or-not decision. However, once that $400 price is in your brain, it’s hard to ignore it. It anchors you into thinking you’re getting a good deal when the jacket is $200.

I won't go into the details here, but the best paper I've read on anchoring is from Magne Jørgensen and Stein Grimstad and is called “The Impact of Irrelevant and Misleading Information on Software Development Effort Estimates.”)

Anchoring and Velocity-Driven Planning

But what does anchoring have to do with sprint planning?

Consider a team in a velocity-driven sprint planning meeting. They’ve selected a set of stories equal to their average velocity. They then ask themselves if that set of stories feels like the right amount of work. (As described, in the post on velocity-driven sprint planning they may also identify tasks and estimate those tasks as an aid in answering that.)

A team doing velocity-driven sprint planning is pre-disposed to say, “Yes, we can do this,” even if they can’t. They are anchored by knowing that the selected amount of work is the same as their average velocity.

It’s like me showing you that jacket with the $400 sign next to it and asking, “How much do you think this jacket sells for?” Even if you don’t say exactly $400, that $400 is in your head and will anchor you.

So, because of anchoring, a team with an average velocity of 20 is inclined to say the sprint is appropriately filled with 20 points – even if that work is really more like 16 or 24 units of work.

This will lead to teams sometimes doing less than they could have. It could also lead to teams sometimes doing more. But in those cases, my experience is that teams will be more likely to drop a product backlog item or two. Experience definitely tells me that teams are more likely to drop than to add.

Velocity Is Great for Longer-Term Planning

By this point, you may be thinking I’m pretty opposed to velocity-driven planning. That’s only half true. Although I’m not a fan of using velocity to plan a single sprint, I am quite likely the world’s biggest fan of using velocity to plan for the longer term. I’ve certainly written more about it than anyone I know.

The problem with velocity-driven sprint planning is that velocity is simply too variable to be useful in the short term. To illustrate why, suppose you get a job working at a car wash. On your first morning, your boss announces that you have a quota: You need to wash four cars per hour.

At the end of the first hour, though, you’ve only washed three cars. Should you be fired? Of course not. It was only one hour and perhaps you washed three large cars. Or perhaps it was overcast and only three drivers brought cars in to be washed.

What about at the end of your first day, an 8-hour shift? By then you should have washed 32 cars. But you’ve only washed 30. Should you be fired now? Again, almost certainly not.

What about the end of your first month? Figuring 20 days and 32 cars per day means you should have washed 640 cars. Suppose, though, you only washed 600. (That’s the same percentage as washing 30 instead of 32 in a day.) Should your boss fire you now? Perhaps still not, but it’s starting to be clear that you are not making quota.

What if you’re off by the same percentage at the end of the year? If that quota was well chosen—and all other employees are meeting it—your boss at some point should consider letting you go (or dealing with your below expected productivity in some way, but this post isn’t about good ways of dealing with productivity issues).

That quota is useful in the same way velocity is useful: over the long term. Think of how poorly run we’d consider that car wash if an employee was fired in the first hour of missing quota. The longest tenured employee would have been on the job for three days. So while that quota may be useful when measured over a month, it is not useful when measured hourly.

Velocity is useful in the long term, not the short term. A team with 30 product backlog items to deliver can sum the estimates (likely in story points) on those items and forecast when they’ll be done. A team with three product backlog items to deliver would be better off doing good ol’ task decomposition on those three items rather than relying on velocity.

So, Now What?

If you are already doing velocity-driven sprint planning and it’s working for you, don’t switch. However, if your team is new to Scrum or if your team is experiencing some of the issues I’ve described here, then I recommend using commitment-driven sprint planning.

Please let me know what you think in the comments below.

Assessing Value Produced By Investments

Herding Cats - Glen Alleman - Tue, 11/04/2014 - 14:28

Speaking at the Integrated Program Management Conference in Bethesda MD this week. The keynote speaker Monday was Katrina McFarland, Assistant Secretary of Defense (Acquisition)(ASD(A)), the principal adviser to the Secretary of Defense and Under Secretary of Defense for Acquisition. 

During her talk she spoke of the role of Earned Value Management. Here's a mashup of her remarks...

EV is a thoughtful tool as the basis of a conversation for determining the value (BCWP) produced by the investment (BCWS). This conversation is an assessment of the efficacy of our budget. 

We can determine the effecacy of our budget through:

  • Measures of Effectiveness of the deliverables in accomplishing the mission or fulfilling the technical and operational needs of the business.
  • Measures of Performance of these deliverables to perform the needed functions to produce the needed effectiveness
  • Technical Performance Measures of these functions to perform at the needed technical level.

These measures answer the question of what is the efficacy of our budget in delivering the outcomes of our project.

The value of the project outcomes must be traceable to a strategy for the business or mission. Once this strategy has been identified, the Measures of Effectiveness, Performance, and Technical Performance Measures can be assigned to the elements of project. These are shown in the figure below

Screen Shot 2014-11-04 at 6.23.39 AM

This approach is scalable up and down the complexity of projects based on five immutable principles of project success.

5 Immutable Principles

Without credible answers to each of these questions, the project is on the path to failure on day one.

Categories: Project Management

Quote of the Day

Herding Cats - Glen Alleman - Mon, 11/03/2014 - 05:27

Never attribute to malice that which is adequately explained by stupidity - Hanlon's Razor

 

Categories: Project Management

Quote of the Day

Herding Cats - Glen Alleman - Thu, 10/30/2014 - 22:50

The most unsuccessful three years in the education of cost estimators appears to be fifth-grade artihmetic - Norman R. Augustine

Opening line in the Welcome section of Software Estimation: Demystifying the Black Art, Steve McConnell.

Augustine is former Chairman and CEO of Martin Marietta. His seminal book Augustine's Laws, describes the complexities and conundrums of today's business management and offers solutions. Anyone interested in learning how successful management of complex technology based firms is done, should read that book. As well, read McConnell's book and see if you can find where 

Screen Shot 2014-10-30 at 3.47.41 PM

Because I sure can't find that proof or any mention that estimates don't work, other than for those who failed to pay attention in the 5th grade arithmetic class.

Categories: Project Management