diff --git a/.linkinator.config.json b/.linkinator.config.json index df7bcf5..ca770db 100644 --- a/.linkinator.config.json +++ b/.linkinator.config.json @@ -7,5 +7,5 @@ "retry": true, "retryErrors": true, "retryErrorsCount": 3, - "skip": "^(https://.*github.com)" + "skip": "^(https://.*github.com),(/tags/)" } diff --git a/content/en/docs/delivery-system-improvement-journey.md b/content/en/docs/delivery-system-improvement-journey.md index 2938deb..950051d 100644 --- a/content/en/docs/delivery-system-improvement-journey.md +++ b/content/en/docs/delivery-system-improvement-journey.md @@ -46,7 +46,7 @@ created the defect and a multi-team effort to improve the development process to is difficult with this architecture. The journey to CD begins with each team executing [continuous -integration](https://minimumcd.org/minimumcd/#continuous-integration) on a team branch and those branches are +integration](/docs/glossary/#continuous-integration) on a team branch and those branches are integrated automatically into a master CI flow daily. [![Multi-team Branching](/images/multi-team-branching.png)](/images/multi-team-branching.png) @@ -98,10 +98,10 @@ quality with less overhead. **Team Structure**: Product teams focused on further de-coupling sub-systems -**Development Process**: [Continuous integration](/testing/glossary#continuous-integration). Small, tested changes are applied to the trunk as soon as complete on each product team. In addition, a larger CI pipeline is required to frequently run larger tests on the +**Development Process**: [Continuous integration](/docs/glossary#continuous-integration). Small, tested changes are applied to the trunk as soon as complete on each product team. In addition, a larger CI pipeline is required to frequently run larger tests on the integrated system, at least once per day. -**Branching**: Because [CI](/testing/glossary#continuous-integration) requires frequent updates to the trunk, [Trunk-Based](https://trunkbaseddevelopment.com) +**Branching**: Because [CI](/docs/glossary#continuous-integration) requires frequent updates to the trunk, [Trunk-Based](https://trunkbaseddevelopment.com) Development](https://trunkbaseddevelopment.com) is used for CI. **[Developer Driven Testing](https://medium.com/@LaSoft/developer-driven-testing-991ca1dab63a)**: The team is responsible for @@ -140,9 +140,9 @@ tests. **Team Structure**: Product teams maintain independent components with well-defined APIs. -**Development Process**: [Continuous integration](/testing/glossary#continuous-integration). Small, tested changes are applied to the trunk as soon as complete on each product team. +**Development Process**: [Continuous integration](/docs/glossary#continuous-integration). Small, tested changes are applied to the trunk as soon as complete on each product team. -**Branching**: Because [CI](/testing/glossary#continuous-integration) requires frequent updates to the trunk, [Trunk-Based](https://trunkbaseddevelopment.com) +**Branching**: Because [CI](/docs/glossary#continuous-integration) requires frequent updates to the trunk, [Trunk-Based](https://trunkbaseddevelopment.com) Development](https://trunkbaseddevelopment.com) is used for CI. **[Developer Driven Testing](https://medium.com/@LaSoft/developer-driven-testing-991ca1dab63a)**: The team is responsible for diff --git a/content/en/docs/devops-learning-path.md b/content/en/docs/devops-learning-path.md index 762c58a..c60c2e3 100644 --- a/content/en/docs/devops-learning-path.md +++ b/content/en/docs/devops-learning-path.md @@ -20,7 +20,7 @@ discussion that informs acceptance test driven development. - [Behavior-Driven Development with Cucumber: Better Collaboration for Better Software](https://www.amazon.com/Behavior-Driven-Development-Cucumber-Specification-Example/dp/0321772636) by Richard Lawrence, Paul Rayner -## Continuous-Integration +## Continuous Integration Continuous integration is a requirement for CD. It requires very frequent integration of non-breaking code. diff --git a/content/en/docs/glossary.md b/content/en/docs/glossary.md index 1e08cc6..b86700e 100644 --- a/content/en/docs/glossary.md +++ b/content/en/docs/glossary.md @@ -1,16 +1,13 @@ --- title: Glossary weight: 1 - -tags: - - glossary --- - [Continuous Delivery](#continuous-delivery) - [Continuous Deployment](#continuous-deployment) - [Continuous Integration](#continuous-integration) -- [Dependency (Hard)](#dependency-hard) -- [Dependency (Soft)](#dependency-soft) +- [Hard Dependency](#hard-dependency) +- [Soft Dependency](#soft-dependency) - [Story Points](#story-points) - [Toil](#toil) - [Unplanned Work](#unplanned-work) @@ -27,9 +24,6 @@ Delivering the latest changes to production **as they occur**. ## Continuous Integration -A development process where each developer integrates tested, -changes to trunk very frequently or at least once per day. Trunk is kept ready to deploy at all times. - > Continuous integration requires that every time somebody commits any change, the entire application is built and a comprehensive > set of automated tests is run against it. Crucially, if the build or test process fails, the development team stops whatever they > are doing and fixes the problem immediately. The goal of continuous integration is that the software is in a working state all the @@ -40,15 +34,17 @@ changes to trunk very frequently or at least once per day. Trunk is kept ready t > project is to fix any change that breaks the application. If people don't adopt the discipline necessary for it to work, your > attempts at continuous integration will not lead to the improvement in quality that you hope for. -Excerpt From: Jez Humble & David Farley. "Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment -Automation." +-- "Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment +Automation." - Jez Humble & David Farley + +You can find recommended [practices for CI at MimimumCD.org](https://minimumcd.org/minimumcd/ci/) -## Dependency (Hard) +## Hard Dependency A hard dependency is something that must be in place before a feature is delivered. In most cases, a hard dependency can be converted to a soft dependency with feature flags. -## Dependency (Soft) +## Soft Dependency A soft dependency is something that must be in place before a feature can be fully functional, but does not block the delivery of code. @@ -57,11 +53,11 @@ delivery of code. A measure of the relative complexity of delivering a story. Historically, 1 story point was 1 "ideal day". An ideal day is a day where there are no distractions, the code is flowing, and we aren't waiting on anything. No -such day actually exists. ;) +such day exists. :wink: -Story points should only be used for planned work. Unplanned work or [spikes](/docs/work-decomposition/spikes) should not be -story pointed after the fact. Doing so artificially inflates the average capacity of the team and results in teams -over-committing to delivery. +There are many common story point dysfunctions: pointing defects, unplanned work, and [spikes](/docs/work-decomposition/spikes) are some of the more +common. Adjusting points after work is done is another common mistake. The need for story points is a good indication +that we do not understand the work. If we have [decomposed the work](/docs/work-decomposition/behavior-driven-development) correctly, everything should be 1 point. ## Toil diff --git a/content/en/docs/workflow-management/_index.md b/content/en/docs/workflow-management/_index.md index 9fbc49a..1fa7b8a 100644 --- a/content/en/docs/workflow-management/_index.md +++ b/content/en/docs/workflow-management/_index.md @@ -1,8 +1,67 @@ --- -title: "Team Workflow" -linkTitle: "Team Workflow" - weight: 3 -description: > - Improving the flow of work on the team. +title: Team Workflow +tags: + - workflow management +--- + +Working together as a team is how we move things from "In Progress" to "Done", as rapidly as possible in value sequence. It's important for minimizing WIP that the team looks at the backlog as the team's work and does not pre-assign work to individuals. + +## Make Work Visible + +To create and maintain the flow of delivery, we need the following: + +- [Definition of Done](/docs/workflow-management/definition-of-done) +- [A way to visualize the workflow](/docs/workflow-management/visualizing-workflow), virtual or physical, with a + prioritized backlog that has not been refined too far in the future. + +--- + +### Plan Work + +Unplanned work is _anything_ coming into the backlog that has not been committed +to, or prioritized. This can include feature requests, support tickets, etc. + +Common struggles teams face with unplanned work can be: + +- [Work that has not been prioritized](/docs/workflow-management/unplanned-work) +- [Work that has not been decomposed](/docs/work-decomposition/work-breakdown) +- [Work that is unplanned](/docs/workflow-management/unplanned-work) + +--- + +### Do Work + +Completed work meets the [Definition of Ready](/docs/work-decomposition/definition-of-ready) +when work begins, the [Definition of Done](/docs/workflow-management/definition-of-done) when work +is delivered, and can be completed in less than two days. + +Process smells identified for completing work include: + +- Context switching +- Ineffective demos that prevent early feedback +- Multiple teams own pieces of the process (Build, Test, Deploy, etc.) +- [Status and visibility of work is unclear](/docs/workflow-management/visualizing-workflow) +- Siloed work on the team + +--- + +### Improve Work + +In order to plan and complete work effectively, there must be [an improvement +process](/docs/delivery-system-improvement-journey#3-continuous-improvement) in place. The improvement process is centered around feedback loops. + +Challenges associated with the improvement process: + +- Infrequent or nonexistent demos +- [Infrequent or unactionable retrospectives](/docs/workflow-management/retrospective) + --- + +### Measuring Your Workflow + +A good measure to implement in your team's workflow is [WIP](/docs/workflow-management/limiting-wip). +Limiting work in progress can help reduce constraints in your workflow. + +[Development cycle time](/metrics/development-cycle-time) is a key +measure of success when trying to optimize and automate your team's workflow. diff --git a/content/en/docs/workflow-management/branching.md b/content/en/docs/workflow-management/branching.md index 7a37e52..88ea923 100644 --- a/content/en/docs/workflow-management/branching.md +++ b/content/en/docs/workflow-management/branching.md @@ -1,50 +1,56 @@ --- -title: Source Branching - +title: Source Management weight: 1 +tags: + - Workflow + - Testing + - Feedback --- -> _Trunk-based development, is a requirement for Continuous Integration._ - -## Recommended Practices +## Use Trunk Based Development -- All changes begin with a branch from trunk and integrate back to the trunk. - - Branches should live no longer than 24 hours. The smaller the PR, the easier it is to identify issues. The smaller the change, the less risk associated with that change. - - Pull requests reviewed by a second party are a compliance requirement. -- Trunk can always be built and deployed without breaking production. - - When needed, use techniques like the Branch by Abstraction pattern or feature flags to ensure backwards compatibility. -- All changes to trunk include _all_ appropriate automated tests. +- All branches originate from the trunk +- All branches merge into the trunk +- Branches, if used, are very short-lived + - The smaller the PR, the easier it is to identify issues. The smaller the change, the less risk associated with that change. +- The trunk can always be built and deployed without breaking production. + - When needed, use techniques such as [Branch by Abstraction](https://www.branchbyabstraction.com/) or feature flags to ensure backward compatibility. +- The change includes __all__ appropriate automated tests to validate that the change is deliverable. - [Unit tests](/testing/unit) - [Functional test](/testing/functional) - [Contract tests](/testing/contract) - etc. -- Branching vs. Forking: It is important that the right process be use for the right reason. Branches are the primary flow for CI + +## Branching vs. Forking + +Use the right pattern for the right reason. Branches are the primary flow for CI and are critical for allowing the team to have visibility to work in progress that the team is responsible for completing. Forks are how proposed, unplanned changes are made from outside the team to ensure quality control and to reduce confusion from unexpected branches. - - Forks should be used for: - - Contribution from a contributor outside the team to ensure proper quality controls are followed. - - Contribution that may be abandoned and that lost work will not impact team goals. - - Branches should be for: - - All planned work done inside the team to prevent lost work due to illness or emergency. + +- Use forks for: + - Contribution from a contributor outside the team to ensure proper quality controls are followed and to prevent + cluttering up the team's repository with external contributions that may be abandoned. +- Use branches for: + - All internal work to keep that work visible to the team. ### Tips - [Story Slicing](/docs/work-decomposition/story-slicing) helps break development work into more easily consumable, testable chunks. -- You don't have to wait to be story/feature complete as long as you have tested - and won't break production. -- Pull requests should be small and should be prioritized over starting new development. +- You don't have to wait for a story/feature to be complete as long as you have tested + that won't break production. +- Pull requests should be small and should be prioritized over starting any new development. ### Common Issues -Trunk based continuous integration often takes workflow adjustments on the team. +Trunk-based development and continuous integration often take workflow adjustments on the team. The main reasons teams struggle with CI are: - [Test architecture](/testing) -- [Work that is too big and / or lacks proper refinement](/docs/work-decomposition/work-breakdown) +- [Work that is too big and/or lacks proper refinement](/docs/work-decomposition/work-breakdown) - Issues with [source code ownership](/docs/workflow-management/source-ownership) (one repo owned by more than one team) -- [Workflow management](/docs/workflow-management/workflow-process) within the team +- [Workflow management](/docs/workflow-management/) within the team --- @@ -54,22 +60,6 @@ The main reasons teams struggle with CI are: - [Branching by Abstraction](https://www.branchbyabstraction.com/). - [Feature Flags/Toggles](https://martinfowler.com/articles/feature-toggles.html). ---- - -## Value - -As a team, the use of trunk-based development enhances our ability to -deliver small, value adding, functional enhancements to trunk while -also decreasing the time it takes to get feedback on our changes. - -## Acceptance Criteria - -- All Development begins with branching from trunk. -- The artifact resulting from changes to trunk is running in production. -- Branches live an average of less than 24 hours. -- Team members hold each other accountable to the size and frequency of integrations. -- Repositories only have short-lived branches and trunk. - ## FAQ - [Pre-requisites for TBD](https://trunkbaseddevelopment.com/deciding-factors/) diff --git a/content/en/docs/workflow-management/code-review.md b/content/en/docs/workflow-management/code-review.md index ced9c98..9b0d5c6 100644 --- a/content/en/docs/workflow-management/code-review.md +++ b/content/en/docs/workflow-management/code-review.md @@ -1,15 +1,11 @@ --- title: Code Review - weight: 1 +tags: + - Testing + - Teamwork --- -As Wikipedia puts it, "Code review is systematic examination of computer -source -code. It is intended to find and fix mistakes overlooked in the initial -development phase, improving both the overall quality of software and the -developers' skills." - ## Recommended Practices - Small changes allow for faster code review and enhance the feedback loops. @@ -19,11 +15,12 @@ developers' skills." ## Tips -- Automated Code Review processes like linting and static code analysis. -- Code review that there are tests that meet the acceptance criteria agreed upon by +- Automate coding standards instead of reviewing for them. +- Focus the review on the tests and code readability. The tests should meet the acceptance criteria agreed upon by the team. -- Keep pull requests small. Look in to [Work Decomposition](/docs/work-decomposition/work-breakdown) +- Keep pull requests small. Look into [Work Decomposition](/docs/work-decomposition/work-breakdown) for guidance. +- Use synchronous code review to remove communication delays. - As the person being reviewed, remember the 10 Commandments of Code Review - Thou shalt not take it personally - Thou shalt not marry thy code @@ -40,19 +37,6 @@ developers' skills." ## References -- [The 10 commandments of navigating code reviews](https://techbeacon.com/app-dev-testing/10-commandments-navigating-code-reviews) - -## Value - -- Finds issues before deployment, saving time and money. -- Increased [Quality](/metrics/quality). -- Decreased [Change Failure Rate](/metrics/change-fail-rate). - -## Acceptance Criteria - -- Automated checks for standards and complexity. -- Code is reviewed for testing and clarity. -- Pull requests are small and last no more than a day. -- CI tests run upon opening and modifying pull requests. +- [The 10 Commandments of Navigating Code Reviews](https://techbeacon.com/app-dev-testing/10-commandments-navigating-code-reviews) --- diff --git a/content/en/docs/workflow-management/definition-of-done.md b/content/en/docs/workflow-management/definition-of-done.md index 0800c12..313005f 100644 --- a/content/en/docs/workflow-management/definition-of-done.md +++ b/content/en/docs/workflow-management/definition-of-done.md @@ -1,16 +1,15 @@ --- title: Definition of Done - tags: - - teamwork - - workflow management + - Teamwork + - Workflow - Work Decomposition --- -> Is it DONE, is it DONE DONE, or is it DONE DONE DONE? +> Is it __DONE__, __DONE DONE__, or is it __DONE DONE DONE__? All teams need a Definition of Done. The Definition of Done is an agreement made between the team -that a unit of work isn't actually complete without meeting certain conditions. +that a unit of work isn't complete without meeting certain conditions. ## Recommended Practices diff --git a/content/en/docs/workflow-management/feedback-loops.md b/content/en/docs/workflow-management/feedback-loops.md deleted file mode 100644 index 923ed3e..0000000 --- a/content/en/docs/workflow-management/feedback-loops.md +++ /dev/null @@ -1,60 +0,0 @@ ---- -title: Feedback Loops - -tags: - - workflow management ---- - -The most important part of the workflow process are feedback loops, and how they affect -the speed and quality of value delivery. - -The ultimate goal is to deliver quality software to our customers. Instead of speculating -how an end-user might consume your teams' product, feedback loops improve your existing -workflow so that you may meet your customer's needs rapidly and with less waste. - ---- - -### Examples of Critical Feedback Loops - -Feedback loops are as follows: -You produce something, measure information on that production, and use that information to improve. - -- How well does the team understand the requirements? - - Teams need to work with leadership to flush out requirements. How well those requirements - are understood, can be shown by how often developers are requesting additional information, or how often - the team is committing code. - -- How fast can the team detect defects? - - Defects are weaknesses in the system. The systematic approach of detecting - where defects are occurring, and how far downstream they are, directly affects - a team's Mean Time to Detect. - -- How effective are our tests? - - [Testing](/testing) is one of the most effective feedback loops a team can have in place. - Automated tests for example, provide feedback about your system in seconds. - -- How well does what we're producing, match the users' actual needs? - - Understanding if we're meeting the needs of the consumer is critical feedback. - - How fast can we determine that the customer is using the feature, and is happy with it? - The longer the duration between the time we've started work, to the time we find out - information, the more expensive it is. - ---- - -#### Tips - -- Use value stream mapping to uncover feedback loops, not just bottlenecks between specific steps. -- Focus on feedback loops that involve human communication, not just system alerts. -- Not all feedback loops are positive. Amplify feedback loops that promote positive change. - ---- - -#### Value - -As a development team, we want to identify and shorten our feedback loops, so that we -can analyze and optimize our workflow processes. diff --git a/content/en/docs/workflow-management/limiting-wip.md b/content/en/docs/workflow-management/limiting-wip.md index 35a513b..d414b4f 100644 --- a/content/en/docs/workflow-management/limiting-wip.md +++ b/content/en/docs/workflow-management/limiting-wip.md @@ -1,26 +1,23 @@ --- title: Work in Progress - tags: - - workflow management - - teamwork + - Teamwork + - Workflow + - Work Decomposition --- ## Why Limit WIP? -Work in Progress is defined as work that has started but is not yet finished. Limiting WIP helps teams reduce context switching, find workflow issues, and keeps teams focused on collaboration and finishing work. +Work in Progress is defined as work that has started but is not yet finished. Limiting WIP helps teams reduce context switching, find workflow issues, and keep teams focused on collaboration and finishing work. --- ### How do we limit WIP? -Limiting Work in Progress is an experiment. Start with one lane on your board. - -Set your WIP limit to n+2("n" being the number of people contributing to that lane) - -Continue setting WIP lower. - -Once the WIP limit is reached, no more cards can enter that lane until one exits. +- Start with one lane on your board. +- Set your WIP limit to N+2 ("N" being the number of people contributing to that lane) +- Continue setting WIP lower. +- Once the WIP limit is reached, no more cards can enter that lane until one exits. --- @@ -77,20 +74,6 @@ Visually distinguish important information. --- -## Value - -As a team, we want to limit our WIP, so that we may deliver the most valuable -thing first. - ---- - -## Acceptance Criteria - -- Set a WIP limit within reason and follow it shamelessly. -- Work on one thing at a time. - ---- - ## References [Making Work Visible](https://itrevolution.com/book/making-work-visible/) - Dominica DeGrandis diff --git a/content/en/docs/workflow-management/retrospective.md b/content/en/docs/workflow-management/retrospective.md index f79517a..89d8ffe 100644 --- a/content/en/docs/workflow-management/retrospective.md +++ b/content/en/docs/workflow-management/retrospective.md @@ -2,7 +2,8 @@ title: Retrospectives tags: - - teamwork + - Teamwork + - Improvement --- **Retrospectives are critical** for teams that are serious about continuous diff --git a/content/en/docs/workflow-management/source-ownership.md b/content/en/docs/workflow-management/source-ownership.md index 9e1cd0f..a2c7912 100644 --- a/content/en/docs/workflow-management/source-ownership.md +++ b/content/en/docs/workflow-management/source-ownership.md @@ -1,35 +1,29 @@ --- title: Source Ownership - - weight: 1 +tags: + - Teamwork + - Quality + - Ownership --- -**_Delivery and quality is being significantly impacted by teams sharing -ownership of the source code and adding process overhead to make sure everyone knows -what's happening in the code._** +**_Delivery and quality are significantly impacted by teams sharing +ownership of the source code. This adds process overhead to ensure everyone knows +what's happening in the code and dilutes quality responsibility._** ## Recommended Practices -- Utilize automated pipelines to help validate that the product remains releasable before and after any code is merged to trunk. +- Utilize automated pipelines to help validate that the product remains releasable before and after any code is merged to the trunk. - Limit ownership of a repository to a single "Two Pizza Team" that decides what code to merge. -- Give all developers on the team access to merge code to trunk. Give read access to everyone else. +- Give all developers on the team access to merge code to the trunk. Give read access to everyone else. - Use an innersourcing policy so that people outside of the team know how to contribute to your product. ## Tips - Teams looking to create an [InnerSourcing](https://innersourcecommons.org/) policy can start by applying their Definition of Done to any external contributions. -- If any developer on the team does not have the ability to merge code, ask "Why?". - -## Value - -As a team we want to create a culture of source ownership so that we can increase our product understanding, code quality, and delivery speed. - -## Acceptance Criteria - -- No contributions to source bypass the team's approval. +- No contributions will bypass the team's quality process. - Automated pipelines validate that PRs from internal and external contributors conform to quality standards. -- All team members have access to merge to trunk. +- All team members have access to merge to the trunk. - [InnerSourcing](https://innersourcecommons.org/) and/or external contributions **fork the repository they do not branch**. - Teams no larger than 12 people per team. diff --git a/content/en/docs/workflow-management/unplanned-work.md b/content/en/docs/workflow-management/unplanned-work.md index ba75305..be7186b 100644 --- a/content/en/docs/workflow-management/unplanned-work.md +++ b/content/en/docs/workflow-management/unplanned-work.md @@ -1,16 +1,12 @@ --- title: Unplanned Work - tags: - - workflow management + - Workflow + - Product Ownership --- -Unplanned work is any interruption that prevents one from finishing something -or from stopping at a better breaking point. It increases uncertainty in the system, -and makes the system less predictable as a result. - -There are times when unplanned work is necessary and understandable, but you -should be weary of increased risk, uncertainty, and reduced predictability. +Unplanned work is any interruption that prevents us from finishing something as planned. There are times when unplanned work is necessary and understandable, but you +should be wary of increased risk, uncertainty, and reduced predictability. --- @@ -23,9 +19,7 @@ what should come first. Most of the time, teams prioritize based on what the customer wants, what the stakeholders want, etc. -Cost of Delay makes it easier to decide priority based on value and urgency. - -How much money are we costing (or saving) the organization if _Feature A_ is +Cost of Delay makes it easier to decide priorities based on value and urgency. How much money are we costing (or saving) the organization if _Feature A_ is delivered over _Feature B_? --- @@ -50,10 +44,3 @@ Planned capacity should fall between 60% and 80% of a team's max capacity. - Make work visible, planned and unplanned, and categorize unplanned work based on value and urgency. --- - -### Value - -As a development team, we want to understand how to plan for unplanned work, so that we can reduce -risk and uncertainty for our deliverables. - ---- diff --git a/content/en/docs/workflow-management/visualizing-workflow.md b/content/en/docs/workflow-management/visualizing-workflow.md index 49e5694..b0ed1d2 100644 --- a/content/en/docs/workflow-management/visualizing-workflow.md +++ b/content/en/docs/workflow-management/visualizing-workflow.md @@ -1,8 +1,8 @@ --- title: Visualizing Workflow - tags: - - workflow management + - Workflow + - Teamwork --- Making work visible to ourselves, as well as our stakeholders is imperative in @@ -61,20 +61,6 @@ what's headed their way, and prevent delays from unknowns and invisible work. --- -## Value - -As a development team, we want to visualize our workflow, so that we may -improve workflow efficiency. - ---- - -## Acceptance Criteria - -- Use a visual board -- Show any and all work - ---- - ## References [Making Work Visible](https://itrevolution.com/book/making-work-visible/) - Dominica DeGrandis diff --git a/content/en/docs/workflow-management/workflow-process.md b/content/en/docs/workflow-management/workflow-process.md deleted file mode 100644 index 868471b..0000000 --- a/content/en/docs/workflow-management/workflow-process.md +++ /dev/null @@ -1,69 +0,0 @@ ---- -weight: 1 -title: Workflow Process - -tags: - - workflow management ---- - -Workflow management is the process the team uses to move things from "In Progress" to "Done", as rapidly as possible in value sequence. It's important for minimizing WIP that the team looks at the backlog as the team's work and does not pre-assign work to individuals. - -## Workflow Management Process - -In order to streamline business tasks, minimize room for error, and increase -overall efficiency, teams need to have the following prerequisites. - -- [Definition of Done](/docs/workflow-management/definition-of-done) -- [Kanban Board](/docs/workflow-management/visualizing-workflow), virtual or physical, with a - prioritized backlog - ---- - -### Plan Work - -Unplanned work is _anything_ coming into the backlog that has not been committed -to, or prioritized. This can include feature requests, support tickets, etc. - -Common struggles teams face with unplanned work can be: - -- [Work that has not been prioritized](/docs/workflow-management/unplanned-work) -- [Work that has not been decomposed](/docs/work-decomposition/work-breakdown) -- [Work that is unplanned](/docs/workflow-management/unplanned-work) - ---- - -### Do Work - -Completed work meets the [Definition of Ready](/docs/work-decomposition/definition-of-ready) -when work begins, the [Definition of Done](/docs/workflow-management/definition-of-done) when work -is delivered, and can be completed in less than two days. - -Process smells identified for completing work include: - -- Context switching -- [Ineffective demos, or lack thereof](/docs/workflow-management/feedback-loops) -- [Multiple teams owning pieces of the process -- [Status and visibility of work is unclear](/docs/workflow-management/visualizing-workflow) -- Siloed work on the team - ---- - -### Improve Work - -In order to plan and complete work effectively, there must be [an improvement -process](/docs/delivery-system-improvement-journey#3-continuous-improvement) in place. The improvement process is centered around feedback loops. - -Challenges associated with the improvement process: - -- [Infrequent or nonexistent demos](/docs/workflow-management/feedback-loops) -- [Infrequent and unactionable retrospectives](/docs/workflow-management/retrospective) - ---- - -### Measuring Your Workflow - -A good measure to implement in your team's workflow is [WIP](/docs/workflow-management/limiting-wip). -Limiting work in progress can help reduce constraints in your workflow. - -[Development cycle time](/metrics/development-cycle-time) is a key -measure of success when trying to optimize and automate your team's workflow.