The First Mess
We started off very well.
Concept design of the products, wire frames, draft design, and basic modules are planned and executed nicely. We did the wire frames very quickly and outsourced the CSS part.
However, when the first alpha version came out, it didn't look like what it was supposed to be. We planned for a smooth tool for blogging. With keywords and tags, navigation will be superb.
It turned out that there are tremendous piles of bugs. Drag&drop did not work. Bad architecture of storing was implemented. Sign up module is off and on (if I say on and off, it means more on than off, right?)
The worst part is the checking process.
Even worse than that, our junior programmer seemed to have little understanding of our UX design.
Well . . . I should not come up with the idea of letting our junior run the whole project at the first place.
It is fair to say that …
We dragged our CTO to focus on the project. Previously, we thought he could jump in when things are quite ready and we need high tech stuff. Of course, devil is in the details and it is a naive thought to think the project is so simple that a junior programmer can handle the whole thing.
I have no IT background although this is not my first startup; however, I still have no clue how to manage the project best.
We were lucky enough to meet Tony. He is a veteran project manager in an IT company.
Discussions after discussions, Oak and I agree that we should do Scrum for the project.
Scrum is an iterative and incremental agile software development framework
You know better than me for sure. As of now I have ~1 month of Scrum experience. What we found is our communication is much tighter and we sync in term of works much more. Scrum just brings all the transparency back to the project. The concept of roles play helps when most of the time team members do not know what should he/her do. Daily standup encourage us to communicate and put the problems on the table.
Programmers have tendency to keep the problem with themselves and dive in to spend hours and hours to fix an issue. We were trying to cut this behaviour short. Daily standup is a chance to make an easy observation on each programmer.
We researched more about other startups and put more frameworks into play.
We found that we wasted 30% of dev time to analyse an error, bug, in the system. If you guess that we are thinking about TDD, you are really following our situation. The time of implementing TDD might yield us in time-saving very quickly given that we will keep adding and adjusting modules. I do not know which stage of a startup suits TDD the most but I think this might help us for diagnosing issues on the project.
I would say many issues of startup are solved. We just need to look around and reduce our attempts to reinvent the wheel.