Why did our process cause us to miss our release date? [closed]

Question

I'm a developer on a team that has just finished some web development work. It was due for a release tomorrow but, as a result of a review by management, needs reworking. This will undoubtedly add a lot of time onto the estimate for release. We can't release what we have, since that's incomplete and we must start work on the redesign tasks now.

To me, this is a bit of a failure. We're now pushing the date back (whichever way you look at it). I believe our agile process failed us, because from my (admittedly limited) understanding of agile, such a methodology encourages iterations and I think our team is iterating wrong.

Solutions I've already considered include:

1. Designed up front with rigid stages of the lifecycle (i.e. "sorry, designs are done now, we're working of what we received originally"). However, this seems more like "waterfall" than agility.
2. We finish working on what we know is a design that will meet the release date, but may become immediately outdated. This seems very wasteful in terms of development effort if we're working on something that will be ripped out in the very near future.

Why did our process fail, and how could we fix it in the future?

Answer 1

I think the crux of your question may actually lie in questions you posed in a comment, rather than in the question itself:

Do you find it acceptable that release dates are not met?

The answer is... it depends. It really depends on the situation; on the project itself. If it is a purely internal project that is a 'nice to have' or some such thing? Yes, not really a big deal to push back the release date. Certainly better to take more time getting it right than to rush out something.

If it's a time-sensitive application where your client has stated if they don't get it by (date) they are dropping your contract and going with another solution? Absolutely unacceptable.

If (as is often the case) it's a grey area where meeting the release date is good but not absolutely required? Then it really depends. Which brings me to the second point...

I'm asking how our methodology here could be tweaked to prevent pushing back release dates.

At the end of each iteration, examine the project. If you see a problem such as this, examine your priorities and update the plan. Exactly what that means will depend on the situation. Pushing the release back is one option. Another is to take out scope, extracting certain features to a future release (or removing them entirely). Another (more risky) is to throw more money at it. That expensive tool your developers have been asking for that they say will speed up their work by 30%? Might be worth looking into. Deciding on these priorities is the job of the Project Manager (or Product Owner in Scrum, etc.)

All Agile is doing is attempting to have these decisions made early and often, rather than putting them off to the end. While that is generally a good thing, if the decisions being made are wrong (or are ignored entirely, etc.), then Agile certainly is not going to save you. But then, neither would Waterfall. With Waterfall, it'd just take you longer to realize you're not going to be saved.

Worth noting:

It was due for a release tomorrow but, as a result of a review by management, needs reworking.

If you had a whole bunch of iterations that management essentially ignored, and then they only took an interest near to the release date... that's not even Agile in the first place. That's a more traditional, Waterfall approach pretending to be Agile.

Answer 2

Both Developers and Executives Broke the Agile Contract

It was due for a release tomorrow but, as a result of a review by management, needs reworking. This will undoubtedly add a lot of time onto the estimate for release.

You have a basic process failure if the first time your management team reviewed the product was shortly before release. In particular, your organization failed to meet two of the core principles behind the Agile Manifesto. Specifically:

• Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
• Business people and developers must work together daily throughout the project.

You (collectively) didn't do those things. You are now apparently surprised that the project team delivered the wrong thing, and that the release date must move to accommodate large post-hoc changes.

These are systemic issues. The entire organization (including the project management team, the developers, and senior management) should work together to fix a clearly-broken process. At this stage, it is also likely the company needs an outside agile coach to help identify all the process problems, and help your company formulate new solutions.

Whether or not your company fixes the underlying problems is ultimately the responsibility of senior management. Project managers and developers can only recommend; the executives must take ownership of strategic decisions for the company.

Answer 3

I would encourage you to sit with your team (perhaps in the retrospective) and take a look at the values in the Agile manifesto: http://agilemanifesto.org/

Customer collaboration over contract negotiation is something to consider spending some time on as a team or selling to your stakeholders. You may benefit from holding stakeholder demos more frequently. The goal is to get iterative feedback from stakeholders early and often, and respond to changing requirements as your product grows closer to an end vision. I strongly believe, and my experience has shown, that the end of the project is not the first time that your stakeholders should see your deliverable. It will very frequently be underwhelming and require rework.

Compare the values in the manifesto to the values displayed by both external stakeholders and your team itself. Perhaps you can start a dialogue with those whose expectations have not been met. Best of luck to you and your team!

Answer 4

Your thinking assumes several fallacies which have been evidenced time and time again.

• The idea that software engineering is accurately estimable (it's not, estimates merely become more accurate as we progress towards completion). A healthy backlog of work with some basic estimating and a maintained burn-up chart would have shown that from the start.
• The idea that the business are not allowed to change their minds. They are. They are paying. Theoretically if they want you to refactor the same 10 lines of code every day for a year they can ask you to do that. Your options if you don't like the business changing their mind is to quit and find a new business who believe will not change their mind.
• The idea that requirements are ever truly fixed. (They are not except in cases of legislative compliance and possibly construction/architecture)
• The idea that rework is bad (It's not if we learn from it and make a superior product in the end)
• The idea that the code is what matters (It's not. The code is what gets you to the thing you are trying to accomplish. Code is not a sacred pet, it is cattle we sacrifice as and when we decide it is the right time to do so)
• The idea that dates drive delivery. They don't. You need a strong individual to communicate that to the Sponsor and you also need to understand that. Dates don't drive delivery. The delivery drives the realistic date by demonstrating when the current scope is likely to be completed with the current resources working to the average pace they are completing engineering tasks.

Agile is not the problem; how can it be since it is simply a set of values and principles about working collaboratively and prioritizing working software?

What you are actually frustrated at is the incremental delivery without fixed requirements. However, consider the following scenario...

Requirements and design are fixed up front and you spent 6 months in a waterfall delivery only to conduct a Big Bang release and then the business change their mind or market conditions change.

Wouldn't it be more beneficial to have a fluid design and commit to some small slice of working software which is then reviewed to make sure you are on the right track?

You are looking at this the wrong way round; you are seeing wasted effort instead of seeing that the review process is working for you. It has saved potentially many more months of developing the wrong thing.

Any developer that ever told me I don't have the right to change my mind about the product I am executive sponsoring is one that better start looking for a new job.