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

Why We Must Learn to Estimate

Herding Cats - Glen Alleman - Fri, 06/20/2014 - 22:18

Screen Shot 2014-06-19 at 1.54.38 PM

The notion of making any decisions without know something about the cost of that decision, the schedule impacts or the resulting impacts on delivered capabilities is like the guys here in the picture. They stared building their bridge. Will run out of  materials, can't see the destination and likely have the wrong tools.

The continued insistence that we can make decisions in the absence of estimates needs to be tested in the market place by those providing the money, not by those consuming the money.

No Estimates

When mentioned that cost can be fixed through a budget process, this still leaves the schedule and delivered capabilities as two random variables that need to be estimated if we are to provide those funding our work with a credible confidence that we'll show up on time with the needed capabilities.

Slide1

Related articles How To Fix Martin Fowler's Estimating Problem in 3 Easy Steps Why Johnny Can't Estimate or the Dystopia of Poor Estimating Practices Making Estimates For Your Project Require Discipline, Skill, and Experience First Comes Theory, Then Comes Practice
Categories: Project Management

Run! Jurgen, Run!

NOOP.NL - Jurgen Appelo - Fri, 06/20/2014 - 15:03

I tried running, and it didn’t work. I suffered from shin splints. No matter what kind of shoes I wore, what stretching exercises I did, or how far I ran, it usually ended up with a sharp stinging pain in my shins. Not good.

I tried Pilates and yoga exercises, and they also didn’t work. It wasn’t the pain this time that made me stop, but a severe lack of motivation to roll out the mat and thrust my skinny legs up in the air. It was so boring. Not good.

I tried swimming, and it didn’t work either. Driving up and down to the local swimming pool cost me far too much time, and I noticed that swimming pools are difficult to carry around when I’m traveling. Not good.

Still, I want to do something in order to improve my health.

The post Run! Jurgen, Run! appeared first on NOOP.NL.

Categories: Project Management

Quote of the Month June 2014

From the Editor of Methods & Tools - Fri, 06/20/2014 - 06:39
A UX team that deals with only the details of radio buttons and check boxes is committing a disservice to its organization. Today UX groups must deal with strategy. Source: Institutionalization of UX (2nd Edition), Eric Schaffer & Apala Lahiri, Addison-Wesley

How To Measure Anything

Herding Cats - Glen Alleman - Wed, 06/18/2014 - 21:41

How To MeasureWhen it is said that we can't forecast or estimate, it brings a smile. Since in fact forecasting and estimating is done all the time. Not always correctly, and not always properly used once the estimate is made, but done all the same, every day in some domains, every week and every month in the domains I work.

In our domains the Estimate At Complete is submitted to the customer every month. And the Estimate At Completion quarterly on most projects we work. These are software intensive projects and some time software only projects. All innovative development, sometimes never been done before, sometimes inventing new physics.

Some of these estimates are very formal, using tools, reference class forecasting, Autoregressive Integrated Moving Average (ARIMA) projections of risk adjusted past performance and compliance with System Engineering Measures of Effectiveness (MOE) and Performance (MOP), traceable to Technical Performance Measures (TPM) and Key Performance Parameters (KPP). Some are simple linear projects of what it will cost give a few parameters - the is it bigger than a bread box type estimates. Here's how to estimate any software deliverable in an informal way.

At last week's ICEAA conference where a colleague and I presented two papers. Cure of Cost and Schedule Growth and Earned Value Management Meets Big Data, along with the briefing deck, we were introduced to this book. It says it's name, you can measure anything. 

Chapter 2 opens with a powerful quote

Success is a function of persistence and doggedness and the willingness to work hard for twenty-minutes to make sense of something that most people would give on after thirty seconds - Malcolm Gladwell, Outliers: The Story of Success.

That chapter and others speak to making estimates about the things we want to measure. Along with Monte Carlo Simulation - another powerful estimating tool we use on our programs. The process entering our domain (space and defense) is Bayesian estimates - adding to what we all ready know. 

The instinctive Bayesian approach is very simple

  • Start with a calibrated estimate
  • Gather additional information
  • Update the calibrated estimate subjectively, without doing additional calculations

So if we hear, we can't forecast the future, estimates are a waste, we can't know anything about the future until it arrives ‚ÄĒ stop, think about all the estimating and forecasting activities you interact with every day, from the weather, to the stock market, to your drive to work, to the estimated cost of the repainting of your house, or the estimated cost of a kitchen remodel.

Anything can be estimated or forecast. All that has to happen is the desire to learn how. Since the purpose of estimates is to improve the probability of success for the project, the estimates start by providing information to those paying for the project. This is a immutable principle of business

Value is exchanged for the cost of that value. We can't know the value of something until we know it's cost. From the kitchen cabinets, the the garden upgrade, to the software for Medicaid enrollment. It's this simple

ROI = (Value ‚ÄĒ Cost) / Cost

20140609_150813_Richtone(HDR)

