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!

Feed aggregator

What Model Do Your Estimates Follow?

Cone of UncertaintyFor years, we bought the cone of uncertainty for estimation—that is, our estimates were just as likely to be over as under.

Laurent Bossavit, in The Leprechauns of Software Engineering, shows us how that assumption is wrong. (It was an assumption that some people, including me, assumed was real.)

This is a Gaussian (normal) distribution. It’s what we expect. But, it’s almost never right. As Laurent says,

“Many projects stay in 90% done for a long time.”

What curve do our estimates follow¬†if they don’t follow a Gaussian distribution?

Troy Magennis, in “The Economic Impact of Software Development Process Choice – Cycle Time Analysis and Monte Carlo Simulation Results,” suggests we should look at the Power-Law (Weibull) distribution.

What this distribution says with respect to estimation is this: We are good at estimating small things. We get much worse with our estimation quickly, and for the long tail  (larger and larger chunks of work), we are quite bad.

Why? Because creating software is innovation. Building software is about learning. We better our learning as we proceed, assuming we finish features.

We rarely, if ever, do the same thing again. We can’t apply precise estimation approaches to something we don’t know.

You should read Troy’s paper¬†because it’s fascinating. It’s well-written, so don’t worry about not being able to understand it. You will understand it. It’s only 10 pages long.

The question is this: What effect does understanding an estimation model have on our estimates?

If we know that the normal distribution is wrong, then we won’t apply it. Right, why would you do something you know to be wrong? You would not estimate large chunks and expect to have a +/- 10% estimate. It doesn’t make sense to do that.

But what can we do? On the printed paper, what the proceedings will show p. 5061, Troy has a table that is telling. In it, he says that if you have large unique work items or you have large WIP, you will have poor predictability. (He has suggestions for what to do for your process.)

My suggestions for your estimation:

  1. Estimate small chunks of work that a team can complete in a day or so.
  2. Keep WIP low.
  3. Replan as you finish work.
  4. Watch your cycle time.
  5. No multitasking.

What should you do when people ask you for estimates? What kind of requirements do you have? If you have large requirements, follow my advice and use the percentage confidence, as in We Need Planning; Do We Need Estimation? Read the estimation series or get Essays on Estimation.

You can predict a little for estimates. You can better your prediction. And, you may have to predict a large effort. In that case, it helps to know what distribution model might reflect your estimate.

Categories: Project Management

Do You Have Senior Management Support?

Do you have someone backing you up?

Do you have someone backing you up?

Audio Version on SPaMCAST 143

I asked many of my colleagues what they thought were the precursors to beginning a CMMI change program. Almost to a person, they began their list with senior management support, which makes sense as the CMMI has become the top-down process improvement framework of choice, and a prominent attribute of top-down change programs is the need for explicit senior management support.

Deciding whether your process improvement program is best pursued from a bottom-up or the top-down perspective is not a throw-away question. The method you are using changes as it matures over time.  I have heard that during early days of the SEPG conference  there were numerous presentations on how the CMMI could be implemented as a grassroots change program.  Presentations on the pursuit of the CMMI using grassroots techniques are now few and far between, however if you go to an Agile conference you will still see presentations of this type.

Given the importance of senior management support, you need to ensure you have it BEFORE you start any top-down improvement program using a framework like the CMMI.  There are six things to consider when determining whether you have senior management support. They are:

  1. Assigning the right people
  2. Being visible
  3. Organizational change management support
  4. Providing required resources
  5. Enforcing the processes
  6. Having a constancy of purpose

Assigning the right people: Start by assessing whether your top performers and leaders are assigned to staff your CMMI change program. Assigning the best and brightest serves multiple purposes. Top performers tend to demand and draw respect from the staff.  Secondly, assigning the best and brightest is a show of determination by the organization.

Being visible:¬† Do members of the senior management team attend training classes or status meetings?¬† Do they stop people in the hall and ask about the program?¬† Being visible is a convincing approach to proving that the CMMI program is important and success is personnel. Tom Szurszewski said, ‚ÄúThe Senior Management/Sponsor should attend the “Intro to CMMI” class, along with the individuals who were being charged with “making it happen.” Participating in training ensures an equal level of understanding and a very public show of visibility.

Organizational change management support: Making the changes needed to support the CMMI tends to require organizational nips and tucks. Only senior management can grease the skids to make organizational changes.¬† Nanette Yokley stressed the need for an Executive Sponsor that ‚Äúideally … understands what they are getting into related to changes needed and long-term process.‚ÄĚ

Providing the required resources:¬† Resources can include budget, tools, space, training classes and others.¬† Without the right resources, change programs will struggle. Trying to apply the CMMI on the cheap is usually a prescription for problems.¬† Paul Laberge went to heart of the matter with one of his comments saying, ‚Äúmanagement must ensure the availability of a resource (or more) to maintain the process improvement program and documented processes.‚ÄĚ

Enforcing the processes: When implementing any process changes, using the process can’t be optional. When push comes to shove (and it will), management can’t hand out free passes. Management must enforce the process or risk the failure of the program.

Constancy of purpose:¬† W. Edward Deming felt so strongly about the need for constancy of purpose that it was the first of his famous fourteen points. Lasting change requires a focus that goes past the first problem or the next quarter. If the CMMI is perceived to be the change ‚Äúflavor of the week,‚ÄĚ the overall degree of difficulty for staying the course will be higher than expected.¬† Dominique Bourget talked about measuring ‚Äúthe will of the upper management to improve.‚Ä̬† Frankly, that will say a lot about staying power of any change program.


  1. Review each attribute. Can you honestly say that your senior management team (usually more than one) is delivering on each attribute?
  2. Answer each with a yes or no.

If you answer five or more yes you are in good shape. If you can answer yes to less than five, it is time for a serious conversation with your senior management on how to handle remediating the problem and to build management support.

Categories: Process Management

Apache Spark

Xebia Blog - Tue, 02/03/2015 - 21:22

Spark is the new kid on the block when it comes to big data processing. Hadoop is also an open-source cluster computing framework, but when compared to the community contribution, Spark is much more popular. How come? What is so special and innovative about Spark? Is it that Spark makes big data processing easy and much more accessible to the developer? Or is it because the performance is outstanding, especially compared to Hadoop?

