Are We Done Yet?

Recently, there has a been a bit of talk about being done in the context of Agile software development.  If I’m not mistaken, as far as Agile frameworks go, it would seem that the Definition of Done as described by Scrum influences many an Agile team. We also know that there are variations on this as well such Done-Done and Done-Done-Done.

But when are we really DONE?

In some regard this depends on how we define done.  Is a movie done when production is over?  Is a presentation done when the slide deck has been prepared?  Is a meal done once it has been cooked?  Is a software increment done when coding and testing are complete?

Teams engaged in real (there is a lot of fake and dark Agile out there) Agile software development are guided by a set of 4 values and 12 principles.  The very first principle in the Agile Manifesto goes as follows:

Our highest priority is to satisfy the customer through early and continuous delivery of valuable software

When we use this principle to guide how we define done, I cannot understand how we can consider ourselves done until we’ve delivered an increment of value to our customers. Not just deployed (and hidden behind feature toggles or something like that) but delivered such that our customers can interact with the increment in some form or fashion.

So the next time your team debates whether you are done, ask yourselves if your customers are using the increment.

(Thanks to Mia Augustine for inspiring this post).

P.S. IMHO Scrum’s Definition of Done (in the best case scenario) is really (more appropriately named) Definition of Ready To Be Delivered.


Unfinished Bridges

This post is a followup to my tweet on possibly scrapping projects.  This post is particularly aimed at those who want to engage a team in software development project work for them.  It may also be of value to those who do the work.

What is a project?  According to the PMI website, this is what we find:

It’s a temporary group activity designed to produce a unique product, service or result.

A project is temporary in that it has a defined beginning and end in time, and therefore defined scope and resources.

And a project is unique in that it is not a routine operation, but a specific set of operations designed to accomplish a singular goal.

I want to focus on the “temporary” and “defined scope” part of the definition as I believe this to be center to the conversation.  Scope is the amount of work/features/functions/etc that we agree need to be completed in order for the project to be done.  Fixing the scope inherently makes the project temporary as at some point, the scope is met and the project ends.  In non-product development disciplines, the defined scope most often equates to what is required for the item to be usable.  On the surface, this seems simple and straightforward enough but its important to note that in these disciplines, usable very often also means finished.   For example, the scope defined for building a bridge would include the fact that bridge is usable (it can convey people from point A to point B) and to be usable, its needs to be finished .  By and large, very little to no additional work will be done towards its original purpose.  The product is not finished until the project is finished.  There is no use for unfinished bridges except for pretty pictures.  unfinished_bridge

This behavior does not necessarily hold to form in software development.  In fact, (largely) unfinished software is used every day in many spheres of life and we have no problem with it at all.  Think of all the software you use, personal or commercial and all the updates you or others make to it.  It doesn’t matter whether its some application you created to help automate some personal activity or business software that you are involved with.  It doesn’t matter whether its software for internal use or to be distributed to a mass market.  Software evolves and evolves quite rapidly. We are continually adding stuff.  The only time it doesn’t is if its a class assignment or the software is no longer being used.

Why does it evolve so quickly and often?  It evolves because in spite of our skill and adeptness, we can only see so far into to the future as to anticipate our needs.  Even when we enumerate all the user stories (if that’s what you do), we still end up discovering as we go along. Software development is by and large an exercise in discovery.  It is critical to gain a true appreciation of the nature of work one engages in to fully exploit it.  In addition, the software development tools available to us allow us to make changes to our systems faster than we’ve ever been able to and this only going to improve as time and technology progresses.  Unfortunately, we still rely on (industrial age) methods that predate software development to manage how we actually do the work.

So why does this matter to you dear client?  Because I believe that you shouldn’t be ignorant when working with those in my profession.  You can decide to kick-off a project with some defined scope upfront and then lock it in but we’ll charge you for every change request you submit, tell you “it’s out of scope” or pull something out to put what you want in.  When we’re done, you’ll have a product that is usable but unfinished because you’ll realize that there were things that you missed that you now want that may be even more important than what you have.  Those of us who have done this for a while knew this would be the case, but you wanted a project didn’t you. Because you are human you are going to feel unsatisfied  and disappointed but we’ll remind you that this is a project and that you (not us) determined (fixed) the scope.  Because you really need those features, you’ll decide to kick off another project with us.  You’ll make subtle changes to the contract with us to protect yourself and the cycle will just repeat itself.  The cycle will most likely repeat itself a couple of times.  I  hope it doesn’t lead to low-trust and a contentious relationship between us but in many cases it does.  But hey,  you decided you wanted a project.

