The bright future of the CC in the agile world

This is the second in a two part blog post on Competence Centers. Read the first post here.

Summarising

The role of Competence Centers in large organisations is diminishing. In many organisations there actually is a notion forming that these centers are obsolete. Considered being a hindrance in an ever more agile environment, the roles of the engineers in these CC's are no longer found in job descriptions. But on close examination, we see that where Competence Centers are fading a way, platform teams are arising as the new home for these experts.

Recap

In my previous post I elaborated on the reasons why in today's day and age of business agility the Competence Centers are no longer wanted. The main driver is most likely the notion that we no longer see IT as a way of doing business more efficiently but more effectively. Take this in for a bit and try to see the significance of this difference in looking at IT.

In my post you could read why the CC is obsolete and why maintaining a CC in an organization that is transitioning towards (business) agility is bad practice.

With that said, I want to explain why I think that the CC still has a place in today’s agile organisations, but in an extremely different way than we’re accustomed to. In my post I hinted to this already in the final part of the post.

Competence Center Classification

Typically Competence Centers consist of experts in a particular functional but more often than not, a technical domain. In my experience, large organisations that benefit from a CC have CC’s addressing aspects like application integration (teams of specialist for a specific ESB product), database systems, infrastructure and networking, mobile app development and often it is the case that there is a team that is very proficient in collaboration software like Lotus Notes, Sharepoint etc. What you’ll most likely also encounter is a group of experts organized as a CC for capabilities like testing, project management and coaching on specific topics (like Agile, Scrum and other new hip buzzwords).

I think that coaching is something that is really of extreme benefit to an organization and having a group of coaches in your organization makes perfect sense. I see them more as grease to the software development machinery than a way to make products more efficiently. Good coaches are the conscience of a team, a department, an organization. They continuously and relentlessly challenge an organization on a variety of aspects.

Capabilities and roles

Read my post on ProjectManagers to read more about how I feel about their role in today’s product development environments. Competence Centers around testing and other activities are to some degree, a large degree, a waste of time and effort. Don’t get me wrong, you really need to test, but that should be part of the team’s efforts and not, definitely not part of an external, at least to the Product Team, team. Testing is part of the product development cycle and should be done by the Product Team as an integral part of that cycle. It should also be automated as much as possible. The same goes for Requirements Engineering, who are often smart enough not to call themselves a Competence Center, but still act as one.

About Testing and Requirements Engineering a departments alike, there’s only one thing that makes sense, which is that they should be dissolved, their members become part of product development teams, considering they do have an engineering mindset. And the practice of testing and the further development of a testing practice should be instigated by a Test Engineering Guild. Same obviously goes for Requirements Engineering etc. (Guild: [...] an organization of persons with related interests, goals, etc., especially one formed for mutual aid or protection [...]). I really don’t think that it makes any sense to have a testing department, and it is counter-productive to have such a department and have testing done outside of the Product Team.

Architecture Centers of Excellence

There’s also the typical architecture group in many large organisations. They are often working in isolation of the developers. There’re a multitude of reasons why there is a distance between developer and architect and often it is due to management expectations. This also results in a reputation that is far from good when it comes to architects. Read my post on the role of architecture and architects in an agile environment. I really am convinced that architecture is a key aspect of real business agility, real meaning measurable instead of gut-feeling and goose-bumps. Especially when an organization needs to be agile in order to work on their long term strategy, i.e. adopt business agility as a strategy, they need to have architecture at the core of their product development. Architects should not be in an Architecture Competence Center, often called Architecture Center of Excellence. Instead, they should be extremely close to their user-base and form a guild. Senior management should abolish any formal group of architects and facilitate an architecture guild, up to the point where active architects in such a guild should be openly credited for their practical contributions to their users.

Back to the more technical CC’s.

The Engineering profession

As I mentioned before, CC’s are often consisting of an organisation’s experts. Which makes sense because the whole of the organization should be able to benefit from their expertise. Mind that this notion and the creation of a CC means that the organization understands the problem of scaling. Experts can’t be scaled up, i.e. cloned, so their time is booked as efficient as possible.

Because the CC will become a bottleneck, we need to find something different to solve this problem. And there is a very effective way of doing so.