This article gives an introduction to the advantages of current systems and compares these two big data systems in depth in order to explain the power of Spark.

Parallel computing

First we have to understand the differences between Hadoop and the conventional approach of parallel computing before we can compare the differences between Hadoop and Spark.

Distributed computing

In the case of parallel computing, all tasks have access to shared data to exchange information and perform their calculations. With distributed computing, each task has its own data. Information is exchanged by passing data between the tasks.

One of the main concepts of distributed computing is data locality, which reduces network traffic. Because of data locality, data is processed faster and more efficiently. There is no separate storage network or processing network.

Apache Hadoop delivers an ecosystem for distributed computing. One of the biggest advantages of this approach is that it is easily scalable, and one can build a cluster with commodity hardware. Hadoop is designed in the way that it can handle server hardware failures.


To understand the main differences between Spark and Hadoop we have to look at their stacks. Both stacks consist of several layers.

Stacks of Spark and Hadoop

The storage layer is responsible for a distributed file system that stores data on commodity machines, providing very high aggregate bandwidth across the cluster. Spark uses the Hadoop layer. That means one can use HDFS (the file system of Hadoop) or other storage systems supported by the Hadoop API. The following storage systems are supported by Hadoop: your local file system, Amazon S3, Cassandra, Hive, and HBase.

The computing layer is the programming model for large scale data processing. Hadoop and Spark differ significantly in this area. Hadoop uses a disk-based solution provided by a map/reduce model. A disk-based solution persists its temporary data on disk. Spark uses a memory-based solution with its Spark Core. Therefore, Spark is much faster. The differences in their computing models will be discussed in the next chapter.

Cluster managers are a bit different from the other components. They are responsible for managing computing resources and using them for the scheduling of users' applications. Hadoop uses its own cluster manager (YARN). Spark can run over a variety of cluster managers, including YARN, Apache Mesos, and a simple cluster manager called the Standalone Scheduler.

A concept unique to Spark is its high-level packages. They provide lots of functionalities that aren't available in Hadoop. One can see this layer also as a sort of abstraction layer, whereby code becomes much easier to understand and produce. These packages are

  • Spark SQL is Spark‚Äôs package for working with structured data. It allows querying data via SQL.
  • Spark Streaming enables processing live streams of data, for example, log files or a twitter feed.
  • MLlib is a package for machine learning functionality. A practical example of machine learning is spam filtering.
  • GraphX is a library that provides an API for manipulating graphs (like social networks) and performing graph-parallel computations.

The Spark Core is also written in Scala and supports Scala natively, which is a far better language than Java for implementing the kinds of transformations it supports. This results in less code which is therefore more intuitive.

Screen Shot 2015-01-24 at 16.41.37

(Source: infoq)

Computational model

The main difference between Hadoop and Spark is the computational model. A computational model is the algorithm and the set of allowable operations to process the data.

Hadoop uses the map/reduce. A map/reduce involves several steps.

Hadoop computational model: Map/Reduce

  • This data will be processed and indexed on a key/value base. This processing is done by the map task.
  • Then the data will be shuffled and sorted among the nodes, based on the keys. So that each node contains all values for a particular key.
  • The reduce task will do computations for all the values of the keys (for instance count the total values of a key) and write these to disk.

With the Hadoop computational model, there are only two functions available: map and reduce.
Note that doing distributed computing with Hadoop results, most of the time, in several iterations of map/reduce.  For each iteration, all data is persisted on disk. That is the reason it is called disk-based computing.

Spark uses RDD, also called Resilient Distributed Datasets. Working and processing data with RDD is much easier:

Spark computational model: RDD

  • Reading input data and thereby creating an RDD.
  • Transforming data to new RDDs (by each iteration and in memory). Each transformation of data results in a new RDD. For transforming RDD's there are lots of functions one can use, like map, flatMap, filter, distinct, sample, union, intersection, subtract, etc. With map/reduce you only have the map-function. (..)
  • Calling operations to compute a result (output data). Again there are lots of actions available, like collect, count, take, top, reduce, fold, etc instead of only reduce with the map/reduce.

Performance Hadoop vs Spark

Behind the scenes, Spark does a lot, like distribute the data across your cluster and parallelizing the operations. Note that doing distributed computing is memory-based computing. Data between transformations are not saved to disk. That's why Spark is so much faster.


All in all Spark is the next step in the area of big data processing, and has several advantages compared to Hadoop. The innovation of Spark lies in its computational model. The biggest advantages of Spark against Hadoop are

  • Its in-memory computing capabilities that deliver speed
  • Packages like streaming and machine-learning
  • Ease of development - one can program natively in Scala

How to Write a Book: Structured or Emergent

NOOP.NL - Jurgen Appelo - Tue, 02/03/2015 - 19:29

I believe most authors apply the hybrid approach to writing. They start anywhere they want, either with a logical outline or with some random writing, but then they bounce up and down continuously to ensure that their writing has both structure and surprise.

The post How to Write a Book: Structured or Emergent appeared first on NOOP.NL.

Categories: Project Management

Sponsored Post: Apple, Couchbase, Farmerswife, VividCortex, Internap, SocialRadar, Campanja, Transversal, MemSQL, Scalyr, FoundationDB, AiScaler, Aerospike, AppDynamics, ManageEngine, Site24x7

