I failed. It wasn’t very spectacular. Well, if I asked people around they wouldn’t even say it was a failure, but for me it was below-average performance. Thus failure.

Did I feel bad? I did. I couldn’t help. I knew I shouldn’t but after all I’m just a human. But then I consider it as much better thing which happened to me than just another success. Why?

Because we don’t learn from successes. We learn from failures.

When we achieve success it’s like someone was telling us “you’re great, no need to change.” And there is a need to improve. Always. The thing is we usually don’t see it unless we fail.

The trick is to embrace failure. Welcome it warmly. It is your ticket to another learning session. Yes, you will fill badly for a while, but in the long run it is more valuable than success.

Failure is an eye-opener. Suddenly you see what you were doing wrong and you don’t understand how blind you’d been not to spot it earlier.

Failure is a kick in the butt. You feel bad so you know you have to do something to avoid this unpleasant feeling next time. Unless you’re a masochist and you like to feel bad.

Failure is a helping hand. You get some guidance what you should improve or what you should avoid.

We are told we should embrace change. I see no reason why we shouldn’t embrace failure.

It seems recently I’m telling you a lot stuff about people management and managers in general. If describing the role of manager wasn’t enough you could also read a rant about screwed promotions which we see so often. This all stuff is good (yes, such a shameless self-promotion), but it assumes one optimistic thing: you can still make decisions who will be promoted to management.

However sometimes we don’t choose who is promoted to managerial positions. These decisions have already been made and they’ve been made wrong. If your task is to deal with that you’ll need to follow a three-step scenario.

1. Coach

OK, great engineer doesn’t make a candidate for a great manager. But it doesn’t make you can’t make a good manager out of great engineer. The trick is to raise awareness that someone doesn’t perform well as a manager and coach them to improve their people skills. Help them to change their focus from engineering to people management. However this effort can’t be unlimited. If someone isn’t willing to change you won’t force them. Then it’s time to move to the point number 2.

2. Find a better place

If someone excelled as an engineer and you can’t make a good manager out of them you might try to move them back to some engineering-related role. Maybe design, maybe architecture, maybe even project management would be a good place. It all depends on an individual case. Of course it is tricky – what you basically do is you move someone back from management to engineering, so you better have pretty prestigious engineering roles. And do it if, and only if, you believe the person would perform well in a new role. If you can’t find such role or leaving management isn’t really an option all you’re left with is a solution number 3.

3. Let them go

If you can deal with an issue other way you should let wrong people go. And yes, this means you’re losing a great engineer, who unfortunately became poor manager and is unwilling to switch back to the role which he performed well at. What you’re left with at that point is either to keep someone who do crappy job, which also affects their team, or to let them go and find possibly a better candidate. Well, if we discuss someone who failed at points 1 and 2 of the plan I’d let him go. As harsh as it sounds it is a good decision for both of you and for the discussed team.

Keeping poor managers is much worse than admitting you’ve made wrong decision promoting them in the first place.

And if you want to see more stuff about being a good manager you will appreciate my recent presentation titled Good Manager, True Leader, which I delivered at our internal company conference.

In one of recent postings I asked you how big your backlog is. My argument was that trying to enforce small backlog size is counterproductive. Although small backlog is easier to manage throwing things away from it just to keep it small isn’t the best idea.

However that doesn’t mean you shouldn’t do some backlog maintenance from time to time. What more, applying a few simple rules can help you to manage backlog easily despite its pretty big size.

Keep epics, split late

Sometimes we add to our product a big story. An epic. It is actually pretty interesting example in terms of sizing backlog. Why? Well, no matter if you split the epic into a list of smaller stories, i.e. sized similarly to your typical features, or keep it big you add a huge piece of work. A piece, which usually makes sense as long as it is completed as a whole. So yes, you need quite a capacity to add the feature, no matter which approach you choose. What do you do if your backlog is limited?

