Jonathan and Will join this panelist episode to tackle team maturity in a company. They discuss their point of view on team maturity when it comes to testing codes and creating new projects. Additionally, they discuss competence in terms of managing one's job and approaching problems. 

Hello and welcome to another exciting episode of Adventures in DevOps. I'm your host for the day, Jonathan Hall, and here in the virtual studio is with me, Will Button.

 

What's going on? Happy New Year.

 

Hey, happy new year.

 

Although

 

Did

 

this.

 

you celebrate? Did you get really hungover?

 

No, I did not get really hung over, but we have a tradition with my friends where we celebrate Nova Scotia New Year. We're on the west coast of the U.S., Nova Scotia is not, so that gives us the opportunity to celebrate New Year's at 8 p.m. and then still get in bed at a nice reasonable hour.

 

I love it. I don't know what time I went to bed, but it was probably around eight or nine, the

 

Yeah.

 

bedtime for my toddler. And he loved the fireworks. He'd never seen them before, or hadn't remembered seeing them before. And I was afraid, so here in the Netherlands, everybody does fireworks on New Year's, like they do in the US for the 4th of July.

 

Oh, right on.

 

So, and at midnight.

 

Oh, that's tough.

 

So,

 

That's tough.

 

I mean, they start early, but the big show is at midnight.

 

Yeah.

 

By show, I mean the loud waking everybody up, the dogs are barking, and the car alarms are going off, moment is at midnight. So I

 

Hahaha!

 

was a little afraid that my toddler would wake up. He didn't, fortunately. I did, but he didn't. So it was a successful New Year.

 

Right on, nice. We have a few people that do fireworks around here. And I've got, we lost one of our dogs earlier this year, and I've got the other one, and she's 14 years old and hates fireworks. So we have this medicine the vet gave her that's like a calming medicine. So we made sure and loaded her up on that so that if the fireworks went off, and she woke up, that it didn't send her into a panic.

 

got it under control.

 

for now.

 

So what are we talking about today?

 

So today we're talking about maturity and I just feel obligated here to reference something Beavis and Butthead related because every time we talk about maturity I go straight to Beavis and Butthead Gifts.

 

Yeah. Yeah, so we're going to talk about something we know nothing about,

 

Great.

 

essentially. Because if you listen to the show, we're not about maturity. We're about being as immature as possible.

 

I am Cornelio. I need DevOps for my... Oh wait, I can't say the last... Can I say that last word? I

 

know.

 

suppose I could, but I'll pass on it.

 

Okay, yeah.

 

Just in case.

 

If you don't know what Will's talking about, check the show notes.

 

Great, yeah. If you haven't watched Beavis and Butt-Head, which is entirely possible, just...

 

You know, I really haven't, but I do know that reference. I've seen clips. I haven't really watched the show

 

Yeah,

 

or

 

this

 

the...

 

is not a big time commitment to get acquainted with Beavis and Butthead. Like any 30 second clip on YouTube will probably

 

You got

 

bring

 

the gist.

 

you up to speed.

 

Yeah. So this topic of maturity was something that I've been thinking about this last week. And usually in the console, it's been bothering me basically. And what I mean by that is I hear people talking about Scrum Masters or Agile Coaches, or just even CTOs talking about the maturity of their team. And usually as a limiting factor, they'll say something like, my team just isn't mature enough for that. practice, whether that be test-driven development or continuous delivery or no estimates or whatever sort of thing it might be, right? It could be a whole plethora of things. And usually the problem I have with this isn't per se that it's wrong. Maybe the team isn't mature enough in some sense for that thing, but that it's not actionable. And I don't think that this phrase, we're not mature enough for something, helps us. address the actual problem. If your team decides it's not mature enough for continuous delivery, then what? What do you do next?

 

Right?

 

Is that the end of the discussion? Do you go home now? Okay, we're not mature enough. Maybe someday we will be. Or what can you do? So that's kind of what I've been thinking about.

 

You

 

And I've

 

just

 

been

 

ride

 

