We’re getting exactly the government IT we asked for

If there’s one complaint that I hear consistently in my studies of IT in large organizations, it’s that government IT, as traditionally practiced, is fucked. Compared to the private sector, the amount of paperwork, the role of contractors, and the seeming separation between doing a good job and working software drives all sorts of angst and failure.

Mark Schwartz’s book on figuring out “business value” in IT is turning out to be pretty amazing and refreshing, especially on the topic of government IT. He’s put together one of the better “these aren’t the Droids you’re looking for” responses to ROI for IT.

You know that answer: you just want to figure out the business case, ROI, or whatever numbers driven thing, and all the DevOps-heads are like “doo, doo, doo-doo – driving through a tunnel, can’t hear you!” and then they pelt you with Goldratt and Deming books, blended in with some O’Reilly books and The Phoenix Project. “Also, you’re argument is invalid, because reasons.”

A Zen-like calm comes over them, they close their eyes and breath in, and then start repeating a mantra like some cowl-bedecked character in a Lovecraft story: “survival is not mandatory. Survival is not mandatory. Survival is not mandatory!”

Real helpful, that lot. I kid, I jest. The point of their maniacally confusing non-answers is, accurately, that your base assumptions about most everything are wrong, so before we can even approach something as precise as ROI, we need to really re-think what you’re doing. (And also, you do a lot of dumb shit, so let’s work on that.)

But you know, no one wants to hear they’re broken in the first therapy session. So you have to throw out some beguiling, mind-altering, Lemarchand’s boxes to change the state of things and make sure they come to the next appointment.

Works as Designed

Anyhow, back to Schwartz’s book. I’ll hopefully write a longer book review over at The New Stack when I’m done with it, but this one passage is an excellent representation of what motivates the book pelters and also a good unmasking of why things are the way we they are…because we asked for them to be so:

The US government is based on a system of “checks and balances”—in other words, a system of distrust. The great freedom enjoyed by the press, especially in reporting on the actions of the government, is another indication of the public’s lack of trust in the government. As a result, you find that the government places a high value on transparency. While companies can keep secrets, government is accountable to the public and must disclose its actions and decisions. There is a business need for continued demonstrations of trustworthiness, or we might as well say a business value assigned to demonstrating trustworthiness. You find that the government is always in the public eye—the press is always reporting on government actions, and the public is quick to outrage. Government agencies, therefore, place a business value on “optics”—how something appears to the observant public. In an oversight environment that is quick to assign blame, government is highly risk averse (i.e., it places high business value on things that mitigate risk).

And then summarized as:

…the compliance requirements are not an obstacle, but rather an expression of a deeper business need that the team must still address.

Which is to say: you wanted this, and so I am giving it to you.

The Agile Bureaucracy

The word “bureaucracy” is something like the word “legacy.” You only describe something as legacy software when you don’t like the software. Otherwise, you just call it your software. Similarly, as Schwartz outlines, agile (and all software processes) are insanely bureaucratic, full of rules, norms, and other “governance.” We just happen to like all those rules, so we don’t think of them as bureaucracy. As he writes:

While disavowing rules, the Agile community is actually full of them. This is understandable, because rules are a way of bringing what is considered best practices into everyday processes. What would happen if we made exceptions to our rules—for instance, if we entertained the request: “John wants to head out for a beer now, instead of fixing the problem that he just introduced into the build?” If we applied the rules capriciously or based on our feelings, they would lose some of their effectiveness, right? That is precisely what we mean by sine ira et studio in bureaucracy. Mike Cohn, for example, tells us that “improving technical practices is not optional.”15 The phrase not optional sounds like another way of saying that the rule is to be applied “without anger or bias.” Mary Poppendieck, coauthor of the canonical works on Lean software development, uses curiously similar language in her introduction to Greg Smith and Ahmed Sidky’s book on adopting Agile practices: “The technical practices that Agile brings to the table—short iterations, test-first development, continuous integration—are not optional.” I’ve already mentioned Schwaber and Sutherland’s dictum that “the Development Team isn’t allowed to act on what anyone else [other than the product owner] says.”17 Please don’t hate me for this, Mike, Mary, Ken, and Jeff, but that is the voice of the command-and-control bureaucrat. “Not optional,” “not allowed,” – I don’t know about you, but these phrases make me think of No Parking and Curb Your Dog signs.

These are the kind of thought-trains that only ever evoke “well, of course my intention wasn’t the awful!” from the other side. It’s like with the ITIL and the NRA, gun-nut people: their goal wasn’t to put in place a thought-technology that harmed people, far from it.

Gentled nestled in his wry tone and style (which you can image I love), you can feel some hidden hair pulling about the unintended consequences of Agile confidence and decrees. I mean, the dude is the CIO of a massive government agency, so he be throwing process optimism against brick walls daily and too late into the night.

Learning bureaucracies

The cure, as ever, is to not only to be smart and introspective, but to make evolution and change part of your bureaucracy:

Rules become set in stone and can’t change with circumstances. Rigidity discourages innovation. Rules themselves come to seem arbitrary and capricious. Their original purpose gets lost and the rules become goals rather than instruments. Bureaucracies can become demoralizing for their employees.

So, you know, make sure you allow for change. It’s probably good to have some rules and governance around that too.