On the other hand, you can decide to break out of the project mold and just decide that you are going to continuously invest in your product until it no longer makes sense for you to do so.  We’ll work together as partners to identify what capabilities are needed first.  We’ll develop and deliver those.  Then we’ll identify what’s next and repeat the same process.  We’ll change priorities as we go because we didn’t lock ourselves into a plan that no longer makes sense.  We won’t waste time arguing about fixed scope, we’ll just get things done.  We won’t spend hours having our lawyers review the contracts so that no one feels cheated.  We’re in this together and for the long haul. You’ll still have usable unfinished product(s) as we go along but I think you’ll feel differently about things, in fact my experience strongly suggests you will.  But hey, you decided not to do a project.

The choice is yours, I just want you know that you have options.  Choose wisely.

The trouble with estimates

Is that they are just that, estimates, and we can’t rely on them solely even when we have to use them.

Let me cut to the chase right way by stating two things upfront.

  1. I consider estimates to be measurements based on the work of Douglas Hubbard focused on reducing uncertainty.
  2. I consider the requests for estimate I largely encounter to be a complete waste of everyone’s time.  Sorry!

I blogged on the topic of estimation in the past but after a  conversation with my mother today, I couldn’t resist the urge to say a little more.

Mom is conducting research in Nigeria which requires a questionnaire to be distributed to 34 universities in 17 different states in the southern region of the country.  To do this, she contracted an individual to travel by road to these 34 universities, distribute the questionnaire and then collect the results.  This may seem a little odd to us in the Western world, but that’s how it is done back home.  Anywho, we had a short conversation (paraphrased) on how much this would cost.

Me: So how much are you going to have to pay this guy to do this running around

Mom: Not less than N150,000 (for my non-Nigeria friends that’s about $947). I have given him that already.

Me: (Silence)

Mom: It could get up to N400,000 ($2525) because he may have to go some universities multiple times

Me: (Ouch!)

(Travel in Nigeria can be extremely uncertain as fuel prices can skyrocket on a dime doubling the cost of transportation.  The means of transportation is not also reliable all the time.  Universities could go on strike causing this individual to have make a couple of trips that were never planned in the first place.)

Me: Lets have touch-points with him after every few universities to see what the expenses are looking like

Mom: Yes, that’s a good idea

Me: At least you’ll have a sense of the what the final bill might look like sooner than later

Mom: And you can get ready to pay for it sooner than later 🙂

Now I am pretty sure that we could have reduced uncertainty even further in much more sophisticated ways by really taking into consideration all the variables at play (see How To Measure Anything) here but I really didn’t want to pay to reduce uncertainty any further.

I should also point that the final bill will be presented, accepted and paid based primarily on trust.  There are not always official receipts that can be reviewed.  The trust discussion is for another day.

Sometimes we need estimates so we can plan and prepare accordingly.  How much effort we put into those estimates depends on how much uncertainty we need to reduce.  However, we must have feedback loops in the engagement that ensure that we can adjust based on how things are progressing.  I think this is one of the things my friends of the #NoEstimates movement continue to reiterate as its a staple value (principle) of both Agile and Lean development.

The Seduction of Problem Solving

In my last blog post, I tried to differentiate problem solving and problem dissolving.  This post continues to explore the differences.  Problem solving is sweet, seductive and addictive.  People experience a high when they solve problems.  It’s exhilarating to have a problem that has stumped everyone and then come up with solution.  Standard performance appraisals have a section where employees are rated on their ability to solve problems and employers reward employees that  score high in this area and penalize those who don’t.  Job opening descriptions list the ability to “solve problems” as a requisite for applying!

Once a pattern for solving a problem has been identified, it is reused over and over and over again.  Because we can solve the problem faster, we tell ourselves we’re getting better at solving the problem.  Our confidence rises and with it our level of cockiness.  We begin to dare the problem to show up again. (For its own good, it better not).