having

 

it out

 

this...

 

and wait for DevOps puberty to kick in.

 

Exactly. Right?

 

I'm getting a bunch of zits. Maybe this is it.

 

So I've been talking to others about this and thinking about it and reading some topics, but I thought maybe I'll just kick it off with that, see what you think, and then we can sort of hash this out, see what we come up with.

 

I think I agree with you a lot on this and have been going through similar pains because it's been I think three or four months now I went to work for Polygon Labs which started 18 months ago they had I don't know 50 or 100 employees and now have over 500 so there's been significant growing pains there. And starting as a very early stage startup, you know, if you've dealt with startups a lot, your first product release in a startup is do whatever it takes to get it into production to see if your product market fit is actually what you thought it was because 90% of the time it's not. And so you cut a lot of corners there, but now our product is successful. And so we have to start maturing our processes to, to use the big M word. And so yeah, we're going through that as well. and my experience with it has been in many instances you know you come across I'll just use a specific example here hey here's this application that's in production it has no tests on it and one way to do that is say oh we're not very mature as an organization but the way I've been approaching it is just go talk to that development team go hey y'all need to write tests oh okay And so there's really not been a lot of pushback. It's just that for many of them, you know, they didn't know or maybe they had heard it and thought, yeah, that would be cool, but they just needed to be like prompted to adopt that mature practice and go, OK, cool.

 

Yeah, I mean, so I've observed the same sorts of things. And I can think of two or three specific examples. Maybe I could just mention some of those and we could see how they differ or are similar. One, I was talking to a CTO, acquaintance of mine. Actually, he's a fractional CTO. And I don't even know what company he was working for when that's good because I wouldn't want to out them anyway. But he was saying that they were doing a lot of manual testing there and that they weren't mature enough yet for automated testing. And I don't know, this particularly really kind of messed my mind because to me, doing manual testing well requires a much larger sense of maturity than doing automated testing well. You know? If I'm starting a brand new company, my first and second and third hires, a manual QA isn't gonna be one of those.

 

Right,

 

I'm gonna

 

yeah

 

be

 

for

 

working

 

sure.

 

on automated testing first. And then later, once we have a mature product organization, then I'm gonna start looking into, okay, now how can a manual QA start to benefit us? So I felt like that certainly in my mind, that was a backwards approach. But as it relates to this conversation, just saying they're not mature enough for this thing. didn't explain, of course, why. I mean, maybe there was some novel reason that this team couldn't do automated testing. I really doubt it, but maybe there was, right? And just plastering over it with the M word made it impossible for me to understand those details.

 

Yeah, it almost sounds in that context like a cop out,

 

Mm-hmm.

 

I think. Because like, what's the level of maturity that you need to write tests? Well, you got to know how to write code. And if they've built an application, presumably they have the ability to write code.

 

I mean, we're getting to maybe to another topic, but in my mind, if you can't write tests, you're not a qualified programmer in the first place.

 

Yeah.

 

You need to, I mean, I don't mean that you're an expert necessarily and you know how to test every scenario, but at a minimum, you should be able to do some amount of testing to be confident that the code you're writing does what you think it's doing.

 

For sure, yeah, because testing, there's a lot of rabbit holes you can go down,

 

Yeah.

 

but like, you should have, like you said, you know, the ability to write some basic tests to prove that your code does what it's claiming to do. I mean, I suppose that there's another scenario, because you have to write your code in a way that it can be tested. So possibly one scenario is, yeah, we looked at the code, try to write some tests for it, and it just all has to be refactored. OK, that's possibly a barrier. But again, I don't know that I would call that a lack of maturity. And again, it's just something that just goes on your backlog, like, hey, we need to refactor this, how do we break it apart into pieces and start doing this incrementally over time? And it's something you can always chip away at rather than just throwing up a wall and saying, we can't do that.

 

