DevOps in the Enterprise

Throughout my consulting career, I have come to find that a great way to establish your software engineering processes, training, best practices, reports, and metrics is to build a center-of-excellence (CoE). When complete, a CoE is a team, or entity, that provides the leadership and governance in a focus area. Often the leadership is in the form of items such as, training, documentation, metrics, reporting.

A CoE is a “buzz-wordy” name, but CoEs are very effective in making sure the projects are on the “right track,” risk is properly managed, and that you have what you need to be successful. A CoE is a group or body that supports a certain focus area through leadership, governance, best practices, and knowledge. I have helped build, or have been part of CoEs at several enterprises, and over and over I have seen how departments, firms, and groups with CoEs have a greater chance of success than those without.

Recently, I helped build a CoE at a large firm in which there was a rollout and configuration of an application lifecycle management (ALM) development tool in the context of establishing a global ALM. The rollout was targeted for the enterprise level, and yes, agile development was a line item in the CoE. Enterprise level projects are always challenging and fraught with technical, managerial, and emotional issues. Many project owners think their projects and/or processes are so unique that no enterprise standard could ever support them. My CoE project was no exception.

We found the key to a good CoE and process adaption was some foresight and forward thinking, on the part of the CoE leads. Good CoE leadership must, as much as possible, be promotedon the part of the extended technical team with simplicity with respect to the CoE practices  and artifacts. Good CoE leads must also use a governance process to manage change, and to also address the needs of teams that may need more process items that are generally supported by the CoE. 

With respect to training, I believe in the train-the-trainer approach.  The train-the-trainer approach allows clients to better manage training costs, and it allows the client’s own employees to apply sections of training to the business needs. This is the training approach we used at my recent building engagement. Train-the-trainer also allows the clients and CoE leads to deliver the product training and also design the training options, such as web-based training.

Our immediate strategy focused on teams that wanted to join our ALM CoE. Teams that want to be early adapters of things like CoEs, generally, are motivated, want to improve, and will better react to change. We used web conferences and networking to find these early adapter project teams. Since change is always hard, we used our foresight and reached out to project teams that thought their success was hindered by a process that was either too cumbersome, too manual, or just too much. Teams in this situation are receptive to CoEs, as the CoE provides expertise, subject matter experts (SMEs), and pathways to improvement and success.

As you would expect, these project teams enjoy the education, documents, best practices, and reports that are part of the CoE. Our CoE, as with most, provides knowledge support, product supports tips, and useful metrics, needed by struggling teams. Some of the useful metrics we designed into the CoE included “build health” and “defects-per-development” Iteration. Metrics such as these help teams improve quickly and support continuous improvement. When successful, CoE early adapters can be some of the CoEs greatest supporters.

We also targeted teams that either wanted or needed to 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 modules the project teams initially adopted, the CoE was there with the artifacts, knowledge, and metrics that supported what was needed. As teams become more mature, the ALM tool and the CoE are there to grow with them. As a project teams mature, they can take on more of the CoE offerings. The project teams can measure new items, thereby generating improvement, and they can take on more complex use cases related to the ALM tool.

For those of you new to CoEs, know that it is a fairly straight-forward concept.  I have found that project managers comprise the foundation of a CoE as they are instrumental in setting the tone for the eventual success of the CoE.  The project manager leads the initial requirements gathering for the CoE. The project manager leads the creation of action items, milestones and schedules for the CoE building.  The project manager also manages the financial date related to the CoE. All this items are critical when a new CoE is starting.

CoE is an “overloaded” and sometimes mysterious term. To help demystify the concept, consider CoEs to be highly customizable, relative to mission and budget. Both project management and professional services can be considered a typical CoE in that they can be customized and scoped to fit the project team’s goals and budget. A CoE usually has the following roles: a CoE project manager (CPM), a CoE delivery team, a project team project manager (PTPM), and a project team. The deliverables of a CoE are typically project plans, artifacts, education materials, best practices, and reports/metrics.     

A CoE is formed and generally charter by the firm’s management, based on a project’s scope and mission.  As an example, consider a tool rollout. As the CoE begins, the CoE project manager creates a CoE project plan. The CoE project manager coordinates and collaborates with the project manager of the client project team, and the CoE project manager identifies milestones and risks, along with a plan to manage the risks.

The CoE delivery team delivers the tool mentoring and training according to the CoE plan. On-going measurements are made of progress, and productivity. Often, follow ups occur to make sure the CoE member teams are experiencing improvement such as fewer defects, increased customer satisfaction, and/or increased quality. These measurements are regularly reported by the CoE project manager to the project team project manager. Risk mitigation, if any, is also reported to the project team project manager.

CoE artifacts are created by the CoE delivery team and stored in the designated repository. These artifacts are used by the adapting development teams. As the project progresses, the CoE project manager schedules the educational and other services to be delivered to the CoE adapters. During the regular project management reporting meetings, the CoE project manager, using a project management tool, or a spreadsheet, will identify the status of the milestones and the CoE project manager may flag milestones at risk with a red color and on-track milestones with a green color.

As the tool rollout nears completion, the CoE will transition to the client project team. Before any disengagements occur, the teams on both sides need to agree that the project, processes, and CoE client team has reached a satisfactory level of maturing. he project team project manager continues to measure and report on the team’s progress.

CoEs are superb entities for implementing process and tools of varying complexity. I see them as incubators for good business design, and methods for addressing the firm’s needs. When implementing for ALM CoE for the financial services firm, flexibility was a key requirement. CoEs can be designed modularly with several options, allowing CoE adapting project teams to take on only the processes, artifacts and tools they need.

CoEs also promote continuous improvement, as key metrics relevant to the firm are designed into the CoE. The metrics allow the adapting teams to gauge their improvement. CoEs promote best practices and provide a repository for best practice documentation and reporting.

All-in-all, CoEs provide a well-managed path to success for the CoE adapters. Good CoEs are staffed with SMEs or provide access to SMEs. If tools and products are involved, the CoE provides education, support, and tool and product best practices. I find CoE invaluable for successful implementation of products and processes.