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

SEMAT: The Essence of Software Engineering

From the Editor of Methods & Tools - Wed, 09/03/2014 - 17:37
SEMAT (Software Engineering Method and Theory) is an initiative to reshape software engineering such that software engineering qualifies as a rigorous discipline. SEMAT and Essence are big thinking for software developers. There are millions of software engineers on the planet in countless programs, projects and teams; the millions of line of software that run the world are testament to their talents, but as community we still find it difficult to share our best practices, truly empower our teams, seamless integrate software engineering into our businesses, and maintain the health of our ...

Story Points Are Still About Effort

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

Story points are about time. There, I’ve said it, and can’t be more clear than that. I’ve written previously about why story points are about effort, not complexity. But I want to revisit that topic here.

The primary reason for estimating product backlog items is so that predictions can be made about how much functionality can be delivered by what date. If we want to estimate what can be delivered by when, we’re talking about time. We need to estimate time. More specifically, we need to estimate effort, which is essentially the person-days (or hours) required to do something.

Estimating something other than effort may be helpful, but we can’t use it to answer questions about when a project can be delivered. For example, suppose a team were to estimate for each product backlog item how many people would be involved in delivering that item.

One item might involve only a programmer and a tester, so it is given a “two.” Another item might involve two programmers, a designer, a database engineer, and a tester. So it is given an estimate of “five.”

It is entirely possible that the product backlog item involving only two people will take significantly longer than the one involving five people. This would be the case if the two people were involved intensely for days while the five were only involved for a few hours.

We may say that the number of people involved in delivering a product backlog item is a proxy for how long the feature will take to develop. In fact, I’d suspect that if we looked at a large number of product backlog items, we would see that those involving more people do, on average, take longer than those involving fewer people.

However, I’m equally sure we’d see lots of counter-examples, like that of the five and two people above. This means that the number of people involved is not a very good proxy for the effort involved in delivering the feature.

This is the problem with equating story points with complexity. Complexity is a factor in how long a product backlog item will take to develop. But complexity is not the only factor, and it is not sufficiently explanatory that we can get by with estimating just the complexity of each product backlog item.

Instead, story points should be an estimate of how long it will take to develop a user story. Story points represent time. This has to be so because time is what our bosses, clients and customers care about. They only care about complexity to the extent it influences the amount of time something will take.

So story points represent the effort involved to deliver a product backlog item. An estimate of the effort involved can be influenced by risk, uncertainty, and complexity.

Let’s look at an example:

Suppose you and I are to walk to a building. We agree that it will take one walking point to get there. That doesn’t mean one minute, one mile or even one kilometer. We just call it one walking point. We could have called it 2, 5, 10 or a million, but let’s call it 1.

What’s nice about calling this one walking point is that you and I can agree on that estimate, even though you are going to walk there while I hobble over there on crutches. Clearly you can get there much faster than I can; yet using walking points, we can agree to call it one point.

Next, we point to another building and agree that walking to it will take two points. That is, we both think it will take us twice as long to get to.

Let’s add a third building. This building is physically the same distance as the two-point building. So we are tempted to call it a two. However, separating us from that building is a narrow walkway across a deep chasm filled with boiling lava. The walkway is just wide enough that we can traverse it if we’re extremely careful. But, one misstep, and we fall into the lava.

Even though this third building is the same physical distance as the building we previously estimated as two walking points, I want to put a higher estimate on this building because of the extra complexity in walking to it.

As long as I’m cautious, there’s no real risk of falling into the lava, but I assure you I am going to walk more slowly and deliberately across that walkway. So slow, in fact, that I’m going to estimate that building as four walking points away.

Make sense? The extra complexity has influenced my estimate.

Complexity influences an estimate, but only to the extent the extra complexity affects the effort involved in doing the work. Walking to the one-point building while singing “Gangnam Style” is probably more complex that walking there without singing. But the extra complexity of singing won’t affect the amount of time it takes me to walk there, so my estimate in this case would remain one.

Risk and uncertainty affect estimates similarly. Suppose a fourth building is also physically the same distance as the building we called a two. But in walking to that building we must cross some train tracks. And the train crosses at completely unpredictable times.

There is extra uncertainty in walking to that building—sometimes we get there in two points. Other times we get stuck waiting for the train to pass and it takes longer. On average, we might decide to estimate this building as a three.

So, story points are about time—the effort involved in doing something. Because our bosses, clients and customers want to know when something will be done, we need to estimate with something based on effort. Risk, uncertainty and complexity are factors that may influence the effort involved.

Let me know what you think in the comments below.

Story Points Are Still About Effort

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

Story points are about time. There, I’ve said it, and can’t be more clear than that. I’ve written previously about why story points are about effort, not complexity. But I want to revisit that topic here.

The primary reason for estimating product backlog items is so that predictions can be made about how much functionality can be delivered by what date. If we want to estimate what can be delivered by when, we’re talking about time. We need to estimate time. More specifically, we need to estimate effort, which is essentially the person-days (or hours) required to do something.

Estimating something other than effort may be helpful, but we can’t use it to answer questions about when a project can be delivered. For example, suppose a team were to estimate for each product backlog item how many people would be involved in delivering that item.

