Process Flow Patterns

Following up on my “patterns for issue tracking” post, here is Deeper documentation of some of the Process Flow patterns. I will try to follow up from time to time with documentation of the patterns. Once the knowledge base is more or less complete I will probably consolidate it into an article/whitepaper/wiki format.

Pattern: Configuration Control Board
Aliases: Change Control Board, Configuration Management Board, CCB
Context: A development group is trying to control content/configuration of its product
Problem:
Conflicts between different stakeholders (PM, QA, DEV, etc.) and their motives can make the answer to “what is best” for the product version a complex one, and the group needs to provide the best business answer considering all aspects.
Forces:
• Every Change Request (CR) has a price – some sort of regression risk depending on scope and delicacy of the change. The risk is accompanied by the testing effort needed to verify/close the CR.
• Some CRs are required to meet release criteria.
• Change Requests (CRs) for Bug fixes potentially improve stability
• CRs for enhancement/features potentially increase user satisfaction or open new markets.
• Time to market tries to force fastest possible implementation of each CR.
• Developers want to implement CRs according to “good architecture practices”
Solution:
Classical CCB (Need to find the authoritative definition…)
But in general:
Define a board comprised of stakeholders for the product including engineering, business/user (PM), QA, management. Stakeholders should be knowledgeable and with enough authority in their domain. This is the CCB
CRs will be submitted to the CCB by engineering. They will be discussed by the CCB, in either periodical or ad-hoc meetings, and a decision will be made and communicated to the relevant parties.
Decisions take into consideration the pros and cons of each CR, the context of the product/version, and make a business decision.
Resulting Context:
• CRs cannot be committed/completed but need to be queued
• Once approved CRs should be completed/committed by either the original engineer or a RE (Release Engineer)
• Rejected CRs will be completed/committed for future versions or dropped altogether.
An issue tracking system enables streamlined CCB operation and tracking of its decisions.

Pattern - Distributed Configuration Control Board
Aliases - CCB Proxy
Context - A development group is trying to control content/configuration of its product, without slowing down or losing context too much
Problem - In classic CCB the latency between submitting an issue to CCB and its approval/rejection takes significant time (there is a limit to the feasible frequency of CCB meetings, even when willing to be ad-hoc).
This time the CR is not integrated, losing ContinuousIntegration time and conflicting with “Merge Early and Often”.
In addition the engineer gets farther and farther away from the context of the CR as he assumes other work.
In addition the time necessary for discussing all CRs in CCB meetings is expensive when considering the number of members and the depth required to make intelligent decisions.
Forces:
• Wish to minimize time between CR readiness and commit time:
o Meet other possibly conflicting CRs as soon as possible (Merge Early and Often)
o Deal with issues as closer to context as possible (minimize context switch cost)
o Raise engineers satisfaction of “completed” work. Minimize “friction”.
• Many issues are “no brainer” decisions that don’t require a full CCB
• Wish to minimize time spent on CCB meetings
• Wish to minimize mistaken judgment calls due to lack of the full picture or mature consideration.
Solution:
Train/Assign CCB Proxies which should be aware of the CCB criteria for decision and should be able to either reach a decision or know when to wait for full CCB.
These CCB Proxies should monitor the queue of CRs submitted to CCB and dispatch CRs according to the CCB criteria, or converse with the CR owner to get more information, or other stakeholders in case necessary.
CCB Proxy effectiveness should be reviewed periodically according to the following criteria:
• Adherence to CCB Criteria
• Results – How many regressions, whether CCB would have made a different decision
• Intimate review of random interesting decisions.

Variants:
• Dispatch the CR queue according to engineering domain – a proxy for each domain, usually a manager in that domain.
• Dispatch the CR queue using a peer system – a peer proxy for each domain, to avoid the situation where a manager approves his own group work. (sort of “peer review” system)
• PM is the CCB Proxy
• Lead QA stakeholder is the CCB Proxy
Resulting Context
• 80% of CRs should be dispatched/approved very quickly (decide on SLA). 20% will be according to classic CCB frequency.
• CCB Meetings will be shorter and more focused (to the relief of the attendees…), and potentially the frequency can be increased.
Related Patterns - CCB, Merge Early and Often (SCM)

Pattern: Heirarchical Triage for Incoming issues
Context: New issues (bugs/feature requests) are opened by interested stakeholders (QA, Customer Support, DEV, PM). Since resources are limited some business intelligence should be applied to decide which issues should be accepted into the work queue of which version (if any), and with what priority compared to other issues.
Problem: Cannot rely on engineering alone to come up with the business decision, OTOH waiting for PM or some sort of CCB committee introduces much latency/bureaucracy into the process
Forces:
• Wish to start working on high priority issues soon, to avoid working on lower priority issues while waiting for processing.
• Wish to have correct priorities and control the version contents (See CCB)
• Wish to minimize time in the decision queue.
Solution:
Priority decision should be assigned to the CCB process, using the same CCB Proxies described in “Distributed CCB” to dispatch the incoming issues queue.
Criteria for priority and version contents should again be decided and documented beforehand. They consist part of the “values” for decisions made by the proxies.
Issues which require more elaborate discussion shall be discussed in a periodical “Triage” meeting (can be in CCB meeting, or separate meeting)
Resulting Context:
• 80% of issues should be prioritized very quickly (decide on SLA). 20% will be according to “triage” meeting frequency.
• Minimum numbers of issues enter the work queue by mistake.
• Minimized feeling of bureaucracy among issue reporters and assignees.
Related Patterns: Distributed CCB, CCB

Pattern: UnderstandBeforeSchedule
Context: In classic issue tracking environments, issues are reported, and then scheduled for work (in a version). Some of the aspects of an issue include scope of change, estimated effort, impact on stability. This pattern deals with having sufficient input into the scheduling decision.
Problem: When scheduling is done without sufficient information regarding scop e/estimated effort/impact, time will be spent on handling them, only to understand later on that they cannot be committed to the version (mainly due to CCB criteria). This is a waste of resources, and a source for frustration among the staff.
Forces:
• Scheduling effectively requires considerable input, which might require actual investigation/analysis by an engineer/developer
• Investigation/Analysis by engineers/developers is usually part of the work done AFTER scheduling the issue for one of the versions.
• Engineers/Developers apply pressure to commit issues they already solved, even to the detriment of the project health. Part of human nature.
• Tracking issues which require analysis is difficult when they are all in the same “unscheduled/new” state/queue.
Solution:
Add an “investigating” state/queue to the workflow. Issues should be in this state when they are pending an investigation by their owner. Exit criteria from this state is to have the required input into the scheduling process.
New issues can go to this state when insufficient scheduling input is available. When the scheduling input is available (either when reported, due to analysis, etc.) the next step is to schedule. Who schedules and according to what flow is out of the context of this pattern.
“Investigation” work stops when scheduling input is available, unless the work necessary to solve the issue is another minimal step, in which the work can be done all the way up to “resolve” (commit depends on the codeline policy and whether CCB approval is required).
Resulting Context:
• Added “investigating” state/phase/queue in the issue workflow
• Use either custom fields or comments to track the relevant scheduling input, according to the level of formality/tracking required.
• Engineers/Developers are comfortable with providing the analysis/investigation data, without going all the way to resolve the issue, knowing that the aim of the process is to utilize their time effectively.
• Shortcuts can be made whenever investigation is redundant.

Improving flow means fewer bottlenecks, faster feedback, and less wasted capacity. Explore flow advisory or let’s talk.