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

How To Make Decisions

Herding Cats - Glen Alleman - Wed, 07/30/2014 - 12:38

Decisions are about making Trade Offs for the project. These decisions are about:

  • Evaluating alternatives.
  • Integrating and balancing all the considerations (cost, performance, Producibility, testability, supportability, etc.).
  • Developing and refining the requirements, concepts, capabilities of the product or services produced by the project or product development process.
  • Making trade studies and the resulting trade offs that enables the selection of the best or most balanced solution to fulfill the business need or accomplishment of the mission.

The purpose of this decision making process is to:

  • Identify the trade-offs ‚Äď the decisions to be made ‚Äď among requirements, design, schedule, and cost.
  • Establish the level of assessment commensurate with cost, schedule, performance, and risk impact based on the value at risk for the decision.
    • Low value at risk, low impact, simple decision making ‚Äď possibly even gut feel.
    • High value at risk, high impact, the decision-making process must take into account these impacts.

Trade-offs are essential to strategy. They create the need for choice and purposefully limit what a company offers.

It is only by assessing the impacts of these tradeoffs can the products or solutions of the projects be guided. Otherwise, just producing the requirements has no real purpose - no strategic purpose connected to the needed capabilities. ‡

Making decisions about capabilities and resulting requirements is the starting point for discovering what DONE looks like, by:

  • Establishing alternatives for the needed performance and functional requirements.
  • Resolving conflicts between these requirements in terms of the product‚Äôs delivered capabilities.

Decisions about the functional behaviours and their options is next. These decisions:

  • Determine preferred set of requirements for the needed capabilities. This of course is an evolutionary process as requirements emerge, working products are put to use, and feedback is obtained.
  • Determine the customer assesses requirements for lower-level functions as each of the higher-level capabilities are assessed.
  • Evaluate alternatives to each requirement, each capability, and the assessed value of each capability ‚Äď in units of measure meaningful to the decision makers.

Then comes the assessment the cost effectiveness of each decision:

  • Develop the Measures of Effectiveness (MOE) and Measures of Performance (MOP) for each decision.
  • Identify the critical Measures of Effectiveness of each decision in fulfilling the project‚Äôs business goal or mission. These Technical Performance Measures are used to assess the impact of each decision on the produced value of the project.

Each of these steps is reflected in the next diagram.

Screen Shot 2014-07-28 at 8.08.44 AM

Value of This Approach

When we hear that estimates are not needed to make decisions, we need to ask how the following questions can be answered:

  • How can we have a systematized thought process, where the decisions are based on measureable impacts?
  • How can we clarify our options, problem structure, and available trade-offs using units of measure meaningful to the decision makers?
  • How can we improve communication of ideas and professional judgment within our organization through a shared exchange of the impacts of our decisions?
  • How can we improve communication of rationale for each decision to others outside the organization?
  • How can we be assured of our confidence that all available information has been accounted for in a decision?

The decision making process is guided by the identification of alternatives

Decision-making is about deciding between alternatives. These alternatives need to be identified, assessed, and analyzed for their impact on the probability of success of the project.

These impacts include, but are not limited to:

  • Performance
  • Schedule
  • Cost
  • Risk
  • Affordability
  • Producibility
  • And all the other ‚Ķilities associated with the outcomes of the project

The effectiveness of our decision making follows the diagram below:

  Screen Shot 2014-07-28 at 8.05.58 AM

In the End - Have all the Alternatives Been Considered?

Until there is a replacement for the principles of Microeconomics, for each decision made on the project, we will need to know the impact on cost, schedule, technical parameters, and other attributes of that decision. To not know those impacts literally violates the principles of microeconomics and the governance framework of all business processes, where the value at risk is non-trivial.

As Shim says think about it. 

Screen Shot 2014-07-28 at 12.26.24 PM

When you hear planning ahead, by assessing our altenatives is overrated, think again.

‡ What is Strategy? , M. E. Porter, Harvard Business Review, Volume 74, Number 6, pp. 61-68.

Connecting IT and Business Strategy, Glen B. Alleman, 5/12/2007

† Derived from Module J: Trade Study Process, Systems Engineering, Boeing.

Related articles Agile Project Management Concept of Operations First, then Capabilities, then Requirements The Value of Information Critical Thinking Skills Needed for Any Change To Be Effective Why Project Management is a Control System
Categories: Project Management

Fit for Purpose, Fit for Use

Herding Cats - Glen Alleman - Tue, 07/29/2014 - 23:50

The notion of Fit for Use and Fit for Purpose can be applied in many ways, much in the same way as Measures of Effectiveness and Measures of Performance and Verification and Validation. 

  • Fit to purpose - describes a Process, Configuration Item, IT Service, etc., that is capable of meeting its business, technical, or operational Objectives or Service Levels. Being Fit for Purpose requires suitable Design, implementation, Control, and maintenance.
    .
  • Fit for use - the effectiveness of a design, development method, and support process employed in delivering a good, system, or service that fits a customer's defined purpose, under anticipated or specified operational conditions.¬†In our project and program management world, we can apply these assessment to all elements of the project. The needed capabilities -¬†are they fit of purpose and fit for use. Can each outcome be assessed by its¬†Effectiveness¬†and¬†Performance. Can we¬†validate¬†and¬†verify¬†the resulting products or services?