Allow me to tell a little story that illustrates this.  Recently, I worked with a team that had problem where user could no longer see some information.  After some analysis, they identified what they needed to do to make the information available again.  They had no idea why it had gone missing in the first place, but who cared?  They made the information available again and made it available quite quickly.  They had done it, they had solved the “missing user data” problem.

They then put a process in place to check if information was not available.  They prided themselves in the fact that they were being proactive about it; before the users identified the issue, they would.  They were sure that this would bode well in the annual performance appraisal exercise.  So for 6 months, they tried to stay ahead by identifying and fixing the problem before their users did.  As you can imagine, the results were mixed.  Sometimes they identified the issue first and other times they didn’t.  Additionally, the team didn’t like the fact that they had to monitor for this.  They just wanted to write software.  So someone came up with a brilliant idea, after all, they were software engineers.  Instead of manually monitoring for the existence of the problem, develop an automated process that (a) identifies the problem exists and (b) fixes it when it does.

Before they could get to developing the solution, they decided to have a conversation about the problem again.  The result of a one hour conversation was that a developer identified WHY data went missing and a couple of hours later, had made the necessary code changes that actually dissolved the problem.

Here is the kicker, they had spent over 6 months fixing the problem on a weekly basis but in a couple of hours they had dissolved the problem altogether.  Early on, they had decided that the problem was complex and would require much time to figure out so they were better off quickly solving the problem whenever it appeared.  There was no need to stop the presses and dissolve the problem.  They did not consider the cost of not determining what actually caused problem.  The cost of people checking the data daily, the cost of solving the problem, the cost of testing the solving, the cost of deploying the solution, the cost of having the end users look for their information.  It all added up.  Unfortunately, they can’t turn back the hands of time but they have learned a valuable lesson.

Buyer Beware: If you foster and develop a culture of problem solving, you are hurting your organization more than you probably realize.

Consider the ant

I just returned from visiting Nigeria for a week and half and as is the case with most trips, I end up stumbling on a couple of object lessons that I find useful and applicable.  I’ll try to share a few over the next couple of days.

Self-organization is a quality many teams talk about wanting to have yet our traditional organizational methods have created structures where people are always looking for someone else to provide direction on what to do.  Many times, teams are at a standstill until a single individual is available.  Dare I say, that is an unhealthy situation.

I had a valuable lesson shared with me while visiting home.  As I was walking (yes, we’re next door neighbors) from my house to my grandfathers house, I observed a colony of solider ants (ijere in my local dialect) in the middle of the path probably relocating from one home to another in a neat, well organized column.  Subconsciously, yet exhibiting (bad) habits developed as a child, I kicked the ground where the ants where and disrupted their column.  I chuckled about it as I recalled also doing that as a child and continued on my way to Papa’s and Mama’s home and gave no further thought to it.

A couple of hours later after visiting with them, I decided to go back home.  When I got to spot where the ants were, I noticed that they were back in order and moving along as if nothing had happened.  Now, this is something I’ve seen hundreds (maybe thousands) of times, but I stopped to think about how it is that they were back in order.  Without going deep into the study of ants, each other basically helps each other (as much as is possible) get back into line by leaving a scent (pheremone) that they each follow.  All the ants are dependent on each other.  There is total dependence and each ant is very important for the success of its fellow ant.


In order for self-organization to actually happen, members of a team should be dependent on each other and not just on one (or few) person(s).  This puts the team in the best position to respond to change in a dynamic and fluid manner.

Is your team self-organizing?  Consider the ant (but don’t get bitten!)

**Credit for picture goes to

Do Your Homework

This is just a reminder to myself and the readers of my blog that it is critical to understand the originating domain and context under which new advice/principles/practices being applied to software development came from.  Taking ideas that sound great on the surface and running with them can be catastrophic if those ideas are not well understood as they can easily be misapplied e.g. no testing as a reaction to “ceasing mass inspection” or the blind use of manufacturing principles in software development.  For those of us leveraging Scrum, have you read the original seminal paper on Scrum as a Product Development Game?

I’m not discouraging looking outside the field of software development for radical ideas as I don’t believe the field will evolve if we don’t do so.  Rather, I’m suggesting that we become more accountable in the application of these borrowed ideas.  Let’s understand that our domain is unique in its own way and grow it in a responsible manner.