APPENDIX X2
ATTRIBUTES THAT INFLUENCE TAILORING
X2.1 INTRODUCTION
This appendix provides high-level guidance on when and how to tailor agile approaches. It can be used to determine circumstances that might warrant changing or introducing new techniques, and then offers some recommendations to consider.
X2.2 FIRST SOME CAUTIONS
Tailoring is an advanced topic that should be undertaken by experienced practitioners who have been successful using agile approaches as originally described in multiple environments before they consider tailoring them. In other words, gain experience and be successful with one approach before attempting to tailor the approach.
A common response when struggling to adopt an agile practice is to consider whether to do it or not. A statement like “Retrospectives were unpopular so we decided to drop them” illustrates this issue and indicates a more fundamental problem on the team that is unlikely to be addressed by tailoring the method. The situation will be made worse by omitting the retrospective activity that aims to improve the process.
Finally, tailoring should be undertaken in collaboration with the teammates or whoever the change is likely to impact. People need to be engaged in the thinking and decision-making process about changing processes in order for them to commit and buy-in to the changes in order to have a successful transition. Omitting people from tailoring a process is likely to result in resistance and resentment to the change, even if it makes good sense technically. Often, experienced coaches or leaders can help to engage people effectively.
X2.3 HOW TO USE THIS APPENDIX
To benefit from the guidance listed in this appendix, we recommend first successfully using the agile approaches as designed. Then review the tailoring guidelines in Table X2-1 that match the situation and read the associated recommendations. Next, discuss the change with the people it will impact and agree on a course of action.
As discussed in Section 5, a good way to evaluate a change is try it for an iteration or two first before adopting it permanently. Or, consider a flow-based approach to try to deliver several features. Then, reflect with a retrospective and reassess.
When people know they can experiment and provide feedback on the experiment, they are more likely to try something new. Having tried it for a timeboxed period, the team should review its effectiveness at a retrospective to determine whether it should be continued as-is, modified to improve it, or dropped from use.
Finally, successfully adopted, tailored approaches can be institutionalized into the standard processes used for projects that share these characteristics. It is also recommended that guidelines from Section 5 be followed that describe adopting (or tailoring) new approaches.
X2.4 TAILORING RECOMMENDATIONS
Listed below are some good practices to consider before tailoring an approach.
X2.4.1 BEWARE OF TAKING THINGS AWAY
Many of the agile practices act as self-supporting pairs. For instance, colocation and frequent business conversations allow for lightweight requirements since gaps in understanding can be filled quickly. Likewise, XP's ruthless testing allows for courageous refactoring as one practice supports the other. Removing something without understanding or addressing its counterbalanced practice will likely create more problems than it solves.
X2.4.2 USE THE TAILORING GUIDELINES TABLE
Using Table X2-1, find the circumstances that match a given situation and consider recommendations for tailoring. Discuss any changes with those who will be impacted by the change and plan a short trial first, along with an honest follow-up review before committing to the change.
Table X2-1. Tailoring Guidelines
| Situation | Tailoring Recommendation |
| Very large project teams | Restructure large projects as multiple smaller projects. Try a technology trial project first and then an implementation project. |
| Consider more frequent releases of fewer features each, which allows for the creation of smaller project teams. | |
| Consider reducing the team down to its critical core members. Often too many people hinder a process, not help it. Reducing a team size can reduce churn as well as costs. | |
| Break large teams into multiple smaller teams and use program management to synchronize and coordinate. | |
| Use agile and lean program management to organize the larger effort. | |
| Consider a scaled agile or lean framework such as DA, SAFe®, or LeSS. Each offers some useful ideas, and each carries implementation risks and process weight/cost. | |
| Dispersed teams | Many projects have (some) dispersed team members. Tools like instant messaging, video conferencing, and electronic team boards help bridge many of the communication gaps. |
| When teams are likely to remain stable, set up face-to-face meetings as soon as possible to make future remote conversations more effective. People who have met face-to-face are more likely to enter unfiltered debate because of higher trust. | |
| When conducting meetings with remote participants where there is a loss of facial and body-language cues, consider round-robin check-ins to ensure participation and check consensus for decisions. | |
| Also, consider the use of iteration-based agile approaches. When team members are many time zones apart, consider using whole-project interactions less frequently, while encouraging more personal meetings (two or three people at a time) more frequently. | |
| Some safety critical products may require additional documentation and conformance checks beyond what agile processes suggest out-of-the-box | Agile approaches can still be used in these environments, but they need to have the appropriate additional layers of conformance review, documentation, and certification that is required by the domain. In that case, documentation could be part of what the team delivers along with finished features. Features may not be done until the documentation is completed. |
| Consider using a hybrid approach (multiple agile approaches) to get the benefits of improved collaboration and communication brought by agile with the added rigor required by the product environment. Aircraft flight system developers and drug companies use agile approaches coupled with their own additional processes to leverage the benefits and retain appropriate controls. | |
| Stable requirements and execution process | Is agile really needed? If uncertainty in requirements is low, low rates of change, or minimal execution risk, the full suite of agile approaches may not be needed. While any project benefits from increased collaboration and transparency; some of the iterative build and review cycles might be overkill. |
| If build/feedback cycles do not routinely uncover or refine requirements, consider extending their durations to minimize the cost impact of review time. | |
| If the project has high rates of change during design and development, but rolling it out to customers is a defined and repeatable process, hybrid approaches that use the appropriate life cycle model for each project phase may make more sense. | |
| Teams are in functional silos inside functional organizations | Agile is built on the idea of cross-functional teams. Consider asking people to create cross-functional teams themselves, without management involvement and see what happens. |
| If the compensation system is organized to recognize and reward functional areas, consider changing that first. People might not act in the interest of the product or the team until it affects their compensation in some way. | |
| Transparency can cause fear | Agile creates a culture of transparency: people show and share their work throughout development. This sharing of interim deliverables and being open and honest about successes, failures, and current state is transparency. Transparency requires courage. |
| Lead by example and demonstrate transparency in decision-making processes by using a status board or whiteboard. | |
| Many of the team members have little technical domain knowledge | Agile approaches encourage and make use of self-directing teams to make local decisions about work items, such as task sequencing and which approach to use when solving a problem. When the majority of team members are inexperienced, consensus-based approaches may lead to problems and rework. So, for these teams, additional help “assigning” and “directing” may be necessary until the team gains the necessary skills. In other words, do not just declare that agile will be used and let an inexperienced team try to figure everything out because they are empowered and self-directing. Consider building centers of competencies to help provide guidance and build domain knowledge. |
| Lack of executive buy-in | When executive buy-in is missing, teams will encounter a clash between the agile mindset and approaches and the more predictive mindset and approaches. |
| Find common ground, areas for improvement based on the organization's needs, and then use experiments and retrospectives to progress. | |
| Consider education/training for executives. Consider explaining agile in terms of lean thinking: short cycles, small batch sizes, frequent reviews, and retrospectives with small improvements. | |
| Agile terms and language do not fit the organizational culture | Modify the terms so people will understand and agree to the activities, if not the agile language. Be specific about what each term means. |
| For example, If the organization finds the word “game” unprofessional, don't use terms such as “planning game.” Instead, consider using the term “planning workshop.” |