Each of these assessments can be applied to the 5 Immutable Principles of project success.

  • When we reach¬†Done is this¬†Done Fit for Purpose and Fit for Use, is it Effective in accomplishing the mission of fulfilling the business can. Can this be verified and validated?
  • If we have a path to reach¬†Done, can this path be verified as one that will actually allow us to reach¬†Done.

5 Immutable Principles

 

So Now the Hard Part

Assessing the Fit for Purpose and Fit for Use can't wait till we're done with the project. It's too late then. We've spent all the money and time. The customer is expecting that we're Done and have meet all the requirements that enable all the capabilities to be Effective (Measures of Effectiveness) at their needed Performance (Measures of Performance).

This is why it is nonsense to not be able to estimate the outcome of any decision on the project before that decision is implemented. Unless of course, you on a co-hacking project (as defined by Guy Strelitz), where the project is...

  • Intimate communication
  • Shared commitment
  • Inexpensive
  • Unconstrained
  • Uncontrolled

So let's look at the answers to the questions possed by the 5 Immutable Principles:

  1. Do we know where you are going by defining ‚Äúdone‚ÄĚ at some point in the future. This may be far in the future ‚Äď months or years from now. Or closer in the future days or weeks from now?
  2. Do we have some kind of plan to get to where you are going. This plan can be simple or it can be complex. The fidelity of the plan depends on the tolerance for risk by the users of the plan. The plan answers the question how long are we willing to wait before we find out we are late?
  3. Do we understand the resources needed to execute the plan. How much time and money is needed to reach the destination. This can be fixed or it can be variable?
  4. Can we identify the impediments to progress along the way to the destination. Have some means of removing, avoiding, or ignoring these impediments?
  5. Do we have some way to measure your planned progress, not just your progress. Progress to Plan must be measured in units of physical percent complete?

So What Does All This Mean?

Assessing the future values for Fit for Purpose and Fit for Use is part of the control systems of successful project management. Without the ability to estimate the cost, schedule, and performance - the fit for use and purpose values - the project has no way of knowing it will be successful. No way of knowing it will reach Done as needed, as well as as planned.

Ignoring this need to know about the future, means the project will be done when it runs out of money and time, or gets canceled by those providing the funding. The notion that features can be delivered every week or every day and the project can stop at any time and provide value to the customer is a wonderful idea - for CoHacking projects.

For other projects, defined in Guy's very nice article, some sense of what Done looks like in terms of cost, schedule, and the probability that the needed capabilities can be delivered for that cost on that schedule, will be needed.

Related articles Back To The Future How Not To Develop What "Done" Look Like The Calculus of Writing Software for Money 5 Immutable Project Success Processes (Again) Control Systems - Their Misuse and Abuse How to Deal With Complexity In Software Projects? It Can't Be Any Clearer Than This Don't Do Stupid Things On Purpose Seven Immutable Activities of Project Success
Categories: Project Management

Quote of the Day

Herding Cats - Glen Alleman - Tue, 07/29/2014 - 17:37

"Great minds discuss ideas; average minds discuss events; small minds discuss people."  - Eleanor Roosevelt 

Categories: Project Management

Ray Bradbury on the Benefits of Short Releases

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

In 2001, author Ray Bradbury gave a talk at the annual Writer’s Symposium by the Sea in San Diego. Fortunately for those of us who were not there, his speech was video recorded and is available.

Bradbury—the author of books such as Fahrenheit 451, The Martian Chronicles, Something Wicked This Way Comes—was offering advice to an audience mostly of aspiring writers. But I watched his speech recently and was struck by the appropriateness of Bradbury’s advice to those of us on agile project.

Early in his talk, Bradbury recommends that aspiring writers write short stories rather than novels. He says that writing a novel at the start of one’s career is a mistake because “you could spend a whole year writing one, and it might not turn out well because you haven’t learned to write yet.”

Bradbury advises instead writing “a hell of a lot of short stories,” suggesting writing one per week. He says “at the end of a year, you have 52 short stories, and I defy you to write 52 bad ones.”

It “can’t be done,” Bradbury jokes, saying that with that much practice, the aspiring writer will eventually come up with something good.

So I’ll go along with Bradbury, but instead of writing short stories, let’s put out new features. Let’s give our customers one release per week for the next year. And, like Bradbury, I defy you to put out 52 bad releases.

Sure, some of your releases will have things your users don’t want. You thought your users would want them, some minimal amount of research may have shown they would, but when you put that release out, you found out otherwise. What you can’t do, though, is put out 52 releases and fail to learn from them.

Like Bradbury’s aspiring writers, you’ll learn more about your customers, your product, and your team. And, like Ray Bradbury, that will help you find your bestseller.

Even if you don’t have time to listen to Bradbury’s full speech (it’s 54 minutes), listen to the first 6 minutes. He makes at least one other point very relevant to the short iterations of agile. If you listen, let me know in the comments below, what else you heard that’s relevant to agile.

Ray Bradbury on the Benefits of Short Releases

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

In 2001, author Ray Bradbury gave a talk at the annual Writer’s Symposium by the Sea in San Diego. Fortunately for those of us who were not there, his speech was video recorded and is available.

