Translate

February 26, 2018

The 'obsoletion' of the CC in an agile world...

... or 'The incompetence of the CC in an agile world'. This is the first in a two part blog post on Competence Centers.


Summarising

Competence Centers have no place in agile environments. They're a remnant from the past in which IT was considered to be something to reduce costs instead of creating value. In the new world, CC's are incompetent, which means they should be dissolved and the freed brains of the specialists are available to work on other (business) challenges.

They still exist, you see them everywhere, the larger the organisation the more prevalent they are. The CC and I don't mean Carbon Copies or those long lists of recipients in emails that the sender wants to be aware of the message she's delivering. I am talking about Competence Centers.

What is a Competence Center?

Competence Centers, once upon a time, made sense. Not always as clearly as one would think, but with an overzealous tendency of making IT more efficient, centralization of capabilities seemed to make perfect sense. You can find these centers in 'normal' factories as well, specialised areas in the factory that is optimised to do something special. More on the topic on efficiency and effectiveness can be found in this post. But obviously every decent book on Lean Manufacturing would be fine as well. And while you're at it, take a look at the classic 'The Goal' by Eliyahu M. Goldratt.
There's a huge benefit of having Competence Centers, CC's, in organisations where you want to improve IT's efficiency, especially when the aim is to improve cost-efficiency. In other words, when you want to reduce IT costs to the max, you're best of by introducing Competence Centers. Mind that CC's are to reduce cost, not improve production. This is a misconception I see a lot.

Before I start explaining the benefit of having CC's in your organisation. Let me explain what a Competence Center is. Here's what Gartner has to say about it:

competency center

An organizational structure used to coordinate IT skills with an enterprise. Competency centers provide expertise for project or program support, acting both as repositories of knowledge and resource pools for multiple business areas. Skills-based competency centers, the most common type in an information services organization, are used for application development, software language skills, data management, Internet development and network design. Within the enterprise, it is increasingly common to find competency centers (or shared services) for travel, finance and human resources. Repository-based competencies act exclusively as sources of information.
As things with Gartner go, ... they're typically right on target, but so easy to misinterpret. And then there's the problem with dates. Most people that read Gartner reports forget to check the date. Every article Gartner publishes is dated. And as you know, in today's world, a year or two is a lifetime.

Anyhow, Gartner's definition of a CC is spot on for most enterprises. But just to be sure, within the context of this post, a Competence Center is a centralised organisation body in which a specific capability or function is concentrated to be used and reused by as many teams, persons, departments within the organisation.
The benefit of having a CC is obvious. By concentrating an organisation's expertise into a single department, the organisation is in a position to leverage that expertise to the fullest... in terms of efficiency.

Within a traditional organisation this makes perfect sense. IT is enabling the organisation to be as efficient in conducting its business as possible. This can only be achieved when IT itself is extremely efficient. Resources within IT are therefore to be utilised as close as possible to 100%. By introducing CC's, the organisation can achieve this goal. Especially because the work done by the CC is specialised work. By putting all experts in a single department or even a single location, the experts can optimise their processes and standardise their work.

Why Conway is relevant?

This works perfectly in environments where business products are developed in relatively long lasting projects with separate phases for analyses, design, implementation, testing and deployments; Waterfall projects. The CC's work really well because they are required to act for a specific project on preset milestones in which they are asked to deliver one or more of their specific standardised solutions. And they are invoked only once or twice during the project, everything is optimised around the 100% utilisation target.
Scaling is either not necessary or required within limitations. Conway's law is at help here as well. In short, what Conway says is that the social structure of an organisation, the organisational structure, reflects the architecture of the software that is developed/used within the organisation. Look around and you see this holds true for pretty much all organisations.

So, with Conway on our side, we can state that CC's and their economic justification (i.e. resource optimisation) warrant their existence and strengthens their position as well. The important aspect here is that in a stable system, being an organisation that evolves gradually yet constantly, the requirement for a CC is a self fulfilling prophesy. The Competence Center is therefore a necessity by design.
Which should sound pretty scary to you once you think about it. But there's nothing to worry since it makes perfect sense to have these centers in environment where waterfall is applied to do projects. More over, when governing waterfall projects using PRINCE2 or alike methodologies, it becomes even more likely that the best solution is the use of CC's throughout the organisation.

Disrupting the CC

So, where's the incompetence of the Competence Center you're asking yourself. Well, it lies in the fact that recently there have been a number of extremely disruptive developments in how we apply IT in our organisations.

Scrum

For one there is Scrum. I deliberately don't call it agile. Scrum typically revolves around developers being able to discuss what they're developing with their users in (extremely) short timespans. This means that once a developer is working on something and actually believes that something is finished, the user comes into play to verify, or rather validate that view of the developer. Typically and preferably, the developer will start working on the functionality once it's clear that so far everything is perfect, or at least good enough for the user. What's that got to do with the CC? Well, if the CC comes into the equation and between the developer and the user, there's a CC that needs to work its magic... well it will take longer for the developer to hear that user is either happy with or needs some adjustments to the work of the developer. Because the CC is involved several times over the course of product development and at seemingly randomly chosen times.