Who's Hiring?
  • Apple is hiring a Application Security Engineer. Apple’s Gift Card Engineering group is looking for a software engineer passionate about application security for web applications and REST services. Be part of a team working on challenging and fast paced projects supporting Apple's business by delivering high volume, high performance, and high availability distributed transaction processing systems. Please apply here.

  • Want to be the leader and manager of a cutting-edge cloud deployment? Take charge of an innovative 24x7 web service infrastructure on the AWS Cloud? Join farmerswife on the beautiful island of Mallorca and help create the next generation on project management tools. Please apply here.

  • Senior DevOps EngineerSocialRadar. We are a VC funded startup based in Washington, D.C. operated like our West Coast brethren. We specialize in location-based technology. Since we are rapidly consuming large amounts of location data and monitoring all social networks for location events, we have systems that consume vast amounts of data that need to scale. As our Senior DevOps Engineer you’ll take ownership over that infrastructure and, with your expertise, help us grow and scale both our systems and our team as our adoption continues its rapid growth. Full description and application here.

  • Linux Web Server Systems EngineerTransversal. We are seeking an experienced and motivated Linux System Engineer to join our Engineering team. This new role is to design, test, install, and provide ongoing daily support of our information technology systems infrastructure. As an experienced Engineer you will have comprehensive capabilities for understanding hardware/software configurations that comprise system, security, and library management, backup/recovery, operating computer systems in different operating environments, sizing, performance tuning, hardware/software troubleshooting and resource allocation. Apply here.

  • Campanja is an Internet advertising optimization company born in the cloud and today we are one of the nordics bigger AWS consumers, the time has come for us to the embrace the next generation of cloud infrastructure. We believe in immutable infrastructure, container technology and micro services, we hope to use PaaS when we can get away with it but consume at the IaaS layer when we have to. Please apply here.

  • UI EngineerAppDynamics, founded in 2008 and lead by proven innovators, is looking for a passionate UI Engineer to design, architect, and develop our their user interface using the latest web and mobile technologies. Make the impossible possible and the hard easy. Apply here.

  • Software Engineer - Infrastructure & Big DataAppDynamics, leader in next generation solutions for managing modern, distributed, and extremely complex applications residing in both the cloud and the data center, is looking for a Software Engineers (All-Levels) to design and develop scalable software written in Java and MySQL for backend component of software that manages application architectures. Apply here.
Fun and Informative Events
  • Sign Up for New Aerospike Training Courses.  Aerospike now offers two certified training courses; Aerospike for Developers and Aerospike for Administrators & Operators, to help you get the most out of your deployment.  Find a training course near you.
Cool Products and Services
  • See how LinkedIn uses Couchbase to help power its “Follow” service for 300M+ global users, 24x7.

  • VividCortex is a hosted (SaaS) database performance management platform that provides unparalleled insight and query-level analysis for both MySQL and PostgreSQL servers at micro-second detail. It's not just another tool to draw time-series charts from status counters. It's deep analysis of every metric, every process, and every query on your systems, stitched together with statistics and data visualization. Start a free trial today with our famous 15-second installation.

  • SQL for Big Data: Price-performance Advantages of Bare Metal. When building your big data infrastructure, price-performance is a critical factor to evaluate. Data-intensive workloads with the capacity to rapidly scale to hundreds of servers can escalate costs beyond your expectations. The inevitable growth of the Internet of Things (IoT) and fast big data will only lead to larger datasets, and a high-performance infrastructure and database platform will be essential to extracting business value while keeping costs under control. Read more.

  • MemSQL provides a distributed in-memory database for high value data. It's designed to handle extreme data ingest and store the data for real-time, streaming and historical analysis using SQL. MemSQL also cost effectively supports both application and ad-hoc queries concurrently across all data. Start a free 30 day trial here:

  • Aerospike demonstrates RAM-like performance with Google Compute Engine Local SSDs. After scaling to 1 M Writes/Second with 6x fewer servers than Cassandra on Google Compute Engine, we certified Google’s new Local SSDs using the Aerospike Certification Tool for SSDs (ACT) and found RAM-like performance and 15x storage cost savings. Read more.

  • FoundationDB 3.0. 3.0 makes the power of a multi-model, ACID transactional database available to a set of new connected device apps that are generating data at previously unheard of speed. It is the fastest, most scalable, transactional database in the cloud - A 32 machine cluster running on Amazon EC2 sustained more than 14M random operations per second.

  • Diagnose server issues from a single tab. The Scalyr log management tool replaces all your monitoring and analysis services with one, so you can pinpoint and resolve issues without juggling multiple tools and tabs. It's a universal tool for visibility into your production systems. Log aggregation, server metrics, monitoring, alerting, dashboards, and more. Not just “hosted grep” or “hosted graphs,” but enterprise-grade functionality with sane pricing and insane performance. Trusted by in-the-know companies like Codecademy – try it free! (See how Scalyr is different if you're looking for a Splunk alternative.)

  • aiScaler, aiProtect, aiMobile Application Delivery Controller with integrated Dynamic Site Acceleration, Denial of Service Protection and Mobile Content Management. Cloud deployable. Free instant trial, no sign-up required.

  • ManageEngine Applications Manager : Monitor physical, virtual and Cloud Applications.

  • : Monitor End User Experience from a global monitoring network.

If any of these items interest you there's a full description of each sponsor below. Please click to read more...

Categories: Architecture

The First Annual Testing on the Toilet Awards

Google Testing Blog - Tue, 02/03/2015 - 17:51
By Andrew Trenk

The Testing on the Toilet (TotT) series was created in 2006 as a way to spread unit-testing knowledge across Google by posting flyers in bathroom stalls. It quickly became a part of Google culture and is still going strong today, with new episodes published every week and read in hundreds of bathrooms by thousands of engineers in Google offices across the world. Initially focused on content related to testing, TotT now covers a variety of technical topics, such as tips on writing cleaner code and ways to prevent security bugs.

While TotT episodes often have a big impact on many engineers across Google, until now we never did anything to formally thank authors for their contributions. To fix that, we decided to honor the most popular TotT episodes of 2014 by establishing the Testing on the Toilet Awards. The winners were chosen through a vote that was open to all Google engineers. The Google Testing Blog is proud to present the winners that were posted on this blog (there were two additional winners that weren’t posted on this blog since we only post testing-related TotT episodes).

And the winners are ...

Erik Kuefler: Test Behaviors, Not Methods and Don't Put Logic in Tests 
Alex Eagle: Change-Detector Tests Considered Harmful

The authors of these episodes received their very own Flushy trophy, which they can proudly display on their desks.

(The logo on the trophy is the same one we put on the printed version of each TotT episode, which you can see by looking for the ‚Äúprinter-friendly version‚ÄĚ link in the TotT blog posts).

