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

Statistical Significance

Herding Cats - Glen Alleman - Tue, 09/16/2014 - 23:58

Screen Shot 2014-09-16 at 4.33.40 PMThe term statistical significance is critical to most every discussion about spending other peoples money with some new and innovative process.

When we here I know a CEO that uses my approach, we need to ask several critical questions both getting too excited about this idea that is being suggested. Especially is this new idea violates some core business processes, like Microeconomics, let alone FASB 86, GAAP cost and revenue recognition.

  1. Is that CEO the CEO of a publically traded firm, subject to governance processes? If so, some outside the developer communbity gets to say if the new and innovative idea hasn't violated the business rules.
  2. Does that CEO's company live a domain where what they do is like what other people do? You know a Reference Class that can be used outside the ancedote.
  3. Does that CEO have to report cash obliogations to his line or credit or banker for some planning horizon in the future? Those pesky bankers do like know the cash call demands from your firm for that LOC.

The notion of an anecdote is always interesting in conversation I knew a guy once who .... But can we make policy decisions based on anecdotes? Hopefully not. 

We can make policy decisions based on statistically sound observation - 8 out 10 dentist recommend Pepsident Toothpaste was a popular advertisement in the 1970's.

This leads us back to How To Lie With Statistics and the self-selected sample space. 

  • Let me ask all the people I ride with in our cycling club what they think of the local brewery where we leave from on Tuesday evenings, what they think of the Nitro Milk Stout that is served for free. We like it.

Without a statistical sound sample space, a statistically sounds sampling processes, any conclusion are just ancedote. This is the core issue with things like the Standish report and other surveys suggesting the sky is falling on IT projects. 

The same goes for thosie suggesting their favorite apporoach to spending other peoples can be done in the absence of knowing hwo much money, when that money will produce value, and what kinds of value will be produced.

Ask for data. No data, then as they say "Data Talks, BS walks"

† The carton above is from Hugh MacLoed, gapingvoid art, 1521 Alton Road, Suite #518, Miami Beach, FL 33139. I've been following him since day one. You shold do the same and buy his book

Related articles Another Nonsense Statistical Survey The Failure of Open Loop Thinking How to "Lie" with Statistics FASB Issues 2015 GAAP Financial Reporting Taxonomy for Public Review How Not To Make Decisions Using Bad Estimates Can Agile Be Integrated with Governance Based Development Processes? How To Fix Martin Fowler's Estimating Problem in 3 Easy Steps What Software Domain Do You Work In? All Project Work is Probabilistic Work
Categories: Project Management

Don’t Equate Story Points to Hours

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

I’ve been quite adamant lately that story points are about time, specifically effort. But that does not mean you should say something like, “One story point = eight hours.”

Doing this obviates the main reason to use story points in the first place. Story points are helpful because they allow team members who perform at different speeds to communicate and estimate collaboratively.

Two developers can start by estimating a given user story as one point even if their individual estimates of the actual time on task differ. Starting with that estimate, they can then agree to estimate something as two points if each agree it will take twice as long as the first story.

When story points equated to hours, team members can no longer do this. If someone instructs team members that one point equals eight (or any number of) hours, the benefits of estimating in an abstract but relatively meaningful unit like story points are lost.

When told to estimate this way, the team member will mentally estimate first in number of hours and then convert that estimate to points. Something the developer estimates to be 16 hours will be converted to 2 points.

Contrast this with a team member’s thought process when estimating in story points as they are truly intended. In this case, team members will consider how long each new story will take in comparison to other stories. You and I might agree this new story will take twice as long as a one-point story, and so we agree it’s a two.

However, you might be thinking that’s five hours of work, and I might be thinking it’s 10. In this way, story points are still about time (effort), but the amount of time per point is not pegged to the same amount for all team members.

If someone in your company wants to peg one point to some number of hours, just stop calling them points and use hours or days instead. Calling them points when they’re really just hours introduces needless complexity (and loses one of the main benefits of points).

 

 

 

 

 

 

 

 

Don’t Equate Story Points to Hours

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

I’ve been quite adamant lately that story points are about time, specifically effort. But that does not mean you should say something like, “One story point = eight hours.”

Doing this obviates the main reason to use story points in the first place. Story points are helpful because they allow team members who perform at different speeds to communicate and estimate collaboratively.

Two developers can start by estimating a given user story as one point even if their individual estimates of the actual time on task differ. Starting with that estimate, they can then agree to estimate something as two points if each agree it will take twice as long as the first story.

