Guessing is not a strategy: How to build decision velocity with AI and real-time data
June 10, 2026 | Live Webinar
6 Communication Tips for Distributed Agile Teams
| Distributed agile teams have to overcome distance and time to achieve what Alistair Cockburn describes as "osmotic communication" -- tacit knowledge and spontaneous discussion. Speakers at an October 2012 summit on distributed agile teams offered six tips for improving high-bandwidth communication: 1. Make a Time Zone Table. You may know this already, but this tool is a must for finding times for meetings required by your agile process, including daily Scrum meetings, estimating, planning, demos and retrospectives. To create one, use a spreadsheet to list rows of times for potential meetings and corresponding time zones for all members. For example: Be aware of each location's typical work hours, and make a separate table or calendar of holidays. 2. Break language barriers. Even when remote team members speak the same language, don't assume smooth communications. For example, some people have heavier accents than others. Language barriers can particularly impact the efficiency of agile teams, which include daily standup meetings. One solution is to assign a spokesperson with better language skills in the team's common language (English, for example). Also, be mindful of cultural metaphors and idioms that may not make sense in other countries. 3. Increase visibility. Because agile teams use task boards to show stories and associated work, communications can become complicated for distributed teams. To show the many visual elements used in agile -- from notecards on a wall to task boards -- teams need to think beyond web cameras. Try using online tools, which can range from free task boards to full-service applications with analytics and portfolio management. Or opt for spatial collaboration environments such as Terf©. Terf shows cards for each task on the wall in the context of other charts and team members. Online virtual rooms deliver contextual information and a sense of co-presence, where distributed agile teams experience the collaboration they are accustomed to in a face-to-face environment. 4. Improve sound. Agile teams rely on high-bandwidth communication. And clear audio is essential in the frequent meetings necessary in the agile process. So if you are using voiceover IP, avoid wireless for a more stable connection. Little things go a long way in improving sound quality, too. Use a USB headset or ear buds to avoid feedback and echoes from built-in speakers. Consider investing in a better microphone. Some have digital signal processing to reduce noise, some are excellent for large rooms and some have different patterns to accept or reject sound. Finally, provide text chat for backup communication and questions during a long discussion. 5. Go on the record. Recording audio from conference calls and screens from slide presentations keep team members informed if they cannot attend in real time. This is especially helpful for informing offshore team members in crucial content meetings, such as agile planning. Just beware that without the interactivity, it is harder for people to remain engaged. So with recordings, try to keep it short. 6. Organize by component, not role. Some teams may be tempted to assign people in one location one role. Yet team members on agile teams are encouraged to share roles. So what's the solution? Cross-functional teams by location, working on a subset of your project. This improves communication between locals, reducing overhead. What communication challenges and solutions have you experienced for your distributed teams? Go beyond communication tips -- find out how to apply measures and metrics of agile techniques into your projects. PMI members can dig deeper into the topic, with expert tips on the many facets of agile. |
Want a Career Edge in 2013? Carpe Diem
Categories:
Career Development
Categories: Career Development
| In my last post, I promised some pointers for what to do after you've identified your career goals. My suggestion is to toss them aside. It may seem to defy career logic, but here's why it works: While our definition of success evolves slowly, the specific steps and goals that get us there can and should change with the circumstances. And circumstances are changing ever more rapidly. For example, a meaningful goal can quickly turn into a waste of time with a corresponding opportunity cost. I remember sitting down for my first career-planning session when I got into line management at IBM in the late 1980s. My manager and I carefully mapped out a plan that included various entry-level positions, followed by roles in middle management and then executive management. It all looked pretty good. Then along came the great upheavals of the late '80s and early '90s that stripped away entire layers of middle management. I found myself with a plan that led to a place that no longer existed. I was trapped in career limbo, until finally I was forced into a role as a system architect. Frankly, that didn't work out very well. But in that role, I attended a conference on software development and learned about project management as a profession. It intrigued me, so I sought out more information about it. You see, the system architects on my team were brilliant technologists. But they weren't good at planning their own work. Opportunity! I suggested that perhaps I could add more value in the role of project manager. The rest, is history. Had I relentlessly pursued the goals outlined in my career plan, I probably wouldn't have survived past 1992. But when serendipity and opportunity intersected, I seized the moment. As a result, I've had a rewarding career, one in which I see myself as successful. (In this regard, my perspective is the only one that counts.) The moral of the story? Where you will end up in your career 25 years from now may have nothing to do with your grand visions of today. Here are a few other suggestions to keep you on course but flexible:
Systematically pursuing relevant goals and adopting new ones as others become irrelevant is a delicate balance. But the resulting career agility is well worth the effort. |
The Scoop on Requirements Scoping
| We've all been there. When a project's scope isn't properly managed, it can lead to schedule delays, budget overruns or not meeting project goals. Requirements scoping can help keep projects under control by establishing what criteria — such as prioritization — will drive decisions. The process also clearly details what the project will deliver, and perhaps just as importantly, what it won't. Depending on a project's complexity, goals and project management approaches, there are various ways to manage requirements scoping. Here are three of the most common. 1. Early scoping assumes all scoping is done as part of the project charter or during the scope definition. The approach relies on precise estimations of required resources, budget and time. It discourages scope creep and requirements changes. The advantage of early scoping is that it facilitates starting project work ahead of time. On the other hand, poorly estimated efforts can translate into budget or schedule overruns, resources bottlenecks or missed project goals. Early scoping is recommended for projects where the main focus is on the scope, and on ones with no, or minimal, budget and schedule constraints. For example, early scoping works well on consolidation or integration projects, where the constraints on the scope (budget limitations, for instance) impact objectives. 2. Late scoping is performed after collecting, analyzing and even designing the requirements. At such late stages, efforts estimates are much easier to assess and generally more accurate. Although late scoping can keep a project within budget and schedule boundaries, this approach has a considerable downside: Efforts spent for out-of-scope requirements are wasted or deferred. Consequently, this leaves less time, budget and resources for addressing in-scope requirements — the ones that matter. Late scoping is recommended for projects addressing requirements that have similar (and not critical) relevance for the project's outcome — for example, regular maintenance projects. 3. Iterative scoping is a balanced, incremental approach. The entire scope is broken down and prioritized by items that have the highest relevance. These will be addressed in the first scoping round. The rest of the requirements, as well as potential changes or rework, are subject to scoping in subsequent iterations. The requirements scoping and the project work advance in a rolling wave approach. Iterative scoping is especially useful for IT and agile projects. How do you manage requirements scoping on your projects? |
Project Adjournment for Virtual Teams
Categories:
Teams
Categories: Teams
| While project managers often talk about building a virtual team, they rarely discuss disbanding one. I recently adjourned the virtual team I'd led for the past four years. As a dispersed team, we initially experienced some issues around cultural differences. But we came together eventually and produced the expected results for the organization. When the time came to close the project and disassemble the team, a different kind of challenge arose. The first issue I encountered was that some team members didn't want to leave the team. Over the life span of the project, we'd built a strong bond. And there was another layer of complexity as team members' cultural traditions and values informed how they expressed their disappointment. As I helped the team to reach closure, I discovered the more "face-to-face" time, the better. I tried to reduce the distance that separated us with video conferences. During these meetings, I would explain that team adjournment wasn't a loss, but rather an opportunity to meet new people and take on new tasks. With some team members, an impromptu call before the adjournment meeting worked fine. With others, I scheduled a conference before and after the meeting to ensure they would be okay. The second challenge was preparing team members for their next project assignment. During the transition process, it was important to see their reactions, so video conferences were helpful here as well. I also tried to keep the focus on how team members could leverage their experiences in our project for their next assignment. Finally, I introduced some team members to project managers in need of skilled resources. Two of my former team members joined projects this way. In the end, the team members understood that our strong bond wouldn't end just because the project did. We're always just an e-mail or a phone call away. As a virtual project manager or team member, what challenges do you face during team adjournment? |
Tailoring Communication for Top Stakeholders
| Given the amount of work involved, most of your project communication efforts should focus on the stakeholders crucial to the success of your project. And this requires answering two key questions: Who are the most important stakeholders, and why are they important? Determining who's important is usually straightforward, based on an assessment of the stakeholder's power and involvement in the project. Understanding why each "important stakeholder" is important helps you define the type of relationship you need to develop for effective communication. Enter the mutuality matrix, a useful project communications tool that starts with two dimensions:
These assumptions create four quadrants for categorizing each of the important stakeholders:
Once you understand the mutuality matrix, the way you communicate with each of the important stakeholders can be adjusted to ensure both parties achieve a satisfactory outcome. For example, the time and effort saved by minimizing communication with intractable objectors can be invested in building relationships with your key suppliers. Keep in mind that each stakeholder will also be either supportive of or opposed to the project. Important stakeholders against the project — typically competitors and objectors — usually need nothing from the project and your communication should be focused on minimizing the objections. Similarly, important stakeholders who need something from the project are usually either passive or supportive, and your communication should be focused on building robust relationships. How do you identify and communicate with important stakeholders? |