The Accelerate Book
The Accelerate book has been on my reading list for a long time, and I bought the book last year. I checked it a few times, and I thought that I was already familiar with the book’s content, so I didn’t read it from the start. Last Tuesday, I visited Udemy’s new Ankara office; we talked about some software engineering practices to improve our software development and delivery performance with a few friends in the kitchen area. They also created a slack channel to discuss these things. I decided to check the book again and then read it.
I read the first and third parts more carefully, but I just looked over the second part about the statistical practices to analyze their survey data.
I read many things about the technical and management practices of Agile and Lean software development approaches. I applied some of them systematically with a team for a 1.5-year project, using some of them as my daily development practices. At my previous company, I spent many hours talking with people at every level to make them aware of these practices and their benefits. The book put most of them together and showed me the statistically significant relationship between them; that’s exciting.
The book collected all of these theoretical things about these Agile and Lean practices and asked people about their experience to infer the relationships between theory, practice, and outcome. They cover 24 capabilities that are categorized into continuous delivery, architecture, product and process, lean management and monitoring, and cultural. You can see these capabilities and their positive relationships to software delivery performance, organizational performance, job satisfaction, etc., here.
Technical practices such as test automation, trunk-based development, empowered teams can produce speed and quality together in software delivery. Speed and quality drive better business, improve organizational performance, also make employees happy. Happy employees can produce better software, and this is a virtuous cycle. These inputs and outputs affect each other.
The book suggests measuring software delivery performance with metrics:
- Lead time(the time it takes for work to be implemented, tested, and delivered),
- Production deployment frequency,
- Meantime to restore(how quickly can a failing service be restored?),
- Change fail percentage for production changes.
And as you see in the first box at the diagram that I put a link above, you need transformational leadership to support all of these activities. People-oriented culture is the root of all of these things, and if you miss it, you only fool yourself. And culture is the sum of all employees’ attitudes in an organization. You can’t change the culture as a whole, and you can only convince people to change their attitudes.
When I think of my previous experiences, I feel I’m lucky in my current company. I can’t say everything is perfect, and also, I can’t say I’m very proactive as I used to evangelize these practices, but we are doing good things. More importantly, many people at every level are very eager to support these activities to improve our technical practices, software delivery performance, and organizational performance to be a better-growing company.