Congratulations to the winners!

Categories: Testing & QA

What does it mean when we say 80% confidence in a number?

Herding Cats - Glen Alleman - Tue, 02/03/2015 - 17:07

Confidence intervals are the means to measure population parameters. A concern in inferential statistics (making a prediction from a sample of data or from a model of that data) is the estimation of the population parameter from the sample statistic.

The sample statistic is calculated from the sampled data and the population parameter is estimated from this sample statistic.

  • Statistics are calculated - this means the data from we are looking at, the time series of values for example in a project are used in a calculation
  • Parameters are estimated - a parameters from these numbers is then¬†estimated from the time series. This estimate has a confidence interval. From this estimate we can make inferences. ¬†

One issue in inference making - estimating - is sample size determination. How large of a sample do we  to make an accurate estimation? This is why small sample sizes produce very unreliable inferences. For example sampling 27 stories in an agile project and making in inference about how the remaining stories are going to behave is Very sporty business.

To have a good estimator, that is to make good estimates from sampled or simulated data the estimator must be:

  • Unbiased - the expected value of the estimator must be equal to the mean of the parameter
  • Consistent - the value of the estimator approaches the value of the parameter as the sample size increases
  • Relatively Efficient - the estimator has the smallest variance of all estimators which could be used.

The Confidence Interval

The point estimate differs from the population parameter due to the sampling error, since there is no way to know who close it is to the actual parameter. Because of this, statisticians give an interval estimate as a range of values used to estimate the parameter.

What's the cost of this project going to be when we're done with all our efforts, given we done some work so far?

The confidence interval is an interval estimate with a specific level of confidence. A level of confidence is the probability that the interval estimate will contain the parameter. The level of confidence is 1 ‚ÄĒ őĪ. Where 1‚ÄĒ őĪ ¬†area lies within the confidence interval.¬†The maximum error of the estimate, E,¬†is ¬Ĺ the width of the confidence interval.

The  confidence interval for a symmetric distribution is the point estimate minus the maximum error of the estimate is less than the true population parameter which is less than the point estimate plus the maximum error of the estimate.

An Example from Actual Observations

While staying at the Yellowstone Lodge during the Millennium (year 2000), our kids got sick with some type of flu going around the lodge. My wife lay in bed, tending them all night long and passed the time recording data about Old Faithful erupting outside our bedroom window. 

The data looked something like this:

        Eruptions Waiting 
1     3.600      79 
2     1.800      54 
3     3.333      74 
4     2.283      62 
5     4.533      85 
6     2.883      55

Eruptions is the duration of the eruption of Old Faithful and Waiting is the waiting time before the next eruption. There is a correlation between these pieces of data. This is due to the physical processes of expelling water at high temperature and the refilling processes of the caverns below the surface

Screen Shot 2015-02-02 at 6.35.16 PM

 If we use R as our analysis tool, we can get a sense of what is happening statistically with Old Faithful. (R code below)

> attach(faithful)     # attach the data frame 
> eruption.lm = lm(eruptions ~ waiting)

Then we create a new data frame that set the waiting time value.

> newdata = data.frame(waiting=80)

We now apply the predict function and set the predictor variable in the newdata argument. We also set the interval type as "confidence", and use the default 0.95 confidence level.

> predict(eruption.lm, newdata, interval="confidence") 
     fit    lwr    upr 
1 4.1762 4.1048 4.2476 
> detach(faithful)     # clean up   We can see there is 95% confidence interval of the mean eruption duration for the waiting time of 80 minutes is between 4.1048 and 4.2476 minutes.   Now to a Project Example In the graph below the black line to the left is the historical data from a parameter I want to estimate from it's past value. But I need an 80% confidence and a 95% confidence interval for the customer as to what values this parameter will take on in the future. We can see from the Time Series of the past value both the 80% confidence and the 95% confidence bands for the possible value the parameter can take on the future.


What Does The Mean?

It means two things:

  • When we say we have an 80% confidence that a parameter will assume to value, we need to know how that parameter behaved in the past.
  • When we hear that we are estimating the future from the past, we¬†MUST¬†know about the behaviours of those past values, the size of the population, and the same size, before we can determine the confidence in the possible future outcomes. Have an Average Value without this data is prettu much useless in our decision making process.

What Does This Really Mean?

Anyone suggesting we can make decisions about future outcomes in the presence of uncertainty and at the same time in the absence of estimating those outcomes is pretty much clueless about basic probability and statistics random processes. 

Since all project variables - the statistical parameters - are random variables, driven by underlying process that we must estimate using statistical process available in R and our High School Stats book.


When it is mentioned I use bayesian statistics, or I use Real Options, ask if they are using something like the R Tutorial Resource with Bayesian Statistics. And of course the source code for the statistical processes described above. Then ask to see their data. There seems to be a lot of people tossing around words, like Bayesian, Real Options, Monte Carlo, and other buzz words without actually being able to show their work or the result that an be tested outside their personal ancedotes. Sad but true.

Related articles Taxonomy of Logical Fallacies Building a Credible Performance Measurement Baseline Late Start = Late Finish
Categories: Project Management

Sticking to our Guns

Software Requirements Blog - - Tue, 02/03/2015 - 16:00
I’ve been working on a program that has certain been a challenge, both from the subject matter, the extremely short timeframes given (imposed governmental regulations that must be met), to the stakeholders (who have day jobs to perform as well). Everyone is under pressure, which can make for some short fuses as well as poor […]
Categories: Requirements

Thoughts on Estimation

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

Ron Jeffries has a new book out, "The Nature of Software Development". I highly recommend everyone read it--in fact, Ron is one of the few people whose every word I recommend people read. I love how he always gives me something to think about. I don't always agree with him--but that's why I like reading what he has to say. If I always agreed, I'd never learn anything and there'd be no point in that.

To celebrate Ron's new book, I asked him to write a guest post for us, which I'm happy to share below. I know you'll enjoy it. Be sure to check out his offer to win one of the great drawings from the book! --Mike