When story points equated to hours, team members can no longer do this. If someone instructs team members that one point equals eight (or any number of) hours, the benefits of estimating in an abstract but relatively meaningful unit like story points are lost.

When told to estimate this way, the team member will mentally estimate first in number of hours and then convert that estimate to points. Something the developer estimates to be 16 hours will be converted to 2 points.

Contrast this with a team member’s thought process when estimating in story points as they are truly intended. In this case, team members will consider how long each new story will take in comparison to other stories. You and I might agree this new story will take twice as long as a one-point story, and so we agree it’s a two.

However, you might be thinking that’s five hours of work, and I might be thinking it’s 10. In this way, story points are still about time (effort), but the amount of time per point is not pegged to the same amount for all team members.

If someone in your company wants to peg one point to some number of hours, just stop calling them points and use hours or days instead. Calling them points when they’re really just hours introduces needless complexity (and loses one of the main benefits of points).

 

 

 

 

 

 

Quote of the Month September 2014

From the Editor of Methods & Tools - Tue, 09/16/2014 - 13:36
The important thing is not your process, the important thing is the process for improving your process. Source: Henrik Kniberg, http://blog.crisp.se/wp-content/uploads/2013/08/20130820-What-is-Agile.pdf

Projects Where You Can’t Predict an End Date

Do you have projects where you can’t predict an end date? These tend to be a job search, a change project, and with a tip of the hat to Cesar Abeid, your life. I like to call these “emergent” projects.

You might prefer to call them “adaptable” projects, but to me, every project has to be adaptable. These projects are emergent. You need to plan, but not too much. You need to replan. You need to take advantage of serendipity.

My column this quarter for projectmanagement.com is Applying Agile to Emergent Projects. (Free registration required.)

Enjoy!

Categories: Project Management

Quote of the Day - Plan for the Future

Herding Cats - Glen Alleman - Tue, 09/16/2014 - 01:05

Before you begin a thing remind yourself that difficulties and delays quite impossible to foresee are ahead. You can only see one thing clearly, and that is your goal. Form a mental vision of that and cling to it through thick and thin.
— Kathleen Norris

Screen Shot 2014-09-15 at 3.58.10 PMAnd when they are impossible to see we need margin and reserve to protect our project from them. This margin is for the irreducible risks and the reserve is for buying down the reducible risks. Both irreducible (aleatory) and reducible (epistemic) uncertainties can be modeled for all projects. This is the role of risk management and project. To NOT model these uncertainties is to ignore them. To ignore them is to say to those providing the money that you're not following Tim Lister's advice...

Risk Management is how Adults manage projects

As well when you begin a thing remember another important quote...

Measurement is the first step that leads to control and eventually to improvement. If you can’t measure something, you can’t understand it. If you can’t understand it, you can’t control it. If you can’t control it, you can’t improve it. ― H. James Harrington

So if we're going to start a job and don't have an assessment - to some level of confidence - of how long it will take, how much it will cost, and what we will be capable of delivering when we get to the end of the money and the time - it is very likely that those paying for our work will be very disappointed in our efforts.

When we here that we can make decisions in the absence of knowing the probabilistic cost, schedule, and likelihood of producing the needed capabilities, think back to the two quotes above. And consider the conjectures below that requires us to ignore those quote and instead follow those statements in the absence of any evidence they are applicable outside of the Value at Risk being low enough that those providing the money don't really care if it's all a loss.

Workshop

† Orginal post from Mark Anderson's email from ExecuNet, 9/14/2014

Related articles Uncertainty is the Source of Risk The World of Probability and Statistics How to Deal With Complexity In Software Projects? Both Aleatory and Epistemic Uncertainty Create Risk Time to Revisit The Risk Discussion
Categories: Project Management

Why I Changed the Title of My New Book

NOOP.NL - Jurgen Appelo - Mon, 09/15/2014 - 14:40
Register for a FREE book!

#WorkoutThe original title of my new book was Management 3.0 Workout. It was the result of a long and challenging process in which I learned that readers of my newsletter liked the Management 3.0 brand and also the workout metaphor that I used in many of my articles and chapters.

So, why did I change it to #Workout for the Amazon Kindle edition?

The post Why I Changed the Title of My New Book appeared first on NOOP.NL.

Categories: Project Management

The Release Paradox: releasing less often makes your teams slower and decreases quality

Software Development Today - Vasco Duarte - Mon, 09/15/2014 - 04:00

