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

Software Development Conferences Forecast July 2014

From the Editor of Methods & Tools - 4 hours 10 min ago
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?

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.


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

Why Testing in Women Testers Magazine

I have an article in a new online magazine, Women Testers, the July 2014 edition. My article is called “Why Testing?”

When I was a tester or a developer, I asked many questions. As a project manager, program manager or consultant, I still ask many questions. One of those is the Why question. This article examines that question from a number of perspectives.

Go read that article and many others from people such as Alexandra Moreira, Bolette Stubbe Teglbjærg, Smita Mishra, Sara Tabor, Karen N. Johnson, and Mike Lyles.

I bet you’ll enjoy it!

Categories: Project Management

My Zero-Tolerance to Bureaucracy Policy

NOOP.NL - Jurgen Appelo - Fri, 07/18/2014 - 14:19
Zero-Tolerance to Bureaucracy

Sometimes, event organizers ask me to fill out a form asking me for my company name, address, bank account number, bank name, tax number, and much more. They tell me they need this information in order to make their payment to me later. But I think this is a bit silly.

The post My Zero-Tolerance to Bureaucracy Policy appeared first on NOOP.NL.

Categories: Project Management

Do Teams Gel or Jell?

In my role as technical editor for, I have the opportunity to read many terrific articles. I also have the opportunity to review and comment on those articles.

One such comment is what do teams do? Do they “gel” or do they “jell”?

Gel is what you put in hair. When you “gel” things, you create a thick goo, like concrete. Teams are not a thick goo. Teams are flexible and responsive.

Jell is what you want teams to do. You want them firm, but not set in concrete. When teams jell, they might even jiggle a little. They wave. They adapt. They might even do a little dance, zigging here, zapping there.

You want to keep the people in the teams as much as possible, so you flow work through the teams. But you want the people in the teams to reconsider what they do on a regular basis. That’s called retrospecting. People who have their feet in concrete don’t retrospect. They are stuck. People who are flexible and responsive do.

So, think about whether you have a gelled or a jelled team. Maybe I’m being a nitpicker. I probably am. Our words mean something.

If you have an article you’d like to publish, send it to me. You and I will craft it into something great. Whether or not your team jells.


Categories: Project Management

The Myth of Incremental Development

Herding Cats - Glen Alleman - Thu, 07/17/2014 - 17:07

Screen Shot 2014-07-13 at 6.27.34 PMIn the agile world there is a common notion that incremental delivery is a desired approach. Many taught rapid release, even multiple releases a day.

The question is two fold. Can the customer accept the release into use and the other does the customer have the ability to make use of the incremental capabilities of these releases?

Let's start with the incremental release. I know the picture to the left is  considered a metaphor by some. But as a metaphor it's a weak. Let's look a a few previous posts. Another Bad Agile Analogy, Use, Misuse, and Danger of Metaphor. Each of these presents some issues with using Metaphors.

But let's be crystal clear here. Incremental development in the style of the bottom picture may be a preferred method, once the customer agrees. Much of the reterotic around agile assumes the customer can behave in this way, without looking outside the ancedotal and many times narrow experiences of the those making that suggestion. For agile to succeed in the enterprise and mission critical product and project domain, testing the applicability of both pictures is needed.

Ask the customer if they are willing to use the skateboard while waiting for the car? Otherwise you have a solution looking for a problem to solve.

Now to the bigger issue. In the picture above, the top series is a linear development and the bottom an iterative or incremental depending on where you work. Iterating on the needed capabilities to arrive at the car. Or incrementally delivering a mode of transporatation.

The bottom's increment shows 5 vehicles produced by the project. The core question that is unanswered is does the customer want a skate board, scooter, bicycle, motorcycle, and then a car for transportation. If yes, no problem. But if the customer actually needs a car to conduct business, drive the kids to school, or arrive at the airport for your vacation trip.

The failure of the metaphor and most metaphors is they don't address the reason for writing software for money

Provide capabilities for the business to accomplish something - Capabilities Based Planning

The customer didn't buy requirements, software, hardware, stories, features, or even the agile development process. They bought a capability to do something. Here's how to start that process.

Capabilities Based Planning

Here's the outcome and an insurnace provider network enrollemtn ERP system.

Capabilities Map

