Companies that are slow to change, or at risk of falling behind competitors, do so because their employees don’t feel safe enough to fail. People value safety far more than predictability. For example, imagine there was a casino that always made you whole: It allowed you to gamble and win all you wanted, but if you lost $100, they’d cover your losses. Would you feel comfortable gambling there? Likely so: There’s nothing to lose, and everything to gain. Now imagine if companies provided the same psychological safety to their employees: You can fail here, but we won’t fire you. Instead, we’ll train you and support you so that you don’t fail again. Like the casino, there’s nothing to lose, and it affords you to make bigger-than-usual bets on yourself, or on your teams.

Companies looking to be more agile, however well-intentioned, need to ensure that team members’ safety (mental, emotional, career) is a top priority. Nobody will take on risk if they feel there’s no commensurate reward, and what sort of reward would be required for the risk of losing your job? (Spoiler: Likely none.)

And so, my hot take on “slow” companies; the sort of companies Agilists mock at conferences for being too cumbersome or process-oriented: Perhaps instead there is an institutional fear of failure that needs to be unwound and mitigated at all levels of the organization. Psychological safety, while easy to talk about, is incredibly hard to provide and continue providing. It requires investment – literal dollars spent – and time – sometimes years – to create. And once established, it remains incredibly fragile. Companies struggling with organizational agility should focus on the psychological safety of their teams before they ever debate whether to execute Scrum or Kanban. If the risk is removed, and the right values are encouraged, a willingness to learn will ultimately replace the fear of failure.

Prioritizing work and making decisions are two sides of the same coin. Perhaps they’re even the same side. Ignore the coin analogy, but recognize prioritization and decision-making are inextricably linked. Conversely, the inability to prioritize implies an inability to make decisions.

Many Leaders and managers pride themselves on having clear direction, purpose, and goals (maybe they even call them OKRs, whatever.) And yet, that conviction and clarity of what’s to be done now is rarely felt or seen by teams. Instead, teams are given multiple priorities, vague goals, and sometimes have no defined charter or purpose. This dynamic ultimately leads to competing priorities, putting teams on constant defense: Nobody is ever happy, and someone is always challenging the value of their work.

This caustic environment is easily resolved: Empower teams to make decisions by providing them all the information you have (include your own bias! It’s OK!), and then trust their decision is the right one. Establish a forced ranking system that demands focus on only one thing at a time (i.e.: limit work in progress.) If that’s not possible, then find a way to make it so. (That would be Leadership, versus, say, management.)

There are a number of prioritization frameworks out there, all aiming to help teams make decisions. Deciding to do everything, all at once isn’t a decision, but rather an abdication of decision making responsibilities. Multiple priorities (an oxymoron if there ever was one) lead to high WIP. High WIP leads to longer lead times. Longer lead times leads to delayed features and greater uncertainty of progress. You know the drill – you’ve seen it a million times.

Empower teams to force rank work. Drive clarity and enable feedback when the ranking seems counter to the broader objective/goal. Team and customer satisfaction are sure to follow.

As Musk moves into Twitter, he does so with a level of cockiness and brazenness we’ve frankly come to expect. None of his memes, tweets, snark, or actions are particularly telling: They reveal that deep down, Elon is insecure as any of us, he just has enough money at his disposal to be a dick about it.

At its core, Musk’s acquisition of Twitter is a leveraged buyout. You know, the kind that ran Staples and KB Toys to the ground. And like most LBOs, the name of the game is return on investment: Getting lots of bang, for the many bucks that’ve been spent. Cue the questions about how to generate income, keep advertisers, or chastise people who balk at paying anything. The intrigue here has nothing to do with the things Musk and his team are aiming for (high ROI), but rather that they’re being done in such a public and crass manner. But again, the dude is a jerk. He gets off on this.

Already we’re seeing benefits taken away, and employees asked to do more. What does more mean? Nobody really knows. I’m not sure Elon even knows. But there’s a mad hustle inside Twitter to make generate some serious ROI, even if it is deeply misguided. This is Twitter now, and like other LBOs before it, there’s not much anyone can do, except the one guy who’s pretty cavalier about it all. Alas.

LBOs usually end well after deep consideration of revenue, debt, risk, and market fit. You could also just push that aside and say “fuck it”, and go with your gut. Elon seems to be very much going with his gut. If this surprises anyone, it shouldn’t, and if you’re an overworked, tired Twitter employee, you should know it’s probably not going to get much better for you. Sorry.

This whole Twitter thing is a weird episode, but only because it’s so public, and the cruelty that’s exposed is so obviously wrong to everyone except its executor. At the end of the day, this is a simple LBO. It will likely go bad, because the value proposition of Twitter hinges on healthy, deep content moderation, and the new owner seems to be just fine not having that sort of thing. What’s left to say?

Twitter will remain fun until Musk debases it. I suspect that time is coming. I’ll stick around to watch the implosion, but not with joy. That’s for the sycophant in the Board Room, alone as he may be.

Early in my agile career, a mentor asked me what quality all good leaders had. I replied with something standard, like “good communication skills”, but otherwise couldn’t answer. Her answer? Good leaders were comfortable with ambiguity. Being relatively new to any sort of outside-the-box thinking, I had no idea what this meant, and went on with my day. But the interaction stuck with me, and the answer even more so. What did “comfort with ambiguity” even mean, and how could one get better at it?

Years later – years spent thinking about this and other leadership challenges (particularly through an agile lens) – I think I have an idea. So let’s tease this out…

When I think about ambiguity, I think of it as a function of change within a system. When change occurs, there are likely less knowns about what’s ahead than the previous state had. If you were operating at a particular speed within this system, your line of sight is now reduced. The risk of failing has gone up, and this perhaps requires more careful consideration of what decisions we’re making, before we continue. The fear of failing a symptom of ambiguity, and it causes things to stall.

We see this all the time in command-and-control ways of working: people are hired to do a thing and absolutely no coloring outside the lines is allowed. Things move smoothly enough, but if there’s a change in management or prioritize, things seize up. Not exactly a win for the organization, right?

The thing is, change happens all. the. time. People move in and out. Strategies change. Customers change. Being able to respond to change is, and has been for decades, a cornerstone of agile product development. And so if you’re comfortable with ambiguity – comfortable with change, risk, and the unknown – you will ultimately succeed, if only because everyone else around you is seizing up, scared to move forward.

So what’s this mean for Leadership? It’s critical that you enable your teams to be resilient to ambiguity. That means giving them options and the ability to own outcomes, and make decisions that help them reduce the risks they may face. It means communicating clearly what needs to be done (see, I wasn’t totally wrong), and trusting them to execute (after all, why did you hire them?)

Of course, none of this is new. It’s baked into the Agile manifesto and principles, it’s described ad nauseam in many leadership books. But in my world, being “comfortable with ambiguity” never made sense, and only just has this week. Perhaps now it’s worth giving those books and methods a re-read, knowing the best leaders are indeed those most prepared to not have all the answers.

The more I try and help teams adopt Scrum, the most I dislike it. And really, maybe it’s not Scrum so much as it is Planning. Plans change! And while the Agile community seems fine telling that to Management, we wring our hands when teams deviate from The Sprint Plan™️. Why? Indeed, the Agile manifesto calls out that responding to change is more important than following a plan. So what’s the point in Planning in depth, as Scrum would suggest we do?

Scrum feels rooted in idealism: That all teams are stable, cross-functional, with experienced Product Owners and a clear purpose. In reality, the most organizations are dynamic, with changing priorities, new and experienced talent alike, with organizational and funding models that are outdated. Applying Scrum to this mishmash of pros and cons feels a bit like willful ignorance: “Let’s just pretend everything is fine and be sure to close out your stories!” The duality of these environments – the reality the organization is present, and the space the Scrum Master is trying to create – is frustrating to team members who are likely incentivized in ways complete counter to “Agile values”. Trying to change behavior without changing the incentives is a fool errands.

And so what then? How do we get teams to change? Well it’s no secret that it has to start at the top, or at least at the highest level of an organization you can get. The higher up the mandate comes from, the easier (mostly) re-aligning teams to a different reality can be. But if that mandate doesn’t exist at all, your Scrum team may find itself on an island of Agile. Here’s how I’m picturing this:

In emergency services they call this the “span of control”: there’s only so much change you can affect (directly or indirectly.) Managers who are supportive of Scrum may never see lasting success, because the wider organization isn’t set up to support scrum teams at a system level. This sucks, but it is the reality for many, many organizations. Frameworks that aim to scale Scrum focus heavily on Leadership buy-in for this exact reason (allegedly¹.) Thing is, systemic change is time consuming, costly, and really difficult to sell to others.

Now of course, if you’re a Scrum Master, your ability to change the system is likely very limited. So, now what? How do we enable teams to be more Scrum-like, in a system that doesn’t really enable that? What do we do with high-performing teams that struggling with sticking to a plan, but get stuff done when they work on it? I think the answer is kanban. Maybe Scrum with Kanban if you must. But I really think the answer is kanban.

Now of course, this discussion has been had, and a Kanban for Scrum Teams Guide exists. It nicely marries some core functions of Scrum with some core practices of Kanban. This is all to say, I’m not the first to have this idea. But the more I work with leadership and teams, the more I see a dissonance between what Scrum sells itself to be, and what is actually possible to do.

¹ Maybe. Or maybe it’s because Leadership has the power to spend a ton of money, which these frameworks would love to get a piece of. Who knows!

Say what you will about Jira¹, but I’ve almost always enjoyed using it. Still, when Jira breaks, it breaks in a way that can be difficult to debug: Was this error thrown because of read/write permissions, workflow compliance, or something else? The errors Jira throws can be quite obtuse. Take this one, for example, when a team member was trying to clone an issue:

The issue was replicable on my end, and so we were off to the debugging races. First, some facts about the issue I was cloning:

• It was a Bug issue type²
• Bugs have specific workflows
• Bugs had newly required fields within those workflows. (I made this change a few days prior.)

In my heart, I knew this had something to do with required fields: Cloning wasn’t broken before I made that change, and now it was. But I was somewhat distracted by the error message: “Check your connection”. Connection to what? An API? The internet? Was I not connected to another project?

A quick Duck Duck Go search showed that others have had the same problem:

Most of those links were specific to cloning Sub-Tasks, which are sometimes treated differently than other issue types in Jira, but they mostly behave the same. In these cases, the fix was adjusting permissions and the default assignee when creating new issues.

Quick side bar for context: When a Jira issue is created, it doesn’t need to be assigned to anyone (Agile purists, rejoice!), but if you have a default assignee, that assignee must have permissions to create tickets in the first place. Jira doesn’t call that out when you designate the assignee, and so sometimes things break. Fun!

But here’s the rub: I – the team’s Scrum Master – was the default assignee, and from a permissions perspective, I had all the access you could have. Still, the error was thrown. Boo!

Next, I tried a cloning a different Bug, picking one at random from the active Sprint. I went through the steps and…

What!

OK, so it wasn’t permissions, nor was it issue types or workflows. Again I suspected the required fields. And so I opened up both issues in their detailed view, side by side. I went field by field, comparing whether or not a given field was filled out (content here wouldn’t matter.) Eventually I came across the culprit: an empty Epic Link field in the original ticket. Stubbing in a random Epic, I was then able to clone the issue without any trouble. Nice – problem solved.

But why was the issue able to exist in that stage of the workflow without the required field? The field, after all, is required. Turns out when you change the workflow and field requirements, it isn’t retroactive, at least not in a destructive sense: The tickets breaking compliance (now the purists are pissed) are allowed to remain in their current state, but any future moves through the workflow are prevented until the required fields are provided. This makes sense, but the messaging from Jira about what’s required is poor.

And so, two take-aways:

1. Jira doesn’t always handle errors very well. There were no “connection” problems, but that language threw me for a loop and led me on a bit of a goose chase. If you see a vague error, definitely check the forums, but don’t discount what you suspect to be true.
2. Required fields are tricky, especially when required mid-workflow. For us Scrum Masters, the fields likely keep our reporting nice and clean. For team members, however, it could break their individual workflow. Tread carefully, and be prepared to roll anything back if it breaks.

¹ Some in the agile community would argue Jira prevents teams from being agile, or encourages bad habits like using Story Points instead of more meaningful metrics. I disagree: If the team isn’t agile, Jira won’t help them be more agile, but if they are, it won’t hurt.

² Every ticket in Jira is technically an “issue” – the issue type (e.g.: Story, Bug, Epic) defines where it sits in the hierarchy. This naming convention has always seemed like a poor choice and almost always leads to jokes like “Everything about Jira is an issue.” (Agile humor is, at best, poor.)

I am of the belief that more prescriptive your are about doing something, the less faith you tend to have that someone (other than yourself, natch) will do the task correctly. Prescriptiveness is a precursor to micromanagement, and is often an indicator of low levels of trust. If you join a team where someone is telling you how to do something, and then speaking on your behalf as you move through the work, what’s the value of you? It turns out that micromanagement’s toxicity can expand far beyond the annoyance of being told how to do something.

In my entire career, I don’t think I’ve ever worked with a full team of new-to-the-job developers, Product Managers, or UX designers. The teams with new comers to the field have often been structured appropriately such that mentorship and knowledge sharing can occur between junior talent and experienced talent. It’s not always a perfect balance, but there’s never been a team I’ve met that doesn’t have collective decades of experience under their belt. The majority of folks I’ve had the pleasure of working with are often very good at their jobs, and are excited to support others just beginning their careers.

This is a long way of saying: I’ve never worked on a team that needs to be micromanaged. And yet, I’ve certainly met a number of stakeholders, middle managers, and “Leaders” that feel the need to tell teams what to do, and how to do it. Strange, and a bit counter-productive, given how toxic micromanagement can become.

It’s easy, of course, to blame poor leadership and middle management for this behavior. They’re always the villains, right? But lately I’ve noticed that many Agile tools and frameworks exhibit the same prescriptiveness, replete with a “Do this, not that” rulebook. The irony is, well, have you read the Agile Manifesto lately?

Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan

https://agilemanifesto.org

(When’s the last time you read that, eh?)

So if the Manifesto helps define the core of Agile values, what’s up with all the frameworks, tools, and trainers dictating exactly how to execute an org-wide Agile rollout, or run an Agile ceremony event? Obviously the biggest offender here is Scaled Agile, which has flooded the market with certifications, templates, and how-to documents that mostly have gone nowhere (find me an org adhering to SAFe 100%. I’ll wait.) But there are others.

Tools like Jira also make it difficult to talk about Agile values, because the tool demands data and numbers and content to be useful, instead of enabling conversations that empower teams to make good decisions for their users. Admittedly, the tools capabilities don’t condemn it entirely – the users of the tool (in this case Jira) can customize and leverage it as needed, but how have those folks been coached on the what and why?

Which brings me to the people aspect of all of this: Trainers, hiring managers, HR teams, team members. In my opinion, trainers get too prescriptive, because the tests for certifications are too prescriptive. There’s an entire industry that mints money creating certifications out of whole cloth, but the value of Agile is lost in most of these, and it’s damaging the wider Agile community.

For example, if you’re looking for a Scrum Master role, take a gander through the jobs listings on LinkedIn. The JD is the same for many – copy and pasted from Scrum.org, or worse, SAFe. There is not deep thought about what a Scrum Master should do for a specific team, or what particular skills a Scrum Master in this company may employ. With a JD like that, you’ll get all sorts of candidates, many of which are unqualified because the hiring manager “isn’t quite finding what we’re looking for.” Garbage in, garbage out. HR Teams feel the brunt of this the most, and though there’s a wider push for HR teams to be more agile themselves, the fundamentals and values of Agile are lost on many doing the actual hiring.

So how does this manifest itself at the team level? It invites risk, which ultimately slows down value delivery. Scrum Master in over their heads or underprepared for the true role? Things will slow down. Team members expecting one way of working only to find they’re forced to do something else? More slowing down. Above all, these sorts of mismatches give Agile – and organization agility – a bad name. How often have your heard “oh we tried that before, it didn’t work.”? It’s just more to unwind and rebuild, which, you guessed it, leads to a slow down.

It doesn’t have to be this way. I encourage any one in the Agile space to consider the ramifications of prescriptive frameworks, or changing processes to align with tools. We can allow more self-organization, greater ownership, all while enabling accountability and transparency. We can use tools for specific purposes, and chose other tools for other purposes. We have agency here, and we should use it to deliver value, not outcomes.

Age and experience are weird things. Imposter Syndrome not withstanding, it’s weird to think that a few years ago my opinions on topics – personal and professional – were that much less informed. As I get older, and experience more, I better understand why some adults in my life were constantly changing their minds and persona views (and encouraging me to do the same), and why those that never did often ended up being so miserly. 

But this post isn’t about grumpy adults! This is about how my opinions on agile ways of working have changed the more I’ve worked in agile ways. Go figure!

