4

A classic scenario: Revamp a website with a new color scheme and a left navigation bar.

After the team has started working on it for a while, upper management decides to go with a completely different color scheme and a 3-panel navigational/highlight design.

In terms of team morale, what is better/worse?

  • Should we call it quits and restart?
    • Cancel the first project and start a new project. New code name, clear out the old schedules and tickets. Possibly shuffle the teams a bit. Maybe have a quick post-mortem and launch party.
    • My concern here is that the team may feel that it wasted its time and never completed the project.
  • Or should we just treat it as a change request, and do as little change as possible?
    • Pretend it's the same project, tweak the schedule slightly as needed and have a quick meeting to inform everybody about the changes.
    • My concern here is that the project seems to drag on forever, with the fear that another major redesign may yet ambush us again.

Or maybe there are other options I have not thought of.

Improve this question
4
  • Are you working with an Agile methodology or a classic 'waterfall' style?
    – Cronax
    Apr 5, 2016 at 13:47
  • 1
    @Cronax: Currently using Agile, but I'm curious why it would matter.
    – Danny Schoemann
    Apr 5, 2016 at 14:35
  • @DannySchoemann How much does the change cost? Is the team being paid for their effort? Money isn't a motivator, but it can become a demotivator. See hygiene factors and motivator factors: mindtools.com/pages/article/…
    – Hey Romey
    Apr 5, 2016 at 19:38
  • 2
    In an agile environment, change is expected. The short term format of the sprints is intended exactly to help cope with this type of changes.
    – Cronax
    Apr 6, 2016 at 6:19

2 Answers 2

Reset to default
4

Since you are in agile, I would treat this as new information discovered about the project and change/update User Stories / sub tasks. You are still doing a website development, so the basis of the project is the same and the team will be the same.

Concerning the morale aspect. I would try some of the following (which may help in different areas)

  • Communicate with the management that this change will require a pause in the project to re-work it
  • Halt the project development and take stock of where all development is - put code into Git, document, test state. etc.
  • Re-plan your project to understand scope change and impact.
  • Take some time out - dependent upon the length of the project, if it is 6 months take a few days to gather your team in, if 1 month, then take a day, but a minimum of a day I think, to gather the team in and engage with them about how they feel, but basically help them to understand the change.
  • Shift around some of the guys in your team, especially if there are one or two that are particularly negative. You don't want that negativity going forward, it will infect the new project and will make it hard work.
Improve this answer
3

Putting scrum aside, is the application written in a flexible manner? Although scrum welcomes change, the way the application was written should be flexible as well up to some extent. if it is too rigid at the very early beginning, you should rethink how to cope with future change requests. Second note, i had seen scrum being abused about change. Even though scrum says that it responds to change very well, sometimes you need to assess the benefits and learn how to say "no" especially if the change request has no business impact or is too shallow as this may affect the project timeline and project budget.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.