Charles Betz

This is the agenda. We're going to talk about higher education in the U.S. and some various topics related to Agile, digital, DevOps, and education, and the intersection. We're going to talk about the report and a modern digital course.

You can download the report right now from your devices for free. It's at dynamicit.education, not .edu, .education: Dynamic IT. I have hard copies up here you can also get after the talk, about 40 there.

The download will ask for an email. It's completely non-commercial. We are building a community list, but it is curated by the Minnesota State Colleges and Universities system.

Anybody play Oregon Trail?

All right. Well, on behalf of the great state of Minnesota, you're welcome. This was the product of the Minnesota Educational Computing Consortium, to which this report is dedicated.

MECC also did things like put Model 33 ASR teletypes in junior high school and high school classrooms throughout the state. The first time I died of dysentery, it was printed out on yellow continuous paper on a device like this in Mr. Steadman's science classroom at Ramsey Junior High, which was also where I learned to program in HP Time-Shared BASIC on a timesharing HP 2000.

Yay.

Yep.

Aren't we all?

All right. So, it's really easy when you're talking about higher education to find articles like this: "Plight of the Public University," New York Times this Sunday. But let's get real. Traditional full-time public higher education is not going to fade away overnight in favor of MOOCs, distance education, coding boot camps, or unschooling or what have you.

If lack of talent is a problem for you and your digital organization, I would suggest it's crazy to ignore a system of such scale and scope. Roughly a trillion dollars in capital and half a trillion in annual run rate, 20 million students a year, four million employees. This is a big chunk of our economy, folks, and through tax advantages and state appropriations, it's a chunk we pay for.

People want to send their kids away for a few years to learn. It's been a thing since the Middle Ages or something.

Of the 20 million, where are they going? They're going to big state university systems, 71% of them still. Like the Minnesota State Colleges and Universities system, recently rebranded just to Minnesota State: 30 colleges, seven universities, 54 locations, 400,000 students, the fifth largest in the country.

New Directions is the annual educator industry conference. Advance IT is the center of excellence. We had Nicole Forsgren come in and keynote this year, which is where we kicked off this whole report, was kicked off this spring at this Advance IT event.

So first we did a survey. A hundred and fifty-nine industry and educational professionals responded on topics like Agile, DevOps, and workforce. Couple highlights.

Of the industry professionals, 62% are now considering Agile skills as a factor. And this is where it's interesting: half of those only started doing so in the last three years. So it's like we're in the tornado. The uptake of Agile and the recognition of Agile as a workforce thing is increasing dramatically.

In terms of continuous delivery, 78% of our respondents viewed it as either emerging or mainstream. Only 45% of schools are recognizing it at all. And by the way, if these are biased in any direction, it's self-selected people who are interested in the topic, so numbers are likely a little lower.

Sixty-five percent of the education professionals we surveyed said, "Hey, our system's doing just fine as far as preparing a digital workforce," but only 32% of the industry folks agreed, which is not surprising.

So moving on to some other sources. In terms of what industry is looking for, what are the needs of the new digital workforce? So for what's the nature of the programmers we require, Y Combinator, the startup incubator, in a survey of what startups need, they noticed that their startups were hiring programmers with a strong product focus, far and away the most desired. Not the technical programs focused on things like algorithms and data structures. The customer-focused, user experience-focused, product-oriented programs, almost twice as much in demand.

And where do we get these product-oriented programmers?

Well, this is where we start to see the structural problems in the education system. So this is the University of Minnesota. My wife and I have five degrees from there. Go Gophers. My wife is the smart one with the PhD in geology, just to be clear.

Notice the Carlson School way over here, and computer science about as far away as we can get from the business school with this big river thing in the middle.

Now let's riff a little bit on Conway's Law. "Organizations which design systems tend to produce," you all remember, "copies of the communication structures." The University of Minnesota is, in a sense, designing our workforce. And what could possibly go wrong here if we are trying to create product-oriented technologists?

So we'll return to this question of how disciplinary boundaries are set.

I'm going to pivot a little bit to a specific practice. One theme I've certainly heard at least anecdotally from many hiring managers: the students are coming out of school, and they don't even know version control or source control. How many of you have had that experience with new hires?

