Customer Context

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!