Whole-team Agile doesn't happen overnight. You can take six or eight software pros, throw them together in a room and call them a team. But a lot of effort is expended -- and mistakes are made -- before they master the whole-team Agile approach. When a team attains that goal, it functions as a single unit; members are collectively committed to, and responsible for, delivering high-quality software. Any problem that arises and any solution that's arrived at belong to the team, not to an individual member.
I was recently reminded of just how hard it is to get to the whole-team Agile approach. By networking with a former colleague, I connected with an Agile coach who leads a newly formed team at the large company where she works. She talked about the challenge of getting her team to come together. Now at the six-month mark, her team is finally beginning to gel. I asked her how they got there, and she shared some ideas I hadn't heard before. "We picked blueberries, whipped up smoothies, baked granola bars and did yoga as a group," the Agile coach said. But none of these activities were about just food and exercise.
The big divide: Coder or tester?
First of all, let me provide some background on how this new team came to be. Deepening its commitment to Agile, the software development organization re-grouped into three Agile teams, each comprised of six or seven members, a mix of developers and testers. As the coach of one team, my contact understood the challenge before her: How was she going to transform seven software professionals accustomed to working separately into a single unit practicing whole-team Agile? How was she going to get them to take on tasks they believed were outside their respective areas of expertise?
The big divide was between developers and testers. As Agile team members, testers would be expected to write a little bit of code, and developers had to take on some testing. Their respective strong suits still mattered: The new role required each member to become what many call "generalizing specialists." Testers mostly test, and developers mostly write code, but everyone shares the work and is able to take on the tasks before them.
Finding neutral ground
The coach wanted her team to come to a shared understanding of one another's strengths and weaknesses, so they could keep work flowing and function as a group. It was clear to her that this wasn't going to happen on its own. A few months after the team formed, she discovered there were actually four backlogs instead of one. Clearly, the team wasn't operating as a team at all, but as a gbroup of individuals with separate to-do lists.
It was time to hit the reset button and get the team to decide as a group what needed to be done and how best to divvy up the work. Step one was getting members to talk about their skill sets, strengths and weaknesses. But she did not want them to resort to defining themselves according to their former roles (i.e., as software testers or developers, respectively). So, seeking neutral ground, she set up what were essentially mini-offsite meetings, hour-long group activities that took place outside of work once a week. The team went blueberry picking at a local farm. They took a yoga class together. And they convened in the kitchen to bake granola bars and whip up smoothies.
Although team members shared a commitment to healthy eating and exercise, the activities were about much more than that, the Agile coach told me. "They were finding things in common, discovering strengths and differences in each other -- and doing it on neutral ground," she said. Back in the office, the out-of-office activities made it easier to talk about their skills and areas of expertise, and to ask one another for help when taking on a task outside of their comfort zone.
Getting application performance right
The team found a new level of comfort with one another. The work is flowing reliably through the project and they are working from a single backlog, not four. Now, they're getting ready to take on a big problem that many teams face: identifying meaningful application performance requirements early in the development process.
The way this Agile team does this is typical of many. The team asks business stakeholders the right questions in a timely manner -- questions like, "What are the performance requirements for this application?" But again and again, the answers that come back prove wrong. The business stakeholders haven't given sufficient thought to performance issues and don't have a reliable answer. "So, there's a lot of back and forth, and then someone comes up with a number and it gets plugged in," the coach explained. "But the number is often wrong, and there is always some stuff that needs to be re-architected after the fact."
Her team is working on an answer to this knotty problem. Now that they practice the whole-team Agile approach, she is confident that they can solve it.
Read more about Agile project management
Get to the bottom of Agile development success
Enabling the Agile MSP: An MSP takes an agile approach to reduce service tickets