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

Handling Work Left at the End of a Sprint

Mike Cohn's Blog - Tue, 10/06/2015 - 18:16

It’s quite common for a team to have a bit of unfinished work at the end of an agile sprint or iteration. Ideally, a team would finish every item on its sprint backlog every sprint. But, for a variety of reasons, that isn’t always the case. This leads to a couple of questions I’ll address here:

  • What should be done with the product backlog item itself?
  • Should be it split or should it be carried it into the next sprint? Should the team receive any velocity “credit” for completing a portion of the story?
First, Be Sure the Item Is Still Important

When a product backlog item is not finished at the end of an agile sprint, it should first technically be put back onto the product backlog. Work never moves automatically from one sprint to the next.

I’m perhaps being overly pedantic here, but the point is that each sprint begins with the product owner making a conscious, deliberate decision about what the team should work on. If there’s unfinished work from the prior sprint, it’s very likely the product owner will want the team to finish that work in the new sprint. But, the product owner should still make an actual decision to do that.

(As a note, let me also say that I’m not suggesting you make extra work for yourself if you are using a tool that would make this difficult. All I’m saying is that work does not automatically move into the next sprint. The product owner must decide if the work is still valuable.)

Splitting or Carrying the Item Forward

When a product backlog is unfinished, teams are often torn on whether they should leave the product backlog item description alone (even though part of that functionality might be complete) or rewrite it to describe just the missing piece.

For example, consider a team building typical print preview functionality in a desktop application. If the team builds everything but the ability to page backward through the pages, it can either carry forward the original user story or write a smaller, replacement story like, “As a user, I can page backward while on the print preview screen.”

I recommend that if you are going to finish the story in the coming sprint, just leave it alone. Don’t rewrite it. Everyone is used to it as it’s written. Assuming it’s still of value to the product owner, it moves forward exactly as written.

However, if the remaining work will be deferred to a later sprint, write a new story that describes just that subset of functionality. IMAGE QUOTE: If you’ll finish in the next sprint, don’t rewrite the story.

Does the Team Earn Velocity Credit

I always want to take a conservative stance towards calculating velocity. This means that a team should only take credit for work that is truly complete.

So, in the case the unfinished product backlog item is rolling forward to be completed in the next agile sprint, do not take any velocity credit. The team instead earns all credit in the sprint in which the work is finished. Since I advocate working with average velocities anyway, this averages out and avoids the risk of overstating velocity.

But when the team splits the story and puts the remaining subset onto the product backlog to be done in the future, go ahead and take some amount of velocity credit. The team will need to do its best to estimate a fair number of points for the subset of work that was completed. And, even though it did not finish the entire original story, the team may give itself all the original points if it feels the story was larger than originally planned. I’d be reluctant to do that very often. But, it is OK.

Always Look for a Root Cause

Finally, whenever work is unfinished at the end of an agile sprint, the team should take time in the retrospective to consider whether it was caused by something preventable. Sometimes, it’s just bad luck or bad timing, such as a team member becoming ill or a problem being found late in the sprint that could not have been found earlier. But, it’s always worth considering whether there is a root cause and whether something can be done to prevent it from affecting future sprints.

What Do You Do?

How do you handle work left at the end of the sprint? And have you found good ways of minimizing how often you have work left unfinished at the end?

The Methods & Tools Award for the Best Software Developer Goes to….

From the Editor of Methods & Tools - Tue, 10/06/2015 - 13:03
The story started when I was recently asked to promote some awards around Agile. I wasn’t interested about this, especially as it seems that nominees can submit their own names. Some days later, I found an update on a professional social network where one of the nominees was sharing this “honor” and many people congratulate […]

30 Hot Books for Your Backlog (October)

NOOP.NL - Jurgen Appelo - Thu, 10/01/2015 - 21:56

These new books are worth your consideration. My 30 reading tips for October! (plus 5 extra)

The post 30 Hot Books for Your Backlog (October) appeared first on NOOP.NL.

Categories: Project Management

The Unmyths of Estimating

Herding Cats - Glen Alleman - Wed, 09/30/2015 - 17:33

Phillip Armour has a classic article in CACM titled "Ten Unmyths of Project Estimation," Communications of the ACM (CACM), November 2002, Vol 45, No 11. Several of these Unmyths are applicable to the current #NoEstimates concept. Much of the misinformation about how estimating is the smell of dysfunction can be traced to these unmyths.

Mythology is not a lie ... it is metaphorical. It has been well said that mythology is the penultimate truth - Joseph Campbell, The Power of Myth

Using Campbell's quote, myths are not untrue. They are an essential truth, but wrapped in anecdotes that are not literally true. In our software development domain a myth is a truth that seems to be untrue. This is Armour's origin of the unmyth. 

The unmyth is something that seems to be true but is actually false.

Let's look at the three core conjectures of the #Noestimates paradigm:

  • Estimates cannot be accurate - we cannot get an accurate estimate of cost, schedule, or probability that the result will work.
  • We can't say when we'll be done or how much it will cost.
  • All estimates are commitments - making estimates makes us committed to the number that results from the estimate.

The Accuracy Myth

Estimates are not numeric values. they are probability distributions. If the Probability Distribution below represents the probability of the duration of a project, there is a finite minim - some time where the project cannot be completed in less time.

There is the highest probability, or the Most Likely duration for the project. This is the Mode of the distribution. There is a mid point in the distribution, the Median. This  is the value between the highest and the lowest possible completion times. Then there  is the Mean of the distribution. This is the average of all the possible completion times. And of course The Flaw of Averages is in effect for any decisions being made on this average value †


‚ÄúIt is moronic to predict without first establishing an error rate for a prediction and keeping track of one‚Äôs past record of accuracy‚Ä̬†‚ÄĒ Nassim Nicholas Taleb, Fooled By Randomness

If we want to answer the question What is the probability of completing ON OR BEFORE a specific date, we can look at the Cumulative Distribution Function (CDF) of the Probability Distribution Function (PDF). In the chart below the PDF has the earliest finish in mid-September 2014 and the latest finish early November 2014.

The 50% probability is 23 September 2014. In most of our work, we seek an 80% confidence level of completing ON OR BEFORE the need date.

The project then MUST have schedule, cost, and technical margin to protect that probabilistic date.

How much margin is another topic.

But projects without margin are late, over budget, and likely don't work on day one. Can't be complaining about poor project performance if you don't have margin, risk management, and a plan for managing both as well as the technical processes.

So where do these charts come from? They come from a simulation of the work. The order and dependencies of the work. And the underlying statistical nature of the work elements. 

  • No individual work element is deterministic.
  • Each work element has some type of dependency on the previous work element and the following work element.
  • Even if all the work elements are Independent and sitting in a Kanban queue, unless we have unlimited servers of that queue, being late on the current piece of work will delay the following work.¬†


So what we need is not Accurate estimates, we need Useful estimates. The usefulness of the estimate is the degree to which it helps make optimal business decisions. The process of estimating is Buying Information. The Value of the estimates, like all value is determined by the cost to obtain that information. The value of the estimate of the opportunity cost, which is the different between the business decision made with the estimate and the business decision made without the estimate. ‡

