Modelos matemáticos disponibles

A

Effective Agile communities collaboratively establish and commit to a set of core values and working agreements that establish the “playground rules” for the project. Core values and working agreements are posted on the wall in the collaborative team workspace and are refined and revised as needed. While these values and working agreements are self-imposed by the Agile team, they must be consistent with organizational values and guidelines.

Core values establish the criteria for decision making and community behaviors. A team’s core values also establish the basis for a set of concrete working agreements. While the core values may mirror those of the entire company, it is valuable for the Agile community to establish and commit to its own set of values. I’ve seen Agile teams establish such values as “Pride in workmanship”; “Continuous focus on high quality”; “Respect, trust, and honor between team members”; “Have fun.” Note that values are broad- brushed statements about what is important to the team. They are not rules. Even when these value statements are similar to company statements, teams that develop their own, with their own wording, become more committed to them.

Working agreements are the rules established by a self-organizing team. They are not imposed by external forces; they are the set of specific guide- lines and behaviors that the team establishes to be highly effective. Working agreements can cover such issues as problem solving, decision making, team meetings, accountability, responsibility, and civility. I’ve seen teams estab- lish such agreements as defining a set of core team hours, when the devel- opment team commits to being together and focused on the project. I’ve also worked with teams that establish agreements about timely responses to requests and preference for face-to-face communication whenever possible.

The development team may establish an additional set of technical prac- tice working agreements such as “Pair programming is required for all story

ptg6843605 SELF-ORGANIZATION REQUIRES TEAM WORKING AGREEMENTS 131

development activities” or “Tests will always be written before the code is written to pass the tests.”

It is important that community members give one another permission to hold each other accountable to the values and working agreements. It can be challenging and sometimes daunting to call a teammate out for violating an agreement. To avoid this discomfort the team should establish a light- hearted and friendly technique for handling violations. Agile teams have been known to throw Nerf balls at the offender or shout out a silly code phrase to highlight the offense.

The power of a good set of core values and working agreements should not be underestimated. I’ve worked with teams that initially downplay these as “fluffy” or unnecessary. These teams typically arrive at some sort of impasse or difficulty in their early iterations that highlights the impor- tance of a common set of values and agreements. I once trained a team that was to be the first to “go Agile” in the organization—the pilot Agile team. Team members were hand-selected from a pool of talented and interested employees. The team was provided with all of the best physical resources (team room, high-end workstations, etc.) needed to succeed. The team was assigned a modestly scoped project so that its primary focus was on learning agility. In spite of these success factors, the team foundered during its first four or five iterations. I was flummoxed: great people, great working envi- ronment, formal training, management support. How could they possibly fail? After closely examining the team dynamics and analyzing the chal- lenges they were facing, I realized that they had not really committed to the working agreements I had them develop during the training workshop. The team members thought this was just a workshop exercise and that the work- ing agreements didn’t move with them into the team work environment. I gave them some general guidelines for team core values and working agree- ments and asked them to create their own (ones to which they were willing to commit) without me in the room. Improvements were apparent almost immediately. The team scrum master (project manager) later told me that the working agreements were key to solving the team’s problems. It became clear that the team members’ individual standards were inconsistent with one another, causing team strife.

Agile Analytics Practice: Establish Working Agreements

Taking the time during project chartering to establish a set of working agreements will boost team performance. These agreements should be published visibly in the team workspace.

ptg6843605

S

-O

R

H

C

Self-organizing and self-managing development teams are given the free- dom to make their own commitments during release planning and dur- ing iteration planning. They have the right to estimate the effort required to develop the desired features (and complete other tasks), and they are encouraged to plan within their limited capacity. Effective Agile teams plan to their capacity, make commitments that are within reason, and then take responsibility for ensuring that those commitments are met. Without com- mitments like these, the “we’re just responding to change” mantra becomes a ready excuse for always missing targets.

The catch is that business intelligence practitioners, like programmers, are eternal optimists. Occasionally our estimates are overly optimistic, and we commit beyond our capacity. In a traditional phased project plan these underestimates tend to accumulate over time and create a large pile of work in the project’s eleventh hour. You’ve probably experienced these projects. They are the ones in which the entire development team starts working 60, 70, and 80 hours per week near the project deadline. Quality of life suffers as does quality of work product.

In an Agile environment, these overcommitments put undue stress on the team’s ability to complete everything before the iteration’s end. A new itera- tion marks a fresh beginning, with a fresh set of commitments along with the lessons learned from the last overcommitted iteration.

Although establishing a sustainable pace is a key Agile principle, it is incum- bent on the team to do whatever is required to meet all of its commitments during an iteration. There are two key reasons why honoring commitments is essential to a healthy Agile project. First, development teams that fall short of their commitments soon lose the trust of other project community members and in turn the right to be self-managing. Second, a team that allows itself to fall short of commitments stands to create a pile of eleventh- hour work as in waterfall projects. In The Mythical Man-Month, Fred Brooks wrote the oft-quoted rhetorical question “How does a project get to be a year late? One day at a time” (Brooks 1975). An Agile variant of this quote might be “How does an Agile project get to be late? One iteration at a time.”

Effective Agile development teams bend over backward to meet their com- mitments, and when they get burned by overcommitting, they self-correct in the next iteration. This sometimes means late nights and long hours if

ptg6843605 SELF-ORGANIZATION REQUIRES HONORING COMMITMENTS 133

the team has committed beyond its capacity. While this may not sound like a long-term sustainable pace, it is sometimes necessary in the short term to maintain the overall health of the project.