I often hear this excuse: “I don’t have power to change this.” Hell, I use it by myself way too often. It is a convenient excuse. Since you aren’t in position to do something the easy way you take a step back and do nothing.

And this is wrong.

Let’s take a typical situation: your boss sucks. If I got 10 bucks every time I heard that someone’s boss sucks I would be crazy rich. But let’s face it, I have poor opinion about managers in general and I think most managers suck anyway so I’m going to agree willingly.

So what do you do when your manager sucks? Wait, let me guess… You do nothing. Hey, you don’t have the power, do you? You just can’t change the situation so it’s better just to accept it, right?

Wrong.

People are simple beasts. We all have our goals, private agendas, drivers and motivators. We also have tools which helps us to achieve these goals. Some of us have power. (And yes, I’m lucky enough I have power long enough to get used to it.) Some of us have skills. And some of us have instinct or cleverness.

It’s not always the guy with power who wins. Actually if that was so, most of companies would work perfectly well, since every reasonable rule would be enforced and widely accepted. But somehow we see organizations which are completely sick and filled with frustration even though their leaders have mouths full of wise advices.

It’s just they’re losing the battle with those who don’t have power but are more knowledgeable and smart.

The trick is, to some point, you can manage everyone around. It doesn’t matter if he is your subordinate, your colleague or your boss. You can. Yes, you can. Yes, you… If I know what is important for you, what drives you and how you act in different situations I can trick you or I can build incentives for you to act like I want. Even if I’m your subordinate.

A couple of examples. Megan had a boss who was pretty much frustrated with surrounding situation. Things were going bad. But he, as a manager, was supposed to play devils’ advocate. Megan, who knew the boss for quite a long time, felt that frustration hidden behind the mask of official optimism and decided to break it talking with the boss privately. She could do nothing, since she had no power to change boss’ attitude and then a new cool business wouldn’t emerge when they both left the company to start it.

John had a manager who loved bells and whistles. He knew most of project decisions were made basing on what the manager personally likes, not on reasonable business analysis. When recession came and every team looked for projects John brought a bunch of cool, but basically useless, ideas to the manager. John expected the manager would personally like a couple of them and he was right. The team got the budget for these projects. Business-wise projects were useless but John played his agenda and got what he wanted.

We all base on a lot of assumptions. Especially managers. We just can’t know every fact so we do what our gut feelings say. And finally we are biased. This means we make our decisions basing on a set of arguments which is far from being complete or even reasonable. That’s why it is not the power which is the most important since almost every power bearer can be blinded easily.

So don’t give me excuses you just can’t change anything since you have no power. At least try. Then try again. Unless you fail a couple of times I don’t believe you can’t do it.

I am a chatty guy. Catch me while I’m not overworked and I will gladly jump into discussion. If you happen to be my colleague, it may be a discussion about our company. That’s perfectly fine for me.

I believe in transparency so I won’t keep all information as they were top secret. This means I’m likely to tell you more than your manager. Not because I don’t know how to keep a secret but because vast majority of managers talk with their teams way too little.

With this approach I usually know a lot of gossips told in companies I work for. Since I also happen to fulfill rather senior roles I have another perspective too. I know what is discussed on top management meetings.

This is sort of schizophrenic experience for me because almost always I have two different pictures of the same thing. I see senior managers praising people who are disrespected by their teams. I see folks who get credited for the work they didn’t do. I see line workers being completely frustrated while their managers are saying these guys are highly motivated. I see managers completely surprised when people suddenly leave while almost everyone saw that coming for past half a year.

I see it and I don’t get it. All these managers do very little, if anything, to learn a bit about their people but they claim they know everything. I may be wrong but I believe I do much more to learn about my team, yet I still consider I know nothing.

If one of you guys is reading that, yes, I’m stressed that you might leave. I’m stressed when you get out of the room to pick the phone since definitely it is a headhunter who’s calling. I can’t sleep when you take a single day off since, and I know it for sure, you have an interview. OK, I might have exaggerated a bit. Anyway in terms of my knowledge about my team I know that I know nothing.

And you know what? If you are a manager you are no better. Because generally speaking we know nothing about our teams. Even if we are friends with our subordinates our professional relationship is much of unknown. With strangers we usually work with it is much, much harder.

Stop expecting you know oh so much about your people and at least try to talk with them. If you’re lucky you may find a couple of folks who actually are willing to talk with you. Remember though, if you ignore them once or twice they aren’t coming back to you.

