What makes an ideal agile team?

Summarising

In many occasions I am being asked by clients to share my thoughts on how they are (planning to) form their Scrum teams. My recurring comments always are to have the team as small as possible, stable and consisting of full-time individuals, maxing out at 9 persons. Have one or more coaches linked to the teams and make sure that there is a mandated Product Owner.
Make sure that relationships are based on trust and ensure that accountability and responsibility are two aspects addressed organisationally with full support of upper management.

The other day I was asked by a manager of one of my clients to comment on a proposal of one of his vendors. A key vendor that has been under delivering since a very long time, but still considered to be a strategic partner in most of my client's business. The vendor is currently experimenting with a different way of addressing its customers by better aligning its services to the needs of its customers. The vendor is proposing to setup a cross-functional team that will be tasked to deliver relevant products in short cycles.

My client is a little sceptical but willing to give the vendor the benefit of the doubt. As such he's agreeing to become one of the first customers to work according to the new proposed process and is now asking me to see what to look for in the proposal. Being the first customer and thus investing time and effort in amending the current mode of operations with this vendor, there's some head room to 'ask' for specific adjustments to the proposal.

The vendor is going to deliver new products and services in a variety of categories to my client and is proposing to setup a Scrum team. My client now wants to know if there are specific aspects of this team that need to be addressed. Also the role of my client with regard to this team is a point of interest in the negotiations. And obviously the delivery of products and services to my client.

Basically the question is: How should my vendor organise its team in order to better meet our requirements? The answer is reasonably straight forward.

In principle you want to keep a Scrum team as small as possible, that is actually a basic principle. The maximum size for a well-functioning team is 9 people. This has already been discovered by the ancient Romans, no kidding.

I would like to argue to start with 6 or 7 people. Rather 6 than 7 by the way. The reason for this is that otherwise you will get specialisations within the team that come to lie with one person, that will immediately become the SPOC / F, who can not get sick or go on holiday.
The strength of a well-collaborating team lies mainly in the knowledge spread throughout the team as well as complementing personalities of the team. This allows members to challenge, supplement and assist each other. It is a common mistake to see what kind of techniques and technologies you want to use and to find the experts for that. It is a Team and not a Group we're trying to forge. Understand the difference, it's important.

I find the use of FTEs in resource planning of Scrum teams confusing and dangerous. I've seen this plenty of time and it never resulted in anything good. One FTE can be filled in by 1 or more people, and that is what you want to prevent. You want the team to be stable, not only within a sprint but also over sprints. Almost at any cost. Again, I'm not talking about a group but about a Team. And, they must all have an engineering mindset. People who dislike doing things themselves and want to automate everything by definition.

Recently I was asked on the subject within the context of an initiative to start treating an operating environment as a platform, which was going to be treated like a product. With a Product Owner at the helm. And a group of my client's experts was assembled to form the 'Scrum team'. I was asked to provide my thoughts on this setup.

We're talking about server provisioning, networking, identity and access management, firewalls, certificates etc. This team is also going to be responsible for operating the platform they're developing. My initial thought is to have therefore functional expertise (provisioning, networking, identity management, loadbalancer, firewalls) and an engineering mindset (automating, monitoring, everything as code), if possible either a senior in one or more functional areas and medior in engineer and vice versa. Depending on the team composition, there may also be a medior / medior combination when there's enough seniority in the overal team. Attitude is more important than knowledge in my opinion. I would therefore always prefer someone who wants to automate, will always test and always asks for insight into production.