Anyway, my advice is to keep epics in backlog as long as possible and split them in the last responsible moment. It is aligned with agile late design approach but that’s not why I advise you so. Actually as long as you don’t start working on the epic there’s no reason to keep a dozen of sticky notes on the board instead of a single one. It’s enough for you to look at epic to know roughly what is to be done. You will need more details when you start development of first epic-related feature so no need to worry at the moment.

It is easier to reprioritize the epic over and over again if it’s in one piece. And reprioritizing is the most common task when it comes to managing backlog.

Groom from time to time

If you have spacious backlog you will face this situation on occasions: you will find out that one or more features waiting in the backlog are no longer relevant. Maybe you’ve changed the goal of your app or you abandoned industry which was addressed with the feature or you just don’t have a faintest idea why you wanted to build the damn thing in the first place. Either way it’s time to forget about it.

Grooming backlog is a great occasion to do that. What exactly grooming is? A simple process of reviewing all features in backlog to verify their relevancy. Yes, if your backlog is big it takes time. But after all this is the way to make it at least a bit smaller, thus more manageable. And you don’t do it every week as you don’t change general plans for your product that often.

Group features

There’s an observation which can be helpful as well. Unless we work on maintenance project where priorities are usually set by the client we tend to build groups of similar features and not randomly choose one from here and another from there. Grouping features which are similar or features which touch the same parts of code can be helpful in terms of prioritizing work. Once done you can just throw in another feature from the group instead of scanning through the whole backlog to look for a relevant task to put in todo queue. That is as long as your general priorities don’t change.

Grouping features also helps in prioritizing whole backlog. Instead of considering each and every feature separately you decide on a group which means you use the same time to judge a dozen of tasks you’d use to judge a single task otherwise.

Dealing with big backlog isn’t that hard after all. All you need is some order and a few rules which help you to organize a long list of tasks somehow.

Recently I told you about TEDxKrakow and how great idea it is to get engaged in a project like that if you want to get some experience in project management.

No one commented that voluntary projects can’t be exactly the same as typical commercial projects even though I pretty much expected to hear this kind of argument. I did because it would be well-grounded. Voluntary projects are specific because, well, they are voluntary.

OK, so where are differences?

• No managers. No one is a boss. No one can just tell others they have to do something. There is no easy path. You have to earn your power before you can use it. People won’t start listening to you just because you are able to talk loudly. You have to show that you are doing at least as much by yourself and/or earn their trust before you start shouting your orders all over the place.

• More talking. Talking is easy, talking is cheap. Unfortunately talking doesn’t get things done. People tend to throw great ideas as long as someone else is supposed to make them real. Unfortunately it sometimes turns into much talking and little doing as there isn’t really a business client who would make quick decisions on what is must-have and what is nice-to-have. A pretty good playground for doers I’d say.

• More freedom. Unlike in typical projects you actually choose what you’re going to do. It’s like the open auction – I have this and that tasks unassigned, who’s going to take them over? Specialization works pretty similar though – we tend to choose things we are competent at and avoid those we suck at.

• It’s easier to shine. In voluntary projects no one wants to get all the credit. After all it isn’t a place where people are going to build their whole careers. Chances are good that your effort will be properly credited. Just choose your tasks wisely and then deliver what you promised to deliver. Since in voluntary projects over-promising is just as common as in all others it should be enough to make you stand out.

There is one more thing. It is real fun to be a part of this kind of project. But, after all, I’m not sure if it is a general rule or TEDxKrakow I used as example is fun to work on or fantastic people I met in this venture made it so. Or maybe all above are true.

And if you haven’t yet registered to this fine event do it while you still can.

The other day I was asked to discuss how we can improve the way one of our software development teams works. Well, actually it was rather something like “Pawel, help us to implement Kanban” but, as it soon appeared, it wasn’t that simple.

A typical discussion about implementing Kanban

Me: So where do we start?

