Is having fixed delivery dates for elements an "Agile" way of working?

Question

We keep being told we are going to be working in an agile way on a new project by senior management. They have set up stand-ups, sprint planning, retrospectives etc. etc. However, they have now come up with a plan detailing all work they want us to deliver with dates against each element and showcase dates again with what will be demoed in each one. This plan goes out to Q2 2017.

To me this seems like Waterfall in the worst sense, a plan with no input from the technical team has been drawn up where certain stories on the plan are very unclear and none have been estimated by the dev team.

However, I know their argument will be "senior stakeholders have to have dates and there has to be a plan, we can't just work from a backlog." To me this seems senior stakeholders have not bought into Agile and therefore we are doomed to fail implementing it at a lower level.

Is this a fair judgement or am I overreacting to this plan!?

Answer 1

There's a difference between meeting the deadline and fulfilling all requirements. Its like the old adage "fast, good or cheap, pick two".

So here you have fixed dates for delivery - that's good, it means you are time-boxed in that what you deliver at the end of your last sprint will be the final product. You remember that you always have to release working software at the end of each and every sprint don't you.

What may happen is that the final software will be missing some features. Well, this happens with all development methodologies, waterfall included. All that will happen is that you'll be tasked with producing a patch release afterwards, or a version 2. That assumes your final delivery is good enough of course!

So fixed dates are not a non-agile way of working. Agile doesn't mean there's an unlimited budget for you to play with your new planning tools. It does mean you'll have to focus on delivery, that's never a bad thing.

Answer 2

No. This is the exact sort of things that non-software companies tend to do. There are plans, and deadlines, and budgets. And it will inevitably fail, since humans suck at predicting the future.

Let's go through the various points here:

We keep being told we are going to be working in an agile way on a new project by senior management.

If you were Agile, then you'd be having self organized teams, not being told how to work by management.

However, they have now come up with a plan detailing all work they want us to deliver with dates against each element and showcase dates again with what will be demoed in each one.

Nope. That is pretty much the antithesis of iterative development. Something will happen (someone gets sick, someone leaves, some requirement was forgotten, your servers die, whatever) and then you miss one of these goals. Now management either gets to recalculate the entire plan, or crack the whip on development.

none have been estimated by the dev team.

So how does management know that this plan is viable at all? In Agile, work is a negotiation. Business says: we would like this. Engineering says: okay, assuming XYZ, that will take 3 weeks. There is no customer collaboration in what you're describing. No individuals and interactions.

To me this seems senior stakeholders have not bought into Agile and therefore we are doomed to fail implementing it at a lower level.

You're not necessarily doomed, but if not, it's only a coincidence. When all of the work shows up because management can't see the future, you'll miss your dates (or produce shoddy code, or require more resources than expected). That will then be your fault. Management will likely then pressure you to work more hours to hit the date, or maybe throw people at the problem.

Best case, management is actually agile, and is smart enough to reduce scope. Meaning they just spent all of this time building a big detailed plan that is worthless.

Answer 3

If there's an expectation that specific sets of features are to be delivered on specific dates, then no, this is not agile project management. Agile project management is empirical in nature. Projections are not made based on the wishes of executives but rather on analysis of prior performance.

Your description matches up with what I consider to be cargo-cult agile. The focus is on the specific processes and ceremonies and not on the core concepts of evidence-based project management. You might have some luck getting business people to understand if you relate this to Lean or TPS. The real problem you need to solve here is getting management past their fear of the unknown. The right answer to the executives is "we can't tell you now when things will be done but once we start delivering value, we can build projections based on our experience." Developers tend to say things like "it's done when it's done" and "I don't know when it will be done." Managers won't say things like that to the executives, it makes them sound like nincompoops. They are simply doing what they know.

Most likely, the plan will fail and need to be revised. The biggest risk for the team is that there will be a big push to hit the deadlines and quality will suffer. At some point you will not be on target (most likely, it will be the first deadline) and there will be a push to hit that date. Overtime will be expected and there will be pressure to cut corners (skip unit test, code reviews, etc.) This is a slippery slope and once you start down this path, it's a bit of a downward spiral and things will get ugly. Productivity will get worse as the project continues in this way.

If you can get the dev team to present a unified front, you really should push back and hold the line on quality. My experience is that project managers tend to think software output is linear. That is, each period X will produce Y 'precentage complete'. That is, if you aren't "50% complete" by halfway through the allowed time, the klaxons start blaring. In reality, if you are doing it right, the first feature tends to take a lot longer than the 50th feature (of similar size.) If you can get through that initial danger crisis period ("what's happening?", "I don't see anything getting done!") you'll probably be OK.

Answer 4

Welcome to real business.

There is an older style of business, which I tend to derisively call "traditional development" and then there's a new style, "agile development." If I try to treat these as opposing ideals, we see a straightforward division down the middle: plans and requirements go on the traditional column, discovery and evolution go in the agile column. It's neat, tidy, and wrong.

In reality, business is a search for the happy medium between the two. It's easy to show that either extreme actually falls flat on its face. We who love Agile eagerly demonstrate all the issues of the pure ideal of traditional development, and there are plenty who can show the many ways pure Agile falls apart. The successful agile companies are the ones that find their particular balance between the two. The successful traditional companies are the ones that find their particular balance between the two. You can't have one without the other.