One item might involve only a programmer and a tester, so it is given a “two.” Another item might involve two programmers, a designer, a database engineer, and a tester. So it is given an estimate of “five.”

It is entirely possible that the product backlog item involving only two people will take significantly longer than the one involving five people. This would be the case if the two people were involved intensely for days while the five were only involved for a few hours.

We may say that the number of people involved in delivering a product backlog item is a proxy for how long the feature will take to develop. In fact, I’d suspect that if we looked at a large number of product backlog items, we would see that those involving more people do, on average, take longer than those involving fewer people.

However, I’m equally sure we’d see lots of counter-examples, like that of the five and two people above. This means that the number of people involved is not a very good proxy for the effort involved in delivering the feature.

This is the problem with equating story points with complexity. Complexity is a factor in how long a product backlog item will take to develop. But complexity is not the only factor, and it is not sufficiently explanatory that we can get by with estimating just the complexity of each product backlog item.

Instead, story points should be an estimate of how long it will take to develop a user story. Story points represent time. This has to be so because time is what our bosses, clients and customers care about. They only care about complexity to the extent it influences the amount of time something will take.

So story points represent the effort involved to deliver a product backlog item. An estimate of the effort involved can be influenced by risk, uncertainty, and complexity.

Let’s look at an example:

Suppose you and I are to walk to a building. We agree that it will take one walking point to get there. That doesn’t mean one minute, one mile or even one kilometer. We just call it one walking point. We could have called it 2, 5, 10 or a million, but let’s call it 1.

What’s nice about calling this one walking point is that you and I can agree on that estimate, even though you are going to walk there while I hobble over there on crutches. Clearly you can get there much faster than I can; yet using walking points, we can agree to call it one point.

Next, we point to another building and agree that walking to it will take two points. That is, we both think it will take us twice as long to get to.

Let’s add a third building. This building is physically the same distance as the two-point building. So we are tempted to call it a two. However, separating us from that building is a narrow walkway across a deep chasm filled with boiling lava. The walkway is just wide enough that we can traverse it if we’re extremely careful. But, one misstep, and we fall into the lava.

Even though this third building is the same physical distance as the building we previously estimated as two walking points, I want to put a higher estimate on this building because of the extra complexity in walking to it.

As long as I’m cautious, there’s no real risk of falling into the lava, but I assure you I am going to walk more slowly and deliberately across that walkway. So slow, in fact, that I’m going to estimate that building as four walking points away.

Make sense? The extra complexity has influenced my estimate.

Complexity influences an estimate, but only to the extent the extra complexity affects the effort involved in doing the work. Walking to the one-point building while singing “Gangnam Style” is probably more complex that walking there without singing. But the extra complexity of singing won’t affect the amount of time it takes me to walk there, so my estimate in this case would remain one.

Risk and uncertainty affect estimates similarly. Suppose a fourth building is also physically the same distance as the building we called a two. But in walking to that building we must cross some train tracks. And the train crosses at completely unpredictable times.

There is extra uncertainty in walking to that building—sometimes we get there in two points. Other times we get stuck waiting for the train to pass and it takes longer. On average, we might decide to estimate this building as a three.

So, story points are about time—the effort involved in doing something. Because our bosses, clients and customers want to know when something will be done, we need to estimate with something based on effort. Risk, uncertainty and complexity are factors that may influence the effort involved.

Let me know what you think in the comments below.

My New #Workout Book Is Best Selling on Amazon

NOOP.NL - Jurgen Appelo - Tue, 09/02/2014 - 14:04
#Workout

On Sunday, I uploaded the Kindle Edition of #Workout to Amazon.
On Monday, I notified all my friends on my exclusive mailing list.
On Tuesday, the book already had 26 great reviews and was listed as Best Selling in the Management category, which makes it one of the Hot New Releases.
I’m so happy! :-)

The post My New #Workout Book Is Best Selling on Amazon appeared first on NOOP.NL.

Categories: Project Management

Why I Don’t Use Leanpub

NOOP.NL - Jurgen Appelo - Fri, 08/29/2014 - 15:21
Leanpub 3

It seems not a week goes by without someone asking me, “Why don’t you publish on Leanpub?” or “Have you considered writing on Leanpub?” or some other variation of the same question.

The post Why I Don’t Use Leanpub appeared first on NOOP.NL.

Categories: Project Management

Quote of the Day — Just a Little Process Check

Herding Cats - Glen Alleman - Fri, 08/29/2014 - 15:12

Everyone is entitled to his own opinion, but not his own facts.— Daniel Patrick Moynihan

When engaging in exchanges about complex topics like cost, schedule, and technical performance management, I always get a smile when someone says oh that problem can be solved with this simple approach. Or I bet that organization has no motivation what so every to solve the problem. 

Then the next quote is applicable...

For every complex problem there is an answer that is clear, simple, and wrong. — H. L. Mencken

Solving complex problems is hard, stating there are simple solutions without having worked on complex problems is easy.

Related articles Complex Problems Require Better Solutions The Three Elements of Project Work and Their Estimates The Power of Misattributed and Misquoted Quotes Is There Such a Thing As Making Decisions Without Knowing the Cost?
Categories: Project Management

Managers Manage Ambiguity

I was thinking about the Glen Alleman’s post, All Things Project Are Probabilistic. In it, he says,

