Agile Solutions For the Federal Government with Glenn Thimmes, CTO of Centeva

Transcript

Ledge: Glenn, good to have you here.

Glenn: Yeah. It’s great to be able to join you.

Ledge: Can you just give a two or three minute background story of yourself and your work?

Glenn: Sure. I got into programming a long time ago. I was in seventh grade when I got my first computer – it was an Atari 800 that came with a basic cartridge that I could push in and write basic code and record it onto a cassette tape.

Started sloughing school so I could stay home and write D&D games, and from there, my love for coding grew. Went on a hold for a while, but then later in life around the age…

I come from an interesting story. I dropped out of high school when I was a freshman. Wanted to go straight to work. I just felt like high school was a waste of time. I wanted to work full time. I wanted to be an adult. At age 24, went to college, entered computer science. Finished my degree in four years and went to work for Microsoft.

I spent a year there doing developer support, and it was right during the release of .NET. So I got to understand the .NET framework from the C# side, the VB.NET side – I came from the C++ background. Got to know all that very well. Then I was recruited by a company back here in Utah where I’m from to come back and build .NET solutions for them.

I’ve been back here for almost 20 years now. Spent 12 years with that company, New Dawn Technologies, building case management software for courts and public defenders and prosecutors in over 300 agencies across the world. Then after that company got purchased I left to go work for another startup – because that’s where it really feels good, that’s where the fun and the action really is – and joined a company called Centeva that’s also here in Utah.

We do a lot of work for the federal government. It’s a little bit more red tape than I’m used to with state level government, but we have gotten to work on some exciting projects. The most notable of which has been rebuilding all the systems that the Nuclear Regulatory Commission uses to inspect all of the nuclear reactors, both research and power, in the United States. Project management. Scheduling all the inspectors. Managing licenses for the people who operate the reactors. That whole spectrum.

We’ve got a team of about eight people that worked on that project, which four companies before us came in and failed. Some of them quite large companies came in and tried to replace the system and failed. We came in, we told them, “Twelve sprints, we’ll go live on this date,” and it happened on that exact date. Which was kind of weird. That never happens, right? We almost felt like we should have moved the date just because we’re supposed to, but we pulled it off.

That’s what happens when you have a great UX team. They can listen to users tell you what their needs are, but they can watch them do their job and identify what they really need and make sure that we deliver the most important stuff first. They were able to do a great job of that and deliver exactly what the users needed to get their jobs done.

That’s been kind of my history. I’ve gone from being a software developer – I still have a love for code and I code with my daughters – to being really a team builder. I build software teams. I build software organizations.

Ledge: You talked a little bit off-mike about that experience of bringing agile to a federal government contracts. All over the news now is, “Federal government wants to try agile,” and all these things.

Talk about what that’s really like on the ground because I think that’s a great story.

Glenn: To a certain degree it’s lip service. They’re catching up. They’re 30 years behind the rest of the software development world to some degree. Some of it is lip service. Some of it is memorandums going out agency-wide, to the entire agencies, saying, “We do agile now,” and nobody has a clue what that is. They assume, well, as long as do a morning standup we’re doing agile.”

Others have really embraced it. Our work with the Nuclear Regulatory Commission has been interesting because, as I was telling you, we went in for a kick-off meeting and they said, “Congratulations. This is our first agile project. We just spent millions of dollars gathering requirements for two years, and now we want you to start building software. Don’t talk to the end users.” We were just blown away by that because that’s not the way we work.

But very quickly they picked up on the value of delivering increments of working software to end users on a frequent basis, and giving their feedback and the excitement that that builds. We went from an environment where they said, “Don’t talk to the end users. They burn out on requirements. They don’t want to talk to you,” to very quickly all the users wanted to talk to us, because they saw working software getting delivered.

So it can happen. It takes support from stakeholders, though. You have to convince more than the end users. You’ve got to get support at a higher level.

Ledge: As you got success there, my guess is that you got a lot of anecdotal, backside feedback about why the other vendors failed, right? What did you do differently? It’s easy to say, agile and we stuck to the guns on user feedback and MVPs. Everybody throws out those words as if that’s what they want. Even the clients that are further down the spectrum – they kind of at least know the vocabulary this time.

But there are material differences in the way that the teams behave, and the way that things actually get done in 12 sprints. When the rubber hits the road there, what is it?

