Agile values “individuals and interactions over processes and tools” and “working software over comprehensive documentation” (Agile Manifesto, 2001). This being the case, it is important that any practical application of agile focuses on agile teams and their collaboration and commitment to working agile and functioning as a committed team. My own practical experience combined with countless practitioner and student discussions shows that building high-performing project teams is one of the hardest parts of project management, regardless of the approach. Adopting agile practices does not make this any easier – in fact, agile can make this initially more challenging.
Agile provides principles that encourage self-managed and co-located teams. Frameworks such as Scrum provide roles, events, and artifacts, but are intentionally not prescriptive in how to use these (that’s what books and trainers do). One of the core tenets of agile is the self-organizing team. The team is ideally cross-functional, dedicated, committed, and accountable. Ideally, they are also co-located. All of these are easier said than done.
Agile traditionally valued co-located teams. As agile and the world evolve and confront change, virtual teams in agile are normal and very effective when supported with appropriate technology and leadership.
Challenge – Dedicated Teams
In my own career, I’ve delivered projects with and without dedicated project teams. It’s unquestionably easier to deliver with a dedicated project team. Agile frameworks assume small, dedicated project teams, and agile projects face immediate impediments without dedicated project teams. Many organizations cannot grasp the importance of dedicated project teams for getting critical work done quickly and efficiently. Instead, these organizations spread out their people across multiple projects, creating the false sense that by touching many projects at once, they are somehow making progress on all of them simultaneously. This is a manifestation of the perpetuated myth that organizations must and can “do more with less.”
“Do more with less” is senior management bullshit often heard in organizations that recently downsized or that experience rapid growth but can’t or won’t staff up to handle it. One area where this is especially prevalent is in delivery of projects, whether agile or plan-driven. Many organizations ask the same group of people to operate their business and deliver multiple projects to enhance the organization at the same time and then wonder why they experience poor results.
The “do more with less” approach creates scenarios where operational and production emergencies delay or stop value-adding projects. This approach causes inefficiencies while lowering morale and causing turnover and automatically puts an organization’s projects at risk when the same people are doing everything. The risks come in two forms: tactical risks to the projects themselves and strategic risks from the delay in return on investment when these projects take much longer than expected.
They focus on delivering the vital few projects in shorter timeframes.
They are willing to put the organization’s best people on teams dedicated to these vital few high-value strategic projects.
They prioritize ruthlessly to get these projects done quickly and efficiently without allowing production and operations matters to throw up unresolved impediments.
In practical agile, we do not delay high-value projects by assigning the people to handle production and operations and to multiple project teams. This applies to the business as well as technology teams. Every contemporary company is effectively a technology company – therefore, the organization’s best business and technology people must be dedicated to value-creating technology-driven projects.
This is a significant change in strategic thinking and structure. Many companies organize and hire functionally and treat projects as exceptions to functional assignments. Agile requires companies to organize, plan, and hire based on value-creating projects and workstreams that can continuously transform the company. This approach also requires conscious development of organizational structure and hiring models that start new people and teams in operational and “keep the lights on” roles, while constantly grooming subject matter experts (SMEs) and technologists who can apply their growing experience almost exclusively to improving the business through value-oriented projects.
Identifying and correcting the risks and inefficiencies caused by the “do more with less” syndrome requires agile practitioners and senior leaders to examine resource assignments within their project and program portfolios. If the same resources are assigned to multiple projects and are also responsible for operations and solving production issues, the core agile tenet of dedicated project teams cannot be realized.
Regardless of the project framework used to deliver projects, the most successful and innovative companies focus their best business and technology people and organize around delivering critical projects. These companies outperform their competitors – not by doing more with less, but by focusing on a vital few high-value projects, getting them done, and moving on to the next while shielding these project teams from operational distractions.
Imagine you wake up one morning and find that somehow, there are five massive boulders blocking your three-car garage. In the garage, you have two cars and a boat. One of the cars is needed immediately, while access to the boat would be desirable, and access to the other car can wait a bit longer. You have your significant other and two strong teenagers as resources, along with the assistance of your neighbors who have volunteered to help.
- 1.
Spread everyone out across all five boulders and ask them to try to move each one a little bit throughout the day?
- 2.
Get everyone together on the boulders blocking access to the first car, move that one, then the boulders blocking the boat, and finally the boulders blocking the other car?
The obvious answer is (2). Yet organizations choose (1) all the time by failing to create dedicated project teams and hold themselves accountable for disciplined prioritization and vigorous, focused execution of a vital few projects.
Challenge – Cross-Functional Teams
In addition to small, dedicated, self-managed project teams, agile also assumes these teams are cross-functional. Cross-functional teams are valued because, in theory, these self-managed teams can work more quickly and efficiently than teams made up solely of specialists, or worse, reliant on specialists from outside of the team. Does this mean that everyone on the team should be either a generalist or know how to do everything that the project work requires be done? No – this is not realistic and would introduce its own inefficiencies.
I tell my students and the organizations I lead or consult for to think of cross-functional teams like this: Everyone is really good at their thing, knows how to do one or two other things well enough to pitch in, and everyone is accountable for checking for quality and helping to clean things up. Here are some practical examples:
For several years, my wife and I were fortunate to know a handyman (Joe) who did a lot of repairs and renovations to our house. Over the years, Joe remodeled bedrooms, basement rooms, bathrooms, kitchens, and decks. Joe knew how to do several things really well, knew enough to take on some other things, and also knew his limitations. For larger projects like our basement office and kitchen, Joe assembled small cross-functional teams. Joe was a good project leader and brought in Don for detailed design and carpentry, and a couple of other guys for general carpentry. Don also knew plumbing quite well, and everyone knew how to drywall, lay flooring, and how to paint. When they needed electrical, they brought in that specialty for the specific task.
Both our basement office and our kitchen remodel projects had to be done in specific four-week windows, and Joe and Don effectively ran each week like a sprint, with a backlog of work to be done each week and goals for each day of work. When one of the team was done with his specialty work for the day, he would assist one of the others, and everyone checked out the quality of the work completed each day and helped to clean up the jobsite.
Mike Cohn, a well-known and respected agile writer and trainer, notes that cross-functional teams don’t necessarily mean that everyone on the team can perform every task or has every skill. Cohn notes that “A cross-functional team has members with a variety of skills, but that does not mean each member has all of the skills.” Cohn provides the example of having a highly talented database developer on a team. The intent would be to allow that person to focus on the database, but to ensure that the team had enough multiskilled members to complete their committed work within each sprint.
Cohn illustrates this with another example. A grocery store has cashiers who scan items and handle payment and will also have baggers bagging groceries. If the bagger gets behind, the cashier shifts and helps bag items. The multiskilled cashier/bagger allows the store to use fewer specialist baggers per shift (Cohn, n.d.).
Testing in software development is one area where cross-functional work has a significant impact. Everyone can test, or support the testing of completed features within a sprint to help their team meet their commitment. Some organizations like Salesforce have eliminated dedicated QA testers from their software teams and require all developers and architects on their teams to test. One senior vice president of engineering at Salesforce explained that everyone is accountable for quality and testing, and that developers rotate quality assurance/quality engineering roles during releases (Ayers, 2016).
Organizations must commit to developing the multiskilled team members desired for agile teams and projects. This is achieved through both intentional hiring practices and cultivation of cross-functional skill sets. Leaders and managers who want cross-functional people and teams will hire “T-shaped people.” These are people who, in addition to having a specialty, also have other interests and skills that enable them to contribute to their teams in multiple ways.
Organizations must also commit to growing their own cross-functional people. In practice, this means that leaders intentionally develop project teams with the intent of ensuring cross-training can happen and also understand that short-term project results will be affected and accept this as desirable for the long-term goal.
Challenge – Co-location
Effectiveness of communications – Adapted from Ambler (2005) and Cockburn (2002)
This speaks to agile’s preference and premium on co-located project teams. The ability to turn and talk to a team member, walk over to their desk, or hop into a conference room or in front of a whiteboard is extremely valuable to the progress of the team and their work. As soon as phone calls, emails, and meetings are introduced into the communications stream, the speed and efficiency of the team is affected. Then, questions or needs for quick assistance instead become impediments, which leads to work not getting done in sprints and missed commitments.
Practically speaking, co-location is not always possible, practical, or even desirable. As of this writing, there is plenty of literature on the effectiveness of remote work and work-from-home options. I have led agile software implementation and development teams with team members spread across the United States and with customers in the United States, Europe, and the Asia-Pacific region, all with remote/distributed teams. Collaboration tools such as Slack, Teams, WebEx, Zoom, Jira, Azure DevOps, Rally, VersionOne, and countless others enable agile teams to create shared workspaces and collaborate in real time without being co-located.
Avoid the War Room Mentality
When it comes to successfully delivering projects, organizations should focus less on where team members sit and instead focus on how teams are organized. In my experience, physical proximity has less to do with getting to “done” than do the strong relationships present within a long-lived, cohesive team.
In one of my recent consulting gigs, I was asked to take over a troubled project that was over a year past its original scheduled completion date. When I was asked to step in, the organization’s functional managers had already twice attempted to finish the project by putting the project team in a “war room” on the assumption that the issues would be partly solved by physical proximity.
In the case of this troubled project, the war room was perceived by the team as a punitive measure. Forced co-location is sometimes used with the dual purpose of ensuring that necessary people are present as well as providing an incentive to the team to get done and therefore be allowed out of the war room. When used as a punitive measure, it is not motivating for the team and can cause valuable team members to take their careers elsewhere.
Rather than jamming people who are not otherwise functioning as a team into a room and telling them to finish the project if they want to be allowed to go back to their usual working spaces, organizations must focus on creating long-lived teams that develop trust in each other along with a shared and deep knowledge of the products, projects, and systems they work on.
Such teams will be more likely to deliver no matter where they are sitting. Along with trust in each other comes increased and sustained knowledge of the products or business functions the team is working to improve. This in turn fosters increased productivity as well as increased quality. As well, these teams develop dependability in one another along with the psychological safety that enables highly functioning teams to creatively and productively debate ideas without fear of repercussions (Schneider, 2017).
Discouraging punitive co-location while highlighting the productivity of remote workers is by no means a knock on co-located teams. Physical proximity definitely helps teams rapidly communicate and collaborate. When possible, it’s always ideal for teams to be long-lived and co-located. However, co-location of teams that are usually distributed or remote should never be forced or punitive. Whether co-located or distributed, successful teams are long-lived, cross-functional, and aligned with business processes. Organizations do well to keep these teams together for as long as possible, regardless of where each team member sits.
Practical Examples
During my time at CloudCraze Software (acquired by Salesforce in 2018), we brought our distributed software development teams together as we finished a release and completed our planning to launch a new release development cycle. These gatherings combined a celebration of work and socialization with release retrospectives and release planning sessions. Typically, the first day would be a welcome and introductory session describing what the program would be for the remainder of the week. That evening would be the main social event in which people who hadn’t seen each other since the last release would reconnect and we would celebrate our most recent accomplishment as a team.
Day two would consist of a release retrospective inclusive of full walk-throughs of the new release for other parts of the organization like professional services, customer success, support, and other company executives. This provided an opportunity for the development team to showcase their complete release as well as provided the vital function of familiarizing the rest of the company with new features and any important defect resolutions that may have been completed. The remaining days were filled with refresher training on items like developing secure code or latest features from the Salesforce platform on which we built and then detailed planning to get ready and launch work on the next release.
Many other organizations using distributed/remote teams do something similar – periods of remote work are punctuated with team gatherings where the teams forge and renew personal relationships and work together for intense periods of time. For example, in The Year Without Pants, Scott Berkun describes the year he spent working at WordPress and how one of their practices was to gather their teams for working and social interactions periodically. Berkin describes how the combination of personal interaction for both social and work outcomes helped to strengthen the team dynamic and also get work done while the team was together and after they returned to their distributed norm (Berkin, 2013).
At Salesforce, a senior VP of engineering described to me how their distributed teams were in San Francisco, up and down the West Coast, in Florida, and some in small offshore groups. As with the other examples here, these teams would co-locate periodically when possible (Ayers, 2016).
Challenge – People
I sometimes get cheap laughs in my classes and presentations by saying “projects would be easy if we could deliver them without people.” After the chuckles (and eye-rolling) stop, I typically speak to the need for respect and understanding on project teams. Working through the differences in people’s work styles and personality types really is one of the biggest challenges in any project environment. The heightened commitment and accountability that are core to agile practices can exacerbate or highlight work style and personality differences, for better or worse.
Agile is totally collaborative and values real-time communication and people interaction.
Stand-ups and retrospectives are critical opportunities for real-time feedback from other team members.
To be valuable and useful, feedback requires both immediacy and respectful interaction that acknowledges and values differences in people’s styles, thinking, and communications.
This means that agile practitioners must develop their soft skills and become proficient at giving and receiving constructive and respectful feedback, collaboration, and finding value in constructive conflict while maintaining respect for people and the team as a whole.
The team member may be new or junior – they are somewhat intimidated by the experience of the other team members and fear looking incapable with the feature they are stuck on.
The scrum master is wondering why this feature is taking so long but has to recognize how the new team member may be feeling while balancing the need and responsibility to help the team self-manage and work through impediments.
The more experienced team members may have realized something was up earlier in the week and wondered why the newer team member did not ask for help.
Everyone in this scenario must recognize that the commitment as a self-managed team requires the new team member to be honest about their impediment and for the rest of the team to be supportive and respectful while also teaching both technical and agile principles to resolve the impediment.
Projects would be easy if they could be delivered without people.
—Shawn Belling, bad punchline from agile course delivery
Summary
In this chapter, we have examined some common issues involving agile teams. We’ve looked at dedicated teams, cross-functional teams, co-location, and virtual, avoiding certain mistakes like the war room, and reviewed some practical examples of how agile teams can be effective in co-located and virtual settings.
Chapter 7 will discuss the role of various agile servant-leader roles: the scrum master, the agile project manager, the agile coach, and others. Chapter 7 will also dive into the meaning of servant-leadership and its importance in agile and hybrid methodologies.