Personal Blog (scroll down)
Deadlines By Fiat, Agile, & Disaster!
Deadlines By Fiat, Agile, & Disaster!

Deadlines By Fiat, Agile, & Disaster!

Increasingly, I find that ‘Agile’ is essentially a modern day metaphor for Communication.  There are volumes of books on the topic.  Strong evangelists and enthusiasts.  Devotees to a new process.  Yet, if you boil it down, it always reduces to Agile==Communication.

Earlier this week I had the privilege of attending the regular Ann Arbor Agile Groupies event.  The focus was fiat deadlines lead to disaster.  For two hours, we traded stories of how arbitrarily set dates led to all manner of disaster: destroying morale, missing delivery dates, being massively over budget, and/or delivery crappy software.

We should probably make sure everyone understands what a ‘fiat deadline’ is, so we’re all on the same page.

jtpedersen Iron-TriangleIn software development (elsewhere too, just with different terms) there is a concept known as the Iron Triangle.  In short, all projects (e.g. product being built) are subject to the same constraints.  They are:

  • Scope
    What you’re going to do. Specifically.
  • Resources
    What you need in order to do it.
  • Time
    How long you need to finish.

The triangle is rigid and within it is Quality. Delivering a quality product demands a tight link between Scope, Time, and Resources.

Scott Ambler writes a good piece, specific to software, in The “Broken Iron Triangle” Software Development Anti-pattern

Having laid the foundation then, a fiat deadline, is one set without understanding the inputs required to deliver.  If management declares when a project will be completed by a specific time, without knowing or understanding the corners of the respective iron triangle, they have created a fiat deadline.

You’ve Seen It Before
jtpedersen_hiding face_Agile_Communication_Disaster_rMany of us have seen these situations.  A team is working on a new product suddenly a new deadline is set.  Or, perhaps the team is halved or scrambled.  Or, the deadline stays the same but a ‘bunch’ of new ‘mandatory’ features are added.  The variations are infinite.  The result is invariably the same though: The iron cross becomes distorted, broken, and projects become late, over budget, and failing to deliver the expected features. Quality, customer satisfaction, and profitability all suffer.

One of Agile’s key promises is for development/engineering to be more responsive to never-ending change, mitigating damage to the iron cross.  (A crude overview for those new to Agile…) This is done by working as small teams, in open-space environments, breaking projects into ever-smaller chunks (sprints) of work.  To make sure everyone knows what is going on, members frequently (at least daily) do ‘stand up’ meetings, tell everyone else what it is that they are doing at the moment and maybe for the next couple days.

The problems, as this week’s discussion (fiat…disaster) unveiled, even when practicing Agile, all the same disasters can—and do—keep happening.  While many crises are mitigated, the magnitude of ‘disasters’ still exist.

Through all of this, the key to success ultimately lays with frequent, transparent, communication.  Product Owners need to let their teams know about what’s going on outside the company, and the potential changes that may occur.  Development teams need to accurately forecast their work, and make sure the product owners understand their constraints and ability to deliver.  Together, everyone needs to agree, to negotiate, what the project’s scope will be.

jtpedersen_talking guys_Agile_CommunicationFailures to deliver on plan, on budget, as specified, and as promised overall, depends on everyone effectively communicating.

For instance, Agile purists will decry those who do ‘checklist’ Agile.  In other words, teams ‘going through the motions,’ checking things off (see, we did it), but not really living in the dream.  What’s the dream: For everyone to freely communicate, to minimize or eliminate surprises, so the end deliverable matches everyone’s expectations.

In the end, the team that has more, better, transparent communication, will outperform any lesser team.  Whether they practice ‘agile,’ or not.

What are your thoughts?  If you’re using Agile, thinking about these issues, then you almost certainly have experiences and an opinion.  Leave a comment and let everyone know what you think!