Okay. Yeah, quite a few.

Majority of the educators that were surveyed, and again, these were biased to people who actually might have been more favorable to it, they don't provide any practical experience in version control.

State of DevOps Report suggests it's one of the factors most correlated with digital delivery performance. Ultimately, I'll draw an analogy, interested in feedback. I kind of compare it to hygienic practices in healthcare. Interns and residents in the medical community are expected to know how to sanitize, why they do so, and to actually do it on an ongoing basis as a practice. There's a practical expectation throughout the healthcare community, and it's grounded in an important theory, the germ theory of disease.

I'd suggest that source control is our equivalent to hygiene. And certainly, noticing Andrew Clay Shafer's quote that I have used a million times over, it's the foundation of every other Agile technical practice. Hard to argue that one.

So why do we have the educational structures that we do? Specific decisions were and are being made under the auspices of well-known organizations that many of us support through membership, I'm a member of all three of these, and through tax exemption. They've got the social mandate to do this.

These are the major players: the IEEE, which handles the engineering side; the Association for Information Systems, which handles the B-school MIS side; and the Association for Computing Machinery, which acts like an overall umbrella and coordination role. This group, it's largely responsible for how the computing-related disciplines are structured in the U.S., at least.

Now, other countries have different players, like the British Computer Society in the U.K., for example. I'm being very U.S.-centric in this presentation.

So they got together in 2005, and this was based on previous work, but I'll just focus on the current cohort of reports. They said, "There will be five: computer engineering, computer science, software engineering, information systems, and information technology." And the B schools get MIS, the C schools and the engineering schools get CE, CS, and software engineering, and IT is kind of all over the map and often not taught at top-tier schools.

Once scoped, further working groups on the four documents on the right here have been produced on a rolling basis for years. And when you dig into these reports, you see very interesting assumptions, including very clear statements, for example, that CS majors need to know next to nothing about business matters, including product management. It's all at this URL here. If you want to see where the education system is defining itself in the curriculum, just go to that URL, and this deck will be on SlideShare.

So I know this is an eye chart. There's a lot of detail here. You can come back to this. This is an excerpt from extensive matrices in the 2005 report that set the disciplinary boundaries.

Scale from zero to five is used to indicate how much graduates from each degree are expected to know across 50 or so different knowledge areas, both core computing and contextual related areas. And basically, you can read this as saying MIS majors do business requirements, business models, business performance, including presumably product management, and CSci majors analyze technical requirements and do techie stuff. The business stuff is almost completely zeroed out for them.

Essentially, what I would argue and propose to you is that we have baked Waterfall into the fundamental curricular and disciplinary structure of higher education. We plan it with IS, we build it with CSci and SE, and we run it with IT.

I'm sorry, backing up. I've been hearing at least anecdotal evidence, including discussions with my dean and industry associations in Minnesota, that the IS and IT degrees in particular aren't as well-regarded by digital hiring managers. It's that top-tier CSci degree that is viewed as the gold standard by hiring managers in industry, including companies like major Minnesota retailers that didn't use to see themselves as technology hirers, and now they do.

So there's kind of a couple of wrinkles here. I spoke with senior faculty in the CSci department of U of M, and he's like, "Charlie, CS departments in schools like mine are incented to produce researchers. That is their social function." Now we've got industry saying, "More."

And so the CSci departments, there's an article, I think it was in IEEE Computer, are under pressure to increase the volumes of computing grads up to 50% or more. But I think industry's going to start demanding a different profile from these grads who are coming out, again, not knowing source control, not knowing product development, not knowing anything about operations.

I want to be a little more precise, and I want to be very careful as we have these conversations with academia about what this report is and is not about. The core stuff on the left: discrete math, fundamentals of computation, automata, operating systems, compilers, and languages. Not talking about any of that. It's great stuff. You need it. You need your people to know it. Go knock yourself out. And not criticizing or suggesting any changes there. I'm not qualified to. Be very clear.