Cull your rules and regulations, or be frozen by them

screenshot-2017-02-25-09-21-23

Instead, the post emphasized new ways NASA is thinking about acceptable risk for these launches. During the space shuttle era, launch sites were governed by some 2,200 safety requirements. NASA worked to “strip down the expensive rules and came up with just 500 core safety requirements for launches.”

But, the post notes, ”at commercial launch sites, there are only 55 safety requirements.” This “underscores perhaps the single biggest difference between NASA and its commercial partners: risk tolerance. NASA likes to have next to none, and pays for it, while the companies tend to embrace calculated risk as a way to iterate and learn while still developing their products.”

This a major point in companies fixing up their software process: you probably have all sorts of rules and regulations that no longer apply. Just like with managing a legacy application portfolio, you have to aggressively manage your compliance portfolio to eliminate rules that no longer apply.

Matt Curry covers this point with a funny boat-metaphor at the start of his brand talk from last year. You also hear some cases of federal agencies forcing this culling by simply not following the rules and seeing if anyone complained: the compliance equivilent of just turning off old, dusty servers to see who’s using it.

Link

TrumpTech: $450bn in annual fed spend in limbo

There is a lot of uncertainty in the air,” said one consultant close to the Office of Management and Budget’s IT efficiency initiatives who asked not to be identified. “The whole IT industry and federal IT operations are in a wait-and-see holding pattern,” he said, anticipating official word on key federal IT initiatives and leadership positions.

In my amateur analysis of Trump’s effect on IT spend, it seems like there’s three options:

  1. More of the same with big contractors and vendors, just wrapped up in myths of change.
  2. Complete shut down of everything with respect to growth; they just stop spending and let government IT age.
  3. Start working with new government contractors and doing things differently; the “Space X” option.

Who knows what’ll happen?

Link

TrumpTech: If the rocket scientists can do it cheaper, surely IT can too

Boeing and Lockheed were already worried about their costs long before the election. If I were the United Space Alliance, I would be even more terrified of the danger of losing government business now. And those of us in federal IT need to realize that our time may be around the corner.

As we discussed in the 2017 predictions show last month, the Trump adminstration is clearly not reliable in it’s agenda or principals for any reliable, let alone logical, predictions. Cutting spending in favor of “non-traditional” options, though, seems like something they’d goof into.

Link

The internet of food nutrition labels

“So anyone who is producing food that ends up in our grocery stores, we’re working with them to get the data from their labels and the packaging information to come right into the database for us,” Pamela Stark Reed, deputy administrator for Nutrition, Food Safety and Quality, said on Information Management month.

The database has actually existed for over a century, Reed said. But before starting the initiative, it only had about 8,000 entries. Since opening it up to manufacturer submission, ARS has received 80,000 new items, a 1000 percent increase.
And on future plans:

The goal for the database is to eventually expand to 1,000,000 items. Reed said ARS anticipates getting store brand and international food items into the database soon. Some items from chain restaurants may follow.

Because of this, the agency is looking into cloud services to increase its storage capacity.

Just imagine, globally, how many data sets like that there are. Throw in the workflow to injest and cleanup the data, and change it, plus APIs to access it, and you have an almost endless amount of projects for software eating.

http://federalnewsradio.com/information-management-month/2016/11/usda-turns-nutritional-data-open-data/

Saving $20m and going agile in the process

From an interesting sounding panel on government IT:

“We do discovery on a small chunk and then development, and then while that’s going on, we’re starting discovery on the next small chunk, and so on and so forth,” Smith said. “And then when the development is done, we loop back and we do user testing on that piece that’s done. But we don’t release it. That’s … one of the differences between agile and the way we did it. At the end of the phase we release everything.”

Also, some fun notes on consolidating legacy systems and resistance to going agile.

6 DevOps columns: government, compliance, ROI, management

Last year I wrote several columns for FierceDevOps. Nancy Gohring was the editor there and graciously asked me to do so (she’s moved over to being an analyst at 451 and is doing awesome work over there). The FierceEmpire has shifted their stuff around and now it’s either impossible or impossibly tedious to find those pieces, so I moved them over to Medium. I’ve got to get my URLs to be my overly self-referential self, after all!

Here they are:

  1. Software Defined Businesses need Software Defined IT Departments
  2. Here’s how we can help push DevOps into the mainstream
  3. There’s no easy way to model DevOps ROI
  4. Management’s role in DevOps: orchestrating the why
  5. Barriers to DevOps in government
  6. Addressing the DevOps compliance problem

Agile Methodology In-depth Review, Government Edition

I’m giving a 90 minute overview of agile for an agency later this month. Here’s my slides, so far. As ever, “government” is just an extra layer of sprinkles on-top of advice for all large organizations.

There’s some extensive (for me) talking points in the slide notes if you’re into that kind of thing.

Better ways of developing software or, coding like a unicorn, government edition

I’m often asked to come speak on, well, the topic of “tell us about the new, interesting stuff out there that makes software development better…but don’t be pitching me anything.” This is my most recent cut at that kind of talk.

You can check out the slides as well.

See these slides and the government edition of them too. This presentation changes slightly each time I give it. Here’s the first, rehearsal run of it as well.