Related articles Making Estimates For Your Project Require Discipline, Skill, and Experience First Comes Theory, Then Comes Practice How NOT to Estimate Anything Resources for Moving Beyond the "Estimating Fallacy" The Metropolis Algorithm Critical Thinking Insight Software Cost Estimating Information Yes, checking calibration of probability forecasts is part of Bayesian statistics How to Forecast the Future
Categories: Project Management

Domain and Context Are King, Then Comes Process and Experience

Herding Cats - Glen Alleman - Tue, 06/17/2014 - 17:51

In many discussions of process there is a proposed solution to a problem in the absence of domain and context. Over generalization is usually the result. This is so common in the agile development world, that I built a short briefing to communicate the issues with making suggestions in the absence of domain and context.

Mosty ideas are credible, once the domain and context are established. There are a few immutable principles of all project management though and with those principles are a few practices that must be in place if success is going to have a chance of appearing before we run out of time and money. The briefing below provides one set of immutable Principles and the Practices and Processes needed to increase the probability of project success. Principles and Practices of Performance-Based Project Management¬ģ from Glen Alleman Related articles Performance-Based Project Management(sm) Released It's Not the People It's the Process? Seven Immutable Activities of Project Success Domain and Context King Agile Requires Discipline, In Fact Successful Projects Require Discipline Three Kinds of Uncertainty About the Estimated Cost and Schedule The Connection Between Domain Expertise and Successful Startups
Categories: Project Management

Agile Is Not Dead (But Some Organizations Might Be Soon)

NOOP.NL - Jurgen Appelo - Tue, 06/17/2014 - 15:51
Agile Is Not Dead

The concept of agility is fine. Agile is not dead. But organizations misapplying good agile practices might be very soon.

The post Agile Is Not Dead (But Some Organizations Might Be Soon) appeared first on NOOP.NL.

Categories: Project Management

Tips for Improving Your Geographically Distributed Agile Team

At the Better Software/Agile Development conference a couple of weeks ago, I gave a talk entitled At Least Five Tips for Improving Your Geographically Distributed Agile Team. (That link goes to the slideshare.)

If you look at Scott Ambler’s 2011 survey, you can see that his data matches my consulting experience. About half of all agile teams have at least one person not co-located. This is by management design.

We can say, “don’t do this,” but that’s not helpful to the distributed and dispersed teams. I would rather be helpful.

For example, in my talk, not the slideshare, I actually said, “Don’t do standups. Do handoffs.” If you are more than about 4 or 5 hours apart in timezones, standups make little sense. You are better off limiting WIP (with a kanban board) than using straight Scrum. Yes, use iterations if you like. You might like the focus of the timebox. But, consider using handoffs, not standups. Change your questions to statements—if that works for you. Change your deliverables to fit your needs.

One tip that created a ton of discussion was the one about keeping people together over time. Some managers are trying to be “efficient” about using team members, optimizing at the lowest possible level. They move people off and on teams, willy-nilly. (Groan.) I explained that agile is about finishing features, so their best bet was to optimize at the project level, or the project portfolio level. It didn’t matter if people weren’t fully utilized. People were best utilized when they asked, “How can I help move this feature across the board?” In a geographically distributed team, that is sometimes a difficult question to answer, especially if the testers are east of the developers.

I had stories, and we had audience participation, which is why the slides are sparse. I hope you enjoy the slideshare. If you have questions, please ask away in the comments. I will answer.

Categories: Project Management

4 Tips for Spring Cleaning Your Product Backlog

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

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

It's May, and we're well into spring now. If you're like me, you haven't yet done your annual spring cleaning. But I'll do mine this week, if you promise to also do yours.

The type of spring cleaning I'm referring to is cleaning your product backlog. When not given sufficient attention, a product backlog can get messier than the shrubs I haven't trimmed the last three years. In this post, I want to share four things a product owner can do as part of spring cleaning the product backlog.

First, the product owner should go through the product backlog looking for things to delete. Many product owners have a habit of adding to a product backlog but never removing from it features that are no longer wanted. If a feature is no longer wanted, it should be removed.

It’s tempting to leave these low-value features in the product backlog under the premise that we’ll get to them someday. If you feel you can’t truly delete items, find a way to archive them somewhere.

If you’re using software to manage your product backlog, it may have functionality for doing this. If you’re using a spreadsheet, copy the unwanted items out of the main spreadsheet and into one named, “Long Term Product Backlog.” That’s what I do. And, if you’re like me, you’ll feel good having saved them, but you’ll never look at them again.

My second spring cleaning tip is also about preventing the size of the product backlog from becoming unmanageable: Group related items. I’ve worked with product owners attempting to manage over 2,000 product backlog items. That’s too many.

I find a good upper limit to be in the range of 100 to 150 items. When a product backlog contains more than that, it becomes difficult to work with the product backlog. It’s harder to see relationships between items. It’s harder to remember if product backlog items already exist for a certain thing, so new items are created, increasing the frequency of duplicates.