Glenn: Well, there’s a number of things at play there. There is the way that companies do business. The way that companies do business at various sizes.

We are a company of about 130 people right now. When I joined five years ago, we were a company of 40 people and our technology team was me and a part-time guy, and our technology team staff is now 50.

But we approach projects, from what we’ve seen, very differently from other contactors in the federal space. It’s kind of sad to see how low the bar is in that space. We’ve come in behind other contractors that won a bid because they bid lower than us, and the owner of our company said to me, “Don’t worry. They’ll hire us to come clean up after that company messes it up.”

I’m not going to name the company but it was a larger company. They staffed it really poorly and delivered a dumpster fire, and just ran away with the dumpster on fire. We got hired to come in and clean it up, and we did it with more resources for a fraction of the price.

One of our core values, that we just discussed two days ago that we put up on the board was, “We value doing the right thing over doing the most profitable thing.” If we stick to that value we’re going to succeed in the long run and we’ll be known for that.

The way our company works is, salesmen don’t sell what we do. That’s never been a model that’s worked for us. It’s been our work that sells what we do. So we do great work and then the word spreads.

That’s been what we’ve seen as the primary failure of some of some of the other companies. One is just understaffing and not really caring and being focused on profits. Delivering the minimal amount of people, to deliver the minimal thing that could possibly even be considered as a solution, that’s hardly viable, and running away when it’s done with the money.

The other problem is, I think some of those vendors that failed before us never got past the requirements phase. They never even got to where they were delivering working software. They spent so much time focused on perfecting the requirements, so they were still stuck in the waterfall mentality. I don’t know if they were thinking that they were starting to do agile at that point or not – I don’t expect that they did – but I think at least two of them ran out of funding before they ever even delivered a prototype.

That’s the other problem, is that the software world has traditionally felt that you need to gather requirements for years before you start writing software. About 30 years ago people started to think a little differently, and did some research and found, “Oh. Standard engineering practices don’t apply to software development. We need to use empirical evidence, and inspect and adapt on frequent basis. Deliver early, fail fast.” Those principles weren’t at play in some of those early attempts, so I think they just got bogged down. Maybe they got four or five million dollars into the project, and said, “We can’t keep doing this,” and all they had done so far was gather requirements.

Ledge: It’s painful to hear, particularly that all of us are paying for that.

Glenn: Yeah, but they’re learning.

Ledge: I’ve been in the government contacting world, and that it is hard for the small vendors to go up against the big guys. You do have to have the long term view point where you know that you could do it better, but you aren’t going to win the initial bids until you can kind of get yourself that reputation over the course of many years, where you might be the sole sourced contractor for some kind of reason. How do you even get ahead of that?

You almost want to caution the small shops that kind of think, yeah, there’s so much money in government contracting. Look at this. Millions of dollars. We know we could do it better.

You know what, they probably could but that business development training there, it takes a whole long time to get that momentum in a way that won’t crush you so you don’t need to think about that productivity or profitability. The cash flow burdens and the payment cycles of government are rough.

Glenn: Right. It’s a long process, it moves very slowly, and relationships are necessary really. At any level of government work that I’ve been involved with, cold RFP is something that’s not worth responding to. If there’s not some form of relationship you’re just not going to get anybody’s attention. They’re not going to look at it. They need to have heard from somebody that you are a contractor worth talking to.

Also, just in defense of the federal government, they do have to work from a position of playing it very safe. That’s one of the reasons why they move slowly, and why it feels like they’re behind the times on technology. It’s because, they’re not going to move Windows 10 the month it releases. It’s going to take them two or three years because they’re going to make sure that it’s hardened, that all the service releases have come out that need to get it stable.

That’s the way that they approach everything. They play it very, very safe. Ironically or maybe appropriately, they’ve adopted or began to adopt SAFe agile as the form of agile that makes sense to them. It’s not this free flow agile party where everybody just does whatever they want and passes out and has a hangover in the morning, but instead they have something that’s documented and you can print out a long 80-page document describing how that form of agile works. That gives them reassurance that even though they’re doing agile there’s still something [00:12:21].

Ledge: For those who don’t know, SAFe is what? Scaled Agile Framework for enterprise. Is that right? Something like that.

Glenn: Yeah.

Ledge: It gets you a little structure around that.

