All developers have deep pride in their work, or at least strive for it. This is why I’ve always aimed to be the most technically adept and knowledgeable person in the Shinetech workgroup. I find it highly satisfying when clients’ feedback includes no bugs following testing and when they are pleased with the codebase quality. I liken good developers to creators - we feel our work is part of us. As a creator our work is our creation and when we hear feedback such as ‘your solutions are fantastic and have no defects’, it’s like saying ‘your child is beautiful and smart’.
In May 2004, as a part of my first project in Shinetech, I completed a small project of around 10 days’ workload for a new client based in Canada. I can still vividly recall my happiness when our work was recognised. Since then I’ve been motivated to solve client’s problems and puzzles with solid skills, whilst being unaware of the value of agile project managers.
I came to realise that although strong tech skills are the fundamental basis leading to project success, they are not the only determining factor. In June 2006, I started getting involved in a project with the adoption of the Scrum paradigm that I’d never heard about. Unlike traditional project management, Scrum methodology and project management is both iterative and incremental. Our team was asked to deliver working software with no defects after each iterorder to meet our client’s requirements, at the beginning of the project we worked overtime to deliver the product, however, we felt frustrated that the bugs in each iteration were inevitable. We gradually grew accustomed to Scrum and eventually received favorable reports from the client. That said, Scrum didn't come easy for me:
“Why do we struggle to produce higher quality products and what makes us inefficient?”, “Why does Scrum define harsh rules for the development team?”
“What do we need to develop in order to meet the client’s demand list whilst being unable to make changes to the alignment?”
These are things I thought to myself, until I became a project manager. I stopped thinking solely about my own coding tasks and began to consider how my work affects the overall project and how the team could work together to make more progress and succeed.
In January 2007 when I first got in touch with a client from the UK that would need our help to upgrade his DOS interface that was developed from ten years ago to Web, it didn’t sound like a challenging technical problem to me. Then I realised I underestimated the degree of difficulty in this project. First of all, the client’s industry is chemical engineering that we were not familiar with. Secondly, what the client wanted was not only system migration, but also the functions were required to be in line with the latest industrial development and standards.
From years of experience I realised that being an efficient learner is at least as important as being an efficient developer. Due to the tech world rapidly changing, we have to keep up with the latest languages, frameworks and actively engage with efficient approaches. Luckily I learnt about the Rational Unified Process (RUP), which is an object-oriented approach used to ensure effective project management and high-quality software production. From the 2006 Scrum experience, I studied the Agile methodology more systematically.
The manifesto for Agile software development says that we value: Individuals and interactions over processes and tools; working software over comprehensive documentation; customer collaboration over contract negotiation; responding to change over following a plan.
I came to grasp that the Agile emphasis is placed on empowering team members to collaborate and make team decisions in addition to continuous planning, testing and integration. Based on the Agile concept, my team simplified the RUP process and divided the whole complex project planning into multiple iterations with some functions and features to deliver at each. Delivering working software is our primary measure of progress, and we made subsequent changes in project planning after each iteration to make our team and project more flexible and effective. At regular intervals, we reflected on how to become more effective, and then fine-tuned and adjusted our way of working accordingly. Our team became an increasingly efficient and self-organising entity under the Agile mechanism. We also established a cooperative and communicative approach between the team and our clients which facilitates trust and transparency. The client has been happy with our team and stayed with us for ongoing system maintenance and support since 2007.
I used similar Agile methodology in other projects such as an enterprise system development project for a large company and an IoT related project in aquaculture industry, that both received good feedback on delivery from clients. In my opinion, Agile has become an enjoyable process for me and it is a process that drives our team constantly to move forward, stay motivated and become enterprising. Through learning and engaging in the client’s field and industry environment, we understand what values clients truly want to achieve and this is why we interact and collaborate with all stakeholders with passions and sincerity.
We have used ODC to successfully deliver a large number of projects and the benefits of ODC are far more than the items mentioned above. But as one type of the cooperation model, what ODC can do is still relatively limited; it's not that easy to deliver a high quality service under ODC model.