It has been 5 years since I started to set up the new branch of NB office, and I think it is probably a good time for the review of works now.
In the last 5 years, the size of NB office expanded from 1 single staff (me) to a total of 18 now, with 13 engineers, 3 testers and 1 PM. And the project size changes from internal and toy projects to the big ones of theme parks, banks, and government.
In total we have worked on 43 projects, among of which 8 projects did not get a happy ending at the end. Most of them still get released. Yet they were not released in the best shape, and the customer was not most happy about that. Sometimes it is due to the budget problem, and sometimes it's because the immature execution or wrong choice of technology.
Like many other things in the world, the success of a project need coexist of a lot of different factors, yet it only needs one single factor to fail the entire project.
Book of Crystal Clear
Starting from day one, I tried to apply what I learned from the book of Crystal Clear to the new office. I also read a lot of articles about scrum and extreme programming as supplementary materials, but the book has been the major reference for the office and team-building.
I really loved this book because it gave a flexible framework instead of a set of rigid rules. The book mentioned 3 core and 4 optional properties for project management. There are also a bunch of strategies, practices, and work products for the reference. Except the very first 3 core properties (frequent delivery, reflective improvement, and osmotic communication), all others are just optional, and you could cherry-pick what suit your team the most.
Here is a detailed list of all mentioned items. You are encouraged to get a book, it is a valuable collection of experiences and observations.
In my understanding, the whole picture should be something like this. First we set up a very rich soil using all the properties and techniques:
Then all programmer, designer, customer and project managers work closely with each other.
All team members meet up regularly and reviewed the problem of process, and reflectively improve the practices as time goes on (genetic process).
So I tried to list out all my projects in a table, and mark down how I could escape the failure if I selected the correct technique/practice by the time. The table should be something like this:
|Project Name||Result||I wish I had used this technique at that time|
|project 1||failed due to xxx||skill aaa|
|project 2||failed due to yyy||technique bbb|
However, when I compared the historical projects against the descriptions in the book, back and forth, I found that the problem is a little bit more complicated than that.
Some items are not process related. The books described a lot of ways to improve the process, but something just got beyond that.
People, individual persons, has great impacts on the success of projects nowadays. With great process and a low-quality team, you could accomplish nothing. Yet with the great team and poor process, you could still get something accomplished, though it may not be the same thing you want from the beginning. As all kinds of programming tools evolve in the world, the power of individual engineer is now bigger than ever.
So the dynamics of projects should be more like the following:
The talent, practice, and discipline should of individual engineers be as important as the process itself. The company should try to make the biggest effort to unleash the potential power of engineers, not only focusing on the best soil for the projects to grow.
For example, the coding style is something not related with consulting process. But with consistent and compact styles, it would improve the readability and maintainability of the code, and make engineers respect the code more. It makes the entire project more stable. It is mandatory, and should not be regarded as something good-to-have.
It should be same for some other core and non-process items, like unit-testing, research ability and presentation skills. I should explore more about that in another post.