Agile Project Management Jim Highsmith Chapter 11

Scaling Agile Projects

Scaling Problems Expected success rates on small (< 10 people), short (3 – 6 months) projects is high. Success rates on large(1,000+ people), long (> 18 months) projects is much lower. Problems with large projects: Increased bureaucracy Excessive paperwork Unmanageable communication networks Inflexibility “Management expertise has become the creation and control of constants, uniformity, and efficiency, while the need has become the understanding and coordination of variability, complexity, and effectiveness.” Dee Hock 1999

Scaling Factors Given two teams… one a 6-person collocated team and the other a 100-person team divided into eight feature teams. Task: Setting up and maintaining the process and tools for Build, Integration, and Testing (BIT) How does the 6-person and the 100-person team handle BIT? 6-person team: Handled collaboratively with the entire team making the decisions and sharing knowledge would be informal and interactive. Team members would rotate BIT maintenance activities informally

100 person-team and Build, Integration, and Testing tasks A part-time BIT team of 3-5 people would be drawn from feature team members who had expertise and interest in BIT BIT team would discuss issues, do research, & propose the process and tools. The proposal would be discussed with feature teams, with team members providing feedback BIT team would make final decisions, set-up the BIT environment & document the process. BIT team members would provide guidance Support of BIT would be done by a rotating team

Collaboration and Coordination For an organizational perspective, agilists view all interactions as collaborative. Collaboration (working together to make a decision) is expensive… the BIT team collaborates to make decisions then coordinates those decisions with the feature teams. “Interpretation of Agile principles” … but as projects get larger, appropriate interpretation and application of the principles becomes difficult and more critical to success. A 100-person team will never feel like a 6-person team, but each can definitely be agile. The key is appropriately applying agile principles to organizational design, decision making and collaboration/coordination design.

Uncertainty and Complexity • Uncertainty comes from issues such as market uncertainty, technical uncertainty, number of customers, and project duration. • Complexity comes from factors such as team size, team location, dependencies, and domain knowledge. • Key questions… Should the project be agile? How should we adapt agile practices for this type of project? and… do we have a culture that capable of applying Agile principles to their project work and responsibilities?

Figure 11-1 An Agile Scaling Model

Business Goals Organization Product Management Team

Release/Project Management Team

Feature Team

Product Backlog

Capability 1

Process

Product Roadmap

Capability 2

Feature 1

Feature 2

Feature 3

Story 1

Story 4

Story7

Story 2

Story5

Story 8

Story 3

Story 6

Story 9

Agile Values

Release Plan

Iteration Plan

Building Large Agile Teams Bigger teams involve the need for more communication, more decisions, more meetings, more documents, and more politics… all of which are of value to the development of the project. Concerted effort in 4 areas is a perquisite: 1. 2. 3. 4.

Organizational design Decision-making design Collaboration/coordination design Applying Agile principles

Collaboration, coordination and knowledge sharing can result in too much communication, endless meetings, tons of documentation and emails.

Organizational Design Hierarchical structures and not compatible with the core values of a “adaptive” workplace. “The political agenda was furthered d by the hierarchy chart, which had little to do with dynamic, highly functional information management teams. Hierarchical IT infrastructures established an atmosphere where politics flourished and collaboration floundered. Hierarchies also let to an embedded culture that fostered adversity and encouraged the consolidation of individual power gases, as opposed to delivering quality information to the enterprise. As power gases enlarged, struggles ensued and adversity grew. You soon had an environment where 80% of workers’ time was dedicated to working around the system, and only 20% was focused on doing their job. Hierarchical management structures are also a classic way to punish those that refuse to play the game and to reward those who know how to manipulate the political machinery”

A Network Organizational Structure Figure 11-2

Feature Teams A-N

Collaboration / Coordination Design What makes communications design so difficult…. is that it rests on a foundation of relationships… of trust, respect, appreciated cultural differences and shared context. A team “in sync” can get away with lower effective means of communicating because they have good relationship contexts for sharing information. Simple set of collaboration guidelines • • • •

Use a wide variety of interaction modes Match interaction needs with collaboration practices Use lower-cost modes to the extent possible Use higher effectiveness modes on critical, higher-risk activities.

Reference… to an approach to implementing large selforganizing teams.

“Traveling pairs” “Every other iteration, a pair from one feature team could travel to the second site where they then pair with developers from the second team.” … transferring knowledge about the team’s features at a working level. “No matter how good the architectural decomposition of a product, two distributed teams working on the same product need a certain amount of working-level conversation and collaboration.” “Exchanging people will be much more effective than exchanging paperwork.” … or emails

Decision-Making Design When there is high risk, lots of coordination and collaboration is needed.

