Jan 09 2008

Revolution: from CMM5 to Agile

Published by xiaoming at 8:06 am under Tech

I recently worked for a client who has been in the stage of CMM5. After long painful struggling of heavy documents and poor quality of production they decide to give Agile a try. Their plan is to start at the point of upgrading their major network management system. Off the top of theirs heads is to refactor the code, add tests (unit tests, system tests), and optimize the software development process.

Things did not start as they expected. Problems came into the project team as flood. Some of the problems are

  • How to do TDD?
  • How to refactor Java or C++ code?
  • How to write unit tests?
  • How to automatically do GUI test and system test?
  • How to apply common Agile software development process under their CMM infrastructure?
  • How to make the agile process keep going on and on and lower the risk of rolling back?
  • etc.

They don’t know the answers of those questions and unfortunately they have a extremely complex software development process which depends on documents output very much. Basically, it constructs under a typical IPD process. The team that I am working with has almost zero knowledge or experience of Agile.

How to bring such a team which follows a complicated process for a quite long time into the agile world? There might be three things that you could do in order to make it happen.

Firstly, IDEAS!

Brainstorming, ice-break, stand up meeting, retrospective, testing everything and etc. Fill the team with all good ideas and practices of agile as feeding the Beijing duck(If you know the story, Beijing duck was forced feed each each meal). While, those good practices and ideas are not the core of Agile. During the each session of training, coaching or Q&A, the core message that we delivered is “Value driven spirit” and Lean project management methodology.

Team build is also the major task in this stage. When I came in the office at the first time, I saw a silent team. There was no group discussion, everyone works on his own and a few communication. Let’s burn them up, agile games were introduced one by one at the beginning of each training or meeting. Then, I encouraged a couple of senior people to coach those junior guys. Prize and appreciation were sent out every a couple hours in order to encourage the whole team to THINK, COMMUNICATE and TALK. It was ready to go forward to next step, when the trust was established in the end of this stage.

Secondly, Process improvement.

The client is using IPD process to manage their software development process. Have a look at the typical waterfall process below.

IPD process

You can see huge amount of design description, requirement description, and software description, HLD, LLD documents were written during the whole process. At each point, those documents must be delivered due to the concept of CMM. Meanwhile the quality of the software was not well verified because of less monitoring or feedback during the whole process.

Based on their current process, we figured out a improved process which is attached below

IPD process

From the diagram, we can see, the design requirement document (DR) was written in the format of release level stories which were broken down into iteration level stories. These iteration level stories forms Design Specification (DS). The advantage of this change is that we merged DS, SRS and other documents which overlapped a lot into iteration level stories. They could be developed in each iteration. We saved much effort of developing those documents instead that we focused on the quality of the software.

Another shining point of this improvement is that developers/testers do not have to wait for the delivery of these design documents before start coding or testing. On contrast, they get the first set of stories from SE(System engineer) and started coding right after those stories were created. Earlier developer started coding, Earlier the product would be delivered. See the time that we saved on the diagram :-)

That has not been all. Step three, do at least four iterations!

People who is doing CMM always have doubts of Agile and its practices. It is supposed to happen and it is really OK. Let’s roll out based on the hard work that we had done. After three to four iterations, people who have doubts saw something new, continuous integration environment, automatic testing tool, deep code refactoring, 100% unit test coverage, TDD, system test automatically, more communication, pair switching, design discussion, and etc. All these activities turned vividly. The project team was happy and relax when they were pairing and coding. Less stress make them think more. Think how to do things in a different way; how to make this test more efficient, how to refactor this piece of code in a effective way……. Many good things happened in the project. The quality of the product was improved because the coverage of the UT, ST, regression test and smoke test. Team work more efficiently because continuous integration tool, automatic GUI testing tool and etc.

Before we launched the project, we would not believe that a CMM5 organization could convert to agile so successfully. However all this happened pace by pace following the ideas of “value driven and lean”.

For me, another successful project as a PM :-)

Bookmark on del.icio.us

Trackback URI | Comments RSS

Leave a Reply

Creative Commons License
This work is licensed under a Creative Commons Attribution-Noncommercial-No Derivative Works 3.0 United States License.