Colleague: Um, I’m not really sure if Kanban is really for us. Convince me.

Me: I don’t want to. If something doesn’t suit your team I’ll be the last person to convince you to implement it.

Colleague: So where do we start?

Me: Maybe with problems you and the team have. I guess there are some otherwise we wouldn’t be talking now.

It isn’t about applying recipes

The discussion changed its course. We immediately switched from discussing Kanban to talking about issues and looking for a solution which would be suitable in each and every individual case. If one of problems is people don’t want to have yet another place to do task management, and they can’t abandon either of current systems, introducing Kanban board may not be as great idea as it initially appears.

If you start discussion with the conclusion already fixed in your head you will not only miss opportunities to improve but you also risk applying the wrong cure and making the situation worse.

It is OK if you just don’t know

A couple of times through the discussion I came up to the point where I had no idea what the right solution might be. And this is perfectly OK. It’s not about playing knowledgeable person. It’s about giving the good advice or not giving any advice at all.

What more, admitting that you don’t know the answer is just a starting point for digging deeper. Each of these moments triggered some changes in our analysis. If we can’t go further here, maybe we should try there. Let’s stop talking about techniques which may or may not work and make a fast-paced Q&A session about potential issues the team may face. Or maybe let’s do mental walkthrough of processes the team covers.

As it appeared each time we admitted that we don’t know helped us with coming up with a reasonable conclusions at the very end.

Adjust tools for people, not the other way around

When you know some method or approach and it works fine for you, you are always tempted to apply it in other environments too. The problem is other environment means other people. As a result your approach may not be so great anymore.

But who said you can’t change the approach? Are methods we use some kind of dogma? Actually choosing a subset of techniques or practices from any given methodology is usually better than not using them at all. And if you choose wisely even a couple of small changes may yield significant improvements. So yes, do adjust methods before applying them.

That doesn’t mean people shouldn’t change ever. Of course they should. But motivation to change should be intrinsic and not enforced from outside, i.e. because manager told so.

A funny thing is that with this approach you can end with similar conclusion to the one you started with. The difference is now you are more likely to succeed as, even though you aim at the same target, you will choose different way to get there.

And in case you were curious, yes, we eventually came back to Kanban.

Once your organization start talking about performance reviews you usually hear about some formal system with the same structure for everyone involved. That doesn’t really sound like a good idea, right? Why companies are using this approach then?

If you have like a couple hundred people on board C-level exec can’t really say anything reasonable about vast majority of people in the organization. However leaders have to make some decisions basing on employees value, like firing rotten apples or promoting best candidates for managers.

This is the point where management is tempted to build an appraisal system which makes it possible to compare people easily, so all these decision can be made basing on hard data. The system ends up as stiff and structured checklist which produces grades in the same categories for each employer.

And this is utterly wrong.

Actually I believe you can hardly do worse. This approach not only makes an illusion of producing comparable results but also harms relations between managers and their subordinates since performance reviews following this pattern just suck.

Do a simple exercise: take a description of a few requirements and send them out to a bunch of managers working in software development teams. Now ask them to judge each feature in a few categories in a scale from 1 to 5. Let them judge difficulty, work consumption, innovativeness and business value. Grab these numbers from managers and compare them.

You will see that someone hit average of 3,5 and another barely 2,5. You will see how differently people look as specific categories. You will see how vague one-word category definitions are. Basically, you will learn what subjectivity means.

Now, I have a message for you: people are hell lot more complex than software requirements.

If you used the same system for people what you would get is a set of top marks for a handful of organization’s gurus, handful of worst grades for a bunch of incompetent slackers and like 90% of random results for the rest of people.

In uniform appraisal system this is taken as reasonable data which decides on a number of things, starting with promotions and money and ending with general respect. These numbers make or break careers. And yes, I’ve just called this data random.

But that’s not the worst thing which is introduced by uniform appraisal system. Yes, it can be worse.

