Thriving with deadlines

[Rickie_Du]

Yes, deadlines are a reality. Agile teams are no exception

In modern English, the word deadline is used to refer to a date or time by which something must be accomplished. In the context of software projects, the date or time could come from many sources.

For outsourcing projects, they are normally set by customers and written into contracts.

For internal projects, they are usually the part of the organization impacted by the project wishing to know when the project will have expected impacts.

For product development projects from software vendors like Flexera, they are usually driven by enterprise business strategy which is a complex system by itself and requires all subsystems to be executed in a well-choreographed manner so that critical business objectives can be achieved.

Even for projects without a hard deadline, there usually are expectations of a release date.

As noted in Parkinson’s Law, work expands so as to fill the time available for its completion. You may have not heard about it before, you have probably experienced it many times in real life though. E.g. your college assignments, regardless if you were given a week, a month or a whole semester to finish, you ended up spending the whole night before the due date just so you could finish it on time!

In the context of software projects, Parkinson's Law could be translated as ‘if a project can go forever, it will, regardless of what cool methodology you or your org may have chosen to use.'

Key learnings about deadlines in our agile journey

It's not uncommon to see engineers describe deadlines as bad. It's equally not uncommon to observe very different perceptions if you ask people assuming other roles involved in the software delivery lifecycle though. 

Instead of arguing about whether they are good or bad, I think it's possibly more constructive to reflect on some of our learnings around deadlines that helped my team to deliver on time repeatedly in our recent projects. Hopefully, some of them are useful to you as well if you do find similarities between your teams and mine.

What does my team look like

It’s a team of 6 practicing Disciplined Agile Delivery(DAD) together with half a dozen far-located teams on building the company’s next-gen product. 

Among the many delivery lifecycles covered by DAD, my team has been exercising the scrum based agile lifecycle, which is based largely upon Scum and XP with a set of time-boxed iterations.

This is the 3rd year of my team’s agile journey. 

Learning 1 - always question the dates

I know this may sound a bit negative to some of us but please don’t get me wrong here. Questioning does not equal to pushing back. It should NOT be used or interpreted as a way to push back at all. Otherwise, you end up with more troubles than you could handle and they will make you regret starting to question at all.

Based on our experience, even the seemingly hardest dates can be and should be questioned. Here is a list of benefits we gained and enjoyed from our questioning process in our previous projects.

a shared sense of purpose

This is very much to do with team morale and thus productivity. It’s human nature. If we feel our work doesn’t lead somewhere appealing or we don’t know where we are heading at all, we are disinclined to focus on it. We won’t move at a good pace along the path if sense of purpose if not in place.

Once we start to question the dates, we get the opportunity to open up conversations about the reasoning process behind it and the big WHY in most cases.

By have conversations like this, for the benefits of the team, the big purpose is no longer a poster on the wall or something made up by others. Instead, it becomes their purpose as well.

A shared sense of purpose by itself apparently won’t guarantee a happy and productive team. However, I am pretty sure that a happy and productive team is impossible without it.

a shared sense of urgency

Let’s be completely honest, sometimes deadlines, especially the ones that are due shortly, are set based on experience, or some other external factors that cannot be easily explained, comprehended or accepted by everyone.

The big why may stay unveiled after the questioning process in such cases. However, it at least offers business stakeholders the opportunity to emphasize the urgency to the team.

I do understand the sense of urgency could mean pressure or stress in some contexts. However, I personally do feel it especially important to have it for projects with pressing deadlines. Be the decision right or wrong, the team needs to share the sense the urgency to try everything they can to figure it out ASAP.

Learning 2 - Fixed can be flexible

Well, we have to admit that some dates are pretty hard to move if not impossible, e.g. customer commitments or dates to hit to guarantee the product’s leading position in the market.

That being said, too often we see fixed deadlines set at the macro level instead of micro-level. In another word, too often the drivers behind fixed deadlines are a lack of details.

The philosophy that my team has been following in such cases can be well described as ‘Fixed dates, flexible scope’ as promoted by Deepak Kaimal, our VP of Engineering, in many of our team meetings.

This philosophy has been critical for our success. This allows the product team to stay focused on the road map and define timelines best suited to market needs while offering the freedom for the domain experts and developers to study and propose what makes the most sense and practical for the given timeframe.

Learning 3 - ALWAYS do inception, at least a mini one

DAD is a very comprehensive agile framework. It doesn’t prescribe anything. What it really offers is a huge library of choices that you can choose from. In another word, the desired way to do DAD is to do some tailoring before adopting any of the predefined processes in the library based on your team’s specific situations and priorities.

With the scrum-based agile lifecycle used by my team, there are 3 major phases defined: inception, construction, and transition.

When we were assigned projects with very tight timelines, we tried to skip the inception phase a couple of times but ended up having to go back to attend some of the inception process goals identified by DAD. Among the 10 goals listed on its website, we have found it always useful to at least run mini inception that covers these 3:

• Explore initial scope and produce at least 2 sprints worth of stories with good details. We found it particularly useful in verifying the understanding of requirements from a high level with sufficient tech risks explored and managed to do this goal.

• Align with enterprise direction. In our case, this means a lot of conversations with our Architect Team.

• Plan the release. This includes story point sizing, put stories into sprints, verify them with collaborating teams, and establish several checkpoints or milestones for delivery.