Management is Prediction

as a inference from Deming. When I read this quote,

If you can’t describe what you are doing as a process, you don’t know what you’re doing. –Deming

I infer from Deming that managers must manage ambiguity.

Here’s where Glen and I agree. Well, I think we agree. I hope I am not putting words into Glen’s mouth. I am sure he will correct me if I am.

Managers make decisions based on uncertain data. Some of that data is predictive data.

For example, I suggest that people provide, where necessary, order-of-magnitude estimates of projects and programs. Sometimes you need those estimates. Sometimes you don’t. (Yes, I have worked on programs where we didn’t need to estimate. We needed to execute and show progress.)

Now, here’s where I suspect Glen and I disagree:

  1. Asking people for detailed estimates at the beginning of a project and expecting those estimates to be true for the entire project. First, the estimates are guesses. Second, software is about learning, If you work in an agile way, you want to incorporate learning and change into the project or program. I have some posts about estimation in this blog queue where I discuss this.
  2. Using estimation for the project portfolio. I see no point in using estimates instead of value for the project portfolio, especially if you use agile approaches to your projects. If we finish features, we can end the project at any time. We can release it. This makes software different than any other type of project. Why not exploit that difference? Value makes much more sense. You can incorporate cost of delay into value.
  3. If you use your estimate as a target, you have some predictable outcomes unless you get lucky: you will shortchange the feature by decreasing scope, incur technical debt, or increase the defects. Or all three.

What works for projects is honest status reporting, which traffic lights don’t provide. Demos provide that. Transparency about obstacles provides that. The ability to be honest about how to solve problems and work through issues provides that.

Much has changed since I last worked on a DOD project. I’m delighted to see that Glen writes that many government projects are taking more agile approaches. However, if we always work on innovative, new work, we cannot predict with perfect estimation what it will take at the beginning, or even through the project. We can better our estimates as we proceed.

We can have a process for our work. Regardless of our approach, as long as we don’t do code-and-fix, we do. (In Manage It! Your Guide to Modern, Pragmatic Project Management, I say to choose an approach based on your context, and to choose any lifecycle except for code-and-fix.)

We can refine our estimates, if management needs them. The question is this: why does management need them? For predicting future cost for a customer? Okay, that’s reasonable. Maybe on large programs, you do an estimate every quarter for the next quarter, based on what you completed, as in released, and what’s on the roadmap. You already know what you have done. You know what your challenges were. You can do better estimates. I would even do an EQF for the entire project/program. Nobody has an open spigot of money.

But, in my experience, the agile project or program will end before you expect it to. (See the comments on Capacity Planning and the Project Portfolio.) But, the project will only end early if you evaluate features based on value and if you collaborate with your customer. The customer will say, “I have enough now. I don’t need more.” It might occur before the last expected quarter. It might occur before the last expected half-year.

That’s the real ambiguity that managers need to manage. Our estimates will not be correct. Technical leaders, project managers and product owners need to manage risks and value so the project stays on track. Managers need to ask the question: What if the project or program ends early?

Ambiguity, anyone?

Categories: Project Management

Software Development Conferences Forecast Agust 2014

From the Editor of Methods & Tools - Thu, 08/28/2014 - 08:38
Here is a list of software development related conferences and events on Agile ( Scrum, Lean, Kanban) software testing and software quality, programming (Java, .NET, JavaScript, Ruby, Python, PHP) and databases (NoSQL, MySQL, etc.) that will take place in the coming weeks and that have media partnerships with the Methods & Tools software development magazine. Agile on the Beach, September 4-5 2014, Falmouth in Cornwall, UK SPTechCon, September 16-19 2014, Boston, USA Receive a $200 discount on a 4 or 3-day pass with code SHAREPOINT Future of Web Apps, September 29-October 1 2014, London, ...

Quote of the Day - All Things Project Are Probabilistic

Herding Cats - Glen Alleman - Wed, 08/27/2014 - 16:28

As far as the laws of mathematics refer to reality, they are not certain, as far as they are certain, they do not refer to reality.

— Albert Einstein Sherwin, Ronald Paul (2014-08-17). In The Tao of Systems Engineering: An Engineer's Survival Guide (pp. 195-197). Ronald Paul Sherwin. Kindle Edition.

When ever you hear that we can't predict the future. Think again. We can always predict the future. The level of confidence of that future is what is in question.

When you hear estimating is guessing. Think again. That person doesn't understand probability and statistics. When you hear we don't need to predict to make decisions, that person has very little at risk from that decision, since making decisions in the absence of knowing the possible loss ignores the principles of microeconomics of everyday life.

When ever you hear we don't need to estimate the outcomes of our decisions. Think again. We don't need to estimate those outcomes only if they are of low enough value that we don't care about the consequences of not knowing to some level of confidence what happens as a result of our decision. We're willing to wright off our loss if we're wrong.

When we hear any conjecture that involves mathematics that does not address the foundation of the mathematical principles of that discussion, remember Einstein, and also remember how to apply that advice in the specific domain and context of the question guided by Deming.

Management is Prediction 

Deming 2

