Agile: It’s a War on Dates

Jan 15 2012

In a comment to my earlier article Thoughts on Kanban someone brought up the subject of end dates. Businesses obsess about the “When can we have it?” question. Dates and deadlines trump all. Let me tell you a secret: dates are bullshit. It is a prohibitive mentality in today’s world. Technology needs to reframe the question. Stakeholders need to change their engagement. No company ever succeeded because they made dates. Companies succeed when they continuously deliver innovation. It is not about the destination. It is about the journey and where you end up.

For agile to truly succeed the DNA of the company–top to bottom–must be continuous improvement through continuous delivery.

I Want Everything. Now.

A friend told me a story of a prioritization meeting he had with a stakeholder. After fleshing out seven distinct features with the dev team, the stakeholder was asked to prioritize. He walked up to the board, put a “1” next to everything, and walked out.

Really? Everything is a top priority? So you are saying you would rather have nothing than anything? Then what you want is worthless. You may think you need everything but you are showing your unwillingness to change or improve. People that cannot work through small changes definitely cannot deal with large ones.

Yes, long-term vision is important. It is the goal. It ensures that everyone heads in the right direction every step of the way. It helps people make reasonable decisions. But it is still long-term; it is just a vision of the future negating the small details that allow the day-to-day. It is painful, ridiculous and unnecessary to wait for the future to just “appear”.

Long term deliverables create impatient, anxious users. It creates large, unmanageable codebases, complex releases, excessive bugs. It disconnects original vision from delivered functionality. The cherry on the cake: it creates a confused user base making awkward and painful adjustments to radical new processes. There is no long-term goal that cannot be broken down and reached via small iterative releases. Baby steps. One at a time, together. It is a three-legged race for everyone.

The Devil Is In The Details.

This is the root cause of scope creep. Okay, we’re working on feature x, but can we do this? Can we do this? What about this? You tell me. Is it more important for you to do that or get what we have out? It is your call! When you look at the backlog is it more important to enhance the current feature or move to the next thing on the list?

We have daily scrums to answer the improve or move question. Get involved in the day-to-day. Transparency is king. If you don’t trust the person making the call then don’t let them make the call. Empower key people: it’s an organizational change which pushes agile forward.

Active engagement between stakeholders and developers is agile development. The less barriers between the two the better. Getting a common sub-conscience understanding of “what we are doing” is the key to success. Small companies align on vision easily. Large companies need to break up into teams and align on goals.

Deadlines Get Things Done

You want to know if this really complex thing you are asking for can be done in eight weeks? Can you spell out every possible detail, define every wireframe, tell me how it should look on every device to every user in the world, outline every workflow, specify the amount of load it requires, explain how you will want to enhance it in the future, not bother us at all while we build it, let us decide any confusing or ambiguous detail, then maybe, maybe, I can do this thing that nobody has ever done before in eight weeks. If eight weeks later when you are unhappy with that one thing you did not explicitly specify (even though I totally asked you to specify everything) I will tell you “It wasn’t in the reqs”.

Is that how you want to work? Or would you rather tell me the gist of what we are doing, come up with a plan to get there, see what we can do first quickly, get it out, then take it from there. Is outlining every validation error on every page necessary to do now or can we start with the first page and take it from there?

You may also use deadlines to motivate people. Vision, direction and importance also motivate people. It is pretty easy to get something done by saying “This needs to happen by this date”. But that shows you do not care what it does or how well it works. You are asking people to time box something because either the details are irrelevant or there is no trust in people to make the right decisions.

Always Be Releasing

Releasing functionality does not mean users have to see it. Turning features on and off, experimenting with small audiences, refactoring one class rather than an entire stack; all these are powerful steps for modern companies to improve products. Constant feedback lets everyone know they are headed in the right direction. It lets dev teams know the health of their code base. What is better than actually integrating new code to production to test integration? What is better than knowing if a feature is worth investing in than testing it on a small set of production users?

I’m sure you heard about the cone of uncertainty. Small and explicit features with short estimations can be delivered accurately. Larger loosely defined features with long dates are difficult to predict. Break down large features into small, clear user stories. A big feature or a long date means you do not care about details.

Short date ranges are okay and can help coordinate people. They work well when matched with story size. A few days, one week, one to three, and three to five are good ranges which require a decent discussion to work out details. Ranges allow for adjustment and can be refined as you move along the uncertainty cone. Ideally they are auto-calculated from story points. Anything +5 weeks requires a break down; there are too many variables. Don’t think you can add up ranges either, that is not the way it works. It is about increasingly clarifying level of detail on what’s ahead to maintain momentum. You can still, and should, deploy intermittently within the date range. Long dates don’t provide detail. Without detail you do not care how features work. So you do not care what you get.

You Work For A Tech Company

Your type of business does not matter. Your size does not matter. In house, off shore, outsourced development does not matter. It’s 2012. Your company uses technology to do business. You work for a tech company. As a tech person your job is to help your business realize this. As a stakeholder your job is to realize this and help your tech team help you do your job faster, better, easier.

I’ll Say It Again: Always Be Releasing.

Good companies consistently take their products to the next level. How? They build an incredible manufacturing pipeline. Why is Toyota’s just-in-time practices so applicable to building software? Because development teams manufacture software. It’s how the product is built. It’s how it changes. It’s how it’s delivered. It’s how it’s fixed. Dev teams buy the land, construct the building, build the robots, define the pipeline, assemble the pieces, run quality control, load up the trucks, deliver and when all that is done they improve. Hopefully the new manufacturing plant allows for easy improvement. Otherwise somebody made a mistake.

Faster, Better, Stronger

It is everyone’s responsibility to ensure that manufacturing pipeline delivers as efficiently as possible with no flaws. Continuous integration, unit tests, programming languages, server frameworks, agile development, clear vision, well written stories, cohesive vision, user feedback; it all goes into building a solid manufacturing process. You do not need to get it right the first time. You just need to change and improve when needed. Tech leaders ensure they are building the right process for the business. Stakeholders enable and leverage that pipeline effectively. Radical product changes, disconnected vision or tech decisions lead to numerous and slow manufacturing plants.

Dates are bullshit. It’s about where you are, where you want to be, and what’s next. That’s the conversation.

• Update: I missed a section of date ranges matching to story points relating to the cone of certainty. Short date ranges are a good tool for predicting near term deliverables and framing what’s next. These ranges are most effective when your agile tool auto-calculates velocity from story points. Remember, the bigger the complexity, the greater the date range.