- Visual Studio and Process Enactment
- Process Templates
- Process Cycles and TFS
- Inspect and Adapt
- Task Boards
- Kanban
- Fit the Process to the Project
- Summary
This chapter is from the book
This chapter is from the book
This chapter is from the book
Fit the Process to the Project
Based on your project context and your retrospectives, you may choose to customize your process template. Ideally, this is a team decision, but certain stakeholders may have special influence. Even then, every team member should understand the rationale of the choice and the value of any practice that the process prescribes. If the value cannot be identified, it is unlikely that it can be realized. Sometimes the purpose might not be intuitive (certain legal requirements for example), but if understood can still be achieved.
As Barry Boehm and Richard Turner have described, it is best to start small:
- Build Your Method Up, Don't Tailor It Down
- Plan-driven methods have had a tradition of developing all-inclusive methods that can be tailored down to fit a particular situation. Experts can do this, but nonexperts tend to play it safe and use the whole thing, often at considerable unnecessary expense. Agilists offer a better approach of starting with relatively minimal sets of practices and only adding extras where they can be clearly justified by cost-benefit.13
Fortunately, TFS assumes that a team will "stretch the process to fit"—that is, take a small core of values and practices and add more as necessary (see Figure 2-11).
)
Figure 2-11 The Process Template Editor (in the TFS Power Tools on the VS Gallery) enables you to customize work item types, form design, and workflows.
One of the tenets of the Agile Consensus is to keep overhead to a minimum. Extra process is waste unless it has a clear purpose whose return justifies the cost. Three common factors might lead to more steps or done criteria in the process than others: geographic distribution; tacit knowledge or required documentation; and governance, risk management, and compliance.
Geographic Distribution
Most organizations are now geographically distributed. Individual Scrum teams of seven are best collocated, but multiple Scrum teams across multiple locations often need to coordinate work. For example, on VS, we are running scrums of scrums and coordinating sprint reviews and planning across Redmond, Raleigh, and Hyderabad, and several smaller sites, a spread of 12 time zones. In addition to TFS with large screens, we use Microsoft Lync for the video and screen sharing, and we record meetings and sprint review demos so that not everyone needs to be awake at weird hours to see others' work.
Tacit Knowledge or Required Documentation
When you have a geographically distributed team, it is harder to have spontaneous conversations than when you're all in one place, although instant messaging and video chat help a lot. When you're spread out, you cannot rely just on tacit knowledge. You can also use internal documentation to record contract, consensus, architecture, maintainability, or approval for future audit. Whatever the purpose, write the documentation for its audience and to its purpose and then stop writing. Once the documentation serves its purpose, more effort on it is waste. Wherever possible, use TFS work items as the official record so that there is a "single source of truth." Third-party products such as Ekobit TeamCompanion, shown in Chapter 4, can help by converting email into TFS work items for a visiable and auditable record.
Governance, Risk Management, and Compliance
Governance, risk management, and compliance (GRC) are closely related terms that are usually considered together since the passage of the Sarbanes-Oxley Act of 2002 (SOX) in the United States. For public and otherwise regulated companies, GRC policies specify how management maintains its accountability for IT. GRC policies may require more formality in documentation or in the fields and states of TFS work items than a team would otherwise capture.
One Project at a Time Versus Many Projects at Once
One of the most valuable planning actions is to ensure that your team members can focus on the project at hand without other commitments that drain their time and attention. Gerald Weinberg once proposed a rule of thumb to compute the waste caused by project switching, shown in Table 2-1.14
Table 2-1. Waste Caused by Project Switching
|
Number of Simultaneous Projects |
Percent of Working Time Available per Project |
Loss to Context Switching |
|
1 |
100% |
0% |
|
2 |
40% |
20% |
|
3 |
20% |
40% |
|
4 |
10% |
60% |
|
5 |
5% |
75% |
That was 20 years ago, without suitable tooling. In many organizations today, it is a fact of life that individuals have to work on multiple projects, and VS is much easier to handle now than it was when Weinberg wrote. In Chapter 10, I discuss how VS is continuing to help you stay in the groove despite context switching, but it is still a cognitive challenge.