Methodology - Camsoft Development Process

Camsoft Development Process uses Lean Development Techniques to produce quality software that meets customer expectations, on budget on time. Lean Development Techniques were initially pioneered by Toyota and Honda companies to improve their development process (and to move away from traditional and outdated assembly line manufacturing principles) and later these time tested principles found their way into software development methodologies.

Since it is now a well known fact that waterfall based methodologies (traditionally coming from assembly line approach from manufacturing industries) has their deficiencies in software development, Lean Development Techniques are making lot of success stories as slightly more well known term of Agile Development. Following diagram is a depiction of Waterfall system which is practically (and unknowingly) still being used by most software development teams mainly due to challenges in upgrading the deeply set basic concepts.

Main problem above is that the methodology inherently makes it harder to adjust to the changes users may request as the project goes on when their understanding of the practical problems and daily usage of the system increases. Basically the development team and the client team gets only one chance to get the design right, get the development right and so on.

Following diagram depicts a typical Agile (or Lean) way of looking at it with more emphasis on responding to change. Here, the development is done by few iterations so the developers and users both get more than one chance to review what they are building and get those right. Constant feedback help drive the quality and reduce nasty later surprises at integration stages or at client expectations.

Agile Development is an umbrella term as there are many off shoots of Agile, which follow different fine grained processes and practices yet adhere to same Lean and Agile thinking and hence having lot of similarities in thinking. Xtream Programming, Scrum etc are few of such well known methodologies.

In Camsoft, we have started with Xtream Programming initially in 2006 and practiced Scrum techniques as well later on, during our experience, we have picked on different fine grained approaches (while firmly staying within the general concepts of Agile Development) based on what works for us in the context of software development in eSriLanka type of government projects. ePopulations Register and eSLIMS are two of success stories in our journey so far.

Camsoft Development Process uses several tools, technologies and artifacts for the proper execution and increase of the efficiency and visibility of it. Xplanner is used for the project management, task and stories definitions and progress tracking. This is a tool used in Xtream Programming. Cruise Control is used for the continuous integration and automated integration testing and automated unit testing. Cruise Control is a specific Agile tool introduced to follow up on continuous integration themes (not waiting until project end to integrate components, do it from the first iteration itself!) which can alert developers for broken units or their integration points. Bugzilla is used for the defect tracking and Mercurial for the internal Source Control. There are several artifacts, however burn out charts (based upon real time task progress and effort data from Xplanner) we find as specially useful.

Below diagram shows a typical task burn out chart from a project data. Initially at the inception stage, more tasks get added on to the project so the count increases. Since tasks could keep getting added in later iterations (dud to changes and feedback, which will be welcomed in Agile!) task burn out is slow at first but after a while they start to get reduced rapidly due to integration issues not appearing in the end and development can be fast due to Test Driven development techniques.

Tailoring of Camsoft Development Process for Allegations Management System

Following the spirit of Agile or Lean Development techniques, it is not required to wait to begin development iterations till end of design phase. So some of early iterations can happen a week into the project start (inception) phase itself. Development team can produce wire frames, project infrastructure, and a deployable vanilla build with the prototype pages but in actual project deployment structure. Hence there are room for few iterations (of 2-3 week long) in the development. Please refer to the work plan for more details. We propose 3 iterations to release testable integrated builds which will incrementally added with more features as the development progresses.

When requirements are uncertain and technology risks are high, adding too many team members to the situation makes slow progress for the team. Grouping people by specialty doesn't make much difference neither. Grouping people by architectural components (a.k.a. component teams) makes things worse eventually.

Camsoft has been composing teams by features which was identified as most successful approach to this problem. Camsoft identified that by launching fully crossfunctional “feature teams” they were able to operate at all layers of the architecture in order to deliver customer-centric features. In a large system this requires learning new skills.

As teams focus on learning, rather than short-term micro-efficiencies, they can help create a learning organization.