Grouping related items together into what is called a “theme” makes it easier to mentally work with those items. So much so that I could group as one item toward my upper limit of 100 to 150.

With low-priority items removed, and related items grouped into themes, it’s time for my third tip for spring cleaning a product backlog: the Product Owner should check the priorities of the items on the product backlog.

An item’s position in the product backlog is based on four factors:

  • How valuable the feature is
  • How much learning will occur by doing the feature
  • How much risk is addressed by doing the feature
  • Changes in relative cost

With the product backlog now prioritized, my final suggestion for spring cleaning is to make sure the top items are ready for the team to work on. Each of the top product backlog items should be sufficiently thought through so that the team can work on them in the next sprint with a reasonable expectation of being able to finish them.

This doesn’t mean that each product backlog item is accompanied by a mini-spec detailing every issue or consideration around that item. It does mean, however, that the remaining open issues are ones that the team and product owner can quickly resolve during the sprint.

If delivering a top priority product backlog item requires three meetings of the “Stakeholder Steering Committee,” that item isn’t a good choice to be at the top of the product backlog.

So there you have it: Four tips for spring cleaning your product backlog. And, even though it’s cleaning, this type of cleaning sure beats cleaning out the garage.

4 Tips for Spring Cleaning Your Product Backlog

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

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

It's May, and we're well into spring now. If you're like me, you haven't yet done your annual spring cleaning. But I'll do mine this week, if you promise to also do yours.

The type of spring cleaning I'm referring to is cleaning your product backlog. When not given sufficient attention, a product backlog can get messier than the shrubs I haven't trimmed the last three years. In this post, I want to share four things a product owner can do as part of spring cleaning the product backlog.

First, the product owner should go through the product backlog looking for things to delete. Many product owners have a habit of adding to a product backlog but never removing from it features that are no longer wanted. If a feature is no longer wanted, it should be removed.

It’s tempting to leave these low-value features in the product backlog under the premise that we’ll get to them someday. If you feel you can’t truly delete items, find a way to archive them somewhere.

If you’re using software to manage your product backlog, it may have functionality for doing this. If you’re using a spreadsheet, copy the unwanted items out of the main spreadsheet and into one named, “Long Term Product Backlog.” That’s what I do. And, if you’re like me, you’ll feel good having saved them, but you’ll never look at them again.

My second spring cleaning tip is also about preventing the size of the product backlog from becoming unmanageable: Group related items. I’ve worked with product owners attempting to manage over 2,000 product backlog items. That’s too many.

I find a good upper limit to be in the range of 100 to 150 items. When a product backlog contains more than that, it becomes difficult to work with the product backlog. It’s harder to see relationships between items. It’s harder to remember if product backlog items already exist for a certain thing, so new items are created, increasing the frequency of duplicates.

Grouping related items together into what is called a “theme” makes it easier to mentally work with those items. So much so that I could group as one item toward my upper limit of 100 to 150.

With low-priority items removed, and related items grouped into themes, it’s time for my third tip for spring cleaning a product backlog: the Product Owner should check the priorities of the items on the product backlog.

An item’s position in the product backlog is based on four factors:

  • How valuable the feature is
  • How much learning will occur by doing the feature
  • How much risk is addressed by doing the feature
  • Changes in relative cost

With the product backlog now prioritized, my final suggestion for spring cleaning is to make sure the top items are ready for the team to work on. Each of the top product backlog items should be sufficiently thought through so that the team can work on them in the next sprint with a reasonable expectation of being able to finish them.

This doesn’t mean that each product backlog item is accompanied by a mini-spec detailing every issue or consideration around that item. It does mean, however, that the remaining open issues are ones that the team and product owner can quickly resolve during the sprint.

If delivering a top priority product backlog item requires three meetings of the “Stakeholder Steering Committee,” that item isn’t a good choice to be at the top of the product backlog.

So there you have it: Four tips for spring cleaning your product backlog. And, even though it’s cleaning, this type of cleaning sure beats cleaning out the garage.

Quote of the Day

Herding Cats - Glen Alleman - Mon, 06/16/2014 - 16:17

Probability theory is nothing but common sense reduced to calculation ‚ÄĒ Pierre-Simon Laplace 1749-1827)

So when you hear¬†we can't forecast the future, or¬†estimates are evil, or¬†we can't know what we need to do until we start doing, focus on the last part of the quote ‚ÄĒ¬†if you don't apply probability theory and its partner statistics, they are correct and missing that basic¬†common sense.¬†If we apply basic statistically thinking to project management issues, we can calculate the probability of anything. The resulting probability may not have sufficient confidence levels - but we can calculate non the less.

Probability and Statistics

When you hear we can make decisions without estimating the cost, schedule, or capability impacts of those decisions, consider Laplace and the nonsense of that notion. And a recent example of how to do the math for forecast the future behaviour of a project in a specific domain Earned Value Meets Big Data and the annotated briefing of the same paper.

