AGILE IN ACTION

Over on InfoQ, Amr Elssamadisy says successful agile teams are predominantly characterized by their culture and not their practices. Agreed. Team culture grows out of the values people share, their behavior and the chemistry their personalities create and the fun they have when they work together, the friendships they form and their combined sense of belonging. Sadly, a team's culture is often limited by the culture of the wider organization. But, it's not enough to just have a great culture. Without disciplined application of practices a team is likely to deliver poorer quality.

In a retrospective a wee while ago we identified the phenomenon of clumping. Clumping, as it has been colloquially termed, is the crowding effect that occurs when too many pairs cram into one section of the bullpen.

We are creating a family of portals and a publishing system to manage their content. We have two sets of users. There are end users - the people in the public who read the content of these portals, and there are editors - employees in the organization (and its partners) who publish content to the portals. The Editorial Director is our Product Sponsor and the Senior Editor is our Onsite Customer. We're part of a product stream so we're colocated with the editors, our Customer and our Product Sponsor. Consequently collaboration is predominantly conversational, by that I mean it's relaxed and happening all the time. We also have some set pieces that occur throughout the iteration, which also help us collaborate with our Customer, the editorial team and the Product Sponsor.

A team's velocity is the sum of the estimates of the user stories that were done during the iteration.

In our team, developers create the vast majority of the automated tests, whether they are acceptance tests, integration tests, or unit tests. They do this because they are story test-driven. They develop stories from the outside in, starting with the user interface and are guided by the acceptance criteria. The developers profile their code and create automated performance and load tests as they go because code has to be production-ready at the end of every 1-week iteration. Testers in our team do exploratory testing and they're free to pair-up with anyone, another tester or more likely a developer, to create any automated tests they feel are missing. The testers, however, add value to the team that goes way beyond testing. Working closely with the Product Owner they facilitate connection and collaboration with the customer, helping the team to empathize with users, understand their needs and appreciate value from their perspective. Working with the facilitator they help the team develop a conscience that is focused on the delivery of value and quality, while their continuous interactions within the team keep collaboration high.

For a while now, there's been some trepidation in the team when holding people accountable. People seem to have difficulty knowing how to hold someone else accountable. It's a communication problem. People are so worried about being seen to blame someone for something that they'd rather avoid the conversation completely. The problem with this approach is that the things that shouldn't be happening keep happening because the people doing them don't know they shouldn't be doing them.