# How To Run Fixed Date Projects In Agile?

1K
• by Ardita l
• 07th Aug, 2018
• Last updated on 11th Mar, 2021

I have been lucky to work in different organizations that have taught me different things and made me aware of different points of view. One thing I have learned early in my career is how to “smell” fake fixed dates. Unfortunately, there still are organizations or people in some organizations that believe that by setting deadlines people will be motivated to get work done.

These are fake deadlines, without real urgency behind them and without any loss of business or clients. They are dangerous because they create fake rush, get people to work late hours for no good reason, and in the end there is nothing to celebrate for what they did.
However, I do believe that there are some legitimate cases when a certain solution is required in place by a fixed date. I have seen these cases and I have seen how Agile teams have been able to deal with them successfully.

Some of these examples are Regulatory changes, Event-driven or Promotional and Holidays.

Regulatory: These are changes that are forced on a company usually by Government or Market regulations.

Event-driven: These changes are usually driven by Marketing and supported by Sales. They are opportunities to showcase the strength of the brand, enforce market presence and/or domination in events like expos, conferences, partner announcements, marketing announcements, etc.

Promotional or Holidays: These changes are usually driven by Sales and supported by Marketing. Think Christmas, Valentine’s Day, or similar depending where you live. These are days that retailers “live for”.

I can think of other cases, but they kind of boil down to the need for an area of the organization to have an offer ready by a certain date that is controlled by external factors/organizations. The good thing about these cases is that usually we have a decent amount time on hand to prepare and deliver. During this time, I have found tools and techniques that help you more than some others, and I want to share those with you.

Good understanding of the meaning of a fixed date

• What happens if we miss the date?
• What happens if we miss the date by a lot/by a little?
• Do we have to have in place feature A or will B do it?
• Can we do A manually?
• Is the deadline for all our clients or just a portion of them?

Keep asking from all the points of view. This is a good exercise that Agile teams are used to doing since they constantly split their stories into smaller work. Now bring all that into splitting the work for the deadline into smaller BUT meaningful and valuable pieces.

Presenting real-time examples

In one of the cases, I assisted my team, we were given only five days to deal with a change required by one of the provinces of Canada. Two of those days were taken by speaking with lawyers to clarify all the details of the change requested. After that, the team was able to understand the amount of work and what was the minimum they had to do to satisfy this new regulation. It was done on time.

In another case, the Retail company had to decide if what they were asking was possible to be done by mid November. They agreed that if it was not in place by then, there was no value in putting efforts towards it since it will be too late for Christmas promotions.

In another case, a product company wanted to present the new features of their 3D software at the most prestigious event of the industry. They decided to be in a good place where the Product Owner knew what wasn’t working or how to get around the features that would be demoed on the expo floor. The goal was to get people excited to have them subscribe and then follow up when the software was ready with the features and high quality experience.

So, keep asking, keep slicing and keep finding ways to do the minimum required. Unless, you have all the time you need and in that case, do what is needed with high quality.

Product Owner and people with all the skills required are available all the time or in very short notice

Although we have asked all the questions and we have figured out the smallest piece of work to start with, questions and issues will always come up. Without the Product Owner always present to respond to questions from the team, we end up with wasted time. Same is true for any specialist or any skill required to achieve the deadline. We manufacture Dependencies.

If this fixed date is high-priority, then let’s give it the right attention and the right dedication. If many things are high priority, it is usually a smell that prioritization is not well and is probably based on who screams the loudest. This is where we need to make sure that expectations are set and clear, where we understand the priorities of the organization and where people will focus.

Coming to dependency management, the following figure can help visualize the ideal ways to manage dependency and streamline your workflow.
Dependency management is done best when we remove dependencies rather than manage them. Take time to identify the dependencies on skills, knowledge, process, sequencing and any other area that affects you. Take time to look at the whole picture and set in place communication channels, core working hours, give heads up with enough time for other areas to prepare for your requests. But one thing that works the best is to have a team that works very closely, possibly co-located and supported with collaboration tools. It would be great if this team is already working together and this request is a new addition to their prioritized backlog.  Otherwise you will lose time with onboarding.

Continuous Delivery Pipeline

We are not done until we are done. And done means it is accepted all the way to production. There is work to develop the change and then there is work to deploy the change. If your company has a long deployment process with many layers of approvals or documents to complete, then you are shortening the time for development. This adds extra stress to the team that will work on this change and frankly speaking from the Lean Governance point of view, a lot of waste in your system.

Often, teams are asked to justify the need for investing in automation and better technology. These are the days when that investment has high returns and pays you back many times over. Continuous Delivery gives teams the advantage of early and often feedback. The earlier you are able to deliver out a solution the faster you learn about what risks you have to deal with when the changes are in the hands of the customers.
There are many ways to leverage early deployments when Continuous Delivery Pipeline is in place. You will be able to deliver a small portion of the change (often you hear MVP but I prefer Learning Release), you will be able to test with a small number of customers or for a specific geolocation of your customers.
Like this, you reduce the risk of releasing a valuable solution on the requested fixed date. No need to work extra hours or late at night.

!! DO NOT !!

Hire more people and make a bigger team.

Big teams move slow. Also, onboarding new people on the team is down time for specialists as well because they will do the training. For changes that have a short time to deal with a fixed date, adding people on the team will only slow you down and create more confusion.
Cut corners

Unfortunately, I often see the practice of “get it off my plate”, where a team just patches together a quick fix and then sends it over to production to call it success. Although everyone knows that this change was not done right, we never give time for teams to go back and do it right.

So if you can, do it right from the beginning or make sure the team does not start working on something else until they refactor the solution. This will allow you to make future changes easier and faster, even if the future changes are urgent and have a fixed date.

On everything we do, we need to continue asking “Why” and challenge better ways of working. Just because this is how things are done now, it doesn’t need to be how we have to keep doing it in the future. The spirit of Agile is continuous improvement and that is where we keep learning and getting better. Asking “why” is where we get out of our comfort zone and become creative with the solutions for our customers.

### Ardita l

Blog Author

Ardita is a passionate Agile coach, trainer, speaker and consultant in the Toronto area. As the President of Industrial Logic Canada, she brings more than 15 years of software development experience from different commercial and public organizations. Over the past few years her focus has been on business process improvement for organizations that are adopting Agile practices. Working with management and development teams, she is well known for applying Agile and Lean techniques to help identify and remove barriers in order to streamline software development efforts. She is driven in creating sustainable change and has developed techniques that focus on building teams that have a culture of continuous improvement.