Technical Competence Centers should be transformed into Platform teams. Platform teams are teams that develop a product, just like Product Teams, but instead of building business products, they create a platform onto which products can be run. The clearest example would be a hosting platform, developed by a traditional infrastructure team. Business products need to be hosted and instead of every Product Team catering for its own infrastructure to host their products, the hosting platform is leveraged. This happens automatically when products are hosted in the Cloud. The likes of Amazon, Microsoft and Google to name three behemoths, understood early on that infrastructure should be a commodity. Since hardware has been a commodity since the advent of the PC, and with the advent of virtualization technologies server hardware joined these ranks, infrastructure as a service (IaaS) has become the norm. Mind that there is still a lot of proprietary hosting platforms out there, we call it on-premise, but what it entails is a sub-standard platform.

Too often I hear that SysAdmins are reluctant to create a true platform of their on-premise systems because of job security. Cynics stating that once they’ve created a user-friendly experience in their data centers as found in the cloud, the SysAdmins are out of a job, are in my opinion wrong. I think that unless infrastructure in the data center is made as accessible to developers like the Cloud is, the SysAdmins will be out of a job. The fact that all around me I hear people nowadays referring to infrastructure as a ‘hosting platform’ instead of server infrastructure as was the case several years ago, means at least to me, that SysAdmins understand this.

But infrastructure is not the only platform to be considered. Take any of the examples of CC’s I gave earlier on in this post. For example the database experts should be working on a database platform instead of creating and maintaining databases. The database team would create a platform that allows for Product Teams to host their database on. It would ensure all compliance aspects, performance, security, resilience etc. The database platform would be an extension of the hosting platform, building on top of it. Consider the situation where the supported databases are SQL Server and MySQL. Product Teams would use these when needing a relational database. But when requiring a NoSQL database, say Mongo, they would do it by themselves on the hosting platform. Who would be better equipped to create a database platform then the database experts that where in the Database CC?

A similar approach would be taken with the former Application Integration CC. They would develop an Integration Platform that other teams can leverage for their integration needs.

From required-to to required-by

The point with a platform is that it is a product as well. So there are users of the platform and it is the Platform Team’s task to ensure that their product is adding value to the business. This means that the platform they create supporting a more agile business, that the platform is user friendly and addressing the user’s needs as much as possible. The user here is the Product Team or the Product Teams building their products using these platforms.

There is an immense shift in mindset here that you should pay considerable attention to. What I mean is that the expert in the CC was required to be invoked in the product development process as part of the process. The product had to be integrated with other products, so the Integration Expert had to be involved. If not only because the means of integration are so complex that mere mortals shouldn’t be allowed to access them. The same goes for databases. Nowadays almost everything needs a database, so in almost every situation the database experts had to be invoked to create one for the Product Team and maintain it.

The CC’s, being the result of rigorous cost-cutting and an efficiency-fetish, have become integral parts of the product development process. Policies dictating their involvement. But platform teams are different. They deliver a product that can be leveraged by Product Teams, but there is always an alternative if not only to do it yourself. The sense of autonomy in agile environments, dictates that Product Teams decide themselves how to develop their products. This holds true for every product, including platforms. So our Competence Experts need to shift from a ‘you have to run it by me’ attitude to a ‘you will want to run it by me’ attitude. And that’s a huge shift.

Many of the people I know that are part of a Competence Center, a Center of Excellence or similar organisational body are really having a hard time wrapping their heads around this. When explaining to them that they’re now supposed to create a product that people will have to want to use instead of just have to use, they have a hard time to fathom what this entails. In my experience, platform teams are among the teams that are the most urgently in need of intensive coaching on concepts like agile and lean.

Not Platform but Product

These teams are often called Competence Centers, but they are merely Product Teams grouped around a certain business aspect using specific development technology. The classification of ‘Competence Center’ is not warranted and these teams should avoid becoming a platform team and instead focus on obtaining business knowledge. Since they are in fact developing business products. Interestingly enough, these teams are more and more converted into Competence Centers although they are probably the teams that are actually in close contact with the user. Being a specialist in a certain technology, or being a team that uses a specific technology to create value doesn’t make you a Competence Center, and certainly not a Platform Team.

Concluding

The role of the Competence Center in large organisations is diminishing as agile development methods are adopted. The shift from efficiency towards effectiveness is emphasising this even further and CC’s will be obsolete in most if not all cases. Does this mean that all efforts exerted in the past in honing the skills of the experts corralled in these centers were in vain?
Absolutely not. Guilds, Platform Teams and new Product Teams are taking hold and further enhance the agility of the business. Provided organisations are adopting as part of their Agile Transformation strategies also concepts around Autonomy, Facilitating Leadership and User-Centric Design, the future of those that once formed Competence Centers will be bright.

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