BT

InfoQ Homepage News How Agile Can Work Together with Deadlines

How Agile Can Work Together with Deadlines

Leia em Português

This item in japanese

Bookmarks

Even with a hard deadline, you can still prioritise work in sprints, use daily stand ups to manage blockers, and run retrospectives to improve your ways of working. Stakeholder relationships are key when attempting to negotiate and soften arbitrary deadlines. Start conversations up front to set better expectations and ensure a smoother delivery, particularly when facing uncertainty.

Ben Dovey spoke about combining agile with deadlines at Aginext.io 2020.

Agile isn’t a monolith, Dovey said. He suggested to figure out what is useful for your team and then keep experimenting, without assuming the same techniques will work in new contexts.

Prioritisation is your greatest negotiator: ask someone what they want and you will get a long list, but ask someone to pick between two features and you will get a decision and a sense of relative importance, Dovey said.

Fixed can be flexible; even the hardest of deadlines can be questioned, said Dovey. This allows you to prioritise the deadlines that won’t move, using them as a powerful tool to focus work, but also to change the deadlines that you can.

InfoQ interviewed Ben Dovey, business analyst at John Lewis, about how agile can work together with deadlines.

InfoQ: What was needed to deliver, by what deadline?

Ben Dovey: I had been working for a year as part of the John Lewis Loyalty team, when we were given a new challenge: combine the loyalty schemes of both Waitrose and John Lewis into one scheme by September 2018, which was seven months away. We didn’t know the driver for that deadline, though we found out later it was linked with a wider rebranding exercise also happening in September.

Our initial task was relatively small; assess the feasibility of printing new cards for customers across both schemes, and given this had come directly from the executive team, it would have been simple (and easier!) to just go ahead and answer that question. However, we chose to dig a little deeper into the "why" behind the question and that’s when we learnt more we started to understand the real drivers pushing this challenge, and then began to question that original scope and that original deadline itself.

In the end, we shifted the scope from a full scale rollout to a trial, and that trial was a slow burn beginning in September with just one customer (which was me!) and then continuing onwards into October. This was a very different outcome from the original ask, but this saved a lot of money and also led to a much greater understanding and learning.

InfoQ: How did you apply agile to meet the deadline?

Dovey: We were an existing standing team, who had been building up our agile ways of working for a number of years. This meant that when the initial brief came to us, one of the first questions we asked was "Why?" and "What’s the value?"

Despite the hard deadline, our day-to-day working did not change very much; we prioritised our work in fortnightly sprints, used our daily stand ups to manage blockers, and ran retros to continue to improve our ways of working. There was a slight increase in upfront planning and scoping activity, but we tried to make sure that this did not distract from the daily cadence of our developers and testers, to keep them focused on building what we needed without getting overly distracted by long distance planning, which was more focused on stakeholder management than anything else.

Overall, the key thing that allowed us to keep working and delivering valuable output was protecting the internal ways of working, focusing on building a strong collaborative team internally, while managing and shielding the team from external pressures.

InfoQ: How did you use prioritisation as a negotiator?

Dovey: When facing a deadline, you often know right from the start that not everything can be delivered. However, your stakeholders will often push for, and expect, everything to be completed one way or another. Approaching this topic is difficult, but crucial, if you want to set realistic targets.

At Loyalty, we sized up a number of features and presented back to our stakeholder group and said, "This is everything you’ve asked for, and this is what we think we can deliver". This set an initial view of what we thought was going to be delivered, and what would have to come later. We also made it clear that this was flexible, something could move up the list, but only if something else went down the list, and that there wasn’t room for anything else. We also explained you could attempt to fit more in, but then the risk of not delivering anything would dramatically increase; our argument was it’s better to have 100% of 4 features than 60% of 7 features, as at least the first option can go live and start adding value.

This process did take some time, but with examples and iterations a common understanding was reached. In the end, we actually delivered beyond our initial target features, but only because we had been able to focus on getting a small few over the line, before picking up the next thing down on the priority list. Without this negotiation, there was the danger that we would have reached the month before our delivery deadline and had to inform our stakeholders that nothing was quite ready. By starting this conversation upfront we set expectations better and led to a smoother delivery.

InfoQ: How did the teams collaborate with the stakeholders?

Dovey: When attempting to soften arbitrary deadlines, your stakeholder relationships are key. Often, the drivers behind a fixed deadline are a lack of detail, context, and trust. For stakeholders to trust that they are going to get something delivered, and more than that something that is valuable delivered, you have to look to build up that understanding and that trust. Once you have built that up, you are also more likely to gain flexibility in your delivery timelines.

At Loyalty, we made sure that we had regular open dialogues with a wide stakeholder group via weekly demos. We talked through the challenges, showed off what had been worked on that week, and acted as a source of truth on our progress. This avoided rumours or corridor chat that can undermine delivery if stakeholders are getting a mixed message. The demos not only built trust, but also removed any rumours; we were regularly available for questions and to have an open dialogue. The other key factor that I have already alluded to is frank conversations. We were upfront from the start about what we thought were good and not-so -good ideas, and what we thought was achievable and not.

InfoQ: What have you learned?

Dovey: I have a couple of key takeaways from all of this.

Firstly, when facing tough deadlines, not everything can be done, and this is not a bad thing. We need to not hide away from tough conversations about the reality of delivery. If we face them upfront, we have a bigger chance of avoiding pain down the line, and getting something of real value delivered. The alternative is the large programme of work that keeps getting delayed. Instead, make priority calls upfront, get small deliverable chunks out, and then keep working through your backlog. In the end, you often end up getting more done than you first realised.

Secondly, and probably crucially, always challenge a deadline. Most of them are made up by someone, somewhere, and so can therefore be changed or altered. If you can figure out the driver behind the deadline, you can also figure out the value it is after and whether there is a better way or timeframe to reach that value. The key for me is figuring out what has to happen, and then the best way to do that, and let that drive you to natural deadlines. If you can get your stakeholders on your side, this becomes much easier, and much better, for all parties.

Rate this Article

Adoption
Style

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Community comments

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

BT

Is your profile up-to-date? Please take a moment to review and update.

Note: If updating/changing your email, a validation request will be sent

Company name:
Company role:
Company size:
Country/Zone:
State/Province/Region:
You will be sent an email to validate the new email address. This pop-up will close itself in a few moments.