Bradbury—the author of books such as Fahrenheit 451, The Martian Chronicles, Something Wicked This Way Comes—was offering advice to an audience mostly of aspiring writers. But I watched his speech recently and was struck by the appropriateness of Bradbury’s advice to those of us on agile project.

Early in his talk, Bradbury recommends that aspiring writers write short stories rather than novels. He says that writing a novel at the start of one’s career is a mistake because “you could spend a whole year writing one, and it might not turn out well because you haven’t learned to write yet.”

Bradbury advises instead writing “a hell of a lot of short stories,” suggesting writing one per week. He says “at the end of a year, you have 52 short stories, and I defy you to write 52 bad ones.”

It “can’t be done,” Bradbury jokes, saying that with that much practice, the aspiring writer will eventually come up with something good.

So I’ll go along with Bradbury, but instead of writing short stories, let’s put out new features. Let’s give our customers one release per week for the next year. And, like Bradbury, I defy you to put out 52 bad releases.

Sure, some of your releases will have things your users don’t want. You thought your users would want them, some minimal amount of research may have shown they would, but when you put that release out, you found out otherwise. What you can’t do, though, is put out 52 releases and fail to learn from them.

Like Bradbury’s aspiring writers, you’ll learn more about your customers, your product, and your team. And, like Ray Bradbury, that will help you find your bestseller.

Even if you don’t have time to listen to Bradbury’s full speech (it’s 54 minutes), listen to the first 6 minutes. He makes at least one other point very relevant to the short iterations of agile. If you listen, let me know in the comments below, what else you heard that’s relevant to agile.

Certificates, Yes and No

NOOP.NL - Jurgen Appelo - Mon, 07/28/2014 - 15:30
certificate color

It seems that the debate around certificates will never end.

Some people and organizations ask me to provide official certificates for participants of Management 3.0 events. What we offer now is a simple “Certificate of Attendance”. It only says that we confirm that a person participated in the event, and that he or she was physically present in the room. That’s all. We cannot certify knowledge or understanding, because I don’t know of any “tests” to validate that a person understands and is able to apply Management 3.0 principles and practices.

The post Certificates, Yes and No appeared first on NOOP.NL.

Categories: Project Management

Software Development Conferences Forecast July 2014

From the Editor of Methods & Tools - Mon, 07/28/2014 - 08:39
Here is a list of software development related conferences and events on Agile ( Scrum, Lean, Kanban) software testing and software quality, programming (Java, .NET, JavaScript, Ruby, Python, PHP) and databases (NoSQL, MySQL, etc.) that will take place in the coming weeks and that have media partnerships with the Methods & Tools software development magazine. Agile on the Beach, September 4-5 2014, Falmouth in Cornwall, UK SPTechCon, September 16-19 2014, Boston, USA Future of Web Apps, September 29-October 1 2014, London, UK STARWEST, October 12-17 2014, Anaheim, USA JAX London, October 13-15 2014, ...

Quote of Day

Herding Cats - Glen Alleman - Sun, 07/27/2014 - 15:09

"in order to reason well ... it is absolutely necessary to possess ... such virtues as intellectual honesty and sincerity and a real love of the truth." ‚ÄĒ C. S. Pierce

Categories: Project Management

Why Project Management is a Control System

Herding Cats - Glen Alleman - Fri, 07/25/2014 - 21:48

When it is mentioned project management is a control system many in the agile world whince. But in fact project is a control system, a closed loop control system.

Here's how it works.

  • We have a goal, a target, some desired outcome.
  • The desired outcome usually comes with a budget - some expected cost.
  • It also comes with a time frame for achieving that desired outcome.
  • That outcome usually - or should if we're doing it right - has a beneficial outcome.

Each of these elements has some unit of measure:

  • Time - the day we need to deliver value or aa capability to meet the business goals or accomplish a mission. There can of course be incremental delievrables, but those also have a time element.
  • Outcome might be he accomplishments of a mission or fulfillment of the business strategy
  • Cost - there is no way to determine the value of anything without knowing its cost. This is the foundation of microeconomics. This can only happen - not knowing cost - by intentionally ignoring the principles of micro-economics. It's done I know, but Don't Do Stupid Things On Purpose.

Here's a small example of incremental delivery of value in an enterprise domain

Project Maturity Flow is the Incremental Delivery of Business Value

The accomplishment of a mission or fulfillment of a business strategy can be called the value produced by the project. In the picture above the value delivered to the business is incremental, but fully functional on delivery to accomplish the business goal. These goals are defined in Measures of Effectiveness and Measures of Performance and these measures are derived from the business strategy or mission statement. So if I want a fleet of cars for my taxi service, producing a sketboard, then a bicycle, is not likley to accomplishment the business goal.

But the term value alone is nice, but not sufficient. Value needs to have some unit of measure. Revenue, cost reduction, environmental cleanup, education of students, reduction of disease, the process of sales orders at a lower cost, flying the 747 to it's destination with minimal fuel. Something that can be assessed in tangible units of measure.

In exchange for this value, with it's units of measure, we have the cost of producing this value.

To assess the value or the cost, we need to know the other item. We can't know the value of something without knowing its cost. We can't know if the cost is appropriate without knowing the value produced by the cost.

This is one principle of Microeconomics of software development

