Pawel Brodzinski on Leadership in Technology

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

Author: Pawel Brodzinski

  • Scrum versus Kanban

    These days every blog discussing agile topics should have a big hairy article on Scrum versus Kanban, so here it is. Well, just joking. Actually many people, way wiser than me, approached that subject some time ago already presenting different arguments. If you want to hear some of the strongest opinions out there check Ken Schwaber’s post on how Scrum is good and Kanban sucks. If you look for more weighted opinion David Anderson shared one. Just recently Mike Cohn also added very reasonable two cents to the discussion even though he actually doesn’t agree with David.

    Also there’s been a lot written about Scrumbut and Scrumban. I don’t see the point in repeating once again that if something works for your team – go for it, no matter if that breaks the orthodoxy of the method of your choice.

    Note: I’m well aware that until now I just share what I’m not going to write about. Is this post is going to be just a set of links to some good articles though? No, not exactly, but please do check mentioned articles – they’re a piece of good reading. Anyway, to the point. There’s one thing which is often mentioned as one of main differences between Kanban and Scrum but I think this is the core of the whole this versus that thing.

    The point

    From pretty much every Scrum and Kanban comparison you’ll learn that introducing Scrum is a revolution while with Kanban it is rather evolution. You’ll also be pointed that both approaches foster improvement. Now, finally, after all that beating around the bush: my point here is how Scrum revolution differs from Kanban evolution in terms of introducing improvements and why it is so.

    Team model and software development process

    Let me start with something I was learning for quite a long time (no, I’m not that bright to catch it during the first class):

    Scrum proposes pretty damn good team model and process for building software.

    If you look for model team which would work in majority of situations go for a Scrum team: cross-functional, small and tightly-integrated. If you look for healthy approach to software development you can’t really go wrong with Scrum. Scrum is well-thought and well-weighted approach. No surprise it ruled the agile world.

    On the other hand Kanban tells you that your team model is good for now, no matter how it is organized. And your process of building software is OK even if it’s pretty chaotic. For now.

    Kanban doesn’t propose any specific team model or software development approach.

    It basically means that you get no hints whatsoever how the well-organized team would look like. Nil. Nothing. Find out by yourself. No help here. Well, almost.

    The difference

    When organizing Scrum team you can basically turn your thinking off. Well, sort of. It’s all in the book. Someone took the effort to propose team model which I’ve just labeled “pretty damn good.” Same with the process you’re meant to follow.

    Kanban chooses the other approach: we don’t know what optimal solution for your team is. Here’s some help but you’re going to learn it by yourself.

    The difference? Pretty damn good doesn’t automatically mean optimal. Scrum is optimized for majority of teams, not for your unique group. Yes, of course, Scrum has improvement mechanisms, retrospective being the flagship here, but in terms of general rules it stays unchanged.

    Kanban accepts that starting point may be way worse than in Scrum case but leaves you all options open. You aren’t really constrained with specific practices or models. What you’re going to end up with is totally on you and your team.

    Help you get

    You can put it in other words if you prefer. Scrum tells you how you should change, at least to some point. Scrum is like your mother-in-law – she always knows that you suck here and there and how exactly you should act to be um… better.

    Kanban on the other hand is like your friend, close but probably not the best one you have. He’ll try to show you where you could improve but won’t state it explicitly. It’s just not that kind of relationship. It will be rather a set of hints and smoke signs – it’s you who chooses to use them to change yourself or just ignore them.

    Which one is better

    Neither. Despite comparisons I’ve just use I really think there’s no winner here. And yes, I’m generally considered as a Kanban guy but I also strongly believe there’s no silver bullet.

    If you need a kick start Scrum may give you one even though it imposes some constraints on the way you work. On the other hand if you have in your team someone who is experienced with variety of different methods it may be a good idea to start with Kanban and check where it’s going to lead you.

    After all, since I’m not an orthodox, I’ll also tell you should experiment like crazy, no matter which path you choose. Heck, that’s where all those Scrumbans started – people were changing their process, people were breaking The Holy Rules of The Method just to end up with something more optimal for them.

    Final thought

    If I want you to remember one thing from this post it would be: Scrum tells you explicitly how to organize work and improve things, while Kanban tells you nothing about the ideal models and helps you find out the optimal way by yourself.

    After all, this post is big and hairy so I guess I succeeded with the task anyway.

    Advertisement: Protect your business from a surprise software audit with License Dashboard.

     

  • Mechanics of Kanban Improvements

    As I’ve already started working on my session for ACE Conference 2011 I tinker at different improvements introduced by Kanban and the way they pop out. Actually if I had to point a single, most surprising for me, feature of Kanban I’d point exactly the way it fosters improvements.

    When we were starting with Kanban I expected it to be more a very lightweight approach, which organizes the workflow and doesn’t get into way, than something which may trigger any improvements on its own. Things didn’t really work that way.

    Yes, we fixed issues we’d faced at that time but that was to be expected. Then we kept finding new issues and correcting them. For a longer time I didn’t really put much thought how it worked but I had to explain somehow specific practices we introduced in my presentation on AgileEE as I wanted to talk about the subject. I realized that we didn’t plan them. They just popped out. Somehow. Magic?

    No, not magic. After short investigation I found the one to blame – it was Kanban. Thanks to using Kanban, specific problems were unveiled and we were just fixing them, sometimes completely unconsciously.

    One of my favorite stories is when I suddenly realized we had collective code ownership. Yes, it was totally out of the blue. “Wait,” I thought “didn’t we discuss it through? Didn’t we end up with conclusion that we wouldn’t have collective code ownership? What the hell?” Actually it appeared that it was just easier to have collective code ownership in a pull system, such as Kanban, so people stopped thinking whether this is their own or someone else’s code. After some some time we had collective code ownership implemented basically effortlessly.

    That is exactly the mechanics of Kanban improvements. You introduce them because it’s just easier that way. You either see something is wrong on the board and have a quick discussion how to tackle the problem and implement a solution or people start dealing with the issue unconsciously. Either way you end up with your process slightly improved.

    And you repeat this activity. Multiple times. After some time when you compare what have you started with and what you ended up with you start thinking: how the hell this whole improvement thing in Kanban works? You can’t see it but somehow it’s happening. All the time.

    Well, it seems it just works that way. Don’t complain, just make use of it.

  • Project Management Styles: The Good, the Bad and the Ugly

    This time a quick look at different types of project management styles. Since I’m dealing with many different teams and many different project managers I hear plenty of opinions about PMs and approaches they employ in their work.

    Somehow those opinions tend to support one of three general pictures: the good, the bad or the ugly. Somehow those opinions tend to be pretty aligned. My wild-ass guess: that’s not without a reason. Actually the more I think about that the more I’m sure I could put any project manager I know in one of these buckets.

    The Good

    You know your job. You try to do your job well. It doesn’t mean you don’t fail. Oh, you do, that’s for sure. However chances are good that every failure is an occasion to learn for you.

    The funny thing is the sole reason that you know your job and try to do it well isn’t enough to be respected by people around. There’s something more. You can adjust yourself to changing environment. After all, as a PM, you’re in the middle of the mess, usually called “a project.”

    You’re a good observer. You know about people you work with. Sometimes you know about them more than their managers or themselves. You call risks out. Not only project-related ones. Also those which are tightly connected with people and their characters. That doesn’t mean you’re always listened. Heck, that doesn’t even mean you’re often listened. But it isn’t a reason to stop trying.

    You’re good but it doesn’t mean you don’t have rough edges. Oh, you do. A lot of them. So yes, we had our fights and misunderstandings. It’s likely we filed each other under “problematic” label after our first meetings. But then, we both know this job takes all sorts and it’s our mutual business to find a way to cooperate well. What more, we clearly stated what we expect from the other side which helped to shorten the process of learning each other.

    Now, you’re one of those who I want to work with. I mean really. You aren’t an easy partner but discussion with you is never a waste of time, even if part our ways without finding consensus. It’s good to see you popping up in my office even when you bring a problem with you. It’s good to know you’ll be running projects I care about.

    Besides, that’s not only my opinion. People keep pointing on you as a project manager they’d like to have in their projects.

    The Bad

    For whatever reasons you don’t really like what you do. It may be anything from feeling you’re predestined to something other/better to belief that your work isn’t appreciated enough. Either way you don’t like the point where you stand.

    The real problem is you don’t do much to turn things around. If we don’t count complaining that is. It’s either definition of your role which is wrong or expectations are too high or boss is a jerk or project is a nightmare or moon is in the wrong phase. You feel a kind of doomed. You can’t work the way you’d like and you have no guts to consistently work to change things around.

    As a PM you have your power though. You use it to show that you are important. You request compliancy, you condemn overruns, you demand people, resources and budgets. There’s interesting thing here – you seem to always know the answer. The best solution is the one you point. And if reality doesn’t stick to it, well, so much the worse for the reality.

    Somehow almost everyone around never lives up to your expectations. And almost everyone around would say about you exactly the same. They keep asking what exactly you are responsible for as they’re suspicious enough to think it should be more than you seem to accept at the moment.

    We might have had our fights, but that’s not so obvious. You might have been just ignored in a well-mannered way. Chances are good you haven’t really fought for your projects. After all the whole world is allied against you, isn’t it?

    Besides, that’s not only my opinion. Most of project teams which worked with you will prefer some other project manager. They won’t be totally disappointed with having another project with you though. After all it’s better to have someone who isn’t supportive but isn’t a pain in the ass either.

    The Ugly

    You consider yourself as a damn good project manager. You’re a tough type, but that’s what this role taught you to be. You don’t care whether you’re liked or not. This job isn’t about being likeable but about pushing projects to their end. Yes, that’s the word, you push these projects. Without you all developers would end up reading news or playing Counter Strike all day long.

    You know how to use project management tools you have. They may say you’re kind of formalist but that’s how you show who failed with their tasks and where eventual project failure should be addressed. Also your ass is always covered. You have e-mails, documents and such for every problem in the project. In the worst case you can say: “Haven’t I told you that?”

    I have mixed feelings about you. Sometimes you’re able to put together a group of people and make them playing as project team. Sometimes playing a bad sergeant brings projects closer to the successful end. Unfortunately at least equally often your approach triggers allergic reaction in project teams which brings additional issues to the project. You have an ability to change performance of teams. The problem is it works in both directions – sometimes it goes up and sometimes it goes down.

    By the way: your successes seem to be interlaced with failures – isn’t that surprising? With your rock star project management skills every project should be a stunning success. I know it’s always team’s fault but hey, there are fellow PMs who seem to have much better success rate.

    Besides, that’s not only my opinion. People say different things about you. There are those who consider you as a model project manager and those who prefer to have no project manager at all than to have you to lead their projects. Have I already mentioned “mixed feelings?”

  • Good Waterfall Is Better Than Bad Agile

    Lech brought an interesting subject recently: isn’t running an R&D project with heavy-weight, structured approach extremely difficult?

    We use to think that we need very flexible approaches for projects which aren’t defined very well, thus agile being frequently a tool of choice for R&D projects, which bear a lot of unknowns by definition. After all can you really produce reliable plan for a research project? It is research; you don’t really know what you’re going to end up with.

    But we fall in the trap of simplifying things. When we think about heavy-weight approach to project management we instantly see BDUF waterfall project with no checkpoints on the way carried through without taking changing conditions into consideration. Yes, there are still a lot of projects done this way but this isn’t the only way of running projects non-agile way.

    The trick with R&D projects is that you wander through unknown areas. It doesn’t mean you can’t plan you journey though. It doesn’t mean you can’t assess your progress and change your course along the way. It doesn’t mean you can’t measure where exactly you are or compare that against expectations which were set up front.

    What more, to some point agile, when done well, enforces us to do exactly that. But then every reasonable approach, no matter whether it’s heavy- or light-weight, does the same. We can have inspect-and-adapt attitude with pretty much any project management approach used these days.

    The real problem is we often misuse tools we have. Project management methodologies aren’t an exception here. When we fail to apply our project management approach reasonable it doesn’t really matter which one we choose – the result will always be poor.

    So my answer for the problem from the beginning of the post is: as long as your project management approach is well-organized and reasonable your R&D project will go well. It doesn’t matter much whether the method is heavy- or light-weight. However if you fail to apply the approach right way don’t expect much of success in your project even if the label on you’re a tool of your choice says “agile.”

    In other words good waterfall is better than bad agile.

    Since I expect “but good agile is better than good waterfall, especially for R&D projects” kind of argument I’ll answer it up front: it depends. It depends on many factors, starting with your domain, going through organizational culture and ending with people you work with. And yes, we can discuss each case separately.

  • Kanban Board: Keep It Simple Stupid

    In one role or another I often help teams to try Kanban out or just to help them to create their task board or Kanban board. There is an interesting pattern I observe.

    First thing is happening when a team discusses what columns should appear on the board. It is very common, and advised, to start working with Kanban with exactly the same process you already have in place. You could expect people would know it by heart. It should be really quick: “we do this, this and that, so it goes to the board.”

    Well, it appears that “process we follow” is pretty ambiguous most of the time. There are discussions whether something is a separate stage of the process or rather a part of the bigger task etc. People find they don’t really know where to put specific tasks as they’re floating depending on a number of factors. It appears the process isn’t really defined or not everyone is on the same page or people understand their tasks differently.

    Note: it all happens without any change in the process. No wonder why many process transitions are failed. What do you expect when people don’t really get how they’re working at the moment, let alone how they’re supposed to work?

    Then there is another observation. In the long run Kanban boards tend to become more and more complex. As teams work with their boards they add something to the structure more often than they remove anything. That’s perfectly understandable. When people learn better their process and the board which should reflect the process they have more ideas how to improve it. So they do, adding things and making the board more complex over time.

    Usually later version of the board has more columns/sub-columns/lanes/you-name-it than the earlier one. Sticky note bears more information too. Well, if you compare the first version of our Kanban board with the last one you’ll exactly see exactly the pattern.

    OK, but where does it bring us?

    Considering these two things: we usually don’t really know the process we try to map with the board and the board becomes more complex over time we should avoid over-engineering the board. Start simple and keep it simple. Don’t try to map every possible issue with the initial design of the board.

    I would even say that the idea to start with a single “ongoing” column representing the whole process of doing the work is pretty good. You will split it anyway but at least you will know exactly why you’re doing that and which stages you want to make explicitly visible and separated from others.

    When crafting your board, if you have doubts whether you should add a column or lane or something or not as a rule of thumb you shouldn’t do that. You’ll do it later… if you really need it.

  • Why Money Doesn’t Motivate

    I touched money and motivation subject recently. Since the post generated quite a discussion it seems the subject is important for many. It also seems many people disagree with the opinion that money doesn’t really motivate which is nice since it gives me excuse to beat the dead horse again.

    In short my points were:

    • Money is more a hygiene factor than a motivator.
    • When you pay less than some healthy level expected by people they start looking for a job.
    • As long as you match people’s comfort level they get, or don’t get, motivated by non-monetary factors.

    I received a number of counterarguments in comments, which I’ll try to address here. I’m aware I overstate bit here and there but that (hopefully) doesn’t change validity of arguments.

    Money does motivate people (and go sell your crap somewhere else)

    A nice thing about Dan Pink’s TED Talk is that he’s making a case. He brings arguments – studies made all over the world – to prove the point: money doesn’t seem to make people work better. Now, I haven’t looked very hard to find research studies which prove the opposite, but maybe you can redirect me to them. For now I consider it is 1:0 for Dan’s team.

    I saw teams whose productivity increased significantly just after bonus money was promised. The problem is usually they were just tricking the system. They knew they could do the job in given time but it was better to slack at the beginning waiting for the magic wand of extra money to be used. Then everybody got at full speed to save the project. The only thing which surprises me is where the hell the management was and why nobody did anything about that sick situation?

    I know lots of examples of people working their asses off because project required their extra effort. Usually they got a big bag of money at the end and everyone was happy. Does it mean money motivated them? Well, I think we’re messing the cause with the effect here. They didn’t start discussing with their managers how much they were going to get. They just gave more, because they thought it was a right thing to do (I know I totally oversimplify here, but we won’t discuss everyone’s individual drivers here, will we?) Then the effect usually was they got some extra money, which was of course completely fair.

    And for the end, if money motivates people my question is: why they don’t get more and more motivated as they get more and more money? I gave quite a lot raises and huge piles of extra money in my career and my observation is it makes people happy. Happy, not motivated. They’re engaged as they were. They give a lot, as they did. But somehow they don’t seem to be motivated better.

    Of course sometimes they consider the money they got as an insult and their motivation fall flat in its face but we’re talking about motivating, not de-motivating, here.

    Companies (and villains running them) want to have engaged people but only to exploit them (that’s what villains do after all)

    That’s true for some companies and some villains running them. But if that is your only experience with your employers please accept my humble condolences. There are toxic companies out there. There are normal companies with toxic managers as well which, from employee’s perspective, is no different. The world however isn’t inhabited with villains only. There are superheroes as well. If you’re sick of work among bad guys maybe it’s time to join Rebel Alliance, La Resistance or other good guys of your choice.

    I know it’s easy to generalize basing on your own situation and experience (that’s what I do on the blog virtually all the time), but be sure to check what’s happening out there in other organizations, especially when your experience is limited to one or a couple of teams/companies.

    Because of rapid development of IT industry we face deficit of good, experienced leaders and managers. It’s even truer in countries where the industry is even younger, like in Poland where I live. But still, that’s not a reason to dismiss the existence of healthy companies or decent managers.

    People should earn amount they expect or they get frustrated (which is bad since frustration is such a nasty word)

    Well, yes. Sort of. We come back to the discussion over a healthy level of salary. If I get paid above some expected minimum, which is a very individual thing, I could always use a raise but I don’t get frustrated about money. However if you asked me how much I wanted to earn my answer would be likely something more than I get. That’s how humans work – we always want more than we have.

    And now that you asked me, yes, I do have a pitch to ground why I should earn more. But don’t be stressed, I’m not going anywhere only because my pitch doesn’t convince you. See? I’m not frustrated.

    However I do agree that once we don’t get the amount we expect there’s always a risk that the other company would offer us more and then we’d be really incentivized to make a move. But I guess that’s the risk most of companies tend to accept. After all last time I checked running a business was about earning money and not spending everything just to pay people more.

    Best moment of motivation is when you see the money on your bank account (let’s switch to weekly wages, shall we?)

    OK, I admit, I don’t get this. At all. You mean once you see a bunch of money on your account you’ll be coding like crazy till the night? Would it be a better motivation to earn weekly wages than monthly salaries only because they’re um… more frequent?

    It’s difficult for me to address this argument but I guess we define motivation differently. As industrial bloodsucker I consider motivation as something good not because the word sounds nice but because motivated people tend to produce better results when they work. Call it a better productivity, bigger involvement or whatever.

    I understand people are happy when they see salary on their account but if we can build no connection with their work quality whatsoever let’s not call it motivation, OK? Of course feel free to correct me if I’m missing something here.

    Over time people get more experienced so they should get raises (like levels in RPG games)

    Um… no. Next please!

    Well, actually that’s the tricky one. Once we get more experienced and more knowledgeable it’s a natural thing we tend to want more, thus expected raises. The problem is employment isn’t an RPG game and our contracts aren’t a leveling system.

    Contract and salary represent a result of a kind of compromise. It’s about how much specific employee is worth for specific employer. It means that the same employee would be judged, and paid, differently depending on the hiring company. And yes, it does mean your salary depends on company’s clients, hiring strategy, specific managers you’ve been talking with, shape of the industry, organization’s career paths and a hundred of other factors which are completely independent on you.

    Sometimes getting more experience and/or knowledge doesn’t make you more valuable for the company. So maybe it’s time to learn what makes one a more valuable person for the specific organization instead of waiting for a reward for seniority?

    There are many jobs which can’t be loved which means people do them for money (after all love and money are the only motivators in the world)

    True. There are many jobs which can’t be loved, especially in the corporate world. But that doesn’t mean people do them for money and for money only. If they hated virtually everything about their jobs they would be looking for new ones like crazy. Somehow vast majority of them do not. I assume it’s not that bad then.

    We don’t get frustrated with our jobs in a second or after a single issue. Frustration grows over months, possibly years. Then yes, it is about a single problem or a single situation but it’s just the last straw.

    Our happiness with our jobs is a complex thing. I could count multiple things I’m happy with and multiple of those I’m definitely not happy with. However the overall mark is pretty good so I’m not going anywhere and probably one new ugly thing isn’t changing this attitude.

    I think it works pretty much the same with jobs which are considered as, well, not-so-nice. Corporate world is the one where conditions are usually less humane but then majority of corporations don’t deal with the risk of being extinct in a few months – something which is pretty common among startups. It’s of course only one of examples but the theme is similar in many cases. After all, when the company offers only jobs which are totally hated they’re going out of business soon as CEO won’t deliver all the projects single-handedly.

    Now, I’ve shared my arguments a little less briefly but I’m sure I haven’t convinced everyone (that wasn’t the goal by the way). Let’s get the heated discussion started.

  • Definition of Done

    Shim Marom’s post on (low) value of industry reports launched an interesting discussion in comment section, which I took part in by the way. The point we reached was how we define whether the project is completed or not.

    And here we come to the definition of done, term which I learned from Glen Alleman.

    On Time, On Budget, On Scope

    A definition which you will hear most often is project delivery on time, on budget and on scope. And there comes a problem. If we overrun a budget for ten bucks are we still on budget or not? What about thousand? Or hundred thousand? Depends on project, right? So what about 0,1% budget overrun? 1%? 5%? Where is the border between success and failure?

    Note: I haven’t even started with time or scope.

    While this definition sounds nice it hardly responds to typical complex project environments.

    The Story of Changing Goal

    I love the Apollo 13 story. Not only because it is a great story about heroes, but also because it is a great story to learn about project management. If I asked you what was the original goal of Apollo 13 mission probably no one would answer correctly. But well, they definitely hit the space for something more to become a base for a Hollywood movie or to coin one of the famous quotes (one of famous misquotations actually). The thing we remember is that Apollo 13 mission’s goal became saving astronauts’ lives. And we all consider it a huge success.

    Were original goals accomplished? No. Probably neither of them. The money was spent however. Probably more than planned because of unexpected problems. But over the course the goal has changed.

    Recently I’ve read similar story about Sir Ernest Shackleton’s Antarctic adventure. It is 18-month long story about fighting for people’s lives. And again initial goal, which was crossing Antarctic continent, was rendered invalid just after several days and the main problem became coming back home in one piece. Thanks to his commitment and determination Shackleton was successful in rescuing every single man from his expedition. Considering conditions a stunning success.

    Was Shackleton able to pass the Antarctic? No. Failure then?

    Maybe You Tell Us About Real Projects…

    You may say that those stories aren’t about typical IT projects which we deal with everyday. Yes, these are extreme examples but the same pattern we see very frequently, but in a bit different scale. Hey, that’s what embracing change is all about. We try to adjust the course of our projects to make them better respond to clients’ needs.

    After all I don’t believe all projects you took part in were specified perfectly at the beginning and carried through relentlessly to the end according to unchanged plan. My wild guess is only few of you had a chance to work on at least one project which looked a bit like that (and yes, Glen is probably among those few).

    Clients often deliver some wishful thinking as requirements, and then vendors go through them only roughly and come up with a generic document which describes fuzzily what should be done. No surprise the real goal appears to be changing over time as everybody realizes all the assumptions and gaps in initial plan.

    Definition of Done Is Changing

    OK, so goals are changing over time. So is definition of done. We usually do a crappy job defining done. But then we’re even worse in adjusting the definition along the way. We change expected costs and schedule. We change scope. Do we change our definition of done as well?

    I mean unconsciously we do, that’s for sure. After all we’re able to follow our gut feeling and tell this project was a success and that was a failure. We know that major schedule slip will be quickly forgotten if delivered software exceeds expectations. We know that being on time on budget and on scope isn’t a reason to boast when the client doesn’t use the system at all for some reasons.

    So yes, we should know what done means in each and every project. And no, we won’t have a single, universal definition which we can use against all our ventures. It is a very individual thing.

    That’s by the way the reason why the industry reports on state of projects will be criticized over and over again. There just aren’t universal measures which would be widely acclaimed.

    http://main.wgbh.org/imax/shackleton/about-one.html

  • The Kanban Story: Retrospectives

    Chapters of The Kanban Story are published pretty irregularly these days but it doesn’t mean the story is over. This time, encouraged by Michael Dubakov’s great post on retrospectives, description of our retrospectives.

    The first thing is we generally don’t hold meetings. At all. This also means we don’t have retrospective meetings. At all. Also, if you asked the team about retrospectives, you’d get mixed answers. Some would answer positively others negatively. Yet I keep saying we do have retrospectives.

    The pattern is very simple: every time someone sees an issue which seems worth reviewing we start discussion. Here and now. Without waiting for a meeting or something. Then people who are interested join the discussion. We also poke people who we need feedback from and they haven’t yet joined us. We try to finish this retro with some action points, but sometimes our action point is “do nothing” as we agree we have no quick idea how to do things better than we already do.

    Doing nothing about the issue isn’t a big deal since when it is important it’s going to come back soon.

    These retrospectives are, by design, very short as they touch only one problem each. We usually finish in less than 5 minutes; hardly any of them lasted longer than 10 minutes.

    Retros are done on the fly. On one hand we don’t prepare ourselves to the discussion but on the other we start talking when the problem is fresh which compensates lack of preparation.

    Prerequisite to this approach is co-location. If you start talking and expect to be heard, everyone should be in the same place.

    Now, the tricky part: interruptions. Sometimes it happens we interrupt others when launching retro. We all know it is costly. However, an interesting thing I’ve noticed is that we’re pretty good at “turning ourselves off” when we’re in the zone. It happens over and over again that we need to poke someone to get him involved in discussion as voices in the room aren’t enough to break into the zone. This means we limit a number of interruptions only to those situations when we really need someone’s input.

    I’m not sure why it works that way. I don’t know if we worked that way from the beginning or I should attribute that to maturity of the team. The trick is it works.

    Of course this is only one of many possible approaches to retrospectives in Kanban. I recommend reading Michael’s article along with comments if you want to learn others.

    Read the whole Kanban Story as well.

  • Money and Motivation

    A few people have left. Or I should say a few good people have left. Yes, the company has tried to stop them but well, when people decide to go it’s usually way too late.

    The next station is realizing that people are gone. Well, they will still come to the office for a couple of weeks but they are gone. Gone. If you wanted to change their minds you should have worked with them a few months earlier.

    And then there comes the idea that you should at least take care about those who are still here. When people leave, their colleagues start thinking about leaving too. That’s how it works.

    So we come to the point where most of managers use tools they have to keep retention on reasonable level. Quite often they use the only tool they think they have, which is money. “That should keep them motivated for some time. And they won’t leave either.”

    Yes, except it isn’t true.

    As I think more about money and motivation I’m closer and closer to Dan Pink’s approach: pay enough to get the money off the table and then focus on things which really motivate people. By the way if you haven’t seen Dan Pink’s TED talk about the subject you really should do it now.

    OK, so what kind of effects you should see when you throw more money at people? For some of them it would take the money problem off the table. Will it keep them in the company in the long run? I don’t know. You are either able to build creative, motivating work environment or you aren’t and raise won’t change anything in the long run.

    For others money wasn’t the issue in the first place. They will happily accept raise, that’s for sure, but is it going to change their approach? Not so much.

    Now you can point a number of examples when someone you know has changed jobs purely for money. I think they fall into the first group. The only difference is in their cases money was a major problem and not a minor one. Bigger salary doesn’t make them motivated – it just gets the problem off the table. It isn’t guarantee that they won’t eventually leave. If your organization suck they will. You can buy a few months but the outcome is going to be the same – they will be gone soon.

    In short: if you have a big bag of money you can make people stop complaining about their salaries, but you won’t make highly motivated top performers out of them.

    I know people who are leaving with no change in remuneration whatsoever. Heck, if you look for people who changed job and got lower salary in the new place I’m one of examples. And yes, I’d do it again. I’ve never left any organization (or project) for money, even though sometimes it was an issue.

    If all you have is a hammer everything looks like a nail. If the only tool you have is money, every problem seems to be solvable with cash.

    But then you see teams which don’t get any bonus money whatsoever and they’re motivated and those which spend days complaining about lack of bonus money. All in the same organization. They are even paid basically the same. I see two possible explanations: one supports argument above and the other includes words “black magic.”

    If people go, you won’t change that if the only thing you can think of is throwing more money at them. Unless you’re paying peanuts, that is.

  • We Are Unique Syndrome

    That Scrum thing sound fine but, you know, the way we work here is quite specific so it won’t really fit our organization. And yes, unit testing is such a great idea but we have pretty unique work environment and I see no way to implement this practice. Oh, I’ve heard about this new web framework, which we might use, but I believe it would be better just to build the stuff in-house. And by the way, that issue we were discussing yesterday – just apply some hacks, I don’t think anyone could have had this problem before.

    You’ve definitely seen that. The canonical example is NIH syndrome often seen in programming. We hate tools built by others because, well, they aren’t built by us. We are so damn unique that there’s virtually no other organization similar to ours in the whole damn universe.

    The same principle applies to other areas as well. Cross-functional teams work in other organizations but here, in this unique, extraordinary and special company they would not, no way. Empowering (damn, I used the word) people results in better motivation and higher retention but it won’t be like that in our organization because we are different.

    Well, yes you are. Everyone’s special. But somehow huge numbers of companies face the same problems. And the funny thing is it seems that usually common solutions help majority of those organizations. Strange, isn’t it?

    While you can pretty easily convince me that your company is special in this or that area (I don’t know your company as well as you, so it’s not that hard) I just don’t believe you’re so freaking different that none of recipes known to the world works in your case.

    If you come to me with unsolvable issue with integrating web services written in Java and .NET I call bullshit. I don’t know the solution but I find it hard to believe that hundreds thousands of web services written in one technology can’t talk with hundreds thousands of web services written in another. Either I miss something here or this was kind of principle for guys who were standardizing this web service gizmo.

    Someone had that problem before (like hundreds or thousands people). You ain’t that special.

    Now go look for solution using this hi-tech tool called Google search. Or you’re so unique that you won’t use such a plebeian tool, eh?

    The same applies to project management issues. Ditto organizational and people problems. Pretty few people in the world can say they worked in truly unique environments on ground-breaking ideas and they had to solve issues no one had had ever before. Yet we all tend to play like we were working on Apollo program and it was sixties.

    Now, I’m not trying to tell you that silver bullet exists. I’d be a hypocrite, wouldn’t I? What I’m trying to say is that your issues have (likely) been solved by others and they (likely) described solutions in details.

    If you deliberately want to keep the way you work unchanged I’m fine with that. Just don’t tell me it’s either the best or the only way unless you have checked. And if you’d checked you (likely) wouldn’t have been selling me that bullshit about your uniqueness.