Yeah, and I think that gets to kind of my main idea around this is that even if you want to say that we don't have the skills yet to do that refactoring, maybe that's the case. If you want to call that a lack of maturity, okay, technically maybe that's true, but that's not a useful description. Let's be more specific and more precise and say, what we're missing here is the knowledge to do that refactoring safely. Because then we can start to address that problem rather than just sort of sitting there waiting for puberty to come along.

 

Right?

 

Thanks for watching. Bye.

 

Yes, I think it sounds more like a poorly worded problem statement than a barrier to the solution.

 

Another example, this was, I think it was a Scrum Master I was speaking to on one of my Slack channels that I'm on. And they were asking how to train a team with proper use of story points. And of course,

 

Yeah.

 

in that conversation came up the discussion, why don't you consider no estimates? And the Scrum Master said, yeah, I think no estimates is great, but my team isn't mature enough for that yet, so I'm teaching them the story points. What do you think of this?

 

I... So estimates are just a wild ass guess anyway. You just literally make up a random number or size and throw it out there. So the level of maturity required to do that is pretty low and the way I've approached it in the past is when you first start doing that all of your estimates are just wild guesses anyway, but then over time you look and say, oh, we said that this was a large or a seven or whatever, and in comparison to other sevens, it doesn't really line up. And so you refine your estimates over time based on the team that you work with, because if, you know, what's a seven for one team at one company may not be anything remotely close to what a seven at another team or another company is. The level of maturity required to start doing estimates, in my opinion, is the level of maturity required to pick a random number. Because it really doesn't matter what the number is, right? It's only what the number comes to mean over time.

 

Yeah, yeah. So I mean, I wouldn't call myself a hardcore no estimates advocate, but I like a lot of the stuff that the no estimates movement and philosophy embraces, which I mean, to summarize, there may be listeners who don't know at all what that is, and so I'll just summarize briefly. The idea of no estimates is that you should be able to build software without estimating. I mean, that... And that's an oversimplification. They do advocate the use of forecasts, which they distinguish as subtly different from estimates. So forecasts are sort of data-driven. I'll use the word estimates

 

Hahahaha

 

for when a project might be done. But so, I mean, they... Maybe I can, I mean, there's different techniques that no estimates people advocate, but one of them is to, rather than sizing your stories, just give every story a single number, one. You know, call it one story point if you want to. And they've discovered that if you give every story point a value of one, your accuracy really is not any different than if you go to the effort of doing, is this a one or a three or an eight or whatever? Like it all averages out anyway. So why waste the effort? with that planning poker session or whatever you're doing to come up with those numbers, just give it a one.

 

Right.

 

And then once you do that, if you look at your historical average, how many stories do we complete per say, week or sprints or month or quarter or whatever, and how many new stories are added to the backlog during the same period, whether that's splitting a story because it was too big, we split it into three or we just add in the requirements, whatever. If you take those two numbers, number of stories completed and number of stories added, then you can predict, over time when your project will be done. Either those numbers, as long as you're adding fewer stories than you're completing every quarter, then those are gonna converge. If you're adding more than you're completing, then you're never gonna get done, right? You're falling behind. Either way, you don't need to estimate, you just need to know how many stories are being done. So that's one of the many techniques they talk about. But I thought it was interesting that this person thought that they needed to go to the effort of training people to pick a random number and then over time, sort of refine that random number to mean something, that that required less maturity than not estimating in the first place. And that kind of blows my mind a little bit. Like how is doing extra work that you don't need to do, how does that require less maturity?

 

How does having imaginary friends make you less lonely? Ha ha ha.

 

I'll offer a final example from a company I was at a few years ago. I had implemented and helped the team implement continuous delivery. And so we were deploying 15 times a day or something like that. And one of the product managers, some bug had gotten into production. One of the product managers didn't like it and thought that the problem was this continuous delivery that we didn't have enough manual checks in place. And somebody's answer to me was, Jonathan, we just aren't mature enough yet for continuous delivery.

 

Wait, you guys wrote bugs? Why did you do that? Ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha

 

Well, we just weren't mature enough. Ha ha ha.

 

