I made quite a bunch of difficult decisions in my professional life. I underestimated their negative impact a few times. I received a lot of flak for making them in the first place. And I would probably make vast majority of them again if I had a chance.

I also restrained myself and didn’t make a few harsh decisions. Sometimes I wanted to do it but couldn’t, sometimes I could but didn’t have guts and sometimes I just didn’t want to deal with consequences. Given the chance I would likely act differently in these situations.

It seems I’m a bit gung-ho when it comes to fighting status quo. Why?

Well, first thing is that whenever you’re reading a story how a company was turned around the story always has this big change, which eventually results in a new, better situation. If you’re doing great that’s fine – do more of whatever you’re doing.

However, pretty few of us are in a position where we can say that we’re doing totally fine. It means that we need to try, sometimes hard, to change things around us. It means that we need guts to make difficult decisions on occasions.

What kind of decisions you ask? Well, so far the most difficult decisions I made were somehow connected with people. It was either about letting them go, which may be just a neat metaphor for firing, or not giving them what they wanted, or moving them out of their comfort zones.

After all, if everyone around is happy with your decisions, they aren’t difficult.

So we come back to the question which so far I’m trying to avoid answering to. Why am I willing to face unpleasant consequences instead of just accepting status quo?

One answer would be that I’m physically unable to accept mediocrity. I mean, in the long run. It doesn’t mean that I’m not willing to work in an organization that sucks. I did, at least once, and even though the starting point was really appalling, the thing which kept me there was a chance to change things around. The thing which frustrates me way more, and mean much, much more, is when you aren’t allowed to improve the situation even if you want it badly. Then, it doesn’t really matter what the starting point is. It may be decent but if it isn’t going to change my frustration will grow. And I don’t like to be frustrated, thus guts to make difficult decisions.

Another answer would be that the real change more often than not requires difficult decisions. I like a metaphor I learned years ago from one of my friends: “powdering shit.” It doesn’t make it smell better or be more pleasant. It’s just fooling yourself – “it is powder, you see, not shit.” Well, no, not really. It smells like shit, looks like shit, it is shit. Sorry. Powdering it doesn’t improve it. At all. You want to change the aroma? Clean the mess. Get your hands dirty. There’s no easy way. The only way is difficult (and unpleasant). Thus difficult decisions again.

It doesn’t mean that bold decisions are a way to go in each and every situation. No. The problem is, it’s way easier to find people who prefer accepting mediocre status quo than painful changes for the better. 4 out of 5 people (OK, I’ve just made up this statistic) will prefer to wait to the least possible (possible, not reasonable) moment before they make a difficult decision. Sometimes this waiting takes years. Years of mediocrity or, even worse, years of witnessing how the situation slowly deteriorates to the point where company goes out of business.

And this is another reason for difficult decisions. There are few people having guts to make them. People, in general, would likely accept them, even though some of them would complain, but they don’t make them. Ever. Unless forced. Even if they say otherwise. After all, who likes to do unpleasant tasks? So yes, my gung-ho approach sort of compensates ultra-conservative approach of majority, thus difficult decisions once more.

Now, don’t understand me wrong – difficulty that goes along with a decision doesn’t automatically make it a good one. You can be wrong with a difficult choice as well as with an easy one, except in former case it will hurt you badly. No risk, no fun, they say.

However, when I think about wrong decisions I made, somehow majority of them are those which seemed ease at the time of making them. It was sort of accepting status quo. “It was always like this, why would you want to change it?”

To make it better. To make our teams better. To make our work better. To make our products better. To catch up with ever-changing business environment. Or, in other words, to keep the organization alive in the long run. Not a bad motivation, eh?

David Joyce shared a short story on Twitter how a team was told by a coach to switch from Kanban to Scrum and they eventually got back to what they’d had initially. It seemed to that the team had been operating pretty well in the first place so I was curious why they were told to change.

It seems that coach’s argument was that they weren’t agile.

Ouch.

