How to Manage Distributed Agile Teams

Key Success Factors

Share on facebook
Share on twitter
Share on linkedin
Share on reddit

Run-through

How do you make a successful distributed Agile software development team? Darn, I thought maybe this time we’d have a simple multiple-choice question. Okay, fine, tough questions – tough answers. The answer starts with a C, the letter that keeps everything going – from coffee, cash, and computers to communication, cooperation, and collaboration, it also works for CPU and things like Command & Control, Conquer…

What’s the Standard for a Successful Agile Team?

A successful agile software development team consistently delivers on time, and within budget, high-quality software that works as intended.

Give or take, WAI might be replaced by meeting or exceeding customer expectations, delighting users, and/or fulfilling its business objectives.

What’s noticeably absent are any metrics, but that doesn’t mean metrics aren’t useful. Success comes incrementally, by degrees, not all at once unless you’re playing Powerball. In the Age of DevOps, even successful teams can find ways to improve.

Causes of Failure and the Pareto Principle

Upfront, successful distributed Agile software development teams are the result of four things:
  • The Project Manager (and Project Requirements)
  • Team Skills and Structure
  • Communication Protocols
  • A Continued Improvement Effort
Developing a successful Agile software development team (any team, really) requires bringing dozens of little parts together into one cohesive formula. Fortunately, the Pareto Principle saves our butts by pointing out that a majority of effects originate from a minority of causes. PMI’s Pulse of the Profession: 2018, identifies the root causes for many failed projects. This is useful information for defining the obstacles to success. Going through this list, nearly two-thirds (12 of 17) of the primary causes of failure relate one way or another to project managers. Nine of them relate directly to project requirements. Some are shared with other stakeholders – C-levels and Clients. Only a small minority of failures are tied directly to the team.
PMI’s Pulse of the Profession: 2018

Success Starts with the Project Manager

This can be intimidating and the responsibility may seem overwhelming. Accepting this may be a heavy load, but think about it – it is logical that the project manager will have the greatest impact on a project. Nearly all teams do their best to do what they are asked to do, yet mistakes can happen. If the software specifications you layout are wrong or if they are not communicated clearly, problems can creep in. That you’re proactively engaging to make your team successful, you’re already on the right track. Now, you mainly need to have faith in the Agile methodology, your improvement processes and use checklists to verify that you’ve remembered everything. If and when something goes wrong, don’t be so hard on yourself. Learn from the experience and do your best to not make the same mistake twice. In all probability, one mistake – even a big one, won’t kill a project. It’s when they multiply and cascade into each other that chances for success diminish quickly. We have additional tips for anyone wanting to be a great software engineering manager and leader – you’re welcome to check them out!

Project Requirements

Properly defining project requirements involves a process to make sure the software you deliver meets your company’s or client’s expectations. A large part of this process is subsumed as a software cost estimation. The details are roughly the same whether you’re developing for a client or for your company’s internal use.
  1. Determine your customer’s needs – what the software will do, its target-market, user personas, and business objectives.
  2. Define the software’s modules, components, technologies, and other requirements.
  3. Create a feature roadmap to show the development sequence of each component.
  4. Create a visual mockup – (storyboard/wireframe) showing how everything fits together.
  5. Check that the customer agrees with items 2-4. Iterate as needed.
  6. Determine the project’s technical stack – languages, technologies, third-party resources, etc., and what you can cover with your existing team (in-house & outsourced).
  7. Look out for issues that can affect development timelines: R&D for new applications, parallel development with devices, certifications or regulatory approval.
  8. Check that the customer agrees with items 6-7. Iterate as needed.
  9. Determine the delivery date or deadline. For particularly urgent projects, assess what can be done later (assumed as technical debt) – manuals, social sharing, etc.
  10. Estimate the effort on a modular basis to finalize the Software Cost Estimate in a way tht lets the customer add/subtract features to fit their budget.
Many companies probably condense this into fewer steps, depending perhaps on whether they provide free cost estimates or charge for them as a professional service. Understanding customer needs deserves emphasis. Some clients may not fully know what’s possible with their software. This warrants educating them about their options. If they learn about an option later, they may come to you mid-stream with a request to add it.

Team Skills and Structure

Obviously, the number of skills useful to a team is mind-boggling in number, say nothing of other variables like where people are working and how large their team is. But we can define three primary factors that make successful Agile teams – agreeableness, skills, and team structure.

The ability to get along

According to McKinsey, “The two most important factors for a person working in an agile environment are the ability to handle ambiguity and a high level of agreeableness.” McKinsey goes on to clarify, “High agreeableness among team members means they respect others and their ideas, are able to work in cross-functional networks, and enable information transparency, understanding, and cohesion among group members.”

Skill coverage

It’s vital to know the technical skill proficiency and experience of your team member. If you’ve worked with your team for any length of time, you probably already have a good idea of what each member of your team knows – at least relative to the projects you’ve done so far. Automated analytics plays a part in being able to optimize teams on a per-project basis, as well.

Sometimes projects take you into new territory with technologies you haven’t worked with before. Check with your team and verify if they have experience in it, and if not, you’ll need to work with your IT agency. There are significant shortages for a number of skills, and they usually take longer or prove more expensive to fill.

 

Structure - How “teams of teams” are organized