Related articles Project Management and the Three Body Problem Critical Thinking Insight
Categories: Project Management

How To Assure Your Project Will Fail - UpDate

Herding Cats - Glen Alleman - Mon, 06/16/2014 - 00:19

Screen Shot 2014-05-27 at 1.05.27 PMThere is a short eBook titled Dealing with Complexity in Software Projects that can be downloaded by clicking on the image to the left.

This book starts with the hypothesis put forth by Theory of Project Management: Explanation of Novel Methods, in which it is conjectured that traditional project management processes are now obsolete and new project management processes are needed. Agile of course is one of those suggested. 

This theory is the basis of a product, Last Planner used in the construction business. 

There are some fundamental flaws starting on page 1 of the eBook, where it is asserted Project Management can be divided into main components:

  • Theory of Projects -¬†why are projects important?
  • Theory of Management - how are projects managed?

The first  is nearly universal, projects are the basis of most business processes, other than production and even then, projects are used to establish the production processes. The second part is domain dependent. In the eBook, it is conjectured that the view of projects rests on the assumptions listed in the orginal paper:

  • Tasks are independent, except for their sequential relationships.
  • Tasks are concrete, with start and end dates.
  • There is very little uncertainty regarding requirements and the tasks themselves.
  • All work is possible to capture in a top-down breakdown of the total transformation.
  • All requirements exist at the start and they can be decomposed just like the tasks.

First let's look at these assumptions from a theory testing point of view. If these assumptions are found to be flawed, then what  follows in terms of seeking new ways, may be based on unfounded assertions.

  • Assumption 1: Tasks are Independent
    • Only if the work is not developing a connected and interoperable system made of of other system elements. That is the work is an¬†assembly of parts with no interactions between the parts other than at their interfaces.
    • This is rarely the case in software, hardware, people, or systems-of-systems.
    • This would mean there are only linear connections between the work elements. No merge points or branch points in the sequence of work.¬†
    • Traditional project management processes deal with these merge and branch points through the technical and programmatic architecture of the project. The¬†network¬†of planned work has many to one and one to many connections throughout the project.
    • Traditional project management processes deal with this quite well, starting with¬†Capabilities Based Planning, moving to Integrated Master Planning, Integrated Master Scheduling, and then the establishment of the risk adjusted Performance Measurement Baseline.
  • Assumption 2: Tasks are Concrete
    • Only if you are pouring concrete or welding pipe, as the original paper suggests projects they are interested in do.
    • If the¬†components of the project being integrated have dynamic behaviours, modern project management methods deal with those through¬†Interface Control Documents, that define both the static and dynamic behaviours of the component. This is the basis of object oriented programming, systems engineering, and most importantly the systems-of-systems approach take by modern project management methods.
    • These interactions are modeled in tools based on sysML. CORE and CRADLE are two I use.
    • The complex behaviours of these interfaces can be modeled. Their dynamic behaviours revealed along with the static - architecture. We use DoDAF as our starting point for architecture. The coupling and cohesion exposed by the tools and the model and most importantly the inter-dependencies documented through another tool - Design Structure Matrix.
  • Assumption 3: There is Very Little Uncertainty
    • This is not only na√Įve, it is wrong. Or perhaps better stated Pauli's quote,¬†"Das ist nicht nur nicht richtig, es ist nicht einmal falsch!"¬† -¬†"It is not only not right, it is not even wrong,"
    • All variables on projects are random variables, generated from the underlying statistical processes for cost, schedule, and technical performance.
    • These variables are drawn from two classes of uncertainty.
    • Reducible uncertainty (epistemic) - which can be reduced with time and money to protect the project from their impact.
    • Irreducible uncertainty (aleatory) - which can not be reduced, so margin is need to protect the project from their impact.
    • Modeling this combined uncertainty can start with Monte Carlo Simulation of that non-linear, non-stationary, stochastic network of work activities called the Integrated Master Schedule.
  • Assumption 4: Work can be Captured Top-Down
    • In practice, Capabilities can be defined top down and assessed by Measures of Effectiveness and Measures of Performance.
    • These capabilities reveal the needed requirements in the upcoming capability release plan. This incremental and iterative process is the basis of DOD and NASA programs, so it should be straightforward for complex software projects to apply this as well.
  • Assumption 5: All Requirements Exist At Start¬†- is na√Įve at best and not factual at worst. These Program Management Handbooks show how to elicit requirements incrementally in an¬†evolutionary manner:
    • Capabilities Based Planning does not assume this
    • DOD 5000.02 does not assume this
    • NASA¬†NPR 7120.5E does not assume
    • You get it, requirements are avaiable up front is a veryt bad assumption.

So Now What?

With the basis for seeking a new and innovative project management process grounded in assumptions that are not actually correct, is there any reason to continue reading the eBook? 

Yes, for one simple reason. To put into perspective the notion of chaos as the basis of any credible probability calculaton for the success of a project. 

