Tim Lister - book co-author
- "Human factor. Successful Projects and Teams” (in the original book is called “Peopleware”)
- "Waltzing with the Bears: Managing Risk in Software Development Projects"
- “Ridiculous with adrenaline and zombified by templates. Behavior patterns of project teams»
All these books are classics in their field and are written together with colleagues in . In Russia, his colleagues are most famous - и who also wrote many well-known works.
Tim has 40 years of experience in software development, in 1975 (no one who wrote this habrapost was born this year), Tim was already the executive vice president of Yourdon Inc. He now works in consulting, teaching and writing, visiting from time to time. conferences around the world.
Especially for Habr, we made an interview with Tim Lister. He will open the DevOops 2019 conference, and we have accumulated a lot of questions, about books and not only. Interviews are conducted by Mikhail Druzhinin and Oleg Chirukhin from the Conference Program Committee.
Michael: Can I say a few words about what you are currently doing?
Tim: I am the head of the Atlantic Systems Guild. There are six of us in the Guild, we call ourselves Principals. Three in the US and three in Europe - that's why the Guild is called the Atlantic. We've been together for so many years that you just can't count. We all have our specialties. For the last decade, or even more, I have been working with clients. My projects include not only management, but also setting requirements, project planning, and evaluation. It seems that projects that start badly usually end badly. Therefore, it is worth making sure that all activities are really well thought out and coordinated, that the ideas of the creators are combined. It is worth considering what you are doing and why. What strategies to use to bring the project to completion.
For many years I have been advising clients in a variety of ways. An interesting example is a company that makes robots for knee and hip surgery. The surgeon does not operate completely independently, but uses a robot. Safety is, frankly, important here. But when you try to discuss requirements with people who are problem solving… It sounds strange, but in the US there are (Federal Drug Administration), which licenses products like these robots. Before you can sell something and use it on living people, you need to get a license. One of the conditions is to show your requirements, what are the tests, how did you test them, what are the test results. If you change the requirements, then you need to go through this whole huge testing process again and again. Our clients have managed to include the visual design of applications in their requirements. They had direct screenshots as part of the requirements. You have to pull them out and explain that for the most part all these programs do not know anything about knees and hips, all this camera stuff, etc. We need to rewrite the requirements documents so that they never change unless some really important underlying conditions change. If visual design is not in the requirements, it will be much faster to update the product. Our job is to find those elements that deal with operations on the knee, hips, back, pull them out into separate documents and say that these will be fundamental requirements. Let's make an isolated group of requirements about knee surgery. This will allow you to build a more robust set of requirements. We will talk about the entire product line, and not about specific instances of robots.
A lot of work has been done, but they still got to places where they used to spend weeks and months of repeated tests without meaning and necessity, because their requirements, described on paper, did not coincide with the real requirements, according to which the systems were built. The FDA told them every time: your requirements have changed, now you need to check everything from scratch. Full re-checks of the entire product killed the enterprise.
So, there are such wonderful tasks when you find yourself at the very beginning of something interesting, and the very first actions set the further rules of the game. If you make sure that from both a managerial and a technical point of view, this early activity starts to work well, there is a chance to end up with a great project. But if that part goes off the rails and goes off the rails, if you can't find fundamental agreements... no, it's not that your project will necessarily fail. But you will no longer be able to say: “We are great, we did everything really efficiently.” That's what I do with my clients.
Michael: That is, you launch projects, do some kind of kickoff and check that the rails lead in the right direction?
Tim: We also have ideas about how to put all the pieces of the puzzle together: what skills do we need, when exactly do we need them, what does the core of the team look like and other such fundamental things. Do we need full-time employees or can we recruit someone part-time. Planning, management. Questions like: what is the most important thing for this particular project? How to achieve this? What do we know about this product or project, what are the risks and where does the unknown lie, how are we going to deal with it all? Of course, at this moment someone starts shouting “But what about agile?!”. Okay, you're all flexible, but so what? What exactly does the project look like, how are you going to take it out so that it suits the project? You can’t just say that “our approach is stretched to anything, we are a scrum team!”. This is nonsense and nonsense. Where are you going to go next, why should it work, where is the point? I teach my clients to think about all these questions.
19 years of agile
Michael: In agile, people often try not to define anything in advance, but to make decisions as late as possible, saying: we are too big, I will not think about the overall architecture. I will not think about a bunch of other things, instead, right now I will deliver to the customer something that works.
Tim: I think agile methodologies starting with in 2001, opened the industry's eyes. But on the other hand, nothing is perfect. I am entirely on the side of iterative development. Iteration makes a lot of sense in most projects. But you need to think about the question: after the product has come out and started to be used, how long does it live? Is this the kind of product that will last six months and then be replaced by another? Or is it a product that will work for many, many years? Of course, I won't name names, but... In New York and its financial community, the most fundamental systems are very old. This is amazing. You look at them and think, what if I could go back in time to 1994 and tell the developers: “I came from the future, from 2019. Just develop this system for as long as you need. Make it extensible, think about the architecture. It will then be improved for more than twenty-five years. If you delay development a little longer, in terms of history, no one will notice! When you evaluate things in the long run, you need to consider how much it will cost in its entirety. Sometimes a well-designed architecture is really worth it, and sometimes it's not. We need to look back and ask ourselves the question: are we in the right situation for such a decision?
So an idea like “We are for agile, the customer will tell us what he wants to get” is super naive. Customers do not even know what they want, and even more so they do not know what they could get. Some will start citing historical examples as arguments, I have already seen this. But tech-savvy people don't usually talk like that. They say: "It's 2019, these are the opportunities we have, and we can completely change the way we look at these things!". Instead of mimicking existing solutions, making them a little prettier and tidier, sometimes you need to go out and say: "Let's completely reinvent what we're trying to do here!".
And I don't think most customers can think of a problem in that way. They only see what they already have, and that's it. After which they come with requests like “let's make this a little easier”, or whatever they usually say. But we are not waiters or waitresses to take an order, no matter how stupid it turned out, and then bake it in the kitchen. We are their guides. We should open their eyes and say: hey, here we have new opportunities! Do you realize that we can really change how this part of your business is done? One of the problems with agile is that it takes away the awareness of what is an opportunity, what is a problem, what we actually need to do, what technologies are best for this particular situation.
I may have been too skeptical here: there are a lot of wonderful things happening in the agile community. But I have a problem with the fact that instead of defining a project, people start to shrug. I would ask here - what are we doing, how are we going to do it? And in some magical way it always turns out that the client should know better than anyone. But the client knows better than anyone only when he chooses from things already built by someone. If I want to buy a car and I know the size of the family budget, then I will quickly find a car that fits my lifestyle. This is where I know best! But, if you please, someone has already made the machines. How to invent a new car, I have no idea, I'm not an expert. When we create custom or some special products, the voice of the customer should be taken into account, but this is no longer the only voice.
Oleg: You mentioned Agile Manifesto. Do we need to somehow update or revise it, taking into account the modern understanding of the issue?
Tim: I wouldn't touch him. I think it's a great historical document. I mean, he is what he is. He is 19 years old, he is old, but in his time he made a revolution. What he did well was that he set off a reaction, people began to whisper about him. You most likely did not work in the industry in 2001, and then everyone worked on processes. Software Engineering Institute, Five Levels of Software Capability Model (CMMI). I don’t know if such legends of the deep antiquity tell you something, but then it was a breakthrough. At first, people believed that if the processes were properly built, then the problems would evaporate by themselves. And then the Manifesto appears and says: “No, no, no - we will be based on people, not on processes.” We are masters of software development. We understand that the ideal process is a mirage, it does not happen. There is too much idiosyncrasy in projects, the idea of a single flawless process for all projects does not make any sense. The problems are too complex to claim that there is only one solution for everything (hello, nirvana).
I do not undertake to look into the future, but I will say that people have now begun to think more about projects. I think the Agile Manifesto is really good, it comes forward and says, “Hey! You are on a ship, and you yourself are leading this ship. You will have to make a decision - we will not suggest a universal recipe for all situations. You are the crew of the ship, and if you are good enough, you will be able to find the way to the goal. There have been other ships before you, and there will be other ships after you, but nevertheless, in a way, your journey is unique.” Something like that! This is the way to think. For me, nothing is new under the sun, people have swum before and will swim again, but for you this is your main journey, and I will not tell you exactly what will happen to you. You must have the skills of coordinated teamwork, and if you really have them, everything will work out and you will come where you wanted.
Peopleware: 30 years later
Oleg: Peopleware was also a revolution, how was the Manifesto?
Tim: Peopleware... Tom and I wrote this book, but we didn't think it was going to happen. Somehow it resonated with the ideas of many people. It was the first book that said that software development is a very human-intensive activity. Despite our technical nature, we are also a community of people building something big, even huge, very complex. No one can create such things alone, right? So the idea of a “team” became very important. And not only in terms of management, but also for technical people who came together to solve really complex deep problems with a bunch of unknowns. For me personally, throughout my career, this has been a huge test of intelligence. And here you need to be able to say: yes, this problem is bigger than I can handle myself, but together we can find an elegant solution that we can be proud of. And I think this is the idea that resonated the most. The idea that we work part of the time on our own, part of the time as part of a group, and often the decision is made by the group. Team problem solving quickly became an important feature of complex projects.
Despite the fact that Tim has given a huge number of talks, there are very few of them posted on YouTube. You can see the report "The Return of Peopleware" in 2007. The quality, of course, leaves much to be desired.
Michael: Has anything changed in the last 30 years since the publication of the book?
Tim: You can look at it from many different angles. Sociologically speaking… once upon a time, in simpler times, you and your team were sitting in the same office. You could be there every day, drink coffee together and discuss work. What's really changed is that teams can now be spread out geographically, in different countries and time zones, but they're still working on the same task, and that adds a whole new layer of complexity. It may sound old-fashioned, but there's nothing better than face-to-face communication, when you all get together, work together, you can go up to a colleague and say: look what I found, how do you like it? Face-to-face conversations provide a quick way to get into informal communication, and I think agile lovers should like it too. Also, I'm worried because the reality is that the world is very small, and now it's all covered with distributed teams, and it's all very complicated.
We all live in DevOps
Michael: Even from the point of view of the conference program committee, we have people in California, in New York, in Europe, in Russia… nobody in Singapore yet. The difference in geography is quite large, and people begin to spread even more. Speaking of development, can you elaborate on devops and breaking down barriers between teams? There is a concept that everyone is sitting in their bunkers, and now the bunkers are collapsing, how do you like this analogy?
Tim: It seems to me that in light of the latest technological breakthroughs, devops is of great importance. Previously, you had teams of developers and admins, they worked, worked, worked, and at some point a thing appeared with which you could come to the admins and roll it out for production. And here the conversation about the bunker began, because the admins are, as it were, allies, not enemies, at least, but you only talked to them when everything was ready to go to production. You went to them with something and said: look, what kind of application we have, but could you roll out this application? And now the whole concept of delivery has changed for the better. I mean, the idea came up that you could push changes quickly. We can update products on the fly. I always smile when on my laptop Firefox shows a popup and says hey we've updated your Firefox in the background and as soon as you have a minute could you please click here and we'll give you a fresh release. And I'm like, "Oh yeah baby!" While I was sleeping, right on my computer, they were working on delivering a new release to me. It's wonderful, incredible.
But here's the difficulty: you have this feature with software updates, but integrating people is much more difficult. What I want to say at the DevOops keynote is that we now have more players than ever before. If you just think of all the people involved in just one team…. You thought of it as a team, and it's much more than just a team of programmers. These are testers, and project managers, and a bunch of other people. And everyone has their own view of the world. Product managers are completely different from project managers. Admins have their own tasks. It becomes quite a challenge to coordinate all the participants so that you remain aware of what is happening and not go crazy. It is necessary to separate the tasks of the group and the tasks that apply to everyone. This is a very difficult task. On the other hand, I think it's all much better than it was many years ago. This is exactly the path in which people grow up and learn to behave correctly. When you are doing integration, you understand that there should be no underground development, so that at the very last moment the software does not come out like the devil out of a snuffbox: like, look what we did here! The idea is that you will be able to integrate and develop, and in the end you will roll out in a neat and iterative way. All this is of great importance to me. This makes it possible to create more value for the users of the system and for your customer.
Michael: The whole idea of devops is to deliver meaningful developments as early as possible. I see that the world has started to accelerate more and more. How to adapt to such accelerations? Ten years ago this was not the case!
Tim: Of course, everyone wants more and more functionality. No need to move, just pile on more. Sometimes you even have to slow down in order for the next incremental update to bring at least something useful - and this is completely normal.
The idea that you need to run-run-run is not the best. Hardly anyone wants to live life like this. I would like the rhythm of deliveries to set its own rhythm for the project. If you're just producing a stream of small relatively meaningless things, the whole thing doesn't make sense at all. Instead of mindlessly trying to release things as early as possible, what is worth discussing with lead developers and product and project managers is strategy. Does it even make sense?
Patterns and anti-patterns
Oleg: You usually talk about patterns and anti-patterns, and that's the difference between life and death for projects. And now, devops bursts into our lives. Does it have any of its own patterns and anti-patterns that can kill the project on the spot?
Tim: Patterns and anti-patterns happen all the time. What to tell. Well, there is a thing we call "shiny things". People really, really like new technologies. They are simply mesmerized by the brilliance of everything that looks cool and stylish, and they stop asking questions: is it even needed? What are we going to achieve? Is this thing reliable, does it make any sense? I often see people, shall we say, at the forefront of technology. They are mesmerized by what is happening in the world. But if you take a closer look at what they do usefully, often there is simply nothing useful!
We were just discussing with our comrades that this year is an anniversary year, fifty years since people landed on the moon. That was in 1969. The technology that helped people get there is not even 1969 technology, but rather 1960 or 62, because NASA only wanted to use what had good evidence of reliability. And now you look at it and understand - yes, and they were true! Now, no, no, but you get into problems with technology simply because everything is pushed too hard in a row, sold from all the cracks. From everywhere they shout: “Look, what a thing, this is the newest thing, the most beautiful thing in the world, suitable for absolutely everyone!” Well, this is ... usually it all turns out to be just a lure, and then it all has to be thrown away. Maybe it's because I'm already an old man and I look at such things with a great deal of skepticism, when people run out and say that they have found the Only, Most Correct Way to Create Better Technologies. At this moment, a voice wakes up inside me that says: “Well, crap!”.
Michael: Indeed, how often have we heard about another silver bullet?
Tim: Exactly, and this is the usual course of things! For example… it seems that this has already become a joke all over the world, but here people often talk about blockchain technologies. And they do make sense in certain situations! When you really need reliable evidence of events that the system is working and that no one has deceived us, when you have security problems and all that stuff mixed together - blockchain makes sense. But when they say that the Blockchain will now sweep across the world, sweeping away everything in its path? Dream more! This is a very expensive and complex technology. Technically complex and time consuming. Including purely algorithmically, every time you need to recalculate the math, with the slightest change ... and this is a great idea - but only for certain cases. My whole life and career is about this: interesting ideas in very specific situations. It is very important to understand what your situation is.
Michael: Yes, the main "question of life, the universe and everything": is this technology or approach suitable for your situation or not?
Tim: This is a question that can already be discussed with the technology group. Maybe even bring in a consultant. Take a look at the project and understand - will we do something right and useful now, better than it was before? Maybe it will fit, maybe it won't. But most importantly, do not make such a decision by default, just because someone took it and blurted out: “We desperately need a blockchain! I just read about him in a magazine on the plane! Seriously? It's not even funny.
Mythical "devops engineer"
Oleg: Now everyone is implementing devops. Someone reads about devops on the Internet, and tomorrow another vacancy appears on the recruiting site "devops engineer". Here I would like to draw attention: do you think this term, “devops engineer”, has the right to life? There is an opinion that devops is a culture, and something does not fit here.
Tim: So-so. Let them then immediately give some explanation of this term. Something to make it unique. Until they can prove that there is some unique combination of skills behind a job like this, I won't buy it! I mean, well, we have a job title, "devops engineer", an interesting title, yes, what's next? Job titles are a very interesting thing. Let's say "developer" - what is it in general? Different organizations mean very different things. At some companies, high-profile programmers write tests that make more sense than tests written by dedicated professional testers at other companies. Well, how are they now programmers or testers?
Yes, we have job titles, but if you ask questions long enough, you will eventually find that we are all problem solvers. We are solution seekers, and some have some technical skills and some others have different ones. If you live in an environment where DevOps has infiltrated, you are in the process of integrating development and administration, and this activity has some pretty important purpose. But if you are asked what exactly you do and what you are responsible for, it turns out that people have been doing all these things for centuries. "I'm in charge of architecture", "I'm in charge of databases" and so on, whatever, you see - all this was before "devops".
When someone tells me their job title, I don't really listen. It is better to let him tell you what he is actually responsible for, this will allow you to understand the issue much better. My favorite example is when a person claims to be a "project manager". What? It don't mean a thing, I still don't know what you do A project manager can be a developer, the leader of a team of four, who writes code, works the job, who has become a team leader, whom people themselves recognize as a leader among themselves. And yet, a project manager can be a manager who manages six hundred people on a project, manages other managers, is responsible for scheduling and budgeting, that's all. These are two completely different worlds! But their position sounds the same.
Let's turn this around a little differently. What do you really understand, have a lot of experience, have a talent for? What would you take responsibility for because you think you can do it? And here someone will immediately begin to deny: no, no, no, I have no desire to deal with project resources at all, it’s not my business, I’m a technical dude and understand usability and user interfaces, I absolutely don’t want to manage armies of people, let me better go work work.
And by the way, I'm a big proponent of an approach where this division of skills works fine. In which technicians can advance their careers as far as they want. However, I still see organizations where techies complain that I have to go into project management because that's the only way in this company. Sometimes this leads to dire outcomes. The best techies are no managers at all, and the best managers may not be able to handle technology. Let's be honest on this.
I see a big request for this right now. If you're a techie then your company can help you, but regardless, you really need to find your own career path because technology keeps changing and you need to reinvent yourself with it! In twenty years, technology can change at least five times. Technology is a strange thing...
"Experts in Everything"
Michael: How do people cope with such a speed of technology change? Their complexity is growing, the number is growing, the total amount of communication between people is also growing, and it turns out that you cannot become an “expert on everything”.
Tim: Right! If you are in technology, yes, you definitely need to choose something specific and go deep into it. Some technology that your organization finds useful (and may actually be useful). And if you are no longer interested in it - I would never have believed that I would say this - well, maybe you should move to some other organization where the technologies are more interesting or more convenient to study.
But in general, yes, you are right. Technology is growing in all directions at once, no one can say "I am an expert technologist in all technologies that are." On the other hand, there are sponge people who literally absorb technological knowledge, who are crazy about them. I saw a couple of such people, they literally breathe and live it, it is useful and interesting to talk with them. They study not only what is happening inside the organization, but in general, they talk about it, they are also really cool technologists, they are very conscious and purposeful. They just try to stay on top of the wave, no matter what their main job is, because their passion is the movement of Technology, the advancement of technology. If you suddenly meet such a person, you should go to lunch together with him and discuss various cool things at dinner. I think any organization needs at least a couple of such people.
Risks and uncertainty
Michael: Distinguished engineers, yes. Let's touch on risk management while there is still time. We started this interview with a discussion of medical software, where errors can lead to dire consequences. Then we talked about the Lunar Program, where the cost of a mistake is millions of dollars, and possibly several human lives. But now I see the opposite movement in the industry, people do not think about risks, do not try to predict them, do not even watch them.
Oleg: Move fast and break things!
Michael: Yes, go fast, break things, more and more things until you die from something. From your point of view, how should the average developer approach risk management now?
Tim: Let's draw a line here between two things: risk and uncertainty. These are different things. Uncertainty occurs when you don't have enough data at any given point in time to come up with an accurate answer. For example, at the very early stage of a project, if someone asks you “when will you finish the work”, if you are an honest enough person, you will say: “I have no idea.” You just don't know, and that's okay. You have not yet studied the problems and are not familiar with the team, do not know their skills, and so on. This is uncertainty.
Risks arise when potential problems can already be identified. Here's a thing that can happen, its probability is greater than zero, but less than a hundred percent, somewhere in between. Anything can happen because of it, ranging from delays and unnecessary work, but also up to a fatal outcome for the project. Exodus, when you say - guys, we roll up our umbrellas and leave the beach, we will never finish it, it's all over, period. We made the assumption that this thing would work, but it doesn't work at all, it's time to stop. These are the situations.
Often problems are easiest to solve when they are already out, when the problem is happening right now. But when the problem is right in front of you, you don't do risk management - you do problem solving, crisis management. If you're a lead developer or manager, you must be wondering what could happen that causes delays, wasted time, wasted costs, or ruined the entire project? What will make us stop and start all over again? When all these things work, what will we do with them? There is a simple answer that holds true in most situations: don't run from risks, work on them. Look at how you can resolve a risky situation, reduce it to nothing, turn it from a problem into something else. Instead of saying: well, we will solve problems as they come.
Uncertainty and risk must come before everything you deal with. You can take a project plan, look at certain critical risks ahead of time and say: we need to deal with this now, because if any of this goes wrong, everything else will no longer matter. You should not care about the beauty of the tablecloth on the table if it is not clear whether you can cook dinner. First you need to identify all the risks of preparing a delicious dinner, deal with them, and only then think about all the other things that do not pose a real threat.
And again, what is the uniqueness of your project? Let's see what can make our project go off the rails. What can we do to minimize the likelihood that all this will happen. Usually you cannot just take and neutralize them 100% in order to declare with a clear conscience: “That's it, this is no longer a problem, the risk has resolved!”. For me, this is a sign of adult behavior. This is the difference between a child and an adult - children think that they are immortal, that nothing can go wrong, everything will be fine! At the same time, adults watch as three-year-olds jump on the playground, follow the movements with their eyes and say to themselves: “oh - wow, oh - wow.” I stand nearby and prepare to catch when the child does fall.
On the other hand, the reason why I like this business so much is because it is risky. We do things and those things are risky. Requires an adult approach. Enthusiasm alone will not solve your problems!
adult engineering thinking
Michael: The example with children is good. If I am an ordinary engineer, then I am pleased to be a child. But how to move towards more adult thinking?
Tim: One of the ideas that work equally well with both a beginner and an established developer is the concept of context. What are we doing, what are we going to achieve. What is really important in this project? It doesn’t matter who you are on this project, even an intern, even a chief architect, everyone needs context. We need to make sure that everyone thinks on a larger scale than their own pieces of work. "I make my piece, and as long as my piece works, I'm happy." No and no again. It's always worth (without being rude!) to remind people of the context in which they work. What we are all trying to achieve together. Ideas that you can be a child as long as your piece of the project is doing well - please don't. If we pass the finish line at all, we will only pass it together. You are not alone, we are all together. If all the people in the project, both old and young, start talking about what exactly is important to the project, why the company is investing money in what we are all trying to achieve ... most of them will feel much better because they will see how their work correlates with the work of everyone else. On the one hand, I understand the piece for which I am personally responsible. But to finish the job, we need all the other people too. And if you really decided that you finished, we always have work in the project that you can do!
Oleg: Relatively speaking, if you work on kanban, when you hit the bottleneck of some kind of testing, you can quit what you were doing there (for example, programming) and go help testers.
Tim: Exactly. I think the best techies, if you look closely at them, they are like their own managers. How would you phrase it...
Oleg: Your life is your project, which you manage.
Tim: Exactly! I mean, you take responsibility, you understand the subject, and you get in touch with people when you see that your decisions can affect their work, stuff like that. It's not about just sitting at the table, doing your job, and not even guessing what's going on around. No no no. By the way, one of the best things about Agile is that they offered short sprints, because that way the state of affairs of all participants is well observed, they can observe it all together. We talk about each other every day.
How to get into risk management
Oleg: Is there any formal knowledge structure in this area? For example, I am a Java developer and I want to understand risk management without becoming a real project manager by education. I'll probably read McConnell's "How Much Does a Software Project Cost" first, but then what? What are the first steps?
Tim: The first is to start communicating with people in the project. This gives an instant improvement in the culture of communication with colleagues. You need to start by opening everything out by default, instead of hiding it. Say: these are the things that bother me, these are the things that keep me awake at night, I woke up this night and was like: God, I need to think about this! Do others see the same? We as a group, should we respond to these potential issues? You need to be able to keep up the discussion on these topics. There is no pre-prepared formula by which we work. This is not the production of hamburgers, it's all about people. “Make a cheeseburger - sell a cheeseburger” is not about us at all, and that is why I love this job so much. I like it when everything that managers used to do, now becomes the property of the team.
Oleg: You've talked in books and interviews about people worrying more about happiness than numbers on a graph. On the other hand, when you tell the team: we are moving to devops, and now the programmer must constantly communicate, this can be far beyond his comfort zone. And at this moment he can, let's say, be deeply unhappy. What to do in this situation?
Tim: I'm not sure exactly what to do. If the developer is too isolated, then he does not see why the work is being done at all, he just looks at his part of the work, and he needs to delve into what I call "context". He needs to figure out how everything is connected together. And of course, I don't mean formal presentations or anything like that. I'm talking about the fact that you need to communicate with colleagues about the work as a whole, and not just about the part of it for which you are responsible. And that's when you can start discussing ideas, common agreements to make your work fit together well, and how to hit a common problem together.
To adapt techies, they often also want to send them to trainings, they discuss trainings. A friend of mine likes to say that training is for dogs. There is learning for people. One of the best things to learn as a developer is to interact with peers. If someone is really good at something, you should watch how he works, or discuss the work with him, or something like that. Some kind of conditional Kent Beck constantly talked about extreme programming. It's funny because XP is such a simple idea, but it causes so many problems. For some, doing XP is like being forced to strip naked in front of friends. They'll see what I'm doing! They are my colleagues, they will not only see, but also understand! Terrible! Some people get really nervous. But when you realize that this is the ultimate way to learn, everything changes. You work closely with people, and someone understands the topic much better than you.
Michael: But all this forces you to step out of your comfort zone. As an engineer, you have to step out of your comfort zone and communicate. As a problem solver, you must constantly put yourself in a weak position and consider what could go wrong. This kind of work is inherently created to cause inconvenience. You deliberately put yourself in stressful situations. Usually people run away from them, people like to be happy children.
Tim: What you can do, you can go out and openly say: “It's okay, I can handle it! I'm not the only one experiencing discomfort. Let's discuss various uncomfortable things, all together as a team! These are our common problems, we have to cope with them, you understand? I think the idiosyncratic brilliant developers are like mammoths, they disappeared. And yes, they are very limited. If you can't communicate, you can't participate normally. Therefore, just speak. Be honest and open. I am very sorry that this is unpleasant for someone. Can you imagine, many years ago there was a study according to which in the USA the main fear is not death, but guess what? Fear of public speaking! So, somewhere there are people who would rather die than say a compliment out loud. And I think it is enough for you to have some basic skills, depending on what you are doing. Speaking skills, writing skills - but as much as you really need in your job. If you work as an analyst, but at the same time you cannot read, write and speak, then, unfortunately, you will have nothing to do in my projects!
The price of communication
Oleg: Is it not more expensive to use such sociable employees, for various reasons? After all, they are constantly chatting instead of working!
Tim: I meant the core of the team, not everyone in a row. If you have an expert who tunes databases really cool, loves to tune databases and is going to continue tuning your databases for the rest of his life, and that's all - cool, keep it up. But I'm talking about people who want to live in the project itself. The core of the team that develops the project directionally. These people really need to constantly communicate with each other. And especially at the beginning of the project, when you discuss risks, ways to achieve global goals and things like that.
Michael: This applies to everyone involved in the project, regardless of specialization, skills, ways of working. You all have a stake in the success of the project.
Tim: Yes, you feel that you have immersed yourself in the project enough, that your task is to help the project come true. Whether you are a programmer, analyst, interface designer, anyone. This is the reason why I come to work every morning and this is what we do. We are responsible for all these people, regardless of their skills. This is a group of people having adult conversations.
Oleg: In fact, speaking of talkative employees, I tried to simulate the objections of people, especially managers, who are offered to go to devops, to this whole new vision of the world. And you, as consultants, should know these objections much better than me as a developer! Share what worries managers the most?
Tim: Managers? Hm. Most often, managers are under the pressure of problems, before the need to urgently release something and make a delivery, and the like. They watch how we are constantly discussing and arguing something, and they see it like this: conversations, conversations, conversations ... What other conversations? Get back to work! Because conversations for them do not seem like something that looks like work. You don't write code, you don't test software, you don't seem to be doing anything - why not send you to work? After all, the delivery is in a month!
Michael: Go code!
Tim: It seems to me that they are not worried about work, but about the lack of visibility of progress. In order for them to think that we are approaching success, they need to see how we press the buttons on the keyboard. All day from morning to evening. This is problem number one.
Oleg: Misha, you're thinking about something.
Michael: I'm sorry, I thought, I caught a flashback. All this reminded me of one interesting rally that took place yesterday... There were too many rallies yesterday... And it all sounds very familiar!
Life without wages
Tim: By the way, it is absolutely not necessary to arrange “rallies” for communication. I mean, the most useful discussions between developers happen when they just talk to each other. You come in in the morning with a cup of coffee, and there five people have gathered and discuss something technical furiously. For me, if I'm the manager of this project, it's better to just smile and go somewhere about your business, let them discuss it. They are already involved as much as possible. This is a good sign.
Oleg: By the way, here you have a bunch of notes in the book about what is good and what is bad. Do you use any of them yourself? Relatively speaking, you now have a company, and even a very unorthodox one…
Tim: Unorthodox, but such a device suits us perfectly. We've known each other for a long time. We trust each other, we trusted each other a lot before we became partners. And for example, we have no salaries at all. We just work, and for example, if I made money from my clients, then all the money went to me. After that, we pay membership fees to the organization, and this is enough to support the company itself. Plus, we all specialize in different things. For example, I work with accountants, fill out tax returns, do all sorts of administrative things for the company, and no one pays me for this. James and Tom work on our website and they don't get paid either. As long as you pay your dues, no one will think to tell you what you need to do. For example, Tom now works much less than he used to. Now he has other interests, some things he does not for the Guild. But as long as he pays his dues, no one will come up to him and say: “Hey, Tom, come on, go to work!”. It is very easy to deal with colleagues when there is no money between you. And now our relationship is one of the fundamental ideas in relation to different specialties. It works and it works very well.
best advice
Michael: Coming back to the “best advice”, is there anything you repeat to your clients over and over again? There is an idea about 80/20, and for sure some advice is repeated more often.
Tim: I used to think that writing a book like "Waltzing with the Bears" would change the course of history and people would stop, but... Well, look, companies often pretend that everything is fine with them. As soon as something bad happens, it is a shock and a surprise for them. “Look, we tested the system, and it does not pass any system tests, and this is still three months of extraordinary work, how could this happen? Who knew? What could have gone wrong?" Seriously, do you believe this?
I'm trying to explain that you shouldn't get too angry about the current situation. We need to talk it over, really understand what could go wrong and how to prevent such things in the future. If, nevertheless, the problem manifests itself, how will we fight it, how will we contain it.
To me, this all looks scary. People deal with difficult, frustrating problems and keep pretending that if they just cross their fingers and hope for the best, that the “best” will actually happen. No, that doesn't work.
Do risk management!
Michael: In your opinion, how many organizations are involved in risk management?
Tim: What infuriates me is that people just write down the risks, look at the resulting list and go to work. In fact, risk identification for them is risk management. And for me it sounds like a reason for the question: well, there is a list, what exactly will you change? You need to change your standard workflows to reflect these risks. If there is some most difficult part of the work, you need to do it, and only then move on to the simpler one. Start solving complex problems in the first sprints. This is similar to risk management. But usually people can't tell what they've changed after listing the risks.
Michael: And yet, how many of these companies are involved in risk management, five percent?
Tim: Unfortunately, I hate to say this, but this is some very small part. But more than five, because there are really big projects, and they simply cannot exist if they do not at least do something. Let's just say I'd be very surprised if it's at least 25%. Small projects usually answer such questions like this: if the problem affects us, then we will solve it. Then they successfully jump into the problem, and engage in problem management and crisis management. When you are trying to solve a problem and the problem is not being solved, welcome to crisis management.
Yes, I often hear, "we will solve problems as they come up." Will we really? How about we decide?
Oleg: You can do it naively and simply enter important invariants into the project charter, and if the invariants break, just restart the project. It turns out very piembuchno.
Michael: Yes, it happened to me that when the risks worked, the project was simply redefined. Nice, bingo, problem solved, no more worries!
Tim: Let's hit the reset button! No, that doesn't work.
Keynote at DevOops 2019
Michael: Let's get to the last question of this interview. You come to the next DevOops with a keynote, could you lift the veil of secrecy on what you are going to tell?
Tim: Right now, six of them are writing a book about work culture, the unspoken rules of organizations. Culture is defined by the core values of the organization. Usually people do not notice this, but we, working in consulting for many years, are used to noticing it. You walk into a company, and in just a few minutes you begin to feel what is happening. We call it "flavor". Sometimes this flavor is really good, and sometimes it's, well, oops. It's very different for different organizations.
Michael: I have also been working in consulting for years and I understand well what you are talking about now.
Tim: Actually, one of the things to talk about at keynote is that not everything is determined by the company. You and your team, as a community, you have your own team culture. It can be either the whole company or a separate department, a separate team. But before you said: this is what we believe in, this is what matters... You cannot change a culture until the values and beliefs behind specific actions are understood. Behavior is easy to observe, but beliefs are hard to find. DevOps is just a great example of how things get more and more complicated. Interactions only get more complex, they don't get clearer and clearer at all, so you should think about what you believe in and what everyone around is silent about.
If you want to get quick results, here's a good topic for you: have you seen companies where no one says "I don't know"? There are places where you have to literally torture a person until he admits that he does not know something. Everyone knows everything, everyone is incredible erudite. You approach any person, and he has to instantly answer something to a question. Instead of saying "I don't know". Hooray, they hired a bunch of erudite people! And in some cultures it is generally very dangerous to say “I don’t know”, it can be perceived as a sign of weakness. There are also organizations in which, on the contrary, everyone can say “I don’t know.” It’s perfectly legal there, and if someone starts rubbing game in response to a question, it’s perfectly normal to respond: “You don’t understand what you’re talking about, right?” and make it all a joke.
Ideally, you would like to have a job where you can be happy all the time. It won't be easy, not every day is sunny and pleasant, sometimes you have to work hard, but when you start summing up, it turns out: wow, this is really a wonderful place, it's good for me to work here, both emotionally and intellectually. And there are companies that you enter as a consultant and instantly understand that you would not have survived even three months and would have fled in horror. That's what I want to talk about in the report.
Tim Lister is coming with a keyout to the DevOops 2019 conference, which will be held October 29-30, 2019 in St. Petersburg. You can buy tickets . Welcome to DevOops!
Source: habr.com