Framing questions for decision design: • What task are being accomplished by each feature and specialty team and what key decisions need to be made to complete these tasks? • What other teams are impacted by the decisions? • Do any of the impacted teams need to be involved in the discussions about the decision? • Who should make the decision (the feature/specialty team, the iteration manager, the product manager, the project leader, the project leader with the team)? • How and to whom should the decision results be communicated? • Who if anyone, should review the decision?

Feature team guidelines: “If in implementing a story the team abides by guidelines established (architectural decisions made by the preceding process, for example) and that implementation does not appear to impact any other team, then the feature team is delegated the right to make all decisions relevant to their story.” “Decision-making design should be part of the working agreement that all agile teams develop. Teams should not make unilateral decisions on items that impact another team without engaging that team in the decision process. So, for example, a team could not change an interface design without coordinating it with other teams that use the interface.”

How is a large agile team different from a large traditional team from an organizational perspective? 1. A large agile team has a flatter, less hierarchical structure – fewer layers of managers. 2. To the extend possible, decisions are pushed out to the feature teams or specialty teams. 3. Feature team members participate in specialty teams to ensure their input is heard and to take part in the decisions 4. Team decision making, whether project or technical decisions are being made, are accomplished in a participatory fashion. 5. Specialty teams are encouraged to issue guidelines, not fiats, and furthermore – like managers – they are encouraged to make as few decisions as possible. 6. Peer-to-peer (feature team to feature team) interactions and dependency management are encouraged. For example, rather than having a project leader manage inter-team dependencies, the teams themselves manage them through mechanisms such as Inter-team Communication Stories (ICS)… 7. The team embraces agile principles.

Knowledge Sharing & Documentation Agile Documentation Guidelines • The fundamental issue is knowledge transfer – understanding, not documentation. • Knowledge transfer requires person-to-person interaction, particularly as the complexity of the knowledge increases. • Documentation should be barely sufficient, but not insufficient: User overviews rather than try to document all the details. • High-quality readable code and test cases, particularly when the test cases are automated, may be adequate for detailed requirements documentation. • Models are a form of documentation. Keep them light and barely sufficient also. Develop only those models that are useful to the development team, and develop them “with” the team. • Documentation should be as informal as possible – while boards, flip charts, digital pictures, wikis, etc.

Agile Documentation Guidelines • •

• •

•

(continued) Interactive, dynamic documentation is important in agile projects: Wiki, Web 2.0 Working software is one goal of development, enabling the ongoing enhancement of that software is a second. Think about the barely sufficient documentation to support both. Documentation requirements vary by industry, company, and project. Permanent documentation is hat which as organization is will to spend the money, and time, to maintain. Working papers are documents that are used during a project (and may be very informal) but are not maintained. Don’t confuse these two types. User documentation should be identified as a story and prioritized by the customer team just as software stories.

Self-Organizing Teams of Teams Large agile teams consist of multiple feature and specialty teams… individuals are the agents in teams, whereas feature teams are the agents in a larger project. A network replaces the common hierarchical structure… Decision making and collaboration must be carefully designed… with discipline reflecting the rules of engagement across teams. What is needed: – The right leaders – Articulating the work breakdown and integration strategies – Encouraging the interaction and information flow across teams

“The project leader’s role should be to facilitate the interactions between the teams, not the specific activities each team uses to produce deliverables.” Key inter-team task is managing dependencies, a task frequently relegated to the project leader… All to often dependency management falls into the same traditional trap… management by documentation and not conversation. Each project is unique… leadership needs to experiment with interaction practices just as it does with technical practices. Similarly, establishing inter-team rules of engagement and accountability are important.

Example Rules of Engagement (Fig. 11-5) Feature Teams • Shall have input to, and participate in (the number of participating teams may be limited) architectural decisions that impacts tier work • Shall have the right to assess the impact of any architectural change and adjust estimates and schedules accordingly. • Shall have the right to request that the project leader review any architectural decision in which the team’s objection is overridden.

Architecture Team • Shall receive prompt information about and feedback on proposed architectural plans. • Shall expect prompt notification of problems that feature teams encounter in implementing architectural decisions.

Team Self-Discipline Individuals have responsibilities to their teams… teams must be self-disciplined in working within a larger selforganizing framework. Team behaviors closely parallel those of team members: • • • •

Accepting accountability for project results. Engaging collaboratively with other feature teams. Work within the project self-organizing framework. Balance project goals and team goals.

“When a team estimates how many stories it can deliver in an iteration, its members must factor in time to coordinate with other teams because team members will undoubtedly serve on specialty teams.”

Process Discipline Larger teams and excessive process … problems. Example End of wave… integration of several modules causes a few days of extra work. Typically, the problem leads to additional meetings to correlate the work. The meetings may take more time that fixing the problem… as well as unanticipated consequences of implementing the fix. So… the issue is not to react and attempt to anticipate “every” problem and establish processes to do this… it’s cheaper and faster to fix problem but not spend time anticipating them. I’m not sure how Highsmith’s rule “Don’t always fix things that are broken” applies to this example.