Let's review the assumptions that are suggested as the reason to abandon the current project management approach and move to something else.

  • Tasks are Independent ‚ÄĒ no they're not. They're independent in only the simplest of projects. Dependencies are everywhere. And not just dependencies on logic, but also cost and technical performance. Projects are collections of interdependent networks of non-linear, non-stationary, stochastic processes.
  • Tasks are Concrete¬†‚ÄĒ only if you're pouring concrete. Any nontrivial engineering development program has emerging and evolving drivers of cost, schedule, and technology.
  • There is Little Uncertainty - a colleague has a saying¬†the project and its plan is a complex situation adapting to an emerging solution. Behave accordingly.
  • Work Can Be Captured Top Down¬†‚ÄĒ this would require clairvoyance and precognition on the parts of the project participants.
  • All Requirements Exist At The Start¬†‚ÄĒ same clairvoyance and precognition needed.

Next

These assumptions ‚ÄĒ¬†wrongly described ‚ÄĒ¬†are then challanged by the Agile Communities approach.

  • In Agile Software development we assume that requirements are not knowm in full at the start, and we ¬†further assume that they will change during the project.
  • We assume that tasks have some sequence, but that the sequence should follow our beliefs regarding the value of each requirements or tasks, and not a possible work-sequence.
  • We assume that the number of requirements will grow as we understand better the problem space, and that we will find novel ways to execute the initial requirements as we understand better how the software system behaves when in use by actual users.

 Let's start with a framework, well developed in many domans - Capabilities Based Planning. In this framework, we don't start with the requirements. We start with the needed capabilities that will result from the project's outcomes. Let's look at the challanges above in light of Capabilities Based Planning.

Project maturity flow is the incremental delivery of business value from Glen Alleman
  • In Agile Software development we assume that requirements are not knowm in full at the start, and we ¬†further assume that tehy will change during the project.
    • With capabilities, we can develop the needed requirements to implement the capabilities for the release of those capabilities to the production environment.
    • In the above example,¬†Demo Conversion Process, Member Reconciliation is a capabilities that can be put to work.
    • With this capability we can start the next one.¬†Integration of ERP Converted to Inventory
    • The result addressed the emerging requirements issue, by freezing the¬†capabilities long enough to produce a¬†capability that can be put to work and start genertaing the planned value.
    • If the requirements are¬†emerging as we are developing, we'll never reach¬†DONE on the planned day for the planned cost.
  • We assume that tasks have some sequence, but that the sequence should follow our beliefs regarding the value of each requirements or tasks, and not a possible work-sequence.
    • For the needed capabilities to show up on time, for the planned cost and the planned benefits, we will need to have a¬†plan to perform the work in the right order.
  • We assume that the number of requirements will grow as we understand better the problem space, and that we will find novel ways to execute the initial requirements as we understand better how the software system behaves when in use by actual users.
    • The number may grow over time. But during the¬†freeze period needed to produce the planned capabilities, on the planned date, for the planned cost, they had better be stable.
    • Otherwise we have a¬†death march project. One that can never seem to get to¬†DONE, because we keep changing what¬†DONE looks like

The End

Projects have lots of problems - symptoms actually - with root causes. But with the assumptions that are the basis of the paper and the eBook, one primary root cause is simple ...

BAD PROJECT MANAGEMENT

So do we move on to the next project management method before to assess the root causes of the current symptoms, fix the root causes and reassess if the current method has shortcomings? Let's hope not.

Here's the Principles, Practices, and Processes needed to increase the probability of project success. Apply these first, see if they are found wanting for the domain you work in. If so, assess then before abandoning them for others that must first be tested to improve the probability of success before jumping on that band wagon.

Principles and Practices of Performance-Based Project Management¬ģ from Glen Alleman So when you hear about the next new thing, do two things.
  • Buy¬†Beyond the Hype: Rediscovering the Essence of Management, Robert G. Eccles and Nitin Nohria, Harvard Business School. Read it and then ask the questions developed in the book to separate hype from Bad Management fixes.
  • Take the contents of the briefing above and see if you can find the Principles, Practices, and Processes on your own project? If not, you may want to install them first before following the pided piper of¬†the next new thing.¬†
Related articles Elements of Project Success Positive Deviance The World of Probability and Statistics Statistical Process Control The Basis of All Modern Control Systems Both Aleatory and Epistemic Uncertainty Create Risk
Categories: Project Management

Impact Mapping and Integrated Master Planning

Herding Cats - Glen Alleman - Sun, 06/15/2014 - 15:55

Impact MappingIn the literally 1,000's of pieces of correspondence I receive or send monthly, I came in contact with Impact Mapping, Gojko Adzic. At the same time I got an email from a person I met while speaking at last weeks conference (International Cost Estimating and Analysis Association).