Producing skateboards, then scooters, then bicycles and then finally the car isn't going to meet the needs of the customer if they want a car or a fleet of cars. In the figure above the Minimal Viable Features, aren't features they are capabilities. For example this statement is a minimal viable product is likey a good description of a Beta Feature. Could be connected to a business capability, but without a Capabilities Based Plan as in above, can't really tell.

Screen Shot 2014-07-16 at 12.16.26 PM

So How Did We Get In This Situation?

Here's a biased opinion informed by my several decades of experience writing code and managing others who write code - we're missing the systems engineering paradigm in commercial software development. That is for software development of mission critical systems, and Enterprise IT is an example of mission critical systems.

Here's some posts:

The patradigm of Systems Engineering fills 1,000's pages and dozen's of books, but it is boiled down to this.

You need to know what DONE looks like in units of measure meaningful to the decision makers. Those units start with Measures of Effectiveness and Measures of Performance.

Each of those measures is probabilistic, driven by the underlying statistical processes of the system. These mean you must be able to estimate not only cost and schedule, but how that cost and schedule will deliver the needed system capabilities measured in MOE's and MOP's.

SE in One Page

Related articles Do It Right or Do It Twice Why Johnny Can't Estimate or the Dystopia of Poor Estimating Practices Agile vs Waterfall: Introduction Lean Startup, Innovation, #NoEstimates, and Minimal Viable Features
Categories: Project Management

What About Cleaning Toilets?

NOOP.NL - Jurgen Appelo - Thu, 07/17/2014 - 16:00
Cleaning toilets

I often promote work-life fusion, quitting jobs that are not fulfilling, and seeking work that is a calling instead of just a career. But, I hear some people think, can this be true for everyone? Is there a great job, somewhere, for every person in the world?

What about cleaning toilets?

How can this work be fulfilling to anyone?

Well, that depends…

The post What About Cleaning Toilets? appeared first on NOOP.NL.

Categories: Project Management

Control Systems - Their Misuse and Abuse

Herding Cats - Glen Alleman - Wed, 07/16/2014 - 03:23

Modern Contrrol EngineeringProject Management is a control system, subject to the theory and practice of control systems. The Project Management Control System provides for the management of systems and processes - cost estimating, work scope structuring and authorization, scheduling, performance measurement, reporting, for assessing the progress of spending other peoples money.

The level of formality for these processes varies according to domain and context. From sticky notes on the wall for a 3 person internal warehouse locator website of a plastic shoe manufacture -  to a full DCMA ANSI-748C validated Earned Value Management System (EVMS) on a $1B software development project and everything in between.

The key here is if we're going to say we have a control system it needs to be a Closed Loop control system, not an Open Loop control system. On Open Loop system is called train watching, we sit by the side of the tracks and count the trains going by and report that number. How many trains should go by, could go by? We don't know. That's what's shown in the first picture. We sample the data, we apply that data to the process and it generates an output. There is no corrective action, it's just a signal based on the past performance of the system. Some examples of Open Loop control implemented in the first picture:

  • A light switch. Turn it on the light goes on. Turn it off the light goes off. Turn it on and the light doesn't go on, don't know why. Could be the switch, could be the¬†blub is burned out, could be the power is out in the neighborhood.
  • Same for a faucet, the burned on the stove, a simple cloths dryer when you use the timer rather than the¬†sense cloths are dry feature.
  • The really cool shade we just installed for the upper deck. Push the button and it lowers to a present position, push it again and it goes back to the storage position.

The key attribute of Open Loop Control 

  • It is a non-feedback system, is a type of continuous control system in which the output has no influence or effect on the control action of the input signal.
  • In an open-loop control system the output is neither measured nor fed back for comparison with the input.
  • An open-loop system is expected to faithfully follow its input command or set point regardless of the final result.
  • An open-loop system has no knowledge of the output condition so cannot self-correct any errors it could make when the preset value drifts, even if this results in large deviations from the preset value.

The key disadvantage of open-loop systems is it is poorly equipped to handle disturbances or changes in the conditions which that reduce its ability to complete the desired task. 

A close loop system behaves differently. Here's some example of controllers used in the second picture

  • Thermostat for the furnace or air conditioner - Set a target temperature and it holds that temperature pretty much constant¬†
  • Refrigerator cold/hot setting - keeps the food in the refrigerator at a preset temperature¬†
  • Same for the temperature setting for oven.