Anyone suggesting that simple serial work streams can accurately forecast -  an estimate of the completion time - MUST read Forecasting and Simulating Software Development Projects: Effective Modeling of Kanban & Scrum Projects using Monte Carlo Simulation, Troy Magennis.

In this book are the answers to all the questions those in the #NoEstimates camp say can't be answered.

The Accuracy Answer

  • All work is probabilistic.
  • Discover the Probability Distribution Functions for the work.
  • If you don't know the PDF, make one up - we use -5% + 15% for everything until we know better.
  • If you don't know the PDF, go look in databases of past work for your domain. Here's some databases:
  • If you still don't know, go find someone who does, don't guess.
  • With this framework - it's called Reference Class Forecasting - that is making estimate about your project from¬†reference classes¬†of other projects, you can start making¬†useful estimates.¬†

But remember, making estimates is how you make business decisions with opportunity costs. Those opportunity costs are the basis of Microeconomics and Managerial Finance. 

Cone of Uncertainty and Accuracy of Estimating

There is a popular myth that the Cone of Uncertainty prevents us from making accurate estimates. We now know we need useful estimates, but those are not prevented by in the cone of uncertainty. Here's the guidance we use on our Software Intensive Systems projects.


Finally in the estimate accuracy discussion comes the cost estimate. The chart below shows how cost is driven by the probabilistic elements of the project. Which brings us back to the fundamental principle that all project work is probabilistic. Modeling the cost, schedule, and probability of technical success is mandatory in any non-trivial project. By non-trivial I mean a de minimis project, one that if we're off by a lot it doesn't really matter to those paying.


The Commitment Unmyth

So now to the big bug a boo of #NoEstimates. Estimates are evil, because they are taken as commitments by management. They're taken as commitment by Bad Management, uninformed management., management that was asleep in the High School Probability and Statistics class, management that claims to have a Business degree, but never took the Business Statistics class. 

So let's clear something up,

Commitment is how Business Works

Here's an example taken directly from ‡ 

Estimation is a technical activity of assembling technical information about a specific situation to create hypothetical scenarios that (we hope) support a business decision. Making a commitment based on these scenarios is a business function.

The Technical ‚ÄúEstimation‚ÄĚ decisions include:

  • When does our flight leave?
  • How do we get there? Car? Bus?
  • What route do we take?
  • What time of day and traffic conditions?
  • How busy is the airport, how long are the lines?
  • What is the weather like?
  • Are there flight delays?

This kind of information allows us to calculate the amount of time we should allow to get there.

The Business ‚ÄúCommitment‚ÄĚ and Risk decisions include:

  • What are the benefits in catching the flight on time?
  • What are the consequences of missing the plane?
  • What is the cost of leaving early?

These are the business consequences that determine how much risk we can afford to take.

Along with these of course is the risk associated with the uncertainty in the decisions. So estimating is also Risk Management and Risk Management is management in the presence of uncertainty. And the now familiar presentation from this blog.

Managing in the presence of uncertainty from Glen Alleman

Wrap Up