Herman is a typical agile coach. He works with teams to help them learn how to deliver high-quality software quickly.
Many teams want to focus on design, architecture, or (sometimes) even on business value. But they are usually not in a hurry to release quickly.
Recently Herman conveyed a story to me that illustrates how releasing quickly can help teams deliver high-quality software much faster than if they would focus on quality in the first place. This is the case of a team that was working on a long overdue project. They had used a traditional and linear process in the past and had been able to release software only very recently, after more than 12 months of work on the latest release.
Not surprisingly, they were having trouble releasing regularly. The software was not stable; once it was live it had many problems that needed to be fixed quickly, and worst of all: all of this was having a direct impact on the company’s business.
The teams were extremely busy fixing the problems they had added to the product in the last year and could not focus on solving the root causes of those problems.
They were in full-fledged firefighting mode. They worked hard every day to fix yet another problem and release yet another hot fix.
This lasted for a few weeks, but once the fire-fighting mode was over, Herman worked with the teams to improve their release frequency. During their work with Herman, those teams went from one year without any release to a regular release every two weeks.
At first the releases were not always possible, but with time they improve their processes, removed the obstacles preventing them from releasing every two weeks and started releasing regularly.
What happened next was surprising for the teams. The list of problems after each release did not grow - as they expected - but instead shrank.
When some problems came in from the customers after a 2-week release, they were also much faster to fix the problem and quicker to release a fix if that was required. When the fix was not critical, they waited for the following release which was, after all, only 2 weeks away.
By focusing on releasing every two weeks, Herman’s teams were able to focus on small, incremental changes to their product. That, in turn, enabled them to fine-tune their development and release processes.
Here are some of the key changes the teams implemented
  1. They started with a 4 week release cycle, and fine-tuned their daily builds and release testing process to enable a release every 2 weeks.
  2. They invested time and energy to improve their test automation strategy and automated the critical tests to enable them to run “enough” tests to be confident that the quality was at release level.
  3. They had some teams on maintenance duty in the first few iterations to make sure that any problem found after release could quickly be fixed, and released to customers if necessary.
  4. They changed their source code management strategy to enable some teams to work on longer term changes while others worked on the next release.
  5. They involved all teams necessary to complete a release in their iterations. This affected especially: production/operations team, localization team, documentation team, marketing team, and other teams when needed.
This list of changes was the result of the drive to complete each release and learning from the failures in the previous release. Some changes were harder to implement, and especially the testing strategy to allow for 2-week release cycles had to be changed and adjusted several times.
One of the key problems the teams had to solve, was the lack of coordination with departments that directly contributed to the release but were not previously involved in their day-to-day work.
This process lasted several months, and would not have been possible without a clear Vision set forth by the teams in cooperation with Herman, who helped them discover the right way to reach that Vision within their context.
Herman’s work as a coach was that of a catalyst for management and the teams in that organization. He was able to create in their minds a clear picture of what was possible. Once that was clear, the teams and the management took ownership of the process and achieved a step-change in their ability to fulfill market demands and customer needs.
Customers have no reason to change provider as they have an ever-improving experience when using this company’s services.
Today, this organization releases a new version of their product every two weeks. Unaware of it, their customers receive regular improvements to the product they use, and have no reason to change provider as they have an ever-improving experience when using this company’s services.

Picture credit: John Hammink, follow him on twitter

GAO Reports on ACA Site

Herding Cats - Glen Alleman - Fri, 09/12/2014 - 19:08

With all the speculation on what went wrong with the ACA site and all the agile pundits making statements about how agile could have saved the site, here's some actual facts beyond all the opinions - that Daniel Patrick Moynihan would remind us...

Every man is entitled to his own opinion, but not his own facts

 

  Screen Shot 2014-09-12 at 11.40.52 AM

and

Screen Shot 2014-09-12 at 11.42.53 AM

The Key Findings are

  • Oversight weakness and lack of adherence to planning requirements.
  • Acquisition planning carried high levels of risk.
  • Requirements for developing the FFM were not well defined.
  • Contract type carried risk for the government.
  • New IT development approach was supposed to save time, but carried unmitigated risk.
  • Contractor did not fully adhere to HHS procurement guidelines, missing opportunities to capture and consider risk important to program success.
  • Changing requirements and oversight contributed to significant cost growth, schedule delays, and reduced capabilities.
  • Unclear contract oversight responsibilities exacerbated cost growth.
  • Significant contractor performance issues without corrective actions.

