Cross-functional collaboration in Agile product development means that the entire product development team is participating. Scrum talks about a development team without distinction of roles. As such, developer
means any competence or skill required to create the product or service that is not limited to programming
It's important that the whole product development team is participating during the entire product development cycle. This whole-team approach creates a shared understanding among everyone (all team roles) right from the beginning. It minimizes any waste, such as handovers, intermediate deliverables, discussing the same topic with people who didn’t participate, etc., originating from working in subteams or silos.
True Agile teams are product-oriented and are able to implement product features end to end, creating pieces of value with every item done. Collaboration with all team members is a great source of creativity, new ideas, and innovation. This kind of cross-functional collaboration is demanding: People are expected to think outside the box, participate in work outside their main domain, and to help create that shared understanding necessary to be able to deliver value within an iteration.
Image: Luke Barrett
Challenges with staggered sprints
Teams working in a phased approach (the so-called staggered sprints) face a number of challenges. This approach should not be accepted as common, and such teams should strive for a better way of working. A phased approach means that some work is done in a sprint before the development
sprint (or, worse, acceptance or testing after the development sprint).
Challenges with the phased approach:
- Sprints fall out of sync.
- Sprints lack agility.
- There is lack of ownership.
- There is waste (handovers, intermediate deliverables, etc.).
Benefits of single sprints
The single, true Scrum team approach has numerous benefits:
- Team members have an understanding of concepts and users’ needs.
- Time to delivery is improved (a precondition is to deliver chunks of value that the team is able to implement within a sprint).
- There is less rework, less waste.
- There is an improved Definition of Done.
- Team members have a sense of ownership.
Regular, just-in-time product backlog refinement ensures that the whole team has a common understanding of the upcoming work, which could require research. We should avoid having large pieces of work done before the sprint (for example, all visual design or user experience work, or all architecture work). And so we urge you to reconsider any large up-front work (before construction). Try to create a shared understanding with the whole team, which will lead to true collaboration within the same sprint.
Another recommendation is to foresee a regular cadence of end-user validation moments. This is done by creating a “validate everything” culture — validate what’s available and, given the end-users’ feedback, improve (i.e., iterate).