Even our blessed SCRUM process shows a balance between the two. While there is a clear attempt to maximize agility, there are a few key tradeoffs made. For instance, the Product Owner has the mighty job of advocating for all of the customers. SCRUM intentionally does not specify how that interaction works. It intentionally handwaves over the fact that everyone needs to get paid at the end of the day. Its' the Product Owner's job to create the illusion that that doesn't matter.

(Its interesting to note that pure agile works great, so long as you don't get paid until you produce a product, and you don't get access to proprietary information until you are vested. I think the only software engineers that are comfortable with this trade are the entrepreneurs)

So the management has dictated what features will be in there and when they need to be there. That's fine. A phrase I have heard is "the customer picks the what and the when, the producer picks the who and the How." You've been signed up for the "what" and the "when." They have not stated anything about the who or the how, other than to offer you a chance to use "Agile" as your how. All that's left is to help management understand how many people they are going to need to hire to meet their needs.

In a perfect world, your company is agile from the outside. It interacts with its customers in an agile way, letting the developers develop agily for them. However, very often the company must interact with the outside while developing agily inside. In between is always a complex set of tradeoffs, unique to each company.

Personally, I treat this situation as a test case for anyone who thinks they understand agile development. At some point in the future, you will have to develop a product for a deadline, and that product/deadline pair will be relatively fixed. If a fixed product/deadline shatters your process, can you truly say you were Agile in the first place?

My advice: don't think of this as a waterfall. You still control the "how." You can still do all of the rapid sprinting and flexible prototyping that Agile is so famous for. You merely have to be aware that the rubber meets the road, and you have to deliver. This is the real world, not the ideal world. Would it have been better for them to ask you in the first place? Sure. It may not have been your call. There may be a thousand business-related reasons to do it their way that you simply do not fully understand. Feel free to push back on them, but understand that they may have a very good reason for what they did.

Answer 5

Agile does not prevent you from planning milestones (E.g we will release V 1.0 in 3 months), but what goes into each milestones cannot be fixed.

I think how you should react depends on the nature of the project. If the project is to send a man to the moon by Q2 2017 everyone would agree that it is doomed to fail. If you think you can deliver an MVP by the end of Q2 2017 you should work on it sprint by sprint.

If the management thinks your team is doing their best and you can show progress with each sprint you should be able to negotiate for more time.

Answer 6

EVERY business relevant project has constraints:

• Time
• Resources
• An expected minimum feature set

This is nothing else. Developing agile doesn't mean "people pay us money, so we can develop whatever we want for whenever it may be ready" - you will always have some time-frame. There will always be some date with some minimum requirements and if they are not met the project will be cancelled and be called a failure. They may sometimes be implicit - so the manager knows "If I don't have a working UI with these features after 4 weeks, this project is doomed to fail" - or there may be shareholders who set a goal.

There are many projects resulting from legislation. - If the government decides you have to implement Feature X until 2017 to respect a new law, you will have an non-negotiable dead-line and a set of features which need to be ready. The only variable is the amount of resources which management can allocate to the task. - And in these projects, where the deadline is an external decision, they will need to watch your progress, hear you prognosis and staff up the teams or outsource part of the work to meet their goals.

All this doesn't oppose agile development. You will still have your sprints, develop your features in your own time-frame. You will always get your feature-priorities from a client - and you will work to deliver as many of these features as you can until the deadline.

If the deadline will actually be met with the available resources is a management problem. You can give your prognosis and weekly/daily status updates and they can decide if they need more resources. Otherwise you will continue working in sprints and deliver runnables - the same as any project.

Answer 7

Imagine asking someone to paint a wall, a house and then a whole street for you, how much time would you give that person to do it ?

Whatever your answer is, you'll be wrong. That's it.

There's no way they could be right about dates if they didn't ask the people who need to do the work what they think.

By the way, if you (as a team) accept these dates, you're in the wrong there.

You should ask for some time to work on this planning along with the stakeholders, so that you can set priorities depending on how easy and fast it is to get things done.

For example, maybe the final work will take twice as long as they thought, but they could use a beta much sooner than they expected.

All in all, you can't let people think you'll be able to do X in Y time if you can't or could be faster, that's your responsibility to make it clear about what you need in terms of details and time.

Answer 8

As someone has already pointed out before the manifesto says:

Individuals and interactions over process

I would suggest you have a look at the plan put forward and suggest changes to it. Remember the Manifesto says that the backlog is never final, it keeps evolving.

So you could take your suggestions to the team. If you have a valid reasoning and the team agrees to it, any product owner worth his/her salt will consider them and evlove the backlog to reflect the opinion of the entire team.

This is the point where it could go two ways.

1. Product owner and business agree with your reasoning and may increase resources to meet the deadline if that's a options OR they may select to drop some features to meet the deadline.

2. They may still want to stick to their own version against the collective opinion of the team.

If the outcome is #2 then this is not Agile.

If you end up with #1 then I would say the team is on the right track , because Agile is not about just the Devs "Responding to change" it's also about the business being able to respond to change.

Answer 9

Its not aglie planning no.

But if you prentend you dont know the plan and just work sprint by sprint. It could be aglie working.

There are always going to be dates and budgets. There is always a risk they will be missed or overrun and when that happens you are always going to have to fall back to a plan B.

If you have been working in an agile way then plan B is hopefully last sprint's demo