I think I should start with a few disclaimers. Yes, you can officially consider me a Kanban proponent. No, I don’t think that Kanban, in general, is superior to Scrum (or any other specific approach). Yes, I like Scrum and witnessed it working very well for some teams. No, I don’t think that Scrum, in general, is superior to Kanban (or any other specific approach).

I do however have problem with people selling agile, or any other approach, as it was the one and the only revealed truth. I do have problem with people selling agile as the way of life. I do have a general problem with any orthodox folks out there selling their snake oil.

The problem is there are more and more such people. Agile is already a business. Scrum is a business as well. Soon Kanban will be business too. This means there is plenty of people who are selling ready-to-apply solutions without even thinking how they might be used in a given environment. Or whether they are applicable at all.

You should avoid these people. The problem isn’t that they aren’t helping. It’s even worse. They are actively harming your team.

One theme which often comes to me whenever I’m working with different teams or preaching agile or lean is that not only should you learn the method of your choice, but also understand why it works. “Whys” are crucial here.

If you understand why a specific practice or rule is there you can fine-tune it in a way that doesn’t harm the team, or substitute it with other technique which covers with the same gap. Otherwise it’s just following the book.

Now, it’s perfectly fair to follow the book if you and your team aren’t experienced with different methods and don’t have answers for all the whys at hand. However, if we take coaches, people who earn money teaching us, it is their freaking duty to understand how, why and where tools they sell happen to work.

Otherwise they are like the coach from David’s story. Selling his snake oil with bullshit arguments like “it isn’t agile.” Well, I’m not agile, so what? Would my customers pay me even a buck for being so? I thought they were paying me for software I build and using this or that method is reasonable if and only if it can help me to be more effective.

When I see snake oil salesmen I’m sad. I’m even sadder when I see people buying their snake oil. If we can do anything about this, we can try to reach as wide audience as possible with our message. Avoid orthodoxy. Avoid people who have the same answer for every problem. Avoid those who can’t answer your whys. And don’t be afraid to call bullshit.

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.

The ACE Conference 2011 is over. To make this summary kind of organized I should go through my opinions on speakers and sessions, organization, networking and such but, well, screw it – I’m going to start with my final thoughts.

ACE Conference is a hell of a conference. I mean, really. I was leaving with the feeling that the event has improved significantly when compared to the previous one. It’s already kind of kick-ass event. Attending next year’s edition is no-brainer for me. And so should it be for you.

OK, so let’s go back to the proper order of stuff.

Speakers

I think we did pretty good job choosing speakers. I write “we” since I was a part of program committee. Anyway, even though we’re still far from perfection, speaker lineup was good and so was variety of subjects covered on the conference. One big topic we didn’t cover properly was quality assurance (Lisa Crispin, do you hear that? Mark the next year’s event date in the calendar), but other than than you could learn about engineering practices, processes, implementations, system change, improvements, people, fruits, chemistry, you name it.

Many speakers did a really good job delivering their presentations. I know I repeat myself but Jurgen rocks. He even forgot to promote his book heavily this time. Corey Haines was very good as well. Btw: if you don’t know his story you have to learn it – it’s great. Personally, I also enjoyed Andrea Provaglio’s, Marcin Floryan’s and Pawel Lipinski’s sessions, but basing on twitter stream everyone could find something which they liked.

Networking

Networking is something I attend conferences for. And it worked, as always. Somehow, with proper attitude it always works. By the way: it’s kind of magic how easy it is to approach stars at such events. If you haven’t tried you can only blame yourself.

Open space

Mike Sutton did astonishing job facilitating open space, and he’s generally a great guy, or I should say dude. However I think open space is definitely something to improve next year. It was filled with interesting sessions but then, for many of them half an hour was totally insufficient, like for the one on estimating. Feeling pressure from guys who want to run their own open space session in the very same place isn’t something which fosters discussion whatsoever.

New format

ACE Conference this year used different format. It was one track and every session, with the exception of a couple of keynotes, was limited to half an hour. Initially I was skeptical about that, but it worked just fantastic. And I say that considering both perspectives: as an attendee and as a presenter.