The key attributes of  Close Loop Control, shown in the second picture

  • Closed-loop systems are designed to automatically achieve and maintain the desired output condition by comparing it with the actual condition.
  • This is done by generating an error signal which is the difference between the output and the reference input.
  • A ‚Äúclosed-loop system‚ÄĚ is a fully automatic control system in which its control action being dependent on the output in some way.

Because the closed-loop system has  knowledge of the output condition - in the case of projects the desired cost, schedule, and technical performance, it is  equipped to handle  system disturbances or changes in the conditions which may reduce its ability to complete the desired task.

When we have a target cost - defined on day one by the target budget, a planned need date, and some technical performance target, closed loop control provides the needed feedback to make decisions along the when, when the actual performance is not meeting our planned or needed performance

Open Closed Loop

In the end it comes back to the immutable principle of microeconomics. When we are spending money to produce a value, we need to make decisions about which is the best path to take, which are the best of multiple options to choose. In our to do this we need to know something about the cost, schedule, and performance forecasts from each of the choices. Then we need feedback from the actual performance to compare with our planned performance to create an error signal. With this error signal, we can then DECIDE what corrective actions to take.

Without this error signal, derived from the planned values compared with the actual values there is no information needed to decide. Sure we can measure what happened in the past and decide, just like we can count trains and make some decision. But that decision is not based on a planned outcome, a stated need, or an Estimated Arrival time for example. 

Without that estimated arrival time, we can't tell if the train is late or early, just that it arrived. Same with the project measurements.

  • We need on average 4.5 stories per iteration. How many stories did you need to do to finish the project on the planned day with the planned capabilities.

Open Loop provides no feedback, so you're essentially driving in the rear view mirror, when you should be looking out the windshield deciding where to go next to escape the problem.

Objects are closer3

Related articles Can We Make Decisions Without Feedback? Seven Immutable Activities of Project Success Agile Requires Discipline, In Fact Successful Projects Require Discipline The DCMA 14 Point Schedule Assessment Control system and its classification The Failure of Open Loop Thinking First Comes Theory, Then Comes Practice All Project Numbers are Random Numbers - Act Accordingly
Categories: Project Management

Quote of the Day - Writing SW For Money Is Micro-Economics

Herding Cats - Glen Alleman - Wed, 07/16/2014 - 03:12

We find no sense in talking about something unless we specify how we measure it. A definition by the method of measuring a quantity is the one sure way of avoiding talking nonsense¬†‚ÄĒ Sir Hermann Bondi

So when we hear a suggested approach to solving any problem, what are the units of measure of the discussion elements, the inputs to that discussion, and the outcomes?

Micro-economics is defined as

A branch of economics that studies the behavior of individuals and small impacting players in making decisions on the allocation of limited resources. Typically, it applies to markets where goods or services are bought and sold.

Certainly in the software development business, goods are bought and sold. Software is developed in exchange for money. The resulting product is then put to work to generate some monetized value for the buyer. The value exchanged for the cost of that value is usually assessed as the Return on Investment

ROI = (Value - Cost of the Value) / Cost of the Value

Economics of Iterative DevelopmentLet's start with some basic concepts of writing software for money. I'd suggest these are immutable concepts in a for proft business world. The book on the left is a ggod start, but there are other materials about the economics of software development. The one that comes to mind is Software Engineering Economics, Barry Boehm, Prentice Hall. While some has suggested this book is dated and no longer applicable to our modern software development paradigm, that could only be true if our modern paradigm is not subject to the principles of micro-economics. And that is unlikely, so let's proceed with applying the principles of micro-economics to the problem at hand. That problem is

How can we know the cost, schedule, and performance of a software product with sufficient confidence into order to make business (micro-economic) decisions about how to manage the limited resources of the project?

Those resources are of course the variables we are trying to determine. Cost, Schedule, and Performance. Each of which contains resources. Cost in software development is primarily driven by staff. Schedule is driven by the efficacy of that staff's ability to write code. And the performance of the resulting outcomes are driven by the skills and experience of the staff, who is consuming the funds (cost) provided to the project.

So if we look at the basics of the economics of writing software for money, we'll see some simple principles.

