Pawel Brodzinski on Leadership in Technology

Whatever it takes to lead a team, build a product, and run a business

Tag: conference

  • Lean Kanban Central Europe Leadership Track

    There’s a question I get asked pretty frequently: which conference I would recommend to attend. Of course the answer is always contextual but surprisingly often after some further inquiry I recommend Lean Kanban Central Europe.

    On one hand it’s the content. Even today I remember all the keynotes from the first LKCE three years ago. That’s how much that stuck. Since then the program was only getting better. Then, there is exposure to new ideas. Lean Kanban series of conferences are surprisingly consistent when it comes to bringing to the mix new concepts, models and methods. One can bet that that thing which sounds so fresh on one of big Agile events was covered in extent a few years ago at Lean Kanban tour.

    Then of course there is networking. With three hundred people networking is of very different quality than at the events that attract a thousand people or more. Everyone is more accessible and it’s not an ultimate challenge to track down someone who you really want to chat with.

    The post wasn’t meant as a just an infomercial of LKCE. The conference, as every good event, evolves. One change that we introduced this year are consistent tracks and track chairs. This means that there’s always someone who made final decisions for the part of the program. This also means that there’s even more space for radical ideas as we as the program board aren’t driven by the consensus that much.

    The track I’m honored to lead is the leadership track. One thing I didn’t want to do with it was just to throw a bunch of great speakers and just let them do their magic. What we’ll have instead is a theme and different ideas on leadership evolving around the same theme. Of course we still have a bunch of awesome speakers in the first place.

    This approach means that everyone who will choose to stay throughout the whole track will get a consistent experience, while being exposed to different ideas. In fact, when working on the track I was thinking of it as of a mini-conference on its own.

    The underlying theme for the track is broadening understanding of what leadership is and what approaches and tools we may use to let it emerge in our organizations. Esther Derby will kick off the track explaining that leadership at all levels isn’t just a nice theoretical concept or wishful thinking. At the same time the challenge is that there are no recipes that allow us to easily build such an environment. If there was such a thing as a track keynote it would be this one and I can hardly think of a better candidate than Esther to deliver it.

    With no recipes we aren’t left alone in the wild though. We do have models and methods that, if understood correctly and used mindfully, can help us to shape the organization to steer emergence of leadership. When I think about people who easily mix different models and methods applying them contextually to provide most value Liz Keogh is on the top of my list. That’s why I asked her to cover that part. At least a bit of exposure to systems thinking and complex adaptive systems seems inevitable.

    By that point the balance of the track will have swung toward more systemic approach to leadership. In that context however we can’t forget that at the end of the day it all boils down to people dynamics. That’s where Marc Burgauer will kick in with his message about how trust, connections, blame and fear of shame play pivotal role in building leadership across organization. Marc does an awesome job bringing people perspective into discussion.

    The only missing bit in that mix is a practical story that shows how one may use all these building blocks to create a culture where leadership emerges and thrives. I tasked myself with that. On one hand at that point my job will be super easy as Esther, Liz and Marc will have covered the important parts and I’ll just build the connection between my story and earlier sessions. On the other, matching such a lineup of speakers is a challenge by itself. I guess my inner speaker now hates my inner track chair.

    Of course leadership track will be competing for attendees attention with other awesome tracks. It was never our goal for LKCE to make choice between sessions even remotely close to easy. I do hope though that there will be some people who will choose to stay with us through all the leadership sessions. Especially that it is the shortest track of the event. As you can see though there was a lot thought invested to provide additional value for those who would be at all sessions.

    The track is more than a sum of its sessions, it’s a product of interactions between its parts.

    Have I just brought systems thinking again to the discussion? Oh well…

    I hope this is one more argument to join LKCE this year. I’d love to see you there and I’d love to get feedback about the final outcome.

  • Better Conferences or Better Learning?

    Bob Marshall recently published his ideas how to improve conferences. Pretty radical ideas I’d say. Basically what Bob proposes is to move from traditional one-way communication to bi- or multi-directional conversations with expertise available on demand (read the whole post – it’s worth it). By the way similar points were shared by Jurgen Appelo in his writing as well.

    I’m no conference animal, even though I helped a bit to organize a few of such events and attended a few more. I went through different formats, from whole day long workshops, through few hour long tutorials, through anything between 90 and 30 minute long sessions, open spaces, TED-like no-more-than-18 minute-long performances, lightning talks, pecha kuchas and whatnot.

    While I understand Bob’s desire to change knowledge consumption from push model to pull model I find it hard to buy his ideas uncritically.

    There is one reason. The conference isn’t better because this or that format is generally better, but because the very set of people attending the very event learned much. In other words, thinking about an event we should think how this specific set of attendees is going to learn, which is a function of how they expect to learn and how they are prepared to learn.

    One of the best events I ever attended was Kanban Leadership Retreat. It was an unconference. It exploited many of ideas Bob shares. From a perspective of attendee, who was willing to learn even though they brought significant knowledge on the subject, it was great. The learning process was very multi-directional and pretty much everyone was both: a teacher and a student.

    At the same time on occasions I speak at events where such format would fall flat on its face. It would, as people who attend generally expect knowledge to be pushed to their heads. You may laugh but actually even such approach is sometimes expected in a whole spectrum of behaviors. On one end there’s mindless zombie who was sent to the event by the company (yet still they can learn something). On another there’s TED, where you know close to nothing on vast majority of subjects being discussed and actually expect expertise from people on the stage. Note: we’re still in “Dear speaker, I know nothing of whatever you’re talking about” land. I know there is another dimension where you move from one-way learning to everyone’s a teacher attitude.

    So basically my thought on the subject is: first, understand what the effective method of learning is for this very group you’re sharing your knowledge with. And yes, I’m talking here about majority, or average, if you excuse me such vast oversimplifications. I’m saying so because we don’t measure success of event by happiness of most demanding person in the room. Even more, probably the most demanding person in the room shouldn’t be happy with the event, because arguably it would usually come at a price of having many others not catching up with the content.

    Having said that I believe that generally speaking conferences should head the way Bob describes as our focus is still on pushing knowledge, not pulling it. I wouldn’t be so quick to revolutionary change all the events though – I would rather look for opportunity to broaden variety of methods attendees can use to learn.

    This is what a better learning is all about. And better learning is something better conferences should be all about.

  • When Kanban Fails

    In my story from Lean Kanban Central Europe 2011 I promised I will elaborate more on my session there, titled Kanban Weak Spots. The starting point to the session was analysis of a number of situations where Kanban didn’t really work, finding out a root cause and then trying to build a bunch recurring patterns from that.

    By the way I have an interesting observation. Whenever I called for Kanban failure stories I heard almost perfect silence as an answer. It seems everyone is so damn good with adopting Kanban that it virtually never fails.

    Except I’ve personally seen a bunch of failed Kanban implementations. Either I’m the most unlucky person in the world and saw all of Kanban failures out there or for some reason we, the Kanban crowd, are still sharing just success stories and not putting enough attention to our failures.

    Actually, when I was discussing the session with fellow presenters we quickly came to the point that basically every time we think about Kanban failures it can be boiled down to people. However, and it is one of recurring lessons from lkce11, we should address vast majority of ineffectiveness to the system, not to the people. In other words, yes, Kanban fails because of people, but we change the system and only this way we influence people behavior.

    This is exactly the short version of the presentation, inspired by Katherine Kirk and Bob Marshall.

    There is the long version too. Symptoms, which show you that something isn’t working, and if you do nothing about them you’re basically asking for failure. I have good news though. Most of the time you will look for these symptoms in just one place – on your Kanban board.

    Probably the most common issue I see among Kanban teams is not keeping the board up to date. In short, it means that the board doesn’t reflect the reality and your team is making their everyday project decisions basing on a lie. A very simple example: given that there is a bottleneck in testing but it isn’t shown on a Kanban board, a developer would come to the board to see what’s next and they would decide to start building a new feature instead of helping to sort bottleneck out. Instead of making things better they would make them even worse, thanks to the board which isn’t up to date.

    I face the same problem but on a different level, whenever a team tries to make a board showing the way they’d like to work, and not the way they really work. Actually this one is even worse – not only do you make your everyday decisions basing on a lie again but it’s also more difficult to get things back on the right track again. This time it’s not enough to update the sticky notes – you need to fix the design of the board too.

    Another board-related issue would be forgetting about a good old rule: KISS. When people learn all these nice tricks they can use on their boards they’re inclined to use a lot of them. Often way too many. They end up over-engineering the board, which means that they bury important information under the pile of meaningless data. Soon, people aren’t able to tell what means what and which visual represent which situation. Eventually, they stop to care to update the board because they’re basically lost, so they’re back to the square one.

    Violating limits has its own place in hell. Of course it is a matter of your policies whether you allow abusing limits at all. However it is pretty common situation that it is generally acceptable that limits are violated very often, or even all the time. Now, let me stress this: limits in Kanban are the fuel of improvements; if you don’t treat your limits seriously you don’t treat improvement seriously either. Limiting work in progress is a mechanism, which makes people act differently than they normally would. When a developer, instead of starting to build another feature, goes to help with a blocker in testing it is usually because limits told them so. Eventually they learn to predict such situations and act even earlier, before they fill up the work queue. Anyway it all starts with simple actions, which are triggered by limiting WIP.

    The interesting thing is that all these problems can be seen on a Kanban board. The reason is pretty simple: the board should reflect the reality, no matter how sad the reality is. You deal with lousy process the same way as you deal with alcoholism: the first step is admitting you have a problem. Even if your process looks like a piece of crap show it on your Kanban board. Otherwise you’re just cheating yourself and you aren’t even starting your journey with continuous evolution toward perfection.

    There is however one driver of Kanban failure, which won’t be seen on a Kanban board. It’s also my recent pet peeve. Treating Kanban as a project management or a software development approach is basically begging for failure. It is asking Kanban to deal with something which it wasn’t designed for. It’s using a banana to hammer a nail. Seems funny indeed, but if you care about a success, well, then good luck – you’re going to need a lot of it.

    Kanban can be called change management approach or process-driving tool or even improvement vehicle but it doesn’t say a word on how you should manage your projects or build your software. If you don’t build Kanban on a top of something, be it a set of best engineering practices or project management method of your choice, you’re likely to fail miserably. And then you will be telling everyone that you need to have experienced team to start using Kanban and that it wouldn’t work otherwise.

    So here it is – a handful of risks you should take into consideration whenever adopting Kanban in your team. A bunch of situations observed by the most unlucky guy in the world, who actually sees Kanban failures on occasions. However, what I want to achieve with this post is not to discourage you to try Kanban out. Pretty much the opposite. I want you to think of this list and actively work to avoid the traps. I just want you to succeed.

    And this is why you will hear me writing and speaking about Kanban weak spots again.

    Now, even though I teased much of the content from my lkce11 session above, here are my slides.

    Kanban Weak Spots

    By the way, if you happened to be on my session in Munich please rate it.

    If you’d like to see some more content on the subject, fear not. As I’m very passionate about that I will definitely write more on this soon.

    Advertisement: Want to have such nice Kanban boards in your presentations or blog posts as well? Check InfoDiagram Kanban Toolbox. Use pawelBBlog code to get $10 discount.

     

  • Kanban Leadership Retreat

    I spent last few days at Kanban Leadership Retreat. An original David Anderson’s idea was to gather in one place thought-leaders working on Kanban and provide them a platform to exchange experience, ideas and thoughts. I must say it kinda scratched my ego in its back to be invited.

    Anyway I’m still impressed how great the event went. I mean, I know that gathering some great minds in one place and giving them free beer (one evening only, but still) is a sure-shot recipe for a stunning success. To be honest, I did have high expectations. Basically all of them were exceeded.

    As the retreat worked as unconference vast majority of sessions ended up as discussions. There was little-to-none pre-prepared content which was both good and bad. It was good because it really enabled a lot of good discussions and thought exchange but there were moments when I’d appreciate a bit of structure, which is naturally brought by standard presentations.

    Personally I’d also prefer to see sessions a bit more focused on real-life stories than on meta-level but I guess expectations on this one differed.

    Anyway, volume of mind-blowing ideas I’m still trying to think through was astonishingly high. After all, what could you have expected after inviting all those though-leaders, and I take the word “leader” very seriously here, to the same place? By the way: you can definitely expect some of those ideas shared here in near future.

    Actually I went to the retreat with a goal to discuss a few of them: portfolio-level Kanban, Kanban failures and methods of selling Kanban to teams and organizations. Lucky me, each of them have made it to the event program. And basically each of the sessions looked totally different than I’d projected. This basically means I got a new, and unexpected, perspective on ideas I’d already had which, by the way, might make attending my future sessions on Kanban way more valuable, if you excuse this shameful plug.

    But all in all it wasn’t the content which was the most valuable for me. People were. I always say that networking is the most important part of any event but this time it was totally on steroids. The format of unconference, the choice of people and never-ending Icelandic days made it the ultimate networking event. If, by any chance, I looked as a child in chocolate factory please forgive me – I had damn good reasons to look so.

    I should probably mention all great folks I was talking to, which would be kind of boring for people who weren’t there, so I’ll refrain (BTW: if somebody is curious please check people I recently followed on Twitter). But if you are the one of them I’d like to genuinely thank you for all the stuff I learned from you.

    Huge thanks for organizing the whole thing goes to David Anderson and his staff along with Hillel Glazer, who facilitated the event.

    Personally I will be there next year. That’s no-brainer for me. If any of you, by any chance, is invited you shouldn’t hesitate whether it is a good idea to go even for a second.