It looks like I have a pretty poor opinion about quality of people management in general. Well, I must admit I do. I would be a hypocrite if I deny it regarding my recent posts on subject:

• Managers Are Clueless
• What Motivates People

Under my recent post about best engineering practices I was pointed that it is just another “do whatever works for you” or “I don’t know experiment” kind of advice. Well, it was that kind of advice indeed. Have I ever given you a different one?

Anyway I admit shot was on target. If someone is one of those battlescars who has seen much they probably would be more than happy to hear something like that. On the other hand if you happen to be a freshman you may expect to get something like a real advice. You know, the one which you can simply take and apply in your team without much thinking since “the wise guy said so.”

Coming back to best practices than. What can I tell you besides you should experiment with your practices to find what works for you? Well, if I had to choose one engineering practice which is definitely a sure shot I’d go for continuous integration. And yes, I’m not expecting a flame war under this post.

“Who the hell doesn’t have continuous build yet? We are in 21st century, haven’t you heard?” Yes, I used to treat continuous build as an obvious thing a decade ago and you know what? I was wrong. There are many teams and companies which don’t have continuous build implemented. Why? Because they think it is hard, because it takes time to setup the whole thing, because the project is oh so legacy, because no one cares, because no one approved order for build server, because, because, because… If you want to hit the dog you will find a stick. And many companies are still beating poor puppies hard. I could name huge systems sold to big institutions which never touched a build server.

I can tell it as an anecdote: pretty much every company I worked for set up continuous build once I was working for them. This basically mean the earlier you hired me the better. Not that every company I’ve worked for still exists but we aren’t discuss business here, are we?

If I think about setting up a team or project the very first task to do is getting and configuring a build server. It is a prerequisite to write a first program. And I’m not going to take a look at damn hello world application until build server is up and running. Don’t even say you dared to write any code without continuous build set up.

So this is my first answer about specific engineering practices we all should employ. Unfortunately once I started to give you specific answers I expect to hear “what’s next?” And from this point every answer can be only more difficult.

That doesn’t mean I won’t try though.

I was taught risk management the classic way. You know, risk log, voting for probability and impact, finding out which risks are the most painful, deciding on mitigation plan, discussing results etc.

A cool thing in this old-school process is that it activates different members of the team. Even those, who wouldn’t be asked otherwise. Even those, who would tell you that the project is doomed unless you decide to do something about that performance issue found last month.

At the same time in small teams this kind of process looks like complete overkill. In small teams which deal with small chunks of work knowledge about risks (about everything actually) is often commonly shared. The problem isn’t about bringing individual opinions to the table. The problem is to make risk management as simple as possible yet still effective.

An easy and powerful approach here is to forget that there is something like risk management at all. At least to the point where you don’t consider having dedicated formal process to do risk management. Instead you incorporate risk management to everyday tasks: stand-ups, retrospectives, demos, planning meetings etc. You discuss potential risks every time you discuss a task or story. You discuss potential risks whenever you feel about it.

You won’t even need a risk log. If you talk about risks at every occasion you quickly learn how to catch those which may become painful (filtering by type) and those which are likely to hit you (filtering by frequency of mentioning).

When you keep talking about risks all the time people learn to deal with them naturally as they work on their tasks. Potential performance problem Luke mentioned yesterday? I’ll run some stress tests as I just have a while and maybe Mike would take a look at database as he’s already tweaking it to build that new feature. The trick is we don’t call it a risk. It is just a performance issue. Possible performance issue actually. Luke just thought it might become a problem but in a couple of days the problem will be gone, this way or another. And you don’t need to use the word risk, have a risk log, perform risk assessment, build and implement mitigation plans etc.

The only thing you need to have this kind risk management in place is a bit of trust and open atmosphere. Oh, co-location and no-meeting culture may help as well but in small teams both are usually in place already.

Kanban, as any other methodology, isn’t a silver bullet. There are situations and teams when it shows its full potential but there are others where its impact will be limited. Where Kanban suits best then?

Micro-sized teams

It is said Scrum works best with teams of 7 or close to this size. Sometimes we deal with smaller groups. 3 people working on a project isn’t something very uncommon. For such micro-sized teams Scrum is often too formalized. You can limit a number of rules you follow and still keep good quality. And you have a bit more time to do the real work.

