Advice on Feature Team Composition During Program Re-Org

Question

I am coaching a client who is reorganizing their Program and could use some advice.

Background: The client works for a large corporation with many different programs that all take their own approach to Agile or do not use it. Over the past two years, I have coached the Program towards the adoption of the methodology and the roll-out of multiple feature teams.

Teams in this organization consist of business analysts, developers, business operations, and engineers. The makeup of these teams depended upon the product the feature team was supporting. The configuration aimed to establish cross-functional teams that could deliver everything their respective product needed.

Scenario: Several months ago, programs began to align differently. Now the client is telling me that they will be moving their engineering and development team members to a Shared Services Engineering team.

They would like the engineering team members to continue to support the product teams from their original Program. The client would like to take the Scrum Masters from Program A and move them with Engineering to Program B. They would like to keep the Product Owners with Program A.

As part of this change, they want to separate the engineering work from Program A and maintain it on separate team boards under Program B.

I have a few concerns about this approach and would like to coach them in the right direction. I would like to get your thoughts on this situation to help them with this transition. As is often the case, I can't tell them what to do, I can only make recommendations.

Constraints: Deals about who was going where from a Program perspective have already been made, and I will have little ability to change things to majorly.

In my experience, the Feature Teams I have supported were built around a Product. The way they are going about this change would mean that the teams would be split from a logical perspective but would run together from a physical standpoint. The Product Owner from Program A would have a team of Engineers from Program B. Currently, all the work appears on one board. With this approach, the work would be split across two boards. This would mean that they are responsible for doing extra administrative work when managing the Product Backlog.

All of this seems slightly off to me. The leadership team wanted to remove engineering responsibilities from Program A. Engineering would then govern technical decisions separately under Program B.

It appears that they are taking the Product Owner (along with business analysts) out of the team and making them separate from the engineers. In this way, it would mean that the Product Owners supporting the Program would request work to be done by engineering and development. Where right now, they are prioritizing work with their immediate feature team. While they say this move is only logical, I feel it will evolve into a long term physical change.

How do I best advise in this situation and help coach the engineering program in establishing a strong foundation when all is said and done?

Answer 1

The first question in a situation like this where you are meant to coach them must be: what are they looking to accomplish?

This is not just a question for you, but for them to consider as well. Often times, people get excited about a solution and don't take the time to understand the problem they are solving.

Once you understand this, you have a discussion about the impact of different models. Obviously, the model they are proposing takes them away from Scrum. That may be ok if it is intentional and thought through. They will lose the benefits of a cohesive team that includes the business. In a shared services model, they may also lose certain amounts of consistency and the benefits of a long-standing team.

On the other hand, if the work they do is relatively homogeneous and the market you are in is not very volatile, you may be gaining some efficiencies. Many organizations also find it easier to maintain consistency in architecture and quality.

One thing I'd definitely warn against is walking away from a scrum structure but keeping some of the constraints of Scrum. Half-practicing Scrum usually leads to getting none (or few) of the benefits of Scrum and none of the benefits of the other models you are trying to use.

My best advise here: focus on helping them make a good, sound decision and leave your own agenda aside.