“Enabling Team” – how Agile it is?

As a software partner we had the chance to cooperate with many clients and teams in various setups. Scrum/Agile is considered as almost standard nowadays, however lots of misunderstandings and company “adjustments” can be observed in almost each “project”. We would like to share some experience on the team topologies we work with.

Pure Agile

First of all – Agile/Scrum is all about products – not projects. There are Products Backlogs, Product Owner – not project backlog, nor project owner (surprise, surprise!). So by design, it suits more organizations and teams working on their own solutions/products. In such scenario, for the basic small team configuration, we can talk about classic set – The Scrum Team consisting of product owner, development team and scrum master.

In this most common basic setup:

• Product Owner is responsible for ROI and answers questions like What? What’s the right thing to do?
• Development team has all the competence to deliver valuable and potentially shippable product increments after each sprint. The team is cross-functional, not each single person (did you know that?)
• Scrum Master should act as a mirror :D(let’s finish here without starting discussion when they are needed, when not, why agile coaches, how orthodox they should be and finally how to get rid of them if the team is finally self-organized

With proper people, that is really simple.

However, when working with some bigger companies, especially those product oriented, we realize that there are some bigger structures. They usually have business units, departments and maybe even PMOs (project management offices) trying to have everything under control with magic glue called – programs and projects. In those cases, while transitioning to gain some agility, they very often end up with something resembling SAFe, LeSS, Nexus – popular scaling Scrum framework. If following SAFe, the simple Scrum Team may appear in couple of forms:

When deep diving into SAFe documentation you need to be quite carefull – as it is very easy to literally get drawned, with so many links with pages with links to another pages and concepts and another links – you know what I mean, so I’m even not pasting it now.

However, something that caught our attention recently is the popularity of “Enabling team” role as very common within the corporation + software house cooperation model, even if in most cases nobody really calls it this way.

Specifics – for team members

While working with various teams, or during consulting and trainings projects we take part with, we meet developers complaining that they are not aware of the business value they bring, or backlogs consisting of just tasks, or items called user stories, but without any “story” nor “user perspective” there. Usually it is a result of the whole setup, or enabling team role in the big picture.

We always try to point out in that case, that probably you need to focus not on the product that much, but the receiver of your work, your increments, and treat them really like your clients.

Example?

Your are probably thrown into enabling team, because you have some unique powers that everybody else is missing. You need to use your sword to untie the Gordian knot. You probably have to refactor some legacy system, implement fast and scaling API, configure some pipelines for CI/CD, containerization, introduce APM (application performance monitoring), improve logging, etc.

It’s quite hard to find proper persona or customer journey and artificially phrase sth like “As bank’s client I want to pay my bills via app, so that I can immediately jump to FB and scroll another few meters of wall instead of walking”

– but there is a real value in what you are doing there, even if on first glance your work items sound quite far from the business story. There are some other Scrum Teams waiting for your increments, to be able to deliver their business items with shorter time to market, in more predicable way, or more stable.

Specifics – for the client teams

If you are a prospering company, that is focusing more on business as usual, or improvements of operations with the use of some custom software, it may occur that it is not worth to have own development team of super experts – which are usually very expensive and demands great challenges to solve on their everyday work.

If you are struggling with competitors, or missing some innovation – again it may occur, that it is faster to hire some external experts, rather than wait for internal forces to grow competence, make mistakes earlier which is natural part of learning curve.

In such cases, scaling you company with some software partner may be a great idea. Even if you already have some internal teams working together, there may be some unwanted, or other always-undone parts that need some special attention – this is the best fit to set up enabling team. You can have your own product owner to clear the internal goals and a proxy product owner or business-language speaking solution architect to take care of progress and visibility on software partner side.

Last but not least, finding enabling areas to outsource, limits also the internal know-how (business secrets) exposition which sometimes may stop you from getting to closer relations with third party.

Is Enabling Team the best choice for outsourcing model?

It is not the only model, we’ve seen lots of “pure agile” models working properly, however if you have any doubts, or it is “not that easy” to start your cooperation journey with design thinking, personas exploration, user story mapping, or simply want to unblock some of your other teams, finding well performing enabling team may be really beneficial. Don’t hesitate to get in touch with us, if you’d like to discuss the possibilities!

FAQ

What is an enabling team in Agile and SAFe?

An enabling team is a team brought in for capabilities other teams lack, rather than for a product backlog of its own. Typical work includes refactoring legacy systems, building fast scaling APIs, configuring CI/CD pipelines, containerisation, adding application performance monitoring and improving logging. The model is common in corporation plus software house cooperation, even when nobody calls it by that name.

When does the enabling team model make sense for outsourcing?

When a company focused on business as usual would not benefit from permanently employing expensive specialists, when competitive pressure makes waiting for internal competence to grow too slow, or when internal teams already exist but leave always-undone areas needing special attention. It also suits situations where starting with design thinking, personas and user story mapping is not realistic.

How can an enabling team see business value when its backlog is purely technical?

By treating the receiving teams as clients rather than forcing artificial user stories onto infrastructure work. Refactoring, pipelines or monitoring rarely fit a persona or customer journey, but other Scrum teams are waiting on those increments to deliver their own business items with shorter time to market, more predictably and more stably. That is the value.

How should a client govern an enabling team from a software partner?

Keep an internal product owner to set the goals, and pair them on the partner's side with a proxy product owner or a business-language-speaking solution architect responsible for progress and visibility. That split keeps internal priorities with the client while giving the external team someone accountable for translating them into delivery.

Does an enabling team limit exposure of business know-how?

Yes, and that is one of its practical advantages. Choosing enabling areas to outsource - infrastructure, pipelines, platform work - rather than core business logic limits how much of a company's business secrets are exposed to a third party. That reduced exposure is often what makes a closer partnership possible in the first place.