There’s a problem with the way most companies, and technology companies in particular, are doing business.  It’s not a new problem and it’s a problem we thought we had already solved, but it turns out we didn’t.  The problem is getting things done on time.

Back in the day we were all about Gantt charts, milestones, timelines and waterfalls.  At around the time of the dot bomb (2000 ish) a new software development methodology was starting to garner broad adoption (actually by this time it had already been around for over a decade, it just took longer to gain momentum).  That approach was Agile Development, and came in a variety of flavors,  Scrum, Kanban, Extreme Programming etc.  Of these the Scrum approach has been arguably the most successful in terms of pure adoption.  The problem is that these methodologies, and particularly Scrum, rely on an ingredient that is missing from their recipe and without which things can end up tasting pretty bad.

Anyone who has implemented, or heard of an implementation of an agile methodology has likely heard something like, “we implemented Scrum but we changed it to suit our business”.  This is a clear signal that the missing ingredient is, well, missing.  This ingredient is so important that without it the decision to adopt Scrum, Kanban or any other agile methodology is not only pointless, it’s actually irrelevant.

This missing ingredient is a mental and philosophical shift that needs to take place across the entire organization.  It is a change in thinking more difficult, yet more important than almost any other change in modern professional life.  It is a change from thinking about companies and projects in terms of time, to thinking in terms of priority.

This is The Big Shift.

In a time-oriented world, things are done by a certain time or date.  “We will deliver X by date A, then we will deliver Y by date B”.  Or more specifically, expectations are set around time based variables.  In a priority driven world there are no times, only priorities.  “We will focus on delivering X before we focus on delivering Y”.

This is a subtle difference that typically sends many executives and CEOs into a tailspin as they try to wrap their heads around how the world can continue to function when there are no dates.  “How will be know when something will be done?”.  “What do we say to our stakeholders?”

And what’s the big deal anyway?  We have been working in a date-based world for a while now and it seems to be working.  But the problem is it’s not working.  Not nearly as well as it should. 

To understand the exact nature and severity of the problem we need to first understand why we have date-oriented expectations in the first place, and why they just don’t work. 

In many cases, particularly where any sort of engineering is concerned and with special reference to software engineering, milestone dates and very often bundled with a basket full of caveats.  “We’ll try to delivery X by date A but we may run into problems.”.  Then after the fact, “Well we tried to delivery but we had a problem”.  This happens all the time, and is not only completely valid but also in many cases is understood by both team members and team leaders on the project via various conversations and agreements that take place throughout the project.  The problem is that these caveats and reasons often don’t filter up to the highest level of stakeholders.  Executives, board members or any external stakeholder will most often be given a précis view of the plan and will simply see:

1. Planned to delivery X by date A

2. Failed to deliver X by date A

This is factually correct, but is missing the nuance and tonal qualities of what actually happened which tell a much more detailed and fair story.

The question that arises (or should arise) from this is, “why do we have that expectation in the first place?”.  In fact, this expectation [of time-based delivery] is actually fairly pointless.   The person/group for whom the expectation was set was either given the bundle of caveats which work to dilute the expectation (i.e. we think we will deliver on time but we could be wrong), or they were not given the caveats in which case they are doomed for disappointment.  In either situation setting any expectations based on time is somewhat futile, and more importantly will almost always lead to someone getting yelled at. 

Of course this does ignore the case where time based expectations are set, without any caveats, and always met.  I’ll leave it up to you to decide how realistic or otherwise this case is.

Aside from this logical paradox, there are two concrete reasons why time-oriented expectations will almost always fail.

1. Technical complexity leads to unpredictability

Technically complex endeavors are, by their nature, unpredictable.  The more complex the endeavor, the more unpredictable it is.  If every single possible outcome could be precalculated then one could say the outcome was predictable.  So it follows that the greater the complexity of the task, the greater the complexity required to predict its outcome.  At the ground level this means programmers aren’t clairvoyant.  They can’t tell you when something will be done by, no matter how many pizzas they eat, so if they do they’re almost certainly lying.

2. Focus is the invisible guide

