Production line from the future for the digital public services

I am not taking a huge risk by declaring this “prophecy”. Things about which I will be writing, there are not so much a prophecy as it is a transfer of something that is quite actual in some parts of the globe. Production of digital public services is a controversial and complex area, intersected by different interests, expectations and rules. Conway law tells us (simplified) that the structure and design of the software reflect the structure and design of the organization which is creating the software. If we apply this law in the area of digital public services, we will get an easy answer why do citizens often consider them to be complicated, unclear, with poor quality, and not bringing the value as they should be bringing…

Looking in the future tells that things in the area of digital public services could be much better. There are mentioning terms as Cloud, PaaS, IaaS, DevOps, Continuous Delivery, Lean, Agile, Design Thinking… That, naturally, are not new concepts and by themselves we cannot present them as wonders from the future. But their application in the area of digital public services – well, that is more like a prophecy!!

But, let’s first go back a bit in the past. In the January of this year, an interesting IT transfer had happened. Jez Humble joined the 18F.

Source: https://twitter.com/jezhumble/status/692048962681843712

Jez Humble is one of the giants in the DevOps movement, a movement which is extremely popular for the last 5-6 years. Jez Humble is the author of one of the pivotal books from that field (Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation). In his career, he worked as principal consultant at ThoughtWorks, then as the Vice President for Delivery Velocity at Chef, then as a professor at Berkeley University in California, and so on. Simply, this is one of the great men in our industry.

The second actor in this tweet, the agency 18F, is somehow a different story. It is a digital services agency established in the middle of 2014. 18F is a part of government administration in the USA. The agency was created due to the enormous problems that American administration encounter when they were implementing HealthCare.gov system – despite the extreme political attention connected to the “Obamacare”, starting this service was significantly delayed and the system operations had issues with performance and functionality due to the inadequate and obsolete development process management. The main task of the 18F was realization of digital products for different government organizations. Working process used by 18F was based on mandatory usage of the lean startup model in the realization of digital services, where relationship with client organizations is defined by the cost recovery model. The similar agency exists, as well, in the UK under the name Government Digital Service (GDS). Their work model was actually an inspiration for 18F, which is explicitly written on the web page of the agency 18F. The approach and methods used by GDS are used in realization of digital services that, according to some estimates, bring savings of 20 million dollars, when compared to previously used approaches.

Government owned IT agency that delivers software every day? Common sense, but not common practice.

Focusing on the principles of Software continuous delivery) is becoming an obvious trend in the government owned IT agencies like 18F and GDS. By implementation of this work principle the goal is to minimize the time for the software delivery. In short, the idea is that software is delivered every day and sometimes even several times a day. Realization of this idea is not easy at all, and there are numerous minimum requirements regarding the organization, process and technical parts. For example, user demands on which developers are working at any time should be “small”, while the complete process of software delivery on the production environment should be completely automatized. Every day delivery of small (but also the complete) parts of functionality (together with automatic testing) reduces risk of errors and also improves the feedback from the software users. It is not needed to specially mention that error correction in this type of delivery is significantly simpler and faster to correct.

Jez Humble at his new employer has a goal to organize and improve the process of the Software continuous delivery. By bringing one of the best world experts in that field, agency 18F (and by that the whole government administration) is clear in showing the intention to improve the quality of the digital public services to the highest possible level. The transition from the traditional way of working in the government agencies (which had issues, for example, with previously mentioned HealthCare.gov system several years ago) into the Software continuous delivery way is not simple. The transition demands both technical and organizational changes, and in some big measure changes in the organizational culture which is never easy. Organizational culture is changed through making new experiences and practices. Including experts like Jez Humble represents a smart investment in the transition success, because this type of an expert will bring in the new experiences and new (technical) practices.

Interesting fact it that Jez Humble is not the only one who decided to this kind of a career step. His transfer is a part of a trend that is noticeable in the American government administration. The administration took a step forward and developed special contract models that enable this type of transfer (usually they are short-term or medium-term arrangements with very well defined goal)

Lean startup as the model in the production of the digital public services?

Causal browsing on the web page of the agency 18F will quickly bring you to a very interesting content – the information about their current projects. First glance on the Dashboard clearly specifies the main attributes of the process – incremental and orientated for continuing improvement through the feedback cycles. This development model is characteristic of the lean startup movement – fast production of the MVP (Minimum Viable Product), its testing and collecting the feedback based on the limited number of users, and improving the product based on the information from the collected feedback. Partial applications of this model in the area of digital public services can be seen in other countries, including Croatia (for example, in the development of the e-Citizen, locally known as e-Građanin, it can be noticed that the way of thinking and working goes in that direction).

But there are usually driven by the enthusiasm of the individuals and they are isolated experiments. Systematic application of that model in the organization and development of digital public services, unfortunately, is not that common and definitely in other countries is one of the stories from the future (that are told by the colleagues from the American 18F and the British GDS).

18F – phases in the life cycle of the service development (source: https://18f.gsa.gov/dashboard)

Transparency in this story from the future goes even one step further, as we can see in the 18F case, that for every service it is possible to see detailed information about the activity statutes and its metrics. The example on the picture is self-explanatory – it is a Kanban project board with the status for the current sprint for the project cloud.gov.

agile s

Current sprint status of the cloud.gov project (soruce: https://18f.gsa.gov/dashboard/project/cloudgov/)

Public Procurement as the marketplace for agile service delivery value?

One more segment of production of digital public services is important in this story from the future – Public Procurement. Agencies like 18F and other parts of the American government administration are using, of course, services from different external foreign vendors. The model mentioned earlier (discovery-alpha-beta-live) doesn’t have a lot of sense if the external vendors cannot be a part of it. And that brings us to the need of adapting the models for Public Procurement of their services (because the traditional models of Public Procurement for custom software delivery are incompatible with lean and agile paradigms. Not even to mention the Lean startup model).

Roughly, without going too much into details, Public Procurement model for the customized software mentioned by the colleagues from the 18F has several important points. The model should function on the principle of the umbrella contracts (on the level of the whole public administration) with multiple vendors. As a starting point, from the vendor it will be required, as a part of their evaluation, to live demonstrate their ability for agile software delivery so that the best vendor can be chosen (and for that it is easy to define clear and transparent industrial criteria). In the return, vendors won’t be required to explain their abilities in the bids (which will dramatically reduce the time and cost for preparing the bids). From vendors chosen in this manner, as a second step it will be ordered a development of the alpha version of the service. Based on what is learned from the alpha phase, the procurement of the beta phase starts and in this step a window for the competition is open. The whole process should be orientated for the use of small and short contracts, followed by a sequence of simple and transparent metrics that clearly indicate the vendor performances.

This lean approach for procurement and realization of alpha and beta versions for sure leads to the end product of a greater quality. By the way, we could also hope for the positive effect of having a healthy competition on the market (through elimination of incompetent vendors that don’t deliver the expected value level)

Will Jez Humble come to Croatia?

The models of public IT agencies like 18F and GDS clearly indicate that the future leads us in the direction of the fast innovation in the area of public services. Technologies today enable this rapid innovation cycle, but in the widespread use they are typically found in the startup companies. There are significantly less used in the enterprise IT companies (although the situation is improving more and more) and drastically less in the domain of public services.

As we have seen from the examples, it is possible to produce the digital public services in a better and more advanced way. The only thing left is to find the will and desire for the change, and probably a couple of Jez Humble’s would come in handy.