Risk Management is how Adults manage projects - Tim Lister. Risk management is managing in the presence of uncertainty. All project work is probabilistic and creates uncertainty. Making decisions in the presence of uncertainty requires - mandates actually - making estimates (otherwise you're guess your pulling numbers from the rectal database).  So  if we're going to have an Adult conversation about managing in the presence of uncertainty, it's going to be around estimating. Making estimates. improving estimates, making estimates valuable to the decision makers. 

Estimates are how business works - exploring for alternatives means willfully ignoring the needs of business. Proceed at your own risk

† This average notion is common in the No estimates community. Take all the past stories or story points and find the average value and use that for the future values. That is a serious error in statistical thinking, since without the variance being acceptable, that average can be wildly off form the actual future outcomes of the project

‡ Unmythology and the Science of Estimation, Corvus International, Inc., Chicago Software Process Improvement Network, C-Spin, October 23, 2013

Related articles Architecture -Center ERP Systems in the Manufacturing Domain IT Risk Management Why Guessing is not Estimating and Estimating is not Guessing
Categories: Project Management

Five Years Ago

NOOP.NL - Jurgen Appelo - Wed, 09/30/2015 - 16:57

On October 1, 2010, I started my life as a self-employed entrepreneur. My full-color high-quality #Workout book costs ONLY EUR 15.00 excluding VAT (normally EUR 27.50) for 24 hours on October 1.

The post Five Years Ago appeared first on NOOP.NL.

Categories: Project Management

All Conjectures Need a Hypothesis

Herding Cats - Glen Alleman - Tue, 09/29/2015 - 16:53

As far as hypothesis are concerned, let no one expect anything certain from astronomy, which cannot furnish it, lest he accept as the truth ideas conceived for another purpose, and depart from this study a greater fool than when he entered it. Andreas Osiander's (editor) preface to De Revolutionbus, Copernicus, in To Explain the World: The Discovery  of Modern Science, Steven Weinberg

In the realm of project, product, and business management we come across nearly endless ideas conjecturing to solve some problem or another.

Replace the word Astronomy with what ever word those conjecturing a solution will fix some unnamed problem.

From removing the smell of dysfunction, to increasing productivity by 10 times, to removing the need to have any governance frameworks, to making decisions in the presence of uncertainty without the need to know the impacts of those decisions.

In the absence of any hypothesis by which to test those conjectures, leaving a greater fool than when entering is the likely result. In the absence of a testable hypothesis, any conjecture is an unsubstantiated anecdotal opinion.

An anecdote is a sample of one from an unknown population

And that makes those conjectures doubly useless, because they can not only not be tested, they are likely applicable only the those making the conjectures.   

If we are ever to discover new and innovative ways to increase the probability of success for our project work, we need to move far away from conjecture, anecdote, and untestable ideas and toward evidence based assessment of the problem, the proposed solutions and the evidence that the propsed correction will in fact result in improvement.

One Final Note

As a first year Grad student in Physics I learned a critical concept that is missing from much of the conversation around process improvement. When an idea is put forward in the science and engineering world, the very first thing is to do a literature search.

  • Is this idea recognized by others as being credible. Are there supporting studies that confirm the effectiveness and applicability of the idea outside the authors own experience?
  • Are those supporting the idea, themselves credible, or just following the herd?
  • Are there references to the idea that have been tested outside the authors own experience?
  • Are there criticisms of the idea in the literature? Seeking critics is itself a critical success factor in testing any ideas. There would be knock down drag out shouting matches in the halls of the physics building about an idea. Nobel Laureates would be waving arms and speaking in loud voices. In the end it was a test of new and emergent ideas. And anyone who takes offense to being criticized, has no basis to stand on for defending his idea.¬†
  • Is the idea the basis of a business, e.g. is the author¬†selling something. A book, a seminar, consulting services?
  • Has this ¬†idea been tested by someone else. We'd tear down our experiment, have someone across the country rebuild it, run the data and see if they got the same results.¬†

Without some way to assess the credibility of any idea, either through replication, assessment against a baseline (governance framework, accounting rules, regulations), the idea is just an opinion. And like Daniel Moynihan says:

Everyone is entitled to his own opinion, but not his own facts. 

and of course my favorite

Again and again and again ‚ÄĒ what are the facts? Shun wishful thinking, ignore divine revelation, forget what "the stars foretell," avoid opinion, care not what the neighbors think, never mind the unguessable "verdict of history" ‚ÄĒ what are the facts, and to how many decimal places?¬†You pilot always into an unknown future; facts are your single clue. Get the facts! -¬†Robert Heinlein (1978)

Related articles Architecture -Center ERP Systems in the Manufacturing Domain IT Risk Management Why Guessing is not Estimating and Estimating is not Guessing
Categories: Project Management

Shifting from Scarcity to Abundance Thinking

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

Over the past few months, I've read a few books on marketing. But I've also taken a handful of video training courses on marketing and have been listening to some enjoyable podcasts on the subject. Back when I was in college, we really did look down on the people majoring in marketing. This was the 1980s. And it seemed like they often chose that major because it didn't require any math at all. And to an outsider, the main skills they appeared to need were a firm handshake and a good golf game.

A lot has changed since then and I've become fascinated with marketing because of all the data that's available to marketers today. It appeals to my analytical side. So while consuming all this content on marketing, I noticed something. Individuals whom I thought would be competitors in that space were often endorsing one another.

Scarcity and Abundance Mindsets

And I realized this no longer happens as often as it should within the community of Scrum trainers and coaches. Too many professional Scrum trainers and coaches have shifted into a scarcity mindset. Each trainer then acts as though any win by another trainer is a loss for his or her own business. Their thinking implies there are only so many clients in the world and clients are to be divvied up like slices of a pie.

But what if that client someone else trains is then wildly successful and tells 10 or 100 or 1,000 other people? The pie grows and it can very likely grow large enough that everyone wins. This is an abundance mindset rather than a scarcity mindset.

The Founding of the Scrum Alliance

When Ken Schwaber, Esther Derby and I co-founded the Scrum Alliance, part of the plan was a credibility transfer from ourselves and the organization to other trainers. We knew that for Scrum to succeed in the world, it needed a lot more training and coaching than the three of us could or wanted to provide. And, approaching it with an abundance mindset, we knew the need for Scrum training and coaching would grow well beyond what the three of us could provide.

And that brings me to today: Many of us who make our livings training and coaching Scrum (or agile in general) seem to have reverted to a scarcity mindset. I'm generalizing, of course. There are some wonderful examples of people within the Scrum community who live an abundance mindset daily. I wonder though if it gets tough for them to continue doing so when many around them are doing the opposite.

We Are Partners and Future Partners, Not Competitors

One of the marketing books I read made an interesting point. The author said he never refers to others in his space as "competitors." Instead, they are "partners" and "future partners." And this is indeed what I noticed while participating in video training and podcasts from these marketing experts. Even when some of them could have viewed themselves as competitors since they sold similar products and services, they knew that if I bought a product from one of them, it did not preclude me from buying a product from the others

So, if you are a Scrum Alliance Certified Scrum Trainer or Coach, or a Professional Scrum Trainer, please know that I consider you a partner or future partner. You aren't my competition, and I'm not yours. Our competition is crappy products and all the forces of nature that conspire to make teams build crappy software.

And, if you're reading my blog looking for a training course, I hope you'll consider mine. But, it's a big world and I may not be in your area at the time you want training. In that case, I sincerely hope you'll consider training, coaching or at least reading the blogs of my "partners and future partners."

Finally, CSTs, CSCs and PSTs (my partners and future partners!): I encourage you to leave links to training pages, bios, blogs, etc. below.

As always, I look forward to everyone's thoughts in the comments below.

Software Development Conferences Forecast September 2015

From the Editor of Methods & Tools - Tue, 09/29/2015 - 07:52
Here is a list of software development related conferences and events on Agile project management ( Scrum, Lean, Kanban), software testing and software quality, software architecture, programming (Java, .NET, JavaScript, Ruby, Python, PHP) and databases (NoSQL, MySQL, etc.) that will take place in the coming weeks and that have media partnerships with the Methods & […]

Projects versus Products

Herding Cats - Glen Alleman - Mon, 09/28/2015 - 16:00

There's a common notion in some agile circles the projects aren't the right vehicle for developing products. This is usually expressed by Agile Coaches. As a business manager, applying Agile to develop products  as well as delivering Operational Services based on those products, projects are how we account for the expenditures of those outcomes, manage the resources and coordinate the needed resources to produce products as planned.

In our software product business, we use both a Product Manager and a Project Manager. These roles are separate and at the same time overlapping.

  • Products¬†are customer facing. Market needs, business models for revenue, cost, earnings, interfaces with Marketing and Sales and other business management processes- contracts, accounting - are Product focused.

Product Managers focus on Markets. What features are the market segments demanding? What features Must Ship and what featues can we drop? What is the Sales impacts of any slipped dates?

  • Projects are¬†internally facing - internal resources need looking after. The notion of¬†self organizing is fine, but¬†self directed¬†only works when the work efforts have direct contact with the customers. And even then, without some oversight - governance - a self directed team has limitations in the larger context of the business. If the¬†self directed¬†team IS the business, then the need for external governance is removed. This would be rare in any non-trivial business.¬†

Project Managers are inward focused to the resource allocation and management of the development teams. How can we get the work done to meet the market demand? When can we ship the product to maintain the sales forecast?

In very small companies and startups these roles are usually performed by the same person.

Once we move beyond the sole proprietor and his friends, separation of concerns takes over. These roles become distinct.

  • The Product Manager is a member of the Business Development Team, tasked with the business side of the product delivery process.¬†
  • The Project Management Team (PMs and Coordinators, along with development leads and staff), is a member of the delivery team tasked with producing the capabilities needs to capture and maintain the market.

Products are about What and Why. Projects are about Who, How, When, and Where. From Rudyard Kipling's Six Trusted Friends)

Product Management focuses on the overall product vision - usually documented in a Product Roadmap, showing the release cycles of capabilities and features as a function of time. Project Management is about logistics, schedule, planning, staffing, and work management to produce products in accordance with the Road Map.

When agile says it's customer focused, this is true only when there is One customer for the Product, rather than a Market for the Product and that customer is on site. That'd not be a very robust product company if they had only one customer. 

When we hear Products are not Projects, ask in what domain, business size, and value at risk is it possible not to separate these concerns between Products and Projects?

Related articles Architecture -Center ERP Systems in the Manufacturing Domain IT Risk Management Why Guessing is not Estimating and Estimating is not Guessing
Categories: Project Management

Risk Management is How Adults Manage Projects

Herding Cats - Glen Alleman - Sun, 09/27/2015 - 20:59

Risk Management is How Adults Manage Projects - Tim Lister

Let's start with some background on Risk Management

Tim's quote sets the paradigm for managing the impediments to success in all our endeavors

It says volumes about project management and project failure. It also means that managing risk is managing in the presence of uncertainty. And managing in the presence of uncertainty means making estimates about the impacts of our decision on future outcomes. So you can invert the statement when you hear we can make decisions in the absence of estimates.

Tim's update is titled Risk Management is Project Management for Grownups.

For those interested in managing projects in the presence of uncertainty and the risk that uncertainty creates, here's a collection from the office library, in no particular order

Here's a summary at a recent meeting around decision making in the presence of risk

Earning value from risk (v4 full charts) from Glen Alleman
Categories: Project Management

Complex, Complexity, Complicated (Update)

Herding Cats - Glen Alleman - Sun, 09/27/2015 - 16:14

Cynefin_as_of_1st_June_2014The popular notion that Cynefin can be applied in the software development domain as a way of discussing the problems involved in writing software for money is missing the profession of Systems Engineering. From Wikipedia Cynefin is...

The framework provides a typology of contexts that guides what sort of explanations or solutions might apply. It draws on research into complex adaptive systems theory, cognitive science, anthropology, and narrative patterns, as well as evolutionary psychology, to describe problems, situations, and systems.

While Cynefin uses the term Complexity and Complex Adaptive System, it is applied from the observational point of view. That is the system exists outside of our influence on the system to control its behavior - we are observers of the systems, not engineers of the solutions in the form of a system that provides needed capabilities to solve a problem.

Read carefully the original paper on Cynefin The New Dynamics of Strategy: Sense Making in a Complex and Complicated World This post is NOT about those types of systems, but about the conjecture that the development of software is by its nature Chaotic. This argument is used by many in the agile world for avoid the engineering disciplines of INCOSE style Systems Engineering.  

There are certainly engineered systems that transform into complex adaptive systems with emergent behaviors that cause the system to fail. Example below. This is not likely to be the case when engineering principles are applied in the domains of Complex and Complicated.

A good starting point for the complex, complicated, and chaotic view of engineered systems is Complexity and Chaos - State of the Art: List of Works, Experts, Organizations, Projects, Journals, Conferences, and Tools There is a reference to Cynefin as organization modeling. While organizational modeling is important - I suspect Cynefin advocates would suggest the only important item - the engineered aspects  of applying Systems Engineering to complex, complicated, and emergent systems is mandatory for any organization to get the product out the door on time, on budget, and on specification.

For another view of the complex systems problem Principles of Complex Systems for Systems Engineering is a good place to start along with the resources from INCOSE and AIAA like Complexity Primer for Systems Engineers, Engineering Complex Systems, Complex System Classification, and many others.

So Let's Look At the Agile Point of View

In the agile community it is popular to use the terms complex, complexity, complicated, complex adaptive system many times interchangeably and many times wrongly - to assert we can't possibly plan ahead, know what we're going to need, and establish a cost and schedule because the systems complex, and emergent.

These terms are many times overloaded with an agenda used to push a process or even a method. As well, in the agile community it is popular to claim we have no control over the system, so we must adapt to its emerging behavior. This is likely the case in one condition - the chaotic behaviors of Complex Adaptive Systems. But this is only the case when we fail to establish the basis for how the CAS was formed and what sub-systems are driving that behaviors, and most importantly what are the dynamics of the interfaces between those subsystems - the System of Systems architecture - that create the chaotic behaviors . 

It is highly unlikely those working in the agile community actually work on complex systems that evolve AND at the same time are engineered at the lower levels to meet specific capabilities and resulting requirements of the system owner. They've simply let the work and the resulting outcomes emerge and become Complex, Complicated, and create Complexity. They are observers  of the outcomes, not engineers of the outcomes.

Here's one example of an engineered system that actually did become a CAS because of poor efforts of the Systems Engineers. I worked on Class I and II sensor platforms. Eventually FCS was canceled for all the right reasons. But for small teams of agile developers the outcomes become complex when the Systems Engineering processes are missing. Cynefin partitions beyond obvious emerge for the most part when Systems Engineering is missing.


First some definitions

  • Complex - consisting of many different and connected part. Not easy to analyze or understand. Complicated or intricate. When a system or problem is considered complex, analytical approaches, like dividing it into parts to make the problem tractable is not sufficient, because it is the interactions of the parts that make the system complex and without these interconnections, the system no longer functions.
  • Complex System -¬†is a functional whole, consisting of interdependent and variable parts. Unlike conventional systems, the parts need not have fixed relationships, fixed behaviors or fixed quantities, and their individual functions may be undefined in traditional terms.
  • Complicated - containing a number of hidden parts, which must be revealed separately because they do not interact. Mutual interaction of the components creates nonlinear behaviors of the system. In principle all systems are complex. The number of parts or components is irrelevant n the definition of complexity. There can be complexity - nonlinear behaviour - in small systems of large systems.¬†
  • Complexity - there is no standard definition of complexity is a view of systems that suggests simple causes result in complex effects. Complexity as a term¬†is generally used to characterize a system with many parts whose interactions with each other occur in multiple ways. Complexity can occur in a variety of forms
    • Complex behaviour
    • Complex mechanisms
    • Complex situations
    • Complex systems
    • Complex data
  • Complexity Theory -¬†states that critically interacting components self-organize to form potentially evolving structures exhibiting a hierarchy of emergent system properties.¬†This theory takes the view that systems are best regarded as wholes, and studied as such, rejecting the traditional emphasis on simplification and reduction as inadequate techniques on which to base this sort of scientific work.

One more item we need is the types of Complexity

  • Type 1 - fixed systems, where the structure doesn't change as a function of time.
  • Type 2 - systems where time causes changes. This can be repetitive cycles or change with time.
  • Type 3 - moves beyond repetitive systems into organic where change is extensive and non-cyclic in nature.
  • Type 4 - are self organizing where we can¬†combine internal constraints of closed systems, like machines, with the creative evolution of open systems, like people.

And Now To The Point

When we hear complex, complexity, complex systems, complex adaptive system, pause to ask what kind of complex are you talking about. What Type of complex system. In what system are you applying the term complex. Have you classified that system in a way that actually matches a real system. Don't take anyone saying well the system is emerging and becoming too complex for us to manage Unless in fact that is the case after all the Systems Engineering activities have been exhausted. It's a cheap excuse for simply not doing the hard work of engineering the outcomes.

It is common use the terms complex, complicated, and complexity interchanged. And software development is classified or mis-classified as one or the both or all three. It is also common to toss around these terms with not actual understanding of their meaning or application.

We need to move beyond buzz words. Words like Systems Thinking. Building software is part of a system. There are interacting parts that when assembled, produce an outcome. Hopefully a desired outcome. In the case of software the interacting parts are more than just the parts. Software has emergent properties. A Type 4 system, built from Type 1, 2, and 3 systems. With changes in time and uncertainty, modeling these systems requires stochastic processes. These processes depend on estimating behaviors as a starting point. 

The understanding that software development is an uncertain process (stochastic) is well known, starting in the 1980's [1] with COCOMO. Later models, like Cone of Uncertainty made it clear that these uncertainties, themselves, evolve with time. The current predictive models based on stochastic processes include Monte Carlo Simulation of networks of activities, Real Options, and Bayesian Networks. Each is directly applicable to modeling software development projects.

[1] Software Engineering Economics, Barry Boehm, Prentice-Hall, 1981.

Related articles Decision Analysis and Software Project Management Making Decisions in the Presence of Uncertainty Some More Background on Probability, Needed for Estimating Approximating for Improved Understanding The Microeconomics of a Project Driven Organization How to Avoid the "Yesterday's Weather" Estimating Problem Hope is not a Strategy Architecture -Center ERP Systems in the Manufacturing Domain IT Risk Management Why Guessing is not Estimating and Estimating is not Guessing
Categories: Project Management

Why Do Projects Fail?

Herding Cats - Glen Alleman - Sat, 09/26/2015 - 17:25

Project-management-failureWe all wish that there was a simple answers to this question, but there are not. Anyone suggesting there is, doesn't understand the complexities of non-trivial projects in any domain.

There are enough opinions to paper the side of a battle ship.  With all these opinions, nobody has a straightforward answer that is applicable to all projects. There are two fundamental understanding though: (1) Everyone has a theory , (2) there is no singular cause that is universally applicable.

In fact most of the suggestions on project failures have little in common. With that said, I'd suggest there is a better way to view the project failure problem.

What are the core principles, processes, and practices for project success?

I will suggest there are three common denominators consistently mentioned in the literature that are key to a project’s success:

  1. Requirements management. Success was not just defined by well-documented technical requirements, but well-defined programmatic requirements/thresholds. Requirements creep is a challenge for all projects, no matter what method is used to develop the products or services from those projects. Requirements creep comes in many forms. But the basis for dealing with requirements creep starts with a Systems Engineering strategy to manage those requirements. Mist IT and business software projects don't know about Systems Engineering, and that's a common cause failure mode.
  2. Early and continuous risk management , with specific steps defined for managing the risk once identified.
  3.  Project planning. Without incredible luck, no project will succeed without a realistic and thorough plan for that success. It's completely obvious (at least to those managing successful projects), the better the planning, the more likely the outcome will match the plan.

Of the 155 defense project failures studied in ‚ÄúThe core problem of project failure,‚ÄĚ T. Perkins, The Journal of Defense Software Engineering, Vol 3. 11, pp 17, June 2006.

  • 115 ‚Äď Project managers did not know what to do.
  • 120 ‚Äď Project manager overlooked implementing a project ¬† management principle.
  • 125 ‚Äď PMs allowed constraints imposed at higher levels to prevent ¬† them from doing what they should do.
  • 130 ‚Äď PMs do not believe the project management principles add ¬† value.
  • 145 ‚Äď Policies / directives prevented PMs from doing what they ¬† should do.
  • 150 ‚Äď Statutes prevented PMs from doing what they should do.
  • 140 ‚Äď PMs primary goal was other than project success.
  • 135 ‚Äď PMs believed a project management principle was flawed.

From this research these numbers can be summarized into two larger classes

  • Lack of knowledge - the project managers and the development team did not know what to do
  • Improper application of this knowledge - this start with ignoring or overlooking a core principle of project success. This cover most ¬†of the sins of Bad Management, from compressed schedules, limited budge, to failing to produce credible estimates for the work.¬†

So where do we start?

Let's start with some principles. But first a recap

  • Good management doesn't simply happen. It takes qualified managers ‚Äď on both the buyer and supplier side, to appropriately apply project management methods.
  • Good planning doesn‚Äôt simply happen. Careful planning of work scope, WBS, realistic milestones, realistic metrics, and a realistic cost baseline is needed.
  • It is hard work to provide accurate data about schedule, work performed, and costs on a periodic basis.¬†Constant communications and trained personnel is necessary.

Five Immutable Principles of Project Success

Screen Shot 2015-09-26 at 9.03.00 AM

  1. What capabilities are needed to fulfill the Concept of Operations, the Mission and Vision, or the Business System Requirements? Without knowing the answers to these questions, requirements, features, deliverables have no home. They have no testable reasons for being in the project. 
  2. What technical and operational requirements are needed to deliver these capabilities? With the needed capabilities confirmed by those using the outcomes of the project, the technical and operational requirements can be defined. This can be stated up front, or they can emerg as the project progresses. The Capabilities are stable, all other things can change as discovery takes place. If you keep changing the capabilities, you're going to be on a Death March project
  3. What schedule delivers the product or services on time to meet the requirements? Do you have enough money, time, and resources to show up as planned. No credible project doesn't have a deadline and a set and mandated capabilities. Knowing there is sufficient everything on day one and every day after that is the key to managing in the presence of uncertainty. 
  4. What impediments to success, their mitigations, retirement plans, or “buy downs are in place to increase the probability of success?" Risk Management is how Adults Manage Projects - Tim Lister is a go place to start. The uncertainties of all project work come in two type - reducible and irreducible. For irreducible we need margin. For reducible we need specific retirement activities.
  5. What periodic measures of physical percent complete assure progress to plan? This question is based on a critical principle - how long are we willing to wait before we find out we're late?  This period varies but what ever it is it must ve short enough to take corrective action to arrive as planned. Agile does is every two to four week. In formal DOD procurement, measures of physical percent complete are done every four weeks. The advantage of Agile is working products must be produced every period. Not the case in larger more formal processes.

 With these Principles, here's five Practiuces that can put them to work

Screen Shot 2015-09-26 at 10.13.08 AM

  1. Identify Needed Capabilities to achieve program objectives or the particular end state. Define these capabilities through scenarios from the customer point of view in units of Measure of Effectiveness (MoE) meaningful to the customer.
    • Describe the business function that will be enabled by the outcomes of the project.
    • Assess these functions be assessed in terms of Effectiveness and Performance.
  2. Define the Technical And Operational Requirements that must be fulfilled for the system capabilities to be available to the customer at the planned time and planned cost. Define these requirements in terms that are isolated from any implementation technical products or processes. Only then bind the requirements with technology.
    • This can be a formal Work Breakdown Structure or an Agile Backlog
    • The planned work is described in terms of deliverables.¬†
    • Describe the technical and operation Performance measures for each feature
  3. Establish the Performance Measurement Baseline describing the work to be performed, the budgeted cost for this work, the organizational elements that produce the deliverables from this work, and the Measures of Performance (MoP) showing this work is proceeding according to cost, schedule, and technical performance.
  4. Execute the PMB’s Work Packages in the planned order, assuring all performance assessments are 0%/100% complete before proceeding. No rework, no transfer of activities to the future. Assure every requirement is traceable to work and all work is traceable to requirements.
    • If there is no planned order the work processes will be simple.
    • This is a rarely on any enterprise or non-trivial project, since the needed capabilities usually have some sequential dependencies. Accept Produce Purchase Request before issuing Purchase Order.
  5. Perform Continuous Risk Management for each Performance‚ÄďBased Project Management¬ģ process area to Identify, Analyze, Plan, Track, Control, and Communicate programmatic and technical risk.

The integration of these five Practices are the foundation of Performance‚ÄďBased Project Management¬ģ.¬†Each Practice stands alone and at the same time is coupled with the other Practices areas. Each Practice contains specific steps for producing beneficial outcomes to the project, while establishing the basis for overall project success.

Each Practice can be developed to the level needed for specific projects. All five Practices are critical to the success of any project. If a Practice area is missing or poorly developed, the capability to manage the project will be jeopardized, possibly in ways not know until the project is too far along to be recovered.

Each Practice provides information needed to make decisions about the majority flow of the project. This actionable information is the feedback mechanism needed to keep a project under control. These control processes are not impediments to progress, but are the tools needed to increase the probability of success.

Why All This Formality, Why Not Just Start Coding, Let Customer Tell Us  To Stop?

All business works on managing the flow of cost in exchange for value. All business has a fiduciary responsibility to spend wisely. Visibility to the obligated spend is part of Managerial Finance. Opportunity Cost is the basis of Microeconomics of decision making. 

The 5 Principles and 5 Practices are the basis of good business management of the scarce resources of all businesses. 

This is how adults manage projects

Related articles Architecture -Center ERP Systems in the Manufacturing Domain IT Risk Management Why Guessing is not Estimating and Estimating is not Guessing
Categories: Project Management

Software Engineering Economics

Herding Cats - Glen Alleman - Sat, 09/26/2015 - 04:51

When confronted with making decisions on software projects in the presence of uncertainty, we can turn to an established and well tested set of principles found in Software Engineering Economics.

First a definition from Guide to the Systems Engineering Body of Knowledge (SEBoK)

Software Engineering Economics is concerned with making decisions within the business context to align technical decisions with the business goals of an organization. Topics covered include fundamentals of software engineering economics (proposals, cash flow, the time-value of money, planning horizons, inflation, depreciation, replacement and retirement decisions); not for-profit decision-making (cost-benefit analysis, optimization analysis); estimation, economic risk and uncertainty (estimation techniques, decisions under risk and uncertainty); and multiple attribute decision making (value and measurement scales, compensatory and non-compensatory techniques).

Engineering Economics is one of the Knowledge Areas for educational requirements in Software Engineering defined by INCOSE, along with Computing Foundations, Mathematical Foundations, and Engineering Foundations. 

A critical success factor for all software development is to model the system under development as holistic, value-providing entities have been gaining recognition as a central process of systems engineering. The use of modeling and simulation during the early stages of the system design of complex systems and architectures can:

  • Document system needed capabilities, functions and requirements,
  • Assess the mission performance,
  • Estimate costs, schedule, and needed product performance capabilities¬†
  • Evaluate tradeoffs,¬†
  • Provide insights to improve performance, reduce risk, and manage costs.

The process above can be performed in any lifecycle duration. From formal top down INCOSE VEE to Agile software development. The process rhythm is independent of the principles.

This is a critical communication factor - separation of Principles, Practices, and Processes, establishes the basis of comparing these Principles, Practices, and Processes across a broad spectrum of domains, governance models, methods, and experiences. Without a shared set of Principles, it's hard to have a conversation.  

Engineering Economics

Developing products or services with other peoples money means we need a paradigm to guide our activities. Since we are spending other peoples money, the economics of that process is guided by Engineering Economics.

Engineering economic analysis concerns techniques and methods that estimate output and evaluate the worth of products and services relative to their costs. (We can't determine the value of our efforts, without knowing the cost to produce that value) Engineering economic analysis is used to evaluate system affordability. Fundamental to this knowledge area are value and utility, classification of cost, time value of money and depreciation. These are used to perform cash flow analysis, financial decision making, replacement analysis, break-even and minimum cost analysis, accounting and cost accounting. Additionally, this area involves decision making involving risk and uncertainty and estimating economic elements. [SEBok, 2015]

The Microeconomic aspects of the decision making process is guided by the principles of  making decisions regarding the allocation of limited resources. In software development we always have limited resources - time, money, staff, facilities, performance limitations of software and hardware.

If we are going to increase the probability of success for software development projects we need to understand how to manage in the presence of the uncertainty surrounding time, money, staff, facilities, performance of products and services and all the other probabilistic attributes of our work.

To make decisions in the presence of these uncertainties, we need to make estimates about the impacts of those decisions. This is an unavoidable consequence of how the decision making process works.

The opportunity cost of any decision between two or more choices means there is a cost for NOT choosing one or more of the available choices. This is the basis of microeconomics of decision making. What's the cost of NOT selecting an alternative?

So when it is conjectured we can make a decision in the presence of uncertainty without estimating the impact of that decision, it's simply NOT true.

That notion violates the principle of Microeconomics   

Related articles Architecture -Center ERP Systems in the Manufacturing Domain IT Risk Management Why Guessing is not Estimating and Estimating is not Guessing
Categories: Project Management

Multitasking Is Bad, Multiprojecting Is Good

NOOP.NL - Jurgen Appelo - Wed, 09/23/2015 - 11:47

Whenever someone warns you that you shouldn’t be working on different things, because it’s bad for your productivity, tell them the problem is multitasking, not multiprojecting.

The post Multitasking Is Bad, Multiprojecting Is Good appeared first on NOOP.NL.

Categories: Project Management

Determining Schedule Margin with Monte Carlo Simulation

Herding Cats - Glen Alleman - Tue, 09/22/2015 - 15:54

Picture1Constructing a credible Integrated Master Schedule (IMS) requires sufficient schedule margin be placed at specific locations to protect key deliverables. One approach to determining this margin is the use of a Monte Carlo simulation tool.

This probabilistic margin analysis starts with the construction of a ‚Äúbest estimate‚ÄĚ Integrated Master Schedule with the work activities arranged in a ‚Äúbest path‚ÄĚ network.

While there may be ‚Äúslack‚ÄĚ in some of the activities, the Critical Path exists through this network for each Key Deliverable. This network of activities must show how each deliverable will arrive on or before the contractual need date. This ‚Äúbest path‚ÄĚ network is the Deterministic Schedule ‚Äď the schedule with fixed activity durations.

By assigning a duration variance for each class of work activity, the Monte Carlo model shows if the at what confidence level the probabilistic delivery date occurs on or before the deterministic date. The needed schedule margin for each deliverable can be derived by the Monte Carlo simulation. This activity network is referred to as the Probabilistic Schedule ‚Äď the schedule with activity durations of random variables.

With the schedule margin inserted in front of each deliverable, the Deterministic schedule becomes the basis of the Probabilistic schedule. Next is a cycle of adjusting the Deterministic schedule to assure the needed margin produces the final baselined Deterministic schedule to be placed on baseline. As the program proceeds, this schedule margin is managed through a ‚Äúmargin burn down‚ÄĚ process. Assessing the sufficiency of this margin for the remaining work is then part of the monthly program performance report.

Here's an example from an upcoming workshop on building and executing a credible Performance Measurement Baseline based on the Wright Brother's work

Screen Shot 2015-09-16 at 8.05.32 PM

For this to work we need several things:

  • The work to be performed. This can be a network of activities in a schedule. It can be a collection of activities in a sprint. In both cases we need some approximation of how long it will take to accomplish the work. In both cases these means making an estimate of the¬†Most¬†Likely¬†duration or work effort to produce the needed outcomes.
  • This¬†Most¬†Likely¬†value can come from many sources. But it does need to be the¬†Most Likely,¬†not the average, not some made up number, not some cockamamie guess

Here's how to use a Monte Carlo tool for determining the likelihood of completing on or before a given date, when there is a schedule of the work with Most Likelies for the work durations and the variances in those durations

Risk management using risk+ (v5) from Glen Alleman Related articles Architecture -Center ERP Systems in the Manufacturing Domain IT Risk Management Why Guessing is not Estimating and Estimating is not Guessing
Categories: Project Management

Deterministic, Probabilistic, and Empiricism

Herding Cats - Glen Alleman - Tue, 09/22/2015 - 15:43

When I hear a post like:

If you use deterministic estimates you must ask the team. If you use probabilistic estimates you must not. #NoEstimates

Two things come to mind:

  • All project work is probabilistic. There is no such thing as a deterministic estimate. OK, there is. But those estimates a wrong, dead wrong, willfully ignorant wrong. All project work is probabilistic. If you're making deterministic estimates, you've chosen to ignore the basic processes of probability and statistics.
  • There is an important difference between Statistics and Probability. Both are needed when making decisions in the presence of uncertainty.

Probability and Statistics

All projects have uncertainty.

And there are two kinds of uncertainty on all projects. Reducible and Irreducible.

UncertaintyReducible uncertainty (on the right) is described by the probability of some outcome. There is an 82% probability that we'll be complete on or before the second week in November, 2016. Irreducible uncertainty (on the left) is described by the Probability Distribution Function (PDF) for the underlying statistical processes. 

In both cases estimating is required. There is no deterministic way to produce an assessment of an outcome in the presence of uncertainty without making estimates. This is simple math. In the presence of uncertainty, the project variables are random variables, not deterministic variables. If there is no uncertainty, not need to estimate, just measure.


When we hear that #NoEstimates is about empirical data used to forecast the future, let’s look deeper into the term and the processes of empiricism.

First, an empiricist rejects the logical necessity for scientific principles and bases processes on observations. [1]

While managing other people’s money in the production of value in exchange for that money, there are principles by which that activity is guided. For empiricist principles are not immediately evident. But principles are called principles because they are indemonstrable and cannot be deduced form other premises nor be proved by any formal procedure. They are accepted they have been observed to be true in many instances and to be false in none. 

Second, with empirical data comes two critical assumptions that must be tested before that data has any value in decision making.

  • The variances in the sampled data is sufficiently narrow to allow sufficient confidence in forecasting the future. A ¬Ī45% variance is of little use. Next is the¬†killer problem.
  • With an acceptable variance, the assumption that the future is like the past must be confirmed. If this is not the case, that acceptably sampled data with the acceptable variance is not representative of the future behavior of the project.

Understanding this basis of empiricism is critical to understanding the notion of making predictions in the presence of uncertainty about the future.

Next let’s address the issue of what is an estimate. It seems obvious to all working in engineering, science, and financial domain that an estimate is a numeric value or range of values for some measure that may occur at sometime in the future.Making up definitions for estimate or selecting definition outside of engineering, science, and finance is disingenuous. There is no need to redefine anything. 

Estimation consists of finding appropriate values (the estimate) for the parameters of the system of concern in such a way that some criterion is optimized. [2]

The estimate has several elements:

  • The quantity for the estimate ‚Äď a numeric value we seek to learn about.
  • The range of possible values for that quantity
  • For estimates that have a range of values, the probability distribution of the values in the range of values. The Probability distribution function for the estimated values. The range of values is described by the PDF, with a Most¬†Likely, Median, Mode, and other cummulants ‚Äď that is what‚Äôs the¬†variance of the variance?
  • For an estimates that has a probability of occurrence, the single numeric value for that probability and the confidence on that value. There is an 80% confidence of completing the project on or before the second week in November, 2005

Now when those wanting to redefine what an estimate is to support their quest to have No Estimates, like redefining forecasting as Not Estimating, it becomes clear they are not using any terms found in engineering, science, mathematics, or finance. When they suggest there are many definitions of an estimate and don’t provide any definition, with the appropriate references to that definition, it’s the same approach as saying we’re exploring for better ways to ….  It’s a simple and simple minded approach to a well established discipline and making decisions and fundamentally disingenuous. And should not be tolerated.

The purpose of a cost estimate is determined by its intended use, and its intended use determines its scope and detail.

Cost estimates have two general purposes:

  1. To help managers evaluate affordability and performance against plans, as well as the selection of alternative systems and solutions,
  2. To support the budget process by providing estimates of the funding required to efficiently execute a program.
    • The notion of defining the budget leaves open the other two random variables of all project work ‚Äď productivity and performance of the produced product or service.
    • So suggesting that estimating is no needed when the budget of provided, ignores these two are variables.

Specific applications for estimates include providing data for trade studies, independent reviews, and baseline changes. Regardless of why the cost estimate is being developed, it is important that the project’s purpose link to the missions, goals, and strategic objectives and connect the statistical and probabilistic aspects of the project to the assessment of progress to plan and the production of value in exchange for the cost to produce that value.

The Need to Estimate

The picture below, with apologies for Scott Adams, is typical of the No Estimates advocates who contend estimates are evil and need to be stopped. Estimates can’t be done. Not estimating results in a ten-fold increase in project productivity or some vague unit of measure.  


[1] Dictionary of Scientific Biography, ed. Charles Coulston Gillespie, Scribner, 1073, Volume 2, pp. 604-5

[2] Forecasting Methods and Applications, Third Edition, Spyros Makridakis, Steven C. Whellwright, and Rob J. Hayndman

Some More Background

  1. Introduction to Probability Models, 4th Edition, Sheldon M. Ross
  2. Random Data: Analysis and Measurement Procedures, Julius S. Bendat and Allan G. Piersol
  3. Advanced Theory of Statistics, Volume 1: Distribution Theory, Sir Maurice Kendall and Alan Stuart
  4. Estimating Software Intensive Systems: Projects, Productsm and Processes, Richard D. Stutzke
  5. Probability Methods for Cost Uncertainty Analysis: A Systems Engineering Perspective, Paul R. Garvey
  6. Software Metrics: A Rigorous and Practical Approach, Third Edition, Norman Fenton and James Bieman
Related articles Architecture -Center ERP Systems in the Manufacturing Domain IT Risk Management Why Guessing is not Estimating and Estimating is not Guessing Herding Cats: The Economics Of Software Development Herding Cats: Decision Support is a Core Business Process
Categories: Project Management

Upfront Thinking Is Like Insurance

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

Insurance is great for all sorts of things. I have health insurance in case I become ill or injured. I have auto insurance that will repair or replace my vehicle if it's damaged. It also protects me in case I am involved in an accident that harms someone else. I have life insurance so that if I die, my wife and daughters are taken care of.

These are types of insurance I've chosen to have. There are other types of insurance I've also chosen not to have. For example, I've personally chosen not to have dental insurance. Most years that works out great for me. But there are some years when I have a big bill and wish I'd paid for the insurance. But, overall, I've been happy with that decision.

Similarly, every time I buy a plane ticket online there's a little checkbox asking if I want to buy travel insurance. I think it covers me in case I get sick right before a flight or something like that. I've never bought that and I've never regretted it. I've also flown over 2 million miles. So forgoing that type of insurance has also worked out well for me.

So insurance is great. I can't imagine going without my health insurance. But other types of insurance can be thought of as calculated gambles, which is exactly what they are. And sometimes those gambles pay off, sometimes they don't.

We can think of upfront thinking on development projects in the same way we think about insurance. Like insurance, upfront thinking is a way of paying a little today to avoid paying a lot tomorrow.

Upfront thinking on software projects can take a number of forms. It can be someone thinking about the architecture of the system. It could be a UI designer sketching wireframes. It could be an analyst building detailed scenarios and confirming all manner of edge cases conditions through workflows. Or it could be a database designer thinking about the structure of the database. I'm not saying any of these are bad (or that they're good). They are merely examples of upfront thinking.

Some projects will benefit from some amount of upfront thinking (although perhaps not all forms at once that I've just listed), just like many of us benefit from having some types of insurance.

How Much Upfront Thinking Is Enough?

An important consideration is how much upfront thinking is enough. The best way to determine this is, unfortunately, in hindsight. But use the level of upfront thinking you do on current projects to help you decide how much to do on future projects. Here's how ...

Suppose your team finishes a project and they never had to reverse a decision. Every decision was made perfectly the first time. I'd say that team overinvested in upfront thinking. They over insured.

Consider instead a team that finishes their project and only had to reverse one decision. But it was a major decision and caused a total re-architecting of the system. That team underinvested in upfront thinking. They underinsured.

Finally, consider a team that finishes the project and had to reverse a lot of little decisions. None caused big re-architecting, but there were a lot of little decisions that each caused rework. On their own, each is small. But added together, it was a lot. Again, here's a team that underinvested in in upfront thinking. They were under insured.

So, as projects progress, evaluate whether the team is having to occasionally backtrack on decision and architectural decisions. They should occasionally have to do so. If they never do so, they've over invested in insurance by doing too much upfront thinking. But, if they're backing up too much or in big ways, they have underinvested and should do more upfront thinking.

What Do You Think?

Use the Comments Section below to let me (and everyone else!) know how your projects are doing. Are you over- or under-investing in upfront thinking? Are there strategies you’ve found helpful for doing just enough upfront thinking?

Ethnography, Emotional Testing, Lean-UX, Enterprise BDD in Methods & Tools Fall 2015 issue

From the Editor of Methods & Tools - Tue, 09/22/2015 - 14:26
Methods & Tools ‚Äď the free e-magazine for software developers, testers and project managers ‚Äď has just published its Fall 2015 issue that discusses Ethnographic Approach to Software, Emotional Testing, Lean UX and Enterprise-Scale BDD. Article in the Fall 2015 issue of Methods & Tools: * An Ethnographic Approach to Software * Testing Your Emotions […]

Resource Efficiency vs. Flow Efficiency, Part 5: How Flow Changes Everything

The discussion to now:


When you move from resource efficiency (experts and handoffs from expert to expert) to flow efficiency (team works together to finish work), everything changes.


FlowEfficiencyThe system of work changes from the need for experts to shared expertise.

The time that people spend multitasking should decrease or go to zero because the team works together to finish features. The team will recognize when they are done—really done—with a feature. You don’t have the “It’s all done except for…” problem.

Managers don’t need to manage performance. They manage the system, the environment that makes it possible for people to perform their best. Managers help equip teams to manage their own performance.

The team is accountable, not a person. That increases the likelihood that the team will estimate well and that the team delivers what they promised.

If you are transitioning to agile, and you have not seen these things occur, perform a retrospective. Set aside at least two hours and understand your particular challenges. I like Agile Retrospectives: Making Good Teams Great, Getting Value out of Agile Retrospectives РA Toolbox of Retrospective Exercises, and The Retrospective Handbook: A Guide for Agile Teams for creating a retrospective that will work for you. You have unique challenges. Learn about them so you can address them.

I hope you enjoyed this series. Let me know if you have questions or comments.

Categories: Project Management

Resource Efficiency vs. Flow Efficiency, Part 4: Defining Accountability

This is the next in a series of posts about resource efficiency vs. flow efficiency:

Managers new to agile often ask, “How do I know people will be accountable?” Let’s tease apart the pieces of accountability:

  • Accountable to the project for finishing their own work
  • Accountable to their team for participating fully by doing their work
  • Accountable to help other people learn what they did by documenting their work
  • Accountable for meeting their estimates
  • Accountable for how the project spends money
  • … There might be more accountabilities

Let’s take¬†the first two together:

Accountable for finishing their own work and by doing their work

I suspect that managers mean, “How do I know each person does their work? How do I know they aren’t asking other people to do their work? How do I know these people are learning to do their own work?”

Those are good questions. I have yet to see a single-person feature. At the least, a developer needs someone to test their work. Yes, it’s possible to test your own work. Some of you are quite good at that, I bet.¬†Many people are not. If you want to prevent rework, build in checking in some form or another: pairing, design review, code review, unit tests, system tests, something.

So the part about “own work” seems a little micro-managing to me.

The part about doing their work is a little trickier. When people get stuck, what do they do? Often, they ask someone else for help. The help might be: talk to the duck, an explanation about what is going on in that area of the product, pairing on solving the problem, or even talking to more people.

There is no such thing as “cheating” at work. Managers are right to be concerned that people work to their capabilities. And, if those people are stuck, I don’t want them mired in the problem. We want people to learn, not be stuck.

Here’s the answer: You can’t know as a manager. You never did know as a manager.

The team knows who is hardworking and who slacks. The team knows how people are learning and if they are stuck. Even in waterfall days, the team knew. Managers may have had the illusion they knew, but they didn’t. Managers only knew what people told them.

Accountable for documentation

For me, the question is who will use the documentation? I am always amazed at how many managers want documentation other than end-user documentation and how few teams find this useful. In agile, you could make it part of the definition of done.

If people build documentation time into their estimates and the team finds the internal documentation useful, the team will pressure each person to deliver their documentation. The team knows whether the person documents their work.

Accountable for living up to estimates

When I ask managers if they want good estimates or completed features, they almost always say, “completed features.” Too often, the people multitask on fixing defects or production support work while they are supposed to work on a feature. I do understand the need for estimates, but holding people to their estimates? Sometimes, that’s about money.

Accountable for how the project spends money

Of all the accountabilities, this one makes the most sense to me. However, it doesn’t make sense in agile, where the customer/product owner is the one responsible. As long as the team completes features, the PO determines when either there is no more value in the backlog, or there is no more money for the project. With any luck, the team has met the release criteria by this time.

For me, the idea of accountability is a team-based idea, not a person-based idea. In flow efficiency, you can ask the team to be accountable for:

  • Finishing features
  • Knowing where they are with respect to the features in progress
  • Helping the PO understand the value of features and how long features will take
  • Providing an estimate, if necessary
  • If the team works in iterations, committing to work and not overcommitting to too much work

When you look at accountability like this, it looks pretty different than a single person’s accountability.

Categories: Project Management