Any engineering task will typically have a myriad of different implementation scenarios.  Given a single problem and 10 engineers it would not be unusual to see 10 different implementations.  This means that at any given point a single engineer is making a multitude of decisions about implementation that are not, and cannot be specified.  How does the engineer decide which approach is best?  Well this often depends on the engineer.  Some will value delivery speed over performance and will be able to solve the problem in a simple way very quickly, but their solution may not scale under load or may only satisfy a small subset of the ultimate use case.  Others will take great pride in their work and will not be happy until the problem is solved in the most elegant, scalable and reusable way, but won’t be able to deliver a solution in as short a time, and naturally there are some that sit in the middle of these two extremes.  This is the nature of the work and can’t (easily) be changed, but what process is each engineer using the decide their approach?  In a time-oriented world this will change based on the stage of the project.  In the early stages the engineers are motivated by elegant design, effective use of systems and tools and ensuring expectations around functionality are all considered.  Towards the end of the project, when the delivery date is looming, this all goes out the window and it becomes combo deal of slashing features, hacking together interim fixes and completely abandoning any testing regime in favor to meeting a date which was wrong from the beginning.  We’ve all seen it happen.

This is because the engineer is using a silent guide to help them make their decisions.  When deciding whether to consider for example the scalability of the component they are writing they will invariably ask themselves, “do I have time for that?”.  It all boils down to the simple fact that this is the wrong question.  The right questions is, “how important is this?”.

Now let’s look at things in the different light of a priority oriented world.  First, a few rules:

Rule #1

There are no dates.  Nope, none.  Get used to it.  This is almost universally met with a disconcerting combination of disbelief, distrust and ultimately confusion but fear not, there’s a very simple reason why dates just don’t matter.

Rule #2

I’m “borrowing” this one from some friends, “Trust enables success”.  The premise that underpins the entire system and without which it simple will not work, is trust.  The company must trust its employees to work diligently with integrity and with their best efforts.

Rule #3

There cannot be two “number one” priorities.  Think carefully about this.  Even though you think two things might be as important as each other, you can’t have both.  Pick one and move on.

The next question invariably is, “how do you possibly set expectations without dates?”, to which there is a very simple response,  you don’t because you can’t.  Setting an expectation on a date that is in the future is by definition a prediction.  We already know we can’t predict what will happen in projects of technical complexity.  Nor can we know ahead of time what roadblocks or changes in the environment may affect our ability to deliver, and anyone with any experience in software development will know that the landscape is always changing.  The universe is not static.  The only thing we can say with complete certainty is what we have already delivered, this is fixed in stone and something upon which we can always rely.   You will often hear comments like, “well you’ve done this a bunch of times before so you should know how long it takes.”  No.  The answer is no, we don’t.  Because every time is different, especially where technology is concerned.

Shifting mental focus to a world where priority, not time, is king leads us into an environment where project and company goals are more closely aligned, employees are happier and more productive and the overall quality of products is greatly improved.  Bold claims, but reasoned ones.

When an engineer is given a focus of priority as opposed to time not only are they no longer concerned about “running out of time” which leads to mistakes, shortcuts and general product “hackery”, but they now have a clear direction when faced with the inevitable question, “how should I implement this?”

Consider the following example:

A project is underway to build enhancements to an existing online ticketing system.  The project owner has decided (via several sessions with a crystal ball, Anthony Robbins cassettes and phone calls to their nephew) that the next feature to be developed should be “automated booking” (whatever that is).

In a time oriented world the engineers will be making hundreds of tiny decisions throughout the project which are all based, at some level, on a delivery date.  Beyond this they have no guidance as to how or what they should build.   The script for this is pretty easy to write:

Question: “Should I make this scalable?”

Answer: “Yes, because that’s good engineering, but only if you have time”

Question: “Should I make this easy to use?”

Answer: “Yes, because that’s good engineering, but only if you have time”

Question: “Should I make this available across multiple platforms?”

Answer: “Yes, because that’s good engineering, but only if you have time” 

We could go on all day, but it should be clear by now what is missing from this.  How does the engineer know which aspect of the product is more important?  They don’t, and thats why 10 different engineers will produce 10 different versions of a solution.  Because they all have their own priorities.

Now consider the same example in a priority driven world:

Consider that there are a range of features that have been proposed, but that it has become clear that the key problem identified by users is performance.  So the project owner has decided to make “performance” the priority.

Question: “Should I make this scalable?”

Answer: “Yes, because it directly impacts the goal of performance.”

Question: “Should I make this easy to use?”

Answer: “No, because it does not impact the goal of performance.” 

Question: “Should I make this available across multiple platforms?”

Answer: “No, because it does not impact the goal of performance.”