Glenn: It’s really trying to solve…

Ledge: It just gets a little structure around that kind of fluffy version that we all like from lean startup.

Glenn: Yeah. It gets more focused on solving agile from the executive level, from the portfolio level. Speaking to the people who don’t get agile but want to understand what’s going on with all the projects in their organization.

Ledge: So, let’s switch gears for a little bit. You talked about teaching your kids how to code at a young age. I know most of us that are kind of into code, I’ve tooled around with a little of the apps and trying to get my six and nine-year-old to care a little bit. They’re probably more into Minecraft right now. But whatever you’ve done there, this is going to be a critical skill. To get kids interested in it is something that appeals to all of us in the craft.

Glenn: I think that those who have kids want to get our kids into coding. It’s something that, at least for me, I’ve wanted to get my kids interested because it’s a way that I can relate to them that would help them understand what I do, and the way my mind works. Also, it’s the one thing that has captivated my mind more than anything in my life.

I’m a ADD. Always struggled in school. Grade school was very difficult for me because I just could not listen during class. I would just tune out and watch movies in my brain. Programming was the first thing, other than coffee, that just completely captured me in tunnel vision and captivated all of my attention. So I want to share that with my children.

I’ve tried early on in various forms, and you make a lot of mistakes. If you’ve ever tried to teach your kids how to ski you know what a disaster that is. There’s a rule. You don’t teach your own kids how to ski because you end up yelling at them the whole time, and they hate it, and it’s miserable, and they never want to ski again. Sometimes I think that I’m not that great at teaching my kids things that I’m good at, but I just don’t know how to explain that to a child. I know how to explain that to someone right out of college that I’m training that has a background, but it’s different.

Ironically, we home school our kids and my wife is a master at this. She has done a beautiful job of schooling our children.

My eleven-year-old was the first one that really started to get interested, and she was drawn in by the same thing as me. I got talking with her about, “What if you had a computer program you could talk to?” That was what got me writing code when I was in seventh grade was, what if I can write a program you could talk to?

So her and I started working on it and over weeks we got to the level of Cleverbot where we figured out, “I think I know how Cleverbot’s working. It seems like it’s recording some people’s questions, reducing those down to a basic statement, and then using that statement on other people and recording their answers. Then boiling that down to a basic statement. Now, it can recognize those back and forth and try different answers and different questions that it knows has been related to each other, but still has no context of where we are in the conversation.”

That’s the problem we are working on next is, how do we create a conversation graph? We’ve been talking for 10 minutes and now the computer needs to respond with something meaningful to the context of what we’ve said in the last 10 minutes. That’s something that she’s been fascinated with.

I’ve done most of the actually writing of the code while she’s helped to design the conceptual solutions. Now we’re moving to where she wants to be at the keyboard, she wants to write the code, and she’s actually learning C#.

I’ve also got a 15-year-old daughter who wants to start college this fall. She wanted to start last year, we told her you have to wait till you’re sixteen before you start college. So she’s starting this fall. I’ve got another daughter that’s in her second year of college. My 15-year-old has decided recently she wants to go into computer science.

So I thought, well, let’s start coding together first of all and see if you like that, because while you’re interested in the fact that developers make good money, it’s more important that you love it because if you don’t love what you do money is not going to fix that. Also, I’m getting her set up with an internship here where I work so that she can be embedded in a team that has co-ownership of delivering a working increment of software every two weeks, and see what that dynamic is like.

She works at a job right now where she’s already been promoted to a manager, and has the keys and opens up in the morning. She’s 15 years old. She thinks that this will be a less social job and I’ve told her, there’s this stereotype of developers, you lock them up in a room and slide a pizza under the door. But that’s not the way it works today. Development teams are highly social. You sit in the same room together, you’re co-located and you’re talking all day. Sometimes maybe too much, but the value of having that much chatter and friendship is what produces really high-performing teams over time. The more they forge relationships and understand each other, the faster they can translate thoughts from one mind to another – with shortcuts because they know each other’s personalities.

I’m going to see how she feels in that environment, and if she does it for three weeks and quits because she hates it, that’s a success, right, because she figured that out before she registered for school this fall and she can start looking into other options. If she does it for three weeks and loves it, then great, she’s already on the right track. I mean, can you imagine being a freshman in college and to have already been working for a few months on a software team? She’ll have a nice head start at age 16.

