By Alan Bustamante & Rahul Sawhney

Transcription

1 By Alan Bustamante & Rahul Sawhney

2 Copyright 2011 Seapine Software, Inc. This work is licensed under the Creative Commons Attribution-Noncommercial- No Derivative Works 3.0 United States License. To view a copy of this license, visit or send a letter to Creative Commons, 171 Second Street, Suite 300, San Francisco, California, 94105, USA. Seapine is proud to be a member of the Agile Alliance.

3 Contents The Ultimate Agile Project Team Scaling Agile Project Teams The Enterprise Agile Project Team Key Challenges to Scaling Agile Project Teams People Challenges Addressing People Challenges Process Challenges Addressing Process Challenges Tool Challenges Addressing Tool Challenges Scaling Agile In a Nutshell

4 The Ultimate Agile Project Team In a perfect world, the ultimate Agile project team is small and co-located. After all, Agile best practices tell us we should communicate daily, face to face, and be able to walk over to a colleague s desk to discuss issues. Best practices also say team size should not exceed nine people, with the ideal team being five to nine people. This is why we often say the ideal team consists of seven people, plus or minus two. What happens when your Agile project team is larger than that? Or is not centrally located? Or both? Don t worry, you can still be Agile. A Word about Enterprise Agility Enterprise-wide Agile processes should go beyond the individual or group of teams, and should help the entire organization become more nimble, responsive to change, and successful in the long term. Incremental project funding and portfolio management are examples of the results of enterprise-wide Agile adoption. However, both are beyond the scope of this ebook. The enterprise view of the product portfolio is illustrated in Figure 1, with the Product 3 Backlog, which is the focus of this ebook, highlighted in blue. Later Next Quarter This Quarter Product 1 Backlog Enterprise Roadmap Product 2 Backlog Product 3 Backlog Team 1 Backlog Figure 1: Enterprise view of backlog management Team 2 Backlog Team 3 Backlog 1

5 Canada U.S.A. Brazil E.U. Russia China Philippines India Figure 2: Globally distributed project team Scaling Agile Project Teams In this ebook, we ll cover how to scale Agile project teams, specifically addressing both team size and team distribution. Because both aspects are independent of each other, a few combinations are possible. For example, a team might be large and co-located or large and geographically distributed. For our purposes, a large project team consists of more than nine people and requires two or more Agile sub-teams. Throughout this ebook we ll refer to team as the project team and sub-team as the smaller teams that comprise the project team. Team distribution also covers co-located and geographically dispersed teams, with the latter meaning teams with members located in different buildings, different states, or different countries as shown in Figure 2. 2

6 The Enterprise Agile Project Team An enterprise Agile project team successfully adapts Agile philosophies and methods to large or distributed teams. As teams grow, they need to ensure three things remain in harmony: people, process, and tools what we ll refer to as project support pillars (See Figure 3). 1. People refers to the things that affect team culture, unity, bonding, dynamics, and structure. 2. Process refers to the method of software delivery. For large or distributed teams (or large distributed teams), processes should be repeatable but flexible. 3. Tools refer to the things (not necessarily software) that best facilitate the team s success. People Disorganized Team Inefficient Team Enterprise Agil e Project Team Tools Disengaged Team Process Figure 3: Enterprise Agile project team support pillars with intersection points 3

7 Regardless of project team size or distribution, the three pillars need to be in harmony. As Agile project teams grow and become enterprise Agile project teams, the three pillars can start to crumble quickly. If not managed appropriately, Agile project teams attempting to scale can quickly spiral out of control. The danger from this breakdown creates problems at the intersection points shown in Figure 3. Risks When people and process are aligned, but not tools, the team becomes inefficient. This inefficiency can lead to communication gaps and insufficient sharing of data or information. When people and tools are aligned, but not process, the team becomes disorganized. It s important for the team to have a flexible process that allows sub-teams to accommodate their own needs. Disorganization can lead to breakdowns in the flow of delivery. It can also lead to misunderstood reporting structures and patterns. When process and tools are aligned, but not people, the team becomes disengaged, which presents serious risks to the success of the project. Agile methodologies rely heavily on people interactions and personal commitment to drive project success. If your people are not engaged, the other two pillars will be difficult to keep in harmony. Disengagement can lead to subversive behavior that undermines the success of the project. It can also lead to lack of cooperation within and among sub-teams on the project. 4