My new book, The Nature of Software Development, will hit the streets in final form any minute now. The book is "long-awaited", at least by me, as it has been percolating in my mind and computer for years. In Nature, I try to share my view that under all the complications and complexity of software development, there is an essential simplicity. I believe that if we keep that simplicity in mind, we can find our way out of the twisty little passages that make up the software business. The pictures in this article are taken from the book. It's full of pictures, hand-drawn by the author (that's me), in the manner of a chalk-talk or illustrated keynote talk.

Did I say "final form"? How silly of me. For example, Nature talks about estimation in its chapter on planning, and elsewhere, including a bonus chapter on the "Five-Card Method" of quickly getting a handle on the scope of the project. But the topic of estimation rages on, and my thinking continues to change, not in direction so much as in refined understanding. I've probably published four or five articles on estimation since the book was finished, and here come some more thoughts for you.

Large Scale: Budgeting over estimation

At the overall project level, I favor a quick estimate if you must, and prefer a budget. Not a multi-million dollar ten year budget but a week, a month, maybe three months for a small team to get a real handle on what the product is and how long it will take until we can have something of use.

We build high-value items first, and continue that so long as the product shows itself to be worth investing in. If we need faster progress, maybe we add people, or even teams. Let's move into the unknown with exploration, not with a huge commitment that may be misplaced.

Small Scale: Maybe no estimates at all

Starting a large project with a small one is controversial enough. At the level of the next few weeks' work, the Scrum Sprint, I have begun to recommend against estimating stories at all, be it in points, hours, or gummi bears.







As Eisenhower said, "Plans are useless, but planning is essential." It's commonly believed that a key part of planning a Sprint is to have estimates for all the backlog items, and the Scrum Guide even tells us that we should track our performance against those estimates.

We might drop or defer a story

One possible advantage of this is that the Product Owner might decide differently what to do if something is going to cost four days instead of two. It could happen: I've seen it happen. In the case I saw, the team scribbled estimates beside stories on the white board, and erased them at the end of the meeting. They found it useful to decide how much work to take on, and at least once, their Product Owner withdrew a story because it was a couple of days more costly than she thought.

This might happen, and it might even happen often enough to matter. Still, I've only seen it once. Even so, if we're doing Scrum as we're supposed to, the stories are in priority order, we forecast how many we can take on, and we work through them. That works so nearly perfectly that the estimates at the Sprint level are generally wasteful.

Estimates will make us learn about the story

Another often-quoted value to small-scale estimates is that it causes the developers to learn enough about the story to really understand it, resulting in better implementations, fewer mistakes, and so on. Yes, it's true that if you will actually think about what's being asked for, you'll do better. It's not clear that estimates are an ideal way to do that.

That said, someone pointed out a value to doing Planning Poker: it quickly identifies stories on which there is mixed understanding, and it provides a ritual where someone who might otherwise be quiet has an occasion to speak. That could be useful. Like my friends with the white board, you might want to consider throwing away any estimates that come out.

Commonly misused

More pernicious -- I used that word in Nature, a copy editor suggested that I change it, and I refused -- is the common practice of comparing estimates to actual "so we can improve our estimates". Hello!?!? How about we improve almost anything rather than estimates? The cleanness of our code, the coordination among our team, the communication between Product Owner and developers? Surely there's something more important to do than focus on the cost of things and guessing the cost correctly. Maybe we could focus on the value?

Value rather than cost






In Nature, I take the position that "Value is what you want," and I mean that literally. Maybe you want revenue. Maybe your product saves lives. Maybe it organizes meetings. Whatever the point of your product is, it is almost certainly not "let's make our actuals match our estimates".

As the picture above suggests, backlog items offer various levels of value, and come with varying costs. What the picture does not show is that value had better be many times larger than cost, or the feature isn't worth doing. If that picture were drawn to scale, the cost dimension would be so narrow we could hardly see it. The picture shows us that what matters most is building high-value items first. Almost any other consideration is far secondary to that one.

I could go on. In fact I have gone on. Beyond the estimation topics discussed in *Nature*, which are just a tiny part of a small book, I've already published quite a few more detailed articles about the topic. And I need your help.

Valuable prizes. Well, prizes.

I certainly hope you'll read, enjoy, and promote Nature. But I have another little proposal in mind for you here.

I'd like to write a few more articles about estimation, mostly about how to get rid of it, but also about what it's good for and how to do it well, if I can find out. To do that, I'd like to hear from you on topics like these:

  • Where have small-scale estimates actually been useful to your team?
  • What have you done to get rid of estimates if you found them troublesome?
  • If management insisted on estimates, how have you been successful in turning that around?

Write me an email at ronjeffries at acm dot org, telling me a bit about your discoveries.

I'll pick at least two emails and dig into them, maybe more. Probably we'll exchange a few notes or talk on the phone. Maybe you'll write an article for my web site or your own. I'll certainly write about your ideas on

Wait, don't answer yet!

If I use your idea, I'll send you a signed print of one of the drawings from the book, printed on the very best paper that will go into my printer. Your choice of drawing if you wish, or I'll pick one.

In addition, I'll draw an equal number of entries randomly. If I use two emails for articles, two more random pictures. If three, three. And so on.

As you'll see when you read the book -- and I hope you do -- these pictures are suitable for framing and for display in any small dark room in your house, such as a closet or pantry. And quite likely, if your cat is like mine, your cat will sit on the drawing if you put it on the floor.

What a fantastic opportunity! Let's see if we can begin to build a community understanding of when estimates are good and when they aren't, and how to work with them, and to work without them.

Oh, and do please consider getting a copy of the book. The pictures are in color, so you might prefer the paper version, or to read it on your color e-reader.


Marco Arment Uses Go Instead of PHP and Saves Money by Cutting the Number of Servers in Half

On the excellent Accidental Tech Podcast there's a running conversation about Marco Arment's (Tumblr, Instapaper) switch to Go, from a much loved PHP, to implement feed crawling for Overcast, his popular podcasting app for the iPhone.

In Episode 101 (at about 1:10) Marco said he halved the number of servers used for crawling feeds by switching to Go. The total savings was a few hundred dollars a month in server costs.

Why? Feed crawling requires lots of parallel networking requests and PHP is bad at that sort of thing, while Go is good at it. 

