April 26, 2019 at 23:59Transparency - The Butcherts' Panacea
I have already tried to treat a “mechanical” scrum ( part 1 , part 2 , part 3 ), and in this article I will try to write out a universal medicine for “burning”. By itself, "burning", "seething", etc. - it’s good, it doesn’t matter to you ( but indifference is a step towards despondency, or, as is customary in IT, to burnout ). A lot of materials have been written and shot on the topic of burnout harm, for example: here , here , here or here .
One common wisdom says: “Buttherts are the engine of progress.” But it often happens like this: it’s burned => a superficial solution is quickly adopted, masking the problem => the solution comes to life => it continues to burn. In other words, instead of sorting out and making a diagnosis, we immediately proceed to treatment. I will try to illustrate this with examples.
First, let's define the term “transparency”. The Scrum guide defines it this way:
These definitions apply only to the process, I want to consider the concept more broadly. I will not undertake to give exact scientific definitions, but I will try to describe “transparency” through the conditions necessary for its existence. So, for transparency, you need:
If these necessary conditions are met, then you can start the process of building transparency: defining the task, defining success criteria in solving the problem, developing a method for evaluating the criteria. How it can be:
First of all, we answer the main questions:
The following sequence of actions is possible:
Separately, I want to emphasize that coherence and the general adoption of agreements are important, without which it is difficult to achieve involvement. Indeed, in decision-making systems ( for example, in the army ), the conceptual basis is uniform, the actions and evaluation criteria are understandable, but how much is accepted ( is there empathy ) by the participants is a big question.
I hope I managed to reveal my idea of transparency, then I will try to give a few examples of situations that can be improved if transparency is added.
Recently, it seems to me that the issue of professional burnout in the IT environment has been very acute ( Entire thematic meetings are held on this topic, for example, PiterJS , where there was a report by my colleague Zhenya Kot bunopus ).
Our work is intellectual, the mindset is analytical, well, you yourself are in the know. It seems to me that there is a tendency to invent difficulties where they do not exist. Sometimes this comes precisely from the lack of transparency ( here are a couple of research results: one and two ), and not because of the large amount of work: there is no necessary information - I’ll come up with it myself ( remember the analytical mindset), from the assumption I will draw conclusions - I will draw up a plan and go to fight with castles in the air. Here are the questions that may concern us ( IT specialists ):
The questions are correct, it is important for a person to reflect on the past, think about the present and plan the future. It is important to think about the people who are around. And transferring it to work, of course, we can expect that the workers themselves will look for answers to these questions, will clarify what interests them. But you can simply make all this transparent, and then people will focus on higher matters and solving problems at the next level, aimed at optimization, innovation, etc. There are tons of tools to provide this kind of transparency, here are some examples:
Now, however, as always, everyone is busy searching for “a person’s place in this world,” and if the tools are given to define themselves at least at work, such an employee will be a little more harmonious and happier, and there may be less cases of professional burnout.
We white people like to break spears in holy wars: React vs Angular , iOS vs Android, OOP vs functionalism, etc. But unfortunately or fortunately, there is no “silver bullet”. There is a specific task and solutions. When we are faced with the choice of technology, framework, architecture, etc., with a high degree of probability we are in a “confused” domain, according to the Kenevin model, and, as a result, there is no correct answer. In this situation, it is desirable to realize and fix the problem being solved, to understand what alternatives we are considering, what criteria we have for making decisions. It is necessary to collect this data together, make a choice and also document it. Over time, it is worth returning to these artifacts and reconcile with where we are moving. Everything is changeable: the world, the company, the team, specific people, conditions, etc., therefore, when we have information about which areas and why we chose, it is easier to adjust the path based on this knowledge. And do not fall into the classic situation of tearing a vest on the chest: “But who ever invented all this ?! It looks like people were unsuitable, since this is heralded. Here is the correct answer, it is obvious. I’ll save everyone and redo everything. ”
I think many people are familiar with the situation when, in an attempt to build a "wonderful new world," they change their leaders, the team, to those who are ready to burn Babylon, but the output is not a phoenix, but a goblin.
You can try not to cut it off your shoulder, but retrospectively analyze all errors and inaccuracies, track the logic of technical decisions, consider risks and put forward a new hypothesis. And the basis for decision-making will not be "they are all fools ...", but "the conditions have changed and we are already solving a new problem."
It seems to me that it’s difficult to make the right technical decisions all the time. You can learn to experiment, evaluate the results and plan the next steps, taking into account the new information received. And it can be easier if you have artifacts available to all interested parties that describe the logic of technical decisions.
There is an eternal debate in the Agile environment: “Where to start the transformation: from culture / values / mindset or mechanics / rituals / artifacts?”. Such a classic chicken and egg dilemma. My position is that for a “strong and independent” agile coach it may happen that a team through mechanics gradually comes to mindfulness. But more often, if you start with mechanics and implement some kind of approach as a cargo cult, then most likely we will get skepticism and disappointment in the methodology, and in the worst case, we will also gain haters. How this can happen is well described in the Scream Guide ( here a fiery translation ).
Therefore, I am in favor of analyzing how much Agile values go in your case, and only then proceed with the application of a framework or technique. Universal test, but there are litmus paper ( for example: to test agile and using agile guide ): first think, can help specifically in your case conditional scrum or not ( yet another example of the test table ).
Let's look at an example: a business gets burned up because development is slow, a decision is made - let's implement scrum / kanban / lean, because it speeds up development ( so it doesn't mean) And over time, we conclude: "this is quackery and marketing tricks, it does not work." A familiar story? My opinion is to start with transparency. Let's understand what exactly bothers. Let's start talking in the same terms and understand the terms in the same way. Let's formulate the questions: “What is the problem?”, “How do we understand that it’s bad?”, “How to understand what’s better?”, “How do we define what’s good?”, “Did everyone realize the problem and perceive "as a problem ( and for example, not the whims of stupid managers )?" And when everything became transparent, then at this moment you can look for solutions. Indeed, “slow development” can mean:
There can be many situations, for each of them there are own improvement tools. And often the implementation of agile / scrum / kanban / lean / etc. it looks like hammering nails with a microscope and, in fact, creating the appearance of violent activity, but not looking for a solution to the problem. Therefore, the rule “do not make yourself an idol” works here: you should not look for a silver bullet in hype approaches / methodologies / frameworks, first just realize what problem you are solving, and choose a solution tool after that. And it turns out that, having embarked on a path of continuous improvement ( awareness of the problem, formalizing work with it, transparency, finding solutions through experiments ), you will build your process unlike anything, but it works perfectly for you.
According to the Kenevin model, almost all of our IT work is in a confused domain, which means that expert opinion does not work here and there are no correct answers. And one of the possible options for a comfortable existence in it is an empirical process that begins with transparency. It would seem that these are common truths, but it seems that they are not always remembered.
If you read up to this place and you got bombarded by another populist-captain’s article, then you can try to ask yourself questions:
Write all this in the comments: put all the dots over i and make this question transparent.
Summing up: opacity can lead to the disintegration of society into groups, holy wars, manifestos , etc. But you can sit down and first try to speak the same language and hear each other. All transparency!
Thanks for the illustration, Sai Kin !
One common wisdom says: “Buttherts are the engine of progress.” But it often happens like this: it’s burned => a superficial solution is quickly adopted, masking the problem => the solution comes to life => it continues to burn. In other words, instead of sorting out and making a diagnosis, we immediately proceed to treatment. I will try to illustrate this with examples.
First, let's define the term “transparency”. The Scrum guide defines it this way:
Significant aspects of the process must be visible to those responsible for the outcome. Transparency requires those aspects be defined by a common standard so observers share a common understanding of what is being seen.
Important aspects of the process should be visible to those responsible for the outcome. These aspects should be defined by a common standard so that observers equally understand the object of observation.
These definitions apply only to the process, I want to consider the concept more broadly. I will not undertake to give exact scientific definitions, but I will try to describe “transparency” through the conditions necessary for its existence. So, for transparency, you need:
- The object that someone needs ;
- A common goal for all stakeholders related to the facility;
- The desire of all stakeholders to achieve the goal;
- The ability of all to communicate in one language, i.e. the ability to develop such a conceptual framework that will be meaningful for all interested parties ( for example, terms such as ROI and Redux , it seems that they lie in different and distant planes, although very capacious in specific information environments ).
If these necessary conditions are met, then you can start the process of building transparency: defining the task, defining success criteria in solving the problem, developing a method for evaluating the criteria. How it can be:
First of all, we answer the main questions:
- What are you going for?
- What is the purpose?
The following sequence of actions is possible:
- We define the terminology ( for example, everyone understands the finished task in the same way, and not so that for development it is when the code is written, and for business it is when the client started using the results );
- We agree on key aspects and how we will measure their condition, how we will perceive the results ( for example, we gather once a day, look at the plan, determine our condition regarding this plan );
- We embody our plan.
Separately, I want to emphasize that coherence and the general adoption of agreements are important, without which it is difficult to achieve involvement. Indeed, in decision-making systems ( for example, in the army ), the conceptual basis is uniform, the actions and evaluation criteria are understandable, but how much is accepted ( is there empathy ) by the participants is a big question.
I hope I managed to reveal my idea of transparency, then I will try to give a few examples of situations that can be improved if transparency is added.
Am I a trembling creature or do I have the right?
Recently, it seems to me that the issue of professional burnout in the IT environment has been very acute ( Entire thematic meetings are held on this topic, for example, PiterJS , where there was a report by my colleague Zhenya Kot bunopus ).
Our work is intellectual, the mindset is analytical, well, you yourself are in the know. It seems to me that there is a tendency to invent difficulties where they do not exist. Sometimes this comes precisely from the lack of transparency ( here are a couple of research results: one and two ), and not because of the large amount of work: there is no necessary information - I’ll come up with it myself ( remember the analytical mindset), from the assumption I will draw conclusions - I will draw up a plan and go to fight with castles in the air. Here are the questions that may concern us ( IT specialists ):
- But am I doing nonsense? How does my work improve the world?
- How good am I in my business?
- Yes they know who I am? Who are they? What do they allow themselves?
- What's next? Where am I going? Do I go with those?
The questions are correct, it is important for a person to reflect on the past, think about the present and plan the future. It is important to think about the people who are around. And transferring it to work, of course, we can expect that the workers themselves will look for answers to these questions, will clarify what interests them. But you can simply make all this transparent, and then people will focus on higher matters and solving problems at the next level, aimed at optimization, innovation, etc. There are tons of tools to provide this kind of transparency, here are some examples:
- The goals, mission and strategy of the company are open and understandable to employees, and they are well known. All tactical tasks are taught through communication with the strategy, it is always clear for what current goal this or that work is required. It is clear not only what needs to be done, but also why it needs to be done.
- Employees regularly receive feedback on the results of their work: achievements, growth points ( for example, 360 or 1 to 1 polls ). Joint development planning and inspection of the dynamics of achieving this plan.
- The described organizational structure and communications within it: what and with whom you can talk. Social contracts, team business cards, etc.
- A transparent motivation system, a career tree and, possibly, gamification of this process. You can be inspired by examples of LitRes or 2GIS , and build your own culture in which employees understand how to determine and influence their level of material motivation.
Now, however, as always, everyone is busy searching for “a person’s place in this world,” and if the tools are given to define themselves at least at work, such an employee will be a little more harmonious and happier, and there may be less cases of professional burnout.
Crusades
We white people like to break spears in holy wars: React vs Angular , iOS vs Android, OOP vs functionalism, etc. But unfortunately or fortunately, there is no “silver bullet”. There is a specific task and solutions. When we are faced with the choice of technology, framework, architecture, etc., with a high degree of probability we are in a “confused” domain, according to the Kenevin model, and, as a result, there is no correct answer. In this situation, it is desirable to realize and fix the problem being solved, to understand what alternatives we are considering, what criteria we have for making decisions. It is necessary to collect this data together, make a choice and also document it. Over time, it is worth returning to these artifacts and reconcile with where we are moving. Everything is changeable: the world, the company, the team, specific people, conditions, etc., therefore, when we have information about which areas and why we chose, it is easier to adjust the path based on this knowledge. And do not fall into the classic situation of tearing a vest on the chest: “But who ever invented all this ?! It looks like people were unsuitable, since this is heralded. Here is the correct answer, it is obvious. I’ll save everyone and redo everything. ”
I think many people are familiar with the situation when, in an attempt to build a "wonderful new world," they change their leaders, the team, to those who are ready to burn Babylon, but the output is not a phoenix, but a goblin.
You can try not to cut it off your shoulder, but retrospectively analyze all errors and inaccuracies, track the logic of technical decisions, consider risks and put forward a new hypothesis. And the basis for decision-making will not be "they are all fools ...", but "the conditions have changed and we are already solving a new problem."
It seems to me that it’s difficult to make the right technical decisions all the time. You can learn to experiment, evaluate the results and plan the next steps, taking into account the new information received. And it can be easier if you have artifacts available to all interested parties that describe the logic of technical decisions.
Implement agile / scrum / kanban / lean in compressed cp * ki
There is an eternal debate in the Agile environment: “Where to start the transformation: from culture / values / mindset or mechanics / rituals / artifacts?”. Such a classic chicken and egg dilemma. My position is that for a “strong and independent” agile coach it may happen that a team through mechanics gradually comes to mindfulness. But more often, if you start with mechanics and implement some kind of approach as a cargo cult, then most likely we will get skepticism and disappointment in the methodology, and in the worst case, we will also gain haters. How this can happen is well described in the Scream Guide ( here a fiery translation ).
Therefore, I am in favor of analyzing how much Agile values go in your case, and only then proceed with the application of a framework or technique. Universal test, but there are litmus paper ( for example: to test agile and using agile guide ): first think, can help specifically in your case conditional scrum or not ( yet another example of the test table ).
Let's look at an example: a business gets burned up because development is slow, a decision is made - let's implement scrum / kanban / lean, because it speeds up development ( so it doesn't mean) And over time, we conclude: "this is quackery and marketing tricks, it does not work." A familiar story? My opinion is to start with transparency. Let's understand what exactly bothers. Let's start talking in the same terms and understand the terms in the same way. Let's formulate the questions: “What is the problem?”, “How do we understand that it’s bad?”, “How to understand what’s better?”, “How do we define what’s good?”, “Did everyone realize the problem and perceive "as a problem ( and for example, not the whims of stupid managers )?" And when everything became transparent, then at this moment you can look for solutions. Indeed, “slow development” can mean:
- There is no normal deployment process; deploying changes to products is a pain. Solution options - implement DevOps culture, run CI / CD ;
- Business and development have not learned to talk. It seems to business that development does not understand anything, and development, on the contrary, believes that the business does not know what it wants. Possible solutions - try to build a goal-setting, build Impact Mapping or use OKR ;
- The hierarchical structure is filled with micromanagement, in which there is a slow adoption of tactical decisions due to the need for coordination with higher ones. Solution options - train people in facilitation, conduct experiments with confidence ( watch a motivational video with TED );
- The list goes on.
There can be many situations, for each of them there are own improvement tools. And often the implementation of agile / scrum / kanban / lean / etc. it looks like hammering nails with a microscope and, in fact, creating the appearance of violent activity, but not looking for a solution to the problem. Therefore, the rule “do not make yourself an idol” works here: you should not look for a silver bullet in hype approaches / methodologies / frameworks, first just realize what problem you are solving, and choose a solution tool after that. And it turns out that, having embarked on a path of continuous improvement ( awareness of the problem, formalizing work with it, transparency, finding solutions through experiments ), you will build your process unlike anything, but it works perfectly for you.
Why am I all this
According to the Kenevin model, almost all of our IT work is in a confused domain, which means that expert opinion does not work here and there are no correct answers. And one of the possible options for a comfortable existence in it is an empirical process that begins with transparency. It would seem that these are common truths, but it seems that they are not always remembered.
If you read up to this place and you got bombarded by another populist-captain’s article, then you can try to ask yourself questions:
- Why is it burnt?
- Why did it infuriate me?
- What could be different, so as not to cause me such emotions?
Write all this in the comments: put all the dots over i and make this question transparent.
Summing up: opacity can lead to the disintegration of society into groups, holy wars, manifestos , etc. But you can sit down and first try to speak the same language and hear each other. All transparency!
Thanks for the illustration, Sai Kin !