8 Key Challenges to Scaling Agile Project Teams You may face three types of challenges when scaling Agile project teams: people challenges, process challenges, and tool challenges. Let s take a deeper look at these challenges, and examine how to address each one. People Challenges When teams grow and become distributed across multiple locations and time zones, it becomes increasingly difficult for team members to keep track of what is going on with the project. There are several reasons for this increased difficulty, but most can be tied to lack of communication. As teams grow, it becomes difficult to keep everyone focused during daily stand-ups because these meetings tend to become longer than 15 minutes. Other meetings (such as release and iteration planning, retrospectives, and iteration reviews) also start taking much longer. Longer meetings, with seemingly more bureaucracy, can erode a team s enthusiasm and focus. When a team is distributed, face-to-face communication suffers. Coupled with the typical time differences between the teams, significant communication gaps can occur among team members. In addition, organizational structures, people, and performance management practices (such as roles and responsibilities, performance evaluations, goal setting and career progression) for different locations may not be aligned. Remote team members may start to feel that colleagues at the corporate headquarters are more empowered to make decisions than they are. This feeling can create insecurity and negative competition between team members at different locations and, in turn, can harm the organization. 5

9 Finally, cultural issues influence team dynamics. When two or more organizations collaborate on a project, differences in organizational culture can significantly impact team performance. For example, an organization that is very focused on employee empowerment and servant-leadership might struggle to work with a partner that insists on rigid employee reporting hierarchies. Cultural differences related to geography can also create disagreements and hard-to-correct misperceptions. This challenge is further exacerbated by the lack of face-to-face interaction, where tone of voice and body language can communicate a person s intent and demeanor much more effectively than an . Note: People issues can occur, even on small Agile teams. To ensure teams perform effectively, pay attention to people and interactions in all teams, regardless of size or distribution. Addressing People Challenges People issues are best tackled through structure, empathy, communication, and people-oriented policies. Ensuring that team communication stays effective is important. When a team becomes large, look for ways to split it into smaller sub-teams so employees stay focused and, in the case of Scrum, there is sufficient Scrum Master and Product Owner capacity. Time zone differences often force team members to work during odd hours to keep communication channels open. Flextime and work-at-home policies enable and encourage collaboration between employees in different time zones. Aligning organization structures and people practices across locations helps align team member expectations. If team members work for an outsourcing partner, organizations should make sure those team members can be integrated 6

10 with the rest of the team and that issues related to differences in organizational culture do not impede productivity. Culture differences are best handled by understanding and appreciating them. It helps if team members can travel to other locations and meet with their colleagues in person. Training on cross-cultural sensitivity also helps team members appreciate differences better. In addition, using tools helps enhance interaction and collaboration. We ll discuss these tools in a moment. Because communication-related issues are to be expected, it s better to be prepared for them by setting up clear escalation paths and aligning structures for product management, project management, technology, development, quality assurance, deployment, and other areas of the organization. Also, because individuals and interactions are so important on Agile projects, it is critical for organizations to provide coaching and mentoring for all team members on multiple aspects of Agile development, including: Project, release, and iteration management Design, development, and testing practices Rapid continuous integration and deployment practices Good coaches will help organizations adopt innovative mechanisms that engage teams and encourage self-organizing team behavior. 7

11 Process Challenges Processes should help teams become more productive and streamline their activities by reducing overhead. When teams are small and co-located, processes are easier to implement and there may not even be a need for formal processes. Team members know how to work well with each other and are in control of their activities. As teams grow larger or become distributed, it can become difficult to keep team members aligned with the project s or organization s objectives. Large teams can rapidly slip into chaos when there is no clear understanding of the execution and delivery processes. Not only are individual contributors forced to spend more time understanding and communicating the process, but misinterpretation can lead to time wasted on activities that don t add value. When process challenges emerge due to scaling, organizations will sometimes create multiple teams focused on delivering components (e.g., data layer) to address the issues. DO NOT do this! Component teams, which target specific components or layers of software, create strong dependences among all the component and non-component sub-teams of the project. Instead of delivering a complete set of features based on business value, these strongly coupled component teams are unable to implement features on their own, which slows down the process of delivering value for the customer. Another way that many organizations try to resolve process challenges is by mandating the use of a one-size-fits-all process. This is extremely common when Agile initiatives are driven from the top down, but this fix is unlikely to work across project teams or sub-teams. Because each sub-team s experience is generally unique, they re often resistant to a one-size-fits-all 8