The process of deciding between choices about cost and value - the trade space between cost and value - starts with information about both cost and value. This information lives in the realm of uncertainty before and during the project's life-cycle. It is only known on the cost side after the project completes. And for the value may never be known in the absence of some uncertainty as to the actual measure. This is also a principle of microeconomics - the measures we use to make decisions are random variables.

To determine the value of the random variable we need to estimate, since of course they are random. With these random variables - cost of producing value and the value exchanged for the cost, the next step in projects is to define what we want the project to do:

  • The desired outcome in the form of capabilities.
  • The desired cost for the desired value.
  • The desired time for the delivery of that desired value for the desired cost.
  • The confidence that we can show up on or before the desired time, at or below the desied cost to delivery the desired value, and deliver the needed capabilities to fulfill the mission.

The actual delivery of this value can be incremental, it can be iterative, evolutionary, linear, big bang, or other ways. Software many times can be iterative or incremental, pouring concrete and welding pipe can as well. Building the Interstate might be incremental, the high rise usually needs to wait for the occupancy permit before the value is delivered to the owners. There is no single approach.

For each of these a control system is needed to assure progress to plan is being made. The two types of control systems are Open Loop and Close Loop. The briefing below speaks to those and their use.

So In The End When we hear about a control loop applied to project management, we'll now know about Open and Closed Loop control. And that there can't be a Closed Loop control process without.
  • A desired outcome - the target budget, date, or some performance parameter.
  • Measures of progress to plan - what has the project been doing to date? This should be measured in units of¬†physical percent complete. Working software is a popular platitude in the agile community. But is it the right working software to fulfill the needed capabilities developed through a¬†Capabilities Based Planning process.
  • Variances between actual and plan - with the target outcomes, capture actuals and calculate variances. These variances are the information needed to make business decisions.
    • These decisions are based not only past performance - the actual's - but future performance - the estimates of future performance given the past performance.
    • This future performance must also be risk adjusted.
    • Both the future performance and the uncertainties that create risks to this performance are statistical processes, producing probabilistic outcomes, that are integrated into the decision making processes.
  • Take Corrective Actions - to keep the project¬†inside the white lines. Using the past performance or cost, schedule, and technical outcomes, the assessment of variances, the role of management is to take corrective action to meet the desired outcomes of the project.
    • The cost goals - we have a target budget that is used for assesing the Return on Investment or target product margin.
    • The schedule goals - we have planned¬†go live or¬†release date¬†that been communicated to the market or the customer.
    • The Needed Capabilities - for the product (internal or external) to¬†earn its keep.¬†
    • Adjustments¬†- to each of these attributes required management action, assessment of this action to actually¬†get back to GREEN, in our parlance, and keep the project headed to success.
  • Monitor these actions against plan - once corrections are taken, management must still monitor the project to assure it¬†stays on plan.
Related articles Elements of Project Success The Value of Information Control Systems - Their Misuse and Abuse Four Critical Elements of Project Success Critical Thinking Skills Needed for Any Change To Be Effective Seven Immutable Activities of Project Success How Not To Make Decisions Using Bad Estimates Why is Statistical Thinking Hard?
Categories: Project Management

Quote of the Month July 2014

From the Editor of Methods & Tools - Fri, 07/25/2014 - 08:22
Research has shown that the presumption of selfishness is true for maybe 30% of most populations; another 50% are reliably unselfish, and the remaining 20% could go either way, depending on the context. If a company presumes that the undecided 20% are selfish, you can bet they will be selfish‚ÄĒit‚Äôs a self-fulfilling prophecy. But worse, the company will create an environment where the 50% of the people who are unselfish are forced to act selfishly. And losing the energy, commitment, and intelligence of half the workforce is perhaps the biggest ...

Purpose, Not Discipline

NOOP.NL - Jurgen Appelo - Thu, 07/24/2014 - 16:06
Purpose, Not Discipline

I tried running a few years ago, but I stopped because of shin splints and impossible work schedules.

I tried a fitness school, for several months, but I hated all the machines and uninteresting equipment.

I tried Pilates exercises, for a few days, but I found the exercises on a mat mind-numbingly boring.

I tried swimming, for a week or two, but the pool was always crowded and it was far away from my home.

I tried body-weight exercises, for exactly two days, but I found them too hard, which didn’t really motivate me.

And I tried yoga, for less than a week, but it was as least as boring as the Pilates exercises.

The post Purpose, Not Discipline appeared first on NOOP.NL.

Categories: Project Management

How Not To Make Decisions Using Bad Estimates

Herding Cats - Glen Alleman - Thu, 07/24/2014 - 04:54

The presentation Dealing with Estimation, Uncertainty, Risk, and Commitment: An Outside-In Look at Agility and Risk Management has become a popular message for those suggesting we can make decisions about software development in the absence of estimates.

The core issue starts with first chart. It shows the actual completion of a self-selected set of projects versus the ideal estimate. This chart is now in use for the #NoEstimates paradigm as to why estimating is flawed and should be eliminated. How to eliminate estimates while making decisions about spending other peoples money is not actually clear. You'll have to pay ‚ā¨1,300 to find out.¬†

But let's look at this first chart. It shows the self-selected projects, the vast majority completed above the initial estimate. What is this initial estimate? In the original paper, the initial estimate appears to be the estimate made by someone for how long the project would take. No sure how that estimate was arrived at - the basis of estimate - or how was the estimate was derived. We all know that subject matter expertise is the least desired and past performance, calibrated for all the variables is the best.

