English | EN Beautiful Delivery Process
Feb 5, 2018
Based on my work on Beautiful Delivery with autonomous cross-functional teams (for more details, see Use Beautiful Delivery to Speed Up Your Digital Transformation), I will focus on defining the agile process of these teams in a bit more detail.
The most important thing about how the team works isthat everyone is responsible for everything. It sounds obvious but it’s actually a profound difference with how most teams work. Think about it, if something need to happen, there is no one to wait for, there no one to hand over to, and most importantly, there is no one to blame. There are simply things that needs to be done, and someone in the team needs to do them. If no one else can do it, you have to do it yourself. It’s not relevant if you are the best at something, or even if you have the proper skills, you just have to try. Even if someone in the team does not perform or doesn’t work well with the others in the team, it’s still the teams collective problem to solve.
Because of this, there is a constantly ongoing involvement from everyone, in most things, and even with many people outside the team. That includes end users, stakeholders, other teams, and other people in the organization that the team have some kind of dependency with, like executives, enterprise architects, marketing, etc. The key word is communication, and lots of it!
The process starts with input in the form of new ideas and things the team have learned from monitoring and user feedback. The input is put in the backlog in the form of user stories. If your reference is use cases, these are much smaller pieces of the functionality expressed in the form: As a <role>, I want <goal> so that <reason>, which is proved by <metric>. Please note that it’s NOT a requirement, but a hypothesis that has to be proven. It’s a good idea to track the user stories back to core business goals (user story mapping). The backlog is constantly prioritized on value of each user story versus the effort to implement it. One interesting way to look at the value is what it costs not to implement something.
Before each sprint (iteration), the top stories in the backlog are estimated and selected to fit into a defined period (usually two weeks), which then becomes the sprint backlog. The team work on completing the sprint backlog, and every day there is a meeting (daily standup) to share status (what has been done yesterday, what will be done today, and if there are any showstoppers). At the end of the sprint, there is a meeting (review) to decide whether to release the result according to a standard (definition of done), and another to capture what has been learned (retrospective) and what needs to change (refactored) in both the process and tools for the next sprint. When the result is released, there is a constant monitoring (with specific metrics derived from how to prove the user stories) and capturing feedback from users, and the cycle starts over. Note that if something important comes up via monitoring or user feedback, it may go into the ongoing spring.
As you can see above, there are a lot of things that is constantly going on. There is a continuous involvement by many people inside and outside of the team, of ideas generated, of prioritization of things to focus on, of development, of builds, of tests, of deployments, of security measures, of monitoring, of feedback, of learning, and improving. To increase efficiency there is also a continuous focus on automation, so that anything that can be automated should, or more drastically, any manual task is a bug.
About the author
