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

Interview with Dave Gray about The Connected Company

NOOP.NL - Jurgen Appelo - Wed, 06/10/2015 - 13:55
the-connected-company

Last year, I read the book The Connected Company by Dave Gray, and I gave it five stars. As an experiment, I decided to reach out to Dave with a couple of questions, and he graciously took time to reply.

The post Interview with Dave Gray about The Connected Company appeared first on NOOP.NL.

Categories: Project Management

It’s Not What You Do. It’s What You Do Next.

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

I see too many teams and product owners obsessing over their entire product backlogs.

You do not need to have your entire your product backlog figured out.

You do not need to know what to do. You only need to know what to do next.

Do that. See how your users and customers respond. Then let their feedback guide what to do next.

Don't blindly adopt anything.

Scrum is a self-organizing team that is given a challenge and to meet that challenge works in short, time boxed iterations during which they meet daily to quickly synchronize their efforts. At the start of each iteration they meet to plan what they will accomplish. At the end they demonstrate what has been accomplished and reflect on how well they worked together to achieve it.

That's it. Anything else---release planning, burndowns, and so on is optional. Stick to the above and find the local optimizations that fit your environment. No expert knows more about your company than you do.

Software Development Linkopedia June 2015

From the Editor of Methods & Tools - Tue, 06/09/2015 - 13:27
Here is our monthly selection of knowledge on programming, software testing and project management. This month you will find some interesting information and opinions about software test automation, what is programming, model-based testing, project estimation.. or not, software architecture, agile software development and a description of how Crisp (Henrik Kniberg’s company) works and why. Web […]

Carl Sagan's BS Detector

Herding Cats - Glen Alleman - Sat, 06/06/2015 - 00:24

There are several BS detector paradigms. One of my favorites is Carl Sagan's. This one has been adapted from Reality Charting the book that goes along with the Apollo Method Root Cause Analysis process we use in our governance process in our domain. Any outage, any hard break, and disruption to the weekly release process is cause for Root Cause Analysis. 

Here's Carl's check list applied to the #NoEstimates conjecture that decisions can be made in the absence of estimates

  1. Seek independent facts. Remember, a fact is a cause supported by sensed evidence and should be independently verified by you before it can be deemed legitimate. If you cannot find sensed evidence of causal relationships you should be skeptical. 
    • Writing software for money is based on making decisions in the presence of uncertainty.
    • a primary process for making those those decisions is Microeconomics and Opportunity costs.¬†What's the lost opportunity for one decison over another?
    • To do this we need to estimate both the cost that results from choosing one decision over another and the benefits, opportunity, from that decision.
  2. Welcome open debate on all points of view. Suspend judgment about the event or claim until all cause paths have been pursued to your satisfaction using RealityCharting¬ģ.¬†
    • The notion that #NoEstimates is¬†exploring and seeking conversation is not evidenced.
    • Any challenge questions are labeled as trolling, harassing, and unwanted.
    • You'd think is #NoEstimates is the¬†next big thing responding to any and all challenges would be a terrific marketing opportunity. It's basic sales strategy, find all objections to your products vale propositon, over come them, and the¬†deal is closed.
  3. Always challenge authority. Ask to be educated. Ask the expert how they came to know what they know. If they cannot explain it to your satisfaction using evidence-based causal relationships then be very skeptical. 
    • This is not the same as¬†challenge¬†everything.
    • This is¬†when you hear¬†something¬†that is not backed b tangible evidence¬†challenge¬†it.
    • Ask the person making the claim how they know it will work outside their personal anecdotal experience?
  4. Consider more than one hypothesis. The difference between a genius and a normal person is that when asked to solve a problem the genius doesn’t look for the right answer, he or she looks for how many possible solutions he or she can find. A genius fundamentally understands that there is always another possibility, limited by our fundamental ignorance of what is really happening. 
    • The self proclaimed thought leaders,¬†agile leaders were¬†challenged, I've been¬†challenged, I must be¬†a agile though leader, needs to be tested with actual evidence.
  5. Don’t defend a position because it is yours. All ideas are prototypical because there is no way we can really know all the causes. Seek to understand before seeking to be understood. 
    • Use this on both sides of the conversation.
    • Where can non estimates be applied?
    • Where is it not¬†applicable
    • Provide evidence on both sides.
  6. Try to quantify what you think you know. Can you put numbers to it? 
    • Show the numbers
    • Do the math
  7. If there is a chain of causes presented, every link must work. Use RealityCharting¬ģ to verify that the chain of causes meets the advanced logic checks defined above and that the causes are sufficient in and of themselves.¬†
    1. If estimating is the smell of dysfunction, show the causal chain of the dysfunction.
    2. Confirm that estimating is actually the root cause of management dysfunction.
    3. Is misuse and abuse of estimates caused by the estimating process?
  8. Use Occam’s razor to decide between two hypothesis; If two explanations appear to be equally viable, choose the simpler one if you must. Nature loves simplicity.
    • When conjecturing that stopping estimates fixed the dysfunction, is this the simplist solution?
    • How about stopping Bad Management practices
    • In the upcoming #NoEstimates book, Chapter 1 opens with a blatant Bad Management process of assigning a project to an inexperienced PM that is 100's of times bigger than she has ever seen.
    • Then blaming the estimating process for her failure.
    • This notion is continued on with references to other failed projects, without ever seeking the actual root cause of the failure.
    • No evidence is ever presented to show that stopping estimates will have make the project successful.
  9. Try to prove your hypothesis wrong. Every truth is prototypical and the purpose of science is to disprove that which we think we know. 

    • This notion is lost on those conjecturing #NoEstimates is applicable their personal anecdotal experience.¬†
    • Testing the idea in external domain, not finding a CEO that supports the notion.¬†
    • The null hypothesis test H0, is basic High School statistics.¬†
    • Missing entirely there
  10.  

    Use carefully designed experiments to test all hypotheses.
    • No such thing in the #NoEstimates paradigm

