Governmental Kanban
Next: Ministry of Silly Ideas
Governmental Kanban
How would such automations and new ideas presented in previous post on open ministry/open municipality be developed? Through governmental Kanban for example. If you do not know what Kanban is, see the end of this chapter for one way to implement it. Shortly: daily meetings to go through what was done on the previous day and what obstacles people have + find someone to help overcome those. Everyone presents their work every day and team helps with problems.
Development of software products is best done interactively with primary users – people who will use the service in the end. When primary user visits physically or online the daily Kanban sessions, the team can ask for opinions when they run into internal arguments of what the users’ really want. Having a real user a few meters away is a great way to resolve these questions, otherwise it is too common for arguments to loop back and forth indicating people are basing their opinions on feelings not on factual needs of users. Joining also helps the primary user to understand what constraints the development team has.
The people who have invested their ‘automation budget’ onto some initiative make perfect primary users – project is something they are enthusiast about, and will be using the end-result themselves.
Over time one can think development where most public projects publish their Kanban boards (or whatever agile method they choose) online. Exceptions would be a small number of security or foreign trade negotiations related projects.
Then all projects would be in direct contact with future users who follow progress on daily basis by participating to meetings, following source code on repositories and adding issues (opinion, proposals, findings) and commenting on them. Projects ends when the users - who are also investors - are satisfied with the results and its usability
Kanban author style
The agile method you adapt does not really matter as long as it produces good results. They all are based on concepts that allow rapid learning from the environment and adapt to it. Adaptation happens both at the product/service level (what should it do?) and also at the process level (are we working well together, are we making right decisions?).
Kanban is one agile development method that I have been using and like. Following is one description how it can be done.
Some of the key principles of agile are:
Everyone is in the same team together. There is no separate product management, development, operations, care, service design etc. units but just one team that is solely responsible. There is no one else to blame when things go astray. The team also needs to have the money to implement the project (the budget). If this is not true, you have been fooled into the salt mines and should look at the ceiling to find the closest “Exit” sign.
Agile teams do not hang themselves to old decisions. If it does not work, change it. Decisions are done together. This is possible because all relevant parties are on the same team.
Work is done in teams. If there are errors, you cannot pinpoint to a single individual as every change has been reviewed (thumbed up) by several team members and there were multiple people working on the same task. Forget about blame and focus on fixing things.
Work is done directly with customers. If something is not requested by a customer, don’t do it. This leads to developing quite different things from regular way. Rather than developing a product, you are solving a customer problem and whatever stands in the way of their success, you need to figure a way to solve.
The rest if a summary of personal experiences of running one project this way in a galaxy far, far away.
In Kanban everything happens through the Kanban board. All work is there and no other work gets done outside of the board. The board is divided into columns that represent the phase where work is – for example waiting for someone to pick it up or under development. We used post-it notes to put stuff to the board and move it around. Kanban is the art of moving stickers around on a board and the world around you chances as the result of it.
Work is done in lanes where each lane represents one unit of work that can be accomplished in relatively short time. Use cases are split into task with each task taking about a day or two. Small sticker was attached to each task to show who is working on it. Multiple people work on the same lane, you’re not supposed to do work alone and every day at regular time the team meets and we move yellow stickers on the board forward and organises help if someone is stuck on something. The people on the lane take the use case from beginning to production.
We had two boards- one for business (customer leads and ongoing cases) and another for development. Every Monday we went through the business board, new cases, new requests or wishes.
Development board went through 3-4 bigger iterations but finally it was kind of split to two parts: backlog of high-level user stories and ongoing work on lanes. Your mileage may differ.
The high-level backlog part had both unordered user stories (“new ones”) and prioritised user stories (“discussed and accepted”. Prioritisation was done with business filter (active customer cases in priority order).
Every Monday after the business board we shuffled the high-level backlog removing stuff, discussing and prioritising.
From the prioritized backlog stories, people could pick up items to work lanes when old stuff was finished (in production). When a user story entered the “ongoing” side, people who chose to join a particular lane, divided it into smaller tasks and allocated themselves to tasks.
The development board had more changes over time. The reasons for changes were that something was not working. At one point we never fixed technical debt, at another point it seemed most people opted to work on technical topics (shorter things right in their comfort zone), at one-point people were not following their topics until they reach production etc. You solve problems like this simply by changing board (i.e. way of working), not by trying to motivate people or giving strong speeches.
Every day at 10 AM we went through the board to see how items were moving. This was originally set so because we had one team in a nearby city (170 kms away) and starting at 9 AM would have required quite early wake-up for them. Daily usually took about 10 mins. We also had a principle that if work on some user story lasted more than two weeks, it needs to be split so that we can close them faster. Otherwise, there is risk that someone works on an item for a month or so until we notice that it was not what customer wanted or for some other reason unnecessary.
Dall-E generated image of a team looking at a Kanban board.
About every two weeks we had retros. First, we took a general pulse with voting with red or green notes on how happy or dissatisfied are people. Then we looked at past promises how we did. After that we collected good or bad observations on stick-it notes that were then categorised to rough groups of good and bad.
We divided into teams and each team worked on one group of similar negative issues to come up with suggestions. We selected usually 2-4 suggestions as something to try out for the next 2 weeks to see if they solve the problem or not.
We also had tech talks about specific technical topics on ad-hoc basis. Sometimes right after Daily or sometimes agreed later on the same day.
We had two complete environment – one for pre-production (smoke) and the real production environment. For both we had setup complete end-to-end tests for all the major use cases we had for customers. These were run once every half-an-hour just to check whether something has broken or not.
We visualised the status of the system on two radiators (status screens with tiles; each tile showing the status of some part of the system). Radiator showed things like is software passing automated tests and how are we doing in deployment. For visualising the status of software, we showed for each repository how the unit/end-to-end tests were doing and who was the last person who modified it. If a tile went red, we knew immediately who had committed the latest change.
For production and smoke, we had similar radiators where we visualised stuff like how the backend on the cloud is doing and how the devices on the field are doing. Information to questions like is database responding fast enough, are microservices responding correctly or are there slow answers, if there are critical alarms from devices etc.
If there were critical errors, we also posted an alarm to team instant messaging app on specific channel.
The radiators are a generic concept and can be used to visualise the status of any system. For example municipality could use it to show the top status of things like electricity network, water works, education etc. based on agreed upon indicators. i.e. it is not self-evident what the overall binary (good, not ok) status of a complex underlying reality is.
Radiators visualise the state of the system in simple to understand grid with contact information for responsible person.
Every day two developers (later just one person when team was smaller) were responsible for ensuring that all radiators are green. We called this the rotating ‘Hat’. If there were errors, the first place to look was to either look at alarms from devices of go to the cloud where we collected all logs together. This way it was easy to roughly pinpoint the device (we had a device oriented service) or cloud service under distress. Principle was that the “hat” didn’t need to be and expert to know-it-all, just acts as first line for finding what is wrong and then asking around for help. Someone who would have more know-how on the topic would help. This way the knowledge how the backend was built and how the devices work slowly spread among the whole team.
We had a principle of sending developers to field trials. There is nothing so motivating than having real end-user breathing to your neck when you turn on the power and your thingy either works or not.
As we were looking to new market, we also did a few user studies ourselves. These were university students doing their specialisation studies. One also with an external provider.
During first field trials we set up direct error reporting with customers using common Internet tools. One customer also had direct phone number where to call a rotating developer.
All aspects in the same team – sales, business development, own service designers doing package design, videos, UX, roll-ups, user studies, development team for software, partially own funding independent of the business unit as we did draw on external sources and some internal innovation funds. We ran and adopted our own way of working loosely based on Kanban, managed and run own cloud service and managed the devices on the field via remote care and service. When things went pear shaped, all the culprits were in the same room and it was us.
You may ask what happened to the project. We ran successfully under radar for quite some time until finally had to “legalise” ourselves inside the larger company and follow official processes. This is when the corporate immune system found us out and now yours truly is a startupper and weird writer on substack.
But that is another story. If you are interested in startup-life, this tweet from Pascal Bornet summarises my experiences of the amazing startup life pretty well.
Why Agile Works?
The traditional explanation is that by putting all people responsible in development – management, sales, development and care into same unit in the same floor next to each other removes barriers of communications and allows fast learning and prevents generating any excuses as there are no other teams to depend on.
In times of great turmoil, the organisation that is the fastest at adapting (not necessarily the richest in resources) survives.
Important as this is, there may be other reasons at play as well. Let’s take a totally different view.
No other management practice has such uncanny resemblance to religion as agile practices and religions as forms of organising work have sustained the test of time over thousands of years – both when there’s been thunder and during dull and steady periods. A short explanation of similarities is in order:
Agile practices organise your calendar and have regular rhythm. People excel at forgetting. Regular grooming sessions where customer cases, their needs and overall product vision are gone over and over every week instil the general target and overall strategy so that even the slowest learners know them by hart after a few months. Same as regular services of religions where the central pieces are gone over and over (be nice to each other etc.).
Regular services of religions are also great at introducing people to each other that have nothing more in common and the common cause creates a positive atmosphere for getting to know each other. Similarly, the daily Kanban or other agile meetings are great at team building. It takes mere weeks before a new person feels familiar and communications start flowing effortlessly.
The space around developers is well controlled with various visualisations like Kanban boards where activities are presented. Everyone can see all the time what is ongoing, who is working and what is progress. All commercial and other unrelated messages get a trip to the bin as wall space is limited. The colourful stickers used resemble – at least if you have bad eye sight – similar colourful stained-glass windows at sacral buildings and the sticker texts contain the core vision and this week’s important texts.
It’s common to send regular developers and designers to direct customer meeting. Great motivational tool and helps to spread the knowledge what customers want. As a concept this is very much like “everybody can be a missionary”.
There is a grand long-term vision – ‘paradise’- towards which the team strives through a narrow and hazardous path.
These methods simply work with the human mind and have survived the test of time in times when totally unrelated world views have been popular. Agile methods have through trial and error found the same processes as most effective way to organise humans. I personally predict agile methods long-lasting success in future.
The only thing missing from agile are breathing exercises. Hymns (religious and other) work because the rhythm forces singers to breath in and out in slow and peaceful manner. This is known to have calming effect on the parasympathetic nervous system. Perhaps in future agile aficionados gather all around the world regularly to the Agile Mambofest to sign both exhilarating and calming tunes.
New research also indicates that standardised rituals have tended to appear hundreds of years before the concept of gods arose requiring same rituals to worshipped them. This might indicate that agile practices will eventually evolve to ‘The Supreme Agile’, that will require people to regularly move yellow stickers around on the wall to please the higher being(s). No doubt complex patterns of movement will evolve.
(Science News: Complex societies gave birth to big gods, not the other way around, March 20, 2019, https://www.sciencedaily.com/releases/2019/03/190320141116.htm)
Summary of Agile
In a fast-moving world ability to react quickly becomes the key success factor. The best visibility into the customers and markets are at the individuals with direct interaction with customers. In agile the core concept is to help people to think like a leader, to maximise the amount of individuals in the organisation that think they have the mandate to say ‘ I will do it’. The form is free.
Summary of Governmental Kanban
In Governmental Kanban agile methods are applied to developing public services. The team is fully responsible for development with own budged coming via Citizens’/Enterprise Automation Budget concept. The primary user participating into daily Kanban is one of the ordinary citizens/enterprise funding the development.
Development is visualised in public boards, stakeholders may make additional suggestions during development as issues, development results are open sourced so other teams (public or private) can learn and use modules.
Next: Ministry of Silly Ideas