Formalized, homogenous appraisal system degrades performance review to simple mark trade instead of making it an occasion to exchange feedback.

You get what you measure. If you measure few criteria, and these criteria are uniformed among the organization, you create incentive to fight about better marks, so people would get more money, have better chances for promotion and would be able to boast in front of their colleagues how cool their marks were on the last review.

There is a side-effect too. This approach creates an incentive for managers to run crappy reviews. Instead of focusing on two-way communication, learning what motivates their people, they just go through a simple script: programming three, communicativeness two, quality four, team work two, creativity five, next please. Hey, this is what the system expects from us, doesn’t it?

Running performance reviews is pretty damn hard job. I always feel stressed when I’m going to talk about one’s performance, no matter how official or unofficial it is. Yes, it is easier to just go through a number of marks and call it a day, but that’s not the option which works for reviewed people. Unfortunately not everyone understands that, so we should build systems which create incentives for positive behaviors, not the negative ones.

So while I don’t agree that performance reviews are evil in general, we can hardly think about worse approach in this area than a formalized, homogenous appraisal system which unifies measures among all employees. That’s just not going to work.

These days wherever you move you hear a lot of buzz words. People manager, are you? There’s one for you. Oh, you are more into leading projects, I understand. Try with hyper-productivity. You will definitely hear it here and there. Well, maybe it is a way to go?

For the sake of this discussion let’s consider there are no well-grounded doubts about figures standing behind the idea. Let’s consider hyper-productivity was never called bullshit. Let’s consider you can make your team hyper-productive, whatever this might mean. But before we come to this I have a question.

Why, the hell, won’t you make your team just productive in the first place?

The problem I see over and over again isn’t with teams which are performing very well and struggle to improve even more. The problem is an average team can hardly be called productive. Just productive.

We keep wasting our time because we organize our work poorly. We face way more interruptions than it is necessary. We don’t really care about making our estimates a bit better to avoid panic (and counterproductive) rescue actions at the end of the project. We hire, and then keep, people who don’t give a damn about learning. We promote wrong people who are living proofs of Peter’s principle. We keep making stupid lists of examples just to prove the point which everyone agrees with from the very beginning (well, that might have been wrong example).

No, hyper-productivity isn’t an issue. If we were able to make average team just productive we’d see hyper-productivity paradise. If you want to optimize system performance you don’t make champions even better – you work to get average majority to another level.

So don’t tell me how to make my distributed team hyper-productive. Give me an advice how to make a bit more fun out of our mundane tasks or help me improve my recruitment skills instead.

Hyper-productivity shouldn’t really bother us, even if it isn’t just a buzz word.

On my AgileCE presentation on Kaban I said that if your Kanban board doesn’t evolve over time you should treat it as a warning sign. It possibly means you don’t improve workflow. And since there’s no by-the-book implementation of Kanban you should experiment all the time.

So what has changed on our board recently?

I can start with things which remain the same – this time we didn’t change structure of workflow. Columns are exactly the same. Limits stand still. But you shouldn’t consider at Kanban board being just a list of stations with appropriate limits attached. Kanban board is a single most important tool you use in Kanban. You look at the board a number of times daily. The more you see there the better is the board. This doesn’t mean we should make our boards completely cluttered. After all, if there’s too much in one place you stop seeing anything but clutter.

OK, you already know we added something to the board. A few things actually.

• Different sticky note colors. At the beginning we were working mainly on a single project. Recently we forked our efforts and now we work on 3 different applications. Getting separate color of sticky notes for each project was no-brainer.

• Blocker flag. Visual mark of blocked feature is a small red sticky note attached to the main card. This is another obvious trick. We added it when we faced the first issue being blocked by external source.

• Color magnets. We use whiteboard as our board. To make it visible who actually works on specific feature we put color magnets on sticky notes. Each team member has their own color. (Mine is white since I’m such an innocent guy.) Magnets give us quick information about load of each of us at any given moment. Besides, they keep cards from falling down.

