Allen Holub was our special guest.
Video is here.
Allen’s Twitter is @allenholub.
Transcript
[00:00:00] Yegor: This is a Shift-M podcast, I record this podcast for a few years already, and every time I try to invite somebody who’s famous and who knows something about management more than I do. And our guest today is Allen Holub who is first of all a software engineer, that’s how I met Allen many years ago when I read articles about object-oriented programming written by Allen. And he’s also an author of a few books about Java and C++ programming actually, but now I think Allen is an expert in management, even though I think Allen would not agree with this word, and I think that’s what we’re going to talk about today, the management work. So Allen, introduce yourself in a few words and then I’ll shoot you with the first question about management.
[00:00:44] Allen: Seems like you just did it. You know I’ve been doing this since dinosaurs roam the Earth. I’ve done a lot of writing, written a bunch of books, and wrote for Dr. Dobbs for ages. Currently I’m working mostly in the Agile space, helping companies get better at it, helping companies adopt it, I don’t like to use the word “Agile transformation”, I think that’s kind of ridiculous, it’s not like somebody sprinkles magic Agile fairy dust over a company and they turn into the Agile pumpkin, it’s a gradual process, so I kind of help people make that transition, if you will, if they want to do that. I do it in a very non-partisan way, if you will, I don’t really hold much truck to the various frameworks, I don’t think they work, so I process agnostic about them. So anyway, that’s me.
[00:01:35] Yegor: That’s great, yeah. I read your Twitter a lot and actually I was preparing for this interview, and I collected many of my questions from your Twitter and from your videos. So my first question is that I see that you oppose productivity versus creativity, so it seems that you think that there are two different things and they cannot go along. So what do you think about this? Сan you elaborate on this?
[00:01:59] Allen:: I don’t think they’re different. What I oppose is the notion of productivity, and to use the idea of productivity as a driver. In other words, if people are trying to be productive, they usually do things that make them less productive, right? They collect metrics that are the wrong metrics, as soon as you start collecting metrics, people’s behavior will change in order to optimize those metrics, so if you’re collecting the wrong metrics, you become less productive, you know, for example is that usually people define productivity as output, so you start collecting metrics for output, and people say “Oh gosh, I’ve got to start producing more or else I’m in trouble”, and they start producing more and more and more stuff, but the stuff has less and less value to your customers, so yeah, you’re producing more output, but you’re producing less value, and the fact that you’re producing less value means you’re going to lose those customers, and the whole company will fail. So the idea of pushing productivity as the main thing is I think contraindicated, instead I think that if you do things in a reasonable way, in a natural way, the productivity will take care of itself. If you always build the most valuable thing next, if you talk to your customers in order to figure out what valuable means, if you implement in small chunks, - right? - deliver every day or two and get feedback constantly, and all of those things reduce working progress, the amount of things that you’re working on at once, you bring that into one, so you can focus. If you do that, productivity will just take care of itself, it’s not something you have to worry about. So, I think the organizations that are focusing on productivity are not focusing on things like value to the customers, which is the most important thing to be focusing on. It’s harder to focus on value to your customers, you have to actually talk to them for one thing, and a lot of companies don’t seem to want to do that for some reason, but it drives everything, that’s the most important thing and if you’re not producing something valuable, then you’re not producing something that’s going to sell, and the company will fail.
[00:04:10] Yegor: Who do you think we are, software developers, like I am a software engineer, so who do you think we are - more like creative people, artists, or we are craftsmen, like we do things, manufacture things, or instead we create things?
[00:04:23] Allen: I like the word “craftsperson”, it’s somebody who uses their hands to make things of value. And that’s not art though. People make a distinction between crafts and art, and I don’t make that distinction - it’s all art. It’s just that things that are crafts have utility, you use them for something. And if it’s pure art, it has aesthetic value, it’s definitely worth producing, but you know we are working for companies who are in the business of making money, which means that we have to produce tangible things that people can actually use, that solve their problems or we won’t succeed at being a company. But that doesn’t mean we’re not artists, it just means that our art is focused on the practical rather than just the pure aesthetics. And I see nothing wrong with that. You know what, we are not engineers, I really don’t like that word “engineering” applied to software development, we don’t do anything like what other engineers do. Engineering for the most part involves applying mathematics to analyze structures before you build them to make sure that they’re gonna not fail. And we don’t do that, we don’t do anything like that, we don’t apply mathematics to what we’re doing, not really, software has almost nothing to do with math, in fact, if you think about the math that you use in programming, a little boolean algebra, a little bit of statistics, a little bit of very simple statistics, some set theory, right, so you could cover this stuff in a one semester class easily, but you’d actually cover it in one semester class and have time left over. And we’re not mathematicians, we don’t do math, you know, there are domains that are mathematically focused, but that’s just a domain like any other domain, right? If we’re building accounting software, we’re not accountants. If we’re building some piece of software that relies on mathematics, we’re not mathematicians, we rely on actual mathematicians to explain the domain to us. So engineering is all focused on math. If you take an engineering program, a lot of it is math, not just calculus, but beyond calculus typically you need two years of pretty serious mathematics requirements to get an engineering degree, and that’s because in every real engineering discipline math is at the core of it, it’s at the center of it, it’s what they do. It’s not what we do, so I don’t like the idea of calling us software engineers, we’re software craftsmen - I’ll buy that, developers - I’ll buy that, programmers… all that makes sense. But “engineers” does not make sense to me, what we’re doing is not engineering.
[00:07:11] Yegor: I totally agree with that, but when we tell programmers that there is some creativity in their work, then they start thinking about themselves not as craftsmen, not as programmers, but as people who are supposed to be artists, and that actually kind of make difficult for managers, I mean for people who have to control how the group of programmers works, to motivate them for actually producing some value, because they start saying that they’re creative people, artists here, so don’t touch me, give me another year, I need to think about something…
[00:07:44] Allen: I’ve never seen that. Have you actually seen that? I haven’t. People aren’t like artistes with their berets and “Oh I’m such a delicate personality, I can’t do anything but my art” - people don’t do that. It’s just not true, you know, people who are the manager types that you just described, if they don’t care about the art, what do they care about? Output?
[00:08:08] Yegor: Output? Correct?
[00:08:11] Allen: Yeah, also I can prove… what is output? Spending time very efficiently, producing stuff that nobody wants, that benefits nobody, output has got no value, it’s not a useful thing to measure. Well, you have to have output of course, but if you’re not outputting the right thing, then you have achieved nothing useful, and optimizing output is easy. You trust people to make decisions, if you take away all of the things that are in the way of their productivity, they will become more productive. And usually managers that are focusing on output are not doing that right, they’re creating delays.
[00:08:52] Yegor: You really believe that if we just take away all the problems from the people, they will just start producing things because they naturally want that? Is it really you believe that?
[00:09:02] Allen: Well, programmers do. Programmers program in their own time, you know, they like to do it, it’s fine. The thing is that the thinking of programmers as uneducated assembly line workers who are essentially lazy and have to be forced into working - that’s craziness, right? And too many companies still do that, they say they don’t, but if you look at their behavior, they do. That’s not going to work, it’s just not going to work. Look at Toyota. Toyota doesn’t do any of the things that you’re describing, it’s that the people who are making the decisions in Toyota are the people on the assembly line, not managers. The managers have given them a strategic directive - we need you to work as effectively as possible - and they’re a leading company, so they say, and the way to do that is we need you to really focus on eliminating waste. And they do that, with enthusiasm. And by eliminating waste the company becomes more profitable, I don’t know if I want to use the word productive, but they become more profitable, because money that used to be wasted is now no longer being wasted. But it’s the people on the assembly line that are doing that work, it’s not some manager sitting in some ivory tower collecting information and dictating what people need to do in order to be more productive, it’s the people on the assembly line figure out how to be more productive.
[00:10:27] Yegor: I’m sure you would agree that some people are more productive, some people are less productive, right?
[00:10:31] Allen: No. I think some people can program faster than others, whether they’re more or less productive, it’s another matter entirely. Productive, again, that’s nothing to do with output, it has to do with producing value, so if somebody is working fast and not producing value, they don’t achieve anything. The other issue is that productivity is a function of the entire system, not of an individual, so if you have one guy that can work 10 times faster than everybody else and even if they’re producing vast piles of code, if that code’s not being released because the rest of the system doesn’t allow it to be released, they’ve achieved nothing, it’s a complete waste of time. So what those people should be doing is not spending time producing huge piles of stuff that’s not being released, right? The leading people call that inventory, and what they should be doing is teaching other people how to become better at what they do. So this notion of the super programmer and you leave him alone because he’s so productive - that’s craziness, because they’re not moving the company forward. So having somebody who’s really-really good is of course valuable, but if you don’t leverage that person as a mentor and a teacher, they won’t provide much value to you as a company.
[00:11:42] Yegor: But you probably know this very famous quote of Robert Glass that he said many years ago, that the difference between an average programmer and the top programmer, the best programmer is like 30 times, and there are other people saying some similar things, like the difference is not 20%, not 50%, but like a hundred times, or fifty times better, the best programmer is, I don’t know, faster, or more productive, I’m not sure about that.
[00:12:07] Allen: Well yeah, let’s talk about what “best” means there, before we start talking about those numbers, right? And again, this was back when he said that, the model was that a programmer was some mysterious person and you put them alone in an office and threw meat under the door occasionally and they produced stuff, and that’s not the way it works. Programming doesn’t work that way. Programming is a social activity. The best programming shops that I know are doing things like mob programming, they’re doing things that are highly social in nature, and the model of somebody sitting alone working by themselves, being productive is a failed model in my opinion. It’s one of the things that I really hate about the work-at-home stands, that have been very vocal in the last year for obvious reasons. I see nothing wrong with working remotely, provided that you’re still collaborating, but to think that working remotely means “Oh, now I can work at home and I don’t have to talk to anybody, just leave me alone” - I think that’s really, really, really counterproductive. I don’t think it’s productive to do that. And I don’t care how fast you’re working. If you’re leaving the team behind, you’re not delivering, what matters is how fast you can get something of value into your user’s hands, and if you have a bunch of people running in a line, having somebody in the middle run faster doesn’t help, because they’re going to bump up against the person in front of them and that’s the end of that. It’s what matters is the speed at which the whole line is moving, not the speed at which one person is moving, so I just don’t buy that argument, it’s based on a faulty model of what programming is, and of what programming should be doing in terms of producing value, and you know it’s easy, it’s lazy to think that way, because you can measure productivity in some ridiculous way like lines of code per day, it’s stupid, but people do it. So the manager can be lazy. If you look at Jira, for example, Jira has all these features in it that are designed to support this kind of dysfunctional laziness. You can measure the number of points an individual programmer produces per sprint, that’s just insanity! The person who’s providing the most value to your company by working on the hardest problems, are probably not producing very many points per sprint, because the problem they’re working on is really hard, but if you don’t solve that problem, the company will fail, because you’re not providing any value to your customers. So those kinds of measures are just ridiculous, I just really don’t like them. I think they drive companies towards failure.
[00:14:47] Yegor: But you’re against any measurements or this specific set of measures?
[00:14:49] Allen: No, there are some measurements that are useful, the leading measurements, if you read Nicole Forsgren’s “Accelerate”, she talks about 4 or 5 measurements, 4 of core ones, that can help you. She uses the word productivity, we’ve had discussions about that, is that she takes umbrage at me not wanting to use the word, but you know that sort of stuff things like throughput for example, or cycle time, or lead time, lead time is probably the better metric. Lead time is the time it takes an idea to get into your customers hands, and that’s a valuable thing to measure, sure. But you have to use the measurements very-very carefully, and most of those measurements should be things that the teams measure, so that they can improve themselves. As soon as the measurements leak into a dysfunctional management hierarchy, they’re going to be used for evil, they’re going to be used to do things that probably slow the teams down in the long run. Some of those measurements are valuable, throughput in particular is I think a valuable measurement, it’s how much time does it take to produce a story. And, you know, measure stories delivered per week, it’s a pretty good measurement. And if you’re delivering a lot of stories per week, it’s telling you useful things, it’s saying the stories are small enough, it’s saying that you’re working in an effective way. The supposition there though is that the stories are describing valuable work, so if this is just producing the maximum number of stories per week is of no value to anybody, if the stories aren’t producing something that your customers find useful. So the metric can’t stand alone, you can’t just look at the metric and say “Oh, we’re okay” - there’s all these qualifiers around the metric that you have to look at to see if the metric is measuring what you actually want it to measure. And ultimately it comes back to value. I think value is the important thing. And that’s not something you can measure necessarily, it’s that people often misquote Deming, they say “Well, if you can’t measure, you can’t manage it”, that’s the middle of the quote, right? Deming starts that off by saying “it’s a myth that what you can’t measure, you can’t manage”, he says it’s destructive to be thinking that way, and that many things that are important are things that you cannot measure. And I agree with that completely, so, you know, I don’t know where the measurement stuff comes from, I think it comes from manufacturing, it comes from assembly lines, where measuring can make sense, right? But we’re not doing that, we don’t work on assembly lines.
[00:17:22] Yegor: Yeah, but let’s try for a different angle. What’s your attitude to competition in the team? Let’s say you are the manager or the product owner…
[00:17:30] Allen: Bad idea. Competition in the team is a really bad idea.
[00:17:33] Yegor: Bad idea?
[00:17:34] Allen: Yeah, if you reward somebody because they’re the winner, they’re going to do everything they can to make sure that they remain the winner, including withholding information from other team members that they need to be effective. If you have competition on the team, what you’re doing is rewarding people for not helping other people. And that means that the team as a whole is going to be very ineffective. The way to get an effective team is through collaboration, not through competition. Competition is extremely destructive. The other thing about competition that’s important is that not only will people not help each other, but they’ll be arguing with each other all the time, because they want to win, they want to be the people that have the great idea, and that’s destructive. That means the person with the loudest voice ends up making all the decisions and that person is rarely the best person, right? It’s a team of people, eight brains, can always be smarter than one person, and when you have a competitive environment, you’re setting things up, so that you can you’re not collaborating, you can’t collaborate.
[00:18:39] Yegor: But some people like to win, they can’t live without that.
[00:18:42] Allen: They’ve got no business being on software development teams then, I don’t think that everybody on the planet has an aptitude for software development. If your personality is one that’s disruptive, then you have no place on the team, I’m sorry. And we don’t have to accept everybody into the profession, if somebody’s gonna be actively destructive, you know, what value do they provide on the team, if they’re being actively destructive?
[00:19:15] Yegor: And you think that the necessity, the willingness to be better than everybody else is actually the characteristics of being destructive for the team, right?
[00:19:24] Allen: I think it can be, absolutely. Now, how do you channel that ego, if you will, for lack of a better word, and if you channel it is as competition, it turns into somebody who won’t help anybody else, who is doing stuff that nobody knows about, so if they take a vacation - you’re stuck, you can’t fix anything that’s in their system, who go off and do bizarre architectural things that don’t integrate properly with anything else because they thought in their ego, that it was somehow better, and so on and so on. If on the other hand that person is saying “Yeah, I’m better than everybody else, so let me help everybody else get as good as I am”, then you’ve got somebody valuable. And so just thinking “I’m better” - that’s not a problem. The problem is thinking “I’m better and I won’t help anybody else get better, because I’m competing. If I help anybody else get better, I’ll lose”. The competition is not good.
[00:20:23] Yegor: How are you going to make the decisions, like money decisions - who gets the raise, who gets the bonus, what about that?
[00:20:26] Allen: I think raises should be done by formula, the idea of merit raises are again actively destructive, because you’re effectively punishing everybody else on the team, and you’re not rewarding one person you’re punishing six people. And there’s been a lot written on that, there have been volumes, thousands of pages written on how destructive performance bonuses are, and people for some reason ignore all that literature, it’s all there, the studies are all there. But the way Spotify does it, I think is interesting, they have a matrix, numbers across the top, and down one side are characteristics that the company values. You help one another, you’re creative, you’re excited about what you’re doing, all the things that people value. And you fill out the matrix and then put check marks where you think you are, and then the team looks at it and the team says “You know, you put this check mark over here at eight, I don’t think you’re an eight”, and you discuss it and once everybody is satisfied that the matrix is correct, they just run it through a formula and that’s your salary. And that’s great, it means that you don’t have gender bias, it means that somebody is not being punished because they’re not good at negotiation, it means that somebody who’s being actively destructive, but is perceived by some manager as a good guy is not making more money than somebody who’s being actually productive… It’s a better system all around. This notion of some manager deciding what people should buy based on some criteria should get paid based on some arbitrary criteria that they have in their head - that’s just a recipe for bias, and it’s a recipe for getting people angry, because the people who are quiet but highly productive, who are getting paid less because they’re quiet, are going to be angry, and you think they’re going to do good work if they’re angry all the time? No. In fact, they’re going to leave eventually and employee leaving is a huge problem, it’s very expensive. I can guarantee you that one, quote, “mediocre programmer” leaving is going to cost you more than any savings you’ll get from one super programmer. And you can’t have that situation.
[00:22:42] Yegor: I totally agree and it seems that what you just described looks to me like this spreadsheet where we have these marks and numbers from people demonstrating their productivity. It looks like a KPI for me, like key performance indicators, so we put all the indicators and then we put it together, calculate and the manager doesn’t make any decisions, we just know who’s more productive. I think that’s what you’re trying to demonstrate.
[00:23:02] Allen: Well I don’t believe in KPIs either, we don’t know from KPIs who’s productive. And more to the point I don’t think that an individual can be more productive than the team as a whole is, it’s not possible, what matters is the rate at which the team is producing software. So you can’t look at individuals, you’ve got to look at the team. And even a team can’t be productive if they’re in an organization that stops them from being productive, so if the team is required to run all their code through some operations department before it’s deployed, and the operations department is running slowly, then the team is not productive anymore, because ops is slowing them down. So this whole productivity thing is a trap. I just don’t buy it, it’s that the companies that focus on productivity destroy productivity.
[00:23:54] Yegor: What’s the job of the manager of such a team? Let’s say we have this team which we don’t measure productivity, so what is the manager doing there?
[00:24:01] Allen: If they’re Agile, they don’t have managers. Agile teams are self-organizing, they manage themselves, they manage their own work. So this notion of having managers around with a so-called Agile organization, what’s that about? It says right there in the Agile Manifesto - it’s a self-organizing team. So I still have managers around, that’s because you used to need managers, because you imagined that software was built on an assembly line, and you have so little imagination that you cannot conceive of a world where these managers don’t exist.
[00:24:30] Yegor: Yes, it’s a habit, you know, and generally speaking, in a fully Agile organization you need no team level management at all, no so-called line management. You’ll need a few people who are coordinating the teams up above the team level, and I suppose we could call them managers, if we want to, but you need very few of them, you don’t need this like one manager for every six people ratio that most companies have, that’s just nonsense. Of course the teams should be managing their own work, so part of learning to be Agile is to learn how to do that. So there will be a role for people who are currently managers to teach people on teams how to manage themselves, but if some manager’s personality is a control personality, defines management as ordering people around, they’re not going to want to teach people stuff. For those reasons we’re just discussing, we’re back in the competition world. And so if you’re going to transition to Agile, dealing with those line managers is a big deal. Most of them are going to go, a lot of them will have useful work to do at first, because they have to train people how to do their job, but once that happens you’ll need very few of them, you’ll need a few coaches around, that will help the teams, so if an organization is going to transition smoothly to Agile, they have to address that problem, you can’t just say to the line managers “You guys, we have no use for you”, because they’ll do everything, and they can possibly can, to keep their jobs, they’ll prevent agility from happening. So you have to do things like say “Okay, we’ll actively find you a job, we’ll keep you on the payroll until we find a job for you, and it’s our responsibility to find those jobs, not yours” - so that you can keep people motivated, otherwise you haven’t achieved anything. You can’t achieve anything.
[00:26:22] Yegor: And who is responsible for the result? Let me rephrase the question: traditional model - the management is hierarchical in traditional company, and the managers on the above, they expect people from beneath them to stand up in front of them once upon a time and answer for the time, for the budget…
[00:26:40] Allen: What does that mean? They’re standing over the team with a whip? That’s abuse, what you’re describing is a kind of abuse, so i’m gonna hold you responsible for what your team is doing, and of course you have no control over that, right? They’re working on a hard problem, it’s going to take longer than I think it should take and you have no control over that, and in fact nobody has any control over that, because the problem is too hard - but I’m going to beat the shit out of you, if you don’t do what I tell you. I don’t want to work for a place like that, it’s craziness.
[00:27:12] Yegor: But that’s reality everywhere.
[00:27:14] Allen: That’s not reality everywhere, look, it’s not reality in Agile organizations. You know, a lot of people reject Agile, because they say “Well, it’s not a real world thing”. If you read Larman’s Laws of Organizational Behavior, just google “Larman’s Laws of Organizational Behavior” and you’ll find them, they’re on Craig’s Larman website. But the issue here is that as soon as somebody starts talking about, well, in the real world that’s an excuse for not experimenting with changes, it’s an excuse for not making any changes, it has nothing to do with the, quote, “real world”, as I know, I can give you plenty examples in the real world where people do not have that kind of abusive management that you’re describing, and the companies are highly successful. It’s not a requirement, it’s because people have no imagination, and there are lots of reasons there. But it has nothing to do with the force of nature, it’s not a law of nature, that people have to abuse one another in order to be productive.
[00:28:13] Yegor: Well, I agree about the abuse, but we can put another word here - “consequences”. And when you start working on something and you fail, then there have to be some consequences and people sometimes have…
[00:28:23] Allen: Why? So what you’re doing is you’re saying “I’m going to set up a world war, I’m going to punish experimentation, I will punish creativity”, because if you do something creative and it doesn’t work out, there will be consequences for that, so people are going to go “I’m never going to be creative around you”. You really want to punish creativity?
[00:28:42] Yegor: That’s why I started with the question - do you think we’re producers, we are craftsmen, or we are creative artists, and you said that “No, we produce value, we write code”, so in most cases programmers are not actually creating something experimenting, they’re actually writing code to produce some real value for the business.
[00:28:59] Allen: So how is that not being creative?
[00:29:00] Yegor: Yeah, they are creative of course, but in most cases the work is pretty well defined…
[00:29:08] Allen: No, it’s not. Agile is based on the notion that the work is not defined, that we don’t know that we’ve done the right thing until we get it into our customers’ hands and talk to them. Everything that an Agile team produces is an experiment, everything, every line of code. And you run the experiment by producing a little piece of software and giving it to your customers and seeing what they think about it. And if the customers don’t like it, you have succeeded in determining that they don’t like it, and you go do something else. There’s no failure there. Everything is an experiment, so to argue, well, we’re just doing what we’re told and we’re producing this thing that we designed upfront, well, that’s Waterfall thinking, right? That we have some magical power that allows us to determine upfront exactly what the customers need. Agile is based on the idea that that’s not possible. It’s fundamental to thinking it natural.
[00:30:05] Yegor: Yeah, but I think you would agree that some people are just lazy, that’s it.
[00:30:09] Allen: I don’t buy that at all, no, some people are doing the wrong job for them, somebody is really good at something and they’re being forced in their work to do things that they’re not good at. i’ll buy that. I’ll buy that people are confused and in the sense that nobody has ever sat down and explained to them how things work, so they’re just stumbling around. I’ll buy that some people need to learn, that they need somebody to sit down and help them and mentor them and teach them how to do things and because they don’t know stuff, they spend a lot of their time in google, for example, trying to figure things out, because nobody will help them. I believe all that. I don’t believe that people are lazy.
[00:30:58] Yegor: It makes sense actually, but still you said that they may become lazy for some reason, so for example the person has no enough information, that’s why he starts…
[00:31:06] Allen: That’s not laziness, no.
[00:31:08] Yegor: It’s not laziness. I agree. But in the end we have no results from this person.
[00:31:13] Allen: So, you help them. You solve the problem by solving the problem. If they’re not productive because they don’t know things, then you need to teach them those things. If they’re not productive because they’re doing the wrong sort of work, you need to have them doing the right sort of work for them. That’s what good managers do. We’re talking about the good ones. It’s they look at people and they say “You know, you’re in the wrong job, you’re clearly not happy. What do you really like to do? What would you be happy doing?” And then let’s make sure that they can do that. I think it’s useful to have people like that around, I wouldn’t make them team managers, I’d make them coaches. But it’s not laziness though, this idea of lazy people, that’s we’re getting back to 1900 taylorist assembly line models, where we’re hiring uneducated lazy people and we’ve got to be beating them all the time in order to make them productive. It’s just a Fault-Failure model. There’s no value in that model at all. So no, there aren’t any lazy people. I don’t see any lazy people, I never see lazy people.
[00:32:22] Yegor: Okay, but we still understand that business has some constraints, right? Because businesses, they have some budgets, they have some time, so we cannot just do experiments forever, so they have some restrictions. And we have to work within these restrictions.
[00:32:39] Allen: We haven’t restrictions about experimenting when it comes to delivering the software. I think we’ve proven pretty thoroughly that trying to figure out everything upfront doesn’t work. I think that’s pretty well understood at this point. So that means that everything is an experiment, it means we’re learning as we’re working. So if you say “Oh, we don’t have time to experiment, we won’t do that, we’re just going to decide and then spend the next six months doing it”, well, that’s fine, that’s Waterfall, though. And the odds of producing something that nobody wants to buy are very high, when you work that way. And you won’t know whether they want to buy it until you’ve already invested in six months of labor. As compared to an Agile approach where you’re saying “Well, let’s experiment and see what they want to buy, figure it out as we go, and then if we fail, we’ve only lost a week’s work, we haven’t lost six months or six years, we’ve lost a week. And we’ll build something that they do like, right?” It’s that it’s a much more effective way to work.
[00:33:33] Yegor: So you’re against estimates at all, or you are suggesting some different form of estimates?
[00:33:39] Allen: Well, to run a business you need to make projections. What I object to is the kind of estimation that is the definition of “estimate” that people usually use when they say the word. From my point of view, when people say the word “estimate”, what they say is we’re looking at a specification and we want to make a projection about how much time it’s going to take to implement this specification. And they’ll do that by analyzing the specification and coming up with lists of tasks, and you know all the things that people do when they estimate. I don’t think that’s ever a good idea, because I don’t think you can have an accurate specification. Now, projections about where you’re going to be in a certain amount of time, you need that in order to run the business. But you can do that by looking at the work, rather than specifications of things. So if you if you say, for example, on average we see that the teams across the organization are implementing two stories a week. We can make projections from that without having to know anything about what those stories are. Those kinds of projections I think are essential, you need to be able to do that to run the business. But I don’t see those as estimates, because they have nothing to do with the specification. So I use the word “projection” for that. No estimate trolls really take obsession to that, they say “projections and estimates are the same thing, and I’m going well, I don’t use that word, I use them in the same way”, and then they discount that, they say “Well, you’re an idiot for not calling them the same thing”. But I divide the world though into predictions that you’re making based on analyzing the work and assuming that work will continue at about the same pace that it continues now. And predictions that you make by analyzing specifications of things, I see this as two different activities, and I find very little value in the first.
[00:35:29] Yegor: And what do you recommend people to answer to their managers which they have right now? Most people have managers still. So what do they tell those managers when they ask them “When you’re going to finish this” or “Will you be able to finish this before the end of the year?” So, what do you recommend them to answer?
[00:35:37] Allen: You know, my answer to that personally has always been “I don’t know”, and if they don’t like it, they can fire me, I’m not gonna be held to some guess, somebody saying “You tell me when you’re going to be done with this and I’m going to hold you to that” - that’s an abusive thing, you’re saying “Give me a number that you can’t possibly predict. And if you guessed wrong, I’m going to punish you”. I don’t want to work for a place like that. So even at the CTO level I’ve been the CTO for startups a couple times, and my CEO would say “When will we have this done?”, and I’ll say “I don’t know, it depends on a lot of things, I’ll give you progress reports every week, I’ll show you software, you can play with it, see if it works or not, but predicting when it will be “done” - I have no idea”. You know, people, they object to this on ridiculous reasons, they say “Well, if I was building a house, I wouldn’t accept that, I’d say to the contractor when all will be done”. Well, I know a lot of people who have built houses, I don’t know a single one that’s come in on time or in budget. So yeah, you can fool yourself, you can live in some fantasy world where you imagine that these guesses are going to be real, but they never are. So if you insist on it what happens, you insist on it, you’ve got to come in on time and budget, you’ll be punished, you say that to the contractor, so the contractor will say “Okay, here’s a fixed price bid, which is probably four or five times higher than it would be if they were working time and materials”. So you pay for that certainty. You go to programmer and you say “I need to know exactly when this is going to be finished”, and they’re going to do one of two things: they’re either going to be honest and say “I don’t know”, or they’re going to know that they can’t be honest and they’ll pad out the estimate by a factor of, if they’re intelligent, six or seven or ten, something that will guarantee that they’ll be able to do it right, it’s this notion of always deliver early. Well, what does that really mean? What that means is that always produce padded estimates, always produce estimates that are so much padding in them, that you have a high up probability being able to deliver before the estimate. So what do you do with the rest of that time? The guy who’s just made this estimate that it’s going to take six months, and it takes a week. So what do you do with these other five and three-quarter months? And you could say “Well, we’re done, let’s move on to the next thing”, or you could say “Oh gosh, if I say six months and it only took a week, I’m gonna be from this point forward every time, I give an estimate they’re going to say it’s going to take a week, and not what you said, so I better not take a week, so they spend the next five months doing whatever they feel like, just to bring the time out and then they deliver a little bit in advance of the six months, a week or two”. So you get inefficiencies.
[00:38:39] Yegor: Yeah, I can explain what many managers think in this situation, if I would be, you know, the traditional manager that comes to programmer and asks how long will it take. The programmer says “I don’t know, I will keep working and I will send you reports just like you expected”.
[00:38:54] Allen: You don’t send them reports, you deliver the software. That’s a big difference. Generally I find that when a team is delivering software that you can put your hands on and use, every couple of days people stop asking that question. They stop saying “When we will be done”, because they can look at the progress themselves, they can make their own projections if they want to. The situation you’re describing is a situation where the process is completely opaque, we don’t know what the progress is going to be, so you want some kind of assurance because you have no idea what progress is going to be. When you can see the progress, you don’t need those assurances anymore, the fact that this progress is your assurance.
[00:39:37] Yegor: Most managers I think will think that if there is no deadline for a programmer, then the programmer will be lazy.
[00:39:44] Allen: They’re wrong, on every front. I don’t think most managers think that though. I don’t think they’re good managers. I think what you’re describing is a really awful person and a really awful manager. And yeah, maybe there are companies that have people like that, but they’re not effective as managers.
[00:40:05] Yegor: But isn’t it true that if there is no deadline, then you will take as much time as you can? No?
[00:40:10] Allen: No.
[00:40:11] Yegor: You personally. No? It doesn’t work for you? Like, for me it works, I think. If there’s no deadline, I will work and work and work and nobody can stop me, but if I know that…
[00:40:18] Allen: That’s if you’re working in Waterfall way. If you don’t need a deadline, you say “Okay, here’s a couple days worth of work, so I’m going to do that, and when I’ve done it, I produced something valuable”. You’re describing the situation where you work for weeks and weeks and weeks and never produce anything valuable. Well, that means you’re not delivering. So if you deliver frequently, you solve the problem.
[00:40:44] Yegor: Yeah, makes sense. So you’re saying that we need deadlines only if the process has no intermediary results?
[00:40:54] Allen: I don’t see that we need deadlines at all. Every so often we have deadlines that are out of our control. Regulatory deadlines, something that has to be done by Christmas, and so deadlines exist, but we can’t say “I’m going to produce exactly this specification by this time”. Well, let’s figure out what’s most important, if it’s a regulatory deadline, there are some things that we need to do in order to satisfy the regulation, and there’s other things that we need to do that are not regulatory, but are important, but they’re not regulatory. And then we do all the regulation related stuff first, so that’s done, so we don’t have to worry about the regulators now. And then we can do the rest of the stuff at whatever pace we can do it, and we need to do it. But the meeting, the deadline typically has to do with assessing the value, with taking a big thing, breaking it up into small things, assessing value, sorting by value, and doing the most valuable thing first. Now, if you can’t even do the most valuable things by the deadline, then there’s no way of working that would have fixed that. It’s that it’s not a solvable problem. And you can’t beat people harder and expect them to somehow be more productive, that doesn’t work. Brook’s law tells us that usually we can’t hire people, if we hire them early enough, we might be able to do it, but hiring people late in the project makes it later, it doesn’t help. So, in that situation you’re just screwed, there’s no way to rescue that, but that’s not an Agile vs non-Agile vs deadlines vs non-deadlines issue, it doesn’t matter if you have the deadline, if you can’t do it - you can’t do it. So the problem is this deadline thinking. So if a deadline is not absolutely mandated by the outside world, then it’s a bad thing. Often deadlines are things that people produce for themselves, that have no connection, if you will, to reality, often it’s built into a contract, because people are thinking in terms of deadlines when they put a contract together, it doesn’t have to be, you know, you can have a Waterfall contract, it says here’s the scope of work and we’ll have it done by this date, or you can have an Agile contract, you can say we’re trying to satisfy these strategic goals and every week we’ll sit down and figure out what the next thing to do to move towards that goal, and every week we will deliver whatever we built last week, and you’ll take a look at it and tell us what’s right and what’s wrong, and we’ll move in the direction of the goal. The contract can specify that just as easily as it can specify a deadline. So if you’re going to work in an Agile way, you’ve got to pick customers who are willing to work in an Agile way. You have a customer that wants you to work in a Waterfall - you cannot be Agile in that environment, so you either have to pick your customers, or educate them, or not be Agile - those are the options.
[00:43:51] Yegor: In one of your presentations I saw on youtube, you were analyzing the chaos report, and you’re saying that the percentages, the statistics they give there are not accurate, because the numbers are correct, but the root cause of these numbers is different. Can you explain a little bit more and then I’m going to ask my questions based on this.
[00:44:09] Allen: Oh, they define failure as cost overruns or not meeting schedule. We can say that the project has failed because it didn’t meet the schedule, the estimate, the other thing we could say is we don’t know how to estimate. It’s not a failure, if you can’t estimate, it’s not a failure to hit an estimate, if the estimate is wrong. An estimate is never a prediction, it’s a guess. So their criteria are wrong, they’re defining failure in the wrong way. And the other criteria they use for failure is a very real one - where they say “Yeah, it came in on time, on a budget, but nobody liked it, nobody used it”. And that’s a huge failure that we can address in a natural way, that has nothing to do with schedules. It’s we have to build the most valuable software, and the only way to do that is with these small experiments, not by trying to come up with a perfect specification upfront, because that’s why those projects fail. They don’t fail because of any effort issues, they failed because the specification was wrong and nobody was doing anything in order to assess what was wrong about it, they just assumed it was right and went ahead. And the whole Agile approach is to say “No, no, no, we have to be constantly assessing what we’re doing to see if it’s the right thing to be doing or not, and if it’s the wrong thing, we need to change”. So, you know, their numbers are right, I think they’re just not defining failure in a useful way.
[00:45:38] Yegor: But the numbers are pretty scary, and they are talking about software.
[00:45:41] Allen: The numbers are not scary, the numbers again are measuring whether you were on time, whatever the hell that means. What that usually means is that you had this big upfront estimate, and you couldn’t meet it. And that’s just thinking in the wrong way, that’s not scary, that’s just stupid. That’s assuming that you can come up with a large detailed upfront specification, that you can produce an accurate estimate from it and it’s somehow a failure, if you don’t meet that estimate. And there’s so much wrong with that way of thinking, that it’s hard to tell you where to start. There’s no guarantee that estimate will be correct, because it’s just a guess, there’s no guarantee that the specification is close to being correct. And that process has no learning built into it. So you can’t reassess as you’re working. It’s just a fundamentally flawed way of working. The chaos report is measuring Waterfall, it’s not measuring actual projects. Agile projects do not fail in the way that they describe it. So I don’t find those numbers scary at all, I think they’re not scary, what they’re doing is they’re identifying a root cause that we need to address. Like any metric, any metric that’s good, should be actionable, we ought to be able to look at the metric, figure out what the root causes are and make some change. And the changes we have to make in that system involve large upfront designs, basing planning on estimates that are based on specifications of things that may or may not be accurate, and so on and so forth - all of the things that went wrong. So the solution to that is to change the way that we work, and it’s only scary if you think this is the only way we can work. And I don’t buy that at all. The scariness comes from not having any imagination about how you’re working.
[00:47:33] Yegor: But how would you fix that crisis, how would you remove these scary numbers?
[00:47:37] Allen: It’s not a crisis.
[00:47:39] Yegor: Not a crisis.
[00:47:40] Allen: No, it’s not a crisis. Fix that by working in an Agile way, by constantly reassessing what you’re doing by talking to your customers, by delivering every few days. By swapping out from Waterfall.
[00:47:58] Yegor: How are we going to measure the satisfaction of our customers then, if we don’t have estimates?
[00:48:01] Allen: Talking to them! You deliver every few days and you ask them. You sit down with them, talk. What do you think of this? They go “Well, it’s okay, but it would sure be better if we did that”, or they said “No, this is not helpful at all”, and if with that answer you’ve lost the last week’s work, well, so what? It’s not like you’ve lost last year’s work, you know, and you have to work in a different way. And that involves getting back to something we were discussing a while ago, and it’s a social process.
[00:48:36] Yegor: But I mean, how the chaos people, there’s the people who build this report from this group, how they will be able to measure the success of the entire industry? Now they know how to do it, you just compare the estimate with the result, but how would you suggest they do it? By what, by going around and asking all the customers, whether are you happy or not?
[00:48:55] Allen: Yeah. That’s what we should be doing. It’s that it’s a hard thing to measure with numbers, but it’s an easy thing to assess by talking. Now the chaos people will have a hard time with that, because they want numbers. And I don’t know how you put a number on customer satisfaction, you know. There are indirect indicators, you can look at profits, you can look at whether your customer base is growing, that kind of stuff, but there’s no direct indicator, there’s no number that means “happy”. You do it by talking to people.
[00:49:27] Yegor: I think customers will say exactly the same they say now, because they still have business constraints, they still have some estimates in their heads, maybe we can allow programmers not to announce estimates, but customers are going to still have them.
[00:49:38] Allen: I’m talking about actual customers, the end users. What Toyota calls the end customers - the people who are going to use the thing that they’re producing. If you’ve got an agency model and the customer is somebody in the middle, then they need to be talking to the end customers. And if they’re not, then you’ve got a problem.
[00:49:58] Yegor: But there are some sponsors, I mean, people who put a lot of money, not end users, not people who actually installed applications on their mobile phones, but people with money, so give like a few million dollars for the project, they create this mobile game, for example, and then they fail because they spend all the money, but the game…
[00:50:13] Allen: They should look at the investment the way that VCs are looking at investment. VCs don’t buy products, they don’t say “I’m going to give you 10 million dollars and I expect you to have a specific product built for my 10 million dollars”. What they do is they invest in the team, and they invest in the strategic vision, and they invest in the general idea, they say “This is a really good idea, here’s a problem you’ve identified that needs solving, and we think that if you provide a solution that will get our money back”, and then they look at the team and they say “Do you have all the skills that you need to actually execute on that?” And then they look at the market, they say “Okay, if we solve this problem, how much money could we make do we think”, and that’s how they make their investment decision. There’s no reason why we can’t do that everywhere, you know. And they expect some things to fail, no VC on his right mind thinks that 100% of the things they’re going to invest in are going to succeed. So that’s fine, it’s just part of doing business, some of the stuff is going to fail. That’s fine. So that’s what we need to be doing, we need to be investing like an investor, not like we’re purchasing something that already exists, when it doesn’t. There’s no worse mistake that you can make, than scheduling a demo in a Waterfall world, where you have no transparency into the process, so you don’t know whether the thing you want to demo is going to be finished, when the day of the demo comes along, and that comes from a lack of transparency, and it comes from saying “I’m going to buy a specific thing”, comes from all these other programs. We’ve got to be thinking more like investors and less like purchasers.
[00:51:55] Yegor: It seems like we need a lot of tutoring and teaching and mentoring our customers, in order to make them understand it.
[00:51:01] Allen: Well, I don’t know about that. You need to release to your customers and listen to them. And if you’re against talking about an agency model you’re closer to write, if you’re working as an agency in order to produce software for somebody else, who have the actual customers, then you have to be educating them, yeah. You have to be saying “We’re not going to do, we don’t know whether this thing that you’re talking about is worth building or not, you don’t know it either, so what we’ll do is build it incrementally and get some feedback, and figure out if we’re building the right thing, because I don’t want to waste your money building something that nobody’s going to buy”. No matter how what kind of contract we come up with, no matter how many deadlines, there’s always that risk, so how do we mitigate that risk? Agile’s all about risk mitigation, and the biggest risk of all is investing a lot of money and not getting any return on it. So how do we mitigate that risk? And the answer is we’ll release in small increments and get feedback and adjust. So that by the time we’ve gone through all that money, we will have produced something that was worth producing. And the people say “I need you to guarantee that you can produce this thing for this amount of money” and I’m going “Well, actually you need to know that once you’ve spent the money, that you can get that money back through sales, that’s what’s important. What’s important is that there’s a return on your investment. So we’re going to focus on that, we’re going to focus on how to maximize the odds of you getting a good return on your investment, whether we build this thing that you think we should build or not, that’s actually not really very important, what’s important is getting a return on the investment. And the best way to get a return is to make sure that we’re building something that people will buy. And we don’t know from the specification, whether they’re going to buy this or not, because it doesn’t exist yet. We have no idea, so let’s work in a way that mitigates that risk by delivering frequently and getting frequent feedback and adjusting as we go along.
[00:54:11] Yegor: You seem to be very much an adept of Agile, so you like Agile, but at the same time you had your go-to talk that Agile is not agile anymore. So can you explain it in a few words?
[00:54:22] Allen: Well, people define Agile as something that it’s not, they define Agile as some kind of process, they think Scrum is Agile, or Safe is Agile or something, and it’s Agile means Agile, it doesn’t mean that some canned process. So I don’t like the word because it’s turned into something that it originally didn’t mean. People have defined Agile as if it’s a specific process and if you follow these rules, you are somehow Agile, it doesn’t work that way.
[00:54:44] Yegor: That’s how people understand Agile, that’s how programmers feel it, programmers don’t know all the theories, they just feel that there are some consultants come and come on board, and there are some scrum masters, and they start doing some projects…
[00:54:54] Allen: What I’m reacting to is that none of that is Agile. If it’s a rigid process, it’s not Agile by definition. Somebody comes in and says “I have a rigid process, we’re going to do exactly this” - that’s not Agile. By definition it’s not Agile. Agile means that you’re flexible, nimble, you’re open to change. And if somebody comes in and say “We’re going to do exactly this process and I’m going to bring in this army of trainers and they’re going to teach everybody how to do this process and we’re going to do exactly that thing” - that’s not Agile by any definition of the word Agile that I know.
[00:55:29] Yegor: So what is Agile in this case? Your opinion.
[00:55:32] Allen: To my mind, capital A Agile means that whatever you’re doing aligns with the values and the principles in the Agile Manifesto. With the caveats, some of those have to be updated based on what we’ve learned in the 20 years since the Manifesto was written. So the Manifesto talks about delivering every month, and I think nowadays we would mostly agree that that’s way too infrequently. And the Manifesto talks about retrospectives happening periodically because back when it was written, people would have retrospectives every few months, and now I think we all believe that we should at least have them every week or two, and most people believe it more frequently. But if you look at the basic principles though, and the basic values I think if you align with those, you’re agile. It doesn’t matter what you’re doing, it matters how. So the only practice, the only concrete practice in the Agile Manifesto is the retrospective. Everything else is up in the air, everything else is open. If you’re talking about agile in the lowercase sense of the word, in that case that’s an attitude. You’re agile if you are open to making changes when they’re needed, no matter how often that is. And if you are inflexible in the way you think about things, you’re not that agile. And inflexibility happens a lot, you see a lot of companies that are inflexible about things. Most of the stuff we’ve been discussing have to do with companies being very inflexible about their thinking. So agile in the lowercase sense means that you need to be flexible, that you need to be willing to embrace change to use the buzzword. And if you’re not willing to do that - then you’re not agile. It’s got nothing to do with scrum, it’s got nothing to do with safe, it’s got nothing to do with all that garbage, all right, all that stuff is snake oil, that’s something that hucksters are using in order to make money, that’s got nothing to do with actually being agile. And, you know, people are falling for the con, right? They’re being conned, and they put a huge amount of money into this snake oil that these hucksters are selling, and it doesn’t get them what they think it’s going to get them.
[00:57:35] Yegor: Okay, that leads me to my final question from your tweet, where you said that, let me quote, you said that Agile is not a process, damn it, can we all just get over that?” and then you say “Stand ups, sprints and backlogs” and you call these three things junk. So do you really think stand ups are actually junk?
[00:57:56] Allen: Yeah, if you’re doing them by route. That is this stand up for, what do you need it for? Well, there are two ways that you can work. You can work collaboratively, mob programming is an example, everybody’s literally working together, or you can work as isolated individuals who don’t talk to each other all the time, who are not in constant communication, and unfortunately in the remote world we’re working in now, that is all too often the case. Where people are working at home and they’re not talking to each other. If that’s the case with the way you’re working, you’re not talking to other people, you need to coordinate periodically, so coordination is essential. Whether you do that as a formal stand-up meeting or whether you just talk to people, is a different issue. If you’re talking sufficiently, you don’t need to stand up. So stand-up is a situation where it is necessary only in situations where people are so unwilling to talk to each other that you have to have some formal mechanism in place to force people to talk to each other at least once a day. And most of us don’t have that problem, we’d much rather do it more often, because we can be more productive, we don’t want to risk spending a whole day wasting all day, because we weren’t talking to somebody. So stand-ups aren’t necessary backlogs. So backlog when done improperly is just this huge long-term upfront Waterfall plan. But you’ve got a backlog with six months of work on it? Well that’s a Waterfall plan for six months of work. If you look at most of the things on that backlog, most of them you never get to, because something more important always comes along, so if you think, if you throw away all the stuff that you’re never going to get to, you’re going to be left with a backlog that’s got about a month’s work on it. And when you start looking at that, you go “Well, why do we even need that?” We can figure out what we need to do next from the feedback that we’re getting as we’re doing the current thing. So I don’t think that the notion of a backlog has much value either. And what was the third one? Stand-ups, backlogs…
[00:59:55] Yegor: …and sprints.
[00:59:57] Allen: Sprints. yeah. I don’t think sprints have any value at all either. Cadence has value. To say “Okay, every day we’re going to look at what we were doing over the course of the day, figure out what was right, what was wrong and prove”. That’s a reasonable cadence. A delivery cadence, where we are aiming to deliver every couple days. Cadences have value. Putting everything on the same cadence is dumb because natural things do not naturally fall into the same cadence, and connecting your delivery cadence to an assessment cadence is really dumb, because you want to be delivering way more often, right? So if you want to say “Okay, every two weeks we want to sit down with in-house stakeholders and get their opinion about whether we are proceeding in the way that we think they should’’? Okay, fine, but that shouldn’t be tied into your delivery cadence, or any other kind of cadence. So the only value that a sprint has, in my opinion, is when you are first starting this, if you have no idea how to make the work small enough, it is forcing you to define units of work that are two weeks or less. And we can do that by just getting rid of the sprint and saying from this point forward “All work has to be done in two weeks or less”. You don’t need to have the sprint. There’s a lot of inefficiencies that go into building work around sprints that have to do with wasting time trying to decide what to put in the sprint, it has to do with time left over at the end of the sprint, when you’re finished with everything, but you don’t want to pull anything else, a lot of wasted time there. You’re much better off just saying we’re going to work on the next thing, we guarantee that the next thing can’t possibly take more than a couple weeks, and when we’re done with that, we’ll work on the thing after that, we’ll just keep working on the next thing. Because that’s a much more efficient way to work. Why would you have a sprint? So I don’t think any of this has value, I don’t think scrum in general has much value, but you know people like it, but I don’t really see anything in the scrum itself, in pure scrum that has value. Some people have a very broad definition of scrum that encompasses all of Agile, and if that’s your definition of scrum, - yeah, sure, but if your definition of scrum is the stuff in the scrum guide, which is my definition of scrum, then I don’t find much value and hardly any of that stuff. There’s some things in that, that I like.
[01:02:12] Yegor: Saying all this about scrum, you still have clients, you still have people who want to work with you as a trainer, as a teacher, as a coach for school,
[01:02:21] Allen: You know if they’re doing scrum, I’ll help them do scrum better, I can do that.
[01:02:25] Yegor: Because you say not very popular things about that, because most Agile teams, they do the stand-ups and they actually practice sprints, so when you come on board, I think they get surprised by your opinions, right?
[01:02:35] Allen: I’m not gonna say to an organization that is locked into doing formal scrum “We have to change everything we’re doing next week”, what I’m going to say is “Let’s start taking the retrospective seriously, and let’s look at in a retrospective, let’s really look at what caused problems and what we need to change and everything is possible”. Scrum fails in the retrospective because they say “The changes that you make cannot change the way that scrum works”, so the thing I’ll say is “Let’s get rid of that restriction, let’s say we can change anything, if something’s not working let’s figure out a way to make it work better”, and then the organizations can through the retrospective process improve. It’s all about incremental improvement, and I’m not going to say “Throw out everything that you’re doing and everything you know and everything that’s familiar, it’s dumb”. What I’m going to say is “Let’s start being really serious about looking at what we’re doing and assessing it and seeing what we can do to make it better”. That’s aligned with scrum except for that requirement that whatever you come up with has to conform to the scrum guide. And so I’m only asking for one change, really, which is get rid of that conform to the scrum guide requirement.
[01:03:58] Yegor: Okay, that was a positive summary of our criticism for bad Agile practices, not all Agile, but bad practices. Many things were answered, actually that was really kind of thought provoking for me, and I think for many of the people who are going to listen through this conversation. Thanks again, thanks for coming.
