Review of Projects and Crystal Clear Methodology

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.

Essential Properties frequent delivery (one month - one-quarter) reflective improvement osmotic communication (optional) personal safety (optional) focus (optional) easy access to expert users (optional) a technical environment with automated tests, configuration management and frequent integration (CI) Strategies exploratory 360 early victory walking skeleton incremental re-architecture information radiators Techniques methodology shaping reflection workshop blitz planning Delphi estimation using expertise rankings daily stand-up meetings essential interaction design process miniature side by side programming burn charts

Process project cycle delivery cycle iteration cycle integration cycle reflection Work products sponsor: project map release plan project status risk list iteration plan viewing schedule business expert: actor-gola list use cases designer-programmer: screen drafts system architecture source code common domain model design sketches notes

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).

The Review

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.