The engineer now has a clear direction and a clear understanding of how he/she should proceed.

Now this may seem like an overly simple scenario (because it is), but the message here is about a mental shift.  Once the shift to priority is made, everything else flows naturally.  How do we decide which features should be built next?  Consult the priority.  How do we know how the features should be built?  Consult the priority.  How do we know when the features will be built?  We don’t, but it’s our top priority.

There is a key premise in play here that needs to be stated, and the best way to put it is in the words of a former colleague of mine,

“Things will take as long as they take.  You can fool yourself into thinking they won’t, but they will” 

If we trust that the members of the team are all working diligently, to the best of their ability, then the above statement will hold true.  Things will take as long as they take and there is nothing that can be done to change this. 

Of course this has always been true, and the standard response to this is for project leaders to find “creative ways to incentivize their team to work harder”.  This means spending $20 on pizza and expecting the team to work long hours and late nights to finish the project on time.  In reality all this does is breed discontent within the team and lead to shoddy workmanship.  Nothing more.  A time based approach means working more hours on a less focused problem; it’s the worst of both worlds.

In a priority oriented world engineers produce higher quality results because they don’t have a sword of Damocles hanging over their head to deliver by a certain time which leads to “corner-cutting” and other hackery.  They are generally happier because they are not required to work ludicrous hours and they feel the company has faith in their ability to deliver.  And they are more productive because whenever they are faced with an implementation decision their direction is guided by an overriding understanding (and appreciation) of the higher level priorities.

But as a top level project owner, how do you know whether you should have faith and trust in the team?  How do you know whether the project is taking a long time because “that’s how long it takes” or because the team members are spending more time snowboarding than coding?  This is where the agile methodology really comes into its own and where it all starts to come together.

Agile methodologies like Scrum advocate “complexity” over time.  That is a “story” (feature) is given a complexity as a value on a numerical scale which is often non-linear (e.g. the Fibonacci series) which represents how difficult a story is to implement, and importantly is peer reviewed.  This means the complexity of a given story is less likely to be the opinion of one engineer (which is almost always going to be biased) and more importantly will reveal possible misunderstandings in the original story.  If one engineer gives a complexity of 1 (the simplest possible task) and another gives a complexity of 8, then we immediately know that there must be some level of misunderstanding about the story. 

At the end of a “sprint” the completed stories have their respective points tallied into an aggregate number known as the sprint “velocity”.  Generally speaking velocity is a measure of the amount of “work” being completed.  Importantly a negative change in velocity is usually an indication of some sort of problem or barrier within the team.  This can be thought of as an “early warning system” and is one of the reason that shorter cycle scrum methodologies can be beneficial.  Similarly a positive change in velocity might indicate that an attempt to remove a barrier was successful and ought to be replicated elsewhere. 

Although generally this velocity measure should not be used to gauge the performance of an individual team member (as this directly contradicts the premise of trust) it is particularly useful in tracking the output of teams, or the company as a whole.  Minor inconsistencies in complexity estimation are minimized by having a standard measure across teams and by the anti-fraud system inherited from a peer review process.

Perhaps the most important, and most often overlooked aspect of a priority oriented approach actually has nothing whatsoever to do with engineering, and everything to do with running a company.  This is about aligning goals.

During every month, quarter or year a company will have objectives that are guided by forces external to the people doing the actual work.  These are things like top line revenue and bottom line earnings, market position and differentiation or internal costs and efficiencies.  The great thing about a priority driven approach is that it permeates all parts of the business.  If the company has a priority to increase revenue (for example) then this priority can and should filter down to all people in all parts of the business.   Project owners can use this priority as a guide to deciding which stories or projects are delivered next (i.e. prioritize projects which increase top line revenue above others).  The outcome of this is that the activities of the business, and the goals of the business are aligned.

Things take as long as they take.  People work as fast as they work.  You can’t change this, but you can change how they work.  The ideal, optimal situation is one in which all members of the organization are spending their time on exactly what they should be and not spending any time on anything they shouldn’t be.  The “should” and “shouldn’t” here are directly translatable to priorities in a priority oriented world.

The final messages to anyone in a position to influence how things are done are this:

1. Abandon dates.  They just won’t work no matter how hard you push.

2. Trust your team.  Let them work however they want to work and they’ll repay you with high quality abundant output.

3. Report on the past, not the future.  Change the thinking from “we will deliver” to “we have delivered”.

Trust me.