Since management is prediction, knowing how to make predictions using statistical methods to produce a confidence interval about the probabilistic outcomes of those business decisions is part of management. When we want a sit at the table where management decisions are being made, knowing this and being able to add value to the decision process is the price of entry to that room. Otherwise we're labor sitting outside the room waiting for the decisions to be made. 
 

Categories: Project Management

Navigating the Way Home

Herding Cats - Glen Alleman - Wed, 08/27/2014 - 03:10

Manx shearwaterI came across a nice blog post from DelancyPlace about the navigation powers of birds. 

This bird was taken from Wale's to Venice Italy and released and found it's way home in 14 days. 930 miles, over mountains .

To be able to find their way home from an unfamiliar place, birds must carry a figurative map and compass in their brains.

The map tells them where they are, and the compass tells them which direction to fly, even when they are released with no frame of reference to their home loft.

Projects Are Not Birds

As project managers, what's our map and compass? How can we navigate from the start of the project to the end, even though we haven't been on this path before. 

How can we find our way Home?

We have a map. It starts with a Capabilities Based Plan. The CBP states what Done looks like in units of measure meaningful to the decision makers. These units of measure are Measures of Effectiveness and Measures of Performance.

  • Measures of Effectiveness - are operational measures of success that are closely related to the achievements of the mission or operational objectives evaluated in the operational environment, under a specific set of conditions.

  • Measures of Performance - characterize physical or functional attributes relating to the system operation, measured or estimated under specific conditions.

These measures speak to our home and the attributes of the home. The map that gets us ti home is the Integrated Master Plan. This shows the increasing maturity of the deliverables that implement the Measures of Performance and those Performance items that enable the project to produce the needed capabilities that are effectively accomplish the mission or fulfill the business need. 

This looks like a map for the increasing value delivery for an insurance company. The map shows the path or actually paths to home. Home is the ability to generate value from the exchange of money to develop the software.

Project Maturity Flow is the Incremental Delivery of Business Value

Related articles Golden Ratio Managing In The Presence Uncertainty Impact Mapping and Integrated Master Planning We Can Know the Business Value of What We Build All Project Work is Probabilistic Work 5 Questions That Need Answers for Project Success
Categories: Project Management

Quote of the Day

Herding Cats - Glen Alleman - Tue, 08/26/2014 - 13:16

"All the mathematical sciences are founded on relations between physical laws and laws of numbers, so that the aim of exact science is to reduce the problems of nature to the determination of quantities by operations with numbers."
— James Clerk Maxwell, On Faraday's Lines of Force, 1856

Categories: Project Management

Quote of the Month August 2014

From the Editor of Methods & Tools - Tue, 08/26/2014 - 09:55
We don’t mean that you should put on your Super Tester cape and go protect the world from bugs. There’s no room for big egos on agile teams. Your teammates share your passion for quality. Focus on the teams goals and do what you can to help everyone do their best work. Source: Agile Testing, Lisa Crispin and Janet Gregory, Addison Wesley

Management is Prediction - W. Edwards Deming

Herding Cats - Glen Alleman - Tue, 08/26/2014 - 01:44

DemingThis statement Management is Prediction is the basis of the microeconomics of writing software for money, someone else's money. 

Along with the quote of Daniel Boorstin's, The greatest obstacle to discovery is not ignorance – it is the illusion of knowledge. Boorstin was the Librarian of Congress. One of his other quotes was once the subtitle of this blog I Write to Discover What I Think.

And here's what I think about the predictive nature of managing projects. If we don't know how to estimate the impacts of our decisions on the future outcomes of those decisions, we have the illusion of knowledge, when in fact we have no knowledge.

There is a popular myth, that estimating the future outcomes of our present day decisions is somehow voodoo, guessing, making things up, and having our management treat them as commitments. It's clear we didn't pay attention in the probability and statistics class. Or worse yet, we have intentionally ignored what we did learn in that probability and statistics class. Thinking naively or with intent ignoring the probabilistic nature of all project work.

All variables in project work are random variables. These variables are almost always coupled to each other in some way, usually a non-linear way. Fix one variable, the other two are free to be variable. Fix two variables, the third variable is free. Fix all three, they still vary. This is the primary reason margin is needed for project to have a credible chance of showing up on time, on budget, and on value. These variances are Irreducible, meaning they will vary no matter what you do. Fixing Budget, only fixes the amount of money you've allocated to the project. It doesn't fix the cost to produce the value from the project, nor the time to produce that value.

Slide1

So Why Do We Estimate?

When ever possible we should use evidence in making decisions about project variables. Observing the behaviour of the variables in an attempt to see what they are doing, where they are going, what the next outcome might be. 

This is the basis of the OODA Loop. Boyd was an Air Force fighter pilot, and like Jeff Sutherland of agile fame, understood that emerging situations are the norm in the skies of Vietnam, just like they are on projects.

OODA ClipThe OODA loop is often popularized as four elements going around in a circle. The picture is the only diagram Boyd ever drew. Boyd's OODA Loop describes the details. The title of the chart above comes from one of our briefings for Managing in the Presence of Uncertainty. But the domain OODA is applicable is not restricted to DOD acquisition, but is applicable in any domain where money, time, and performance are at risk.

Just to push a little harder, when you hear about Clausewitz and Tzu from agile coders, remember Boyd's comments when he spoke in public