Amazingly, Marco wrote an article on how much Overcast earned in 2014. It earned $164,000 after Apple's 30%, but before other expenses. At this revenue level the savings, while not huge in absolute terms given the traffic of some other products Marco has worked on, was a good return on programming effort. 

How much effort? It took about two months to rewrite and debug the feed crawlers. In addition, lots of supporting infrastructure that tied into the crawling system had to be created, like the logging infrastructure, the infrastructure that says when a feed was last crawled, monitoring delays, knowing if there's queue congestion, and forcing a feed to be crawled immediately.

So while the development costs were high up front, as Overcast grows the savings will also grow over time as efficient code on fast servers can absorb more load without spinning up more servers.

Lots of good lessons here, especially for the lone developer:

Categories: Architecture

Why I’m Not Writing a Blog Post This Week

Making the Complex Simple - John Sonmez - Mon, 02/02/2015 - 17:00

Just a minute ago my wife walked into my office and busted me. It’s Saturday, around 4:40 PM and I’ve been in my office “writing a blog post” for the last 3 or 4 hours. It’s not like I didn’t get anything done. I responded to like 50 emails, and I shipped out some signed copies of my “Soft Skills” ... Read More

The post Why I’m Not Writing a Blog Post This Week appeared first on Simple Programmer.

Categories: Programming

You Need Feature Teams to Produce Features

Many organizations create teams by their architectural part: front end, back end, middleware. That may have worked back in the waterfall days. It doesn’t work well when you want to implement by feature. (For better images, see¬†Managing the Stream of Features in an Agile Program.)

Pierce Wetter wrote this great article on LinkedIn, There is no “front end” or “back end.”¬†Notice how he says, referring to the yin/yang picture,

Your product isn’t just the white part or the black part above. It’s the whole circle.

That has implications for how you structure your teams.

If you have front end, back end, or middleware teams, you lose the holistic way of looking at features. You can’t produce features—you produce components, parts of features that work across the architecture. Even if everyone does their job perfectly, they still have to knit those pieces together to create features. Too often, the testers find the problems that prevent features.

Instead, you want a product development team, a feature team. That team has someone from the back end, someone from the front end, someone from middleware, and a tester, at minimum. Your team may have more people, but you need those people to be able to create a feature.

You might call these teams product development teams, because they produce product chunks. You can call them feature teams because they can create features.

Whatever you call them, make sure—regardless of your life cycle—that you have feature teams. You can have feature teams in any approach: serial, iterative, incremental, or agile. What differentiates these teams from functional or component teams is that feature teams can produce features.

Features are what you offer to your customers. Doesn’t it make sense that you have teams that create features?


Categories: Project Management

How to make the sprint review meeting worth your while

Xebia Blog - Mon, 02/02/2015 - 16:44

My work allows me to meet a lot of different people, who actively pursue Scrum. Some of them question the value of doing a sprint review meeting at the end of every sprint. Stakeholders presumably do not ‚Äúuse‚ÄĚ nor ‚Äúsee‚ÄĚ their work directly, or the iterated product is not yet releasable.

Looks like this Scrum ritual is not suited for all. If you are a person questioning the value of a demo, then focus on your stakeholders and start to demo the delta instead of just your product. Here is a 3-step plan to make your sprint reviews worth your while.

Step 1: Provide context

Stakeholders are not interested in individual user stories. They want to see releasable working software they can use and work with. That is were the value delta is for them; in practical services and products they can use to make their lives a little bit better than before.
So the thing you should do in the sprint review is to explain the completed stories in the context of the iteration and how this iteration will add value to the upcoming product-release. Providing the context will make it easier for stakeholders to give your team the feedback it is looking for.

Step 2: Demo the delta

Search for the abstraction level on which the user is impacted by the story you have completed, even if this means combining stories to demo as a whole. This is especially useful if you are working in component-based teams.

It will enable you to explicitly illustrate the added value from a stakeholder perspective after the change. It’s not just about adding an input screen or expansion of variables. It’s about being able to do something different as a stakeholder.

Think about the possibilities given the new additions to the system. Maybe people can be more effective or more efficient saving time, money and energy. If possible try to explicitly show the effect of the delta on the stakeholder, for instance by measuring key variables in the before and after situation. Seeing the explicit effect of the changes will get your stakeholders fired up to provide your team with additional ideas and feedback for your next release.

Step 3: Ask for feedback

The goal of the sprint review is to generate feedback. Often, this won‚Äôt happen automatically and means you have to explicitly ask for it. Doing it wrong is to do the review without interruption and to conclude by asking: ‚Äúany questions?‚ÄĚ This will certainly not evoke people to participate in a group discussion as posing questions is, unfortunately, still seen by many as a sign of weakness.

To counter this group dynamic, you should be the one asking the questions to your audience. Example stakeholder focused questions to generate feedback might be; ‚Äúwhat are your thoughts on improving this feature further?‚ÄĚ Or ‚ÄúHow would this fit in your day-to-day routine?‚ÄĚ

By doing so, you will lower the barrier for others to start asking questions themselves. Another tip to turn around the question dynamic is to specifically target your question to a single stakeholder, getting the group out of the conversation.

Up until now these steps helped me a lot in improving my sprint review meetings. These 3 simple steps will let your key-stakeholders be the subject of your review meeting, maximizing the chance that they will provide you with valuable feedback to improve your product.

Sources for Reference Class Forecasting

Herding Cats - Glen Alleman - Mon, 02/02/2015 - 16:19

Reference Class Forecasting is a useful source of data for making estimates in a variety of domains.

And some databases used for RCF

Then there are tools for parametric estimating

A sample of the nearly endless materials on how to apply Reference Class Forecasting

Screen Shot 2015-02-01 at 12.24.18 PM

So when you here we can't possibly estimate this piece of software. It's never been done before. Look around a bit to see if Someone has done it, then look so more, maybe they have a source for a Reference Class you can use. 

Related articles Good Project and Bad Project Building a Credible Performance Measurement Baseline Your Project Needs a Budget and Other Things We Suck At Estimating
Categories: Project Management

How to Define Your Target Audience… with Questions

