Agile shines a light on dysfunction. Once the dysfunction is exposed, you have 2 options: 1) fix it or 2) sweep it back under the rug. Which will you choose?
How does Agile shine a light on dysfunction? All Agile practices are designed to unearth sub-optimizations.
In the previous posts I described how we designed cross-functional squads aligned around strategic goals. A key benefit of alignment is that it automatically delivers an increase in speed of delivery by dramatically reducing, or eliminating, the dependencies and bottlenecks which so often slow us down. By aligning people around goals and outcomes you essentially streamline your organisation and expose the bottlenecks in resource.
In the previous post I described our squad principles and roles. In this post I’ll talk about the broader framework in which the squads operated — some of the ceremonies and practices we introduced to provide visibility and coordination between squads.
I spend most of my days with large digital focused organisations. They usually have diverse platforms and scores of people trying to continuously deliver. But, like all huge organisations, implementing change, whether a product, process, business practice etc is a mammoth task. They talk agile, but to many, it is an elusive as a handful of sand. At the same time, agile has long since passed the tipping point. There are too many experts screaming it from the rooftops.
In the previous post I talked about the process of moving from a functional to cross-functional structure. In this post I’ll describe how we used Spotify’s model of squads and tribes as a guide. What we ended up with was quite different from Spotify, but it relied on the same principles. I’ll also outline the values and roles within our squad model.
In many of the places that I have worked, both as a consultant and as a part of a product delivery team, it is usually a case of keeping the Enterprise Information Security team (EIS) at arm’s length. Truth be told, many teams hold to the old adage that the less EIS get involved, the better. Even more so with agile delivery, as the focus towards shorter, more targeted delivery means that EIS is a thorn in product delivery’s side. And though this article leans towards agile delivery, the points made are equally applicable to any waterfall delivery.
Beyond the obvious reasons why alignment is sensible, for me alignment was critical in order to promote speed. I believed this would help achieve one of our key outcomes - to get faster.
Lean Startup and Design Thinking are two complementary principles that can be used in the process of creating and building new businesses, products or services. These principles are widely used in large and small organizations. But what is the difference, and when should you use each?
Before we dive into that, let me first explain both principles.
Recently, I have undertaken a number of roles as an Agile Engagement Lead, working with large corporates as they began the journey of migrating their operations and delivery to agile ways of working. In most cases, I was starting with entirely new teams who had absolutely no agile experience. It was challenging, but interesting as I had to develop a systematic approach to rolling out Scrum. There were a number of hurdles that kept on repeating themselves and along the way, I was lucky to be able to pilot a few new approaches
Have you ever had a boss who rejected your idea? What can you do about it? Pretty much nothing.
Unhappy with the company direction? What can you do about? Pretty much nothing.
You are assigned to work on something that you think is a waste and possibly detrimental to the company. What can you do about? You get where I’m going with this.