About two weeks ago, during Q&A session following Let’s Manage IT event in Łódź, I was asked a great question – how to measure progress of Agile transformation. Short answer – don’t measure it, as you’re missing the point. For a touch longer one, see the short video below.

I am an avid reader. From quantum physics, via business, to sport psychology – and beyond, if I get my grasp on a book, I’m on it. And the further I go, the more often I’m disappointed. It’s actually hard to find a good book nowadays. And truly groundbreaking vaults of knowledge are extremely rare. With that in mind, I would like to share my top three books on leadership with you. While you mind find this selection trivial, they helped me reshape myself to provide a better service and better value to those that I work with.

“Leaders Eat Last” by Simon Sinek

If you’re even remotely interested in leadership, you must’ve seen Simon on stage during his seemingly countless TED talks and interviews. It’s his second book, following spectacular success of “Start With Why” (which I also recommend, though for building a business). While you may argue it’s entry level, that’s one of it’s advantages. It’s deceptively easy to get so entangled in complex processes and models, that basics fade out from our view. Also, I love how Simon phrases his ideas – in an easy to follow and understand way. I envy this skill, as – clearly – I don’t possess it. Altogether, a great book covering the most crucial aspects of leadership, without all the corporate mumbo-jumbo.

“Turn The Ship Around!” by David Marquet

An intriguing story of one nuclear submarine captain, who was almost forced to become humble and drop his know-it-all mindset. We all know these managers. It’s just impossible for team to convince them they’re wrong. Well, David was used to know every possible detail of warships he commanded. One day, just days before setting sails, he was stricken off balance by his superiors. He was to take over a different submarine – also, of other type. Having no chance to learn everything by heart, he caught himself failing several times – and making an unorthodox (and possibly illegal) decision to empower his crew. Within months, his submarine became the most efficient of US Navy vessels. The story, with all the findings and conclusions, makes one wonder – if it’s possible to achieve that on a military warship loaded with nuclear missiles, how hard could it be in corporate environment?

Yes, very. Unless you learn how to improvise, adapt, and overcome the obstacles. David’s book will give you a hand.

“Extreme Ownership” by Jocko Willink

While previous two are light reads, this book is quite hardcore. Jocko was one of the commanding officers of US Navy SEAL team during heavy fighting in battle of Ramadi. His story goes far beyond what they teach you at business school. From brutal training, through dusty streets of Iraqi cities, to ruthless corporate environment, we learn what it takes to truly lead our men. It’s a story of extremely hard work, honest accountability, and discipline. I love three things about Jocko’s story. First, there’s no sugarcoating included. Leading is a hard work and this book is one of the very few places where it’s stated openly and repeatedly. Second, it’s truly practical, with examples that most of readers will relate to with ease. Third, the book gave us one of the most popular episodes of Tim Ferriss podcast (which I highly recommend) and extensive podcast series by Jocko Willink himself.

These three may not resonate with you the way they did for me, though they will expand your horizons and give you great tools to work on your business, your team, and yourself.

For unorthodox books on Agile, see this post.

When I get to stage to talk about anything related to Scrum, you can expect me to do a few things. Sometimes I prove that most Agile companies are actually working waterfall style. In other cases, I ridicule the concept of becoming proficient at anything during a two-day course. And quite often, I prey upon Scrum Masters, in the most annoying way possible. All it takes is a simple question, flavored with a touch of surprise.

I ask them what they do.

And as I do that for a few years now, I’m still waiting for any single soul to provide me with some reasonable question. So far, it didn’t happen, which is odd. I mean, the Holy Book of Scrum has a whole section dedicated to the role. How hard can it be to remember any of that?

It might’ve been easier if any of Scrum Masters did what’s stated in The Book.

Let’s see what’s in there.

The Scrum Master is responsible for promoting and supporting Scrum as defined in the Scrum Guide. Scrum Masters do this by helping everyone understand Scrum theory, practices, rules, and values.

The simplicity of this description is truly misleading. Unless you’re familiar with the Guide to the letter, you’ll have no idea what it means. As top brass in companies cannot be bothered with such minute details, Scrum Masters create what they understand as more clear descriptions.

Which makes all the executives to wonder why their well-oiled machineries would need anyone to remove impediments. The practice of propagating these alternative role descriptions is quite harmful. Nobody in the organization will be compelled to find out what Scrum really is. But, back to the Guide.

The Scrum Master is a servant-leader for the Scrum Team. The Scrum Master helps those outside the Scrum Team understand which of their interactions with the Scrum Team are helpful and which aren’t. The Scrum Master helps everyone change these interactions to maximize the value created by the Scrum Team.

