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.

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.

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.

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.

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.

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.

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.

I often say that you can implement Kanban in your team in a single afternoon. That’s how we did that after all. So when Andy Brandt asked me to do Kanban Basics webinar I expected that preparing it would be pretty simple. How long can you talk about few-hour-long task?

Well, it wasn’t as simple as I expected.

Kanban itself is very simple. But telling people they should visualize workflow, limit work in progress and measure the flow isn’t really all the basic stuff they need to know. After a while it always ends up with questions how we do this and how we do that.

What limits should be set on board?
What happens when a bug is found during testing?
Should sticky notes be moved back on the board at all?
How cycle time is measured?
What happens when the limit is reached?
What to do when emergency task pops up?
How to cope with multiple projects?
Is feature-by-feature deployment mandatory?
How estimation is done?

That’s an interesting observation – I often deal with most of these questions at the end of my Kanban presentations, no matter if I cover basic or advanced material. After giving it some thought I decided this would be a good starting point to prepare Kanban Basics presentation.

What I ended up is presentation below. It covers a bunch of scenarios visualized with (surprise, surprise) Kanban board. Additionally I used Scrum as the reference to make a basic Kanban description easier to understand.

If you have some basic questions which seem to be omitted in the presentation, please leave a comment. I’d be happy to both answer the questions and update future versions of the presentation.

If you speak Polish feel free to watch the recording of the webinar.

Also, check The Kanban Story series as it reveals all the details of Kanban implementation in my current team.

OK, I admit it. This is a biased post. But you should have known. I’m sharing our journey with Kanban for more than a year already and the journey itself is even longer. And I’m still not fed up with all that Kanban thing. But then, after days like today, I realize why I appreciate Kanban that much.

Majority of you was in this situation before – you saw your team working on tasks as planned when someone came with that super-important, top-priority pre-sales project which totally required that your team added widget foo to some application. And it had to be done exactly then.

What I used to do in those situations was anything between panicky search for least loaded engineer and panicky explanations why we couldn’t do that before requested deadline. Either way the word “panicky” was involved. In every situation the threat was the same: we had a lot of pre-planned work to do and needed no additional distracter so what we really hoped for was to get the salesman hell out with his damn pre-sales project.

And now? Now I just put the task on the top of the stack. Well, I do if it is important enough of course. Then the magic happens. In vast majority of cases you get someone to start working on your damn widget tomorrow. Day after tomorrow if you’re less lucky. Glad I could help you that fast. Note: I didn’t tell you “at the beginning of the next sprint.” But now, the best part.

It doesn’t ruin the way we work. We aren’t distracted by your drop in. It is the process we follow which allows us to deal with the issue so quickly.

As I think about that, we hate all those unplanned tasks not because they’re unplanned (we know they’re going to happen after all) but because they force us to change our initial plans. If we had a framework which helps us to embrace those tasks in a way which is acceptable for our dear stakeholders (what a nice way to call salespeople, isn’t it?) wouldn’t that be worth trying?

So what are you waiting for? Go try damn Kanban!

Going to the meeting to tell business folks that you’re going to do your best adding all those crazy things they think they need to get the deal (and not lying on the same time) and then getting back to the team knowing that you aren’t going to change all their plans is priceless.

And that’s the beauty of Kanban.