NOOP.NL - Jurgen Appelo - Mon, 02/02/2015 - 16:16

“Can our organization be a little bit more like Pixar, Spotify, Netflix, Zappos, Virgin, Valve or IDEO? Is there something I can do to get a better company culture? Better collaboration? Better management?”

There is a reason why I started the book description of my #Workout book on Amazon with this question. For me, it defines the target audience of the book.

The post How to Define Your Target Audience… with Questions appeared first on NOOP.NL.

Categories: Project Management

I'm speaking at the O'Reilly Software Architecture Conference

Coding the Architecture - Simon Brown - Mon, 02/02/2015 - 13:19

I'm thrilled to say that I'll be speaking at the inaugural O'Reilly Software Architecture Conference in Boston during March. The title of my session is Software architecture vs code and I'll be speaking about the conflict between software architecture and code. This is a 90-minute session, so I look forward to also discussing how can we solve this issue. Here's the abstract...

Software architecture and coding are often seen as mutually exclusive disciplines, despite us referring to higher level abstractions when we talk about our software. You've probably heard others on your team talking about components, services and layers rather than objects when they're having discussions. Take a look at the codebase though. Can you clearly see these abstractions or does the code reflect some other structure? If so, why is there no clear mapping between the architecture and the code? Why do those architecture diagrams that you have on the wall say one thing whereas your code says another? In fact, why is it so hard to automatically generate a decent architecture diagram from an existing codebase? Join us to explore this topic further.

Software Architecture Conference 2015

You can register with code FRIEND20 for a discount. See you there!

Categories: Architecture

The Great Leadership Quotes Collection Revamped

A while back I put together a comprehensive collection of leadership quotes.   It‚Äôs a combination of the wisdom of the ages + modern sages.   It was time for a revamp.  Here it is:

The Great Leadership Quotes Collection

It's a serious collection of leadership quotes and includes lessons from the likes of John Maxwell, Jim Rohn, Lao Tzu, Ralph Waldo Emerson, and more.

Leadership is Influence

John Maxwell said it best when he defined leadership as influence.  Tom Peters added a powerful twist to leadership when he said that leadership is not about creating followers‚ÄĒit‚Äôs about creating more leaders.

I like to think of leadership in terms of incremental spheres of influence starting with personal or self-leadership, followed by team leadership, followed by organizational leadership, etc.   Effectively, you can expand your sphere of influence, but none of it really works, if you can‚Äôt lead yourself first.

Leadership is Multi-Faceted (Just Like You)

I also like to think about the various aspects of leadership, such as Courage, Challenges, Character, Communication, Connection, Conviction, Credibility, Encouragement, Failure, Fear, Heart, Influence, Inspiration, Learning, Self-Leadership, Servant-Leadership, Teamwork, and Vision.  As such, I‚Äôve used these categories to help put the leadership quotes into a meaningful collection with simple themes.

I‚Äôve also included special sections on What is Leadership, Leadership Defined, and Leading by Example. 

Sometimes the Source is More Interesting than the Punch line

While I haven‚Äôt counted the leadership quotes, there are a lot.   But they are well-organized and easy to scan.   You‚Äôll notice how the names of famous people that said the leadership quote will pop out at you.  I bolded the names for extra impact and to help you quickly jump to interesting people, to see what they have to say about the art and science of leadership.

I bet you can find at least three leadership quotes that you can use on a daily basis to think a little better, feel a little better, or do a little better.

Leadership is Everyone’s Job

For those of you that think that leadership is something that other people do, or something that gets done to you, or that leadership is a position, I’ll share the words of John Maxwell on this topic:

‚ÄúA great leader‚Äôs courage to fulfill his vision comes from passion, not position.‚ÄĚ ‚ÄĒ  John Maxwell

In fact, if you’ve never seen it before or need a quick reminder that everyone is a leader, this is a great video that makes the point hit home:

Everyone is a Leader

It’s one of those cool, simple, cartoon videos that shows how leadership is everyone’s job and that without that philosophy, people, systems, organizations, etc. all fail.

The world moves too fast and things change too much to wait for somebody at the top to tell you what to do.   The closer you are to where the action is, the more context you have, and the more insight you can use to make better decisions and get better results.

Leadership is a body of principles, patterns, and practices that you can use to empower yourself, and others, with skill.

Just like a Jedi, your force gets stronger the more you use it.

If You Want to Grow Your Leadership, Then Give Your Power Away

But always remember the surprise about leadership ‚Äď the more you give your power away, the more power that comes back to you.

It‚Äôs not Karma.  It‚Äôs caring.  And it‚Äôs contagious.

(As Brian Tracy would say, the three C’s of leadership are Consideration,Caring,and Courtesy.)

Well, maybe it is like Karma in that what goes around, comes around, and leadership amplifies when you share it with people and help everyone become all that they are capable of.

Stand strong when tested, and lead yourself from the inside out.

You Might Also Like

347 Personal Effectiveness Articles to Help You Change Your Game

Happiness Quotes Revamped

Habits, Dreams, and Goals

Interview with The Entrepreneur’s Library on Getting Results the Agile Way

My Story of Personal Transformation

Categories: Architecture, Programming

Start with Problem, Than Suggest The Solution - Part Deux

Herding Cats - Glen Alleman - Mon, 02/02/2015 - 03:44

A metaphor in agile development of building a transportation device in the picture below. There were a few tweets about stretching the metaphor, or my favorite of course you could build a car, if that's what you wanted.

If You Don't Know What Done Looks Like in Units of Measure Meaningful to the Decision Makers, You're On a Death March Project To Nowhere

Starting a project without the end in mind has been a bad idea for a long time

Suppose one of you wants to build a tower. Will he not first sit down and estimate the cost to see if he has enough money to complete it? For if he lays the foundation and is not able to finish it, everyone who sees it will ridicule him saying, "This fellow began to build and was not able to finish." - Luke 14:28-30