Servant leadership is one of the most ridiculously absurd concept I know. I mean, do you know any other approach that is known for decades, helps companies achieve great success, and is so counter-intuitive that almost nobody really attempts to do it?

Simply put, despite all the benefits, servant leadership strains managerial egos beyond what they teach you at business school.

Guarding interactions, on the other hand, is the most notorious thing that Scrum Masters claim to do. That’s something. But here’s where the Guide gets more specific.

The Scrum Master serves the Product Owner in several ways, including:

  • Ensuring that goals, scope, and product domain are understood by everyone on the Scrum Team as well as possible;
  • Finding techniques for effective Product Backlog management;
  • Helping the Scrum Team understand the need for clear and concise Product Backlog items;
  • Understanding product planning in an empirical environment;
  • Ensuring the Product Owner knows how to arrange the Product Backlog to maximize value;
  • Understanding and practicing agility; and,
  • Facilitating Scrum events as requested or needed.

This is where the fun begins. The last point on the list is the most visible to external stakeholders. All the meetings, silly retrospective games, millions of post-its to recycle. Product planning can also score high on visibility scale, though only in organizations that are a bit more aware of what they do. It’s no wonder that this is what most trainers, coaches, and participants focus exclusively on these two.

The rest is to be honed on the battlefield, even though our Scrum Master is now professionally certified. In two days.

The Scrum Master serves the Development Team in several ways, including:

  • Coaching the Development Team in self-organization and cross-functionality;
  • Helping the Development Team to create high-value products;
  • Removing impediments to the Development Team’s progress;
  • Facilitating Scrum events as requested or needed; and,
  • Coaching the Development Team in organizational environments in which Scrum is not yet fully adopted and understood.

This part is clearly visible to the team, which has interesting consequences. With good intentions on all sides, Scrum Master is likely to drift towards the third and the fourth way. Often, they simply lack understanding and experience in leadership, coaching, and business to do anything more.

If they stray into this territory too far, they might pass the tipping point – which pushes them into abyss called Scrum Team Secretary. All in plain sight of their teams, which may – and ultimately will – question the point of the role. Scarily enough, if things get to this point – they will be right.

The Scrum Master serves the organization in several ways, including:

  • Leading and coaching the organization in its Scrum adoption;
  • Planning Scrum implementations within the organization;
  • Helping employees and stakeholders understand and enact Scrum and empirical product development;
  • Causing change that increases the productivity of the Scrum Team; and,
  • Working with other Scrum Masters to increase the effectiveness of the application of Scrum in the organization.

Now, this is the sad part. Unless we’re speaking of a very small organization, nobody will want that to happen. It’sa  little surprise, to be honest. Would you like someone who has just finished two-day course to plan Scrum implementation in your company? Maybe, you would like them to lead and coach the organization during the adoption?

Some Scrum Masters catch that quickly. Many never do, believing – in good intentions! – that what they learned during these two days is enough. And not every trainer corrects that mistake.

After all, why would they rock their own boat?

How to become a good Scrum Master? It’s obvious, easy to figure out, difficult to actually do. It just takes years of humility, experiments, and hard grind. Regardless of certificate.

(And while we’re at it – do get to know the Agile Manifesto in the process. I know dozens of Scrum Masters who hardly ever heard of it. Now, that’s failure of training at its finest.)

For years, I have lived in a belief that complex problems require complex solutions. If we’d like to hugely improve our business with agile, we should use some complicated framework, with multitude of tools, approaches, and processes designed to address every possible scenario. It backfired on me several times. The wake up call was almost three years ago, during Agile Portugal 2015 conference.

You might know it or not – 2015 was year of agile at scale. If you wanted to be treated seriously as a speaker, consultant, or coach, you just had to share your experience with it. Everyone was into scaling. Because, clearly, we all knew how to do it right on a team level… Obviously, having quite a background at large scale agile, I joined the bandwagon. My speech in Porto covered exactly this topic.

Then, during a break following my presentation, reality hit me with a sledgehammer.

You all talk about agile at scale, which is great, but we’re startup of ten people and want to do it. How?

If I remember correctly, my answer actually made sense. Something along the lines of starting small, using the least processes and formalities possible, just the kind of basics that make sense. Regardless, I was dumbfounded enough to quit corporate job two years later and joining a very small company to see how it really works.

But there’s more to it.

