Patterns of Agile success – Part 5 of 6
Welcome to the penultimate in our series of mini-blogs about patterns of successful Agile implementations. Our last blog covered self-organization and it is intimately connected with the subject of today’s blog – collaboration. The subject includes both ways of working within the team and between teams or with other departments or third parties.
The blog is taken from our session Adapting Agile, which forms part of the Agile Practitioner Pathway – find out more here.
Collaboration
There’s a large overlap between this pattern and that of self-organization. Many of the outward signs of it working well (or badly) may be fairly similar and the principle of transparency is essential for both. Collaboration requires trust and a sense that everyone shares the same overall goal – that is why the goals of teams and departments must be aligned and clearly understood by all.
In general, Agile teams try to incorporate all the skills they need within the team – that means they are cross-functional and include end-to-end functionality. We try not to be dominated by specialists, since ‘specialization’ often means a separation into departmental siloes and this becomes a major block to innovation and fast development. Instead, Agile advocates the sharing of skills, demonstrated through a blurring of roles and divisions.
In order to do this effectively, we have to share knowledge. It means encouraging and being prepared to invest in rich forms of communication. Creative working sessions and face-to-face meetings should be valued over email or documentation. Practices designed to foster collaboration include: planning meetings at which developers, business owners and product owners are all present; requirements written in a form to encourage conversation; stated sprint goals to give clarity to what the team is trying to achieve in that increment, and pair programming or other technique designed to share knowledge.
Risks of ignoring the pattern
The risks of a lack of collaboration should be obvious – not only in theory but because most of us have experienced it in practice. There are few people who have not come across internal politicking as departments jockey for larger budgets or greater influence. While entirely understandable, the behavior is ultimately destructive to the interests of the organization as a whole. Apart from anything else, it is inherently wasteful – this is true of projects that are shut down early because of a lack of high-level support as well as of projects that drag on for years without achieving the goals for which they were set up.
Signs to watch out for
Does the team have clear boundaries?
Knowing where responsibility ends is almost as important as having any in the first place. The boundaries of a team’s remit need to be clear and visible, otherwise, Reinertsen describes them as ‘running up against invisible fences’.
Can decisions be questioned and challenged?
The transparency that fosters collaboration does not end with the project team, it expands to cover the whole planning and approval process. The decisions and the rules, thinking and assumptions behind them should be equally visible. This is not the same as everyone agreeing with a decision – speed often depends on quick decisions. But when the outcome of the decision begins to be seen, the decision can be challenged, revisited and revised.
We do best when we look at what we got wrong and when we hold one another to account. In planning, several business owners should normally be present to help keep value estimates objective, just as several technical people help keep effort estimates reliable. Estimates can still be massively wrong, of course, but a truly collaborative organization is not afraid to go back, consider why, and then apply learning to the next planning round. If we don’t do this, then no amount of planning games or reviews are of any use.
Does the team share learning?
Collaborative teams try to avoid being too dependent on any one individual – no matter how brilliant. This means the team needs to invest in sharing knowledge, sometimes by having a more expert practitioner pair with someone who knows less, or by more formal investment in training. Supporting such a culture often involves ensuring the company is motivating the team rather than just individuals through shared responsibility and reward.
Does the organisation provide tools and opportunities for collaboration?
Face-to-face meetings, regular reviews, co-located teams, wikis, and other means of sharing information or feedback… these are all symptomatic of collaborative cultures. Especially with geographically distributed teams, organizations need to invest in webcams, video conferencing and even flights to ensure some face-to-face contact.
Who is allowed to look at or change the code?
You need plenty of safeguards to ensure fiddling with the code doesn’t crash everything else, but in principle, Collective Code Ownership allows anyone qualified to do so to fix or make changes to the code.
Additional Insights
The future of full stack engineering talent
The art of feedback
Don’t confuse tools with technologies