The logic of the picture goes like this:

  • In the end I want a Panel Van to deliver groceries for my door-to-door organics company.
  • I want vehicle ¬†for a purpose, to provide a capability to do something that fulfills a need or a mission, to conduct my business.
  • I've defined the need, capability, or mission up front - I ¬†know what I want to do with the outcome - I want to deliver groceries.
  • I have some idea of why I need this vehicle, what value I will receive from it, and some sense of how much I'm willing to pay to receive this value. Since my ROI for the vehicle is is simple.
    • ROI = (Value - Cost) / Cost

In the agile example below - the Like this! panel makes none of these examples

  • I don't really know what I want, otherwise I wouldn't be willing to pay for something that doesn't meet my needs.
  • I can't use a skateboard, a scooter, a bicycle, and a motorcycle to accomplish my mission. I need a Panel Van.

So when it is suggested that the second path to the car (the bottom picture) is the way to produce a capability - in the absence of a domain and a context of that domain, I'd suggest

This is a Solution Looking for a Problem to Solve

In that condition there are not many people willing to spend money for vehicles they're not interested in using for their final purpose. And simply saying not this, but this has little value to someone needed to Panel Van and without the Panel Van, can't do their business. So it's going to be hard to get a seat at the table until the connection with the Needed Capabilities, fulfilling the business case, or accomplishing the mission are the starting point, rather than the suggested solution. 

Agile evolution

In the bottom picture, if those outcomes can't be used, re-used, or resold, the Car in #5 is then burdened with a unrecoverable sunk cost of all the vehicles that come before it. This rarely seems to be discussed in the agile paradigm where this picture is common. 

Not Knowing What You Want - in terms of a Capability - is a good way to waste money

Imagine a Toyota production line where the assembly of the car takes place incrementally. The car dealer sells you the car AFTER it comes off the assembly line. You'd not want to pay for a partially completed car. You want a Whole car. A car that meets your needs. In the bottom picture you may in fact want to own the skateboard, scooter, bicycle, motorcycle and then the car. We have a garage full of skateboards, scooters, bicycles, no motorcycle, a 4 cars. But those vehicles, each with a purpose, a cost and a value. 


Related articles Your Project Needs a Budget and Other Things Building the Perfect Schedule
Categories: Project Management

SPaMCAST 327 ‚Äď Stand-up Meetings, Architecture, Communication Objectives


Listen to the Software Process and Measurement Cast

Subscribe to the Software Process and Measurement Cast on ITunes

This week’s Software Process and Measurement Cast features our essay on the ubiquitous stand-up meeting. The stand-up meeting has become a feature of Agile and non-Agile project alike. The technique can be a powerful force to improve team effectiveness and cohesion, or it a can really make a mess out of things! We explore how to get more of the former and less of the later

We also have a new Form Follows Function¬†column from Gene Hughson. This column is the second of a three column arc on micro-services and architecture.¬† This installment is titled ‚ÄúWho Needs Architects? ‚Äď Navigating the¬†Fractals.‚ÄĚ Check out Gene‚Äôs blog at Form Follows Function.

We also continue with Jo Ann Sweeney’s column Explaining Communication. In this installment Jo Ann addresses communication objectives and why setting and understanding those objectives BEFORE you start the communication process is a big deal if you are interested in being effective! Visit Jo Ann’s website at and let her know what you think of her new column.

In the next Software Process and Measurement Cast we will feature our interview with Alex Papadimoulis. Alex is returning to the Software Process and Measurement Cast to discuss Release. Release is card game about making software inspired by development strategies like Lean, Agile, and DevOps, and classic trick -taking card games. We also circled back to talk about continuous delivery and DevOps; a bit of lagniappe to add to a great interview.

Call to action!
We are just completed a re-read John Kotter’s classic Leading Change on the Software Process and Measurement Blog ( and are in process of choosing the next book for Re-read Saturday. Please go to the poll and cast your vote by February 15!

Vote now at Software Process and Measurement Blog!

Shameless Ad for my book!
Mastering Software Project Management: Best Practices, Tools and Techniques¬†as¬†co-authored by Murali Chematuri and myself and published by J. Ross Publishing. We have received unsolicited reviews like the following: ‚ÄúThis book will prove that software projects should not be a tedious process, neither for you or your team.‚ÄĚ Support SPaMCAST by buying the book¬†here.

Available in English and Chinese.

Categories: Process Management

SPaMCAST 327 ‚Äď Stand-up Meetings, Architecture, Communication Objectives

Software Process and Measurement Cast - Sun, 02/01/2015 - 23:00

This week’s Software Process and Measurement Cast features our essay on the ubiquitous stand-up meeting. The stand-up meeting has become a feature of Agile and non-Agile project alike. The technique can be a powerful force to improve team effectiveness and cohesion, or it a can really make a mess out of things! We explore how to get more of the former and less of the later

We also have a new Form Follows Function column from Gene Hughson. This column is the second of a three column arc on micro-services and architecture.  This installment is titled “Who Needs Architects? – Navigating the Fractals.” Check out Gene’s blog at Form Follows Function.

We also continue with Jo Ann Sweeney’s column Explaining Communication. In this installment Jo Ann addresses communication objectives and why setting and understanding those objectives BEFORE you start the communication process is a big deal if you are interested in being effective! Visit Jo Ann’s website at and let her know what you think of her new column.

In the next Software Process and Measurement Cast we will feature our interview with Alex Papadimoulis. Alex is returning to the Software Process and Measurement Cast to discuss Release. Release is card game about making software inspired by development strategies like Lean, Agile, and DevOps, and classic trick -taking card games. We also circled back to talk about continuous delivery and DevOps; a bit of lagniappe to add to a great interview.

Call to action! 
We are just completed a re-read John Kotter’s classic Leading Change on the Software Process and Measurement Blog ( and are in process of choosing the next book for Re-read Saturday. Please go to the poll and cast your vote by February 15! 

Vote now at Software Process and Measurement Blog!

Shameless Ad for my book!
Mastering Software Project Management: Best Practices, Tools and Techniques as co-authored by Murali Chematuri and myself and published by J. Ross Publishing. We have received unsolicited reviews like the following: “This book will prove that software projects should not be a tedious process, neither for you or your team.” Support SPaMCAST by buying the book here.

Available in English and Chinese.

Categories: Process Management