It's the contextual courses. Project management, requirements management. I mean, a software engineering or even a CSci program might require three credits of project management, and this is in a day and age when companies are shutting down their PMOs in favor of continuous flow approaches. So what are we going to do about that? I mean, should we keep doing that?

We've got these big batch, three credits of requirements, three credits of architecture, three credits of software quality assurance. I mean, we've baked Waterfall both into the disciplinary boundaries as well as the computing curricula. So operations shunted off at best to the IT degree.

And yet here you've got the site reliability engineering folks calling for CSci majors in operations, where you've got CSci majors that are going to come in, landing in organizations with heavy-duty operational aspects, high flow, customer-driven digital pipelines. And out of the current curricula, they land on like, "What? This isn't what I went to school for."

And sure, are there institutions that are better? There's variability in the institutions. Some of you may say, "Well, the schools I know, they're actually starting to get..." But this is workforce, folks. This is about the 8 million. This is about the broad structures, and the broad structures are defined and influenced by these artifacts we're looking at here.

Final note on this slide. In Europe, there's this thing called informatics, and we have that here too at UC Irvine, Indiana, Northwestern, maybe a few other places. I'm wondering, I'm not ready to suggest, but I'm wondering if the informatics degree really is kind of the vehicle that we might be able to move forward on. Just the beginning of a conversation.

So let's turn to the report.

So here it is. I've got 40 copies here. You're welcome to take one, and there is also a URL where you can download it. You can download it even now if you want it: dynamicit.education.

This is how we structured it. First, we provide an overview of the Agile, DevOps, and digital context, and we give people lots of references to think about. We talk about the historic failure of the Capability Maturity Model, the emergence of empirical process control. We talk about origins of Agile, 10 deploys a day. We define five competency areas that I think could be considered by any computing-related discipline. We'll talk about those later. Finally, make some specific recommendations for adapting and creating new courses, and conclude with some thoughts on digital labs and simulations.

I want to be very clear. This report is not prescriptive. The report specifically says, "It would be ironic and presumptuous to attempt to mandate a standard Agile curriculum." What we are trying to do is provide a resource for teaching faculty, busy teaching faculty across the U.S., who otherwise might be blindsided by the movement coming out of conferences like this. These folks do need some help, and they need some resources.

So going into the competency areas. The first one we talk about is dynamic infrastructure operations. The competency areas break down into categories, competency categories, competencies themselves, and we put lots of learning objectives for course designers to consider as a reference. All cited, mostly cited with respect to industry literature, a lot of O'Reilly books and stuff.

This is about virtualization, cloud, infrastructure as code, site reliability engineering, operational practices. We bring in John Allspaw, Tom Limoncelli, Google SRE book by Betsy Beyer et al., and more.

Continuous delivery is the second major competency area. We talk about it's not DevOps, because DevOps is a bit too broad. We talk full stack, full lifecycle, and the learning objectives here relate to core Agile as well as continuous integration, continuous delivery, and of course, the State of DevOps research gets a bit of attention and love here.

Product management. We've got 85,000 Scrum product owners, all created by commercial training. So what should new ones learn in school? Should there be an academic response to you? What about the product-focused devs that the Y Combinator companies want? If I want to go into this as a field, what do I do? What do I need? Amazing, huge gap.

For faculty, we suggest Marty Cagan, Steve Blank, Jeff Patton, Jeff Gothelf, design thinking folks, and also note that the existing UI and user experience courses that already exist in curricula might be decent places to start.

Fourth competency area is resource and execution. Now, this is kind of a common abstract area to discuss both project and process in a generic sense. We need a better language for discussing and analyzing these questions. Things are a little too religious right now. You get DevOps versus ITIL, no estimates, no projects, SAFe versus LeSS, Scrum versus Kanban. I want a more clinical... I suggest we need a more clinical terminology and a big hat tip to Don Reinertsen. I would much rather talk about things like cadence and synchronization and batch size, queuing, specialization, skill versus product alignment. All of the themes you hear at this conference when people, you know, they're really engaging with this problem.

And then finally, organization and culture. Students need to be able to assess whether they're in a culture that's ultimately going to support high performance. Organizations need to know that too. And we can quantify this. It's not woo-woo stuff anymore. I mean, that's very clear from the conversations here, right? So we call out Project Aristotle, more of the State of DevOps work, and so on.

