One of the big Agile mantras is “Deliver Value Sooner”. They get all excited when I tell them about the client whose Agile discipline was, well, not disciplined at all. But they doubled their financial benefit purely by delivering value sooner. It’s like a before and after diet picture. We love looking at it, but are the results typical? I assert that they can be, but you need to break down the need for big-bang results.
What on earth does having your ducks in a row mean anyway? Does it mean everything is ship shape and Bristol fashion? And what the hell does that mean?
I tend to say I’m a Designer by trade, but a Change Manager by heart. But I also add that it’s all the same, and here’s why.
Of course, it does matter what you design. Whether you’re in Product design, UX-design, Business Design or Organization Design, requires different skills and experiences. However, I do believe that they all require a similar mindset.
Could you introduce yourself and what you do?
Sure, I’m Luke! I’m a change management professional, currently working as a consultant for Agilisys; a public sector consultancy. I help organisations change the way they work and try to ensure everyone’s happy about it!
There are a variety of definitions of change management, but how would you define it?
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.