Frequent priority changes

“Walking on water and developing software from specifications are easy if both are frozen.” Unfortunately we deal with a lot of changes as we build software. There are new features; importance of tasks changes, new top priority bugs requires instant attention. Our response is moving to more flexible approaches. We try to avoid BDUF projects. We switch to agile methods employing short iterations. We even make iterations shorter and shorter. It allows us to change priorities frequently. Once every couple of weeks if we take typical Scrum implementation.

The problem is when priorities happen to change even more frequently. Once every few days. Or even every single day. And yes, there are such projects. Kanban is a great answer for them. Feel free to change priorities every day. As long as it is well-grounded it shouldn’t ruin your project.

Maintenance projects

A typical maintenance project routine looks like this:

1. Whenever high-priority bug is submitted fix it as soon as possible
2. Low-priority bugs becomes high-priority ones when resolution deadline approaches; then see above
3. Whenever a client orders change request (CR) and there’s no high-priority bugs – try to do it as soon as possible
4. If there are more than single concurrent CR ask project manager about priorities
5. If there are no bugs or CRs do some refactoring or other improvement job

Sounds like ideal Kanban playground, doesn’t it? That’s typical case of event-driven development (not event-driven programming) where you don’t actually have a roadmap or something but you do whatever new day brings. After all you don’t expect to have a bug submitted tomorrow, or do you?

Multiple small projects

Working on several rather small projects or sub-projects with the same team at the same time is pretty difficult. Resources (what a nice name for your people) are usually insufficient since it is harder to synchronize stream of small orders to keep it at the same level all the time and bringing more people just-in-case isn’t the best business strategy around. This ends up with (surprise, surprise) a lot of priority changes and trade-off games. “We can complete this additional project on time but we’d fail to meet a deadline here or there.”

With standard structured project management approaches coordinating different threads with ever-changing priorities becomes pretty much a hell. What Kanban does is it organizes workflow so the main, well almost the only, thing you should care about is setting priorities at the beginning of workflow.

Common part

The common part for all of environments above is they don’t require many constraints to work. Few simple rules which come with Kanban should be enough to get things done. Another common thing is mid- and long-term planning is hard or even close to impossible, which is another problem hardly resolvable with more structured approaches. These two things are the most specific for environments where Kanban shows its full potential.

This isn’t really a post which is a part of the Kanban Story but if you found it interesting you should like the story as well.

Today I attended a training session where we were learning about motivation. I’ve heard pretty poor opinions about the session before, but I wouldn’t be me if I didn’t check by myself. And if you need to know these opinions were crap – training was pretty good.

Anyway, we had a very small and very open group which was cool. I think I should thank here those who didn’t show up, since the session was planned for a bigger audience. The best thing about the group was each of us works in different team and we are on different levels in organizational structure. This means our perception of the organization itself and tools we have to motivate ourselves and our people differ vastly.

This is kind of cool because otherwise we would barely have a chance to confront our points of view. And it appeared every single one of us pointed different things as our main motivators. This is basically the lesson I want to share with you. If you want to know what motivates people working for you, move your fat ass from your damn throne and learn what drives every individual in your team, instead of asking for universal recipes.

Yes, you will hear all sorts of answers from “more money” up to “my cellar is cool actually; just don’t interrupt me when I’m in THE flow.” On a side note, money isn’t a tool you can use to motivate people.

Motivation is a very individual thing. I remember sharing a really fat bonus with one of my former PMs after she completed one those hard core projects. Since we were getting on well I asked if that motivated her for further effort. The answer was “no, not at all.” I can’t say I was surprised much, since I’d moved my fat ass from my throne to learn what had driven my team. If you asked me why the fat bonus then, well, she’d still earned that money.

Don’t expect simple answer for a question about motivating people. The subject is just too complex. And if you still believe there is a simple and universal solution for the problem you may want to reconsider predisposition to be a manager.

In case you were curious my biggest motivators are learning opportunities and having things under control.

You may also like other posts on motivation:

• Why Money Doesn’t Motivate
• Money and Motivation

If you’re into Kanban you probably have heard the term swarming. Actually chances are good you’ve heard the term despite your lack of interest in Kanban.

What is swarming?

In short swarming is all about getting more people to do the task than you’d get otherwise, in normal situation. An example: you have a bug which normally would be fixed by a single developer, but for some reason you have the whole team working on it. And you already have another question…

