Agile Practices, purpose and domain

	A	B	C	D	E	F	G	H	I	K	L	M
1			Practices purpose. A way to look at a practice purpose: when the team is already achieving that purpose than there's no needed to explicitly enforce the practice
2
3						The execution of the practice:				The practice will move a problem:
4	Method	Practice	Type	Frequency	Main Purpose	is based on heuristics more then rules?	deal with uncertainty about what is the right decision ?	require to build consensus?	is in the Domain	anecdotes / the problem	from the Domain:	to the Domain:

5	XP	Sit Together	team	few times per day - continuously	Enable frequent effective natural communication between team members. Support development of team fundamental dynamics.	no	no	yes	- the initial adoption can be socially complex - simple while the practice is in place and no tweaking are required
6		Whole Team	team	continuously	Enable development of team structure and integrity required to a team to act as a team	no	no	yes	- the initial adoption can be socially complex for the team - the initial adoption can be socially complex to chaotic for the organization - simple while the practice is in place and no tweaking are required
7		Informative Workspace
8		Energized Work
9		Team Continuity
10		Shrinking Team
11		Weekly Cycle
12		Quarterly Cycle
13		Real Customer Involvement
14		Stories
15		Negotiated Scope Contract
16		Pay-Per-Use
17		Slack
18		Root-Cause Analysis
19		Single Code Base			Eliminate the waste caused by multiple code streams avoiding code base duplications and reducing the life of code branches to less then few hours	no	yes	yes	- the initial adoption can be socially complex to chaotic - simple while the practice is in place and no tweaking are required
20		Shared code			Permit anyone in the team to improve any part of the system. Requiere CI and shared team responsibility as prerequisite	no	no	yes	- the initial adoption can be socially complex to chaotic - simple while the practice is in place and no tweaking are required
21		Ten-Minute Build	coding	10min - 1h	Identify early a broken build and a red-test making more evident the link between the problem and the code change that caused it. This greatly accelerate the diagnostic and the fix of the problem	no	no	no	- mainly complicated - simple while the practice is in place and no tweaking are required - occasionally complex/chaotic when code-base require major changes to keep the build/tests under 10 minute, and the changes have impact on other team members work	coding problem: ensure that the code-base is in a good state	complicated	simple
22		Continuous Integration	coding	30min - 1h	Identify early conflicting changes that broke a build or cause a red-test reducing the effort required to fix the problem	no	no	yes	socially complex and technically complicated	coding problem: integrating interfering code changes from many team members	chaotic	complex
23		Test-First progr. TDD	coding	5min - 1day	Drive the design of the code at the method/class/namespace level and cover the code with unit test to enable safe refactoring and code evolution	no	yes	yes	complex
24		Test-First progr. A-TDD	coding	1h - 1week	Document the expected behavior of the application and automate the verification. Drive the design of the system at the namespace/su-bsystem/system/external-systems level.	no	sometime	yes	complex/complicated
25		Code and Tests
26		Incremental Design
27		Pair-Programming	coding	30min rotation	Keep quality high and spot mistakes early. Combine skills and knowledge and share information and clarity misunderstanding with team members	yes	sometime	yes	complex
28		Incremental Deployment
29		Daily Deployment
30	Scrum	Sprint	team	every sprint	Set the external act-inspect-adapt feedback loop frequency that drive the validation, discovery and adaptation of the team work and of the project goal. Define the time-box available to produce an increment of the product. Provide a fixed rhythm, an heartbeat that helps to synchronize all the other activities of the team. Support prioritization.	yes	yes	yes	complex
31		Planning Meeting	project	every sprint	Identify and agree on the next most valuable increment of the project to be implemented. Ensure that it can be successfully implemented by the whole team during the next Sprint and can be accepted, released and used by the users	yes	yes	yes	complex
32		Sprint Review	project	every sprint	Coordination event for team and stakeholders: share all the aspects of the progress achieved with the last sprint, inspect the current project implementation, and adapt the Product Backlog accordingly	yes	no	sometime	complicated/complex
33		Sprint Retrospective	team	every sprint	Access the overall effectiveness of all the aspects of the team work in relation to the project goal and the team members needs. Spot changes in the surrounding environment/context that could affect the project goal and react/adapt to them. Identify and sustain actual improvements, identify and plan to remove major impediments during the next sprint	yes	yes	yes	complex
34		Daily Scrum	team	daily	Daily coordination event for the whole team: share info learned and discovered and the current progress; share any kind of obstacle to the achievement of sprint goal and plan to remove them; Identify and organize the most useful activities for the day	yes	sometime	sometime	complicated/complex
35		Product Backlog
36		Sprint Backlog
37		Definition of Done
38		Product Owner
39		ScrumMaster
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100