So it's becoming clear #NoEstimates does pass the smell test of the basic BS meter

The Big Questions

  1. What's the answer to how can we make a decision in the presence of uncertainty and not estimate and NOT violate the core principles of Microeconomics
  2.  It's not about the developers like or dislike of estimates. When I was a developer - radar, realtime controls, flight avionics, enterprise IT - I never liked estimates. It's about business. It's not our money. This notion appears to be completely lost. It's the millennials  view of the world. We have two millennials (25 and 26) It's all about ME. Even if those suggesting are millennials, the message appears to be it's all about me. Go talk to the CFO.

The End

The rhetoric  on #NoEstimates has now reached a fever pitch, paid conferences, books, blatant misrepresentations. Time to call BS and move on. This is the last post.  I've met many interesting people in both good and bad ways. And will stay in touch. So long and thanks for the Fish. As Douglas Adams says. Those with the money will have the final say on this idea.

Categories: Project Management

Myth's Abound

Herding Cats - Glen Alleman - Thu, 06/04/2015 - 18:35

Screen Shot 2015-06-04 at 8.43.58 AMMyths, misinformation, and magic bullets abound in the software development business. No more so than in the management and estimating of complex development projects.

The Standish report is a classic example of applying How to Lie with Statistics. This book is a must read for anyone responsible for spending other peoples money.

The current misrepresentation approach is to  quote people like Bent Flyvbjerg - who by the way does superior work in the domain of mass transportation and public work. Bent, along with many others, one of which is a client, have studied the problems with Mega Projects. The classic misuse of these studies starts with the reading of the introduction of a report and going no further. Here's a typical summary.

9/10 Costs (are) underestimated. 9/10 Benefits (are) overestimated 9/10 Schedules (are) underestimated.

OK, we all know that's what the report says, now what?

  • Do you have a root cause for each of the project's overages?
  • Did those root causes have sufficient assessment to show:
    • Primary Effect ‚Äď is any effect we want to prevent.
    • Action ‚Äď momentary causes that bring condition together to cause an effect.
    • Conditions ‚Äď the fundamental causal element of all that happens. It is made up of an effect and its immediate causes that represent a single causal relationship.
      • As a minimum, the causes in this set consist of an action and one or more conditions.
      • Causal sets, like causes, cannot exist alone.
      • They are part of a continuum of causes with no beginning or end, which leads to the next principle that¬†Causes and Effects are Part of an Infinite Continuum of Causes.

NO?, then the use of reports and broad unqualified clips from reports is just Lying With Statistics.