Ledge: She already should go to the government. There you go.

That’s fantastic. So toolset-wise, you’ve got to have been what? VS Code and you’re actually using the .NET frameworks? It almost sounds like you’re thinking about using something like the NLP functions and stuff like that?

Glenn: Everything we’ve been doing is a consul app in .NET. We’re working in Visual Studio. This code I think would be probably a little bit simpler interface for her and maybe a better place, but we’ve just been using basic .NET framework features, voice to text.

Actually, one of the hardest things above any… Surprisingly, the hardest thing is I want it to look like the computer is typing back as it talks. That was one of the hardest things to implement. Of all the problems we had to solve, having the characters appear on the keyboard slowly as the computer talks, like they did in the movie WarGames. Maybe I’m too old.

Ledge: No, I know WarGames. That’s a classic.

Glenn: Okay. In my brain I thought, it’s got to look like that. If the computer’s talking to me, it’s got to look like it’s typing as it’s talking. That was one of the hardest things to figure out.

Ledge: So you’ve got her really thinking in that architect seat and design. Like, let me talk about specifications and the real way that as a user I want to experience this. I think that is probably vastly more valuable as a skillset, to understand that user empathy piece prior to even writing a single line of code. The rest of it you’re going to pick up real fast – on the syntactical and object oriented and whatever that is. Those things are very easy to pick up from a logical standpoint. The rest of it is not.

Glenn: Yeah. One of the things that really come into play – and this goes back to our whole philosophy on how and why we home school our children. I have to be really careful about not going too far. If they’re interested in something, I want to feed them what they’re interested in and the minute they start to lose interest that’s when you stop. That’s something that my wife helped me to learn early on, but it really has taken… You learn all your mistakes with your first two kids, and your third kid you get it right.

Ledge: You also let them eat a lot of dirt.

Glenn: Yep, you do. I’ve made a lot of mistakes in trying to participate in home schooling our kids, because I get home from work at five o’clock. They’re done, they’re just as done as I am, right? They’re burned out, they’re tired, and they don’t want to hear anymore. I’m at the dinner table, trying to teach them a lesson. My wife is looking at me going, “Glenn, they’re not even listening. Stop.”

I picked on that quick enough, and gave up a long time ago on trying to be the teacher at five o’clock at night, but the idea that when kids are interested in something and they want you to feed them information, you feed it as long as they’re consuming it. But the minute they lose interest, stop, because that’s how you destroy their love of learning.

Honestly, that’s how I believe the school system burns kids out on learning. We’re all born with this natural desire and urge to decode things and it’s really easy to destroy that. There’s a lot of research that’s been done that backs that up. Kids want to learn how to read, they want to learn how to decode.

We never did any reader books, any flashcards with our kids. we just let them start reading when they started reading. I think all of them learnt their first words from playing video games. “Exit,” “Start” were some of their first words. Our first kid didn’t start reading until she was six or seven, but her first book was Twilight. There were no reader books in between. The same thing with our next kids.

We’ve taken that approach of only feeding them what they’re asking for. In the radical unschooling world they call that strewing. Where you provide strings, and whatever string they pull on you keep feeding more of that until they stop pulling. Then whatever string they pull on next, you feed that. My wife has just filled our home with all kinds of stuff.

That applies to trying to teach your kids how to code. I think I could have failed really fast with my 11-year-old, trying to teach her how to code. had I not been very sensitive to that. As long as she’s interested let’s keep going, but the minute she loses interest let’s… Oh she wants to play Minecraft now. Let’s go do that.

Ledge: That’s so hard for us as passionate practitioners.

Glenn: It is.

Ledge: But we found our thing, and we love our thing. I try to remember, hey, if they want to write poetry that’s kind of just their code and I’ve got just back off. Don’t help. Don’t even try to be useful. Say, “Oh that’s good.” Encouragement.

Glenn: Yes.

Ledge: As we wrap here I’ll say, when bring it back around, all those principles are really what the organizational literature would all tell us make for engaged employees and really successful professional teams. It kind of comes back to the, all I needed to learn I learned in kindergarten.

Glenn: Right. Absolutely.

Ledge: It’s interesting stuff. Glenn, thanks for the conversation today. Really inspiring.

Glenn: Thank you for inviting me.