Practising agile in deadline driven environments

Question

As a I understand, Agile is based on the team's velocity, which means that the project deadline is based on their velocity.

Problem 1

What do you do if you are a project manager, and the sales team have made a sale based on delivering the project on y date? Meaning that you have very little control of when a project should be due?

How do you practice agile methodologies properly so that the project is done in increments based on your teams velocity whilst respecting the deadline the sales team have made?

Problem 2

Agile unlike waterfall is based on not having a listing of requirements set at the start of the project, but rather discovering what is required on a sprint by sprint bases. I get that.

The problem is what if the client requests a project roadmap for launch so that they get a high level overview of roughly how the project is going to progress? How do you visually do this if you do not know what is required?

Answer 1

The only option you have is to use the transparency and "working on the important features - scope" aspect of agile. The deadline is set so the only thing you can do is to figure out what is really needed and what is the minimum for launch (sales will say everything, but that rarely the case).

Transparency will establish trust in the team and will so the organisation what is realistic to achieve in the given timeframe. Moreover, this can be useful later when you negotiate for new business.

Working on the scope is essential in each project, especially in agile ones (there is nothing else to do really, because time and resources are fixed, the only moving part should be the scope). In your sprints try to understand more about the business case and figure out what your team can deliver so that the customer reaches their goals.

There always be deadlines (agile is not about working without them), and your goal should be to figure out how to deliver real value when it is needed. That's a nice agile challenge.

Answer 2

Agile works well in a deadline driven environment as long as there is flexibility on scope.

With agile we typically work with a prioritised backlog of requirements. This ensures that as we work towards a deadline the most important features will be worked on first. The closer we get to the dealine, the less important the feature we will be working on. It is possible we won't complete all the desired work by the deadline, but we can be confident the work we don't complete will be of lower priority than the work we do deliver.

It also helps if we are doing regular releases as the project progresses. This helps the stakeholders (such as the sales people and the clients) to see concrete progress. That way expectations can be managed.

As for your second point, Scrum uses an approach called 'release planning'. In your situation you would do this by putting requirements on your backlog that cover the functionality you expect to be needed for the release (or whatever milestone you are working towards). This may at first appear like the non-agile approach of having an up-front specification. But with agile we treat the backlog as a dynamic list, that gets updated frequently. This is one of the reasons why in Scrum we tend to work with user stories that often consist of just a simple sentence. We only add the detail to the stories when we are approaching the time when we will work on them.

So, rather than having a rigid, detailed up-front specification, we have a far less detailed, dynamic list of requirements.

You can offer the client the project roadmap they request, using the backlog and the team's velocity to show the potential points at which functionality will be complete. The important thing is that you need to explain to your client that this roadmap will not be set in stone. It will be continually reviewed as you progress, taking in to account feedback they provide and any requested changes. Think of it as a very dynamic roadmap that is continually being improved.

It may appear that the client will not like this approach as it includes some uncertainty. But you may find that if you explain it carefully to your clients that they understand the benefits of this approach, such as flexibility in allowing them to make changes and seeing concrete progress in the form of interim releases.

Answer 3

Problem 1:

As a solution to problem 1 you should involve the customer in the process. As a part of scrum, every sprint has a sprint review which consists of two parts: one where you show the client the result of what has been done and one where the team reviews the sprint to see what went well and what needs to be improved (aka the retrospective).

The sales department should be very clear towards the customer that the deadline is an estimate and that the customer will be made a part of the process, giving them incremental demonstrations of the work that is being done so that they can give feedback along the way. If you have a client that doesn't want to be a part of the process, solving problem 1 becomes almost impossible.

Also, as long as the sales department keeps making promises that are highly improbable to be kept, the company image will suffer. They must be made to realise that it's better to have a later deadline and sometimes be done with the work before that than it is to promise a sooner deadline and have to buy more time with excuses or limit the scope of the project to be able to make the deadline.

Ideally, the team should get a hand in setting the deadline: first the sales team gets the requirements from the customer, then the team turns those requirements into stories and tasks and makes a rough estimation of how much time it will take to complete them and finally you and/or the sales team adds a few sprints worth of time to that estimate to determine the deadline for the customer. If the team doesn't consist entirely of people who are fresh out of school, their experience (whether in the current team or another team) should help them make this very rough estimate and if the team stays together they will keep getting better at it.

Problem 2:

As you can glean from my solution to problem 1, I don't entirely agree. The start of the process in agile is to determine what the customer's needs are and defining those at a high level. As soon as this is done, one should work with the customer to break up the high level chunks into more concrete parts and the priority of those concrete parts should be determined.