The classic example from the same source states Steve McConnell PROVES estimates can't be done in his book. Which of course the antithesis of the title of the book and the content of the book.

This approach is pervasive in places where doing your homework appears to be a step that was skipped.

From our own research in DOD ACAT1 programs (>$5B qualifies for Megaprojects) here's the Root Cause of program problems in our domain.

Screen Shot 2015-06-04 at 9.07.45 AM

When we hear some extracted statement from a source in another domain - Bent for example is large construction infrastructure projects - roads, rail, ports - moved to our domain without the underlying details of both the data, the root causes and all the possible corrective actions to avoid the problem in the first place - that idea is basically bogus. Don't listen. Do your own investigation, learn how to not succumb to those who Lie With Statistics.

So let's look at some simple questions when we hear there are problems with our projects or projects in other domains trying to convince us it's applicable to our domain.

  • Was there a credible set of requirements that were understood by those initiating the project?
    • No? You're going to be over budget, late, and the products not likely to meet the needs of those paying.
  • Was there a credible basis of estimate for the defined work?
    • No? Then what ever estimate was produced is not going to be what the project actually costs, its duration, or the planned value.
  • Was the project defined in a Risk Adjusted manner for both reducible and irreducible uncertainties?
    • No? Then those uncertainties are still there and will cause the project to be over budget and late.
    • If the reducible risks are unaddressed, will come true with their probabilistic outcomes will drive the project over budget, late, and not provide the needed capabilities
    • If the irreducible risks don't have margin, you're late and over budget before you even start.
  • Was there a means of measuring physical percent complete in meeting the needed Effectiveness and Performance measures?
    • No? Then money will be spent and time will pass and there is no way to know if the project is actually producing value and meeting its goals.

These questions and their lack of answers are at the heart of most project performance problems. So pointing out all the problems is very easy. Providing corrective actions once the root cause is discovered is harder, mandatorily harder by the way. Because Risk Management is How Adults Manage Projects. 

First let's look at what Bent says

He states the political economy of megaprojects, that is massive investments of a billion dollars or more in infrastructure or technology, consistently ends up costing more with smaller benefits than projected and almost always end up with costs that exceed the benefits. 

So the first question is are we working in the mega project domain? No? Then can we assert Bent's assessments are applicable. If we haven't then we're Lying with Statistics. (Read Huff's book to find out why).

Flyvbjerg then explores the reasons for the poor predictions and poor performance of giant investment projects and what might be done to improve their effectiveness. Have we explored the reasons why our projects overrun? No? Then we haven't done our homework and are speculating on false data. Another How to Lie With Statistics.

Stating that projects over run 9 out of 10 times without also finding the reasons for this is the perfect How to Lie with Statistics. Make a statement, no supporting data, be the provocateur.

The End

When we read a statement without a domain or context, without a corrective action, that is intended to convey a different message, taken out of context, without the evidence it is applicable in our domain, than the person writing the original statement, is Lying with Statistics - don't listen, go find out for yourself.

Related articles

The Dysfunctional Approach to Using "5 Whys" There is No Such Thing as Free Mr. Franklin's Advice Essential Reading List for Managing Other People's Money Eyes Wide Shut - A View of No Estimates
Categories: Project Management

The Dysfunctional Approach to Using "5 Whys" - Redux

Herding Cats - Glen Alleman - Wed, 06/03/2015 - 21:54

It's been popular recently in some agile circles to mention we use the 5 whys when asking about dysfunction. This common and misguided approach assumes - wrongly - causal relationship are linear and problems come from a single source. For example:

Estimates are the smell of dysfunction. Let's ask the 5 Whys to reveal these dysfunctions

The natural tendency to assume that in asking 5 whys there is a connection from beginning to end for the thread connecting cause and effect. This single source of the problem - the symptom - is labeled the Root Cause. The question is is the root cause that actual root cause. The core problem is the 5 whys is not really seeking a solution but just eliciting more symptoms masked as causes.

A simple example illustrates the problem from Apollo Root Cause Analysis.

Say we're in the fire prevention business. If preventing fires is our goal, let's look for the causes of the fire and determine the correction actions needed to actual prevent fire from occuring. In this example let's says we've identified 3 potential causes of fire. There is ...

  1. An ignition source
  2. Combustible material
  3. Oxygen