So when we hear 

Workshop

Think in what domain, with what value at risk, with what complexity of project, and what business process in which these could possibly be applicable. In fact this goes back to the core of the agile manifesto. And when we hear "pure agile," Scrum Masters produce Scrum Slaves, Mob Programming, "we all want a seat at the table with equal voices, and many other "opinions," remember Moynihan and ask for facts, domain, past performance, experience, and examples of success.

As agile starts to scale to larger domains and the government seeks better ways to develop software beyond the failed processes described above - what parts of this manifesto are applicable outside of a small group of people in the same room with the customer directing the work of the developers?

As my colleague (former NASA Cost Director) reminds our team if you see something that doesn't make sense - follow the money. In the case of ACA and in the case of the Work Shop outcomes above.

Related articles Can Agile Be Integrated with Governance Based Development Processes? Agile Means ... Can Enterprise Agile Be Bottom Up? Agile as a Systems Engineering Paradigm How To Create Confusion About Root Causes Agile and the Federal Government Quote of the Day - Just a Little Process Check Sailing and Agile
Categories: Project Management

Cost, Value & Investment: How Much Will This Project Cost? Part 2

This post is continued from Cost, Value & Investment: How Much Will This Project Cost, Part 1

We’ve established that you need to know how much this project will cost. I’m assuming you have more than a small project.

If you have to estimate a project, please read the series starting at Estimating the Unknown: Dates or Budget, Part 1. Or, you could get Essays on Estimation. I’m in the midst of fixing it so it reads like a real book. I have more tips on estimation there.

For a program, each team does this for its own ranked backlog:

  • Take every item on the backlog and roadmap, and use whatever relative sizing approach you use now to estimate. You want to use relative sizing, because you need to estimate everything on the backlog.
  • Tip: If each item on the backlog/roadmap is about team-day or smaller, this is easy. The farther out you go, the more uncertainty you have and the more difficult the estimation is. That’s why this is a tip.
  • Walk through the entire backlog, estimating as you proceed. Don’t worry about how large the features are. Keep a count of the large features. Decide as a team if this feature is larger than two or three team-days. If it is, keep a count of those features. The larger the features, the more uncertainty you have in your estimate.
  • Add up your estimate of relative points. Add up the number of large features. Now, you have a relative estimate, which based on your previous velocity means something to you. You also have a number of large features, which will decrease the confidence in that estimate.
  • Do you have 50 features, of which only five are large? Maybe you have 75% confidence in your estimate. On the other hand, maybe all your features are large. I might only have 5-10% confidence in the estimate. Why? Because the team hasn’t completed any work yet and you have no idea how long your work will take.
Technical Program with Communities of Practice

Technical Program with Communities of Practice

As a software program team, get together, and assess the total estimate. Why the program team? Because the program team is the cross-functional team whose job is to get the software product to done. It’s not just the software teams—it’s everyone involved in the technical program team.

Note: the teams have to trust Sally, Joe, Henry and Tom to represent them to the software program team. If the teams do not, no one has confidence in any estimate at all. The estimate is a total SWAG.

The delegates to the program team know what their estimates mean individually. Now, they “add” them together, whatever that means. Do you realize why we will call this prediction? Do Sally, Joe, Henry, and Tom have feature teams, service teams, or component teams? Do they have to add time for the experiments as they transition to agile? Do they need to gain the trust of their management? Or, are they already experienced agile feature teams?

The more experienced the teams are at agile, the better the estimate is. The more the teams are feature teams, the better the estimate is. If you are new to agile, or have feature teams, or have a mixed program (agile and non-agile teams), you know that estimate is way off.

Is it time for the software program manager to say, “We have an initial order-of-magnitude prediction. But we haven’t tested this estimate with any work, so we don’t know how accurate our estimates are. Right now our confidence is about 5-10% (or whatever it is) in our estimate. We’ve spent a day or so estimating, because we can spend time delivering, rather than estimating. We need to do a week or two of work, deliver a working skeletong, and then we can tell you more about our prediction. We can better our prediction as we proceed. Remember, back in the waterfall days, we spent a month estimating and we were wrong. This way, you’ll get to see product as we work.”

You want to use the word “prediction” as much as possible, because people understand the word prediction. They hear weather predictions all the time. They know about weather predictions. But when they hear estimates of work, they think you are correct, even if you use confidence numbers, they think you are accurate. Use the word prediction.

Beware of These Program Estimation Traps