• Dates. We write two dates down on sticky notes. First when we start working on feature and another when we’re finished with the task. We keep forgetting about these dates, since this is pretty fresh idea, but that’s not a problem to fill them after a couple of days when we still remember well when we started/finished work on MMF. This trick helps me to report retroactively cycle time. Earlier I had to dig for information in task management system.

• Numbers. Each sticky note has its own unique number. This makes it easy to link anything with MMF. A bug? We start with a number and everyone instantly knows which feature is defective. A task? We start with a number and we know which development tasks are related with MMF so we can tell how much work is remaining. We even use them in discussions: “Have you finished ninety seven yet?”

• Excel sheet as backup. One day I thought what would happen if our cleaning lady would, well, cleaned our board. Man, we would be doomed. So I made simple sheet where I add information about every sticky note, which makes its way to the board. It is also a place where I store information about cycle time etc so it serves as reporting tool too.

None of these improvements is significant. A few are pretty obvious. Yet when we were starting with Kanban we didn’t use any of these small tricks. They emerged as tiny improvements of the board and the process. And these small tricks do the job. Even though neither of them brings much value on its own they add up and make the board significantly better.

As additional reading learn how our Kanban board evolved. Check out the whole Kanban Story too.

My recent post on verifying competence triggered some reactions, one of them being specifically interesting. Bob Marshall pointed that my idea of competence test isn’t congruent with Deming’s teachings, namely 95/5 rule.

Deming says that 95% of performance is attributable to the system and only remaining 5% can be attributed to individuals. Does it render the question “Would you hire a discussed person to your own dream company to work in the same role?” irrelevant?

I don’t think so. The question isn’t really a very generic one and there are a few assumptions made already before you ask it.

• You have control over the system. Actually the question is about your own company, which means it isn’t some hypothetical organization or random system. We’re discussing the organization you’d like to have. The best possible one you can think of. Besides, you will have a chance to improve the system too.

• The system is the same for everyone. We don’t discuss best possible performance in the world (whatever that would mean) but performance of different individuals within the same system, namely your company. This means the only differentiators which come into play are individual traits and individual performance.

• We compare similar systems. Even though we have in mind our dream company we shouldn’t assume it would automatically be top-performing system. If we worked whole professional life in average systems what we are likely to achieve is slightly-above-average system. The change between two organizations (current workplace and our company) won’t be as dramatic. Theoretically it is of course possible, but not likely.

Besides, what we look for in the competence test isn’t aimed at finding the best performing work environment. It is aimed at finding the right people. Of course I silently assume you won’t hire wrong people to do wrong jobs. I would probably hire none of great developers I know if I started a restaurant.

If I’m not clear enough let’s go through an example. There is Mark the Coder who works for yet another average software shop. Mark the Coder stands out, at least at his current organization. Now let’s hire Mark in another average software shop. Would he still stand out? Pretty likely.

OK, so now hire Mark in low-performing company. His personal traits which made him shine in the original organization will play even more important role as the background is worse. Would he still stand out? Yes. Would he perform better than in original situation? Rather not. Actually relatively he should perform worse, but he would still be considered as great performer in his new environment.

What happens if we hire Mark in high performing organization then? He will likely perform better, as the system itself performs better, but it isn’t so obvious whether he will still be considered as one of top performers. Why? First, high-performing organization is a competitive background for personal traits and second, high-performing organizations tend to draw many top performers making it more difficult to stand out. Either way Mark the Coder should cope with the new situation, even if he loses the guru plaque.

I know that what we really consider asking the question “Would you hire that person in your own organization?” is the last scenario, which is also the one with least obvious outcome. However if someone has a chance to become a top performer in the new high-performing system it is likely the one who was already among top performers in the old organization, thus Mark the Coder serves as a good candidate here.

So no, I don’t find the ultimate competence test conflicting with Deming’s teaching. Do you?