[Osia-members] GovHack (and Open Government) could be more impactful if they learned from Open Source communities

[Jack Burton]

G'day Steve -- must have been about a decade since we last had a little
chat -- good to hear you're still around :)

On Sun, 2017-08-20 at 12:04 +1000, steve jenkin wrote: 
> I could only find on-line “AGOSP" (Australian Government Online Service
> Point), not Jack's AGOSSP acronym.

That would be the "Australian Government Open Source Software Policy",
available here:
https://www.finance.gov.au/sites/default/files/australian-government-open-source-software-policy-2013.pdf

There used to be an accompanying "Guide" document (which is referenced
in the policy itself), but that seems to have been lost somewhere in
the transition from AGIMO to AGICT...

> A partial answer to Cameron’s video comments on implementing “Open
> Govt” principles:
> 
>  - there is no direct or measurable reward or benefit to IT workers or
> managers, so why would they waste time & effort on it?
> 
>  - Government agencies are almost universally isolated, iconoclastic
> silos with limited migration and no contact with other IT Depts and
> often with other internal IT groups. The frontline troops never get to
> see things ‘done better’ or experience the benefits of collaboration.

That second point was a big part of what OTF was supposed to address,
but didn't. Not all that surprising, given OTF's highly ambitious &
overly broad scope (Commonwealth gov, plus all states & territories
*and* NZ). As Carl & I suggested (in section 2.3 of our submission to
PM&C), it might be more realistic to attempt addressing that issue with
a similar initiative across just the Commonwealth Government (which,
even on its own, is still tremendously broad) to begin with.

> The DTA’s (Digital Transformation Agency) “Principles” are great, they
> cannot be faulted, but by themselves are just more words. IMHO, they
> lack the organisational motivators and processes to create real,
> lasting change. A Cultural Change required is to add “Open Source” to
> the “Nobody ever got fired for buying ….” (IBM, Oracle, Microsoft, ….)

Agreed, but I would go further and suggest "substitute ... for" rather
than "add ... to".

For example, the 2016 Census provides a textbook example of where
someone really *should* have been fired for "buying IBM then failing to
manage them".

See also Sections 5.3 & 6 of our submission to PM&C.

> You’ll know the DTA has done its job when its normal practice for
> frontline staff to first ask “what’s the Open Source product most used
> for this?"

That would certainly be a big improvement, but again I don't think it
goes far enough. "most used" falls into the same trap as "nobody ever
got fired for X".

Innovation requires analysing problems afresh from first principles,
rather from the perspective of common solutions. Of course, that does
not mean that solutions have to be built from scratch -- FOSS licences
are a great tool for avoiding the need for that -- but I do think that
a greater emphasis on the analysis phase is an essential ingredient.

In other words, "more haste, less speed".

> I’ve yet to see an IT Dept where the staff aren’t frantically busy and
> don’t feel constantly overloaded. There’s ‘no time’ to fix things or
> address “out of scope issues” - they are mostly too busy fighting
> brushfires to find & fix the flamethrower creating them.

Very true.

As always, under-staffing & unrealistic expectations can be blamed for
that to some extent, but that's far from the whole story.

It used to be said that a systems manager's role was to "automate his
own job out of existence", in order to free himself up to work on
newer, bigger & more exciting challenges more relevant to the
organisation as a whole.

That was much of the motivation behind the "infrastructure thinking" /
"systems approach" of the '90s, from which the "devops" movement of
today evolved. But somewhere along the way something went awry and the
results most commonly seen started moving back in the opposite
direction.

I have several theories on why that might be, but won't bore the list
with them here, as I think we're already straying quite a bit from the
original topic of open source & open government, well into enterprise
architecture territory...

> Bringing up topics like “Professionalism”, “Quality” and “Improvement”
> with workers is only met with groans - they’ve had repeated bad
> experiences with “Management by Fad” and aren’t interested in anything
> that gets in the way or slows them in meeting the latest deadline.
> “Quality” is often confused with “massive bureaucratic processes” and
> used to beat-up on people or to shift blame. (“you signed off on this,
> you’re at fault not me”)

Indeed. That's a common reaction to quality "done wrong", which happens
all too often.

Deming (and after all these years I still believe there's no single
greater authority on quality than Deming) taught the exact opposite.
Several of his "14 points for management" would seem germane...

I differ from Deming's 14 points only in that I believe that individual
accountability *is* vital. But I agree with him 100% that individual
accountability can serve no purpose (and indeed, can cause much harm)
if the workman, engineer or manager is denied his right to pride of
workmanship (which is exactly the effect that unrealistic deadlines
have).

I don't think "stop doing QM" is the answer though. Similar to the
point on innovation, I'd suggest that approaching QM from first
principles (or at the very least, understanding the *reasons* why
whatever forumlaic approach chosen was originally designed that way and
making sure that's a good fit for the needs of the organisation in
question before blindly applying it) would be a good start.

As Deming himself said, QM cannot simply be imposed from above. You
need buy-in at all levels of the organisation first if it is to be
effective...

...which gets back to your point about "no measurable direct reward or
benefit". There *is* measurable benefit to be had. But if the majority
of staff aren't sold on that (or don't understand why/how it will be
effective), or if certain business units are given no input into the
process design phase, any QM initiative is likely to be
counter-productive.

To a great extent, I think quality as a discipline has become a victim
of it own success: so much demand for it (in name alone, unfortunately)
that "pick a framework and follow it blindly" has become the norm,
which rather defeats the purpose.

I could bang on about QM for hours, but I'll stop there, as again I
think I've strayed a bit far from the original topic...

> A wider view:
> 
> For 10-15 years, I was “parachuted in” to these environments and
> developed a personal process described in “Digging Out” (Turning around
> challenged Technical Projects/Environments) if anyone is interested.

Just read it. An interesting article. For others who may be interested,
it's here:
http://stevej-on-it.blogspot.com.au/search/label/digging%20out

> If you think these problems are limited to Government, or any level of
> Government, you’re wrong. This is right across the Industry.

Absolutely. Hope I didn't come across as suggesting otherwise.

<...>

> R5: Government should define a best practices guide for publishing
> data services, and then follow this guide.
> 
> > I'm in two minds about your R5 -- personally I see benefit, rather
> > than detriment, in diversity of APIs (including protocols &
> > standards for data access), as healthy competition tends to foster
> > innovation (and whilst the goal is clearly to encourage innovation
> > in the use of open data, why not foster innovation in how it's
> > published too?) ... but I agree with you 100% on the importance of
> > having clear documentation for them.

Just to clarify, I'm not opposed in principle to Government documenting
best practices (so long as they're not too prescriptive/exclusive).
Most of my comment above was in reference to the text in Cameron's
article leading up to his R5, rather than in response to his R5 itself.

Regards,



-- 
Jack Burton FACS CP <jack at saosce.com.au>
--
Director, Saosce Pty Ltd (OSIA Member #50)
Company Secretary, Safecoms Cyber Security Pty Ltd
--