This small book has a powerful concept that matches closing with a paradigm used in our domain Integrated Master Plan (IMP) and Integrated Master Schedule (IMS). The IMP/IMS approach to program management starts with a set of Program Events that assess the increasing maturity of the program itself and the deliverables that make up the program.

The IMP is derived through a Systems Engineering process is eliciting the Measures of Effectiveness and Measures of Performance for the outcomes of the program. The things that fly, swim, walk, or drive away after the program is complete. These measures are guided by Key Performance Parameters.

What is of interest is not the IMP/IMS (that's talked about in many other posts) or the book itself (which should be in the shelf of every software and IT Project Manager), but the notion of defining what done looks like in units of measure meaningful to the decision makers. 

This last phrase of course is the basis of my own book¬†Performance-Based Project Management¬ģ¬†which shows how to put that phrase to work.

But that's not the point either. The point is ‚ÄĒ the notion of defining¬†capabilities connecting these capabilities together to solve a complex problem, eliciting the technical and operational requirements that enable the capabilities to¬†be capable, then collecting all these capabilities and requirements into some¬†model to assess the impacts of each component on the other components to inform the decision makers on the probability of success of the project is actually very rare.

Why is it Rare?

It is rare, because in our technology world we start on the wrong end of the problem. Tom Poppendieck says it best in the forward With few exceptions, software development work has long been separate from other parts of the organizations it supports. 

This disconnect is not a development problem. It is not a business problem. It is not solved by rapid feedback, since rapid feedback in the absence of a clear and concise description of what DONE looks like in those pesky units of measure meanigful to the decision makers - is just rapid production of software that doesn't solve the real problem. 

The Real Problem

The real problem is neither those paying for the solution nor those providing the solution have a shared understanding of the vision and mission that will drive the needed capabilities before starting work. The notion that the requirements will emerge is used in the agile community. But in fact there is no actual test of that notion. Next week, June 17th, Jim Highsmith is speaking here in Boulder. It'll be interesting to hear what he says about emergence. 

The real problem is without some shared understanding of mission and vision and the units of effectiveness and perfomance, no project is going to fulfill its goal without waste of time and money. From Joint Strike Fighter to the internal IT project, work without a definitized set of capabilities, simply spends time and money searching from those through rapid delivery of technical outcomes.

It's a solution looking for the problem. Rapidly producing a solution for sure, but looking all the same

So buy the book, it's a good read. And it'll improve the conversation around what DONE looks like. But it's only one piece of the solution to a very complex problem in product development. 

  • What do we want to system to do in the broader business process sense?
  • Do we even have a business process?
  • What are we willing to pay for this system?
  • When do we think we will need this system to provide the capabilities we think we have identified?
  • How can we test the notion of the needed capabilities, the cost, the time to get feedback that we're on the right track for each of those?

The answers to these questions are hard to come by for all the right reasons - they're hard.

So we focus on the things we know about and many times the things that have little to do with the actual problem of producing value in exchange for money.

But buy the Impact Mapping book, buy my book, buy a Balanced Scorecard books and read articles, buy a strategy making book. Start with the hard part first - what does DONE look like.

One Small Glitch

On page 27 of Impact Mapping is a topic of adaptive planning. Adapting your plans to emerging situations is called planning. Plans are meant to reveal the future and therefore must be changed when encountering the reality of the situation.

The picture used is of a person building a Dog House, then bringing a dog to the Dog House and realizing the Dog House is too small. Then having an ideas for a larger Dog House.

This is bad project management and bad planning. If you are going to build a Dog House, you'd better figure out what size dog will fit in the Dog House before starting to hammer. If you have a dog and build the Dog House too small, you're a poor engineer. If you build the Dog House before knowing what size dog will fit in the Dog House, you're a bad planner. 

DDSTOP

Other than that the Impact Mapping book is a must read. 

Related articles

The "Real" Root Cause of IT Project Failure 5 Questions That Need Answers for Project Success How To Assure Your Project Will Fail Why Agile is failing
Categories: Project Management

Quote of the Day

Herding Cats - Glen Alleman - Sat, 06/14/2014 - 16:37

It is remarkable that a science which began with the consideration of games of chance should become the most important object of human knowledge ‚ÄĒ Pierre Simom Laplace, 1812.

The notion that all project variables are Random Variables is not well understood in many instances, especially in the agile community and those suggesting that estimating cost, schedule, and performance are not needed to make business decisions.

In some agile paradigms, fixed duration sprints mortgage the future by pushing unfinished or un-started features to future sprints resulting in a Minimal Viable Features outcome rather than the Needed Capabilities for the business case or mission success.

While possibly useful in some domains, many domains assume the minimum features are the same as the required features. Without all the required features, the system is non-functional. Management Reserve, schedule margin, and cost margin are needed to proetct those required features, their cost and their schedule from the random behaviours shown below.

Screen Shot 2014-06-14 at 8.35.49 AM

When developing products or services using other peoples money, it is incumbent on us to have some understanding of how these random variables behave on their own and interact with each other. This knowledge provides the basis for making decisions about how that money will result in value to those providing the money. In the absence of that knowledge, those providing the money have no way of knowing when the project will complete, how much it will cost when it is complete, and what the probability is of the capabilities produced by the project to meet the needed business, technical, or mission goals. And most importantly how to make decisions based on those behaviours and interactions. They are deciding without the needed information of the consequences of their decisions. 

To continue to assume otherwise ignores Laplaces.

Related articles Four Critical Elements of Project Success How To Assure Your Project Will Fail Making Estimates For Your Project Require Discipline, Skill, and Experience Software Cost Estimating Information Can There Be Successful Projects With Fixed Dates, Fixed Budgets, and Promised Minimal Features?
Categories: Project Management

Experimenting with Better Workshops

NOOP.NL - Jurgen Appelo - Thu, 06/12/2014 - 17:43
Workshop Experiments

The first two workshops were a bit scary! (Well, for me they were.) As a facilitator, I’m trying many things for the first time. Some things work, some things don’t. That’s a good thing. The idea of exploration is, when half of the experiments fail, you’re learning as fast as possible.

The post Experimenting with Better Workshops appeared first on NOOP.NL.

Categories: Project Management

Software Development Linkopedia June 2014

From the Editor of Methods & Tools - Thu, 06/12/2014 - 17:08
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 project estimation, JavaScript frontend testing and refactoring, retrospectives, software configuration, Test-Driven Development, software tools and NoSQL databases. Blog: Calculating Velocity FAQ Blog: Writing Testable Frontend Javascript Part 1 ‚Äď Anti-patterns and their fixes Blog: Writing Testable Frontend Javascript Part 2 ‚Äď Refactor away anti-patterns Blog: Creating options by slicing features – #NoEstimates technique Article: Agile Retrospectives: Why They Matter Article: First Sketches of an App: Planning the Design ...

Creating options by slicing features - #NoEstimates technique

Software Development Today - Vasco Duarte - Thu, 06/12/2014 - 04:00

Each feature (or story) in a product backlog contains many undiscovered options. By taking features as they are without slicing them into thin slices of functionality we implicitly commit to an implementation strategy. However, when we slice features we create options that allow us to pro-actively manage the scope of a project.

Let’s return to the IT Support Ticketing System project we discussed in a previous post. A feature like the one below will not allow us to manage the scope actively.

  • As an employee I want to be able to submit issues to IT so that I can fix a particular problem that prevents me from working.

The feature above is what I would call a ‚Äúbinary‚ÄĚ feature. Either the employee is able to submit an issue to IT or not. This simple feature can have large implications in terms of the amount of work required to implement it. Taking the feature above and breaking it down into several smaller features or stories will allow us to make decisions regarding the implementation order, or delaying certain parts of the implementation. Let‚Äôs look at an example:

  • As an employee I want to be able to email an IT issue to the IT department so that I can have a fix for a problem that prevents me from working As an IT helpdesk employee I want to have a queue of issues to handle so that I know what items I should be working on at any given time.

By slicing the original feature in this particular way we unpacked the functionality under the term ‚Äúsubmit issues‚ÄĚ in the original feature into two different features: Email (replaces submit) and Queue of issues (replaces the receiving end of the submission process). We‚Äôve potentially reduced the scope of the initial feature (no need to have a system to enter IT tickets, just send an email), and we‚Äôve given ourselves the option to implement a solution based on standard tools. The two features we created allow for a solution based on email and a spreadsheet program with shared editing, like Google Docs.

These two stories could still be implemented with a full-fledged IT issue tracking system, but that is an option. Not a mandatory outcome of the initial feature. Slicing features into separate functional parts helps us actively manage the scope by creating different implementation options that are often implicit and non-negotiable when we have larger features in the backlog.

Picture credit: John Hammink, follow him on twitter

Read a Book! Or Two.

NOOP.NL - Jurgen Appelo - Wed, 06/11/2014 - 15:08
Read a Book

I started running. Again.

But unlike previous (failed) attempts, this time, I want to do it right. This time, I intend to learn. That’s why I recently read The Power of Habit, by Charles Duhigg. Instead of just going for a run whenever I feel in the mood (which is almost never), I wanted to understand how to really make running part of my daily habits. Thanks to the book, I understand what to do now. My next challenge is to look for inspiration on why to keep running, which is the reason I’m reading Eat and Run. The next book on my list is the brilliantly titled Never Wipe Your Ass with a Squirrel.

The post Read a Book! Or Two. appeared first on NOOP.NL.

Categories: Project Management

Making Estimates For Your Project Requires Discipline, Skill, and Experience

Herding Cats - Glen Alleman - Wed, 06/11/2014 - 14:07

BuffonI'm speaking at the ICEAA conference here in Denver (not on travel for once) on forecasting the Estimate At Completion (EAC) for large complex programs using Box Jenkins algorith. And the Cure for Unanticipated Growth in EAC.The notion of making estimates of cost, schedule, and performance of something goes back to the beginning of all projects. From the Egyptians to modern times. Projects that bend metal, projects that develop new life forms, projects that write software in exchange for money.

Each and every project on the planet today has three variables. These variables ae not independent. They are coupled in some way. Usually this coupling is non-linear, non-stationary (this means they are evolving) and many times unknown. These variables are cost, schedule, and delivered capabilities.

If these variable on the project are are UNKNOWABLE (Black Swans), your project is in the ditch before it starts. So let's skip that excuse for not estimating the three variables of the project. Another excuse we can dispose of is our clients don't know what they want. If this is the case, someone has to pay to find out what DONE looks like in units of measure meaningful to the decision makers. Don't have this information in some form, any form, that can be used to further the conversation? Your project is a Death March project on day one.

Modeling Random Variables on Projects

If we are managing a project, or a participant on a project, we should know something about the work we have been asked to do, the outcomes of that work, the relationships between the elements of the work - the hull size of a ship and the cost of the propulsion system. Or, the size of the hardware needed to handle the number of users on the systems. 

But the first and most important thing to know is all variables on projects are random variables. If you hear we can't estimate because we can't know exactly what the cost, schedule, or capabilities will be, that person may be unaware of the underlying statistical processes of all projects. Projects are not accounting. They are decision making processes. Decision making in the presence of uncertainty. Anyone seeking certainty - a manager, a customer, a provider - is going to be serious disapponted when they discover all the project variables are random variables, with a Mode (Most Likley), a Standard Deviation, and higher order Moments, describing the shape of the Probability Distribution Function.

So here's a simple and straightforward approach to modeling our project in Excel. Let's start with some urban myths about estimating anything:

  • Estimating is not guessing - guessing is not only bad math, it's bad management, and it's bad development. You wouldn't guess at how to size the table space on disk for your Oracle instance? No you wouldn't. You'd get to explain to your customer why you ran out of table space and the app crashed - ONCE. Then you'd have to explain to your customer, why they should keep you as a supplier or an employee.
  • There is nothing new under the sun. We're not inventing new physics. I've worked in that job early in my career and we did invent devices and their software that required new physics - surface acoustic wave digital filters. Somewhere, someone has done what you have been asked to do. If you can't find them, you can build a¬†parametric model of something that looks like you've been asked to do. This is the¬†is it bigger than a bread box game. It's also the 20 questions game. Here's an example of How To Estimate Any Software Deliverable.
  • Our Customers Don't What They Want - if this is the case you're in a¬†Death March¬†project. Buy Yourdon's book read it, Stop Doing Stupid Things on Purpose. If you've been tasked to be the steward of your customers money, time to behave like that. Inform them of the consequences of spending money without knowing what done looks like. You may be able to find what¬†DONE looks like, but it's going to cost money. And spending that money on the project may be a true¬†waste, since the customer will be spending money exploring while you are writing code for things that may never be needed to deliver those pesky¬†Capabilities that produce the needed business value.
  • We don't know how to estimate -¬†That's acceptable. Many don't. It's a common situation. But saying¬†we can't estimate, or¬†estimating is a waste, or¬†we can't forecast the future ignores a very large body of literature, books, courses, and tools that can be the foundation of learning how to estimate, that you can find here.

In The End, It Is This Simple

If you're building products or providing services using someone elses money, you are professionally obligated to provide some sort of understanding of the cost, scehdule, and probability of showing up with the needed capabilities. Since each of those is interconnected in some non-linear, non-stationary manner, with unknown, but knowable correlations between the lowest level work elements, assume a fixed budget and a set of past performance from measurements of work will provide a credible forecast of future performance is naive at best.

As a Final Aside Most the conversation arounbd agile software development assumes a list of work in the backlog, but ignores completly the correlations between these work elements in the future. This is the myth that the cost of change in flat in the agile world. This violates system logical, This idea of flat cost is true IF AND ONLY IF - and this is a BIG IF - that those produced components have not inter-dependencies between the developed components. Once there are inter-dependencies, change in one drives change in others, in unknown and possibly unknowable ways in the absence of a detailed architectural document. Design Structure Matrix applied to the architecture question is one way to assess the cost of any change in any system.   Related articles Elements of Project Success Everything is a Random Variable Four Critical Elements of Project Success
Categories: Project Management

Posted: What Is A Professional?

I write a twice-yearly column for Better Software magazine. The title of the column is called “Technically Speaking.” For this column, I decide to tackle the question of “What’s a Professional?

If you don’t already subscribe to the magazine, you do have to join the site. It’s a free registration to join.

Categories: Project Management

Posted: What Is A Professional?

I write a twice-yearly column for Better Software magazine. The title of the column is called “Technically Speaking.” For this column, I decide to tackle the question of “What’s a Professional?

If you don’t already subscribe to the magazine, you do have to join the site. It’s a free registration to join.

Categories: Project Management