Why, oh why?

Why would you want people to swarm around a small task? Typically teams do this when they face either a blocker, which hampers whole team, or a very difficult problem, which is hardly solvable by a single person. Either way you get more people to move things further, which would be impossible or at least very difficult otherwise.

Swarming in Kanban, part 1

Up to this point swarming is something teams do intuitively at times. The reason why the term is mentioned so often in the context of Kanban is one of Kanban rules: limiting work in progress. Because in Kanban we want to have as few ongoing tasks as possible, yet as much as it still does make sense, we have limits for different stages of our process. And it when we hit the limit we treat it as a problem which we want to solve and we want to solve it fast. That’s why we swarm.

Swarming in Kanban, part 2

There is another thing which you may read about, which I call everyday swarming. Everyday swarming is done by teams which swarm by default, when no emergency situation happens. The reason standing behind this behavior is trying to make cycle time and/or lead time as short as possible thus flow of tasks very rapid and smooth. Oh, and you have fewer ongoing tasks then too, which means you have less work in progress, which means you have less waste, which means you are oh so lean.

Our story

I must admit I don’t really like the idea of everyday swarming. I mean cycle time is definitely shorter but I’m so sure about throughput. Flow is smoother but you kick in a lot of micro-switches when a few people need to integrate their work into one piece of code since they all have worked on a single feature. You also may invite some issues with version control this way since you’ll be working on the same chunks of code. For me the net weight of swarming by default is negative.

Basically that’s why we avoid swarming whenever possible. When there is some serious problem to solve and standard approach is not enough we naturally help each other. One person after another joins the rescue team and this basically ends as swarming. But other than that we prefer to have only one person working on the task at the same time. Well, of course there are exceptions like discussing design or testing and bug-seeking/bug-fixing but these all are pretty natural things for any software development team. After all it would be pretty schizophrenic to discuss the design with oneself.

It looks like we swarm as David Anderson initially proposed, despite ignoring David’s teachings when it comes to lead time. I think this is the most natural way of swarming. But of course you remember the rule to experiment like crazy, so you may want to try something different in your team.

Read the rest of Kanban Story as well.

The other day I was asked to write an article for our company’s intranet portal. The first thing which came to my mind was “no one would read it.” Well, probably few people would but not many more.

You might say I have a sad view of humanity, and you’d probably be right, but I kind of lost enthusiasm to systemic attempts to spread knowledge within organizations. And I mean here all things like intranet news sites, internal corporate blogs, knowledge bases, company magazines etc.

In theory, as long as you have at least a few dozens of people on board, these things are great. They have no weak points. There are a couple of leaders who organize site/blog/magazine/you name it, then there is a group of producers who work on content and then there is a vast majority who consumes all the stuff.

That’s the theory. In practice first two groups (leaders and producers) are rarely a problem. The problem is people don’t give a shit about your news site, blog, knowledge base and magazine. They couldn’t care less whether they might learn something from there. People just don’t want to learn.

Scott Berkun recently shared his thought why the world is a mess in general (read not only the post, but comments too). His conclusions are that people don’t listen and don’t read either. This actually supports the theory I offer above – even if you take the effort to create a gem or two and drop it into your intranet portal no one would read, no one would notice.

Actually not willing to learn, listen and read are just symptoms. And yes, there’s a single disease behind them all. People are lazy. They don’t learn because it’s easier to leave things as they are. They don’t read because skimming takes less effort. They don’t listen because trying to genuinely understand what other are saying is hard, much harder than just waiting for your turn to speak.

Note, I don’t say I’m not lazy. If I have problems with motivating myself while working at home that’s exactly because I am. If I tend to procrastinate most of housekeeping tasks, like fixing the lamp or securing a shelf to a wall, the reason is the same. Scott may be no different by the way.

Now, before you tell me that I’m over-generalizing, I know that. The same as you know that most people fit the picture above. When I look at statistics for recent articles on the intranet site I see that less than 10% of people in the organization read them. So when asked whether I would write an article on Kanban to be published there I wanted to answer with something like “I write about goddamn Kanban at least one every two weeks on my goddamn blog which you may find typing my goddamn name into goddamn Google. I did two goddamn presentations recently and sent goddamn links to two thirds of folks within the goddamn company. Shouldn’t that be enough for pretty much anyone here to find a goddamn article on goddamn Kanban?”

But now when you ask, I will write the (goddamn) article. It is worth helping people even if just 10% of them care. And it might make me look less lazy too. You know, I just aspire to be in to 10% of population.

Last week we had an internal audit in our team. If you automatically think “ISO 9001” when you hear “internal audit” let me just state it had nothing to do with ISO. We have a few so called quality requirements in the company and every team should follow them but these aren’t anything like ISO procedures.

The reason why I was interested how the audit would go is we work pretty differently than the rest of the organization so quality requirements aren’t really adjusted to our specifics. I was also curious how our non-standard process would look like in comparison to other teams.

I caught a few things which are worth sharing.

Small Features versus Big Features

Our currency for functionality is MMF (Minimal Marketable Feature). MMF itself probably doesn’t tell you much and I know different teams use different sizes for MMFs. In our case average MMF can be coded by a single developer in about a week, so they are pretty small.

On the other hand in other projects typical currency for functionality is requirement which is significantly bigger and, as such, less detailed. I’d say that on average it is few times bigger than MMF.

Where’s the difference? I mean, besides the size itself. One very visible difference is we do significantly less paperwork. With features small enough that they can be easily analyzed and decomposed by product owner, developer and tester we don’t need to write low-level design documents or test cases or user stories. We can spend more time doing the real work instead of creating a pile of documents which tend to become outdated as soon as you hit the save button.

Frequent Deployment versus Not-So-Frequent Deployment

I guess there aren’t many teams which still treat deployment as one-time effort done at the end of project. But still, frequent deployment is a painful thing, especially when developers work in different team than QA engineers and QA engineers work in different team than release managers. An average project isn’t deployed biweekly. Not even close.

On the contrary we deploy, on average, once every 9 days and I mean calendar days here. Of course it didn’t look like that from the very beginning and it cost us a bit to get there. I would say it took us about half a year to gain this pace.

Where’s the difference? I could tell you about time-to-market, but it really depends on project whether you need time-to-market counted in days or months. The cool thing is somewhere else. With such a short cycle time we don’t have a temptation to incur technical debt. We don’t leave unfixed bugs. We just don’t. After all we might have been discussing about a single low priority bug, not a few dozens of them so the fixing cost would be so low that we don’t even start the discussion in the first place. Even if we hit a dead-end redoing the whole darn feature doesn’t take us a couple of months – it’s just a few days so it’s much easier to accept it.

Everyone on the Same Page versus Formalized Process

We’re small team and we’re co-located so we have fairly few communication issues. The process we follow is very simple and, what is even more important, crafted by our team. We all are at the same page.

Most of the teams in the company follow more formalized process. There are different functional teams which are meant to cooperate, there are specific documents expected from each other by people working on projects etc. On the top of that there’s some office politics too and formalized process is used as a weapon.

Where’s the difference? This one was pretty much a surprise for me, but it looks like our process appears as mature and effective even though it isn’t even recorded in any form. We just know what everyone should do. Whenever some obstacle appears on the way people naturally try to help each other as they see and understand what’s happening. And yes, I’m over the top just because no one forced me to write the process description down. On the other hand formalized process is often artificial for other teams who have to follow it and they sometimes focus on being compliant to the process (or fighting with it) instead of building software.

What Does It Mean For You?

I’m not trying to say here you should now automatically cut every feature you work on in half (at least), deploy three times more frequently than you do now and throw every procedure out. It would probably end with chaos, which your managers might have not appreciated.

I’m not trying to say it was easy to get where we are now. It took great people, some experience, a lot of experimenting and enough time to get better at what we started doing. A year ago I would have hard time trying to point how our approach might be better than what you could find in the rest of the company.

And I’m not trying to say you should read these advices in “this over that” manner known from Agile Manifesto. It’s not only our team which is pretty different than average team in the company but a product is also far from standard projects we build in organization so I compare pretty different environments. I wouldn’t even say that every single team in the company would benefit from implementing our approach, although a few of them definitely would.

These are just things I learned while talking with Ola who audited our team (and many other teams in the company). For me these lessons weren’t obvious. I mean connection between frequent deployment and short time-to-market is pretty clear for anyone who understands what “deployment” and “time-to-market” means, but I’ve never really considered that very short production cycle may help to avoid technical debt too.

And if you’re interested what the audit result was, I’d say it was pretty good. I mean, everyone likes to listen to some compliments from time to time, so we may want to ask for another audit soon.