What does a cross-functional Agile team look like?
Although not declared in the Agile Manifesto, pretty much any Agile advocate will tell you that you need cross functional teams in Agile. What does that mean exactly? How wide does the scope of the team’s skills need to be? This is an interesting question and touches on organisational design, DevOps, HR, and other topics. Caveat: I’m here talking about large organisations implementing Agile. A small startup could probably skip a lot of these headaches and easily implement a truly cross-functional team in Agile.
What are cross-functional teams in Agile?
A cross-functional team is one with a variety of skills, abilities and experience, so that they can develop their scope (stories, features, “product backlog items”, whatever) by themselves, without help from others. This is a good idea, and part of a smart but subtle agenda in Agile that we should move away from silo specialist teams that you usually get on Waterfall projects. The “database team”, the “front-end team”, the “integration team”, etc.
The thinking here is that the team should have capability and responsibility to deliver it’s scope end-to-end. There are a number of reasons (if you want more detailed explanations, I would highly recommend the Large Scale Scrum book – it goes into great detail on this topic). If you want to know about cross-functional teams in agile check out this awesome guide from Tcgen.
Less handovers
Dependencies on other teams or people means handover points, which are inefficient. If your “front-end” team is waiting on a functional specification or UX design from your “design team”, they will get frequently blocked. And this will happen not just on the initial scope items, but later on, when changes happen (which they will).
A cross-functional team can work together to produce small full end-to-end pieces of functionality, without waiting on a handover from anyone. This helps enable Flow (one of the key concepts in Lean, which is one of the venerable ancestors of agile).
Communication becomes easier
Dependencies on other teams or people can involve communication problems (e.g. the team may be in another building or worse, another country and timezone). The best way to communicate is in real-time, face to face (although admittedly that is a little harder as of time of writing, in mid 2020). If you have a small group of people seated together who are all working on the same piece of work, they will communicate much more frequently and effectively. This also aids not just flow, but also knowledge sharing and creative thinking.
Diversity is good
Numerous studies have shown the value and importance of diversity in a team. People with different skillsets and work or education background can bring fresh new thoughts and perspectives that you wouldn’t otherwise get with a dedicated “component” team.
Better coordination
The Scrum rituals such as the daily standup are important for ensuring coordination and collaboration. These meetings will be much more effective if all the people involved with completing sprint scope end to end are present and participating.
How cross-functional is the team likely to be?
The problem is how wide this responsibility is assumed to be. At many organisations doing Agile, they will have cross-functional teams, but the border ends at the channel level. Beyond that is the SOA or middleware layer, and that involves the SOA team, who are their own people doing their own thing.
From an engineering perspective, the SOA integration services are beyond the scope of the channel deliverables. Developers can work with stubs for these services, integrate with them and test against them in a SIT (System Integration Testing) environment, and declare our team to be cross-functional from a strict engineering perspective.
However, this is a misleading and dangerous position. It’s not what we should really call a “full stack” team. Full stack means your team builds and owns the functionality all the way to the backend systems. The diagram below explains this a bit more clearly:
It’s not just about SOA or an integration layer: you might have a security layer, a logging layer, an analytics layer, and so on, depending on your application’s pipeline. Full stack means you own it all, from the very top to the very bottom. Assembling a truly full stack team like that could be very difficult, depending on the size of the organisation and complexity of the technology.
What about cross-functional people?
In an even more perfect world, you would not only have a full stack cross-functional team, but each person in the team would be able to fill any of the activities that any of the people in the team could do. They may not be experts, but they can fill in gaps. For example, “Dave the DBA is on training today and tomorrow, Jenny can you drop the front-end dev stuff you’ve been working on and finish off those scripts? That would help us get this story over the line.”
This would offer some clear benefits:
- The team is less vulnerable to velocity disruptions from sick / annual leave, training, conferences, etc.
- Anyone in the team can peer review or code review anyone else’s work
- Anyone in the team can train up someone on any skill.
Finding ten people who can do just about anything is obviously going to be hard. If you can find such a team, consider yourself very fortunate. More likely, you will have to foster a culture of learning, cross-skilling and up-skilling. This is a key part of being a Learning Organisation and Continuous Improvement.
What about functions besides Build?
Releasing software isn’t just about build though (and under build I include architect, design, test, and refactor). There are other functions, or activities: deploy, release, run, monitor, analyse, upgrade, repair.
Cross-functional should include Operations / DevOps
Teams should move away from the old Waterfall mindset of “throwing the application over the wall to Operations”, at which point looking after it becomes “somebody else’s problem”.
The DevOps movement has done well to move organisations away from this outmoded and inefficient way of thinking. Teams should own and take responsibility for the full lifecycle of their products, include operations and maintenance. If this sounds like it would be too much work for your team, you probably don’t have enough automated processes like Continuous Integration and Continuous Delivery in place.
Another important point that bears repeating here: DevOps doesn’t mean just replacing an Operations team with a DevOps team! “DevOps” is not a team or role. It is a mindset and philosophy and approach to development integration and deployment. If your organisation has a “DevOps” team, it is probably not doing DevOps, more likely they have just bought an expensive DevOps tool, handed it to the operations team, and renamed everybody’s roles.
What about other functions?
What about the infrastructure it runs on? What about the marketing? The training and change management? The customer relationship management and communications? These activities are getting pretty far away from the actual coding activities required to create software, but they are important.
We’re now talking about skills extending sideways from the channel, rather than up or down the technology stack. In a perfect world, you’d be able to assemble a team that could do all of that, and keep it at or under 10 people, but I doubt that’s possible in most organisations. And if your company’s marketing team require a 3 month lead time for any new features, then being able to deliver it in two sprints is not such a useful ability (though it’s certainly still a good thing). What you therefore want to do is:
- Make sure the communication loops between your team and these outside (but important) people are very short. Everyone being in the same building helps a lot.
- Try to reduce the lead time of these external teams so they don’t become blockers to your work. If their lead time is as short or shorter than the lead time of your scrum, you’re fine, but it’s unlikely.
If you want to know more, have a read of my article on common organizational barriers to agile adoption.
