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

[Cameron Shorter]

Jack, Steve,

Can we get your comments added at the bottom of this post? Please add 
them. 
http://www.themandarin.com.au/82472-making-govhack-open-government-more-impactful/#disqus_thread

I've just got an email from GovHack National Director suggesting we take 
these ideas to the community, and it would be really good to see your 
ideas easily accessible as well. ...

On 20/8/17 4:03 pm, Richard Tubb wrote:
 > Hi Cameron,
 >
 > That is fantastic! Great ideas here! Well done! 😊👏
 > Post Red Carpet Awards (October 14) it'd be great to take some of 
these ideas to the community for feedback and collaboration. 😎


On 20/8/17 3:56 pm, Jack Burton wrote:
> 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,
>
>
>

-- 
Cameron Shorter
M +61 419 142 254