Dealing with Dates

Happy new year! Welcome 2021 and time for some reflection on 2020.

One of my conclusions is that December became a very stressful month. Like last year and the year before and the year before that. Why does it seem like every December is a hectic period of wrapping up critical deliveries?

Yearly business plans, budgets and personal development plans, naturally forces critical delivery dates. Deliveries needed to accomplish a certain goal. And given the yearly planning, 31st of December or 1st of January become popular delivery dates for new initiatives. But I also think that the annual calendar is a strong basic artefact for us, something tangible to organise work around.

Personally, I like to divide the year into the spring and autumn semester, like schools. It’s a reasonable planning horizon, not too long, not too short (or “lagom” as we say in Swedish), and usually followed by a holiday. And take the New Year Resolution: we can start new, good habits at any time really, but the new year marks a new chance or opportunity in an appetising way. It’s the closure of a chapter, starting of a new.

Often a date is simply picked to align with an overall plan or goal. It can be a best guess, a qualified forecast or maybe just wishful thinking.

Additionally, many large enterprises still have some kind of “freeze period”, up to a month when applications and infrastructure are not allowed to be touched, in order to keep a stable state during holidays.

All fixed dates aren’t necessarily a problem. However, they often are and especially when multiple fixed dates pile up in the same period. Also, once a date has been strongly communicated it becomes an anchor.

– Why are you late?

– We’re not late, the date was never agreed. It was just wishful thinking.

And here we have a potential conflict coming up, a conflict that can often be proactively avoided. So, how to deal with dates in the agile world? Here are some tactics to try, different approaches to pick from or combine, given the context.

Challenge the Date

Always start by investigating whether the given date is actually fixed. If so, what does it mean, is it really a “deadline”? Often the date is only someone’s wish. Sometimes dates come from a personal development plan or a business plan and haven’t been discussed or agreed on at all.

True fixed dates can, for instance, be compliance with new regulations, like GDPR (data protection) or 3DS (payment security). The large Christmas campaign probably also has a true fixed date. There can also be dependencies to third party products being unsupported or decommissioned. Nevertheless, always start here.

Also, clarify what the risks are of not meeting the date. Cost of delay can be a good technique to use. Maybe the impact of being late is acceptable? Ask!

Align priorities and focus

Having concluded that there is a fixed date to adhere to, there needs to be a clear priority and focus. This is not only for the development teams involved, but for everyone who must contribute to get the job done.

For large enterprises, going through a crisis can be a good thing in this aspect: a crisis makes everyone come together and focus on what really matters. This I have also observed before.

Define the MVP

With the delivery date fixed, the scope needs to be somewhat negotiable. This is a situation when working out the minimum viable product becomes applicable. Define what features are really needed for the first release, for the fixed date. Everything else can wait.

This is an excellent approach when trying out new ideas, products or features when we need early customer feedback. The date marks a start for customer collaboration rather than a specific set of deliveries.

Introduce good technical debt

In his technical debt quadrant, Martin Fowler defines a state where you prudently and deliberately introduce a technical debt because “We must ship now and deal with consequences”. This could be a good tactic to manage a fixed date, that is, taking a deliberate but never sloppy shortcut.

Don’t forget to plan for the effort needed for necessary improvements!

Make a smart release plan

Another way to meet a challenging date is to find a smart release plan that mitigates risk. Your options here depends of the nature of your product of course, these are examples from my domain:

  • Start with a small market
  • Start with a small percentage of customers
  • Start with a less used scenario

The story then becomes “yes, we are live, just not completely” 🙂

Sense of urgency

Finally, used with care, dates can also be a good thing. Agreeing on an ambitious yet realistic date can create a positive sense of urgency. It’s a balancing act.


We are working on removing our freeze period. Maybe next December we won’t have it and pressure will be lower. Happy new year!

The very short story of DevMaint

-Hi Lisa, welcome to your new job as a software developer! You will start here in our support team doing maintenance. That’s the best way to learn our products. After a year or so, you will be ready to start working on new development.


