A paradox is something that is seemingly absurd but really true. When I experience complexity and uncertainty, I find comfort and power in paradox. It opens up creativity, possibility, and collaboration. Let’s take a look at 4 paradoxes we need to navigate in the agile world and beyond.

Once you assemble a high-functioning DataOps team, it’s time to establish agile mindsets, skill sets, and toolsets. Second part of a two-part series.

To create a data-driven organization, you first need the right DataOps team, a topic we covered in part 1 of this series. The next step is equally important. True transformation takes agile mindsets, skill sets, and toolsets.

My wife and 2-year-old son were playing with building blocks.
A single adjustment to his construct was the genesis of this post.
I made one adjustment to a toy and delighted myself on how the successive improvements flowed from one to another.
My son was delighted that he had a new toy.
If this post brings me some mirth when I reflect on it a few years from now, then I’ll consider it a success.

Milestones mark miles. They are made of stone. They are hard to move and are no longer valid once moved. They don’t exhibit agility, nor do they need to. They resemble tombstones and are often referred to as ‘dead-lines’, or ‘drop dead’ dates.
They don’t convey any expectations on why you want to get to where you’re going, how you might get there, how else you might get there, if you’ll make it there at all (the level of safety en-route), the quality and experience of your journey nor if it’s even the right destination, given your intent.

When you start to scale and have multiple products and/or teams, alignment becomes paramount. The general trap is to try and control things to stop misalignment form every happening by adding many layers of bureaucracy — or as I like to call “forced-alignment”. This stifles creativity, does very little to keep your people motivated and usually degrades team velocity.
But there is another way, a way to keep teams and product aligned whilst still allowing for the speed of autonomy.

When an organization has made the decision to adopt an agile way of working, they often only acknowledge the impact to teams. However, there is also a significant impact on leaders and middle management. This shift requires them to change the way they have been managing and delivering past success to the organization–often without a seemingly tangible explanation as to why.

I recently joined a new organisation to support them in what they had termed an ‘Agile Transformation’. As I transitioned from my previous company to the new one, I stopped to reflect on what an Agile Transformation really means and what was likely to affect the success of this. I very quickly came to one conclusion, based on my observations from all the companies in which I have worked as an Agile Coach. Transitioning teams is easy; transitioning organisations is hard. Why would this be so?

Agile coaches can be squeamish about metrics to evaluate how effective their efforts are because ultimately results are outside of their control. Yet we all like to know that our work adds value and makes a difference; when we feel we are not seeing positive results despite our best efforts, we will look to make a change in that coaching relationship. Metrics could support conversations with the people we coach about how things are going and if coaching should continue with them or not.

“We’re going to invite people from 40 product teams to meet for 2 days. Our goal is to map dependencies between the teams for our enterprise initiatives and determine how we might need to shift priorities for feature delivery across teams.”
It was a big ask. Roughly 200 people in a large room. Mapping out future work and dependencies on the walls, tables, and out into the hallway. It can be overwhelming to have so many people in a working session together. The goal was to create smoother delivery plans across so many teams. In my experience, big collaborative work sessions benefit from a very small amount of pre-work by attendees. The session is for work to happen.

Thanks to the Google research on Project Aristotle, we know that psychological safety is critical when it comes to creating and sustaining effective teams. People need an environment where they are free to take risks, encouraged to speak their mind and not ridiculed for asking what may appear to be a stupid question. In my experience, creating this kind of environment comes in large part from trust within the team. To build trust, you can host a team happy hour, or participate in team exercises like axe throwing and trust falls. When people start to let their guard down and open up a bit more, I believe that it accelerates team and trust building.