“Don’t be a member of Clausewitz’s school because a lot has happened since 1832,” he would warn his audiences, “and don’t be a member of Sun Tzu’s school because an awful lot has happened since 400 BC.”

So just like those reference to 1968 reference to the Software Crisis - a lot has happened since then.

So Here's a Simple Fact

Also often ignored by some wanting us to learn to decide without knowing the impacts of those decisions.

People learn better when they predict

Making an estimate about the future — predicting on outcome or impact — forces us to think ahead about those very outcomes. Making an estimate causes us to examine more deeply the system we are observing and our engagement with that system and our reactions to the system. It causes us to question our understanding of the system as it is now — in  its current state — and what we would like it to be in its future state. As well, by making estimating about future outcomes, we can learn more about our understanding of the management beliefs we hold as we examine the results of our predictions.

So like Deming tells us ...

Management is Prediction

Not making prediction's about the impact of our decisions, the processes affected by those decisions, like - cost, schedule, and technical performance - shown in the three legged picture above, ignores the principles of Deming. And when we do that, ...

... we're not managing how we spend other peoples money.

The only way this notion can't be called bad management is if the amount of money at risk is low enough that those providing the money don't care if we waste it or not.

Related articles Making Estimates For Your Project Require Discipline, Skill, and Experience Why We Must Learn to Estimate The OODA Loop - Insight into Strategic Thinking An Agile Estimating Story Averages Without Variances are Meaningless - Or Worse Misleading Four Critical Elements of Project Success The Value of Information What does a "broken OODA loop" look like? How To Create Confusion About Root Causes
Categories: Project Management

Capacity Planning and the Project Portfolio

