 |
This section of the portal is for supporting the Disciplined Agile Value Stream Consultant Workshop (DAVSC), currently under development. Discussions on the pages here will take place on the Disciplined Agile LinkedIn group. |
A common situation in companies is that there is not a good intake process to make explicit what people should be working on. This article presents one of a few case studies that represent many of the situations companies find themselves in. Return to Playbooks provided for categories of challenges
Background
Before beginning we’ll provide a little background and terminology. Figure one represents part of the idealized value stream (DevOps, shared services, documentation, support and other after deployment groups are not shown.
Figure 2 shows our motivation in implementing the suggestions here. In companies without a good intake process the Implementation group spends most of their time doing rework or induced work.
Situation
Symptoms
- The company is working on way too many initiatives driven by too many groups.
- No one really knows how much is too much but we do know we’re over the limit.
- This is recognition that although the problem appears to be in Implementation, but it’s because they are being at the effect of Discovery asking them to do too much and having poorly developed requirements that are changing all the time.
- People initiating requirements tend to work in their own silos. This is both in terms of making the requests and on not seeing the impact these requests have on others
What’s Stopping You
Note, not all of these may be present. They are listed here as a basis.
- People are motivated to work in their own area
- There may be a process to follow, but it’s geared toward getting requirements, not for deciding which of what we have to do is more important. Prioritization may be being attempted, but prioritization is actually a failed practice. Everything is important. Everything adds value. We need to say which items are most important. We must sequence the work items to accomplish this.
- Because of the high work load levels and having a process that inherently won’t work people just go around the process and make demands on Implementation
- People on the Discovery side are operating for their own mandate. This is understandable given there’s no holistic view of things. We don’t have a way to see what’s important compared to other things.
- Implementation takes on the work – there’s no safety to say no, executives are pushing for the work, we’ve done this historically, in the past we threw money at it – but can’t do that any more.
What’s needed
Give good requirements to Implementation
Allow for Implementation to work at the right level of capacity
Hold interruptions to a minimum and only in exceptional, well-defined situations.
Agreements
Before discussing the specifics of actions we need to agree on intentions. These agreements set the stage for our actions. The following agreements are key for this situation.
A note on terminology: DA FLEX uses the terms: Business Increment and Business Increment Planning instead of Program Increment and Program Increment Planning. The term change is because:
- We want to focus on the release of value, not work being done
- The BI is not the same as the PI in that it is centered around Minimum Business Increments (MBIs) and the Intake Queue has a Definition of Ready (DoR).
#1. Agreements made between Discovery and Implementation
We will give you requirements of what to work on that are sufficiently complete in problem statement and scope. These may change for different types of work. The definition of complete will be mutually agreed upon by both Discovery and Implementation.
#2. Agreements made between all initiators of requests.
We agree to create a workflow to provide the documents specified in Agreement 1 and to abide by it. Any requests for which we don’t do this will automatically get sequenced at bottom of queue.
#3. Made between Implementation and Discovery
Implementation teams agree to work on items in the order in the intake queue. Note that things that don’t meet the Intake queue requirements are at the bottom. One role of the intake queue is that it forces Discovery to work together with Implementation instead of individual people in Discovery making isolated requests to Implementation.
#4. Made amongst all Implementation.
We agree to collaboratively work on the most important items in the Intake queue
#5. During the Business Increment Discovery agrees to:
- Limit changes to priority on the Intake Queue to only essential ones. Any work added because a PBIs importance has changed will incur a cost specified by Implementation. If it represents new work a corresponding amount of work will be removed from the BI.
- Limit changes to new work being added to the Business Increment after planning. Any work added because a PBIs importance has changed will incur a cost specified by Implementation. If it represents new work a corresponding amount of work will be removed from the BI.
- Limit requests of Implementation to do discovery work before the end of the working part of the BI. Any requests for new effort will result in planned work being dropped if the aggregate of these requests exceeds what was planned for.
The Baseline Playbook
There is no one size fits all. And even when we have a playbook for a particular scenario, a suggested approach should be just that – a suggestion. It creates a baseline for thinking – not a prescription to follow.
Actions to take
- We will agree on a “Definition of Ready” to indicate whether a request is ready to be worked on. An example DoR is given below.
- Requests will not get into a business increment unless it meets the DoR for the type of work – no exceptions.
- Requests for consideration to be in the next program increment would be stored in <toolOfChoice> as our source for Intake.
- A Discovery Workflow will be created to get requests ready to be worked on, inclusive of end-to-end customer experience, and operational impact on teams that enable the value being created (e.g. Service Design).
- Interruptions during the program increment will be controlled and measured so that overall workload within Implementation is maintained.
Getting Items Into the Business Increment
The Intake Queue
The intake queue holds all of the items that will be planned in the Business Increment. It typically does not hold maintenance items as the time to spend on them is typically allocated. However, it is not enough to just put an item on the intake queue to be done in the next Business Increment. It must meet the Definition of Ready or it will automatically be placed at the bottom of the queue.
Definition of Ready
For the definition of the Definition of Ready see Definition of Ready and Different Ways to Use It.
In this case study, any of the ways of using the definition of ready may be valid. When Discovery leaves a lot of work that they should do to be done by Implementation, it should be considered whether to put anything not meeting the DoR at the bottom of the intake queue.
The Discovery Workflow
The Discovery Workflow is a suggested method by which people in discovery get items on the Intake Queue. It is the method by which the items on the Intake Queue are made to satisfy the definition of ready (DoR).
A note about the Discovery Workflow and the Graduation Process
The Discovery Workflow can take advantage of what’s been done with the graduation process but note two things:
- The discovery workflow is just about getting items to meet the definition of ready – it therefore isn’t the entire graduation process
- The key is not following the Discovery Workflow, but having items meet the definition of ready (DoR) so that they will be ready to be worked on in the next business increment.
Changes During the Business Increment
Handling Date Changes During a Business Increment
When a date in which an MBI is needed is moved up, some corresponding amount of work must be moved down. See “Behaviors that need to change.” Implementation has the option of removing up to 20% additional work if this new requirement takes additional planning and/or results in a mismatch of capacity when changing from the current plan to the new.
Discovery adding new items in the middle of the Business Increment
New work added into the business increment adds overhead to the work being done.
Discovery asking for people in Implementation to help create items on the Intake Queue
Implementation will collaborate with Discovery to analyze new requirements but will not accept requests thrown to them without Discovery’s involvement.
Mantra: “Implementation collaborates with, not works for, Discovery.”
Discovery can set aside a certain percentage of Implementation capacity that Implementation has available for requests of this type. Implementation will plan with this overhead in mind.
FAQs
Q: How is this different from what we’ve done before?
A: In the following main ways:
- We are focusing on the Definition of Ready in the intake queue, not in how we get there (the Discovery Workflow/part of the graduation process
- We have the backing of leadership that we must actually do this work
- That we are not “following processes” here (which are somewhat doomed to begin with, but making agreements which we all will abide by that shifts the focus from our individual areas to our company as a whole
- We will have one repository for our enhancements and innovations
- That we will attend to greatly diminish the changes to scope, requirements and date in the business increment
- That we shift from our silos to a company wide perspective
Q: Is there administrative work being added?
A: Almost all of the additional work is in the doing by Discovery. There is a marginal amount of administrative overhead but it amounts to little more than checking off that work has been done and represent just a tiny fraction of the work involved. In any event, this “administrative” effort will greatly increase the collaboration needed to do this.
Playbook Template When Lack an Intake Process
This template is for the Missing Intake Process Playbook
This playbook describes the actions to take when there is no intake process. This template is sued to document the options provided in it.
Check if agreement made
___ #1. Agreements made between Discovery and Implementation
___ #2. Agreements made between all initiators of requests.
___ #3. Made between Implementation and Discovery
___ #4. Made amongst all Implementation.
During the Business Increment Discovery agrees to:
___ #5.a Limit changes to priority on the Intake Queue to only essential ones. Any work added because a PBIs importance has changed will incur a cost specified by Implementation. If it represents new work a corresponding amount of work will be removed from the BI.
___ #5.b Limit changes to new work being added to the Business Increment after planning. Any work added because a PBIs importance has changed will incur a cost specified by Implementation. If it represents new work a corresponding amount of work will be removed from the BI.
___ #5.c Limit requests of Implementation to do discovery work before the end of the working part of the BI. Any requests for new effort will result in planned work being dropped if the aggregate of these requests exceeds what was planned for.
The Discovery Workflow
______________________________________________________________
______________________________________________________________
______________________________________________________________
______________________________________________________________
Changes During the Business Increment
Handling Date Changes During a Business Increment
________________________________________________________
________________________________________________________
Discovery adding new items in the middle of the Business Increment
________________________________________________________
________________________________________________________
Discovery asking for people in Implementation to help create items on the Intake Queue
________________________________________________________
________________________________________________________