There are plenty of potential traps when you estimate programs. Here are some common problems:

  • The backlog is full of themes. You haven’t even gotten to epics, never mind stories. I don’t see how you can make a prediction. That’s like me saying, “I can go from Boston to China on an airplane. Yes, I can. It will take time.” I need more data: which time of year? Mid-week, weekend? Otherwise, I can only provide a ballpark, not a real estimate.
  • Worse, the backlog is full of tasks, so you don’t know the value of a story. “Fix the radio button” does not tell me the value of a story. Maybe we can eliminate the button instead of fix it.
  • The people estimating are not the ones who will do the work, so the estimate is full of estimation bias. Just because work looks easy or looks hard does not mean it is.
  • The estimate becomes a target. This never works, but managers do it all the time. “Sure, my team can do that work by the end of Q1.”
  • The people on your program multitask, so the estimate is wrong. Have you read the Cost of Delay due to Multitasking?
  • Managers think they can predict team size from the estimate. This is the problem of splitting work in the mistaken belief that more people make it easier to do more work. More people make the communications burden heavier.

Estimating a program is more difficult, because bigness makes everything harder. A better way to manage the issues of a program is to decide if it’s worth funding in the project portfolio. Then, work in an agile way. Be ready to change the order of work in the backlog, for teams and among teams.

As a program manager, you have two roles when people ask for estimates. You want to ask your sponsors these questions:

  • How much do you want to invest before we stop? Are you ready to watch the program grow as we build it?
  • What is the value of this project or program?

You want to ask the teams and product owners these questions:

  • Please produce walking skeletons (of features in the product) and build on it
  • Please produce small features, so we can see the product evolve every day

The more the sponsors see the product take shape, the less interested they will be in an overall estimate. They may ask for more specific estimates (when can you do this specific feature), which is much easier to answer.

Delivering working software builds trust. Trust obviates many needs for estimates. If your managers or customers have never had trust with a project or program team before, they will start asking for estimates. Your job is to deliver working software every day, so they stop asking.

Categories: Project Management

Software Development Linkopedia September 2014

From the Editor of Methods & Tools - Thu, 09/11/2014 - 09:36
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 the software developer condition, scaling Agile, technical debt, behavior-driven development, Agile metrics, UX (user eXperience), NoSQL databases and software design. Blog: The Developer is Dead, Long Live the Developer Blog: Scaling Agile at Gilt Blog: Technical debt 101 Blog: Behaviour Driven Development: Tips for Writing Better Feature Files Article: Acceptance Criteria – Demonstrate Them by Drawing a House Article: Actionable Metrics At Siemens Health Services Article: Adapting Scrum to a ...

The Main Benefit of Story Points

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

If story points are an estimate of the time (effort) involved in doing something, why not just estimate directly in hours or days? Why use points at all?

There are multiple good reasons to estimate product backlog items in story points, and I cover them fully in the Agile Estimating and Planning video course, but there is one compelling reason that on its own is enough to justify the use of points.

It has to do with King Henry I who reigned between 1100 and 1135. Prior to his reign, a “yard” was a unit of measure from a person’s nose to his outstretched thumb. Just imagine all the confusion this caused with that distance being different for each person.

King Henry eventually decided a yard would always be the distance between the king’s nose and outstretched thumb. Convenient for him, but also convenient for everyone else because there was now a standard unit of measure.

You might learn that for you, a yard (as defined by the king’s arm) was a little more or less than your arm. I’d learn the same about my arm. And we’d all have a common unit of measure.

Story points are much the same. Like English yards, they allow team members with different skill levels to communicate about and agree on an estimate. As an example, imagine you and I decide to go for a run. I like to run but am very slow. You, on the other hand, are a very fast runner. You point to a trail and say, “Let’s run that trail. It’ll take 30 minutes.”

I am familiar with that trail, but being a much slower runner than you, I know it takes me 60 minutes every time I run that trail. And I tell you I’ll run that trail with you but that will take 60 minutes.

And so we argue. “30.” “60.” “30.” “60.”

We’re getting nowhere. Perhaps we compromise and call it 45 minutes. But that is possibly the worst thing we could do. We now have an estimate that is no good for either of us.

So instead of compromising on 45, we continue arguing. “30.” “60.” “30.” “60.”

Eventually you say to me, “Mike, it’s a 5-mile trail. I can run it in 30 minutes.”

And I tell you, “I agree: it’s a 5-mile trail. That takes me 60 minutes.”

