It’s not all about the team.
For Agile to work in a large program or a large organization, the cross-team issues are even more important than how well teams function individually. This is a common phenomenon in the world: that relationships between things are even more important than the things.
There is a trend today that I find troubling: non-technical release train engineers, Agile coaches, or others in Agile leadership roles who are non-technical, leading the way for Agile ceremony planning without including technical thought leaders who know the technical side of Agile (which today is CI/CD).
Technical practices are the backbone of Agile. It is the technical practices that make Agile possible. If you don’t center discussions around technical enabling practices, you are wasting your time.
Don’t get me wrong: there are non-technical things about Agile. Things like a Lean Portfolio, retrospective, and backlog grooming. But if you want to improve those processes, you have to include a discussion of the technical enablers that make improvement possible.
Welcome to Interview Series! In this Series, we ask questions that you submit through our social media channels to our consulting practice leaders.
Having played senior leadership roles in many solutions delivery organizations, we have witnessed both the presence and absence of a Culture of Commitment.
More often, organizations pervert the notion of the Sprint “commitment” with crushing delivery pressure or a lack of a support structure that allows a real commitment culture to take hold. For these environments, you can see the team do a collective “Whatever!” when Sprint Planning ends and everyone is looking for the commitment to the Sprint Goals. The real “commitment” is just to get the Sprint Planning meeting over and done. It is these types of organizations from which the Scrum Guide felt the need to “protect” us by removing any notion of commitment.
Project oriented organizations focus entirely on getting a related set of intent packaged into a container called a project and seeing that entire container move through from requirements generation to software release. Release-Orientated organizations are singularly focused on continuously getting releases out the door that maximize business value delivery without being constrained to only releasing related business intent in the portfolio. To achieve the continuous release of software systems, organizations must apply lean thinking and principles to every aspect of their delivery frameworks and minimize the overhead associated with making releases with high quality. While Continuous Delivery has become a very popular destination for many software engineering and IT shops, Release Orientation goes well beyond the rapid feedback and rapid test and release cycles of Continuous Delivery. Release Orientation is focused on realizing value through regular and frequent solution releases going into production (or customers’ hands) – thereby realizing continuous value for the business. In other words – Continuous Concept to Cash.
As experienced leaders, we expect that our managers and executives trust us as well as give us autonomy in decision-making. Some call this empowerment. The secret for this empowerment begins with trust.