I do not see why one would need a full-time Scrum Master, that's probably overkill. Having said that, it seems wise to let the team choose their Scrum Master from the team itself. And with experienced teams that have been working together for a considerable time this is likely a viable option. But when you're just starting with Scrum in your organisation or when the team is just starting with Scrum and Agile concepts, I always prefer a Scrum Master from outside the team. Since the Scrum Master is the team's conscience, and at times will have to use strong words to get focus back on the team's goals and principles... it will be challenging for a Scrum Master from within the team.
Add a coach for roughly the first 6 sprints to coach the Scrum Master, even though the Scrum Master might be experienced, it is still good to have a coach. The team chooses the Scrum Master because it will ensure that it's their choice, a choice supported by the team. You want good chemistry between team and conscience.
The role of the Scrum Master is all about addressing people to the standards and values ​​of the team, but also facilitating them in doing their work. I have seen in various situations that it can work when the Scrum Master is also facilitating in another supportive role, e.g. as Tool integrator in Continuous Deployment environments. I'm not a proponent of this though.

I told the client that I was missing the Product Owner (PO) in his approach. The PO is relevant because the PO determines what the team is going to work on. That would be the person who talks to the customers about what is needed, etc. And to the users about what was delivered. Therefore the PO is accountable for what the team will deliver. The team is responsible for what it creates, the PO is accountable. These are the two most important aspects.

Keep in mind that responsibility can be delegated and shared, accountability cannot be delegated nor shared. So a delegated PO doesn't exist, as it would mean delegated accountability.

So a stable team and a PO (outside the team) defining the team's priorities. No one else but the PO is mandated (i.e. empowered) to determine what the team is working on, because the PO defines the priorities of the products and features to be developed. The team plans the work. So there has to be, by definition, a lot of trust between the PO and the Team, because the PO must be able to rely on the team's commitment to what they are going to do in a sprint. Here comes the Scrum Master in the picture again. Because the Scrum Master has to make sure that the team does not overcommit.

Here's an interesting aspect, the trust aspect. An aspect I will address in a future post, where I will cover more on metrics and KPI's and the trouble of the user story in this regard.

In my opinion, the role of customers should be not only one of the customer, but also one of the user. This will allow a user-centric approach on developing the product, and at the same time be very customer aware.

You should look for a future post on stakeholder management and agile processes to get some more insights on this topic.

I told in another case with another client of mine that it makes perfect sense to start treating their Scrum teams as internal startups. Basically consider the PO of these teams as the CEO of the startup and the management team would be the Venture Capitalists. By doing so, there's ample opportunity to experiment and evolve into a value driven minded organisation.
In this particular case I suggested to see if it would be feasible to go along these same lines.

The PO will need to determine what an MVP would be. Something small delivered in short increments, so to quickly find out if something is usable. Start cultivating a mindset where 'Done' means 'In use at a customer!' (Done = Live).
Agile means being able to deal with change in a timely manner. So here comes the point of view that the PO is a person who has a strong personality and is met with a lot of respect. Somebody that knows what the product should look like, with a product vision. And the PO will have to be mandated/empowered. It should never be the case that the customer can circumvent the PO to get things prioritised. This is for internal and external customers. And managers.

Again, I told my client to get a coach involved here as well. Even if it is an experienced PO, it is important to be coached. In the beginning intensive, but perhaps later (even after 6 sprints) it may be a bit less. It might be an opportunity to invest in an agile-coach, who will take care of all the coaching work (team, Scrum Master and PO).
Just like the PO is mandated to define what is and what is nog going to be in the product, the Team and the PO should be granted autonomy, independence and self-reliance. The PO is positioned external to the Team and in case of scaling up the team to two teams I would like to argue that both teams get the same PO.

In this particular setting, one could even consider starting with three small teams of 3 to 4 people who all work on their own part within the platform, three products if you will. A team for provisioning servers, one that works on network and connectivity (including DNS, firewalls, loadbalancers) and a team that focuses on IAM Automation (Directory services for example) and certificates. Combine these teams with a single Scrum Master and a PO with three Teams. Obviously an Agile coach for the whole bunch.

So, concluding: A maximum of 9 individuals, all full-time, in the Team. One of which will assume  the role of Scrum Master. Alternatively, form 3 teams of 3 to 4 full-time individuals with an overarching Scrum Master. In addition, a PO with knowledge of the subject matter and full mandate and an agile-coach.

Thanks once again for reading my blog. Please don't be reluctant 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.

Arc-E-Tect