Team size can also play a significant role though partially balanced by the manager’s or team leader’s ability. Agile recommends having teams with 3-9 members. Maximum efficiency is typically realized with teams of 4-5 members. Industry-wide, teams have 7 members on average. It’s advantageous in Agile when team members are able to fill two or more roles. In some teams, developers are responsible for the majority of their QA efforts. Some project managers with business analyst experience can fulfill the requirements of both roles. A typical software development team for a startup might look like this:
  • 1 Project Manager
  • 1 Business Analyst
  • 1 Designer
  • 2+ Developers
  • 1+ QA and/or other specialists as needed (data scientists, ML/AI specialists, etc.)

But, with success and funding, that team is likely to expand its development efforts. Instead of having 10+ developers reporting to a single software engineering manager, it’s more efficient to assign a team leader for every 3 – 6 developers. The team leader is then responsible for participating in the project meetings and sharing all relevant information with their team.

Fundamentally – software developers must eventually transition from developing their team to developing teams of teams.

The formula behind team size is N (N-1) / 2 which defines the number of combinations or relationships possible – 10 in a team of five; 21 in a team of seven; 36 in a team of nine. At issue is the strength of the relationships within a team and the relative productivity of the team members (i.e. Amdahl’s Law). The larger a team is the more inefficient it will be, as a near scientifically proven fact, beautifully illustrated by Agile Pain Relief. They cite a study by Putnam and Myers on a survey spanning 491 software projects finding that teams of 9 -11 people took around 2.5 – 3.5 times as long as teams of 5-7 and 3-5 to complete projects of a similar size. It follows in an archetypal sense in how small companies and startups are able to run circles around large enterprises. The inherent points of smaller teams apply to tighter relationships as team members are working more closely and frequently with each other. This helps to build rapport, cultivate trust, and identify knowledge gaps faster. It’s also less complex to assign tasks to 3-5 team members than 7+, making for tighter task descriptions and less ambiguity.

Communication Protocols

With a team distributed across multiple time zones, it’s important to set up a communications structure to guarantee everyone keeps informed and can get answers promptly. This applies to meetings, standups, retrospectives, code reviews and spur-of-the-moment, but time-sensitive questions. Your daily startup might kick off the day for your developers in California while those in Europe are getting ready to wrap up their day. There’s also the question of whether you’re letting your developers work flex hours/days outside of meetings. So, just like computer systems use protocols like TCP/IP or X.25 to connect with each other, in a distributed environment, so do we.

San Francisco

Thu 01:38:50

New York

Thu 04:38:50

London

Thu 09:38:50

Five Levels of Priority for Communication

TYPE DESCRIPTION USEFUL TOOLS
Formal and Fixed Any scheduled meeting – and 99% of meetings should be scheduled, preferably 24 hrs in advance. Video conferencing like Zoom or VR meetings with software like Spatial.
Routine Communicating the status of tasks to other stakeholders. Chat and instant messaging tools like Slack, and detailed notes in Jira or other PMS software.
Informal and Urgent Someone needs an answer, ASAP! Chat and instant messaging tools like Slack. If you need 360’ visibility on your team, Sococo can put everyone into a virtual office.
Casual Chitchat, ideas for future consideration, etc. Email
Ad Hoc SHTF scenarios requiring a formal response to something urgent. Ideally few and far between. Notify with Slack or call via Mobile to meet on Zoom.

If you’re not working in the same office and same overlapping hours, there is no guarantee you can communicate with someone immediately. Even then, they might be in the powder room and a full-on DefCon 1 scenario will have to wait. But going to the other extreme also bites. Contacting teammates late Saturday night with an important question starts with once, turns to twice, and pretty soon it’s a habit.

A Continuous Improvement Effort

Every team starts somewhere. With continuous effort, any team can achieve greatness. There’s a process for this as Renata Pataki, [CEO for Gitential / Gitential’s Head of Product ] also suggests in her article, Improving Agile Team Performance. Five of the seventeen reasons identified by PMI can be reasonably associated with team performance, directly or indirectly. These include team member procrastination, task or resource dependencies, limited resources, and the notorious, other reasons. This harkens back to Stripe’s Developer Coefficient citing a 31.6% developer inefficiency rate.

The core of any continuous improvement effort is being able to identify where improvements can be made and to prioritize improvements according to their impact. Renata points out that provided you maintain the same quality standards, an improvement in one performance metric will inherently improve multiple metrics. You can carry this over to your retrospectives to let your team decide which metric to focus upon, how to improve it, and how to measure the improvement. Over a year, your team will be able to work on at least two dozen performance metrics. The results should be readily apparent.

Automate Your Software Development Metrics

Gitential helps you to improve the performance of your software development team based on their Git activities with actionable insights. It’ll help you automate the gathering of software developer and engineer performance metrics, interaction analytics, frequency of commits, volume of code churn, and more! With this data, you can begin measuring the benefits of teamwork in software development, identify what’s holding your team back, improve cycle time, and more. Try Gitential now for free – no credit card needed!

Did you like our content?

Spread the word

Share on facebook
Share on twitter
Share on linkedin
Share on reddit

Subscribe to Our Newsletter

Don't miss our latest updates.
All About Software Engineering Best Practices, Productivity Measurement, Performance Analytics, Software Team Management and more.

Did you like our content?

Spread the word

Share on facebook
Share on twitter
Share on linkedin
Share on reddit

Subscribe to Our Newsletter

Don't miss our latest updates. All About Software Engineering Best Practices, Productivity Measurement, Performance Analytics, Software Team Management and more.