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.
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.
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).
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.
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.
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.
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.
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:
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.
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.
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 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:
If you want to know more, have a read of my article on common organizational barriers to agile adoption.