Now, one of the things we often hear is that tech moves too fast and that we're going to get into vocationalism. But ultimately, this is not about let's teach the latest version of Jenkins. There's a big tectonic shift going on here in the transition to continuous flow and continuous delivery. And so I do think that this is something that is appropriate now for academic attention.

And I'd say to the... And certainly for two- and four-year teaching colleges, well, they are supposed to do vocational and workforce teaching. So what's the problem with being vocational?

And I'd suggest for the researchers that you think you couldn't create hundreds of PhDs out of the questions and concepts being discussed at this conference? My God, I mean, it's immensely rich narratives and conversations we're having here that absolutely could be researched.

So much for learning objectives. Don't have time to go into the whole report here. Time is slipping away quite quickly.

So as we look at updating pedagogy, a few things. It's not easy to create net new courses. The report suggests various ways in which we could adapt them. For example, continuous integration and delivery could be brought into SQA, a software quality assurance course, if you're not ready to actually get rid of the course.

But I think product management and operations probably call for new courses. I haven't seen too much evidence of those out there, not that I've reviewed every syllabus in the country. And we also suggest interdepartmental collaboration. So get the CSci and B-school people talking, and get students from both sides working together.

We also go into virtualization, virtual labs, and simulations. A bit more on that in a bit.

So turning to the micro, this is my course at the University of St. Thomas. It's essentially a broad IT management survey course. It uses a scaling model as a primary learning progression, with also a flipped model where people view lecture video online, and in-class is all lab-based and experiential.

And the lab approach is what I call full stack, full lifecycle.

What do I mean by that? So we teach IT using two narratives. We use either a stack narrative, say this depends on this depends on this, and we either teach it bottom-up if you're CSci or top-down if you're a B school, or we teach the lifecycle, i.e., kind of Waterfall. Now, both of these narratives have some important educational aspects, but they both have limitations.

And so the narrative that I'm suggesting as a learning progression that I use, I call the emergence model from my current book. And my students love it because everybody can relate to Larry and Sergey in the garage creating Google. You can sell the incoming students on, "Hey, let's have a startup. Let's think about what it takes to run a startup."

And the interesting thing is you step people from bottom to top through the scaling model. That's where you can have very targeted conversations on things like, well, when you move the state transition from team to team of teams, that's where you get into all those interesting hard questions about coordination and what do we do about the time wasters and dependencies. And you can't just assume that they aren't ever going to be there. So it also gets past, again, some of the religious debate.

Important conceptual point. Whichever of the dimensions you choose, you have to collapse the other two. So if you choose to teach along a scaling narrative, then you have to collapse both stack and lifecycle.

So the basic theme is you need full stack, full lifecycle education from day one for students to really understand the DevOps and digital transformation we're going through. And this is exactly what I do.

So I am an architect. I have Visio on my laptop. Ooh. I also have Vagrant, VirtualBox, ChefDK, and a set of seven virtual machines with Java, Ant, JUnit, Git, Jenkins, Artifactory, and Nagios in an end-to-end continuous delivery pipeline. All runs on a MacBook Air. It's pretty cool.

I use it for teaching experimentation. You can do stuff with virtualization that would have required millions of dollars in capital for education years ago. Classes are a blast. We stand up four or five of these things and abuse them, get the students swarming around them and supporting each other. If you submit pull requests to improve the system, you get extra credit.

It's just beginning to dawn on faculty what you can do with this stuff. It's all defined as code on GitHub: a master Vagrantfile, a bunch of Chef recipes. I haven't got to Docker yet. I'll get there next year, folks. There is a lag with academia. I'm sorry. But there's a difference between being three miles behind moving at the same speed versus falling further and further behind. I'm happy being three miles behind as long as I'm moving at the same speed.

So going forward, I think I'm roughly on time here. We're considering putting the overall guidance in some kind of online system like a Stack Overflow, so that we can collaborate on these learning objectives and they're not being held too close to some insular group. I want broader community participation.