Based on this information, the team can make a more concrete estimation of the work that will be required to satisfy the stories and on that estimate, you can base a roadmap: figure out the interdependencies, combine them with the priorities worked out with the customer and now you can define a general roadmap. This roadmap won't survive reality, but it should be a good indication.

Note that sometimes, the customer will insist that everything is of equal priority, they need it all done by the deadline. This is never true: surely in a spreadsheet app the ability for the app to make calculations is more important than the ability for the user to have a colour picker to make the cells in the table turn that colour.

In general, remember the project management triangle!

If the project is fixed price, the deadline is fixed and the scope is fixed, the only thing left that can vary is the quality. If the customer wants a high quality product, you need to have flexibility on at least one point: cost, schedule or scope. This triangle has proven itself time and time again, pretending it doesn't hold true for your company is an illusion. Help your sales team understand this, work together to establish a process that works for the company and is acceptable for the customers. Inevitably you will lose some potential customers over this, but consider that it would most likely have been impossible to satisfy them to begin with. Rather than risking the company's good name (and the potential resources needed to complete the product before the deadline at all cost...) it is preferable to work with customers that can understand the reality of software development.

Answer 4

Coming from the dev side, I know that salespeople promising heaven and earth are a serious problem, especially, when they promise tiny features and gadgets, which have little actual value, but mess deeply with the system's architecture and premises.

Sprint velocities of teams take some time (many months) to determine, and even then, they are just averages. If you do old fashioned time estimates with an optimistic, average and pessimistic number (e.g.: 2,3,7 days), the pessimistic is often about twice the time and more than the average, but you must take it if you want to make a commitment that has nearly the chance of a Russian roulette headshot to miss the deadline.

It seems like either your customers are in a position of power to push your company to very risky or impossible commitments, or your company is too greedy in terms of growth, deliberately promising more than it can handle. In the first case, it is very risky, because the customers may end up not paying the price or even demanding penalties. If the salespeople can't negotiate for reasonable deadlines and sufficiently flexible conditions, the company is doomed. The last may work for a while, but is dangerous, because reputation takes damage, and development may be forced to create technical debt in form of really bad, rushed code, which is impossible to maintain, very difficult to improve and pure gambling on whether it works correctly.

You can't do witchcraft on developers, or make them faster with a whip, their abilities are limited. Perhaps, agility allows you to scale down to a console application with typing commands and parameters, instead of a fancy GUI at the deadline (and perhaps make the rest later), but if it's really impossible, the employees will end up passing the buck to each other for the inevitable disaster.

Whatever you do, never, really never attempt to just beat down estimates or urge developers to make impossible commitments! Their estimates are serious requirements, and you would urge them to lie about them. This would, in addition, destroy all the predictability gained through the Scrum process. Remember, developers are for software design and programming, not politicans and not to stand up against pressure, so they may possibly give way to pressure and accept a lower estimate, knowing they will never be able to fullfill such a commitment! Everybody knows that the actual work required can't be beaten down with pressure!

Answer 5

You get the same problem you get with any methodology. You are going to run the risk of missing that deadline!

Having a customer spec in advance is actualy a bonus because it defines your criteria for success.

Aglie advises againt planning upfront because it damages the changes of achieving business value. In your case you dont have to do that, just achieve what was requested.

1: Make sure you hit your deadline by being *ruthless* about the minimun possible product which matches the spec. If the colour isnt specified its whatever the dev put in that day. If they didnt specify response times, dont raise a bug for slow pages. You really have to be brutal even if you think its sh*t. do not add/change features

2: Aim to finish at least 75% of the allowed project time. If you arent on track, start worrying.

3: at 50% you should have that minimun product done. Phew! contractualy you are safe. Show the customer, you have 25% of the time left to respond to 'bugs' and tweaking, making it nice and the customer happy, polishing etc.

4: at 75% lock down and start your go live/deployment whatever. This always exposes new bugs. You have 25% wiggle room left if you havent had any problems, new features, unexpected illnesses etc to fix them. In practice you will be asking the customer for another 2 weeks and those ftp/firewall/policy wording details they promised you last month.

Answer 6

I have never been in a agile project without a deadline. Maybe I have just been unlucky, however to get the budget in the first case you need the business case which has a deadline...

From my experience working with agile, deadlines are about managing scope, team velocity and stakeholder expectations. I have been using Agile Monte Carlo forecasting and tracking with good results. First in a rather complex Excel sheet and then by creating the solution below. Take it for a spin and let me know what you think!

https://agilemontecarlo.com/