The format makes presentations content-heavy. If speaker has like 25 minutes to deliver their message they just don’t beat about the bush. Also you are exposed to wider variety of different topics as it’s possible to pack more sessions into the schedule. This is great for the audience. As a presenter you start appreciating shorter presentations when it comes to rehearsing. You can actually do twice as many rehearsals as in standard-sized, 60-minute long session. Also you tend to pick best pieces of content if you come to a point where you must choose what’s in and what’s out.

Organization

If Jurgen rocks as a speaker, so does Paul Klipp as organizer and host. As a speaker I can’t think of an event where I was served better. As an attendee I could hardly complain about anything important. Well, coffee breaks were a bit worse than last year, which is surprising as the venue hasn’t changed. There was some queue for registration too. Oh well, the event couldn’t be perfect, could it? Otherwise, how would it be improved next year? Anyway kudos to Paul for making it happen.

My session

I received very positive feedback after the session about Kanban improvements. Experiment with real Kanban board kind of worked. Structure was also decent as at the end I answered to questions tweeted during the sessions, even though I hadn’t read them. I miss some critical feedback as I believe there’s always a place to improve, so if you have some please share it in comments or drop me an email.

Also I kindly ask you to rate Kanban improvements presentation on SpeakerRate.

If you want to see slide deck here it is.

Final thoughts

I actually started the post with final thoughts so you don’t expect anything here, right? Well, as I think about events I attended last year it was probably ACE Conference 2010, which I liked most. But then the bar definitely went up this year.

The thing I love about ACE Conference is it isn’t crowded. There were 200-something people this year and I really hope there won’t be more next year. It’s selfish, I know, but I believe it is optimal size to see great networking as everyone is very accessible and after a few hours you actually start recognizing faces of fellow attendees.

So the final recommendation regarding ACE Conference 2012 is: you better have a damn good reason if you aren’t going to be there as otherwise it would be completely dumb move.

I had a spell in a company where I was hired to sort things out in technical department (development, quality assurance and project management). I went there with a head full of ready-to-apply ideas how to solve issues I’d heard about. One of the most important things I’ve learned there is you can’t find the right cure unless you know the disease very well. And you can’t learn what the disease is unless you get dirty going into the middle of the mess.

Pretty similar lesson I got from our Kanban story. I think this message is often lost between discussing a few simple Kanban rules, Kanban board etc. The message is: start with mapping what you have; don’t try to change the process on a day one. Reason is simple: get dirty going into the middle of the mess and then you’ll learn what you should really change in the first place.

I know it’s tempting to start adjusting surrounding world to the vision you have in your head. Every now and then I feel that whenever I find myself in new environment. But I learned to resist. First, the vision we have in our heads on the day one will be changing over time and it will be changing really fast, especially at the beginning. Second, the opinion we have about surrounding reality is wrong, at least most of the time.

So yes, my advice is: don’t change anything. Don’t change anything unless you see everyday proofs that it has to be changed. Don’t change anything unless keeping things as they are is a real pain in the ass. Don’t change anything unless you’re pretty sure you aren’t seriously screwing things up because of your limited knowledge.

It doesn’t mean you have to wait long until you start improving things. Just be sure you’ve got your hands dirty before you do that.

In my case you can count this as a part of a story of parachute manager since that’s exactly what I do now. However it works the same every time you join new environment, no matter whether it is a new team, new project, new customer, new company, new method or new people.

I’m not a conference animal. I don’t earn for living as consultant/trainer/coach/industry guru so I don’t treat conferences as must-be-there kind of events. However if I had to point a single event I attended last year, which I’d love to attend this year it would be ACE Conference (former Agile Central Europe). This is surprising since it was the very first edition of the conference.

Disclaimer: I’m a part of program committee for ACE Conference 2011 so please formally consider me biased but after all you don’t join program committee for an event you don’t like, do you?