So what is the root cause of the fire? To prevent the fire - and in the follow on example prevent a dysfunction - we must find at least one cause of the fire that can be acted on to meet the goals and objectives of preventing the fire AND are within our control.

Here's a briefing used now for our development and deployment processes in the health insurance domain

Root cause analysis master plan from Glen Alleman

The notion that Estimates are the smell of dysfunction in a software development organization and asking the 5 Whys in search for the Root Cause is equally flawed. 

The need to estimate or not estimate has not been established. It is presumed that it is the estimating process that creates the dysfunction, and then the search - through the 5 Whys - is the false attempt to categorize the root causes of this dysfunction. The supposed dysfunction is them reverse engineered to be connected to the estimating process. This is not only a na√Įve approch to solving the dysfunction is inverts the logic by ignoring the need to estimate. Without confirmation that estimates are needed ot not needed, the search for the cause of the dysfunction has no purposeful outcome.¬†

The decision that estimates are needed or not need does not belong to those being asked to produce the estimates. That decision belongs to those consuming the estimate information in the decision making process of the business - those whose money is being spent.

And of course those consuming the estimates need to confirm they are operating their decision making processes in some framework that requires estimates. It could very well be those providing the money to be spent by those providing the value don't actual need an estimate. The value at risk may be low enough - 100 hours of development for a DB upgrade. But when the value at risk is sufficiently large - and that determination of done again by those providing the money, then a legitimate need to know how much, when, and what is made by the business In this case, decisions are based on Microeconomics of opportunity cost for uncertain outcomes in the future.

This is the basis of estimating and the determination of the real root causes of the problems with estimates. Saying we're bad at estimating is NOT the root cause. And it is never the reason not to estimate. If we are bad at estimating, and if we do have confirmation and optimism biases, then fix them. Remove the impediments to produce credible estimates. Because those estimates are needed to make decisions in any non-trivial value at risk work. 

 

Related articles Let's Get The Dirt On Root Cause Analysis The Fallacy of the Planning Fallacy Mr. Franklin's Advice The Dysfunctional Approach to Using "5 Whys" Essential Reading List for Managing Other People's Money
Categories: Project Management

Using Lines of Code as a Software Size Measure - New Lecture Posted

10x Software Development - Steve McConnell - Tue, 06/02/2015 - 18:08

I've posted this week's lecture in my Understanding Software Projects series at https://cxlearn.com. Most of the lectures that have been posted are still free. Lectures posted so far include:  

0.0 Understanding Sofware Projects - Intro
     0.1 Introduction - My Background
     0.2 Reading the News

1.0 The Software Lifecycle Model - Intro
     1.1 Variations in Iteration 
     1.2 Lifecycle Model - Defect Removal

2.0 Software Size
     2.05 Size - Comments on Lines of Code (New)
     2.1 Size - Staff Sizes 
     2.2 Size - Schedule Basics 

Check out the lectures at http://cxlearn.com!

Understanding Software Projects - Steve McConnell

 

Holacracy and the Search for Agile Organization

Mike Cohn's Blog - Tue, 06/02/2015 - 15:00

I met Brian Robertson back when he was still the CEO of Ternary Software and experimenting with the ideas that have become Holacracy. You’ve probably heard of Holacracy by now. It’s a way of running organizations. But it’s a very different way of running organizations. It’s been written up in Forbes and Wired magazines. But it’s often poorly described and misunderstood. So, what better way for us to learn about it than from its primary developer, Brian Robertson, who has written this guest post for us. —Mike

Agile software development is truly a stark contrast to the machine-like predict-and-control methods of a waterfall approach. For better or worse, agile methods are also in stark contrast to the organizational leadership, management, and governance structures of modern day business, which — like waterfall approaches — rely on autocratic predict-and-control management and tend to fight change.

This clash often creates significant stress between agile teams and the rest of the organization — stress that can severely slow or even kill the shift to agile methods. For organizations that do manage to make agile stick in their software teams, interesting questions then arise like, “can we run the rest of our organization on similar principles?” and “what would it take to make our entire organization agile?”

Fortunately, there are emerging methods that do for entire organizations what agile has done for software teams. This post examines one approach, called Holacracy, which offers a complete system for achieving agility in all aspects of an organization.