So Here in Lies the Rub - to Misquote from Shakespeare's Hamlet

The ideal line is not calibrated. There is no assessment if the orginal estimate was credible or bogus. If it was credible, what was the confidence of that credibility and what was the error band on that confidence. 

This is a serious - some might say egregious - error in statistical analysis. We're comparing actuals to a baseline that is not calibrated. This means the initial estimate is meaningless in the analysis of the variances without an assessment of it accuracy and precision. To then construct a probability distribution chart is nice, but measured against what - against bogus data.

This is harsh, but the paper and the presentation provide no description of the credibility of the initial estimates. Without that, any statistical analysis is meaningless. Let's move to another example in the second chart.

Screen Shot 2014-07-23 at 11.22.14 AM

The second chart - below - is from a calibrated  baseline. The calibration comes from a parametric model, where the parameters of the initial estimate are derived from prior projects - the reference class forecasting paradigm. The tool used here is COCOMO. There are other tools based on COCOMO and Larry Putman's and other methods that can be used for similar calibration of the initial estimates. A few we use are QSM, SEER, Price.

One place to start is Validation Method for Calibrating Software Effort Models. But this approach started long ago with An Empirical Validation of Software Cost Estimation Models. All the way to the current approaches of ARIMA and PCA forecasting for cost, schedule, and performance using past performance. And current approaches, derived from past research, of tuning those cost drivers using Bayesian Statistics.

Screen Shot 2014-07-20 at 10.42.05 PMSo What's All The Flap About?

The issue of software management, estimates of software cost, time, and performance abound. We hear about it every day. Our firm works on programs that have gone Over Target Baseline. So we walk the walk every day.

But when there is bad statistics used to sell solutions to complex problems, that's when it becomes a larger problem. To solve this nearly intractable problem of project cost and schedule over run, we need to look to the root cause. Let's start with a book Facts and Fallacies of Estimating Software Cost and Schedule. From there let's look to some more root causes of software project problems. Why Projects Fail is a good place to move to, with their 101 common casues. Like the RAND and IDA Root Cause Analysis reports many are symptoms, rather than root causes, but good infomation all the same.

So in the end when it is suggested that the woo's of project success can be addressed by applying

  • Decision making frameworks for projects that do not require estimates.
  • Investment models for software projects that do not require estimates.
  • Project management (risk management, scope management, progress reporting, etc.) approaches that do not require estimates.

Ask a simple question - is there any tangible, verifiable, externally reviewed evidence for this. Or is this just another self-selected, self-reviewed, self-promoting idea that violates the principles of microeconomics as it is applied to software development, where:

  • Economics is the study of how people make decisions in resource-limited situations. This definition of economics fits the major branches of classical economics very well.¬†

  • Macroeconomics is the study of how people make decisions in resource-limited situations on a national or global scale. It deals with the effects of decisions that national leaders make on such issues as tax rates, interest rates, and foreign and trade policy, in the presence of uncertainty

  • Microeconomics is the study of how people make decisions in resource‚ÄĒlimited situations on a ¬†personal scale. It deals with the decisions that individuals and organizations make on such issues as how much insurance to buy, which word processor to buy, what features to develop in what order, whether to make or buy a capability,¬†or what prices to charge for their products or services, in the presence of uncertainty. Real Options is part of this decision making process as well.

Economic principles underlie the structure of the software development life cycle, and its primary refinements of prototyping, itertaive and incremental development, and emerging requirements. 

If we look at writing software for money, it falls into the microeconomics realm. We have limited resources, limited time, and we need to make decisions in the presence of uncertainty.

In order to decide about the future impact of any one decision - making a choice - we need to know something about the furture which is itself uncertain. The tool to makes these decisions about the future in the presence of uncertainty is call estimating. Lot's of ways to estimate. Lots of tools to help us. Lots of guidance - books, papers, classrooms, advisers. 

But asserting we can in fact make decisions about the future in the presence of uncertainty without estimating is mathematically and practically nonsense. 

So now is the time to learn how to estimate, using your favorite method, because to decide in the absence of knowing the impact of that decision is counter to the stewardship of our customers money. And if we want to keep writing software for money we need to be good stewards first.

Related articles Averages Without Variances are Meaningless - Or Worse Misleading How to "Lie" with Statistics How to Fib With Statistics When Uncertainty is Good No Estimates of Costs and Schedule? The Value of Information COCOMO Model Why is Statistical Thinking Hard? Back To The Future The Failure of Open Loop Thinking
Categories: Project Management

All Decisions Are Based On Mathematics

Herding Cats - Glen Alleman - Thu, 07/24/2014 - 04:25

How Not To Be WrongObvious not every decision we make is based on mathematics, but when we're spending money, especially other people's money, we'd better have so good reason to do so. Some reason other than gut feel for any sigifican value at risk. This is the principle of Microeconomics.

All Things Considered is running a series on how people interprete probability. From capturing a terrortist to the probability it will rain at your house today. The world lives on probabilitic outcomes. These probabilities are driven by underlying statistical process. These statistical processes create uncertainties in our decision making processes.