Yeah, to me that one doesn't sound, again, like all of these, I don't think maturity is the right word. I think to me that indicates the person who made that statement. Well, actually maybe they aren't the mature one. They haven't been doing this long enough to understand that writing bugs is just what we do. Like you're going to introduce bugs into production, you're going to have outages, you're going to get hacked. These are all known guarantees in life. You can't stop them. The only thing you can do is try to build in controls over time that minimize the blast radius and minimize the time that it's out there before it gets noticed.

 

So one of the thoughts I had, so I had a conversation with a number of people on a Slack group about this and it reminded me of a podcast I had just listened to, one of my favorite podcasts.

 

Adventures in DevOps?

 

Yes, no. My other favorite podcast. It's called the No Nonsense Agile Podcast. They had me on as a guest a few weeks ago, which was fun. But their most recent episode, I should pull up the guy's name so I can actually quote it correctly. Sorry, Mr. or Ms. Editor, I don't know who's editing this. Just edit out this pause while I'm looking this up. All right, here we go. So the No Nonsense Agile podcast, our most recent episode, they interviewed Eric Lopez, who's a retired US Army Colonel. And they were talking about the concept of mission command. which is relatively new, I guess, I don't know how new. Newer than World War II anyway, so which is relatively new in military terms. I got the sense that it's new in the last couple decades, like maybe since the Afghanistan or maybe Iraqi War. But it is a new approach to the command hierarchy and structure in the US Army, or at least in parts of the Army. It's in contrast to the old approach of command and control. And I don't remember the full list, but he talks about, I think it was six principles they use in this mission command approach. Basically the idea is that the upper management or the general, whoever's in charge of the mission, gives small specific orders about here's the intent. Not how to do it, but here's the intent. We wanna capture that hill or take that city or whatever the thing is. And then as that goes down the chain of command, the orders may become more specific as the person giving the commands knows more about the situation. But ultimately it's up to those carrying out the mission to make good judgment calls and do the right thing to accomplish that initiative. So they had a list of principles, five or six or seven, and they went through each one in the episode. It's a good episode to listen to if you have a chance. But the last one was competency. And it was interesting because they added this one later. Initially, competency wasn't in the list of things. And then they discovered that if you give some fresh bootcamp grad a rifle and the responsibility to go make good decisions, but he doesn't know how to use that rifle yet or whatever, it's kind of a disaster situation that might be happening, right?

 

I can see how that would work out here. Yeah.

 

So they added competency to the list of principles. And I think that a lot of times when we're talking about a lack of maturity, what we really mean is a lack of competency. You know, if you say we're not mature enough to do, to write automated tests, I don't think, I mean, again, whether that's technically true or not, isn't the point. Is it useful? I don't think it is. But if we say we don't have the competency yet to write automated tests, Now we can do something about it. Now we can go, okay, let's get someone in here to train you how to write automated tests, or let's have you take a course or read a book, or practice for a weekend, or whatever it takes. What do we need to do so that you can become competent in that area? Or we don't have the competency to do estimates, or no estimates, or whatever the thing is. I like this framing of it a little bit better because I think it's more actionable.

 

Yeah, I would agree with that. Um, and those are the same, some of the same principles that, uh, you just referenced on that podcast that were brought up by Jaco Willink and his, I think it's his latest book, leadership strategy and tactics, which I've picked on the show here a couple of times. Really good book along those same lines, but I like the phrasing of using competency because in my mind, um, that allows you to say, okay, where is the lack of competency at? You know, if you go to your team, say, hey, we're not writing tests because we don't have the competency. And your team says, well, we know how to write tests. You just don't, you didn't tell us to. Or you don't give us time to. Or, you know, whatever. And so it opens up the discussion to determine where the competency is lacking because it may not be where you think it is. because it could be an incompetent process versus an incompetent skill set.

 

Right, right. W. Edwards Deming has a great quote about that. Let me find it. Sorry, editor.

 

Yeah

 

So W. Edwards Deming, who's sort of considered the grandfather of Lean and Agile, had a quote about that. He said, a bad system will be the good person every time.

 