While Holacracy is by no means the first attempt to take agile approaches outside of software teams, as The Economist points out, “Holacracy goes further in shaking up working practices than most [other] approaches.” Holacracy also has more traction than any other defined system: it is already being used by hundreds of companies around the world, including notable mentions like Zappos, the David Allen Company, and Medium.

Adam Pisoni, co-founder of Yammer, adds: “Just like agile development systems break work into sprints, Holacracy forces a company to revisit its rules, roles, objectives and authorities in short cycles. This prevents you from over-planning upfront. It also gives you the chance to re-evaluate your plans, direction and beliefs on a regular, frequent basis.”

So, what is Holacracy? Essentially, it’s a new way of running an organisation that removes power from a management hierarchy and distributes it across clear roles, which can then be executed autonomously, without a micromanaging boss. More specifically, Holacracy differs from the traditional management model in four ways:

  1. No more job descriptions
    In most companies each person has a single job description that is often imprecise, outdated and irrelevant to their day-to-day work. In Holacracy, people have multiple roles, often on different teams, and those role descriptions are constantly updated by the team actually doing the work. This allows people working in a Holacracy-powered company a lot more freedom to express their creative talents. It also means that the company can take advantage of those skills in a way it couldn’t before.

    Ev Williams, cofounder of Blogger, Twitter and Medium, puts it this way: “In the past, as my companies have grown, I’ve hired these amazing people, and I’ve felt like I was getting less and less of them as the company got bigger. Part of that was because they were in a particular area, and if they had ideas or concerns or perspectives that were relevant outside that area, it wasn’t clear what to do with them. Holacracy provides a very specific way where people are actually encouraged to bring this stuff up. You really take advantage of everybody’s perspectives and ideas.”

  2. No more delegated authority
    The agility that Holacracy provides comes directly from truly distributed authority. In traditional organisations, managers loosely delegate authority, but ultimately their decisions always trump those they manage and everybody knows it.

    In Holacracy, authority is truly distributed and decisions are made locally, by the individual closest to the front line. Teams are self-organised: they’re given a purpose, but they decide internally how to best reach it. In this way, Holacracy replaces the traditional hierarchy with a series of interconnected but autonomous teams (“circles” in Holacracy’s vernacular). And once a circle has distributed some responsibility or authority to one of its roles, whoever fills that role has a whole lot of power in that area -- power no one else can trump.

    This is very different than in most companies, where only the management has the kind of authority needed to make important decisions. In practice, this means that everyone in the company is asked to take the reins and become a leader of their roles, and, conversely, a follower of others’ roles.

  3. No more big re-orgs
    In traditional companies, the organisation chart gets revamped every few years. These cyclical ‘re-orgs’ are an attempt to keep up with the changing environment, but since they only occur every three to five years, they are almost always out of date. In Holacracy, the structure of the organisation is updated every month in every circle.

    Yammer co-founder Adam Pisoni says it this way, “Most startups believe in iteration of their products. Now they need to apply the same thinking to their organisations.” Holacracy is precisely this type of solution: a rapid and agile approach to organisational development, rather than the industrial-age approach of predict, plan, and then cross your fingers and hope that you’ve made the right prediction.

    With Holacracy, the definitions of the roles and the circles are not prescribed in advance, nor are they rigidly defined. Instead, Holacracy allows a company to evolve whatever organisational structure is most suited to its current environment. In this way, Holacracy doesn’t just help organisations become evolved – it helps them become evolutionary.

  4. No more office politics
    In most companies, things are done a certain way because “that’s how we’ve always done it”, and those implicit rules are hard to change. Often no one knows why those rules exist, who decided them, or who can change them. This makes distributing authority almost impossible, because there is no way to ensure that everyone is following the same set of rules. The traditional management hierarchy is based mostly on ‘people who get it’ promoting other ‘people who get it.’

In Holacracy, distributing authority is not just a matter of taking power out of the hands of a leader and giving it to someone else or even to a group. Rather, the seat of power shifts from the person at the top to an explicit process, which is defined in detail in a written document (called the Holacracy ‘constitution’). In fact, when an organisation adopts Holacracy, the very first step is having the CEO or current power-holder formally cede his or her power into its rule system, meaning that they are subject to the same rules as everyone else.

This shift from personal leadership to constitutionally derived power is central to Holacracy’s new paradigm. The transparency of the rules means that you no longer have to depend on office politics to get things done.

