Optimizations - what do you think when you hear this word? Something is getting better and more effective and genuinely helps to extract more value from what people do. But what happens when we focus more on optimization than the initial cause? We Try to Optimize Everywhere. Think about your day-to-day activities: We use Jira or any other task-management system; We have created a Definition of Ready, which indicates that something can be started; Definition of Done to understand when something is indeed done and ready to be shipped; Other checklists that are supposed to help us navigate the VUCA world; Branching strategies so that engineers can work separately and then ship combined artifacts; Engagement form with external team to embrace prioritization and a front-dore forum that aims to provide some clarity for what has to be done; Weekly progress report meeting to offer updates to the leadership team; But do they help? Do we even remember the original idea behind the majority of these items? Who proposed them? Who tracks how they are being lived? What happens if we just remove the majority of them? All these questions are fundamental to living by Lean and Agile values, reducing waste, and caring about what matters. Let’s take a look at two common examples of what we think are known to the majority of people. Jira Workflow. The Jira workflow is the mightiest tool. Leadership loves it as it provides an overview of what’s going on, and engineers hate it because it is rarely user-friendly. In the diagram above, you can see a typical workflow for the Jira issue. It contains of: A dozen or more statuses; An extremely complex net of transition between these statuses; Rules, mandatory fields, and automation rules which are not even visible on the workflow but we can ensure everyone exists. All this was created to make someone’s life easier. But does it? As a new joiner navigating through this workflow, you are most likely to get one or more comments from the list: Why do we do Y? Why can’t I move the item to column Z? We don’t use this status anyway, but I still need to click through it every day; I will just put N/A in this field, as everyone does this. It doesn’t look like it helps anyone. Would it make sense to review the workflow again? The team no longer needs tech specs as everyone does pair programming, and the architect is always there with the developer to help create it on the go (the situation is oversimplified for the purpose of this discussion); Some testing statuses are obsolete as the team does only automation testing now; It is too complex, there are 16 statuses, over 30 transitions, and some hidden rules and exceptions. The workflow and obsolete items on it are perfect examples of local optimizations. They were created for good and probably made sense at that point, but as an organization and its people evolved, some elements became useless and even dangerous. That’s a rabbit hole now. Definition of Done. According to the Scrum guide, It is a formal description of the state of the Increment when it meets the quality measures required for the product. Once the Definition of Done is met, the Increment is Done and can be delivered. Clear and easy to define and use, isn’t it? But how do we actually use it? It all starts from a few items, let’s say: Acceptance Criterias are met; Code Review is done; Testing is completed; Code is integrated. When one of the iterations is released, users start getting error 403: The team quickly reverts the release, does a postmortem, and realizes that they have forgotten to drop sessions that are not valid anymore, so they add the item to the Definition of Done, and now, it consists of: Accpetance Criterias are met; Code Review is done; Testing is completed; Code is integrated; User sessions are dropped. They release it again, and now there is an error 404: The team quickly reverts the release, does a postmortem, and realizes that database migrations were not applied, so they add the item to the Definition of Done, and now it consists of: Accpetance Criterias are met; Code Review is done; Testing is completed; Code is integrated; DB migrations are applied; User sessions are dropped. The release, and guess what? Error 500: The team quickly reverts the release, does a postmortem, and realizes that …. You have got my point. This list is going to be expanded forever until someone decides it is a mess and proposes to recreate it. That’s a rabbit hole now. So What? Don’t get me wrong, local optimizations are helpful. They are extremely helpful on short distances and can help to: Streamline processes; Ensure that the team is not missing crucial parts of the process; Meet governance requirements; Boost productivity; Improve communication and accountability; But they can also, and most likely will, distract from what matters at a long distance, especially if left unattended. They are a necessity. Each team will try to ease their lives by introducing a checklist, framework, or regulation. It is important to remember that while they can help, they are guaranteed to harm in the long run if they are left unattended. Try to think about optimizations that you have introduced to your team and review them. Try to minimize those that focus on a narrow set of actions, but instead, try to influence behavior. While evaluating those that already exist or when you try to create new think about: Why are we doing this? How does/will it help us? Is there any other way to prevent an encountered situation in the future? If you had to introduce them, it's not a problem. Just make sure to plan a check-in in the future and put it on your calendar. During the check-in, revise: Why was it introduced? Did it solve the problem? Do we still need it? How do we move forward? It is hard to get out of the rabbit hole, but remember that everything is possible in the world where magic exists! Optimizations - what do you think when you hear this word? Something is getting better and more effective and genuinely helps to extract more value from what people do. But what happens when we focus more on optimization than the initial cause? We Try to Optimize Everywhere. Think about your day-to-day activities: We use Jira or any other task-management system; We have created a Definition of Ready, which indicates that something can be started; Definition of Done to understand when something is indeed done and ready to be shipped; Other checklists that are supposed to help us navigate the VUCA world; Branching strategies so that engineers can work separately and then ship combined artifacts; Engagement form with external team to embrace prioritization and a front-dore forum that aims to provide some clarity for what has to be done; Weekly progress report meeting to offer updates to the leadership team; We use Jira or any other task-management system; We have created a Definition of Ready, which indicates that something can be started; Definition of Done to understand when something is indeed done and ready to be shipped; Other checklists that are supposed to help us navigate the VUCA world; Branching strategies so that engineers can work separately and then ship combined artifacts; Engagement form with external team to embrace prioritization and a front-dore forum that aims to provide some clarity for what has to be done; Weekly progress report meeting to offer updates to the leadership team; But do they help? Do we even remember the original idea behind the majority of these items? Who proposed them? Who tracks how they are being lived? What happens if we just remove the majority of them? All these questions are fundamental to living by Lean and Agile values, reducing waste, and caring about what matters. Let’s take a look at two common examples of what we think are known to the majority of people. Jira Workflow. The Jira workflow is the mightiest tool. Leadership loves it as it provides an overview of what’s going on, and engineers hate it because it is rarely user-friendly. In the diagram above, you can see a typical workflow for the Jira issue. It contains of: A dozen or more statuses; An extremely complex net of transition between these statuses; Rules, mandatory fields, and automation rules which are not even visible on the workflow but we can ensure everyone exists. A dozen or more statuses; An extremely complex net of transition between these statuses; Rules, mandatory fields, and automation rules which are not even visible on the workflow but we can ensure everyone exists. All this was created to make someone’s life easier. But does it? As a new joiner navigating through this workflow, you are most likely to get one or more comments from the list: Why do we do Y? Why can’t I move the item to column Z? We don’t use this status anyway, but I still need to click through it every day; I will just put N/A in this field, as everyone does this. Why do we do Y? Why can’t I move the item to column Z? We don’t use this status anyway, but I still need to click through it every day; I will just put N/A in this field, as everyone does this. It doesn’t look like it helps anyone. Would it make sense to review the workflow again? The team no longer needs tech specs as everyone does pair programming, and the architect is always there with the developer to help create it on the go (the situation is oversimplified for the purpose of this discussion); Some testing statuses are obsolete as the team does only automation testing now; It is too complex, there are 16 statuses, over 30 transitions, and some hidden rules and exceptions. The team no longer needs tech specs as everyone does pair programming, and the architect is always there with the developer to help create it on the go (the situation is oversimplified for the purpose of this discussion); Some testing statuses are obsolete as the team does only automation testing now; It is too complex, there are 16 statuses, over 30 transitions, and some hidden rules and exceptions. The workflow and obsolete items on it are perfect examples of local optimizations. They were created for good and probably made sense at that point, but as an organization and its people evolved, some elements became useless and even dangerous. That’s a rabbit hole now. Definition of Done. According to the Scrum guide, It is a formal description of the state of the Increment when it meets the quality measures required for the product. Once the Definition of Done is met, the Increment is Done and can be delivered. Clear and easy to define and use, isn’t it? But how do we actually use it? It all starts from a few items, let’s say: Acceptance Criterias are met; Code Review is done; Testing is completed; Code is integrated. Acceptance Criterias are met; Acceptance Criterias are met; Code Review is done; Code Review is done; Testing is completed; Testing is completed; Code is integrated. Code is integrated. When one of the iterations is released, users start getting error 403: The team quickly reverts the release, does a postmortem, and realizes that they have forgotten to drop sessions that are not valid anymore, so they add the item to the Definition of Done, and now, it consists of: Accpetance Criterias are met; Code Review is done; Testing is completed; Code is integrated; User sessions are dropped. Accpetance Criterias are met; Code Review is done; Testing is completed; Code is integrated; User sessions are dropped. User sessions are dropped. They release it again, and now there is an error 404: The team quickly reverts the release, does a postmortem, and realizes that database migrations were not applied, so they add the item to the Definition of Done, and now it consists of: Accpetance Criterias are met; Code Review is done; Testing is completed; Code is integrated; DB migrations are applied; User sessions are dropped. Accpetance Criterias are met; Code Review is done; Testing is completed; Code is integrated; DB migrations are applied; DB migrations are applied; User sessions are dropped. User sessions are dropped. The release, and guess what? Error 500: The team quickly reverts the release, does a postmortem, and realizes that …. You have got my point. This list is going to be expanded forever until someone decides it is a mess and proposes to recreate it. That’s a rabbit hole now. So What? Don’t get me wrong, local optimizations are helpful. They are extremely helpful on short distances and can help to: Streamline processes; Ensure that the team is not missing crucial parts of the process; Meet governance requirements; Boost productivity; Improve communication and accountability; Streamline processes; Ensure that the team is not missing crucial parts of the process; Meet governance requirements; Boost productivity; Improve communication and accountability; But they can also, and most likely will, distract from what matters at a long distance, especially if left unattended. They are a necessity. Each team will try to ease their lives by introducing a checklist, framework, or regulation. It is important to remember that while they can help, they are guaranteed to harm in the long run if they are left unattended. Try to think about optimizations that you have introduced to your team and review them. Try to minimize those that focus on a narrow set of actions, but instead, try to influence behavior. While evaluating those that already exist or when you try to create new think about: Why are we doing this? How does/will it help us? Is there any other way to prevent an encountered situation in the future? Why are we doing this? How does/will it help us? Is there any other way to prevent an encountered situation in the future? If you had to introduce them, it's not a problem. Just make sure to plan a check-in in the future and put it on your calendar. During the check-in, revise: Why was it introduced? Did it solve the problem? Do we still need it? How do we move forward? Why was it introduced? Did it solve the problem? Do we still need it? How do we move forward? It is hard to get out of the rabbit hole, but remember that everything is possible in the world where magic exists!