Yeah.

 

And I like that. You know, most of, we hear a lot of talk about hire good people, you know, how do you screen for the best candidates and so on. I think most of that's a wasted effort. I mean, that's to say it's completely wasted. You know, you can't hire. bad people, people who are gonna be lazy or actively sabotage your system or whatever, but they're very rare.

 

Yeah.

 

The bad systems are really the problem.

 

Yeah, I agree. There's a quote from Bill Gates very much along those lines that I've liked for years. It says, applying automation to a bad process magnifies the inefficiencies. Applying automation to an efficient process magnifies the efficiency. Something like that. I'm sure I butchered it, but hopefully

 

Oh, you probably

 

you get the point.

 

said it exactly

 

Ha ha ha

 

right. Ha

 

ha

 

ha

 

ha ha ha ha ha.

 

ha. Ha ha ha.

 

Cause that's what I'm known for. Ha ha ha

 

Ride.

 

ha ha.

 

So do you think there, where is maturity a legitimate element of this, either on a team level or individual level? I mean, what does actual maturity look like if it's not these things we're already discussing? Is there an element of that in this?

 

Um... I guess just as a blanket statement, you could say that lack of maturity would look like you want to do this thing X, but your team doing it just physically does not possess those skills. Which I think in the examples we've talked about here, we kind of debunked those. But if you really had an immaturity problem, it would be trying to solve problem X and you just physically do not have that skill set in the people. So we're not writing tests because the team's not mature enough, meaning that you ask the team, hey, can you write some tests? And they were like, what's a test?

 

Yeah.

 

What do you think?

 

That would be a case of possibly hiring bad people, I would think.

 

Yeah,

 

Ha ha ha ha.

 

right? And again, I think then the maturity, the immaturity problem is not with the team, but with the person who built

 

Yeah.

 

that team.

 

Yeah. So I think, I mean, when I see problems, or when I think of problems that I might attribute to maturity, they're mostly soft skill types of problems, you know, like, this team can't agree on anything, or this team can't have a... Everybody's always showing up late to the meetings and nobody's ever around to make the decisions, you know, those sorts of things would seem like a lack of maturity. I would be tempted to blame that on the maturity of the individuals in the team, although if the whole team is doing that, it's probably a systemic problem that maybe is the team or the company. I would expect any, quote, mature team to be able to... I don't care what their skill levels are. I mean, if you take a mature team of auto mechanics and ask them to optimize MySQL... I would expect them to approach the problem well. They wouldn't have the skills, you know, they had to go figure out what MySQL is and look up, you know, Google for several hours, but I would expect them to not just sit there with their thumbs up their butts going, you know, we can't do this, we're gonna argue forever. I would expect them to approach the problem and try to find a solution. So, you know, if, yeah, I don't think, we don't know MySQL is properly attributed to maturity. I think the maturity of a team has to do with Are they communicating? Are they working together to solve problems? And if they're doing that, then no matter what their skills are, we can say it's a mature team and that they're prepared to tackle any problem we throw at them, whether it's optimizing MySQL or getting rockets into space, they should be able to approach the problem in a mature way.

 

Yeah, I would agree with that because dealing with unknown technology is kind of what we do as a profession. Like even if today, you know, let's say, you know, all of the tools and all the products in your trade. Next month, there's going to be something new. And in a year from now, there'll be something that's really hot. And five years from now, all the tools you're using today are going to be considered obsolete. So your entire career, you're going to have to be tackling problems that you don't really understand the product initially.

 

Okay, I don't know if we finished that topic already?

 

Well, it may seem a bit premature, but yeah, I think we did.

 

I'm trying to think of another angle to discuss because I only see 27 minutes on our clock. It feels like we should go longer, but I'm not thinking of anything else either.

 

Yeah, I don't know. I think we can probably wrap that up. Like, because I don't want to get to the point where we're continuing to talk about something that's no longer entertaining for

 

Right,

 

the listener.

 