This is how it was; I had forgotten. The separation between the “fun and creative” software development and the lower-status software maintenance. For nasty bugs, the heavy artillery would be brought in to assist, but the different teams didn’t work close together on a daily basis and there was definitely a rank between the two.

Continue reading

Offshore Development Anti-Patterns

Cost of connection, Group intercommunication formula: n(n − 1) / 2

“The Mythical Man Month” – Fred Brooks, 1975

Like most people I am currently working from home. The Corona pandemic is upon us and everything has changed. When we emerge from these hard times, we will see a new normal. I hope this new normal can also be better.

Because of the situation, our development teams are now 100% distributed, an unwanted but interesting experiment to study. Suddenly we are more equal, there’s no onsite and offshore, everyone is alone.

This post is about offshore development, or rather some learnings and “don’ts” from my own experience from the past seven years, through different setups. Continue reading

Challenging the Enterprise

“You don’t need to fire people and hire new people: you need to create an environment where people can learn” – Jez Humble

How would you describe your typical working week? This was mine: taking a deep breath outside the main entrance Monday morning – “Attack!” and then tumbling out  Friday evening.

But after almost two years, my colleague and partner in enterprise battle and I agreed, we could be proud of what we had accomplished.

Continue reading

From Push to Pull, My Summary

I have chosen to write about From Push to Pull because I think it’s one of the most important as well as difficult shifts to make in an organisation. You can find signs of a push culture in many areas and on many different levels: that’s why I think it’s critical to start change here.

Basically, it’s only about whether you assign tasks to people or let them pick up work when they’re ready. Can’t be that difficult or important, right?

Well, I think it defines the workplace. Here are some typical characteristics in different areas. Continue reading

From Push to Pull, Lesson 3: Performance Development Plans

Managing is improving – Toyota Kata

This time of the year, I guess a lot of companies are working on performance development plans. We are. As a base, we have the company’s vision and strategic goals, along with the employee and leadership model. The leadership model reflects the company’s Lean values, something very important to me. So far so good.

Continue reading

The Planning Fallacy

For the last six months I’ve been reading Thinking, Fast and Slow by Daniel Kahneman. It took me a long time to read, not only because I’m a slow reader, but because every chapter could have been a full book itself, given all the shared experience and the thoughts it triggered.

In short, our fast thinking is automatic and jumps to conclusions (impulses and intuitions), while our slow thinking is more systematic and requires effort and concentration.

For this post, I have taken theories and ideas mainly from the part Overconfidence and reflect upon my own experiences.
Continue reading

The Agile PMO’s Dictionary

Seek first to understand, then to be understood – 7 Habits of Highly Effective People, Stephen R. Covey

For some time, I’ve been collecting expressions that often lead to misunderstanding, confusion, or even frustration and conflicts. And these expressions clearly stand in the way of organisational and process improvement.

You always have a choice to either try to understand and find a way, or to spot flaws and come to a dead-end. Even though it’s the message that matters most, sometimes using a different word or expression will help carry your message further without confusion.

This Agile PMO dictionary should help you choose alternative expressions for some commonly misunderstood ones.

Continue reading

From Push to Pull, Lesson 2: Ownership

In August, I started a new journey and also a new blog series: From Push to Pull covers my first observations and reflections at my new job. The first post is about communication: how basic habits negatively impact a workplace and contribute to create a Push system. This second post is about the importance of Ownership.

The Observation

Our product has received seriously negative customer feedback for a long time. One could therefore expect devoted engagement and a strong drive, but it wasn’t there. I wondered why? Continue reading

From Push to Pull, Lesson One: Enterprise Communication

One of my first observations at my new job was that I had come to a very meeting- and mail-intense workplace. After one day my calendar was fully booked and my inbox flooded. I realised my big plans for fast changes would soon be shattered, since I would be so busy running to important meetings and reading even more important emails.

Having coworkers enthusiastically filling each other’s calendars and inboxes creates a destructive Push culture. These basic actions form whether someone else controls your time (Push) or you decide yourself how to make the best of it (Pull). Continue reading