0

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?

JᴀʏMᴇᴇ
  • 131
  • 7
  • @JayMee Yes, there's rework because iterative processes iterate. On paper, there's a trade-off between efficiency and efficacy, but it's a false dichotomy. Iterative processes almost always deliver better results over time when done correctly. – Todd A. Jacobs Jan 19 '17 at 21:23
  • Right, I've never had this much difficulty in conveying the meaning behind my question on a stack exchange site. Just to clarify, I'm not ranting at all. The words 'rant', 'whinge' etc. are entirely out of place. My question is really, really simple - in the scenario whereby requirements are changed last minute (prior to the previous iteration being complete), what is the best course of action? What should we do in that scenario? I'm not an angry developer, I don't blame anyone per se, I don't have anything to rant about, I'm asking for input into improving methodology. That's it, that's all. – JᴀʏMᴇᴇ Jan 19 '17 at 23:25
  • 1
    When requirements change, you re-plan. That means scope, schedule, and budget must all be adjusted based on the new plan. From the comments, you seem to expect to be able to deliver fixed scope on a fixed schedule, but that's not how project constraints work. If you don't understand how the Iron Triangle works in project management, and especially in agile project management, ask a new question on the topic. – Todd A. Jacobs Jan 20 '17 at 05:16
  • 1
    Related Q&As: http://pm.stackexchange.com/q/16372/4271 and http://pm.stackexchange.com/q/11664/4271. – Todd A. Jacobs Jan 20 '17 at 05:17
  • @CodeGnome - finally, you've identified an area I lack understanding in and have provided constructive feedback rather than focus on some mythical rant I went on. I will research iron triangle, I'm still no clearer on how in this scenario we can adapt to meet the release date and manage client expectations, but I don't expect people on here to be able to answer that by the sounds of it. I'm quite possibly done with pm.se, feel free to close the question. – JᴀʏMᴇᴇ Jan 20 '17 at 07:47
  • 2
    @JayMee You can bring it up on meta if you want, but "I blame our agile approach" sounds like a rant to me, and apparently to others as well. It may have just been a poor word choice on your part that didn't reflect what you really meant, but we get a lot of questions here that sound like the baseball analogy and that's how your original post came across. But the question was edited, and you received answers. Comments are not for extended discussion, but you can certainly address the issue on meta if you feel it's warranted. – Todd A. Jacobs Jan 20 '17 at 07:52
  • 3
    "I blame our Agile approach for encouraging this particular problem, am I wrong?" is an opinion-generating question of a type explicitly off-topic per our help center. Since the OP keeps rolling back edits designed to keep the question open, closure is recommended until the question can be edited to meet the site standards. – Todd A. Jacobs Jan 20 '17 at 16:44
  • 1
    @JᴀʏMᴇᴇ although you already accepted Sarovs answer, which based on the limited knowledge we have about your teams process, leaves nothing much to add: I think the topic is interesting, and I would like to find out more about how your team was working.

    For instance:

    • How did your iterations look like? How long? How many already?
    • Have there been previous releases?
    • Was the new functionality regularly internally tested / presented to management?
    • On what basis and how long ago was the release date set?
    • Was a dedicated product owner and / or product management involved?
     – trueunlessfalse Jan 24 '17 at 14:45

4 Answers4

7

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.

Todd A. Jacobs
  • 50,264
  • 7
  • 59
  • 177
6

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.

Sarov
  • 14,768
  • 5
  • 33
  • 62
2

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!

Casey Sprague
  • 167
  • 5
1

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.

Venture2099
  • 4,075
  • 18
  • 38