The last sprint to the end of the project is always an exciting time for the team has worked so hard to get there.
They have fought through all the trials and tribulations, the late nights, the early milestones (and the late ones).
Through the good and the bad – they have stuck together, making it out as one cohesive team, stronger for what they have gone through. When that final push comes, they are all jumping in to help to see it go out the door and the first user log on – not matter your role on the project, everyone is doing everything they can to see it go out the door.
It’s an incredible feeling of teamwork and accomplishment and one I look forward to when shipping.
This is how a project should end.
But sometimes we get overzealous and anxious as we get close to the finish line, we start seeing other projects coming in behind is and think it would be a better idea to move people around and onto new things.
Same amount of work, but now less people – not a good combination.
You can read this and think – “Well that’s just plain silly, I would never do that” – but we all have at some point in our careers.
If there is any reason to not do this – think of those feelings when you shipped something that you worked hard on for the last six months – would you want to have those feelings of success and accomplishment be replaced with feelings of not being able to complete all of the project’s bugs on time? Or being late because the team responsible for deploying has no longer in the know as to when your project was going out the door?
Let the team finish the project, then move them around – it’s worth more to you in the long run.
Want more? Check out my book Code Your Way Up – available as an eBook or Paperback on Amazon (CAN and US). I’m also the co-host of the Remotely Prepared podcast.