image credits:
Diagram, JT Pedersen
Talking Guys, Rafael Marchesini
Hiding Face, Scott Liddell


  1. Hi JT,

    I have certainly seen my share of managers who seem to forget basic math: that you can’t, for example, take a team with the capacity to handle two projects at once and ask them to handle another without either eliminating one or slowing them all down. As you say, this usually stems from a lack of communication.

    Corporate management is typically bad at communicating so it’s up to us as leaders in product development to keep telling them what we’re doing, why, and when we expect to be done. Then we’ve provided all the necessary facts for a conversation where they want something more or sooner. We can always respond with some variation of “ok, to provide that, what do you NOT want to do?”

    Separately, I think it’s worth noting that there is nothing wrong with an arbitrary deadline. Sometimes they are just a business reality. We have to ship for a public event or a customer deadline. It can also be useful to set a deadline to avoid over-engineered solutions. Sometimes it just makes sense to allocate some specific number of person-weeks to a project and no more.

    It’s not arbitrary deadlines per se that lead to disaster. It’s setting them without acknowledging that the other parts of the triangle have to adjust in concert. You can pick a deadline, you just can’t also dictate the budget and the scope.

    1. JT

      Hello Bruce,

      Thank you for your note.  I can appreciate the practical reality you outline, such as managers doing ‘bad math.’

      I did like your point about constraining projects as well.  Sometimes you do need to simply limit the amount of resource you’re prepared to invest in a given effort.  Failure to realize the importance has led to way too many never-ending projects.

  2. Cool JT. I love hearing about the Agile group discussions as it is informative to learn of the Iron Triangle and your perspective on Agile & communication. The continuing intrigue I have with Agile is the capacity for adapting, flexing while staying focused on a clear goal, that itself may even change. Living productively in responsive tension, is also what I like to call it.

    From my org. development systems side, dealing with traditional management efficiency thinking can be one of the big wrenches in the works, with some rigidity that can lead to disaster. In fact, managers can create their own silos of “being managerial” when what is needed is leadership.

    A built in culture of flex (like Michigan Steelcase focused on an idea culture), that is respectful of those who do the work, two way feedback, and experience with what works (no phone ringing on software problem, via our local Menlo Innovations) – is one take away from mulling over your post. I like that I’ve heard Rich Sheridan rattle off the typical problems of new specs, changing expectations and THEN how Menlo has become so very clear about the boundaries and guidelines to deal with such project buster behaviors. Such behaviors are also legion within large organizations who are internal customers of each other. Boundaries and guidelines, mutually agreed upon, are still important, even more so.

    I like that smart teams DO create checklists. Pilots use them. They ARE useful to check our ego and blind spos. They help create better boundaries and guidelines conversations = communication = which can evolve to thinking systemically & just being team smart. In a VUCA* world, that means agility with good communication to me. Thanks again for getting me thinking about agility and what it really means.

    *VUCA = volatile, uncertain, complex and ambiguous, a term coined by the US Army War College in the weeks before September 11, 2001.

    1. JT

      Hello Deb,

      Thank you for your note.  Reading it, you helped underscore another observation many seem to miss: Agile’s principles in many ways can be applied to disciplines beyond software development.

      Glad it had some take-aways for you.

  3. Martin

    Thank your for the great article. Now I have something to prove my project manager that fiat deadlines are bad and might lead to disaster.
    Currently I’m working in a team which tries to be agile for various reasons but fails often because the client sets fiat deadlines, and the team is forced to promise to deliver without even having a clear understanding what the business requirements are. Of course, we fail to deliver in time, and everyone is frustrated … but nevertheless, the work continues, and from the reaction of the client it’s clear that actually there was no need for the deadlines. The client does not lose anything in this particular case, but the developers lost so much – they were exhausted working overtime just to meet the deadlines.
    Some would argue that in Scrum every sprint could be considered a deadline, but I would call it a checkpoint – deliver what was done and evaluate how the team and the client is doing together and how the future of the project looks like.

Comments are closed.

%d bloggers like this: