Agility is the publicized target condition for nearly every enterprise today. The challenge is defining exactly what that means.
Based on my experience I don’t believe most organizations are actually targeting agility as their goal but rather an implementation of Agile.
🧵👇
The difference is significant. Agile is an output -- a series of steps, processes and methods that dictate how people should work.
Agility is an outcome -- a measurable change in the behavior of our teams, leaders and executives.
Given the broad global adoption of the idea of Agile and the desire to fit in, many organizations seek the path of least resistance to be able to claim that they, too, are agile. What ends up happening is an application of a method
-- a recipe -- designed to decrease time to market, improve organizational response time, drive up collaboration and the customer-centricity of the organization.
However, that's not how success gets measured for these efforts.
Instead of actually measuring whether the organization has indeed achieved those qualities many companies are satisfied knowing that Agile "has been adopted" and training has covered a significant percentage of the staff.
The tricky business of increasing an org's agility requires a deep, internal look at how work is conceived, prioritized and funded, how success is measured and how leaders and managers do their job not to mention incentives and performance management criteria (a lot, right?).
When this work is done, agility takes root ultimately leading to mature organizations who care less about whether they're using Scrum or SAFe or any other recipe but rather how well they're serving customers and are able to react to their and the market's ever-changing needs. //
• • •
Missing some Tweet in this thread? You can try to
force a refresh
I once met a team struggling to get their leaders to hear and incorporate user feedback on the Android app they were building. The team would actively test their ideas, collect their findings and share with leadership.
[🪡🧶] 👇
Their leaders would promptly ignore that feedback because it contradicted their own opinions. They took most of their inspiration from apps they “liked” and features they saw on their kids’ phones (neither the execs nor the kids were target audience for this app).
The only thing the execs did pay attention to was reviews in the app store. They would regularly point to these reviews as the only thing the product team should pay attention to.
While reviews are one channel for feedback, the team had much richer insight from their own work.
We put a lot of the weight of becoming a customer-centric organization that manages to outcomes and "tests and learns" on the shoulders of our leaders and executives. But it's a two-way street. Our teams also need to change how they work to increase the likelihood of change 1/n
Teams want their stakeholders to trust them to solve problems, allow them to listen to customers and empower them to make tactical day-to-day decisions. In many organizations this is a radical shift for these stakeholders. What do we give them in return for that trust? 2/n
Transparency. Radical transparency is the proactive sharing of information on a regular cadence both up to your leaders and out to your colleagues. Candidly putting on display your work, wins, failures & learnings is key to building the trust that enables agility. 3/n
Corporate innovation labs fail regularly. The way I see it there are 4 reasons for this:
1/ Talent -- intrapreneurship is a tough quality to find in your teams. When it is found, it needs to be recognized and nurtured in ways most big corps treat as theater.
2/ Equity -- innovation comes from creative entrepreneurs. These folks won't give up their best ideas to their employer for the promise of another 2 weeks' worth of pay. How big orgs compensate in-house innovators makes or breaks the "lab."
3/ Exit strategy -- on the off chance that a corp innovation lab finds a big idea, what will they do with it? Without a clear sense of how an idea "exits" the lab most intrapreneurs won't pursue true innovation.
There were some clear themes coming out of the presentations at #productized in Lisbon yesterday about #prodmgmt and #design and #culture. Here is a brief summary of what I heard:
1/ Very little mention of #agile as a problem or a choice. It was just assumed by all speakers that this is the way everyone works.
When we wrote #leanux we wanted to help product design and development teams collaborate more effectively and ultimately build better products for their customers. The overwhelming feedback from readers has been (no surprise) that they want to work this way. However...
What we didn't expect was the amount of teams out there telling us things like "my boss won't let me work this way" or "my company would never let us talk to customers." Hearing this again and again gave us the sense that there was (at least) another conversation to be had. So...
We wrote another book - #senseandrespond . That book took the conversation up a level to leaders and makes the case that to stay competitive in today's business world you have to build continuous learning loops with your customers. I believe many orgs heard this message but...