Author: admin

Featured

Free Training – Make Any Team Agile

You may have seen IT professionals praising the word Agile, used to describe wide array of practices, principles, and frameworks, all aimed at improving team’s effectiveness. As I work with them since 2011, I realized that the same way of working could, in a simplified way, be carried over to other teams. 

More precisely, ANY team.

Continue reading “Free Training – Make Any Team Agile” →

Focusing Large Scale Agile Transformation

With all the hype surrounding the new ways of working (though calling them ‘new’ is dubious at best), you can still find some dinosaur playing the old game. Fixed scope software projects, infrastructure changes, provisioning of new services – all done the old way: loaded with project managers fighting over ‘resources,’ massive multitasking, and complete obscurity of accountability. Yeah, it still happens. I find it amazing that companies with core parts working like this are still afloat. 

The moment they notice their momentum is not limitless, the new begins. Sooner or later, large businesses realize that change is necessary. Then the transformation begins. I will not go into specific frameworks or approaches (though you can see my view on the best Agile framework in existence), but areas of focus.

As an agile coach, who should you work with the most?

The typical answer is obvious – put your effort on teams. After all, there can be hundreds of them. Even a large team of seasoned coaches will need quite a while to equip them with minimal viable agility, not to mention doing it right. Though it’s hard to expect an agile coach with any work ethic whatsoever to stop at the bare essentials, they will be pressured just to get it done. According to the plan. On time. Waterfalling Agile transformation will never get old.

Not to mention that focusing on teams will not yield the best results. Just think about it – as per the Agile onion idea, it’s not really about Scrum, Kanban, or (God forbid) Jira. These are just a means to an end, nothing but tools. Sure, you can train two hundred teams in Scrum, but unless you have very assertive and mature Scrum Masters with a mandate to do something useful, nothing will change. No increase in effectiveness. No shortening time to market. No twice the software in half the time.

For sure, though, your organization will become leaner. Your best people, those of the highest market value, will get frustrated with false promises and transformational tornadoes and quit. If that’s what you’re after – way to go!

Back to business – if transformation is not about the way teams work, what is it about? It’s the mythical mindset, which means what you should aim at is a cultural change, not process and tools one. And who shapes the culture? Everyone above the teams in the pyramid. Line managers, their managers, group managers, directors, executives. Culture radiates down from the top and is almost impossible to change bottom-up – and every attempt to do so will inevitably raise the bar of frustration on all sides.

Where should you focus your transformational effort first? All the management impacting teams (it will usually go higher than you expect). They should be the first to realize that multitasking is often a waste of time and money. They should measure their lead times and actively work on shortening them. They should do daily meetings and hold retrospectives. They should have transparent backlogs. Otherwise, they will be rightly perceived as fake, pushing yet another brilliant idea to their teams.

Give me six hours to chop down a tree and I will spend the first four sharpening the axe.

Abraham Lincoln, weirdly relevant

The best thing is that investing some time to work on management first will shorten the duration of the whole transformation. The culture and environment for teams to become Agile will already be there – no disappointments, no surprises, no frustration. I can’t think of a reason not to do it – and if you can, comment here (or PM me here).

Okay, there may be one reason – if you don’t want to transform. 

That’s always an option: comfortable, safe, short-lived.

Illusion of Mastery

It was almost a decade ago. With two dozen of my colleagues, I was anxiously waiting in a dimly lit conference room. So, that was the big thing. The company was going Agile and we were chosen to be trailblazers, first group of Certified Scrum Masters to carry the torch… Ah, who am I kidding. We wanted to learn something new and score brilliant, shiny, and – back then somewhat exclusive – certificates to show off on LinkedIn.

Two days went like a blast. We got to pass balls to learn optimization. We’ve heard the story of birds pooping all over Washington Monument (I still don’t know if it was true…) to think about root cause analysis. We were moving post-it’s in silence learning magic estimation. We got to experiment with some games to spice up retrospectives. It was fun. Then I passed some test over the Internet and certificate arrived in my mailbox. I became certified master of something new and exciting. Cool!

There was only one thing left to do: update my LinkedIn profile. Along with my colleagues (all of whom passed the test), I did just that.

Little did we know, that (at least back then – I really don’t know, or care, how it looks like now) CSM trainings weren’t standardized. It meant that their quality varied wildly. Some were great. Some weren’t. And some were just unfortunate. It was all dependent on experience of the trainers. So, in my case? Well, the guys were clearly quite competent trainers. Experts in Agile? Hmm. No. They did teach us enough to pass the test – on the other hand, I’ve never heard of anyone to fail it. Like, nobody, ever, worldwide.

It became clear once we actually started to use Scrum at work. I mean, we did sprints, meetings, all the magic – on the other hand, we had projects, with full half a year (or more) of scope estimated and planned. We measured our progress with three-page long PowerPoint decks displaying projections of burndown months ahead. The most pathetic part was that I actually co-created these monstrosities. That was expected of me. I was certified to be master of something, hence it was implied that I should know. Given I was taught this particular chart to be all-in-one progress tracking tool, why wouldn’t I do it?

In hindsight, I’m pretty sure I was the worst Scrum Master I’ve seen in my life. And, believe me, I’ve seen my share of truly horrible ones.

Soon enough, things deteriorated to a point when we were all sent to another expensive training – this time Professional Scrum Master, standardized around the globe. Now, mind you – I worked for outsourcing company, where both sides of each coin were thoroughly inspected prior to spending it. And yet, they spent another huge pile of money to train us again, properly.

I remember talking with one of my best friends shortly after this one. We were excited and humbled, along the lines of “oh, so this is how it should be done!” She made a remark that I remember to this day – that previous training felt like some very basic introduction compared to this one. Following another online test, we updated our LinkedIn profiles again and got to work. It went much better this time – though, admittedly, organization itself evolved over time.

Another year later, I got to participate in PSPO training. It kills me to this day, but I distinctly recall myself thinking “Had I known that as a Scrum Master, my life would’ve been so much easier.” At the same time, I had fresh memories of boasting with my certificate and allowing myself, my team, and my company to think that, well, NOW I KNOW THIS STUFF.

God almighty.

The name of the role itself brings a lot of trouble. Becoming master of anything after two days of training? Seriously? They cover no more than 5% of what you should know to be good at it. I mean, would you expect medieval kid to become master blacksmith after two days?

No. That kid would be an apprentice first. Few years later, he’d be promoted to journeyman. Then, maybe, one day he would become a master. After at least fifteen years of daily practice. Still, reaching the top rank was unlikely anyway. And with all things Agile, all the psychology, sociology, sales, personality traits involved – I dare to say it’s far more complex than smithing.

It’s not that the position name itself is the cause of all problems that occur. There are companies faking Agile. Others are faking not faking Agile. There’s a substantial training and certification business. There’s new commercial framework born every Tuesday. There are idiots pointing at practices that work and shouting “that’s not Agile!” There are others, recommending out of the box solutions to companies with very unique problems, saying “trust me, it’s Agile!” Sure, there’s all that.

You can say it’s implied that first two days are only the beginning of the path. I know trainers that actually say it straight. But others don’t. It’s bad for business. And if new adepts are not humble enough, they will not even know how their own ego has played them.

I was never a Scrum Master. Apprentice, at best. How about you?