What to do when time takes all your cards away?

Let me just go through some of the fundamentals of project management and highlight some the challenges one can face in software development. Let start with the stages of software development which is common in almost on all development departments, sometimes you do this in a big loops, sometimes in small iterations, depending on the methodology of your choice.

  • Problem definition
  • Gathering requirements
  • High-level planning
  • High-level design
  • Coding, debugging
  • Unit testing
  • Integration testing
  • System testing
  • Maintenance, operations.


When you start any project, you have 5 variables you can control.


These are:

  • 1- People:  Who is assigned to this project?
  • 2- Technology: What processes, methods, and tools are we going to use?
  • 3- Scope: What features are we building?
  • 4- Time: When are we planning to deliver?
  • 5- Quality: What degrees of completeness and correctness, is it MVP or polished version?

Once you are committed to this, game starts. When you move with the project, you need to adapt and change things, but as a manager, pretty much this is your cards and your playground.

Let me brainstorm around the limitation that you would face while changing any of these variables.


  “Adding manpower to a late project makes it later” Frederick P. Brooks, Jr., The Mythical Man-Month: Essays on Software Engineering. 1975

There are still managers out there, they think they can solve everything by just throwing men at it. When you add new people, your engineers will spend time on training them. Communication cost is massive. Adding manpower later will just create a higher risk of missing the deadline. Onboarding new employee will be difficult and frustrating due your busy employees.


Changing tools and methods on the half way could create deep learning curves and extra time spent educating people. Especially introducing something new. You need to consider the effects of bad change management. People will question the change, maybe will not buy in. If the developers do not care about the product, you will hear saying; “Are we going to rewrite everything again?”


You can always cut the scope to make a deadline, but a few things you need to remember. If you are cutting something that developers are already putting a lot of effort, it will be very disappointing for them. Therefore, it is very important to have prioritization from the beginning. Having A, B and C as well defined, or better using MOSCOW.

  • Must have
  • Should have
  • Could have
  • Won’t have

So, when you start cutting, you should start from the bottom (C), and this is mostly likely the stuff that has not been worked on, so it will easier to cut.


Adding more time always sounds good, but you need to remember, it will be hard in the future for the team to commit to a deadline. They always think it will be postponed anyway, so what should work so hard. As a good manager, you should never create forfeit deadline. The deadline should be serious and when you change it, it should be very clear to everyone, what lead to that reason.


Sacrificing on quality, it is just time borrowing. Your team will be trapped in a continuous operation mode. Your long time plans will effected. Your programmers will start jumping where the fence is low. It will create frustration, you will most likely plan for bug fixing and this will lead to the technical depth, never ending operations work. Etc.

Your responsibility

It is your responsibility as a manager to set the team for success. You need to create a balance of these variables that support each other before the project start. Setting an exploratory team before the project start is one of the things you can do. These small exploratory teams could give you a lot of insides and can collect information to make you better plans.


With the information you gather, you should start preparing yourself and your team for success. Being agile means, being open to change. Try to communicate “Read and React” to the team. Make sure you hold a meeting and encourage the team to talk about the Risk and have a risk mitigation plans. Introducing milestones with clear goals and measuring your velocity early can help you to make decisions early.

“Time will take your cards away from you.”

Where is Agile?

If you are doing agile development right, you will not be limited by the things above, your project will be in small iteration and you adjust as you go. But nevertheless, if the rest of your organization is not committed to agile, you will be end up with an expectation gap. If you have a  deadline and fixed scope you should not do agile.

When all goes wrong.

Let’s say you have done everything you could, but still you are out of track, Now it is time to call for a war meeting or called it Cruch. Below some of the rules I follow when call for an emergency meeting.

#1 Set the scope in stone

If you can’t set the scope and agree 100% what to deliver, don’t call for a war meeting. Nobody wants to commit to chasing goals.

#2 Only invite high performers.  Avoid nay sayers and film critics.

#3 Make the goal visual. Print it out or write to white boards, so the team can see it.

#4 Make sure, you take a decision, don’t postpone a decision.

#5 Trust your developer, never double guess them.

#6 Don’t do it more than 25 Working days.


Rules of the war meeting:

  • We meet to solve problems not to complain.
  • If we clear the board, we will ship it.
  • We take decision here and now.
  • You have selected because we believe you can deliver.

Screen Shot 2015-10-05 at 15.28.33

Good luck, and thanks for reading.






Leave a Reply

Your e-mail address will not be published. Required fields are marked *