I recently finished reading The Land Is Ours by Tembeka Ngcukaitobi. The book fascinatingly narrates the lives of the first 6 black lawyers in South Africa, all practising in the early 1900s.
There are common happenings in each of their lives: they all had the opportunity to study law in UK or USA, they all came back and had hurdles to jump over to practice in an increasingly discriminatory South Africa, and they all regularly fought cases resulting from the dispossession of land brought about by the Native Land Act of 1913 (hence the title of the book).
There is also a saddening common theme that runs through a number of their lives: some of them ended up self-destructing. Because at the time there weren’t lawyers representing black people, they were in fairly high demand. They also found themselves becoming increasingly involved in political activities through various organisations such as the South African Native National Congress (which later became the ANC). These increased demands on their time resulted in dropping a number of balls they were juggling, such as cases they had committed to for several clients. Some of their clients who had put so much hope in them ended up suing them, and one was eventually even disbarred because of his unprofessional conduct. One ended up taking to alcohol and dying early. Another ended up living an obscure life in Mthatha after a temporary period fame and glory. One of them, Pixley ka Isaka Seme rebounded and was able to build up his legal career again.
In software development teams that have adopted practices and tools that allow them to release value to the customers faster, a similar fate sometimes befalls them. There is a heavy weight of expectation of these teams, especially where there are a large number of stakeholders in a corporate settings; and increased pressure to deliver what each stakeholder perceives to be of value, in a short space of time. The end result for some is a similar self-destruction from burnout and loss of quality, leading to mistrust and increased bureaucracy.
Just as other service oriented businesses such as law firms have disciplines to ensure long-term sustainability, teams that build software also need to have some disciplines to ensure that they can deliver value to customers over the long term in a sustainable manner.
I’ve thought of a few, and this list is not exhaustive. It would be great if readers can post some of their thoughts in the comments section below.
- A stable prioritised backlog. With new information, there can be a change in what a team chooses to work towards delivering to customers. This should be expected from a team that responds adequately to change. Yet, despite this, what they work on should not be subject to the whims and spontaneous delights of every stakeholder involved. A stable product backlog gives a team a prioritised bigger picture of what they are to be working on, giving them an opportunity to take ownership of the delivery.
- Sustainable working hours. There are numerous articles floating around about “Developers in Silicon Valley who [insert stupid destructive habit meant for the appeasement of a VC with an over-inflated ego]”. While there are times when teams need to push hard in order to reach certain time-specific goals, the norm should be one where regular (i.e. daily) rest and recuperation occur. The alternative is a loss of quality due to working in a sub-optimal mental condition, burnout, and a high team turnover.
- Automated Tests. These ensure that functionality works as previously intended, despite continuous changes from different members of the team. Without this, one cannot have a degree of certainty that the change they are making is not affecting existing functionality. This results in fear of making changes, and individual ownership of pieces of code, instead of team ownership of pieces of code. Personally, I am a fan of TDD as a way of driving out the design of the code and creating a suite of tests as a measure to guard against regression errors.
- Continuous Integration. Code that each developer in a team writes should be merged with code from other developers within a team daily to ensure that the code works together, and there is quick feedback to initiate corrections if it doesn’t work together. When there are long-lived branches, the risk of incorrectly resolved merge requests is higher, and the cost to fix them greater.
- Code Reviews. Code written should be checked by another developer before being merged with other code, to ensure that it is understandable, maintainable, and adheres to some of the subjective standards that the team has set in place (e.g. naming standards, structure of functions and classes, etc.). This can take the form of pull requests when merging code into the mainline branch, or pairing.
- Code Retrospectives. In addition to code reviews, regularly meeting to continuously improve how code is being written is useful. It is in these meetings that the subjective standards of the team can be agreed upon, as well as looking for places in the code can be improved upon from new information gained since the respective code was written. This promotes a culture of continuous improvement.
- Limiting work in progress. The focus of a team should be on getting work finished and in the hands of customers, and not getting work started (yes, I know you have to get it started to get it finished). When individuals in a team start juggling multiple tasks at the same time, it actually slows down their completion of the tasks. The common excuse is normally ‘I am just waiting for [insert dependency], then I will complete it’. As part of this discipline, teams may also only start tasks which have no outstanding dependencies, and can be completed.
- Continuous Delivery. There are many internal and external stakeholders who have an interest in the software being written, and a team should be able to get software to them as soon as possible in order to get quick feedback, and make adjustments where necessary. A continuous delivery pipeline is a tool that enables this value to reach the hands of the stakeholders as soon as the developer merges his code with the rest of the source.
This is what I can think of while sitting on the bus on my daily commute. Anything I may have missed out on? Please comment below.
Patrick Kayongo 