Experiences with teams without coding capacity

Experiences with teams without coding capacity: there should be focus on the end-2-end product

Lately I’ve experienced working with Scrum Teams without coding capacity. My main conclusions:

1) principles and values of agility can certainly improve these teams and make them more effective, but without considering the end-2-end product the overall organizational agility will not increase. My second conclusion is that

2) agility in a hardware or software environment can lead to a bigger growth of effectiveness than in a non-hardware or -software environment. This is caused by technical excellence and (extremely) short feedback-loops which are hard to accomplish (or not even possible) in a non-hardware or non-software environment.

Explanation Business Agile

Let me first explain what I mean by teams without coding capacity. It’s about focusing on ‘agility’ (or ‘agile’) without considering the whole product. E.g. a team that focuses only on procurement from the procurement department perspective or marketing from only the marketing department perspective, without considering the rest of the product. I think organizations should aim to have ‘organizational’ agility (a term I borrowed from Jurgen de Smet https://www.linkedin.com/in/jurgendesmet/) with focus on the whole product and without focusing too narrowly on one specific part.

Description of the teams I’ve worked with

The teams I worked with were two commercial Product Management teams and one operational team with logistic designers. Their goal is to have more focus on delivering value, better collaboration with less hand-overs and a more multi-disciplinary perspective. In this blog I will focus on the two Product Management teams, because they are focusing on products relevant for customers.

So, what do these teams actually do and of who do they consist of? These teams are responsible for a specific product area of the organization and focus on the most valuable products and initiatives for that product. Either for developing these products as for maintaining these products. They do all stakeholder management for these products, either internally with e.g. marketing as well as with customers for feedback. From a Product Management perspective they are quite multi-disciplinary as they have information management and operational knowledge by people from these areas representing them. They are the stakeholder for the software development teams (several, see below) that develop and maintain the software for the products. With the whole team they make sure new valuable initiatives are developed, stakeholders are managed and software development teams execute the work they need. After development in the software development team, they make sure it is implemented and communicated. And because of that, I’ve called them ‘Product Owner teams’ a few times. Unlike a project-based approach where many projects at the same time in the same product area may occur, these teams canalize all ideas and initiatives. Since these teams have an overview of all initiatives, they are able to focus and prioritize the initiatives, and thus limit the Work in Progress on that product area.

Experiences in these teams

Many of the principles and values from agility (or Lean) are beneficial for these teams. Many of the Scrum values – especially focus and openness – help in the improvement of such a team, especially if they are long-lived. Furthermore, an iterative approach with more Lean Startup thinking and rapid feedback on the products increase the value of the products that are delivered. The teams improved their way of working and their internal collaboration. They were also very active in collaborating with other teams (especially the software development teams) and made sure the initiatives were well-aligned, mostly by attending Reviews and ‘just talk’ with those teams when they needed to refine the features. For me personally, it was a lot of fun and I learned a lot from it. For one thing because teams that focus on commerce usually have different kind of personalities in the team (in comparison to software development teams), which was represented mostly by their extraversion and instant feedback.

However, Lean Startup thinking can only work when the teams that actually make the product (mostly software development teams) have the same priority and focus. When agility helps these teams without coding capacity and they become more effective, it leads to an increase of the demand and new ideas. But when there is little consideration and improvement of the whole product, this demand cannot be answered properly and the ‘stock’ for actually realizing the initiatives grows at the software development teams.

And here is where it gets tough. If the teams that the Product Management teams collaborate with do not have the same focus on the product area, it is hard to focus and prioritize. There will be additional handovers and the software development teams do not know the customer and initiatives as well functionally. Although a good collaboration can camouflage a lot (and the teams I worked with certainly collaborated well), the end-2-end product is not optimized.

This may also cause ‘waterfall’ steps, because the Product Management teams first gather requirements and a ‘functional’ design, and subsequently the software development teams work out or design the solution. If the design and estimation is acceptable (and thus can be prioritized), the development will start. The (functional) testing will occur after the development by the Product Management team. It gets complex when the software development teams are component teams and not feature teams (read this (https://less.works/less/structure/feature-teams.html) for a simple explanation). For the software development (and maintenance) of a product (area) there are multiple teams needed. So, the Product Management teams have to collaborate with multiple (and not always the same) software development teams. Prioritization must be together with multiple other product(s) (areas), because they all need these component teams. So, there is a ‘battle’ for prioritization between the Product Management teams (and sometimes ‘other’ initiatives as well) and consequently their preparation for new initiatives has to be more comprehensive to show the possible value. A Lean Startup approach with fast development and feedback gets harder as it is hard to show the value of these ‘MVP’ initiatives. As a result, the MVP usually gets ‘bigger’. Another challenge is testing the new feature: it has to be executed by the Product Management team, because they are the only team that have the overview of the feature and the product (area).

(there has been written a lot about feature and component teams and I will not get into that in this blog, but I hope to have shown the perspective of Product Management (teams) in working with component teams)

Learnings

So, for the teams itself there is a lot of improvement. However, without improving the end-2-end product, the organization doesn’t have the full advantage from it.

What can you do to improve this from an organizational perspective? A focus on the whole product, from a commercial perspective, operational perspective and a software development (and maintenance) perspective – and other perspectives as well when applicable – helps in focusing on the product (area), simplifies the collaboration and speeds up the development and maintenance of the product (area). The Product Management teams and other teams, in particular the software development teams, shouldn’t be separated and should work closely together and have the same focus and prioritization. If everybody that works on the product fits in one team (for either product management, software development etc.), that’s preferable. If it is too big for one team, multiple teams should work closely together with the same focus and prioritization on the same product (area) and not on other product(s) (areas) as well. E.g. with a (de)scaling framework like Large Scale Scrum (LeSS).

And although many of the values and principles from agility (or Lean) can lead to improved team effectiveness and collaboration, I think the most value from agility can be achieved in a software or hardware environment. Technical excellence and short feedback-loops of the product can lead to exponential growth and improvement in agility. In a solely ‘business’ environment these benefits cannot be gained and therefore the improvement and agility will grow only ‘linear’.