If it's a product development effort, someone in the marketing and sales department has a planned release date. This date and the projected revenue from that release is in the sales plan. These are random numbers of course -  so I won't repeat that, but all numbers in business are random numnbers until they get entered into the General Ledger.

  • These projected revenue numbers are based on releasing the product with the features needed for customers to buy it.
  • The cost to develop that product is subtracted from the revenue - usually in some complex manner - to produce the retained earnings¬†attributed to the product.¬†
  • This of course is the simple formula
    • Earnings = Revenue - Cost¬†
    • Where cost is categorized in many ways, some attributable to the development of the product, some to overhead, benefits, fringe, and other indirect costs (ODC).
    • Revenue recognition is a continuously evolving issue with taxes and performance reporting in actual firms
    • But for the purposes here, the simple formula will do.¬†Managerial Finance, Brigham and Weston is a good place to look for the details.

If it's a service effort, the customer has engaged the firm to perform some work in writing software, doing consulting around that software, integrating existing software or some combination of these and other software related services. Managing the Professional Services Firm, was mandatory reading along wioth other internal company written books when I worked for a large Professional Services (PS) firm. With our small firm now, we still refer to that book.

  • Some type of problem needs to be solved involving a solution that uses software (and maybe hardware), processes, and people.
  • The cost, schedule, and capabilities of the solution need to be worked out in some way in order to know what¬†DONE looks like. Any one subscribing to this Blog know the¬†Knowing What Done Looks Like is a critical success factor for any effort.
  • But in the case of a services solution, this¬†knowing is a bit more difficult than the product solution, since the¬†customer may not know themselves.¬†
  • This is the golden opportunity for incremental and itertaive development.
  • But in the end the PS customer still needs to know the cost, schedule, and what will be delivered, because that person has a similar ROI calculation to do for those funding the PS work.
Related articles Earning Value from Earned Value How To Assure Your Project Will Fail Why Johnny Can't Estimate or the Dystopia of Poor Estimating Practices The Value of Information
Categories: Project Management

The Power of Misattributed and Misquoted Quotes

Herding Cats - Glen Alleman - Tue, 07/15/2014 - 15:30

Warning this is an Opinion Piece.

In a conversation this week the quote Insanity is doing everything the same way and expecting a different outcome. Or some variant of that. Attributed to Einstein. As if attributing it to Einstein makes it somehow more credible, than attributing it to Dagwood Bumstead.

Well it turns out it is not a quote from dear olde Albert. It is also mis-attributed to Ben Franklin, Confucius, and a Chinese proverb.

The first printed record of this quote is in the 1981 Narcotics Anonymous approval version of their handbook. No other printed record is found. 

Why is this Seemingly Trival Point Important

We toss around platitudes, quotes, and similar phrases in the weak and useless attempt to establish credibility of an idea by referencing some other work. Like quoting a 34 year old software report from NATO, when only mainframes and FORTRAN 77 were used, to show the software crisis and try to convince people it's the same today. Or use un-vetted, un-reviewed, charts and graphs from an opinion piece in popular techncial magazine as the basis of statistical analysis of self-selected data

Is it world shaking news? No. Is the balanced of the universe disrupted? Hardly. 

But is shows a lack of mental discipline that leaks into the next level of thought process. It's always the little things that count, get those right and the big things follow. That is a quote from somewhere. But it also shows laziness of thought, use of platitudes in place of the hard work to solve nearly intractable problems, and all around disdain for working on those hard problems. It's a sign of our modern world - look for the fun stuff, the easy stuff, and the stuff we don't really want to be held accountable for if it goes wrong

I will use the Edwin Land quote though, that is properly attributed to him

Don't undertake a project unless it is manifestly important and nearly impossible. 

That doesn't sound like much fun, let's work on small, simple, and easy projects and tell everyone how those successful processes we developed can be scaled to the manifestly important and nearly impossible ones.

Related articles Resources for Moving Beyond the "Estimating Fallacy" How to Deal With Complexity In Software Projects? 50 Common Misquotations, but no Howard Thurman Fake quotes flood social media 31 Famous Quotations You've Been Getting Wrong 6 Famous Misquotes & Where They Came From (Mis)quoting Neil Armstrong
Categories: Project Management