Both Aleatory and Epistemic uncertainty exist on projects. These two uncertainties create risk. This risk impacts how we make decisions. Minimizing risk, while maximizing reward is a project management process, as well as a microeconomics process. By applying statistical process control we can engage project participants in the decision making process. Making decision in the presence of uncertainty is sporty business and many example of poor forecasts abound. The flaws of statistical thinking are well documented.

When we encounter to notion that decisions can be made in the absence of statistical thinking, there are some questions that need to be answered. Here's one set of questions and answers from the point of view of the mathematics of decision making using probability and statistics.

The book opens with a simple example.

Here's a question. We're designing airplanes - during WWII - in ways that will prevent them getting shot down by enemy fighters, so we provide them  with armour. But armor makes them heavier. Heavier planes are less maneuverable and use more fuel. Armoring planes too much is a proplem. Too little is a problem. Somewhere in between is optimum.

When the planes came back from a mission, the number of bullet holes was recorded. The damage was not uniformly distributed, but followed this pattern

  • Engine - 1.11 bullet holes per square foot (BH/SF)
  • Fueselage - 1.73 BH/SF
  • Fuel System - 1.55 BH/SF
  • Rest of plane - 1.8 BH/SF
The first thought was to provide armour where the need was the highest. But after some thought, the right answer was to provide amour where the bullet holes aren't - on the engines. "where are the missing bullet holes?" The answer was onb the missing planes. The total number of planed leaving minus those returning were the number of planes that were hit in a location that caused them not to return - the engines.

The mathematics here is simple. Start with setting a variable to Zero. This variables is the probability that a plane that takes a hit in the enginer manages to staty in the air and return to base. The result of this analysis (pp. 5-7 of the book) can be applied to our project work.

This is an example of the thought processes needed for project management and the decision making processes needed for spending other peoples money. The mathematician approach is to ask what assumptions are we making? Are they justified? The first assumption - the errenous assumption - was tyhat the planes returning represented were a random sample of all the planes. If so, the conclusions could be drawn.

In The End

Show me the numbers. Numbers talk BS walks is the crude phrase, but true. When we hear some conjecture about the latest fad think about the numbers. But before that read Beyond the Hype: Rediscovedring the Essence of Management, Robert Eccles and Nitin Nohria. This is an important book that lays out the processes for sorting out the hype - and untested and liley untestable conjectures - from the testable processes.

Related articles How To Fix Martin Fowler's Estimating Problem in 3 Easy Steps The World of Probability and Statistics Stationary processes How Not To Be Wrong Why is Statistical Thinking Hard? Selection bias and bombers How Not To Make Decisions Using Bad Estimates
Categories: Project Management

How Pairing & Swarming Work & Why They Will Improve Your Products

If you’ve been paying attention to agile at all, you’ve heard these terms: pairing and swarming. But what do they mean? What’s the difference?

When you pair, two people work together to finish a piece of work. Traditionally, two developers paired. The “driver” wrote the piece of work. The other person, the “navigator,” observed the work, providing review, as the work was completed.

I first paired as a developer in 1982 (kicking and screaming). I later paired in the late 1980’s as the tester in several developer-tester pairs. I co-wrote Behind Closed Doors: Secrets of Great Management with Esther Derby as a pair.

There is some data that says that when we pair, the actual coding takes about 15-20% longer. However, because we have built-in code review, there is much less debugging at the end.

When Esther and I wrote the book, we threw out the original two (boring) drafts, and rewrote the entire book in six weeks. We were physically together. I had to learn to stop talking. (She is very funny when she talks about this.) We both had to learn each others’ idiosyncrasies about indentations and deletions when writing. That’s what you do when you pair.

However, this book we wrote and published is nothing like what the original drafts were. Nothing. We did what pairs do: We discussed what we wanted this section to look like. One of us wrote for a few minutes. That person stopped. We changed. The other person wrote. Maybe we discussed as we went, but we paired.

After about five hours, we were done for the day. Done. We had expended all of our mental energy.

That’s pairing. Two developers. One work product. Not limited to code, okay?

Now, let’s talk about swarming.

Swarming is when the entire team says, “Let’s take this story and get it to done, all together.” You can think of swarming as pairing on steroids. Everyone works on the same problem. But how?

Someone will have to write code. Someone will have to write tests. The question is this: in what order and who navigates? What does everyone else do?

When I teach my agile and lean workshop, I ask the participants to select one feature that the team can complete in one hour. Everyone groans. Then they do it.

Some teams do it by having the product owner explain what the feature is in detail. Then the developers pair and the tester(s) write tests, both automated and manual. They all come together at about the 45-minute mark. They see if what they have done works. (It often doesn’t.) Then the team starts to work together, to really swarm. “What if we do this here? How about if this goes there?”

Some teams work together from the beginning. “What is the first thing we can do to add value?” (That is an excellent question.) They might move into smaller pairs, if necessary. Maybe. Maybe they need touchpoints every 15-20 minutes to re-orient themselves to say, “Where are we?” They find that if they ask for feedback from the product owner, that works well.

If you first ask, “What is the first thing we can do to add value and complete this story?” you are probably on the right track.

Why Do Pairing and Swarming Work So Well?