12 approach. Also, the communication and cultural issues outlined previously will begin to bubble up if teams are forced into adopting certain practices without any consideration for their specific needs and challenges. Addressing Process Challenges Using Agile processes on a large scale can dramatically change organizations in many ways. Addressing process challenges for scaling requires organizations to understand their process focus and ensure it is aligned with the organization s vision, mission, and values. The team that is responsible for delivering the project s outcome should be engaged to get their input on how to make the processes useful for them. Where legal and regulatory obligations are concerned, special consideration should be made when adopting Agile processes. Processes should be sufficiently piloted, tweaked, demonstrated, and recognized for success to be accepted by the enterprise. Organizations should consider using established Agile frameworks, but should not be afraid to mix in other methods. Processes should be repeatable to improve the predictability of results, but should also be adaptable so teams can freely experiment and continuously improve their performance. If an organization wants to use Agile methods for enterprise projects, it should carefully examine how the product backlog will be structured and prioritized, and how the work will be assigned to teams. Process and structure should allow teams to quickly identify and pull the most important item that needs to be worked on. When teams are large or spread across multiple geographical locations, sub-team interactions need considerable attention. For example, in the case of Scrum, participants, duration, frequency, and schedule of Scrum-of- Scrums meetings should be well thought out (see Figure 4). 9

13 For long-term success, processes must also continuously evolve. Organizations and teams should continuously monitor a process s function through various inspect and adapt methods. For example, regular retrospectives are a good way to monitor performance at the end of each iteration, daily stand-ups are good for daily monitoring, and iteration reviews are good for gathering broad stakeholder feedback. Every 24 Hours Scrum of Scrums Tool Challenges Tools should facilitate the team s success. But, as teams grow and expand across geographical boundaries, some distinct challenges start to emerge. Perhaps the tools aren t integrated and can t tie all pieces of product development together. Tools can also introduce waste into the delivery process in the form of overhead and duplication of work. The result is gradually increasing technical debt as the product becomes more complex. Figure 4: Scrum-of-Scrums means one person from each sub-team forms a Scrum to update each other on each sub-team s progress. 10

14 Addressing Tool Challenges Addressing tool issues is tricky because there are so many tools to choose from, and one option rarely solves all issues. Focus on tools that facilitate the team and sub-team s processes by eliminating or minimizing non-value-added work. Tools should support the team s process, not dictate the process. Note: Addressing tools alone is not sufficient. Configuring tools around a flawed process will still result in a flawed process. Fix any people and process issues first. Real-time collaboration tools, such as voice over IP, video conferencing, chat, social media, and web-based meeting tools, such as Citrix Online s GoToMeeting, should help an enterprise Agile project team get a handle on stand-ups and other meetings. Robust enterprise Application Lifecycle Management (ALM) products, such as Seapine ALM, tie all pieces of product development together, ensuring the team spends less time supporting piecemeal solutions or solutions from multiple vendors, and more time on value-added work. Ultimately, the team should decide what works best for them. 11

15 Scaling Agile In a Nutshell As we ve seen, you can still be Agile even if you have a large, distributed team. Here s what we learned: As teams grow, they need to ensure the three project support pillars remain in harmony: people, process, and tools. People refers to the things that affect team culture, unity, bonding, dynamics, and structure. Process refers to the method of software delivery. Tools refer to the things (not necessarily software) that best facilitate the team s success. When people and process are aligned, but not tools, the team becomes inefficient. When people and tools are aligned, but not process, the team becomes disorganized. When process and tools are aligned, but not people, the team becomes disengaged. People issues are best tackled through structure, empathy, communication, and people-oriented policies. Addressing process challenges for scaling requires organizations to understand their process focus and validate that it is aligned with the organization s vision, mission, and values. Focus on tools that support and facilitate the team and sub-team s processes by eliminating or minimizing non-value added work. Configuring tools around a flawed process will still yield a flawed process. Fix the people and process issues first. 12

16 About the Authors Alan Bustamante, PMP, CSP, leads Seapine Software s Agile Services practice. Alan has worked with software development teams for more than 10 years in tester, software engineer, business analyst, and project manager roles. He has worked on projects in the Americas, Asia, and Europe, and in multiple industries, including energy, insurance, IT, manufacturing, non-profit, and telecom. Alan has spent the last four years leading Agile teams, and is passionate about promoting Agile values through his community involvement. Be sure to follow Alan on Rahul Sawhney, Certified Scrum Professional (CSP), started his career in 1998 as a developer with Tata Consultancy Services and now works as a Senior Project Manager with Citrix Online. He is passionate about Agile development, and has been managing Agile teams and leading Agile transformation initiatives for over five years. During his career, Rahul has worked with multiple organizations and distributed teams across the globe, helping them adopt and succeed with Agile. Connect with Rahul on LinkedIn: 13

17 About Seapine Software With over 8,500 customers worldwide, Seapine Software, Inc. is a leading provider of quality-centric application lifecycle management solutions and services. Headquartered in Cincinnati, Ohio, with offices in Europe and Asia-Pacific, Seapine s development tools help organizations of all sizes streamline communication, improve traceability, achieve compliance, and deliver quality products. Seapine s products support best practices, integrate into all popular development environments, and run on Microsoft Windows, Apple Macintosh, and Linux platforms. Tweet this Share on Facebook Share on LinkedIn 14