Taking over someone else’s project is akin to adopting a kid. It was not you who gave birth to them, but it is your duty to help them grow up to be the man. Everyone who commits to taking such a responsible step should be ready for a number of issues that will have to be solved on the run because product development is a continuous process.
So, today we’re talking about the danger of someone else’s misdeeds, learning how to gain the trust of a client disappointed in IT due to their negative background, and why it is important not to refuse such offers. No unnecessary data, just our own experience and insights. Well, what you are most likely to face when deciding to take someone else’s project to the finish line.
Bags of bugs left by the previous development team
The ideal scenario (and you should insist on it) is when the previous team transfers the project step by step to new developers. At the very least, such an approach will give you important insights and foundations and help you concentrate on essentials asap. Since speed and organisation are important, there'd be no time for self-exploration.
Thus, one of the projects we “adopted” was a complete mess. The program itself was unstable, there were errors jumping out behind the corners like monsters in a bad horror movie getting on users' nerves. To add to the confusion, we had to keep driving in that clunker, fixing, modifying and optimizing it on the run. That was the Client’s business need and we were aware of it in advance. But still It all looked sad and irresistibly difficult.
Well, we all know here that patience, hard work and perseverance always pay off, and this pretty obvious formula really helped us make the monsters problem go away. However, many things also depended on our project manager (PM), who was able to start moving that pile left by the predecessors. And correct prioritization played an important role in it.
Many tasks - no prioritization
The biggest challenge we faced working on the case was the problem of scheduling and prioritizing tasks. On the one hand, the show must go on: the product required further continuous development, on the other hand, we were detecting many different errors in the program all the time that needed to be urgently corrected.
The previous team PM who helped us accept the project also pointed out this problem. He said that they tried to plan the workflow, but failed, and strongly recommended us to stand the fact that “it is impossible to systematize the chaos”. Our PM could barely put up with it, though.
The project was huge, the system was complex with a lot of functionality, and all this stuff needed streamlining. We collected all the current tasks (the list was impressive) - and started arranging planning sessions with the product owner. These calls helped us understand the system, how it worked and what additional steps should be taken. We built a paradigm: what was missing at that moment, what’d we be paused, and what we’d do later (when we’d get around to it), and what needed to be done first.
Development methodology: to change or not to change
For a long time, new tasks were a higher priority for us. Then the Client-Executor system became a little more complicated: the Customer got a new user, and it was necessary to add additional, personalized functionality to the software we were developing. So, the needs of the new “player” also became the priority.
Well, we weren’t confused and carried out another prioritization, highlighting the P1 group, which included about 10 tasks of the first priority. Unfortunately, it was very rarely possible to create gradation between them, at least two tasks were always equally important. We used different prioritization methods, some of them helped, the other didn’t. In general, several tasks of the P1 category kept standing in front of us all the time, and it was almost impossible to choose what to do in the first place, so the constant asaps were still actual. Just imagine yourself coming to your office every single day with a specific working plan to find new emails marked “hot” in your inbox that change everything. “This won’t do,” our PM thought and decided to change the development methodology.
The thing is, we worked on Scrum that time. We had two-week sprints, and everything that got into development was brought to the end. But due to the project dynamics, the constant priority shake-ups, something had to be changed all the time, some tasks had to be removed and new ones were added and required immediate consideration. Our team worked productively enough, and somehow we managed to do some stuff beyond. The guys didn’t want to throw tasks out of the sprint: once they were set up, they didn’t like being jammed. As a result, the development process turned into an endless race, which could not but exhausted and bumed the team out.
In the end, our PM made the decision to switch to the kanban methodology. As the tasks began to flow, the things gradually dropped. Asaps, hot features, hot fixes arrived as before, but in kanban it was easier to manage them. We built a good process, found the limits that the team could use at a specific development stage, and carried on working on the project happily ever after.
Okay, of course, it wasn’t that easy. To be honest, that “adopted” project was a real pain in the neck with so many bugs, pitfalls and unforeseen circumstances (for instance, the Customer’s unscrupulous contractors couldn't be more unscrupulous if they tried, but we did have to have them). Seriously, no one should experience that.
Unless you’re a race car driver having jumped in the rally called Experience & Reputation. That’s exactly why we do not regret being involved in this adventure. Firstly, such challenges bring the team together. Secondly, sophisticated tasks are essential for professional development. And finally, it just feels so good to carry good ideas out all the way till the end (even if you didn’t launch the process) and to help smart and hardworking people push their brilliant message to the world.