change their development methodology; agile development’s popularity has led to many project teams to wanting to switch over. We promoted the ALM CoE‘s agile process support to teams that were interested in agile development. The CoE’s agile standards, ALM tool, education, knowledge, process templates, metrics, etc. attracted many teams to the ALM CoE. Again, the agile project teams were drawn to the CoE as it provided such items as agile process templates, tool standards and training, and SMEs. The CoE made the transition to agile less risky.
Groups that were the most adverse to change were the most challenging to attract to the ALM CoE; these are teams that are best taken on later, after several the early adapters, and later wave adapters have experienced success through process improvement, like increased customer satisfaction, decreases in defects, faster time to market, and success process transition to something like agile. Being successful gave our CoE team more credibility. We also gave these teams the option of a small, tightly scoped evaluation period using the CoE tools, processes, and other artifacts.
The work still goes on, and there are still several teams that need to migrate to the ALM CoE. However, to date, despite many issues, and struggles, the teams that have joined the ALM CoE have experience improvements, and/or successful process transitions. Not all migrations were easy and some were difficult. Some difficulties included the adjustments made to the ALM tool, occasional technical problems with the ALM tool, confused users, users that were determined to be confused no matter what happened or what we did, and integrating the CoE into team with mature processes.
However, good project management, and a dedicate consultant and client team lead to success. We had to resolve many ALM tool technical issues, such as installation problems, occasional run-time errors, integration issues with other development products, upgrade errors, and training problems. We also recognized projects teams that made the transition to the CoE. Recognition really helps with relationships, and project team moral. The problems with the ALM tool were mostly resolved by working with the vendor’s product support team.
Looking back, I believe designing flexibility was one key to the success of the CoE. The one size fits all is a tough sell. In this case, flexibility refers to creating a CoE governance process that will allow project teams to customize their processes, process templates. It also allows teams to adapt practices and tools that are relevant to their business. Flexibility allows teams to take on and adopt only the elements they think they need. Early on the client selected Rational Team Concert (RTC) for their ALM tool. RTC is very modular and project teams can select only the modules they need to use. The ALM tool has two usage flavors, the first being a web-client supporting dashboards, change management functions (defects, change requests, etc.), iteration planning, and reporting modules. The second flavor is a rich interface that supports all the web-client items and also layers on support for configuration management and build management.
The ALM tool is also flexible with respect to process and it supports customizable process templates. Therefore, if a team needed to keep their current process, the tool could support it. If a team needed to migrate to an agile methodology, the tool also has the process templates associated with agile. The tool has actually helped teams by provided a path for migrating to an agile methodology, which has made everyone’s life easier.
The flexibility and modularity provided by the ALM tool supported keeping adaption as simple as possible. No matter which ALM tool