Microsoft uses Tell Mode and Ask Mode to refer to different time periods after the Feature Complete milestone but prior to a release.
During Tell Mode the Development team tells the rest of the team which issues are actively being worked on (resolved). In other words, Development is primarily driving the stabilization process based on what they think should be fixed -- as determined by priority, severity, complexity (i.e. risk), and effort required. This works for a while, but at some point you have to reign in Development in order to ship, er, release.
Thus we transition into Ask Mode whereby Development must ask permission before resolving any issues. It is okay to investigate issues, but no code changes can be made to address an issue until approval by the “War Team” (er, Triage Team) is granted.
During Ask Mode we look first at the scenario that is being fixed (i.e. the motivation for fixing it), we look at why the bug happens (regression, test hole, coding error, etc.), and then we investigate the necessary source code changes and associated risk. Every potential change is heavily scrutinized to evaluate whether it is worth the risk to fix it, because at this point in the schedule, every change -- even one that seems trivial -- has the potential to destabilize the solution and slip the schedule.
While the overall process of the daily triage meetings stays the same as we transition from Tell Mode to Ask Mode, there is a noticeable shift in focus.
During Tell Mode, work items are often immediately triaged as Approved, or work items triaged as Investigate are often just fixed without further review. This is no longer the case once we enter Ask Mode.
In Ask Mode every work item is first assigned a triage of Investigate. The person responsible for investigating the item must thoroughly document details about the item -- in the Description field of the work item, unless a more formal DCR (Design Change Request) is deemed necessary.
The investigator (typically a member of the Development team) documents the:
- Motivation -- "Why are we making this change?"
- Proposal -- "How should we resolve the issue?"
- Risks -- "What is the worst case scenario if we make this change?"
- Solution -- "What specifically needs to change?"
- Teams Impacted -- "How much work is required by Development, Test, Release Management, and (potentially) Product Management teams?" (note that the estimates need to come from the respective team members -- the investigator should not "guess")
Note that both Solution and Teams Impacted are not needed, one or the other is fine. If the necessary change (and associated risk) is very small -- such as a configuration change -- then just documenting the Solution should suffice. The goal is not to overburden ourselves with process -- but we also need to ensure that no change is made unless it has been thoroughly evaluated. If the change (or risk) is substantial, then document the impact on each of the various teams.
After documenting these details, the investigator then changes the Triage field to Recommend Approve (if the value in making the change is greater than the associated risk) or Recommend Reject (if the risk of making the change outweighs the value). The Triage Team then reviews the detailed information about the work item and either changes the Triage field to Approved or Not Approved (i.e. "punt to v.Next").
Note that the Triage Team can certainly “overrule” the investigator, which is why it is critical that no work be done on actually resolving the work item until approval is received from the Triage Team (i.e. the Triage field is set to Approved). Also note that, unless you are a member of the Triage Team – and even then, only during a formal triage meeting – you should not change the Triage field to anything except Recommend Approve or Recommend Reject. Otherwise, you should fully expect a thorough hazing from virtually all team members.
I have included slightly "scrubbed" versions of a couple of the bugs below, in case you are interested in seeing examples.
Bug 1505 - There are no results displayed in WCOSLSCD if a search is performed on few publication types
Repro steps:
- Select the publication type as “Certificate of Analysis” or “Material Safety Data Sheet” from the drop down and click on search
- There are no results displayed for these publication types even though there are lot of documents under these publication types in TEST
Motivation:
LiteratureResults.aspx currently excludes the following content types (since the number of publications of these types is disproportionately higher than other publication types and also because these publication types have separate search forms):
- Chromatogram
- Certificate of Analysis
- Material Safety Data Sheet
However, the current user experience is not desirable since the search form allows users to narrow their search results to just Certificate of Analysis or MSDS publications (which will never return results).
Proposal:
Remove Certificate of Analysis and MSDS from the search criteria. This would allow users to search specifically by these publication types and would also include these results by default.
Risk:
Of the roughly 33,000 publications in the EPI Warehouse, there are approximately 1,300 Certificate of Analysis and 7,100 MSDS publications.
Since the new SharePoint search includes full-text indexing as well as metadata, including these two publication types by default may dramatically change the search results.
Teams Impacted
Development
Modify LiteratureResults.asp to no longer exclude Certificate of Analysis and MSDS publications by default (0.5 hours).
Release Management
Merge updated ASP file into legacy VSS and deploy to WCOSLSCD and CAGCHEM (0.5 hours)
Test
Retest ESI Library searches through legacy General Site (2 hours)
Product Management
Review new Library search results on legacy General Site to determine if the large number of Certificate of Analysis and MSDS publications has a negative impact on search results. (2 hours)