Cloud

Then there's the Cloud. A little piece in cyberspace where apparently anything goes as long as you have a credit card. Of course this is initially always the case, but very quickly Cloud usage in any organisation matures. The disruptive part of the cloud with regard to CC's is that the business model of the Cloud vendors like Amazon, Google and Microsoft, is to get as many solutions in the Cloud as fast as possible. Which entails two very important aspects. For one, everything is automated or can be automated and as consequently can be expressed in code. And secondly, everything is abstracted to the point where intrinsic complexity of IT solution is removed by wizards and mouse clicks. Where the likes of Amazon, Google and Microsoft actually make the transition from wizards in a browser to coding in an editor to be almost zero-effort. Point being that the CC can be circumvented easily in Cloud environments, not because it's the Cloud, but because the Cloud is removing the raison d'etre of the CC. It's unique position within the organisation's processes to get things done is not existing in the Cloud.

Continuous Delivery/Deployment

Continuous Delivery/Deployment practices are a third disruptor I want to mention. Here the disruption is caused by the fact that effort is put into reducing the cycle time between idea - product - insights (the build-measure-learn loop from a business perspective) as much as possible. Cycle time reduction is achieved predominantly by automation. CD Pipelines, sets of integrated tools used by teams responsible for getting an idea as a product into the hands of a user and getting feedback from the user are team specific. Addressing the specifics of the product developed and the markets using those products to allow for fine tuning in order to get product/market fit. Together with Lean practices, the Continuous Delivery or even Deployment paradigms build on concepts that help further reduce the cycle time. Which means that there is within a given timeframe more opportunity to go to production. Since the process requires the involvement of the CC, the CC is required more often to act.

What about other disruptors?

Obviously there're a lot more aspects and disruptors that are putting the CC to shame, but the above are the ones I see most often causing a problem with Competence Centers. And the reason why they are so problematic in organisations that rely on Competence Centers is the fact that these are implemented from a mindset that centralisation results in more efficient resource utilisation. Thus resulting in lower cost. And there's your problem, because the CC's are bottlenecks in the process. It's fine when it is possible to plan for their involvement in the process, because one can do some proper resource planning. But when the CC is called to action whenever needed, they're causing delays. The problem is caused by the lack of elasticity, which obviously is needed. And we all know how challenging it is to scale a department up and down. Especially one that was created because of its specialised nature.

Scaling is always a problem

So scaling is a problem and it is needed to be able to support all product developments Just In Time an in such a way that you don't need to plan for their services or make reservations.
The only way to handle this, as you might have guessed is by automating the process steps the CC would perform. Machines are excellent when it comes to scaling. So the CC can only be competent within the agile enterprise when it automates its own activities.
Far fetched? I think not! Think about IT infrastructure teams that are extremely specialised. Provisioning servers, connectivity and storage is not a trivial task. You need specialists to do this, especially when it needs to be done within quality margins. And infrastructure was one of the first areas where automation was used to be able to support the JIT characteristics of agile product developments. Automation and virtualisation resulted in... tada... The Cloud.

Automation has been the culprit for the demise of the infrastructure teams, sort of. Because the automation functionality was given to the product developers, who started provisioning infrastructure from a self-service portal.

The trend is that CC's are becoming bottlenecks in processes. The problem is solved by widening the bottleneck through scaling of the CC by adding resources. Which is costly if at all possible, and automation is used to fix this. Automated processes are fool-proof in many cases, and therefore development teams can access the automated processes all by themselves. The CC is rendered obsolete.

Efficient or Effective?

Is this a problem? Not from an enterprise perspective, because less CC's means less costs. So more (cost) efficient. And on top of that, or even more importantly, the CC's are obsolete because their tasks are automated, therefore more consistent in execution and they can be executed at will. Or if you will, just in time. So more effective as well as more efficient.
From a human resources perspective, there is a challenge. Because the experts in the CC are no longer required since the machine made them obsolete. Or did it? In fact, the specialist made herself obsolete. As an organisation you want to cherish these specialists because they understand how to fix process bottlenecks, often have an engineering mindset and are most likely able to adjust and become a specialist in other areas as well. Or even more desirable, they become platform engineers that will maintain and further develop the platform that was once maintained by the CC. Not in a manner of keeping the lights on but further developing the platform. Just like the infrastructure engineers created the Cloud platform and continuously develop it. Not as a Competence Center, but as a platform team.

Hence, Competence Centers are incompetent in agile environments, but that's an opportunity as it means that perfectly automatable functions no longer keep the engineers and specialist busy with repetitive tasks and allows them to work on not automatable functions we tend to call platforms.


Thanks once again for reading my blog. Please don't be hesitate to Tweet about it, put a link on Facebook or recommend this blog to your network on LinkedIn. Heck, send the link of my blog to all your Whatsapp friends and everybody in your contact-list. But if you really want to show your appreciation, drop a comment with your opinion on the topic, your experiences or anything else that is relevant.

Please subscribe to my blog to show your support.

Arc-E-Tect

No comments:

Post a Comment