Just at the end of 2017, I was contracted to run series of trainings on basics of agile to over one hundred employees of a large state-owned conglomerate of very traditional sector. As if it wasn’t challenging enough, majority of the participants had little to none exposure to IT terminology, processes, and industry. Trying to grasp and convey the essence of what agile is was quite tricky.

To make things worse, I’m not really sure if they stand a chance to actually make it with the transformation. Reading between the lines, it was clear that management buy-in was dubious at best. Agile was yet another great idea they had, following (and perhaps preceding) series of other spectacular transformations.

Yet, I wanted them to benefit from my trainings regardless of what future could bring. Then, out of the sudden, I had my eureka moment. I found the Holy Grail of the least you could do to get all the benefits in the world. And it was hiding in plain sight, disguised as one of Scrum ceremonies.

(I seriously dislike the official, semi-religious terminology of Scrum. Artifacts, ceremonies, masters…)

Retrospectives, in their simplest possible form, are Minimum Viable Agile.

It’s that simple. Get your team for half an hour and ask them the most basic and most profound of questions: If we had a second chance to live through these last two weeks again, what would we do differently?

Hell, you don’t need to wait few weeks. You can ask this question every morning. The benefits will astonish you.

Why?

First, as human beings, we hardly ever reflect on our lives. Not to mention, on a regular basis. We only do this when things either radically change (think: you’re about to have a baby), or when they go really, really wrong. If neither of these conditions is fulfilled, we just fly ahead with staggering mindlessness. Nothing weird about that, we’re just humans, perfect in our imperfection. It is worthy to shed some light on whether we’re going the right direction or not.

Second, no currency is worth more than our time. Not only you cannot buy more of it – it comes in extremely limited supply. Given you’ve reached this sentence of this post, you’re about four minutes closer to your death than you were at the beginning of it. It’s one of the most uncomfortable facts people are ever faced with. You will have no chance of reliving yesterday. If you did something stupid, or pointless, or in an inefficient way – you will not have a chance to change it.

You do have a shot of making it differently today. Otherwise, tomorrow you will be even closer to your demise, with yet another wasted day. That’s your choice.

Third and the most important reason for starting with Minimum Viable Agile – it will get you somewhere else. Yes, there are thousands of prophets saying you must use Scrum, Kanban, or whatever else. Each of them has numerous examples of how, to a different extent, these things worked in the past. They are perfectly right about that! These approaches, in that particular conditions, in these particular businesses, gave very specific results. That’s a fact.

However, extrapolating these past experiences into your business can be nothing but a false prophecy. No company is out of the box, so applying off-the-shelf framework can only work to an extent.

By regularly inspecting and adopting the way you work, day by day, you can create your own agile. Tailored and customized to your specific needs, to the way your people work, to the very DNA of your business.

All it takes is to start small.

So, if you had second chance to relive yesterday, what would you do differently?

Some time ago, I was interviewed by Samir Penkar, who’s researching the future of project management. For this particular conversation, we discussed the Scrum Master role. Check the video below to see where it got us.

Make sure to visit Samir’s blog and follow him on LinkedIn for more interviews and his interesting insights.

Setting aside the enormous power of our habits, several times each day, we still have a conscious choice to make. While we usually fail to notice that, each of them is inevitably influenced by complex set of biases. And there are literally hundreds of these. Just see this amazing infographic. Despite corporate pushes to always make the best choice possible, finding an optimal one is quite tricky. I even dare to say it’s impossible, given that there’s always a set of factors we’re not even aware of. If we care to be on the spot, usually we’ll just be close enough.

But what if we could do one simple thing to improve the process? Just a small tiny detail? Wouldn’t that be good?

A few years ago, the key employee of my client notified them of canceling his contract. Do you know what the CEO said upon hearing the news? “Damn, that’s bad.” Then he started figuring a way to handle the situation, as everyone would expect. Disbelief, anger, disappointment – all underlined with a notion of uncertain future. To ensure everyone else that things aren’t actually that bad, he called for an all employee meeting, sharing the optimistic operational data and mentioning several promising prospects. He’s never done that before.

As you can imagine, he clearly overdone it, prompting more employees to consider quitting.

A few months ago, a friend of mine – somewhat tired of her current employment – heard that competing business was to open nearby. Even more, they were fishing the job market for people just like her. All she could say was, clearly, “That’s good news!” With new optimism, she updated her resume and filed it instantly. You could see her eyes brightening up and cheering. With emotions and hopes storming within, she started to underperform at work. An ad-hoc feedback session, with HR member involved was, in her perception, just brutal.

The new business didn’t hire her.

