This content is part of the Essential Guide: Next generation Agile: Guide to continuous development
Evaluate Weigh the pros and cons of technologies, products and projects you are considering.

Tackling the whole-team Agile approach

Achieving a whole-team Agile approach is hard. Here's how one coach took unusual measures to get her team members talking, asking each other for help and tackling each issue as a team problem.

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?

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.

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.

Next Steps

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

Dig Deeper on Topics Archive

Join the conversation


Send me notifications when other members comment.

Please create a username to comment.

Is your Agile team having trouble enacting the whole-team approach? What have you tried that has worked, and what hasn't?
Referring to the SW dev group as the whole-team is a misnomer and, understandably, lead to the performance miscommunication. The 3 D's make up the whole-team:  definers, developers and deliverers. Forming this team at project launch gives them time to self-organize, establish a value stream and a 'done' cadence.
A lot of agile is about the empowerment and agency of the group doing the work. Meaning, that the group gets to make make the decisions they think are best based on the information they have and the expertise they have.

The failures I've seen are in companies that try to do agile, or at least add scrum and kanban boards,  but still force the tech workers into highly structured environments where they are not allowed to make decisions for themselves. 
I've seen a major failure with an attempt to "implement agile" when no one really understood why. After some time struggling with the rituals the project staff turned back to the old habits and practices. The group brilliantly enacted whole team approach in resisting and sabotaging an unwanted change.
I find the generalizing specialist term a little strange. A tester that is writing test code is still a tester. They aren't generalizing, they are learning skills to help them test in that context.
This is a "whole software development team". If done in conjunction with a whole product team effort then you have the beginnings of a successful, sustainable Agile adoption. Otherwise, you've just traded one silo for another.
Successful, sustainable Agile adoptions start with the whole product team which includes definers, developers, deliverers, deal makers and the deal (customers). Now, rather than an new silo among silos you've created a single point - the product; and that's where the value is,
There seems to be a confusion about the goals. What business needs, is a well performing, delivering software development team. Acting truly as a team is one of success factors but it's important to remember what is the goal and what are the means.
There seems to be also an illusion that a group of people becomes a team "one day". In fact, there are "degrees of a team". In some situations, people may act more like a team, in other - less. It's an ongoing, sometimes bouncing, process.
A good team puts in a good use whatever qualities and skills people bring in regardless of a title, and supports development of skills/expertise needed to fill the gaps.