DevOps Workflow Board and Value Stream Analytics
Description
Teams and companies want to be able to analyze their value stream. i.e. the value-producing activities they engage in. In software development terms, that usually includes things such as planning, coding, testing, and deploying.
From Chris Condo's slides for a webinar we recently did together:
Looks reminiscent of the DevOps lifecycle stages!
Now, why do people care about value streams?
- Part of the value of Value Stream Analysis is to understand what parts of the effort directly generate value vs what parts are overhead or "waste". Overhead is usually represented as a vertical flow away from the main horizontal flow - presumably to indicate that it's not helping to move the value forward.
- Part of the value of Value Stream Analysis is to understand lead time vs process time. i.e. how much time something is waiting for something to start vs time spent actually working on the thing.
- But ultimately, the value we espouse is to understand and shorten the total time to deliver value, because that's a key driver to business success.
That sounds an awful lot like cycle analytics, but cycle analytics misses the mark in a few ways:
- It doesn't align perfectly with our DevOps lifecycle stages
- It isn't complete
- It doesn't use known terminology (i.e. some people want "value stream" and don't know that cycle analytics maps closely to what they want)
- Users want to create their own value stream steps - e.g. some teams have several steps of QA before deploying
- Users want to modify the definitions of each step
- Some steps might be impossible to measure automatically
- Measuring lead time vs process time is hard
We could start working down that list, including letting people customize cycle analytics, but this gets very complicated very fast. Instead, imagine a very different approach. Start from issue boards.
A very simple issue board might have todo
, doing
, and done
. But a more elaborate one might have planning
, scheduled
, doing
, in review
, merged
, deployed
. This lets users move issues between each stage to communicate where something is in their workflow. It looks an awful lot like the value stream above. What if we just let users create an issue board for their value stream? You can pick whatever column labels you like, and manually move issues between them when things change. This seems pretty natural, and is pretty close to what people are already doing to communicate state to their team.
The interesting twist is that we could then measure how long the issues stayed in each stage and generate value stream analytics based on those recorded timings!
Seems promising, incredibly simple, yet incredibly flexible and powerful. We no longer have to worry about the perfect definition of when something leaves review and enters QA, or artificially map these actions to the 7 stages of the DevOps lifecyle (or the outdated I2P steps). We recognize that while there are 7 categories of DevOps actions/functionality; they really represent a bunch of activities that don't map exactly 1:1, and that people want to see their flow. With an issue board, they're in complete control.
Now, this sounds great, but also quite painful. What if I forget to move the issue from doing
to merged
after I merge the code? Anyone glancing at the board during that window will be misinformed, but on top of that, now my analytics will be off! We already automatically move issues to done
when they're closed, what if we extend that automation? We know when the associated MR is deployed, can't we move the issue to deployed
automatically? Since columns are just labels, all it requires is for us to programmatically set/change/remove labels when various actions are detected. This gets even better with label groups (https://gitlab.com/gitlab-org/gitlab-ce/issues/21902#note_70111849) to enforce that only one stage label can be applied at any time.
In true iteration fashion, we could start by providing automation rules for the obvious things, like detecting when something is deployed to production. Then build on those until we've automated all of the transitions. But of course, also let people customize them. e.g. if a project deploys to an environment with a different name, or if this project doesn't deployment to production at all, and instead publishes a release to the artifact repository. We'll provide a bunch of common definitions, and the primitives to let people customize them. It's possible though that some transitions aren't automatable, in which case we'd fall back to the manual application of labels.
Maybe we could even help measure lead time vs process time. If they're using the Web IDE, we could actually measure time spent coding/reviewing vs idle/blocked.
Proposal
MVC
- Create an Issue Board that represents your value stream.
- Redo Cycle analytics based on issue boards. Analytics relate directly to your workflow.
MVC+1
- Automate steps to move issues along the board. Trigger actions will change the state of the issue, moving it to a different column. (https://gitlab.com/gitlab-org/gitlab-ce/issues/28692)
MVC+2
- Enforce that issues can only appear in one column at a time, perhaps via Label Groups (https://gitlab.com/gitlab-org/gitlab-ee/issues/5805)
Potentially, this could be a specific type of board (https://gitlab.com/gitlab-org/gitlab-ee/issues/977).
Links / references
- Value Stream Analytics: https://gitlab.com/gitlab-org/gitlab-ee/issues/5410
- New issue/MR state: deployed : https://gitlab.com/gitlab-org/gitlab-ce/issues/45755
- Label groups: https://gitlab.com/gitlab-org/gitlab-ce/issues/21902#note_70111849
- Issue board types: https://gitlab.com/gitlab-org/gitlab-ee/issues/977
- GitHub project automation: https://blog.github.com/2017-10-30-keep-your-project-boards-up-to-date-automatically/