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.
Teams are not constrained by how much they can learn. They are constrained by how much they are allowed to try, as well as by how much they don’t know what they don’t know.
When Agile adoption struggles in a large organization, it is almost always because managers are in the way—that is, teams are blocked by rules or upper level decisions—as well as because teams don’t know that there are better ways than what they are accustomed to doing. Those are the two predominant kinds of constraint on performance that one tends to see.
Rules exist for a reason: to manage risk. It is therefore unreasonable to expect that managers will just say “Do whatever you think is best”. To say that would be to abdicate their responsibility to manage risk for the organization. Doing that would also lead to chaos: each team would invent its own methods, and so the organization would cease to be one: it would devolve into a collection of tiny tribes.
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.
In the third and final episode of our Agile Coaching Intensive series - Ken Fritz (Director of Software Delivery) overviews the agile coaching roadmap and key agile mindset shifts that come along with agile coaching. Watch this episode to unpack the career path and impact of an agile coach.
In the second episode of our Agile Coaching Intensive series - Ken Fritz (Director of Software Delivery) overviews the who, what, when, where and why of an Agile Team Facilitator. Watch this episode to unpack the evolution of an agile team facilitator in career path of agile coaching.
In the first episode of our Agile Coaching Intensive series - Ken Fritz (Director of Software Delivery) overviews the four main pathways of an agile coach's career and how the agile coach interacts with the rest of the organization.
There are many misconceptions about what Agile means. Here are a few of the most common that I've heard:
So then, what is Agile?
So you graduated with your degree in IT - how long ago? And you have been learning lots as you have worked at different jobs and on different teams. But you keep getting emails about taking this training or that course and wonder ... Is it worth spending the money? I've been doing this IT stuff for several years now, I know what I'm doing. What's the point of taking any of these training courses?
Transforming to an agile software delivery model is filled challenging, especially when you are working in an organization of a large scale. In large organizations, one of the most common practices to improve efficiency is to build an organization of specialists. Every specialist knows how to get their specific tasks done in the best way possible. Additionally, large companies typically have very large and complex software architectures for their systems. Between the specialists and the complex architectures, getting the entire solution delivered can be inefficient since it takes so much planning, effort, money, and time to get anything delivered.
The most intrusive inefficiency with these organizational models is that they are not designed with support for natural delivery flow.
Because of this, when transforming to a scaled agile model, there are specific guiding principles that can help determine the best organizational design to make your move to agility most effective. If planned and implemented properly, this agile transition will allow you to get the most business value delivered.
In order of importance, these principles are:
