Johannesburg, 19 Mar 2021
Describe the typical software development cycle. How does Chillisoft’s approach differ?
I’m going to preface this by saying there are thousands of different variations out there, but the most common approach today is the agile approach. If you look at the most agile companies, they work in two-week sprints. This means you can only have 24 chances to release in a year, and for us, that is absolutely horrifying. How can you only have 24 chances to go live? That means we only have 24 opportunities to correct where you’re going wrong! Only 24 opportunities to pivot, that’s just terrifying. Why can’t you have 100 opportunities?
Chillisoft has developed the ability to run super-tight cycles:
- By applying the lean approach to software development, which is all about putting practices in place that allow you to release often and frequently, eliminating waste from your software development process.
- Using continuous deployment/delivery if it suits the client’s environment and needs.
- Optimising our processes and practices to make change easier and to give the client more opportunities to go live.
If you have more opportunities to change, what happens? You learn and improve!
This is the biggest difference and a core value proposition.
How detailed must the requirements be before the software development can start?
This is a super-interesting question; because of the approach we’ve adopted and refined, they don’t have to be very detailed at all. There is an inverse relationship between how many times you can go live and how detailed requirements need to be. The more often you can go live, the less detailed the requirements need to be, as there are more opportunities for a full feedback loop between developers and the user and therefore more opportunities for a course correction if what has been developed doesn’t align to expectations, or simply doesn’t work as well as it was thought it might.
There is of course a proviso. If a client wants to engage for a fixed term and budget, then they have to have a clear understanding of what they are looking for, and therefore fixed requirements.
However, when clients aren’t sure what the solution needs to look like and are willing to path-find with us in a more flexible way, then the requirements do not need to be as defined before we start development.
Another reason we’re able to path-find in this way is that Chillisoft’s senior developers are comfortable interfacing directly with business, without the need for a BA, and then communicating requirements to our teams. When you layer this ability over our process (which is going live with changes as soon as possible, uninhibited by a predetermined sprint cycle), we can get iterations of the solution into the clients' hands for feedback more frequently – in some cases, daily!
How do you define a thin slice?
I think this is best answered by starting at the beginning. Software development is a bit of a mixed field that stems from a combination of other fields: maths, science and engineering. When it comes to planning and project management, a lot of the know-how was initially borrowed from engineering, specifically construction.
This idea of “building” something has been carried through to the software industry as a metaphor. We reason about and plan what we do in terms of building something in a physical space.
In construction, you start with the foundations, then your walls, windows, and finally your roof. To build, you must construct your building in horizontal layers very much like a cake. You can’t build a building in vertical layers. You can’t build some roof then some walls and finish off with some foundation – you are constrained in what you can do because you are building something physical, you can’t just ignore gravity or structural integrity.
When I was being taught, they literally used the building metaphor. I was taught to work sequentially starting at the bottom with the foundations (the DB) and work my way up to the UI. This is what we call horizontal slices in software development, you build one whole functional layer before moving onto the next one which uses the one you just built. The problem with this approach is that you are unable to release often – you release only once all layers are finished.
The reality is that we’re not creating physical things, we’re creating virtual things that don’t have the same physical constraints, such as gravity, we can build in a vertical layer. This means we can build a part of the roof (UI), one wall (business logic) and a part of the floor (DB) and then make an assessment and get feedback.
This is what we call a thin slice. It’s simply when we build a slice of the system, end to end, from UI through all the logic, through all the data and the back up. The idea behind a thin slice is that you try and build as narrow a piece of the system - end to end - as possible. Doing this allows us to get iterations of the solution into the hands of the end-user and therefore to get feedback. It also allows us, the developers, to learn and test our assumptions around a variety of things, such as tech and business domain.
If I can release a part of the system which clients can use and it adds value to the user, that’s a massive win for everyone – especially if I can learn while doing it so that that learning is fed into future slices. A thin slice is building things vertically, building as only what you need to achieve your goal, getting feedback on that goal, then using that feedback to amplify your learning.
Do you have to compromise on software quality if you are trying to get to market quickly?
I don’t believe so. Unless you are incredibly lucky and get everything right the first time, being first to market is a process that involves getting something into the hand of end users often and adapting to feedback.
Adapting to feedback either requires change to existing software or building new software. If your experiments are still small enough to rebuild them then you could argue quality can be traded for speed. However, that phase of the process doesn’t last very long, at some point, usually sooner rather than later, it isn’t an option to rebuild, you have to make changes to existing software, at that point higher quality speeds up changes.
Don’t get me wrong, everything is a trade-off, it’s just that the “more speed for reduced quality” trade off stops working faster than most realise – because of this there are some quality practices that we very rarely compromise on, such as TDD, we are very clear on where we are willing to compromise and where we aren’t.
When we do compromise, we leverage the red bin approach through which we empower anyone on the team to raise issues or declare a compromise, so that it is collectively understood and solved at the appropriate time. This really helps to make compromises more transparent and will often start hard but needed conversations with clients.
In essence, we don’t really compromise, we strategically defer!
What does ‘showing up, delivering value’ mean?
For me ‘showing up’ means being available, mentally present and engaged. During lockdown, we worked 100% remotely because of the pandemic. This meant we had to get ‘showing up’ right in its purest form, as there was no physical presence to hide behind. A big part of this for me was practicing active listening during meetings, as they were all online, and it is way too easy to zone out or just continue working on something else during those.
‘Delivering value’ is always contextual, for me it is about knowing who your users/customers are and how what you do impacts them, how your actions add or remove value from them.
Our projects have very tight and very real deadlines. This means that business has a very real need to manage delivery risk, what was going to be built and how long it would take.
In one of my projects, in order to try and mitigate this risk, the business had asked us to spend two weeks going over the requirements and doing detailed estimations to get the size of the project. On the surface this sounds like a reasonable activity; however, this is big up-front planning, which is notoriously inaccurate in software development, so the value of delivering estimations alone was questionable. Because we understood the value the business was trying to get from this activity, we proposed also building a non-functional UI, which allowed them to see what was going to be built. This added meaning to the estimations and allowed us to have constructive conversations around what we could descope and the consequences thereof.
In this project, after development got underway, we worked closely with their BA to understand the problems that the requirements were solving. This allowed us to understand how we were adding value to the end users, which allowed us to unpack a lot of issues that would have only been discovered after the deadline. This was only possible because we understood that ‘adding value’ isn’t just following a requirements document to the letter and we only understood that because we ‘showed up’.
Showing up and delivering value is our way of being; it is how we do business and do life. It also shows up in our commitment to understanding how every single action we take, impacts our clients and their end-users and ensuring these impacts are always win-win.
Share