A few weeks ago, as I was preparing to leave home in the morning, I checked the weather. It was to be foggy, moisty, and substantially colder than the day before. I distinctly recall saying to myself, “What a bad weather!” As I drove to a client, I kept thinking if any of my plans need updating due to unexpected conditions. As pessimism filled my heart and brain, the obstacles started piling up. I called my assistant and asked her to postpone important meeting to another day.

Then, out of nowhere, a viral thought manifested in my mind. It was strong enough to leave me missing one green light and pushing the envelope of everyone’s behind me tolerance to stupid drivers to their very limits. What if we all used wrong words?

As humans, we’re driven by emotions and gut feeling more than we would ever admit. It’s not really a bad thing. We’re perfect in our imperfection, that’s what makes us human.

The catch is that we can invoke these emotions with incredible ease. And they bias even more, for no valid reason whatsoever. Words like good, bad, great, fantastic – all impact our decision making. Which is sad, as they’re mere opinions, not facts.

What the CEO could’ve said instead? “Okay, that will impact our plans.” That’s a fact. “Damn, that’s bad” is an opinion. Ironically, business can actually benefit from departure of key employee – it sparks evolution, a change, an improvement of process to be more resilient in the future.

My friend? “So I have second career option.” It’s neither good, nor bad, just statement of a fact. And being happy of alternative option is likely to yield better results than being happy because, well, it’s good news.

Myself? “Okay, there’s fog outside”. As many of us, I was programmed in my childhood to automatically associate rainy days and fog with something bad. You know, “Don’t go outside, the weather is bad.” That’s beyond pointless. The weather just is. As are career options. As are events impacting businesses.

Now scroll up and read the last sentence of the second paragraph.

“Wouldn’t that be good?”

I think that stating it like “Wouldn’t that yield more benefits?” would’ve been more factual.

Just give it a shot. You’ll be surprised.

I know a guy incredibly fond of estimating development effort for a ‘scrum’ team in hours. Because, apparently, it’s the best tool to increase developers performance.

Ouch. On so many levels. For so many reasons. As the science of engagement screams in pain while dying, let’s just repeat: ouch.

Of course, there are some arguments against the practice. That no two developers share the exactly same knowledge of the product. That no two developers have the same experience. That, ultimately, we learn and grow by failing. That, maybe, for some reason, we have this team-based tool, called story points, which could make more sense. Because ‘this whole scrum thing’ is all about teams, and so on.

It’s a big no, apparently.

And this guy is actually right! Yes, you can use time-based estimates to evaluate each individual developer’s performance! Yes, it will work! For a price, but let’s just leave it to the side.

On the other hand, it takes some deliberate effort.

First, during the planning session, you have to split all the tasks at hand between individual developers. Simply because, my hour will never equal your hour – which works for every single pair of individuals in the world.

Second, you force each of the developers to precisely estimate the level of effort. It may take up to one full day per two-weeks sprint. A money well spent, apparently!

Third, immediately after the sprint you invest some time to assess each individual’s performance and provide immediate feedback. Failing to do so means no learning occurs, hence people never ever improve.

This guy I know fails on all three.

Which is a good thing after all. Their estimates are rubbish, but as long as nobody *really* cares about them, they’re just fine. Yes, the client will complain for a while – but then they’ll become used to it. Just burning some more money sprint by sprint, oh well.

And yet, it’s not the worst outcome ever!

The worst thing would happen if this guy I know would start exercising his power on the time-based estimates. Because every sane individual involved would just quit. Immediately.

There’s another scenario though. If you were an engineer and was mercilessly persecuted for every time your work log exceeded your estimate, what would you do? That’s right. Increase the estimates. Sure, you’d be bored as hell quite a lot – but safe! Long enough to find another job without quitting immediately.

Story points were created for a reason. Use them. They make sense.

At one point or another, every organization turns to hiring some truly experienced staff. People possessing skills unavailable in-house. Those that not only deliver more than the rookies – their performance can be seen as shocking. Their insights reach well beyond what’s visible to the naked eye.

The experts.

Sometimes they turn whole business around and put it back in black. Sometimes they can foster growth of others, for the greater good. Sometimes their leadership (social, technological, actual…) can massively contribute to historic successes.

Most often though, they’re just a waste of money. Given their expertise and limited marketplace, a substantial waste of money. It’s not like it’s their intent.

It’s just that they’re misused.

How is it even possible? How can you understand the need for expert support, find the right person, pay them a ton of money – and somehow spoil it all?

It’s remarkably easy. You misuse expert by telling them what to do. Don’t ever do that.

Tell them what to achieve. They’ll tell you what to do. Then they’ll do what’s necessary.