The problem is that we are both right. You really can run it in 30 minutes, and it really will take me 60. When we try to put a time estimate on running this trail, we find we can’t because we work (run) at different speeds.

But, when we use a more abstract measure—in this case, miles—we can agree. You and I agree the trail is 5 miles. We just differ in how long it will take each of us to run it.

Story points serve much the same purpose. They allow individuals with differing skill sets and speeds of working to agree. Instead of a fast and slow runner, consider two programmers of differing productivity.

Like the runners, these two programmers may agree that a given user story is 5 points (rather than 5 miles). The faster programmer may be thinking it’s easy and only a day of work. The slower programmer may be thinking it will take two days of work. But they can agree to call it 5 points, as the number of points assigned to the first story is fairly arbitrary.

What’s important is once they agree that the first story is 5 points, our two programmers can then agree on subsequent estimates. If the fast programmer thinks a new user story will take two days (twice his estimate for the 5-point story), he will estimate the new story as 10 points. So will the second programmer if she thinks it will take four days (twice as long as her estimate for the 5-point story).

And so, like the distance from King Henry’s nose to his thumb, story points allow agreement among individuals who perform at different rates.

The Main Benefit of Story Points

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

If story points are an estimate of the time (effort) involved in doing something, why not just estimate directly in hours or days? Why use points at all?

There are multiple good reasons to estimate product backlog items in story points, and I cover them fully in the Agile Estimating and Planning video course, but there is one compelling reason that on its own is enough to justify the use of points.

It has to do with King Henry I who reigned between 1100 and 1135. Prior to his reign, a “yard” was a unit of measure from a person’s nose to his outstretched thumb. Just imagine all the confusion this caused with that distance being different for each person.

King Henry eventually decided a yard would always be the distance between the king’s nose and outstretched thumb. Convenient for him, but also convenient for everyone else because there was now a standard unit of measure.

You might learn that for you, a yard (as defined by the king’s arm) was a little more or less than your arm. I’d learn the same about my arm. And we’d all have a common unit of measure.

Story points are much the same. Like English yards, they allow team members with different skill levels to communicate about and agree on an estimate. As an example, imagine you and I decide to go for a run. I like to run but am very slow. You, on the other hand, are a very fast runner. You point to a trail and say, “Let’s run that trail. It’ll take 30 minutes.”

I am familiar with that trail, but being a much slower runner than you, I know it takes me 60 minutes every time I run that trail. And I tell you I’ll run that trail with you but that will take 60 minutes.

And so we argue. “30.” “60.” “30.” “60.”

We’re getting nowhere. Perhaps we compromise and call it 45 minutes. But that is possibly the worst thing we could do. We now have an estimate that is no good for either of us.

So instead of compromising on 45, we continue arguing. “30.” “60.” “30.” “60.”

Eventually you say to me, “Mike, it’s a 5-mile trail. I can run it in 30 minutes.”

And I tell you, “I agree: it’s a 5-mile trail. That takes me 60 minutes.”

The problem is that we are both right. You really can run it in 30 minutes, and it really will take me 60. When we try to put a time estimate on running this trail, we find we can’t because we work (run) at different speeds.

But, when we use a more abstract measure—in this case, miles—we can agree. You and I agree the trail is 5 miles. We just differ in how long it will take each of us to run it.

Story points serve much the same purpose. They allow individuals with differing skill sets and speeds of working to agree. Instead of a fast and slow runner, consider two programmers of differing productivity.

Like the runners, these two programmers may agree that a given user story is 5 points (rather than 5 miles). The faster programmer may be thinking it’s easy and only a day of work. The slower programmer may be thinking it will take two days of work. But they can agree to call it 5 points, as the number of points assigned to the first story is fairly arbitrary.

What’s important is once they agree that the first story is 5 points, our two programmers can then agree on subsequent estimates. If the fast programmer thinks a new user story will take two days (twice his estimate for the 5-point story), he will estimate the new story as 10 points. So will the second programmer if she thinks it will take four days (twice as long as her estimate for the 5-point story).

And so, like the distance from King Henry’s nose to his thumb, story points allow agreement among individuals who perform at different rates.

Cost, Value & Investment: How Much Will This Project Cost? Part 1

I’ve said before that you cannot use capacity planning for the project portfolio. I also said that managers often want to know how much the project will cost. Why? Because businesses have to manage costs. No one can have runaway projects. That is fair.

If you use an agile or incremental approach to your projects, you have options. You don’t have to have runaway projects. Here are two better questions:

  • How much do you want to invest before we stop?
  • How much value is this project or program worth to you?