right. All right, well, whoever's editing, please chop out that little discussion there. And so we look smarter than

 

Make

 

we

 

us

 

actually

 

look good.

 

are.

 

Which I've listened to our Finnish shows, the editor does a really good job of

 

Yeah.

 

making us look good. You know, given the clay that they have to work with.

 

Shall we go on to some picks?

 

Let's do some picks.

 

Do you have any for us?

 

I do. I've got kind of like a dual combo pick for today. Because for years and years, I've used pen and notebooks for taking my daily notes and writing down ideas. But it's hard to index, and I can never find the stuff I'm looking for. And so I've tried all kinds of note planning and. personal organization software and all of that kind of stuff and failed miserably at all of it. But about a month ago, I bought a new iPad and went back to using Evernote. And with Evernote and the iPad with an Apple pencil, you can just draw and write. And it's actually pretty nice to draw and write on because it's, um. It's very responsive and it feels like you're actually writing. Whereas a lot of times when I've done this in the past, there was just like a disconnect between me making the hand motion and something appearing on the screen. This feels very fluid for some reason. And so it gives me, it's given me the ability to just write down sketches and drawings and notes freehand. But then when I save it, Evernote does the text recognition when I remember writing something down I can just go back into Evernote and search for what I wrote and it will find it. So that's that's my pick. I'll keep you posted on how that works out.

 

I'm curious, I have a problem that I can't even read my own handwriting. I'd be a little bit surprised if a piece of technology could.

 

Hahaha

 

So I'm going to pick a shameless self-plug

 

Hmm

 

this week. I'm launching a new website related to my YouTube channel and my new daily email list that I've launched.

 

Right

 

The new

 

on.

 

website is boldlygo.tech, and it's all about the Go language. So if you are a Go developer or thinking about developing Go, check out my new website. It has links to my YouTube channel, which is by the same name, BoldlyGo. And since the beginning of the year, I am writing a daily, five days a week email about Go. And at the moment, I am going through the GoLang spec and explaining it in easy to understand terms. So

 

Oh wow.

 

my goal is to make the spec as accessible as possible to anybody. I don't think anybody should be intimidated of this spec. I don't think you can feel like, oh, that's something for the for the gurus to read. I want everybody, if you've never read, read a line of Go in your life, you should be able to look at this spec. and appreciate it and get value from it if you're writing Go. So that's my intention. If you would find that valuable, head over to boldlygo.tech and you can sign up for that daily mailing list and you'll be jumped into the middle. At the time this is published, I've already, at the time this episode goes live, I've already done about three or four weeks worth of that, but you can catch the old daily emails on the website too if you wanna read what I've done already, so.

 

Oh cool, that was going to be my question is can I catch up to speed on it or? Nope, sorry. You're just going to be deficient in

 

Yeah,

 

that section of

 

you'll

 

go

 

never

 

for

 

know

 

the

 

the

 

rest

 

beginning

 

of your

 

of the

 

life.

 

spec now. And you know, I'm thinking about, if it proves popular enough, I may turn these daily emails into an ebook so you can get the whole thing at once. I'll probably wait until I'm at least halfway through or something to do that, but I might turn it into an ebook. You can just download the whole thing.

 

Right on. Cool, that sounds cool. I've been watching your videos that you're doing and those are actually really, really helpful and they look like they're doing quite well too.

 

Yeah, I feel like I'm doing well on the YouTube channel too. I have close to 500 subscribers. I've only been going about three or four months.

 

Yeah.

 

So my goal for the first quarter of this year in particular is to really focus on the Go related content. I'll probably be launching a Go course before too long. So stay tuned for that too.

 

Nice. Right on.

 

Cool.

 

Yeah, good

 

Well,

 

times.

 

thanks, Will.

 

Yeah, thank you. It was

 

Thanks

 

great

 

for listening.

 

having this mature conversation with

 

Yes.

 

you.

 

For the first time, we've had a mature conversation on this channel, on

 

Alright.

 

this show. Until next time, everyone.

 

All right, see you, Roland.