And in terms of what you can do, here are some ideas. Look to your local university advisory boards. Look to your tech lobbying associations. Your university should be willing to hear from you. They have a slower feedback cycle, but they do have feedback channels. You just have to be a little more patient.

And in conclusion, what I would ask for help with: send your faculty friends to dynamicit.education. And then what I need help with is have a look at the report. Are the competency areas or the structure, are we on target? Is it the best we can do? And think about how we could do this more collaboratively and collectively.

And then finally, I do have an interest in how we would ultimately relate this also to commercial training and that whole space. That would probably be a whole other talk.

So I think we're probably right on it, right?

Yeah.

Yeah, they didn't... Oh, okay. Well, it says 4:50. Oh, I do. Have fun with this. I was basing this on my... So here, I have one thing that I have. Do that. I see it.

And since I have a minute, go ahead, but I'll just tell a joke.

So why did I call my pipeline the Calavera Project? I googled "walking skeleton," and I got two major classes of imagery. So I could have either gone with the Grateful Dead or Día de los Muertos, so I went with Día de los Muertos as kind of the conceit for the Calavera Project.

Anyways. Yeah, go ahead.

Q&A

Q: Question about not the content, but the form. In addition to topics that are missing, there's also computer science people are taught lecture style, they are certified, and they give answers to questions about best practices where we need people to be able to learn how to learn. And does your curriculum address not only what people know, but how they can learn moving forward into their careers?

A: The report does not address pedagogy. We deliberately took that out. It has just a couple pages on it because the scope would've blown open.

Q: Okay.

A: Mostly the report is about just providing people cited learning objectives and 100 references. That's the bottom-line value.

Q: And the second, real quick, in the culture section, do human sciences fit into that? Anthropology?

A: We note that one of the notable phenomena in the DevOps community right now is the increasing openness to pulling in human factors and operations research. We specifically mention John Allspaw's contributions there and bringing in people like Sidney Dekker. We don't mention anthropology specifically, no.

Q: Have you interacted at all with the Georgia Tech group that's doing the online master's in computer science program? They've had a lot of announcements lately about what they're doing there. Just wondering if you've...

A: No. No. I've had interactions with a few different folks actually around the world, but not them.

Q: Okay.

A: Yeah. Shoot me their contact info. Definitely. Yeah. There was another one. Behind you? Is it behind me? Right behind you, literally.

Q: More of a basic question. There's a lot of material here.

A: Yes. Sorry.

Q: Is there a top takeaway for us who are here? How does it matter to us, and what should we do about it in that sense?

A: Well, it depends on your role. If you're a hiring manager, I think the takeaway is this is the beginning of a conversation you could have with your local higher education advisory boards. That would be the takeaway I would suggest. The assumption is this would be of interest to hiring managers.

I could think more, but I'd be sitting up here, thinking out loud. We could talk more afterward. It's a good question.

Q: Yeah, cool. Thanks.

A: Yeah.

Q: So what you said really resonated with me because I work at Lockheed Martin. I've been there for 22 years, and I try really hard to bring new teams up to speed in Agile and DevOps, and it's a struggle. But you're right, we hire a lot of computer science majors. They don't understand why the product matters. It only matters that they've gotten some code. You're lucky if you got them to think it's important to compile. I'd really like to engage in this because I think I can see a solution that hadn't occurred to me before.

A: Let's keep in touch. Thank you. Appreciate it. One more. We got one more. And then we've got to let other speakers in. Yep. Great.

Q: Okay. Sorry. I actually do a lot of work with my alma mater. I sit on the school business advisory council.

A: Great.

Q: But it's a public university, so in a pretty large public university system. Can you give some advice on how to articulate benefits of doing this to help sell it to them? Because it's a really hard thing to change the curriculum within a public university.

A: Yeah. Well, it starts with the fact that the public university has a social mission. And I think if you frame it in those terms, there's an obligation to the students, there's an obligation to the stakeholders.

Starting with the State of DevOps Report might be as good a place to start as any, and I would invite you to take a couple copies of this report because it does talk about the why. It starts with the executive summary and executive positioning.

Thank you, all. Appreciate it.