For starters, let’s talk about certifications. When I mention that, to which organization does your mind go, if at all? Is it Scrum Alliance? Scaled Agile? ICAgile? When I was new to Agile, certifications meant everything to me. It was a point of pride, and proof that I had “done the work.” In reality, I hadn’t done much of anything, and applying any learnings from a CSM class proved way more difficult than any test Scrum Alliance could put in front of me. Understanding that teams were made up of people, and people had their own motivations, opened my eyes to how much coaching had almost nothing to do with the framework you were applying.

Frameworks are tricky things: They purport to be a solution that will solve a problem – be it scaling, or how to organize work, or how to innovate. But they are not solutions, really. Frameworks are a tool – or collection of tools – that need to be applied correctly, with precision, to see any positive results. 

Take the example of a building a wooden coffee table: There are instructions for how to do so, and it’s clear what tools you need to get the job done. But the instructions don’t tell you how the tools operate, or what setup you’ll need to actually use the tools – they assume you’ve figure all that out. But if you fail to give yourself the space and fail to practice using your tools, you’ll find yourself struggling the entire time you build that table. And should you actually complete the damn thing, you may find that it wasn’t worth it and next time you’ll just buy something pre-made. You may not feel that accomplished at all.

Agile can feel a bit like building something, or baking, if that’s your bag. There are dozens of instructions and schematics and recipes out there, but without practice and forethought, Agile can feel like a slog. It can be impressively demotivating.

I used to feel Agile was cultish, and exclusive: I couldn’t understand coaches claiming that Agile was “a mindset.” And yet years later, here I am having incredibly nuanced conversations about the intention Scaled Agile (of all things.) These conversations, today, come easy to me. There’s value in the edge cases, and an honest conversation about what we can expect from all these solutions and certifications is useful to have before pursuing them. 

The Agile community continues to evolve its thinking on fundamental best practices. Story Points and velocity are on their way out, while throughput and predictability are becoming more widely accepted metrics. We’re learning how all this stuff actually works now that we’ve built a few wooden tables and tweaked the toolkit a bit. It’s good, if not a bit challenging, and I refuse to get too grumpy about it.

Scrum Teams spend a lot of time in a room together. In a two-week Sprint, they’ll spend upwards of 10 hours in Ceremonies. Ostensibly, this is a good use of time, but is that time evenly allocated to planning and self-improvement? I’d argue it is not.

A Scrum Team following industry best practices spends upwards of 60% of their time together figuring out what to do next. (Included here are both Planning and Stand-ups – both ceremonies dedicated to ensuring What’s next? is answered.) If we include Demos as de-facto Planning session (you are gathering feedback about what to iterate on next, aren’t you?), that number jumps to ~80%. This leaves just 20% – 90 minutes – every two weeks to reflect and share on learnings for the entire team. If you’re following the rules, that could upwards of 7 people! How much can you share, reflect, and digest feedback in 13 minutes? And that’s assuming you start on time with everyone staying engaged throughout!

I posit that a compressed, singular ceremony in which you need be present, open, and responsive to feedback is untenable. Few teams use their time well to retrospect, and it shows: Retrospectives are usually the first Ceremony to be cancelled when the team “needs” the time back at the end of the Sprint. It seems there’s always time to build, but not so much time to learn and reflect.

So, what if we flipped the script? What if we spent less time planning what happens next, and more time reflecting on how our learnings can be applied to that next step, whatever it may be? There will always be something else to work on – why not spend more time applying lessons learned to future work?

A pie chart of time allocated toward Sprint Ceremonies would shift a bit:

To be clear, Stand-ups and Planning would still occur – we’d just spend less time talking about What’s next?

Instead of “What did you do yesterday?” maybe we’d ask “What did you learn yesterday?”

Instead of “What will you be doing today?” we may ask, “How will you take what you’ve learned and apply them to your work?”

Blockers could (should!) still be surfaced, but what more did we learn about that particular problem? Do we have any more data or insight to work with so we can accelerate our effort to unblock it?

Ultimately, this falls to the Scrum Master to facilitate and enable, but here’s my pitch… Do this, and you’ll see two things happen over the course of a few Sprints:

1. A more thoughtful, mindful team, very self-aware and very transparent with each other.
2. Less time spent racing blindly toward the finish, and more time critically considering the best path forward.

Who knows what this will do to your teams’ velocity, but, like, does that really even matter? Probably not as much as you think.