By Rosalyn Charlton
March 2011
Our Durban Agile user group kicked off 2011 with an in-depth open discussion on some concepts that lie at the very heart of Agile, but which often pose the greatest challenges to Agile teams; these being Collaboration, Swarming, and Pair Programming.
Interestingly, although collaboration is a core concept of Agile, it is never well defined by the Agile community in any distinct form and is often very misunderstood. It is never really clear whether one is “being collaborative” or what it looks like when one “swarms” and whether pair programming is really worth its discomfiture. Hence our selection of these sticky topics for our first gathering of 2011.
With an agenda-free approach, armed only with flip-charts, coloured pens and three willing scribes, the group jumped right in and stirred things up nicely, arriving at some great concepts, ideas, improved understandings, and generally agreed upon definitions. Beyond just the “What Is It” discussions, the group explored in great detail the ever-burning question of “How do we do it”, and through this some great experiences and insightful thinking was shared. I have allocated a greater proportion of this article to discussing the techniques of “Swarming”, as it seemed to be the topic of most contention and greatest need for clarity. It also happens to be my personal belief that it is one of the essential “tricks” to getting Scrum right.
While a lot of ground was covered during the group’s discussions, and these are certainly topics one could discuss at length, I will summarise the outcomes and highlight the more crucial points made by the group, and add my own insights from time to time, if I may.
Collaboration
It was agreed that collaboration was applicable in all industries and environments, but first-hand experience in the group was of course in collaborative arrangements between IT teams and customer representatives.
- Collaboration is best represented by a multi-skilled group working toward a clearly defined common goal, with a mutual undertaking and accountability to the achievement of the common goal.
- On-going and meaningful face-to-face communication is essential, even if this is via video conference tools for remote teams.
- All parties contribute and communicate throughout a project; there are no surprises.
- In Agile IT projects, collaborative teams are comprised of agile development teams and business users or customers, or their appointed representatives, i.e. those who best know the requirements, and those who will implement the solutions.
- The collaborative team is jointly responsible for decisions and solutions, and mutual trust is integral to overall project success.
- In practice, collaboration always produces higher performing teams, shorter times to market, and more accurate “fit for purpose” solutions.
- Collaborative approaches reduce assumptions, improve project communication, and result in higher quality and greater productivity.
- Solutions more accurately reflect the customer’s needs as collaborative behaviour alleviates misunderstandings.
- The classic Agile objective of “Fail Fast” is fully enabled as solutions (and impediments) are assessed incrementally and development direction adjusted accordingly.
Swarming
As peculiar as this practice may sound and seem, and regardless of what you choose to call it, it is undoubtedly an extremely essential Agile practice within Scrum development teams in particular, and was explored within this context. While this behaviour lies at the very heart of Scrum philosophy, it is often misunderstood, or overlooked entirely when teams implement Scrum, possibly for the reason that it is an incredibly foreign approach for development teams to take, and can seem counter-intuitive. In all the teams that have implemented Scrum with ‘swarming’, its benefit is uncontested. Let’s explore further.
- An agile development team ‘swarms’ by having all team members working together on a specific backlog item (eg user story), at the same time.
- Rather than taking on a separate piece of work each, as is customary in conventional development practices, the team tackles ONE item, combines their skills, self-organises, and achieves the solution as a unit in the best way possible.
- Ideally this is the approach: the team selects the highest priority item on the sprint backlog, designs the solution together, breaks this up into tasks to share between them, integrates these respective parts to form the solution at the end, and does not move on to the next story until it is done – as per the team’s definition of done.
- The team needs to first have a clearly understood definition of done.
- This approach ensures that the team delivers distinct, completed and usable items of work within each iteration, rather than numerous half-completed work items.
- A swarming Agile team is given the autonomy to self-organise. The team decides, as a unit, on the best solution and best approach to achieve this solution. This self-organisation results in the greatest possible productivity on any task.
- A high-trust environment is essential, both between team members, and in the team unit by the organisation.
- The knowledge and skills of all team members are contributed to each work item and used to achieve the agreed objectives.
- Prolific and almost effortless knowledge-sharing and cross-skilling occurs in a collaborative team using swarming techniques. This reduces knowledge silos and associated risks.
- The suggested preferable Scrum team size of 7 plus or minus 2 becomes very relevant in this arrangement.
- The team is jointly accountable for every deliverable, and commits to that deliverable as a unit. This produces far greater ownership and rates of success.
- Taking guidance from product owner prioritisation, the team must be permitted to select its work per iteration and commit to these deliverables.
- Greater innovation is encouraged and enabled, and creative problem solving occurs when a team is held jointly accountable and is not constrained by predetermined roles and approaches.
- The team’s sense of achievement is far greater since deliverables are achieved with every iteration, with increased success.
Pair Programming
This topic is so extensive, and diverges in so many directions that it may very well be a good topic for an entire event or workshop. We eventually constrained our focus to the very high-level pair programming principles, and the following points were agreed:
- To most, pair programming simply means 2 developers, one PC, one person typing, the other analysing and advising; in other words, two people working simultaneously on a single piece of code at the same workstation.
- Up to 4 developers have also worked successfully in this manner with great success, still only 1 at the keyboard.
- The roles can be switched as regularly as needed to achieve fresh perspective.
- The different perspective provided by the slightly removed role of “observer” yields far better solutions since the code can be reviewed as it is created.
The benefits of pair programming are hotly debated, since logically placing two people on one task defies productivity. What has been found, however, is the following:
- Statistically 60% greater efficiency is usually experienced in pair programming teams.
- Quality of the code produced is always far better than that produced by individuals alone, bringing huge time savings.
- Errors are spotted immediately; essentially, in-line code and solution review is performed.
- Team members learn improved and alternative techniques through observation and joint participation.
- Costs resulting from product failure and bugs are significantly reduced as delivered quality is dramatically improved.
While it was a common comment that this practice is quite uncomfortable for developers at first, all successful pair programming teams reported enormous benefits and productivity enhancements, which they agreed made perseverance past initial discomfort worthwhile.
Putting it all together
Combining all these ideas and concepts, I have attempted to formulate a hypothetical, yet highly recommended, approach for a scrum team working on a project.
Let’s take a scrum team, comprised of developers, testers, business analysts, scrum master, along with a product owner to prioritise the product backlog. Along with this we have business users (or customers, since these are regarded as the same thing in Agile) who have been identified for their understanding of the business needs.
The scrum team and the business users are jointly accountable for the success of this project. They will collaborate throughout the entire project from specifications of User Stories, throughout each iteration, to final testing and implementation, with the ideal scenario including co-location of all participants. The solution is emergent in this arrangement since there is preferably no large upfront plan or design. In this way the business representatives and the developers ensure that the product being developed meets the real needs of the business every step of the way.
As the scrum team selects from the backlog, and commits to, a set of User Stories for each iteration, they build a sprint backlog that they will swarm on by tackling the user stories (backlog items) one at a time as a team. When swarming, the team will self-organise to determine the best possible solution and the best possible way to achieve it, and collaboratively involve the input of the business users throughout as needed.
The team will break each user story down into smaller tasks, sharing these amongst themselves, trusting each other’s understanding of their collective accountability to the deliverable. To perform this development the team will break into pairs and tackle it using pair programming, thus ensuring delivery of the highest possible quality, reduced come-backs and enhanced productivity on the overall project. Completed tasks are integrated by the team ensuring that the overall solution meets the real requirements of the business by collaborating with business representatives.
Once the solution meets the team’s definition of done, they will swarm on the next user story having successfully produced a distinct and usable increment of business value. This is the ultimate objective of these practices.
It certainly seems to be a shared conclusion that using any, or all, of these practices one undoubtedly achieves greater productivity and team velocity, higher product quality, greater knowledge sharing, a reduction in high-risk pinnacles of knowledge, and engaged committed team members. Ultimately, these practices deliver greater business value, which is the primary objective of Agile.
From our perspective here at SA Home Loans, in the scrum teams we are thoroughly appreciating the techniques of collaboration, swarming and pair programming, as well as the enormous benefits we see at the end of every single sprint. After spending the last year or so working at these practices, and understanding how they work for us, attending this Agile SA gathering gave us an opportunity to share in other teams’ experiences, voice our own findings and approaches, and glean some new ideas as to how we can improve even further.
While it may not be easy to achieve, the effort involved in getting it right far outweighs any effortless alternative.
).
|
Copyright © 2009