How do you achieve the mind shift from a "waterfall" way of doing things to thinking iteratively? When this is done within the context of a CMMI ML3 process improvement initiative, the complexity increases a couple of levels and requires a careful and well thought-out strategy. This paper discusses some of the nuances of planning and executing such an initiative.
Iterative lifecycle models come in various sizes and shapes. One of the most well known and industry proven methodologies is the Rational Unified Process a.k.a RUP. There are many good reasons why an organization might decide to ‘go iterative’ but that is the not the main subject of this paper. We will focus mainly on the implementation and institutionalization aspects of rolling out RUP.
First and foremost, you need to be absolutely clear about the real goals & objectives behind deploying the Rational Unified Process in the organization. Some of these might include
- Adopt an industry proven software development methodology that lets your organization benchmark IT software development processes against those of best-in-class organizations.
- Leverage the efficiencies to be gained in terms of competency and skills management of existing and new employees and the benefits of working with mature service providers who might already have adopted the iterative methodology.
- Support the application development teams by providing a credible alternative to the waterfall lifecycle model thus moving away from the "one size fits all" approach.
The above reasons and the anticipated benefits would therefore comprise your business case and help you put together a project charter. Remember, achieving this mind-shift in an organization that is used to a conventional approach requires sustained effort and a clever strategy for stakeholder involvement and management. Often, a small project is set up for this purpose that looks after all aspects of the roll-out, not limited to process engineering, stakeholder involvement, deployment planning, coaching and migration support.
Now, the obvious question is: If RUP is an out-of-the-box process framework from IBM, what kind of effort would be required before it is ready for your organization. This is often a tricky subject because the level and extent of customization required is often based on what already exists in the organization in terms of process infrastructure, in-house expertise in iterative concepts, ongoing process improvement initiatives such as CMMI, regulatory and other organization specific requirements that have to be adhered to and the general readiness/resistance towards such a change. For e.g. in a green-field kind of scenario where no standard models exist, the Classic RUP (for small, medium or large projects) could be applied as-is and incrementally enhanced and customized to the requirements of the organization. On the other hand if CMMI model compliance is required, then the Classic RUP will need to be enhanced a bit so that it is fully compliant to all the model requirements, especially in areas such as Integrated Project Management, DAR and Acquisition process areas. In most cases, the process would also need to be tailored to other organization specifics such as quality gates, policies, re-usability across lifecycles, management reporting and other standard operating procedures in an organization.
Consequently, the deployment approach also plays a significant part in overall success of the program. Issues such as a pilot approach vs. a big-bang deployment need to be addressed. If the organization is not used to the iterative concepts, then a big-bang deployment of the standard Rational Unified Process could be overwhelming and often counter productive. In such cases, deploying a tailored lean process using a pilot approach would be more beneficial. Often it might also be wise to pilot the most important disciplines first before trying to deploy the complete configuration. While in pilot mode and before becoming generally available, there are several important things to get right.
Coaching and training of the practitioner community is arguably the most important part of this phase. One of the ways to support pilot projects using RUP would be to assign RUP coaches to hand-hold and guide them through this process implementation. It is important that the coaches offer a balanced view in terms of RUP process essentials as well as organizational imperatives such as CMMI (if relevant), adherence to Policies, Quality Gates etc. Coaching cannot however substitute for a certain amount of formal training in the beginning. Such trainings would ideally be Instructor led classroom trainings so that participants have a chance to clear up initial uncertainties and know what to expect from the coaches and from the Rational Unified Process. It is important to also get the coaches and the practitioners on a common gathering from time to time so that the best practices and lessons learned are not lost but shared between the projects. Such sessions also serve as a platform for communicating changes and organizational agenda around the RUP rollout initiative.
In cases where the RUP roll-out is within the context of an overall process improvement journey, the coaching of projects should take that into support for CMMI requirements. CMMI appraisals happen in three stages for most organizations–A SCAMPI C is conducted as soon as the organization has defined processes i.e. decided on RUP and made the necessary customizations. The process is then implemented for a few projects that often serve as pilot projects. The SCAMPI B appraisal validates process implementation over this sample of projects. A more rigorous SCAMPI A is then conducted to ascertain level of process institutionalization. The SCAMPI B and SCAMPI A appraisals require projects to produce a PIID (Practice Implementation Indicator Database) that shows direct and indirect evidences of process implementation and institutionalization. Projects often need a lot of support in putting together the PIID and more importantly to generate the required evidences. The coaches would play a big part between SCAMPI B and A (usually around 4-6 months) in making sure the process is institutionalized and projects are able to leverage real benefits from using an iterative approach to software development.
Now that we have the plans and essential activities sorted out, let us look at some of the typical challenges that one would encounter in this process. Most organizations are resistant towards new change, particularly if the change involves having to learn new ways of doing things. It is therefore imperative to manage such stakeholders, particularly the 'naysayers' from de-railing the initiative. Also, in trying to leverage or re-use existing frameworks and process models in the organization (such as process assets from a Waterfall Lifecycle Model), there is tendency to dilute RUP to an extent that it risks not being iterative anymore, but rather be seen as "old wine in a new bottle". A lot of thought has to go into selecting pilot projects that are good candidates for trying out RUP. If the projects that sign-up early on as pilots do not apply the process essentials adequately, it could result in bad press for the RUP rollout initiative as well wasted time and energy on such pilot projects.
Conclusion: The Rational Unified Process offers a robust framework for iterative software development and can be adapted to most organization scenarios. As with any such initiative, it represents a significant organizational change and therefore need to be managed and guided to its successful outcome.