Both pairing and swarming:

  • Build feedback into development of the task at hand. No one works alone. Can the people doing the work still make a mistake? Sure. But it’s less likely. Someone will catch the mistake.
  • Create teamwork. You get to know someone well when you work with them that intensely.
  • Expose the work. You know where you are.
  • Reduce the work in progress. You are less likely to multitask, because you are working with someone else.
  • Encourage you to take no shortcuts, at least in my case. Because someone was watching me, I was on my best professional behavior. (Does this happen to you, too?)
How do Pairing and Swarming Improve Your Products?

The effect of pairing and swarming is what improves your products. The built-in feedback is what creates less debugging downstream. The improved teamwork helps people work together. When you expose the work in progress, you can measure it, see it, have no surprises. With reduced work in progress, you can increase your throughput. You have better chances for craftsmanship.

You don’t have to be agile to try pairing or swarming. You can pair or swarm on any project. I bet you already have, if you’ve been on a “tiger team,” where you need to fix something for a “Very Important Customer” or you have a “Critical Fix” that must ship ASAP. If you had all eyes on one problem, you might have paired or swarmed.

If you are agile, and you are not pairing or swarming, consider adding either or both to your repertoire, now.

Categories: Project Management

Business or Pleasure? Boy or Girl?

NOOP.NL - Jurgen Appelo - Tue, 07/22/2014 - 16:05
Business or Pleasure?

Someone emailed to me, “I’m sorry to see you had to work on Saturday night.” I don’t understand why because the “work” was only a couple of emails that I sent. And I was happy to do that on a Saturday night, just like I was perfectly happy to spend the entire Tuesday morning shopping for a mountain bike.

The post Business or Pleasure? Boy or Girl? appeared first on NOOP.NL.

Categories: Project Management

My Primary Criticism of Scrum

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

On the first day of my Certified ScrumMaster course, we go over the agenda for the two days. I point out that one topic we’ll cover will be “meetings.” I usually point out that Scrum is often criticized for the amount of meetings it defines. I then claim that this is a pretty weak criticism of Scrum because most of the meetings really aren’t very long, and that if we wanted to, we could find better criticisms of Scrum than “Scrum teams meet too much.”

After saying that, I always expect someone to ask for an example of a better criticism of Scrum. But usually, no one asks and I move onto the next topic.

And since I think it’s important to remain critical, I’d like to use this post to share one of my own criticisms of Scrum.

The strongest criticism I’d levy on Scrum is that many Scrum teams have become too focused on checking the boxes to say they are done with something, and less focused on finding innovative solutions to the problems they are handed.

Scrum in the mid-1990s (as I implemented it and saw it implemented back then) was all about finding innovative solutions. Teams were given a problem, and given a month (or four weeks) to solve the problem. With that much time, teams were able to try one or more potential breakthrough approaches before having to revert back to a safer, tried-and-true approach.

In today’s version of Scrum, many teams have become overly obsessed with being able to say they finished everything they thought they would. This leads those teams to start with the safe approach. Many teams never try any wild ideas that could lead to truly innovative solutions.

I believe a great deal of this is the result of the move to shorter sprints, with two weeks being the norm these days. Shorter sprints leave less time to recover if a promising but risky initial approach fails to pan out.

I’m willing to take my share of the “blame” for the prevalence of two-week sprints. I’ve certainly been vocal in my preference for that length (while remaining open to whatever is right for a given team). And, I still think two weeks is the right length for most teams. Two weeks is also my default, initial recommendation to a team until I know more about them.

So, as much good as a shift toward shorter sprints have done for Scrum teams, for many teams, it has come at the expense of creativity, experimentation and breakthrough ideas.

I don’t think the answer is for all teams to instantly revert to four-week sprints. I think mature Scrum teams have found ways to balance the pressure to get things done with the benefits that come from occasionally pursuing long-shot ideas that sometimes pay off.

So, there’s my biggest criticism of Scrum as I see it practiced today. What’s yours? What problems do you see with Scrum as defined or as it’s commonly practiced today?

My Primary Criticism of Scrum

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

On the first day of my Certified ScrumMaster course, we go over the agenda for the two days. I point out that one topic we’ll cover will be “meetings.” I usually point out that Scrum is often criticized for the amount of meetings it defines. I then claim that this is a pretty weak criticism of Scrum because most of the meetings really aren’t very long, and that if we wanted to, we could find better criticisms of Scrum than “Scrum teams meet too much.”

After saying that, I always expect someone to ask for an example of a better criticism of Scrum. But usually, no one asks and I move onto the next topic.

And since I think it’s important to remain critical, I’d like to use this post to share one of my own criticisms of Scrum.

The strongest criticism I’d levy on Scrum is that many Scrum teams have become too focused on checking the boxes to say they are done with something, and less focused on finding innovative solutions to the problems they are handed.

Scrum in the mid-1990s (as I implemented it and saw it implemented back then) was all about finding innovative solutions. Teams were given a problem, and given a month (or four weeks) to solve the problem. With that much time, teams were able to try one or more potential breakthrough approaches before having to revert back to a safer, tried-and-true approach.

In today’s version of Scrum, many teams have become overly obsessed with being able to say they finished everything they thought they would. This leads those teams to start with the safe approach. Many teams never try any wild ideas that could lead to truly innovative solutions.

I believe a great deal of this is the result of the move to shorter sprints, with two weeks being the norm these days. Shorter sprints leave less time to recover if a promising but risky initial approach fails to pan out.

