During the last several months our team came across 3 projects with the same issue – customers had the “almost done” project (usually customers state smth like “85%” or “95% done”) but they could not launch it, because the bug fixing process was endless or the “last crucial” feature was almost impossible to implement. Almost all of them were startups. We performed code review for them to be able to answer if we can handle it. From inside the products looked very similar. I think I even could tell all their development history by looking at these layers of code, covering each other like patches in a crazy quilt. We usually ended up with these clients arguing about one question – “Rewrite or do not rewrite all of that”. So I decided to write this post about the BIG rewriting.
Development seems to be one of the slowest things on the earth – I hear so many complaints about it’s slowness every day. “Why we can’t do that in a day instead of a week?”, “We missed deadline because your developers are too slow, they should work faster!.”
Sometimes project managers think that the team they got is the slowest they can imagine. And they dream about making it 2 times faster (I mean “work 2 times faster”). But the fact is that there is a big chance the team is pretty average and managers don’t get the difference between “make the flow faster” and “make the team work faster”. They somehow think if the developers start typing 2 times faster everything would be fine with the schedule.
A lot of software development companies have the structure based on discipline – you can come across development department (which can be divided by discipline too: mobile, front-end development, etc), design, QA, etc. Sometimes some mixed disciplines teams are formed for the project, but they depend a lot on the departments and members of these teams are not full time involved into the teams and report to their “manager” – head of department, for making their own tasks. So you can see something like “Ok, project failed, but the QA department work was wonderful!” Who cares, if the project failed?
When we talk about the development process in outsourcing with my colleagues we usually “start” project with development phase: “So, we got that project and started with the team our sprint 1”. It is the most often phrase you can hear about the kick-off of the project. In the books about scrum you can find a lot about sprints, but so few about sprint 0 and preparation to the development. They start with “Ok, we have a list of features and we need to estimate them and get a backlog”. But where from we get this list of features? We start with design and then hang this design to the developers? Of course, not. We need a good Sprint 0 with a team to be able to start development. And then I discovered that we even need Sprint -1, where we go through the analysis of the project idea.
I just want to share my practical experience, which suits for the outsourcing software development company, that wants to deliver better product-oriented service. I am surprised how far from that we can be in some of our big outsourcing leaders.