Conclusion: a better way of working?
Companies designed in the 20th century have very little capacity to evolve and adapt. They are subject to evolution’s process at the market level and may survive or die as a result, but they are rarely adaptive organisms themselves, at least on more than a superficial level.

“The key to doing better,” argues Oxford economist Eric Beinhocker,“is to ‘bring evolution inside’ and get the wheels of differentiation, selection, and amplification spinning within a company’s four walls.” Holacracy offers the possibility of doing just that: embedding an enhanced capacity to dynamically and continually evolve, within an organisation’s core DNA.

It helps create organisations that are fast, agile and succeed by pursuing their purpose, free from the tyranny of top-down planning or the time-consuming pursuit of consensus.

It’s not a silver bullet – it takes hard work and practice to make the shift into such a dramatically different way of organising, but those who see and experience it in action are excited about its results. In the words of David Allen, author of "Getting Things Done" and a business leader with years of Holacracy experience in his own company, “Holacracy is not a panacea – it won’t resolve all of an organisation’s tensions and dilemmas. But, in my experience, it does provide the most stable ground from which to recognise, frame, and address them.”

Pre-order Brian’s book, "Holacracy: The New Management System for a Rapidly Changing World" (released June 2nd) here: http://holacracybook.com/

You can also read the first chapter here:
http://holacracy.org/sites/default/files/images/holacracybook-ch1.pdf

Share your thoughts, reactions, and questions about Holacracy in the comments section of the blog. We'll choose two commentators at random and send them a free copy of Holacracy.

From Software Delivery to Software Creativity

From the Editor of Methods & Tools - Tue, 06/02/2015 - 13:04
This editorial was inspired by a quote from Mary and Tom Poppendieck’s book “Lean Mindset“. They wrote “What‚Äôs next is to stop thinking about software development as a delivery process and to start thinking of it as a problem-solving process, a creative process.” In many large companies, software development has often been traditionally considered as […]

Software Development Conferences Forecast May 2015

From the Editor of Methods & Tools - Fri, 05/29/2015 - 15:05
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 & […]

Team Sizes and Schedule Basics - New Lectures Posted

10x Software Development - Steve McConnell - Thu, 05/28/2015 - 19:19

I've posted this week's lecture in my Understanding Software Projects series at https://cxlearn.com. Most of the lectures that have been posted are still free. Lectures posted so far include:  

0.0 Understanding Sofware Projects - Intro

0.1 Introduction - My Background
     0.2 Reading the News

1.0 The Software Lifecycle Model - Intro
     1.1 Variations in Iteration 
     1.2 Lifecycle Model - Defect Removal

2.0 Software Size
     2.1 Size - Staff Sizes (New this week)
     2.2 Size - Schedule Basics (New this week)

Check out the lectures at http://cxlearn.com!

Understanding Software Projects - Steve McConnell

 

The Crater of Unhappiness

NOOP.NL - Jurgen Appelo - Wed, 05/27/2015 - 10:52
meteor-crater

Many years ago, during a trip through the USA, a friend and I visited Meteor Crater, a giant crater left behind by a meteorite. At the bottom of the crater, there are some remains of a small airplane. We were told that, many years ago, the plane had unintentionally flown into the space contained within the crater, and was then unable to get out.

The post The Crater of Unhappiness appeared first on NOOP.NL.

Categories: Project Management

Who's Budget is it Anyway?

Herding Cats - Glen Alleman - Wed, 05/27/2015 - 05:30

When we hear things like ...

Why promising nothing delivers more and planning always fails,
or
 It's in doing the work that we discover the work that we must do,
or
 If estimates were real the team wouldn't have to know the delivery date, they just work naturally and be on date.

You have to ask do these posters have any understanding that it's not their money? That all project work is probabilistic. That nonlinear, non-stationary, stochastic processes drive  uncertainty for all work in ways that cannot be controlled by disaggregating the work (slicing), or assuming that work elements are independent from other work elements in all but the most trivial of project context.

Systems Thinking and Probability†

All systems where optimum technical performance is needed require a negative feedback loop as the basis for controlling the work in order to arrive on the planned date, with the planned capabilities, for the planned budget. If there is no need to arrive as planned or as needed, then no control system is needed, just spend until told to stop.