If you need a recommendation you may read my opinion written just after the event. But if you asked me today why I liked it most among last year’s events I attended I would probably give you different reasons. I really liked the fact the event wasn’t crowded as it reduces distance between presenters and the audience, especially on open spaces and coffee breaks. Another thing is professional organization which is usually commented only when it’s absent. When everything goes right it seems effortless – you learn to appreciate it after attending conferences where nothing goes as planned.

If you’re keen on software craftsmanship, best engineering practices aren’t just an empty cliché for you and you care about some great discussions ACE Conference is a place for you. Early bird registration is already open. And if you have doubts about the program, trust me, it will be promising. I wouldn’t sign up for the program committee if it wasn’t.

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.

Dear Office Politics,

You’re here to stay. I know. This isn’t 20-person company so you aren’t going anywhere, I’m perfectly aware of that. This means we are going to work hand to hand, you and me, together.

I can’t say I’m happy. Remember? We met before in the other company, but I decided to part our ways. After all it’s never you who’s going away. It’s always others. And then we’ve been seeing each other on occasions but you’ve never kicked in hard way. Yet it’s been enough to remember I didn’t really like you. So no, I’m not happy to see you again.

You happen to like some people and dislike other. Strangely enough I’m always in the latter group. Well, not so strangely maybe, after all you don’t value honest and straightforward attitude and this is how I tried to act over years. But, you know, I can adjust myself. That’s human nature after all – we can live in both equatorial and polar climate, we can work in healthy or very unhealthy environments. With you, Office Politics, it is no different. For me it’s the matter of motivation: I’m either motivated to accept that you’re at some place, and then stay, or not, and then go.

These are your rules: everyone around has to play by them or leave.

You know what is funny? You’re not like a part of furniture or something. It’s not like someone bought you and you can be thrown out if they don’t like you anymore. You never pop up uninvited by some people up there, being pretty high in pecking order. And yet is takes just a few dozen people in organization and you always make your way there somehow. Once you’re a part of the organization you just can’t be thrown out. You are there for good.

It looks like we have to rebuild our relationship. It would be like love-hate relationship. Sort of. Well, without “love” part. But then I don’t have to love you. It’s enough if I tolerate you. All it takes to master your rules is playing by them long enough and that’s exactly what’s going to happen. No one is forced to love this game.

After all you, dear Office Politics, are just this: a game. A very demanding and not very pleasant game, which is won on long distances.

By the way: I always performed crappy in sprints. But that doesn’t really matter here, right?

If you follow discussions in project management community you should be familiar with term kaizen, which is usually used to name small evolutionary changes. Fewer people are familiar with term kaikaku, which represents radical changes.

This is pretty characteristic, as I believe we generally prefer small changes over big ones. We keep talking about continuous improvement (isn’t it prescribed by pretty much any agile method?) and there is no similarly popular term to label big changes.

And then you see opinions that organizations aren’t ready for radical change. Well, it isn’t without reason that the word “reorganization” usually stands next to the word “dreaded.”

Of course companies, and when I say companies I think management, are partially responsible for the situation. Frequent reorganizations with no sensible reason seen by people aren’t something very uncommon in big firms. But then I’ve seen a number of big changes which have made a lot of sense but have got very little support from people all around.

This is another part of the same story – people hate big changes. It moves them outside their comfort zones. The funny thing is you can hear a lot of complaining from people who should support the change as you’re doing something to improve their situation. “Nothing will change, anyway. It never changes. And by the way, we’re so unhappy, make something about that.”

No surprise kaikaku doesn’t get much positive buzz. People just don’t like it.

What’s the conclusion? While of course you should get as much buy-in from people affected by the change as possible you should also consider making the change smaller. Don’t try to do everything on the day 1. It makes sense to wait with some decisions even if you’re totally convinced they’re good. After all it’s not about you and your beliefs. It is about people who will be affected by the change. If you go way too fast no one will follow you.

Don’t make change even more radical as the only thing you will get this way is more resistance. Up to the point where no change can be done at all.

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.