Chapter 2: Who is the most important person in the room?

3 minute read
What is DevOps?

What is DevOps?

DevOps is the continuous delivery of prioritised value to an organisation. For more click here.

Atlassian Fastrack

This is a Summary of the second chapter of a book Daysha DevOps published titled 1Faat (one feature at a time). The book is an ongoing summation of our consultants experience as they help our clients to transform digitally.

The most important person in the room when it comes to delivering software is the customer. To be clear the customer is the person using the software not the business sponsor. Ideally the customer is represented by a product owner but even if the role does not formally exist the key here is accountability to the business for benefits (ideally measured in money).

Once delivery teams are aligned with customer-centric goals, the next most important step is to coordinate teams in determining when a task is considered done. In the realm of software engineering, this is referred to as the ‘Definition of Done.’ This becomes essential for organizations aspiring to attain levels of agility and efficiency characteristic of 1FaaT™. No work is considered complete, and teams don’t receive bonuses until it reaches a production deployed state.

The crucial idea here is that everyone involved in a software project must share a common understanding of what done means, particularly the business sponsor. When you engage with a delivery team, it’s essential to ensure that when all individuals definition of ‘done is aligned. Any discrepancies indicate a barrier that must be addressed for incentives to align and accountability to be established. Anything less than this results in measuring ‘done’ in silos, such as completing test. The definition of done for less mature teams can be Continuous Integration and as a team improves this will be Continuous Delivery.

For a definition of done to truly succeed we need a team leader to facilitate rather than impose command-and-control instructions at a micro level. A tried and trusted way of progressing towards 1FaaT is to use the Theory of Constraints which involves incrementally moving the definition of done forward through Kaizen bursts, also known as the Plan-Do-Check-Act cycle.

Once teams share common goals, corresponding reward structures can be implemented. In many large organizations, bonuses are divided into a company and an individual component. It is recommended to replace or subdivide the individual part to include a team metric, such as cycle time. This ensures that all delivery team members align around a common measurable objective, such as reducing lead time by a certain number of days or reducing the change failure rate.

Establishing enduring delivery teams is imperative. In the current organizational model, technology investments are often delivered as projects with a defined start and end. Once the application is built, the team hands it over to a new team responsible for ongoing support. However, this handover approach creates a situation where individuals, aware of their impending reassignment, might take shortcuts, such as knowingly concealing defects that may only surface after the handover.

Enduring delivery teams eliminate the concept of ‘change projects’ and the transition to Business As Usual (BAU) teams. The traditional notion of projects is challenged, as highlighted in Mik Kerstens’ “Project to Product” book. The team constructing the application is the same team responsible for its ongoing support albeit reduced in size to meet the reduced requirements.

One of the key concepts in 1FaaT is ‘cultural debt’. We are all familiar with technical debt but organisations are also capable of cultural debt which is manifest when the ongoing opportunity for improvement is rejected. ‘That will never work around here’ is a comment to watch out for. In later chapters we explore how to address cultural debt.

While cultural debt doesn’t appear on balance sheets, it is a tangible issue. Leaders risk losing credibility, and valuable Intellectual Property (IP) can be lost as good people depart or wont join an organisation because of poor organizational culture.

Link to Book

Previous Chapter

Next Chapter

POSTED IN: Agile, Agile Best Practice, Agile Methodology, DevOps culture