The negative feedback loop as a control system, is the opposite of the positive feedback loop. In chemistry a positive feedback loop is best referred to as an explosion. In project management a positive feedback loop results in a project that requires greater commitment of resources to produce the needed capabilities beyond what was anticipated. That is cost and schedule overrun and lower probability of technical success.

A project is a type of complex adaptive system that acquires information about its environment and the interactions between the project elements, identifies information of importance, and places that information within a context, model, or schema, and then acts on this information to make decisions.

The individual members of the project act as a complex adaptive system themselves and exert influence on the selection of both the schema and the adaptive forces used to make decisions. The extent to which learning produces adaptive or maladaptive behavior determines the survival of failure of the project and the organization producing the value from the project.

Managing in the Presence of Uncertainty

Uncertainty creates risk. Reducible risk and irreducible risk. This risk by its nature is probabilistic. Complex systems tend to organize themselves in a normal distribution of outcomes ONLY if each individual element of the system is Independent and Identically distributed. If this is not the case, long tailed distributions result and are the source of Black Swans. And these Black Swans are unanticipated cost and schedule performance problems and technical failures we are familiar with in the literature. The project explodes. 

Screen Shot 2015-05-26 at 11.08.07 PM

So We Arrive at the End

To manage in the presence of an uncertain future for cost, delivery date, and delivered capabilities to produce the value in exchange for the cost, we need some mechanism to inform our decision making process based on these random variables. The random variables that create risk. Risk that must be reduced to increase the probability of success. The reducible risk and the irreducible risk.

This mechanism is the ability to estimate to impact of any decision while making the trade off between decision alternatives - this is the basis of Microeconomics - the tradeoff of a decision based on the opportunity cost of the collection of decision alternatives.

Anyone conjecturing that decisions can be made in the presence of uncertainty without making  estimated impacts of those decisions has willfully ignored the foundational principles  of  Microeconomics.

The only possible way to make decisions in the absence of estimating the impact of a decision is when the decision has a trivial value at risk. Many decisions are just that. If I decide wrong the outcome has little or no impact on cost, schedule, or needed technical performance. In this case Not Estimating is a viable option. For all other conditions, Not Estimates results in a Black Swan explosion of the customers budget, time line, and expected beneficial outcomes based on the produced value.

† Technical Performance Measurement, Earned Value, and Risk Management: An Integrated Diagnostic Tool for Program Management, Commander N. D. Pisano, SC, USN, Program Executive Officer Air NSW, Assault and Special Missions Programs (PEO(A)). Nick is a colleague. This paper is from 1991 defining how to plan and assess performance for complex, emergent systems. 

Related articles Just Because You Say Words, It Doesn't Make Then True There is No Such Thing as Free Essential Reading List for Managing Other People's Money The Dysfunctional Approach to Using "5 Whys" Mr. Franklin's Advice
Categories: Project Management

Staying Ahead of the Curve

From the Editor of Methods & Tools - Tue, 05/26/2015 - 15:45
We all want to stay ahead of the curve – after all, that’s what you go to a conference for. But have you ever considered how being ahead of the curve might be dangerous? Using a new language before you understand it, putting a technology into production so you can learn it, abandoning “old practices” […]

Product Backlog Refinement (Grooming)

Mike Cohn's Blog - Tue, 05/26/2015 - 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.

Product backlog refinement—sometimes called product backlog grooming in reference to keeping the backlog clean and orderly—is a meeting that is held near the end of one sprint to ensure the backlog is ready for the next sprint.

During a product backlog refinement meeting, the team and product owner discuss the top items on the product backlog. The team is given a chance to ask the questions that would normally arise during sprint planning:

  • What should we do if the user enters invalid data here?
  • Are all users allowed to access this part of the system?
  • What happens if…?

By asking these questions earlier, the product owner is given a chance to arrive at answers to any questions he or she may not be prepared to answer immediately.

If those questions were asked for the first time in sprint planning, and too many could not be answered, it might be necessary to put a high-priority product backlog item aside and not work on it during the sprint.

These questions do not need to be fully resolved in a backlog refinement meeting. Rather, the product owner needs only to address them just enough so that the team feels confident that the story can be adequately discussed during the coming planning meeting.

Backlog refinement in that sense is really a checkpoint rather than an effort to fully resolve issues.