I’m willing to take my share of the “blame” for the prevalence of two-week sprints. I’ve certainly been vocal in my preference for that length (while remaining open to whatever is right for a given team). And, I still think two weeks is the right length for most teams. Two weeks is also my default, initial recommendation to a team until I know more about them.

So, as much good as a shift toward shorter sprints have done for Scrum teams, for many teams, it has come at the expense of creativity, experimentation and breakthrough ideas.

I don’t think the answer is for all teams to instantly revert to four-week sprints. I think mature Scrum teams have found ways to balance the pressure to get things done with the benefits that come from occasionally pursuing long-shot ideas that sometimes pay off.

So, there’s my biggest criticism of Scrum as I see it practiced today. What’s yours? What problems do you see with Scrum as defined or as it’s commonly practiced today?

My Primary Criticism of Scrum

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

On the first day of my Certified ScrumMaster course, we go over the agenda for the two days. I point out that one topic we’ll cover will be “meetings.” I usually point out that Scrum is often criticized for the amount of meetings it defines. I then claim that this is a pretty weak criticism of Scrum because most of the meetings really aren’t very long, and that if we wanted to, we could find better criticisms of Scrum than “Scrum teams meet too much.”

After saying that, I always expect someone to ask for an example of a better criticism of Scrum. But usually, no one asks and I move onto the next topic.

And since I think it’s important to remain critical, I’d like to use this post to share one of my own criticisms of Scrum.

The strongest criticism I’d levy on Scrum is that many Scrum teams have become too focused on checking the boxes to say they are done with something, and less focused on finding innovative solutions to the problems they are handed.

Scrum in the mid-1990s (as I implemented it and saw it implemented back then) was all about finding innovative solutions. Teams were given a problem, and given a month (or four weeks) to solve the problem. With that much time, teams were able to try one or more potential breakthrough approaches before having to revert back to a safer, tried-and-true approach.

In today’s version of Scrum, many teams have become overly obsessed with being able to say they finished everything they thought they would. This leads those teams to start with the safe approach. Many teams never try any wild ideas that could lead to truly innovative solutions.

I believe a great deal of this is the result of the move to shorter sprints, with two weeks being the norm these days. Shorter sprints leave less time to recover if a promising but risky initial approach fails to pan out.

I’m willing to take my share of the “blame” for the prevalence of two-week sprints. I’ve certainly been vocal in my preference for that length (while remaining open to whatever is right for a given team). And, I still think two weeks is the right length for most teams. Two weeks is also my default, initial recommendation to a team until I know more about them.

So, as much good as a shift toward shorter sprints have done for Scrum teams, for many teams, it has come at the expense of creativity, experimentation and breakthrough ideas.

I don’t think the answer is for all teams to instantly revert to four-week sprints. I think mature Scrum teams have found ways to balance the pressure to get things done with the benefits that come from occasionally pursuing long-shot ideas that sometimes pay off.

So, there’s my biggest criticism of Scrum as I see it practiced today. What’s yours? What problems do you see with Scrum as defined or as it’s commonly practiced today?

What is Your Minimum Agile Reading List?

In preparation for my talk, Agile Projects, Programs, and Portfolio Management: No Air Quotes Required, I have created a Minimum Reading List for an Agile Transition. Note the emphasis on minimum.

I could have added many more books to this list. But the problem I see is that people don’t read anything. They think they do agile if they say they do agile.

But saying you do agile doesn’t mean anything if you don’t get to done on small stories and have the ability to change. I hope that if I suggest some small list of potential books, people will read the books, and realize, “I can do this!”

I am probably crazy-optimistic. But that hasn’t stopped me before.

I would like your help. Would you please review my list? Do you have better books? Do you have better suggestions? It’s my list. I might not change my mind. However, if you comment on that page, I would know what you think.

Thank you very much.

 

Categories: Project Management

Can There Be Actionable Suggestions Without Evidence of Them Working?

Herding Cats - Glen Alleman - Sat, 07/19/2014 - 01:38

Visiting the Montana State Museum of the Rockies this weekend and came across this sign in an exhibit. 

Now writing software for money is not this kind of science, but it is closely related to engineering and the enablement of engineering processes in our domain - things that fly away, swim away, drive away, and the enterprise IT systems that support those outcomes.

Evidence

When we hear about some new way to do something around managing projects that spend other peoples money, we do need to ask the questions posed by the sign above.

Is there any evidence that the suggested way - this new alternative of doing something - has the desired outcomes?

No? Then it's going to be difficult for those of us working in a domain that provides mission critical solutions - ERP, embedded software, infrastructure that other systems depend on - to know how to assess those suggestions.

The process of asking and answering a question like that is found in the Governance paradigm. Since our role is to be stewards of our customer's money in the delivery of value in exchange for that money, it's a legitimate question and deserves a legitimate answer. Without an answer, or at least and answer than can be tested outside the personal anecdotal experience of the proposer, it tends to be unsubstantiated opinion. 

Related articles Performance Based Management Positive Deviance Can Agile Be Integrated with Governance Based Development Processes? What Software Domain Do You Work In? The Myth of Incremental Development How to "Lie" with Statistics What Does "Done" Look Like? Why is Statistical Thinking Hard? If We're Going To Make Improvements, We Have To Be Able To Calculate Real Numbers
Categories: Project Management