Pawel Brodzinski on Leadership in Technology

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

Author: Pawel Brodzinski

  • Why Organizational Transformations Fail

    You can’t reorganize the way a business thinks by reorganizing the business.

    ~Stephen Parry

    I can safely state that every company I worked for was attempting to make an organizational transition during my time there. Motivations varied from simply surviving, through adjusting to a new environment, to improving the whole business. Approaches to run a transition also differed, but one common part was a reorganization.

    Oh, reorganizations. Who doesn’t love reorgs? Shaking everyone around. Bringing in good old insecurity and fear of unknown. Quite an interesting strategy to introduce a positive change, although the one which is most prevalent and often inevitable. Unfortunately, a strategy that has a pretty low success rate too.

    After all, coffee doesn’t become sweeter simply because you stir it.

    The interesting part, however, is that I can come up with an example or two in which reorganizations helped to make a transition a success, or even make it possible in the first place.

    How come? The answer is hidden in Stephen Parry’s words at the beginning of the post. It’s not about the reorganization itself; it’s about changing the way business thinks. The problem with most reorgs is that they’re driven from the top, which usually means that the top of hierarchy remains the same. It also means that the way business thinks, which spreads top-down, remains unchanged.

    If the organization’s leaders’ mindset remains the same, any change that is introduced down there isn’t sustainable. Eventually, it will be reverted. Depending on how many layers of isolation there are it may take some time but it’s inevitable. Prevailing mindset just goes top-down and unless you can address its source it’s a battle you’re not going to win.

    I can think of, and have been a part of, reorganizations that shook the very top of a company, introducing new leaders and thus enabling the new way of thinking. Yes, the business was reorganized but this was neither the only nor the most important part of the change.

    Because coffee doesn’t become sweeter simply because you stir it. Unless you’ve remembered to add sugar before, that is.

    The game-changer here is mindset; that has to change in order to enable the successful transition. And I have bad news for you: it has to change at the very top of the organization. You don’t necessarily have to start there, but eventually it either happens or things, in general, remain the same.

    So if you consider a reorg as a way to change how your business works, ask yourself a question: does this change affect the mindset of the organization’s leaders? If not, I wouldn’t expect much chance of success.

    Besides, there are many ways to skin a cat. A reorg isn’t the only tool you have to change mindset across the organization. Heck, it isn’t even a very good one. Remember that when you start the next revolution just to see that virtually nothing changes as a result.

    By the way, there is a neat application of this idea in a bit different situation too. If you want to preserve mindset across the organization when changing leaders, pay very close attention how new leaders think. Your company can be a well-oiled machine, but when steering wheel is grabbed by a guy who neither understands nor cares about the existing mindset, the situation is going to deteriorate pretty quickly. You just don’t want to hire Steve Balmer to substitute for Bill Gates.

  • WIP Limits Revisited

    One of things you can hear repeatedly from me is why we should limit work in progress (WIP) and how it drives continuous improvement. What’s more, I usually advise using rather aggressive WIP limits. The point is that you should generate enough slack time to create space and incentive for improvements.

    In other words, the goal is to make people not doing project or product development work quite frequently. Only then, freed from being busy with regular stuff, they can improve the system which they’re part of.

    The part which I was paying little attention to was the cost of introducing slack time. After all, these are very rare occasions when clients pay us for improvement work, so this is some sort of investment that doesn’t come for free.

    This is why Don Reinertsen’s sessions during Lean Kanban Europe Tour felt, at first, so unaligned with my experience. Don advises to start with WIP limits twice as big as average WIP in the system. This means you barely generate any slack at all. What the heck?

    Let’s start with a handful of numbers. Don Reinertsen points that WIP limit which is twice as big as average WIP, when compared to no WIP limit at all, ends up with only 1% idle time more and only 1% rejected work. As a result we get 28% improvement in average cycle time. Quite an impressive change for a very small price. Unfortunately, down the road, we pay more and more for further improvements in cycle time, thus the question: how far should we drive WIP limits?

    The further we go the more frequently we have idle time, thus we waste more money. Or do we? Actually, we are doing it on purpose. Introducing slack to the system creates an opportunity to improve. It’s not really idle time.

    Instead of comparing value of project or product work to idle time we should compare it to value of improvement work. The price we pay isn’t that high as it would initially seem basing simply on queuing theory.

    Well, almost. If we look at the situation within strict borders of a single project value of improvement work is non-existent or intangible at best. How much better will the product be or how much faster will we build remaining features? You don’t know. So you can’t say how much value these improvements will add to the project.

    However, saying that the improvements are of no value would be looking from a perspective of optimizing a part; in this case a single project. Often impact of such improvements will be broader than within borders of the project and it will last longer than the project’s time span.

    I don’t say I have a method you may use to evaluate cost and value attached to non-project work. If I had I’d probably be a published author by now, had lots of grey hair and a beer belly twice as big. My point is that you definitely shouldn’t account all non-project work as waste. Actually, most of the time cost of this work will be smaller than value you get out of it.

    If we based purely on Don Reinertsen’s data and assumed that whenever we hit WIP limit people are idle we could come up with such a chart:

    On a horizontal axis we have WIP limits going from infinite (no WIP limit at all) to aggressive WIP limits inflicting much slack time. On a vertical axis we have overall impact on a system. As we introduce WIP limits (we go to the right side of the chart) we gain value thanks to shorter average cycle times and, at least at the beginning, improved throughput. At the same time we pay the cost of delay of rejected or queued work waiting to enter the system (in backlog) and the cost of idle time.

    In this case we reach the peak point of the curve pretty quickly, which means that we get most value with rather loose WIP limits. We don’t want to introduce too much idle time to the system as it’s our liability.

    However, if we start thinking in terms of slack time, not idle time, and assume that we are able to produce enough value during slack time to compensate the cost the chart will be much different.

    In the case number two the only factor working against us is cost of delay of work we can’t start because of WIP limits. The organization still has to pay for people doing non-project work, but we base on assumption that they create equal value during slack time.

    The peak of the curve is further to the right, which means that the best possible impact happens when we use more aggressive WIP limits than in the first case.

    Personally, I’d go even further. Basing on my past experience I’d speculate that often slack time results in improvements that have positive overall impact on the organization. In other words it would be quite a good idea to fund them as projects as they simply bring or save money. It gives us another scenario.

    In this case impact of slack time is positive so it partially compensates increasing cost of delay, as we block more items to enter the system. Eventually, of course, overall impact is negative in each case as at the end of horizontal axis we’d have WIP limit of 0, which would mean infinite cost of delay.

    Anyway, the more interesting point to look at is the peak of each curve, as this is a sweet spot for our WIP limits. And this is something we should be looking for.

    I guess, by this time you’ve already noticed that there are no numbers on the charts. Obviously, there can’t be any. Specific WIP limits would depend on a number of context-dependent factors, like a team size, process complexity or external dependencies, to mention only the most obvious ones.

    The shape of curves will depend on the context as well. Depending on the work you do cost of delay can have different impact, same as value of improvements will differ. Not to mention that cost attached to slack time vary as well.

    What I’m trying to show here is that introducing WIP limits isn’t just a simple equation. It’s not without a reason that no credible person would simply give you a number as an answer for a question about WIP limits. You just have to find out by yourself.

    By the way, the whole background I drew here is also an answer for the question why my experience seemed so unaligned with ideas shared by Don Reinertsen. I just usually see quite a lot value gained thanks to wise use of slack time. And slack time, by all means, should be accounted differently than idle time.

  • Leadership, Fellowship, Citizenship

    There was a point in my career when I realized how different the concepts of management and leadership were, and that to be a good manager one had to be a good leader. Since then the idea of leadership, as I understand it, has worked for me very well. I even like to consider my role in organizations I work for as a leader, not a manager.

    Perceptions of leadership shift these days. Bob Marshall proposes the concept of fellowship. The idea is based on the famous Fellowship of the Ring and builds on how the group operated and what values were shared among its members, so that they eventually could achieve their goal.

    A common denominator here is that everyone is equal; there’s no single “leader” who is superior to everyone else. At different points in time different people take over the role of leader in a way that is the best for the group.

    As Bob points, leadership doesn’t really help to move beyond an analytical organization (see: The Marshall Model). This means the concept of leadership is insufficient to deal with further challenges our companies face on a road of continuous improvement. We need something different to deal with our teams, thus fellowship.

    Another, somehow related, concept comes from Tobias Mayer, who points us to the idea of citizenship. Tobias builds the concept on a balance between rights and responsibilities. It’s not that we, as citizens, are forced or told to keep our neighborhood clean – it’s that we feel responsible for it. This mechanism can be transferred to our workplaces and it would be an improvement, right?

    I like both concepts. Actually, I even see how one can transit to the other, back and forth, depending on which level of an organization you are. On a team level, fellowship neatly describes desired behaviors and group dynamics. As you go up the ladder, citizenship is a nice model to describe representation of a group among higher ranks. It also is a great way to show that we should be responsible for and to the people we work with, e.g. different teams, and the organization as a whole.

    Using ideas introduced by Tobias and Bob we can improve how our teams and organizations operate, that’s for sure.

    Yet, I don’t get one thing here. Why fellowship and citizenship concepts are built in opposition to leadership?

    OK, maybe my understanding of leadership is flawed and there is The Ultimate Leadership Definition written in the stone somewhere, only I don’t know it. Maybe fellowship and citizenship violate one of The Holy Rules of Leadership and I’m just not aware of them. Because, for me, both ideas are perfectly aligned with leadership.

    Leadership is about making a team operate better. If it takes to be in the first line, fine. When someone needs to do the dirty work no one else is willing to do, I’m good with that as well. I’m even happier when others can take over the leader’s role whenever it does make sense. And what about taking responsibility for what we do, people around and an organization around? Well, count me in, no matter what hat I wear at the moment.

    When I read Bob and Tobias I’m all: “hell, yeah!” Except the part with labels. Because I still call it leadership. This is exactly what leadership is for me. Personally, I don’t need another name for what I do.

    I don’t say that we should avoid coining new terms. Actually, both citizenship and fellowship are very neat names. I just don’t see the point of building the opposition to ideas we already know. The more so as citizenship and fellowship are models, which are useful for many leaders.

    I don’t buy an argument that we need a completely new idea as people are misusing concepts we already have. Well, of course they are. There are all kinds of flawed flavors of leadership, same as there will be flawed flavors of fellowship and citizenship when they become popular.

    I don’t agree that leadership encourages wrong behaviors, e.g. learned helplessness. Conversely, the role of a leader is to help a team operate better, thus help eliminate such behaviors. A good leader doesn’t build followership; they build new leaders.

    That’s why I prefer to treat citizenship and fellowship as enhancements of leadership, not substitutions of it.

  • Why Burn-up Chart Is Better Than Burn-down Chart

    The other day I was in the middle of discussion about visuals a team was going to use in a new project. When we came to the point of tracking completion of the project I advised a burn-up chart and intended to move on. The thing that stopped me was the question I was asked: why burn-up and not burn-down?

    Burn-down Chart

    First, some basics. Burn-down chart is an old idea I’ve learnt from Scrum. It is a simple graph showing amount of work on a vertical and timeline on a horizontal axis. As time progresses we keep track how much work is still not done. The goal is to hit the ground. The steepness of the curve can help us approximate when it’s going to happen or, in other words, when we’re going to be done with the whole work.

    When we think about quantifying work it should be anything we use anyway – story points, weighted T-shirt sizes, simple number of tasks or what have you.

    Burn-up Chart

    Burn-up chart’s mechanics is basically the same. The only difference is that instead of tracking how much work is left to be done, we track how much work we’ve completed, so the curve is going up, not down.

    The Difference

    OK, considering these two work almost identically, what’s the difference? Personally, I don’t buy all the crap like “associations of the word burn-down are bad.” We learned not to be afraid of failure and we can’t deal with a simple word? Give me a break.

    The real difference is visible when the scope changes. If we suddenly realize we have more work to do burn-down may look like this.

    Unfortunately, it can also look differently if we happen to be (un)lucky enough to complete some work at the same time when we learn about additional work.

    It becomes even trickier when the scope decreases.

    Have we just completed something or has a client cancelled that feature which we talked about yesterday? Not to mention that approximating the finish of work becomes more difficult.

    At the same time, burn-up chart makes it all perfectly visible as progress is tracked independently on scope change.

    You can see scope changes in both directions, as well as real progress. And this is exactly why choosing burn-up over burn-down should be no brainer.

  • Refactoring: Value or Waste?

    Almost every time I’m talking about measuring how much time we spend on value-adding tasks, a.k.a. value, and non-value-adding stuff, a.k.a. waste, someone brings an example of refactoring. Should it be considered value, as while we refactor we basically improve code, or rather waste, as it’s just cleaning after mess we introduced in code in the first place and the activity itself doesn’t add new value to a customer.

    It seems the question bothers others as well, as this thread comes back in Twitter discussions repeatedly. Some time ago it was launched by Al Shalloway with his quick classification of refactoring:

    The three types of refactoring are: to simplify, to fix, and to extend design.

    By the way, if you want to read a longer version, here’s the full post.

    Obviously, such an invitation to discuss value and waste couldn’t have been ignored. Stephen Parry shared an opinion:

    One is value, and two are waste. Maybe all three are waste? Not sure.

    Not a very strong one, isn’t it? Actually, this is where I’d like to pick it up. Stephen’s conclusion defines the whole problem: “not sure.” For me deciding whether refactoring is or is not value-adding is very contextual. Let me give you a few examples:

    1. You build your code according to TDD and the old pattern: red, green, refactor. Basically refactoring is an inherent part of your code building effort. Can it be waste then?
    2. You change an old part of a bigger system and have little idea what is happening in code there, as it’s not state-of-the-art type of software. You start with refactoring the whole thing so you actually know what you’re doing while changing it. Does it add value to a client?
    3. You make a quick fix to code and, as you go, you refactor all parts you touch to improve them, maybe you even fix something along the way. At the same time you know you could have applied just a quick and dirty fix and the task would be done too. How to account such work?
    4. Your client orders refactoring of a part of a system you work on. Functionality isn’t supposed to be changed at all. It’s just the client suppose the system will be better after all, whatever it means exactly. They pay for it so it must have some value, doesn’t it?

    As you see there are many layers which you may consider. One is when refactoring is done – whether it’s an integral part of development or not. Another is whether it improves anything that can be perceived by a client, e.g. fixing something. Then, we can ask does the client consider it valuable for themselves? And of course the same question can be asked to the guys maintaining software – lower cost of maintenance or fewer future bugs can also be considered valuable, even when the client isn’t really aware of it.

    To make it even more interesting, there’s another advice how to account refactoring. David Anderson points us to Donald Reinertsen:

    Donald Reinertsen would define valuable activity as discovery of new (useful) information.

    From this perspective if I learn new, useful information during refactoring, e.g. how this darn code works, it adds value. The question is: for whom? I mean, I’ll definitely know more about this very system, but does the client gets anything of any value thanks to this?

    If you are with me by this point you already know that there’s no clear answer which helps to decide whether refactoring should be considered value or waste. Does it mean that you shouldn’t try sorting this out in your team? Well, not exactly.

    Something you definitely need if you want to measure value and waste in your team (because you do refactor, don’t you?) is a clear guidance for the team: which kind of refactoring is treated in which way. In other words, it doesn’t matter whether you think that all refactoring is waste, all is value or anything in between; you want the whole team to understand value and waste in the same way. Otherwise don’t even bother with measuring it as your data will be incoherent and useless.

    This guidance is even more important because at the end of the day, as Tobias Mayer advises:

    The person responsible for doing the actual work should decide

    The problem is that sometimes the person responsible for doing the actual work can look at things quite differently than their colleague or the rest of the team. I know people who’d see a lot value in refactoring the whole system, a.k.a. rewriting from scratch, only because they allegedly know better how to write the whole thing.

    The guidance that often helps me to decide is answering the question:

    Could we get it right in the first place? If so then fixing it now is likely waste.

    Actually, a better question might start with “should we…” although the way of thinking is similar. Yes, I know it is very subjective and prone to individual interpretations, yet surprisingly often it helps to sort our different edge cases.

    An example: Oh, our system has performance problems. Is fixing it value or waste? Well, if we knew the expected workload and failed to deliver software handling it, we screwed this one up. We could have done better and we should have done better, thus fixing it will be waste. On the other hand the workload may exceed the initial plans or whatever we agreed with the client, so knowing what we knew back then performance was good. In this case improving it will be value.

    By the way: using such an approach means accounting most of refactoring as waste, because most of the time we could have, and should have, done better. And this is aligned with my thinking about refactoring, value and waste.

    Anyway, as the problem is pretty open-ended, feel invited to join the discussion.

  • Code Better or Code Less?

    An interesting discussion (that might have happened):

    I would rather students apply their effort to writing better code than to writing better comments.

    ~ Bob Martin

    But…

    I would rather students apply their efforts to writing less code than writing “better” code.

    ~ Bob Marshall

    Because…

    There is nothing so useless as doing efficiently that which should not be done at all.

    ~ Peter Drucker

    Having read this, one realization is that better code often means less code. I don’t think about lines of code exactly, or something similarly stupid, but in terms of meaningful code. However, argument for less code isn’t about making code as compact as possible, avoid redundancy, etc.

    The argument is about not writing code at all whenever reasonable or possible.

    Should we focus on deciding what should and what should not built instead of polishing our software development craft then?

    Yes and no.

    Yeah, I know. Exactly the kind of answer you expected, isn’t it? Anyway, you can’t answer this question meaningfully without a context.

    Better code

    One perspective is the one of a developer. The developer in almost every medium-to-big organization, and in quite a lot of small ones too, is pretty much disconnected with product management/product ownership part of a project. It means that they have very little-to-no knowledge what actually should be built.

    Of course being a developer I can, and should, share my concerns about usefulness of building specific features but it’s unlikely I have enough information to judge such situations correctly in many cases. By the way, even when I’m right and this darn feature shouldn’t be built odds are that it’ll be built anyway because a client says so. Sounds stupid? Sure, it does! Does it make the client change their minds? Not very often.

    If you’ve ever worked on one of those big contracts where everything is (allegedly) specified upfront and no one on a client’s side is willing to change anything because of internal politics, you exactly know what I’m talking about. If you haven’t, well, damn you, you lucky bastard.

    So it might be a great idea not to build a feature but developers either don’t have enough knowledge to be aware of the fact or aren’t allowed to skip the feature anyway. In this case a better thing to do is to focus on building better code, not less code, because one can hardly say what meaningful less is.

    Less code

    The other perspective is the one of product management folks, however this specific role is called in your org. For them, their first and main focus should be on building less code. Yes, product owners, product managers, etc. Yes, less code. And yes, I do know they don’t write code. It still should be their main goal.

    You see, this is the place where meaningful decisions about not building features can be made. Product folks should know what adds value and what doesn’t. What’s more, they are usually better suited to start such discussions with clients, whenever needed. After all, it is so common that clients want, and pay for, unnecessary features and useless code.

    Organizational-wise you get more value, or less waste, focusing on building less code. Given that you’re free to work on both: better code and less code across the organization, it would likely be wiser to choose the latter. At the same time efficiency of your efforts depends much on the part of the organization you work with and, locally, it may be a much better choice to focus quality of code and not quantity of code as an issue to tackle.

    So if I could choose what kind of superhero posters are in rooms of my people I’d go with Peter Drucker for product folks and Bob Martin for developers.

  • Kanban Coaching Professional

    Frequent visitors might have noticed a new banner on the sidebar of the blog that says “Kanban Coaching Professional.” It might come as a surprise that I’ve decided to join the Kanban Coaching Professional program. After all, I used the word certifiction (no typo here) repeatedly, shared my concerns about the idea of certifying anything around Kanban and even showed my hatred to any certification at all. And now, I jump on KCP bandwagon.

    Why, oh why?

    Well, I must admit I like a couple things in the approach David Anderson and Lean Kanban University have chosen in the program. Peer review is one. To get through the process and become a Kanban Coaching Professional, you need to talk with folks who know the stuff.

    On one hand it sounds sort of sectarian – we won’t let you in unless we like you. On the other, it is just a good old recommendation process. I trust Mike Burrows so I trust people who Mike trusts, etc. This way the title means something more than just a participation trophy. Also, the seed people who will be running the decision-making process are very decent.

    There is a risk of leaving some people behind – those who are not active members of the Kanban community but are otherwise knowledgeable and smart folks. Well, I really do hope it won’t become some sort of coven who doesn’t let fresh blood in. It definitely is a risk Lean Kanban University should pay close attention to.

    Another thing I like is that there’s been an option to be grandfathered into the program. By the way, otherwise I wouldn’t be a part of this. I just don’t feel like attending a course just to be approved. That’s just not my way of doing things.

    I prefer to write and speak regularly about Kanban, showing that I do and know the stuff, instead of attending the course. Yeah, this is a hard way but it’s just the way I prefer. With such an attitude, there’s no way I’m going to be CSM, but it seems the Kanban community has some appreciation for non-standard cases such as myself.

    Actually, I hope this option will be kept open. I mean I can imagine great people with an attitude similar to mine – willing to get their hands dirty (and prove it) – but not really willing to attend the course.

    Because, when we are on the course, I’m not a fan of this requirement. I understand it is there for a reason and, to be honest, I don’t think I have a better idea for now, but I have the comfort of standing at the sideline and saying “I don’t like it.”

    I guess it is supposed to be a business, so there needs to be a way of making money out of it. For the time being though, not the business which I’m a part of.

    However, the simple reason that I could, and rather easily, become a Kanban Coaching Professional isn’t why I decided to give it a go. After all you still need pay some money for this, so we’re back to the question: “Why?”

    As Kanban gets more and more popular, I see more people jumping on this bandwagon, offering training, coaching and what have you. The problem is that sometimes I know these people and I’m rather scared that they are teaching Kanban.

    Not that I want to forbid anyone to teach Kanban, but I believe we arrived to the point where we need a distinction. The distinction between people who invest their time to keep in touch with the community, attend events, share experience, engage discussions, etc. and those who just add a Kanban course to their wide training portfolio because, well, people want to buy this crap.

    This is exactly why I decided to get enrolled in the KCP program. For this very distinction.

    I believe that, at least for now, it differentiates people who you’d like to hire to help you with Kanban from those who you can’t really tell anything about. This is where I see the biggest value of KCP. I really do hope it will stay this way.

    Unless the situation changes the banner will hang there on the sidebar and I will use KCP title as a confirmation of my experience and knowledge about Kanban. Sounded a bit pompous, didn’t it? Anyway, if you look for help with Kanban, pay attention to these banners or KCP titles.

  • Is a ScrumMaster of Any Value?

    Tobias Mayer, who I respect very much, recently put his thoughts about ScrumMasters into a blog post. The post that can be summarized best by its title: Delete [ScrumMasters]. The strongest point of the post goes as follows:

    “I believe the concept of ScrumMaster has done more damage to our industry than it has aided in change. It has been a way for individuals and organizations to jump on the Agile band wagon, in a mostly painless way (discounting severe certification costs) and continue to do much as they were doing before.”

    It isn’t a surprise for me that the post gained a lot of traction. Many experienced leaders in our community have quickly supported Tobias’ crusade.

    I haven’t.

    I agree with vast majority of what Tobias has written. I like the diagnosis he makes. I even believe we should be told such things by our thought-leaders. Yet I don’t jump on the bandwagon of spreading the epiphany: we don’t need ScrumMasters anymore.

    One of stories that instantly pops into my head whenever I hear about the role of ScrumMaster is the one John Cieslik-Bridgen, who used to be a ScrumMaster at Lunar Logic, shared with me once:

    “We were doing a “design your ideal team” exercise. In this exercise, I liked the fact that I wasn’t referred to as a ScrumMaster, rather ‘a John’, as in, “we’ll need ‘a John’”. I think the use of the word “coach” much better reflects what I try to do.”

    On a side note: I’d love to have “a John” as a title on my business card someday. After all, many teams need a John.

    By this point you may wonder, which part of Tobias’ post I haven’t understood, as the story is totally aligned with the article. Well, I have understood the post. John’s story, however, is just one side of the coin.

    The other is that few organizations are mature enough to hire, or promote, a John. Conversely, many companies lose their Johns, these great coaches and counselors, because they don’t have a named place for them. What’s more, organizations often need some kind of framework to even allow a role of a John. This framework very often happens to be Scrum and the role is called ScrumMaster.

    I don’t say it is a magic pill that solves every problem in an organization. I just say this step is often very helpful in moving to the next level for both the org and for a John.

    And yes, I can think of other, arguably better, means to an end of organizational and personal improvement, but I find this one working surprisingly often. To quote Tobias once more: “Sorry guys, it’s what I see.”

    I actually see much value if a John blossoms and eventually leaves the organization because it just scratches the surface and doesn’t really introduce agile values. At the end of the day we still have one more great guy on the job market.

    While I agree with the argument that the ScrumMaster role is often abused and I don’t really like how it is defined, I still consider it one of the valuable options for organizations. The option that may end in preservation of status quo, but also in creating a space for people who will take the org to the next level.

    Does it mean we should throw away the role as a whole? Well, in mature organizations, where there is a good understanding of the reasons that ScrumMasters were introduced and what they are supposed to do, I see no reason to cultivate the role or the title.

    On the other hand I still see the ScrumMaster role as a tool that can create space for change agents (I hate this name too) and catalyze improvements. After all, would there be a John without a ScrumMaster first?

    Have I just written a post in defense of the ScrumMaster role? Oh well…

  • Don’t Ask For Permission

    “It’s easier to ask forgiveness than it is to get permission.”

    ~ Grace Hopper

    As a leader of more than a hundred people I often get asked questions that I don’t really know how to answer. Well, I probably could answer pretty easily, although I don’t think “who, the hell, even asks such questions” or “maybe I could come up with some random piece of advice if you really need one” are really the type of answers they are looking for.

    On such occasions my default answer is Grace Hopper’s famous quotation.

    Don’t get me wrong, I’m not a fan of total anarchy. I do appreciate some order and asking for permission is an integral part of most of orders I know, if not all of them. However, when in doubt just take the advice from Grace Hopper.

    You may wonder whether this approach backfires on me sometimes. Oh yes, it does. I guarantee you this. Not very often, but pretty regularly. On such occasions, for a brief moment I wish that guy had asked what to do and had not simply done as he liked. But then I realize how much of a bottleneck I’d be with this attitude.

    Heck, not only would I be a bottleneck but also I’d restrain many of the great initiatives my teams pursue. I would tell them over and over again how much they’re begging for failure. Or even better – I’d keep them from failing. Except, eventually, they don’t fail. Damn those guys, they just don’t want to fail even though I predicted that.

    Actually, even when they fail, it is still better. After all, a failure is the best teacher and, as a bonus, I can use my clairvoyant hat: “Told you, but you wouldn’t listen.”

    When you think about it, the worst thing which can happen is that you might need to explain to a few very important guys why your team did what they did. And believe me, it doesn’t happen very often. It’s a pretty low price for all the great initiatives people pursue, the results they achieve, and the culture you all help to create.

    On a side note: when we are on the subject of culture, it probably is a cultural thing, but I find it interesting that we actually need to encourage people to go beyond hierarchies, procedures and rules. Otherwise many of them are naturally inclined to preserve the status quo.

    Status quo is likely nothing you’d like to preserve.

    So next time you have any doubts, just do the goddamn thing and ask for forgiveness. If you even need to do this after the fact, that is.

    Yes, I am well aware that quite a bunch of people from my team are going to read it.

    Yes, I know that some of them will take the advice to heart.

    Yes, I am pretty sure that they will use it in a way that (on occasions) will kick me in my butt. Hard.

    And yes, I am still happy with that. This is a tiny price for what I get in exchange.

    After all, if your butt isn’t kicked at all, you’re likely failing as a leader.

  • Local Optimizations Aren’t (Always) Evil

    A message that we hear over and over again is that we should optimize the whole and not the parts as local optimizations often (arguably always) result in making the whole operate less efficiently.

    I don’t want to bring up such stupid examples as counting lines of code (Want some? Here it goes!) or counting bugs (Whoa! On this screen there are several glitches. Why don’t I submit dozen tickets?). Listen to John Seddon’s stories for some less obvious examples.

    So let’s assume that we should focus on optimizing the whole.

    Now, tell this to this line manager who works for a couple thousand-employee organization. How the heck can this poor guy leading five people optimize the whole? Most likely he can’t. Well, of course he may, and should, fight his way up there to make his managers aware of problems he sees and help them to convince their managers, who need to get through to their managers, etc. A couple years later someone, finally, tells the CEO that she has a problem, so she makes the right decisions to optimize the whole.

    Except it doesn’t work this way. Most likely the message is ignored on one level or another. It’s actually pretty common that it doesn’t get through past the first level of a hierarchy. So we’re back to square one: our poor leader can’t optimize the whole. He neither has the visibility nor the power to do so.

    Should he fall back and sit silent?

    Hell no!

    He should make a goddamn paradise out of his tiny slice of the organization. He should optimize locally to the point where his team is the most effective team on the planet Earth.

    And yes, I am pretty much aware that many of these optimizations mean suboptimizing the whole. Actually, that’s perfect. Yup, I’ve just said it: that’s perfect. It means the guy’s manager needs to act. Set some boundaries or constraints. Point out how the manager harms the rest of the org. Otherwise the boss is just accepting the fact that the overall performance of his teams will drop. Of course he will still have this rock star team, but I guess you don’t get much praise for having a star player and, at the same time, seeing your team relegated to a lower league.

    There’s another nice side effect of the situation. These local optimizations, as long as they’re reasonable, are likely to virally spread throughout the organization. It means that the change starts affecting more than just a single team or even a division. It starts changing the whole org. For better or for worse. The role of senior managers is to funnel these changes into the right direction.

    After all, when our line manager changes the part of the organization which he can comprehend isn’t it optimizing the whole from his perspective?

    So roll up your sleeves and make your part of the company the best freaking team/division/what have you in the freaking world. Make your boss think how to set you constraints in a way that it doesn’t result in suboptimization of the whole.