I like to hold the product backlog refinement meetings three days before the end of the current sprint. This gives the product owner sufficient time to act on any issues that are identified. Some teams find that doing shorter meetings every week rather than once per sprint are more suited to their cadence, and that is, of course, fine.

Unlike other Scrum meetings, I do not think the product backlog refinement meeting requires the participation of the whole team.

If you think about a whole team meeting three days before the end of the sprint, there is likely to be someone who will be frantically busy—someone who, if forced to attend one more meeting, may have to work late to finish the work of the sprint.

I’d prefer to conduct the meeting without such team members. As long as the same team members don’t miss the meeting each sprint, I think it’s fine to conduct backlog refinement meetings with about half the team plus the product owner and ScrumMaster.

Early Release of Agile and Lean Program Management Available

 Scaling Collaboration Across the OrganizationI have finished integrating comments from the early review of Agile and Lean Program Management: Scaling Collaboration Across the Organization. I decided that the book was good enough to release to the general public.

I find it difficult to release books in progress. The in-progress part challenges my perfection rules. I also know that some of you who want this book will wait until it’s done, or worse, available in paper.

However, since this is an agile and lean book, it seems nuts to not release it, even though it is not quite done.

If you get the book, please send me comments about what confused you, what you thought was crazy, and anything else.

Thanks so much!

 

Categories: Project Management

Memorial Day

Herding Cats - Glen Alleman - Sun, 05/24/2015 - 19:27

Memorial-dayIn case you thought it was about the 3 day weekend, parties, and the beach

Thanks to all my neighbors, friends, and colleagues for their service.

Categories: Project Management

Software for the Mind

Herding Cats - Glen Alleman - Fri, 05/22/2015 - 00:21

The book Software for Your Head was a seminal work when we were setting up our Program Management Office in 2002 for a mega-project to remove nuclear waste from a very contaminated site in Golden Colorado.

Here's an adaptation of those ideas to the specifics of our domain and problems

Software for your mind from Glen Alleman This approach was a subset of a much larger approach to managing in the presence of uncertainty, very high risk, and even higher rewards, all on a deadline, and fixed budget.  As was stated in the Plan of the Week.
  • Monday - Where are we going this week?¬†
  • Daily - What are we doing along the way?
  • Friday - Where have we come to?

Do this every week, guided by the 3 year master plan and make sure no one is injured or killed.

That project is documented in the book Making the Impossible Possible summarized here.

Making the impossible possible from Glen Alleman Related articles The Reason We Plan, Schedule, Measure, and Correct The Flaw of Empirical Data Used to Make Decisions About the Future There is No Such Thing as Free
Categories: Project Management

We've Been Doing This for 20 Years ...

Herding Cats - Glen Alleman - Thu, 05/21/2015 - 03:58

We've been doing this for 20 years and therefore you can as well

Is a common phrase used when asked in what domain does you approach work? Of course without a test of that idea outside the domain in which the anecdotal example is used, it's going to be hard to know if that idea is actually credible beyond those examples.

So if we hear we've been successful in our domain doing something or better yet NOT doing something, like say NOT estimating, ask in what domain have you been successful? Then the critical question, is there any evidence that the success in that domain is transferable to another domain? This briefing provides a framework - from my domain of aircraft development - illustrating that domains vary widely in their needs, constraints, governance processes and applicable and effective approaches to delivering value.

Paradigm of agile project management from Glen Alleman Google seems to have forgotten how to advance the slides on the Mac. So click on the presentation title (paradigm of agile PM)  to do that. Safari works. Related articles The Reason We Plan, Schedule, Measure, and Correct The Flaw of Empirical Data Used to Make Decisions About the Future There is No Such Thing as Free Root Cause Analysis Domain is King, No Domain Defined, No Way To Test Your Idea Mr. Franklin's Advice
Categories: Project Management

Software Development Linkopedia May 2015

From the Editor of Methods & Tools - Wed, 05/20/2015 - 15:24
Here is our monthly selection of knowledge on programming, software testing and project management. This month you will find some interesting information and opinions about Agile software development, giving feedback, managing technical debt, normalizing user stories, dependency injection, developer griefs, behavior driven development (BDD) and software architecture. Web site: The GROWS Method Blog: The Failure […]