You need to think about cost, value, and investment, not just cost when you think about about the project portfolio. If you think about cost, you miss the potentially great projects and features.

However, no business exists without managing costs. In fact, the cost question might be critical to your business. If you proceed without thinking about cost, you might doom your business.

Why do you want to know about cost? Do you have a contract? Does the customer need to know? A cost-bound contract is a good reason.  (If you have other reasons for needing to know cost, let me know. I am serious when I say you need to evaluate the project portfolio on value, not on cost.)

You Have a Cost-Bound Contract

I’ve talked before about providing date ranges or confidence ranges with estimates. It all depends on why you need to know. If you are trying to stay within your predicted cost-bound contract, you need a ranked backlog. If you are part of a program, everyone needs to see the roadmap. Everyone needs to see the product backlog burnup charts. You’d better have feature teams so you can create features. If you don’t, you’d better have small features.

Why? You can manage the interdependencies among and between teams more easily with small features and with a detailed roadmap. The larger the program, the smaller you want the batch size to be. Otherwise, you will waste a lot of money very fast. (The teams will create components and get caught in integration hell. That wastes money.)

Your Customer Wants to Know How Much the Project Will Cost

Why does your customer want to know? Do you have payments based on interim deliverables? If the customer needs to know, you want to build trust by delivering value, so the customer trusts you over time.

If the customer wants to contain his or her costs, you want to work by feature, delivering value. You want to share the roadmap, delivering value. You want to know what value the estimate has for your customer. You can provide an estimate for your customer, as long as you know why your customer needs it.

Some of you think I’m being perverse. I’m not being helpful by saying what you could do to provide an estimate. Okay, in Part 2, I will provide a suggestion of how you could do an order-of-magnitude approach for estimating a program.

Categories: Project Management

Define Your Target Audience

NOOP.NL - Jurgen Appelo - Mon, 09/08/2014 - 14:44
target audience

The big checklist that I used while writing my new book #Workout contained the following items:

Remove use of the words “agile” and “lean”
Remove use of the words “software” and “development”
Remove use of the words “Scrum” and “Kanban”

The post Define Your Target Audience appeared first on NOOP.NL.

Categories: Project Management

How to create a knowledge worker Gemba

Software Development Today - Vasco Duarte - Mon, 09/08/2014 - 04:00

I am a big fan of the work by Jim Benson and Tonianne Barry ever since I read their book: Personal Kanban.

In this article Jim describes an idea that I would like to highlight and expand. He says: we need a knowledge worker Gemba. He goes on to describe how to create that Gemba:

  • Create a workcell for knowledge work: Where you can actually observe the team work and interact
  • Make work explicit: Without being able to visualize the work in progress, you will not be able to understand the impact of certain dynamics between the team members. Also, you will miss the necessary information that will allow you to understand the obstacles to flow in the team - what prevents value from being delivered.

These are just some steps you can take right now to understand deeply how work gets done in your team, your organization or by yourself if you are an independent knowledge worker. This understanding, in turn will help you define concrete changes to the way work gets done in a way that can be measured and understood.

I've tried the same idea for my own work and described it here. How about you? What have you tried to implement to create visibility and understanding in your work?

Making Decisions

Herding Cats - Glen Alleman - Sat, 09/06/2014 - 23:07

Making Multi-Objective DecisionsAlmost all decision problems involve the simultaneous considerations of different objectives that are many times in conflict.

In the software development world this might be characterized by a customer wanting a set of features to be delivered for a budget on a certain date so those features can be put to work earning back their cost.

Since the list of features is likely to needed to be developed in a specific order with varying costs, the question is what features should be done first and what features down next. 

The traditional response from an agile developer is the define the value of those features and produce them in that order. What is the unit of measure of value. That's rarely stated. But along with the Value is the cost of that value and other attributes of the development process. Risk, resource demand, inter dependencies between other features, inter dependencies between these features and external processes - the externalities of all complex problems.

The formal discipline is this process is called Multi-Criteria Decision Analysis (MCDA). MCDA has the following elements:

  • A goal, objective, or criteria to be achieved
  • A  need to be fulfilled
  • Constraints and requirements associated with and affected by the decision
  • Decision options or alternatives
  • The Environment in which the decision must be made
  • The Experience and background of the decision makers

The methods to solve these types of problems started in the 1950's with Churchman and Ackoff, and were axiomatized by Debreu in 1960, along with Luce and Tukey, Krantz, and Scott.