I was problem-solving with a potential client the other day. They want to manage their project portfolio. They use Jira, so they think they can see everything everyone is doing. (I’m a little skeptical, but, okay.) They want to know how much the teams can do, so they can do capacity planning based on what the teams can do. (Red flag #1)

The worst part? They don’t have feature teams. They have component teams: front end, middleware, back end. You might, too. (Red flag #2)

Problem #1: They have a very large program, not a series of unrelated projects. They also have projects.

Problem #2: They want to use capacity planning, instead of flowing work through teams.

They are setting themselves up to optimize at the lowest level, instead of optimizing at the highest level of the organization.

If you read Manage Your Project Portfolio: Increase Your Capacity and Finish More Projects, you understand this problem. A program is a strategic collection of projects where the business value of the all of the projects is greater than any one of the projects itself. Each project has value. Yes. But all together, the program, has much more value. You have to consider the program has a whole.

Don’t Predict the Project Portfolio Based on Capacity

If you are considering doing capacity planning on what the teams can do based on their estimation or previous capacity, don’t do it.

First, you can’t possibly know based on previous data. Why? Because the teams are interconnected in interesting ways.

When you have component teams, not feature teams, their interdependencies are significant and unpredictable. Your ability to predict the future based on past velocity? Zero. Nada. Zilch.

This is legacy thinking from waterfall. Well, you can try to do it this way. But you will be wrong in many dimensions:

  • You will make mistakes because of prediction based on estimation. Estimates are guesses. When you have teams using relative estimation, you have problems.
  • Your estimates will be off because of the silent interdependencies that arise from component teams. No one can predict these if you have large stories, even if you do awesome program management. The larger the stories, the more your estimates are off. The longer the planning horizon, the more your estimates are off.
  • You will miss all the great ideas for your project portfolio that arise from innovation that you can’t predict in advance. As the teams complete features, and as the product owners realize what the teams do, the teams and the product owners will have innovative ideas. You, the management team, want to be able to capitalize on this feedback.

It’s not that estimates are bad. It’s that estimates are off. The more teams you have, the less your estimates are normalized between teams. Your t-shirt sizes are not my Fibonacci numbers, are not that team’s swarming or mobbing. (It doesn’t matter if you have component teams or feature teams for this to be true.)

When you have component teams, you have the additional problem of not knowing how the interdependencies affect your estimates. Your estimates will be off, because no one’s estimates take the interdependencies into account.

You don’t want to normalize estimates among teams. You want to normalize story size. Once you make story size really small, it doesn’t matter what the estimates are.

When you  make the story size really small, the product owners are in charge of the team’s capacity and release dates. Why? Because they are in charge of the backlogs and the roadmaps.

The more a program stops trying to estimate at the low level and uses small stories and manages interdependencies at the team level, the more the program has momentum.

The part where you gather all the projects? Do that part. You need to see all the work. Yes. that part works and helps the program see where they are going.

Use Value for the Project Portfolio

Okay, so you try to estimate the value of the features, epics, or themes in the roadmap of the project portfolio. Maybe you even use the cost of delay as Jutta and I suggest in Diving for Hidden Treasures: Finding the Real Value in Your Project Portfolio (yes, this book is still in progress). How will you know if you are correct?

You don’t. You see the demos the teams provide, and you reassess on a reasonable time basis. What’s reasonable? Not every week or two. Give the teams a chance to make progress. If people are multitasking, not more often than once every two months, or every quarter. They have to get to each project. Hint: stop the multitasking and you get tons more throughput.

Categories: Project Management

What I Don't Know Can Actually Hurt Me

Herding Cats - Glen Alleman - Fri, 08/22/2014 - 19:23

Ostrich Head in SandThe notion of not knowing the impact of decisions, choices, approaches is like putting your head in the sand because you don't like the answer or don't what to know the answer.

In our domain there are three common root causes for program difficulties when the program overruns it's budget, shows up late, or the delivered product doesn't work as required

  1. They couldn't know - the source the problem was in fact unknowable.
  2. They didn't know - the source of the problem was knowable, but the effort to discover it was done.
  3. They dodn't want to know - the source of the problem was there, but if it was made visible the project would be canceled or not started

When I read about decision making processes like ...

Screen Shot 2014-08-22 at 12.07.24 PM

I'm struck by the 3rd statement. Knowing something about the cost of a decision, the outcome of an investment, the risks, scope impact, progress reporting of future values requires you make estimates. Since all project variables are random variables that interact in random ways - technically non-stationary stochastic processes - knowing about the impacts from deciding anything using these variables means estimating the three core variables of all projects, shown below.

When I hear the suggestion that decisions can be made in the absence of those estimates, think of the Ostrich, ask the following:

  • Can I decide about some future outcome without estimating the impact of that outcome?
  • If I'm going to invest - spend money - can I do the ROI calculation in the absence of the estimate of the cost or the value - since neither of those are known on day one?
  • Risk - by it's very definition - is an uncertainty. These uncertainty are probabilistic outcomes of future events. Estimates are needed.

If there ways to decide these things without estimates, let's hear them. Each of the three variables and each of their drivers is a random variable whose value is not know in the present, but can only be knowing with an estimate of it's future possible values.

Screen Shot 2014-08-22 at 12.11.42 PM

Related articles Resources for Moving Beyond the "Estimating Fallacy" Making Estimates For Your Project Require Discipline, Skill, and Experience Four Critical Elements of Project Success First Comes Theory, Then Comes Practice How to Deal With Complexity In Software Projects? Statistical Process Control The Basis of All Modern Control Systems Let's Stop Guessing and Learn How to Estimate The Value of Information Why is Statistical Thinking Hard?
Categories: Project Management

The Plague of Methods and Frameworks

NOOP.NL - Jurgen Appelo - Thu, 08/21/2014 - 16:33
Methods and Frameworks

I know of no industry in the world that is as infested with methods and frameworks as the software business. Whether it’s RUP, XP, Scrum, AUP, DAD, or SAFe, it seems IT businesses are always looking for yet another method or framework that they can “implement” next month.

The post The Plague of Methods and Frameworks appeared first on NOOP.NL.

Categories: Project Management

Software Development Linkopedia August 2014

From the Editor of Methods & Tools - Thu, 08/21/2014 - 14:48
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 Agile retrospectives, software architecture, software developer psychology, software testing  in Agile teams, quality code and the (funny) history of programming. Web site: Fun Retrospectives Blog: How to make software architecture decisions? Blog: Cognitive Biases in Software Engineering Blog: How the Other Half Works: an Adventure in the Low Status of Software Engineers Blog: Confessions of an ex-developer Article: Tearing Down the Walls – Embedding QA in a TDD/Pairing and ...

No News is Bad News - Feedback Must Create Steering Signal from Plan †

Herding Cats - Glen Alleman - Wed, 08/20/2014 - 22:41

Screen Shot 2014-08-20 at 12.39.03 PMProject Manager: How's the project progressing to plan? 

Developers: We're spending money, consuming resources, producing outputs that the customer likes. 

Project Manager: I was more interested in what's our performance against our planned spend, planned resource consumption, and planned outputs of value to the customer? 

Developers: What do you mean, we didn't estimate any of that, we're managing this project with #NoEstimates. You know that new alternative to estimates for making decisions in software development. That is ways to make decisions with "No Estimates." of the impacts on the future of those estimates or of our work on the future cost, schedule, or technical performance. You know where we can use Decision making frameworks for projects that do not require estimates, or apply Investment models for software projects that do not require estimates, and have our project management methods for risk management, scope management, progress reporting, not require any of those annoying estimates. 'Cause we kinda suck at them anyway, so we just decided instead of learning how to estimate, we'll just not estimate and get back to coding.

Project Manager: Oh, you mean that approach of managing other peoples money that violates the principles of software microeconomics with Open Loop Control - where our organization can make business decisions on the allocation of our limited resources, without examining how those decisions effect the supply and demand of our resources. You do know about those resources? Like money, people, and time?

Developers: Yea, we don't need any that mumbo jumbo microeconomics that we all learned in school, since we didn't pay attention in that boring the statistics and probability class that tried to teach us that all variables on a project are actually random variables and we should to know something about their behaviour in the future if we're going have a hope in hell of ever managing this project in the presence of uncertainty about those values.

Project Manager: What's that smell? Maybe we'd better start rearranging the deck chairs on our ship here real soon, cause I smell an Iceberg getting closer.

No project can be managed to successful closure in the absence of steering targets defined at periodic intervals for the expenditure of cost, schedule, and technical performance. Knowing what those steering targets should be requires estimating their values, then measures the actual values to develop the needed steering signal - the variance between plan and actual.

The only way out of the need to estimate those intermediate steering targets is to straight line the budget, schedule, and needed technical performance - from start to end, then measure the actual performance. 

Like the intended route of the Titanic, our project does not proceed in a straight line, so that idea is a non-starter. And like the Titanic, our project cannot confuse the intended speed with the actual speed, just like we can't confuse the budget - the total planned crossing time - with the actual cost - the actual total crossing time.

Titanic-Route

Without those pesky intermediate targets to steer toward - those targets created by estimating the needed cost, needed scheduled arrival date, and, needed capabilities on the needed date for the needed cost. We're managing the project Open Loop, driving in a straight line. Never knowing what will pop up in front of our path. 

Say good bye to Kate Leonardo, you're gonna get wet.

† Full attribution for the inspiration for this post comes from the very useful blog by Gene Hughson

Related articles Staying on Plan Means Closed Loop Control How Not To Make Decisions Using Bad Estimates Control Systems - Their Misuse and Abuse More Than Target Needed To Steer Toward Project Success Why Project Management is a Control System
Categories: Project Management

The Agile Household: How Scrum Made Us a Better Family

Mike Cohn's Blog - Wed, 08/20/2014 - 20:13

I’m always fascinated by stories about Scrum (or any agile process) being used outside of software development. When Martin Lapointe told me how he and his family used Scrum -- and especially a task board -- to manage their recent relocation from Paris to Montreal, I immediately asked him to share that story. I’m sure you’ll find it as interesting, amusing, and informative as I did. - Mike Cohn

Ever since discovering the “Agile Manifesto,” I have been trying to integrate its core set of values into my day-to-day routines in hopes of improving processes outside of the office environment. With this in mind, my family and I embarked on an agile adventure that produced amazing results we never expected!

Since my childhood, I have longed to live and experience life in a different country. I have always been especially interested in exploring Europe in hopes of better understanding the many different cultures that make it such an amazing place. This dream had always been on the back burner, and then in 2011, with the help of my wife, Pascale, and my two girls, Elisabeth and Sarah (8 and 5 years old), we decided to make it a reality.

Carpe Diem (Seize the Day)!

With our family mantra in mind, we picked up, left Montreal and migrated to Paris, France.

As expected, when displacing a family of four from a three-story house to a small Parisian apartment, the move was exhausting and quite chaotic. Almost right off the plane, I started my new job as a ScrumMaster at a telecom company, and meanwhile, Pascale embarked on her new role as “Product Owner” of our household. Our two girls were rapidly immersed into the Parisian lifestyle and school system.

"With our family in mantra in mind, we picked up, left Montreal and migrated to Paris, France."

The next two years flew by at light speed! Before we knew it, it was time to start planning our return to Canada.

Looking back on our initial move to Paris, we wish we had better prepared ourselves and been more organized as a family while facing this major life change. In the face of another move, we began thinking of ways to approach yet another life changing experience.

Our hearts filled with emotions as we started compiling our to-do lists of Post-its that had to be completed before D-day. As the tasks piled up, we started to wonder how we could possibly get all of this done while trying to maintain a balance of work and living a happy life until the end of our European adventure.

What if Scrum Was the Answer to Our Challenge?

Then, one night, we said to ourselves let’s try something different. What if Scrum was the answer to our challenge? In the agile world, we try to leverage experience and failures to improve, so why not use the same approach to our big move?

Having some positive experiences experimenting with Scrum on a non-IT related team, I said to myself, why not take the same approach with my family? So, we gathered in our bedroom with our Post-its and sharpies in hand, and said, let’s create a backlog!

Elisabeth, being the curious one, immediately asked me, “Daddy, what’s a backlog?” I responded by explaining that a backlog is everything we need to do before leaving Paris. Elisabeth quickly asked, “Can I add the Eiffel tower carrousel to the backlog?” Of course, we said yes!

Mom then asked, “Can we also add taking out the trash?” I said yes, of course! Within seconds, everybody was writing valid stories down on Post-its. Sarah drew her story, because she hadn’t learned to write yet: a picture of her favourite Parisian sweets, Pierre Hermé macarons!

In one evening we compiled more than 50 family stories. These stories weren’t perfect by any means. There were no acceptance criteria, no estimations, but the girls were on board, and dare I say it, excited, and that was more than enough!

Next, we asked ourselves: what can we realistically accomplish in a week? Mom wanted to add the entire house cleaning tasks to the backlog. The girls wanted to add all of the fun stuff, and I wanted to add the must-see tourist attractions we hadn’t yet visited.

So we took a small board and made three columns: “To do,” “Ongoing” and “Done.” We negotiated ruthlessly, but ultimately Elisabeth and Sarah got the most stories in (don’t worry! The parents got their revenge in the following iterations ☺). The first iteration was about to begin.

"We had never seen this much work get done so fast, with so much happiness, ease, understanding and visibility!"

The Scrum momentum was on. We agreed upon one-week iterations (sprints) and then took time on the weekends to plan the next iteration. Each morning, we would have a quick gathering (daily stand-up) and the girls were very anxious to move the Post-its around the board. We had never seen so much work get done so fast, with so much happiness, ease, understanding and visibility!

With the Scrum approach, we were able to get the entire apartment-cleaning task list done, administrative tasks complete and some great museum visits in without any conflicts. Scrum was turning out to be a great tool for our family to use when trying to improve clarity and set priorities for big challenges!

We had the joy of experiencing our last days in Paris in a way that we will never forget.

Scrum Was Turning Out to be a Great Tool for Our Family

Back in Montreal, it seemed as though something was missing … It was Scrum! Realising this, we started a new backlog in the basement, and added a cork Scrum board in the kitchen. Our activities are now visible and updated each morning at the breakfast table.

If there’s one overlying factor that we’ve taken away from this experience it’s that we are so proud to be an agile family!




 

The Agile Household: How Scrum Made Us a Better Family

Mike Cohn's Blog - Wed, 08/20/2014 - 20:13

I’m always fascinated by stories about Scrum (or any agile process) being used outside of software development. When Martin Lapointe told me how he and his family used Scrum -- and especially a task board -- to manage their recent relocation from Paris to Montreal, I immediately asked him to share that story. I’m sure you’ll find it as interesting, amusing, and informative as I did. - Mike Cohn

Ever since discovering the “Agile Manifesto,” I have been trying to integrate its core set of values into my day-to-day routines in hopes of improving processes outside of the office environment. With this in mind, my family and I embarked on an agile adventure that produced amazing results we never expected!

Since my childhood, I have longed to live and experience life in a different country. I have always been especially interested in exploring Europe in hopes of better understanding the many different cultures that make it such an amazing place. This dream had always been on the back burner, and then in 2011, with the help of my wife, Pascale, and my two girls, Elisabeth and Sarah (8 and 5 years old), we decided to make it a reality.

Carpe Diem (Seize the Day)!

With our family mantra in mind, we picked up, left Montreal and migrated to Paris, France.

As expected, when displacing a family of four from a three-story house to a small Parisian apartment, the move was exhausting and quite chaotic. Almost right off the plane, I started my new job as a ScrumMaster at a telecom company, and meanwhile, Pascale embarked on her new role as “Product Owner” of our household. Our two girls were rapidly immersed into the Parisian lifestyle and school system.

"With our family in mantra in mind, we picked up, left Montreal and migrated to Paris, France."

The next two years flew by at light speed! Before we knew it, it was time to start planning our return to Canada.

Looking back on our initial move to Paris, we wish we had better prepared ourselves and been more organized as a family while facing this major life change. In the face of another move, we began thinking of ways to approach yet another life changing experience.

Our hearts filled with emotions as we started compiling our to-do lists of Post-its that had to be completed before D-day. As the tasks piled up, we started to wonder how we could possibly get all of this done while trying to maintain a balance of work and living a happy life until the end of our European adventure.

What if Scrum Was the Answer to Our Challenge?

Then, one night, we said to ourselves let’s try something different. What if Scrum was the answer to our challenge? In the agile world, we try to leverage experience and failures to improve, so why not use the same approach to our big move?

Having some positive experiences experimenting with Scrum on a non-IT related team, I said to myself, why not take the same approach with my family? So, we gathered in our bedroom with our Post-its and sharpies in hand, and said, let’s create a backlog!

Elisabeth, being the curious one, immediately asked me, “Daddy, what’s a backlog?” I responded by explaining that a backlog is everything we need to do before leaving Paris. Elisabeth quickly asked, “Can I add the Eiffel tower carrousel to the backlog?” Of course, we said yes!

Mom then asked, “Can we also add taking out the trash?” I said yes, of course! Within seconds, everybody was writing valid stories down on Post-its. Sarah drew her story, because she hadn’t learned to write yet: a picture of her favourite Parisian sweets, Pierre Hermé macarons!

In one evening we compiled more than 50 family stories. These stories weren’t perfect by any means. There were no acceptance criteria, no estimations, but the girls were on board, and dare I say it, excited, and that was more than enough!

Next, we asked ourselves: what can we realistically accomplish in a week? Mom wanted to add the entire house cleaning tasks to the backlog. The girls wanted to add all of the fun stuff, and I wanted to add the must-see tourist attractions we hadn’t yet visited.

So we took a small board and made three columns: “To do,” “Ongoing” and “Done.” We negotiated ruthlessly, but ultimately Elisabeth and Sarah got the most stories in (don’t worry! The parents got their revenge in the following iterations ☺). The first iteration was about to begin.

"We had never seen this much work get done so fast, with so much happiness, ease, understanding and visibility!"

The Scrum momentum was on. We agreed upon one-week iterations (sprints) and then took time on the weekends to plan the next iteration. Each morning, we would have a quick gathering (daily stand-up) and the girls were very anxious to move the Post-its around the board. We had never seen so much work get done so fast, with so much happiness, ease, understanding and visibility!

With the Scrum approach, we were able to get the entire apartment-cleaning task list done, administrative tasks complete and some great museum visits in without any conflicts. Scrum was turning out to be a great tool for our family to use when trying to improve clarity and set priorities for big challenges!

We had the joy of experiencing our last days in Paris in a way that we will never forget.

Scrum Was Turning Out to be a Great Tool for Our Family

Back in Montreal, it seemed as though something was missing … It was Scrum! Realising this, we started a new backlog in the basement, and added a cork Scrum board in the kitchen. Our activities are now visible and updated each morning at the breakfast table.

If there’s one overlying factor that we’ve taken away from this experience it’s that we are so proud to be an agile family!