The principles in these early papers and the continued development of multi-criteria decision making have now moved to nearly every domain where scarce resources, probabilistic outcomes, uncertainty of the impact of the decisions, and value at risk is high enough to ask the question

What will be the outcome of this decision on the future of the processes, cost, technology, environment, or any other external domain?

So when we hear that

  • Decision making frameworks for project that don't require estimates.
  • Investment models for software project that don't require estimates.
  • Project management (risk management, scope management, process reports) approaches that don't require estimates.

We have to wonder if these frameworks, investment models, and project management methods have come in contact with the reality of how business works. As Carl saying in a somewhat harsh manner

Extraordinary claims require extraordinary evidence. Carl Sagan

Related articles Positive Deviance 5 Questions That Need Answers for Project Success
Categories: Project Management

Focus on Value is Only ½ The Equation

Herding Cats - Glen Alleman - Fri, 09/05/2014 - 16:54

ValueWhenever I hear "we need to focus on value" it tells me that only ½ the equation of business  success is understood.

Absolutely value is needed and is the focus of our work efforts. No customer is going to pay for a product or service that doesn't have the needed value. This value is usually in a unit of measure around a "capability" to do something for the that in turn solves a problem, generates revenue, enables another process to function.

Measures of Effectiveness to get the job done. Measures of Performance while getting the job done. The Technical Performance Measures of the underlying hardware, software, people processes that enable the job to get done at the right cost.

But this value is an enabler. The units of measure of the value are defined by the customer, not the provider. The Marketing department of the provider may have suggestions about the value of the product or service, but it is the customer that confirms that value.

In doing the confirmation of Value, the buyer (internal or extermal customer) makes this assessment using a foundational principles of all business decisions...

Microeconomics

Microeconomics is a branch of economics that studies the behavior of individuals and small impacted organizations in making decisions on the allocation of limited resources. Those limited resources to the buyer are:

  • Time - the need for the capability provided by the Value produced by the developer usually has a time frame on it. If that Value could arrive any time, then it is unlikely the Value of the Value is very high.
  • Money - the other limited resource is money. How much does the Value cost?

The time value of money is then used by the buyer to enable another decision making process

ROI = (Value - Cost ) / Cost

So when we hear, we don't need to know the cost, that is we don't need to estimate the cots of producing the value, think again. This can only be true if the delivered value takes place in the presence of unlimited resources. That is we have all the time we need and no one really cares about the cost. That is the principle of microeconomics of business decision making is not in play.

As a final point. Budget is NOT Cost. Setting the budget, only sets the budget. The cost of the work is called Actual Cost and actual cost is generated by exchanging labor and materials for money. So setting the budget is needed. But setting the budget only says what the expected cost might be. If you're given an budget and an expected set of Value outcomes, estimates of the confidence of delivering that Value will be needed. Otherwise your budget is just a number, that will easily be blown before you delivery the needed capabilities on the needed date.

If asked what should our budget be for the expected Value, then solving the ROI or Expected Monetary Value, or Value at Risk needs to take place. In order to do this for a decision about the future ROI, EMV, or VAR, we need to estimate both the Cost and Value - then manage the project that produces the Capabilities that deliver the Value toward both those cost and time variables. And of course those variables are random variables.

When it is stated in an work shop where the participants will learn about

  • Decision making frameworks for project that don't require estimates.
  • Investment models for software project that don't require estimates.
  • Project management (risk management, scope management, process reports) approaches that don't require estimates.

Then those processes are not operating in a governance domain where microeconomics of product developments are in place. Can't say where they are operating, but it's not on this planet of a for profit business. Or those proffering this approach have discovered a secret sauce that gets around the basic principles of all business -

Profit = Revenue - Cost of Goods Sold

The only place I know this principle is not in place, is here in Colorado, just outside of Fairplay, CO, is South Park.

South-park-bowl-and-grill

Here in South Park, the local businessmen have a clever plan to get rich without be subject to microeconomics of making decisions about how to do that.

Screen Shot 2014-09-05 at 9.39.44 AM

Categories: Project Management

Hangout Interview

NOOP.NL - Jurgen Appelo - Thu, 09/04/2014 - 15:25
hangout-interview

Mads Troels Hansen had a some challenging questions for me in this hangout, such as…

“How do your introduce change in large organizations?”

Oh boy…

The post Hangout Interview appeared first on NOOP.NL.

Categories: 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 ...