The other day I had a discussion about leadership and management. When we came to an argument that there’s no chance to advance to a position where you can facilitate leadership and management skills in discussed organization several people (from present and from past) automatically came to my mind. They all have the same problem which they may overlook.

They all are (or were) great engineers. People you’d love to have on your team. But at some point of their careers they started to think about having their own teams, managing their own people. Hey, that’s natural career path for great engineers, isn’t it?

Well, actually it is not.

Do a simple exercise. Think who you consider as a great engineer, no matter if he’s a star book author or your colleague no one outside your company knows about. Now what do they do to pay the rent? I guess they are (surprise, surprise) engineers, tech leads, freelancers, independent consultants or entrepreneurs. I guess there are none who would be called a manager in the first place, even when they happen to do some managerial work from time to time.

Why? Because these two paths are mutually exclusive. You can’t keep your technical expertise on respected level in the meantime, between performance review of your team member and 3-hour status meeting with your manager. You either keep your hands busy with writing code or you get disconnected with other developers out there.

On the other hand what makes you a great engineer usually makes you a poor manager at the same time. If you spend all day long coding, you don’t have enough time for people in your team. And they do need your attention. They do much more often than you’d think. If you’re going to be a decent manager big part of your time will be reserved on managerial tasks. There won’t be enough time left to keep on technical track. Sorry.

That’s why all these people who I thought of have to (or had to) make a decision which way they are (were) going to choose. Technical leadership path means most of the time you won’t have people to manage but you may be respected as an architect, designer, senior engineer. If you’re lucky enough you can even get one of these fancy business cards with title of Chief Scientist or Chief Guru or maybe just a simple Co-Owner.

Managerial path on the other hand will make you feel lame during basically every technical discussion out there but yes, you will have people to manage. If you’re lucky, and I mean lucky, not competent, you’ll become VP or something.

You have to choose. Or you had to some time ago. What’s your choice? What do you regret about it?

A lot of discussion on estimation recently. A lot of great arguments but a lot of good old mistakes we’ve already went through. This brought me to a few random thoughts on estimating techniques.

1. Estimation technique which involves discussion between different people is better than one which just simply uses their estimates as input.

2. Using factual recorded historical data is better than basing just on experience.
3. Smaller tasks can be estimated way better than big chunks of work.
4. Every estimate starts with some kind of guess at the very beginning.

I know these should be obvious yet I’m surprised how often people:
– forget about them
– deny these are true

Then they head towards wild guesses with some magic number applied, which may have some sense but not when used instead of real estimation.

Agile is such a capacious term. Under the flag of agile we do different things. Scrum is agile. And XP is agile. Scrum-in-the-name-only is also agile. We go with no plan whatsoever and that’s so damn agile is agile too.

Yes, you say the first two are true agile and others are fakes just tainting The Holy Agile Name. That reminds me… wasn’t it exactly the same with waterfall and others bad, bad techniques? Wasn’t they tainted by poor implementations which got everything wrong so we had to come with new better methods? Well, just a food for thought.

Coming back to agile. With all these good and bad implementations I can safely say that there’s no single flavor of agile. There never was. I believe it was never intended to be the only one. I recently read notes on the writing of the agile manifesto by Alistair Cockburn and one thing stuck with me:

“I came in through the doorway marked “Efficiency” not the doorway marked “Change” – because my background was in fixed-price fixed-scope projects. (…) Other people came to agile through the doorway marked “Change”, and that’s fine for them.

So although agile gets billed most of time through Kent Beck’s “Embrace Change” moniker, I’m not happy encouraging people to just change stuff all the time – it’s more efficient to think for a while and try to make good decisions early – the world will supply enough change requests without us adding to the list by not thinking.”

Different experiences, different projects, different backgrounds. Different accents when talking about the Manifesto. I can’t say I haven’t expected that at all but still. There was never one universal interpretation of agile principles yet we see every now and then people selling the only right and proper method of being agile. How come?

On a side note: I wrote this piece a few days ago. In the meantime The Big Ugly Change came and kicked my ass big time. “The world will supply enough change requests.” Couldn’t agree more these days.

A boss came to a worker:
– Would you come to work on weekend to rescue project?
– And what would be the reward? – asked poor little worker.
And there was no answer.

Actually the unspoken answer was “I don’t really know” or “I don’t want to say” or “Don’t mess with me, kid.” Either way it was wrong.

The worker’s question isn’t a very nice one – personally I prefer working with people who don’t ask for reward before job is done. On the other hand it isn’t unexpected either. As far as you’ve done some extra job and haven’t been rewarded in any way or your so called reward could be interpreted only as an insult you learn to ask before, not after. Every manager should be prepared to hear the question.

Being prepared here means having an answer and having the one which actually says something specific. Let it be “You’ll get this and that amount of bonus money” or “You’ll have higher engagement rating during next performance review” or “I can do completely nothing for you because I’m a crappy manager but I still ask you to come.” It’s still better than nothing.

A reason why these are better than those above is simple. They are transparent. You show how things look like. You don’t hide your magic algorithm which is a number of overtime hours multiplied by standard rate multiplied by secret factor of 1,25. This by the way becomes perfectly clear for everyone once they do the basic math. Basically if you as a manager hide something it’s either wrong or it shouldn’t be a concern of a team. Actually the former most of the time. Even when you don’t hide you suck being a manager while you’re trying to be transparent it’s better than trying to play kick-ass boss. Everyone would know you suck anyway but you’d avoid a label of hypocrite at least.

If something is interesting for the team or a person in the team – say it. An algorithm you use to tell how much bonus money people are going to get? Say it. Rules you use to decide on a promotion? Well, say it. New facts about this huge project you’re trying to get? Guess what. Say it. Unexpected issues with company cash flow which will bring some inconveniences for the team? How about saying it? Be transparent. People will appreciate this even if they won’t say that out loud.

Being transparent cuts off gossips, increase team’s trust to their manager and helps to spread information among the team. It is good. Do the opposite and you won’t keep your alleged secrets and you won’t control information (and gossip) flow in any way either. Not to mention you’ll be considered as a poor manager by your team. And well, they’ll probably be right this time.

There was a company, which was doing reasonably well. When times were good they were growing stronger. Some people were leaving, as it always happen, but more were coming on board. Since things were rolling fast no one really had time to stop and verify whether all new faces are doing fine.

Some time passed. Newbies were no longer newbies – they were semi-experienced people or at least their seniority would indicate that. Reality was a bit different. Some new people appeared to be great hires but other were, well, pretty mediocre.

Then stagnation period came. There were reasonable amount of work but not as much as it used to be yet somehow everyone looked still pretty busy. Incoming stream of new people were limited and the company mostly stuck with these who already were on board. World crisis increased employee retention.

Then people started telling stories. A story about the guy who was sleeping at his desk during one third of his office hours. A story about lad who was in the office barely 6 hours a day even though he was paid for 8-hour workday. A story about lass who was spending all days long browsing the web. A story about colleague from another office who claims she’s completely overworked yet she was doing about one tenth of what other people did on similar positions. Morale nose-dived. Productivity started dropping. On a side note – no, these examples weren’t made up.

Where’s the problem?

The first symptom was not doing much with poor-performers. OK, they were trying to fix their approach but when coaching and setting rules didn’t work there was no another steps. Underperformers soon learned they didn’t have to change.

A real problem was: the company wasn’t able to fire people.

They stuck with every single employee no matter how they sucked. And yes, I know they should try coaching, training, finding new role first. To some point they did. But face it: it isn’t possible to have only perfect teams and only perfect employees. It just doesn’t work that way. Even companies which have very strict recruitment process find black sheep in their teams from time to time. And vast majority of companies aren’t very demanding when it comes to recruitment. Especially when time is good and they need all hands on deck and would take almost anyone who can help at least a bit.

I understand lack of will to fire people. Firing people sucks. But it’s a part of manager’s job and from time to time it just has to be done. Cost of rejecting to do this is way higher than just poor performance of a couple of people. It spreads like a sickness. Yet somehow I still hear about companies accepting underperformers for some reason.

Update: Since the post received pretty much buzz in my company a small disclaimer: this is true story but not about my current company, not even about any IT company. Yet still it’s about a firm I know pretty well. Anyway I used the example since the case is pretty general.

While explaining another thing which I thought was obvious for everyone in the team but appeared as not clearly communicated the question came back to me: is it possible to over-communicate in project? I dropped the question on Twitter and expected answers like “Hell no!” Or “Maybe it is possible but no one seen that yet.”

Responses surprised me though. Author of Projects with People found problems of being too detailed for the audience or revealing facts too early. Well, what exactly does “too early” mean? When people already chatter on the subject at the water cooler is it too early? When managers finally become aware of chatter is it still too early? Do we have to wait until management is ready to communicate the fact (which is always too late)?

Actually gossips are powerful and spread fast. The only way to cut them is bring official communication on the subject as soon as possible. Hopefully before gossiping is started. Which does mean early. Earlier than you’d think.

Another thing is being too detailed. This can be considered as unnecessary or even clutter. Clutter is an issue raised by Danie Vermeulen. If something doesn’t bring added value it shouldn’t be communicated. If we kept this strict we could never post any technical message on project forum since there always would be someone who isn’t really interested which framework we’re going to use for dependency injection or how we prevent SQL injection and what the heck is the difference between these two. And how do you know what is a clutter for whom anyway.

John Moore looks at the problem from different perspective – over-communication can be bad when it hurts morale. I must say I agree with the argument to some point. Some bad news isn’t necessarily related with people’s work (e.g. ongoing changes in business team on customer side) and can be due to change. Then keeping information for you may be a good idea. However if bad news is going to strike us either way the earlier means the better. One has to judge individually on each case.

Although I don’t see easy way to deal with above issues they remain valid. Actually I can agree it is possible to over-communicate yet there’s no concrete border or clearly definable warning which yells “This email is too much! You’re over-communicating!” at you whenever you’re going to send unnecessary message.

The best summary came from Lech who pointed that risk of over-communicating is lower than risk of under-communicating. I’d even say that much, much lower. How many projects with too extensive communication have you seen? One? Two? Personally I’ve seen none. On the other hand how many projects suffered because of insufficient communication? I’ve seen dozens of them.

On general we still communicate too little. Yes, we can over-communicate from time to time but I accept the risk just for the sake of dealing a bit better with insufficient communication which is a real problem in our projects.

How does it look like in your teams?

I’ve already told you that writing test cases is worth the effort. What I haven’t stressed are shortcomings of test cases.

If you take time to prepare test cases you most likely do it for the reason and I guess not for “my manager will fire me if I don’t” one. You want to invite some organization to your testing and improve overall quality of the product at the end of the day. I don’t want to go deeper for motivations since it isn’t the point of this article.

The thing you do is preparing some scenarios up front, definitely before you actually start testing. Generally the earlier the better but either way test cases are before test execution, that’s for sure. Basically when you prepare test cases you imagine how you’d like the application to be tested and you write it down. Do this, verify that, expect something other and proceed to the next step.

Now what’s wrong with that?

1. You suck at predicting how your users would use the products. We all do. Applications are built by developers who don’t even try to imagine how users will interact with software. Then they’re tested by quality engineers who are also far away from average users. Then they’re deployed by people who actually talk with users but can’t influence application development in almost any way. The whole process is driven by product managers whose job is to think about general concepts, not detailed usage flows. Who cares about usage scenarios then? Well, pretty much no one.

2. Test cases are closed scenarios by definition. When designing test cases you don’t have “flow with your gut feeling” block at hand to put it in the diagram. You actually have to make it possible to verify test results thus you’re limited to some specific path – one among hundreds or thousands. This means you won’t go through the vast majority of cases yet you will decide whether a new feature works well or not.

3. It’s not possible to have a complete set of test cases. A typical method which takes only an integer as an argument can be called in possibly 2^32 different ways which is basically infinity. If you add that you may need to call another function as a prerequisite you end up with a number which blows my head up. And we’re talking only about a single function, not about whole application. Test case is always a dramatic simplification in terms of possible usage scenarios.

4. It’s easy to complete test cases and call it a day. Hey, after all test cases are for quality engineers, aren’t they? QA people should base their activities on test cases. Except they shouldn’t limit their work just to test cases. And you want it or not there’s always a bit of incentive to turn off your thinking and just follow the plan instead of going an extra mile. I’ve already said that a couple of times, but QA team is no place for follow-the-book people. Creativity is a key trait for QA engineers, yet we don’t live in an ideal world and you don’t have only the best and the most creative people in QA team, no matter what your company website says.

With all these shortcomings I still strongly advise you to write test cases. You may try to do them as precise as possible, or you may just use general flows leaving some autonomy for testers but either way it will pay off. Especially if you understand where test cases fall short and find a way to deal with that using other tools.

Test cases are here for a long time. Used equally willingly by these who work with heavy-weight processes and those who choose the agile way. They can be stored in an appendix to documentation in BDUF (Big Design Up Front) project or be written on yellow cards along with user stories. Where’s their main value then?

Think about the comparison: test cases for application functionality are the same as unit tests for application code. Except of one thing: it is way harder to write good and complete list of test cases. You may safely assume that’s impossible. This means the main value of test cases isn’t in covering full application functionality because you simply won’t achieve that, no matter how hard you try.

Well, maybe it is a valuable tool for QA engineers? You know, they have some kind of walkthrough for testing sessions. Hm… show me quality engineers who prefer just to follow test cases instead of explore the application by themselves and I’ll tell who should be fired. Testing is such a creative task that there should be no place for follow-the-manual people in QA teams.

OK, test cases don’t ensure completeness of tests and don’t help QA people much. So? Show me the money, as one of my customers used to say. Where’s value?

The main benefit of test cases lies in the activity of writing them down. Or, to be more precise, in the process of thinking about them before they’re written down.

Test case is not much more than short scenario of application usage. Sometimes pretty weird scenario but still. Unfortunately we often forget about this perspective. We tend think in terms of code or requirements and forget about the very basic thing – no class in the code and no requirement alone makes any sense for the end-user.

Looking at application while being in end-user’s shoes benefits in two ways:

– You find black holes of your design which aren’t covered with user stories, or requirements

– You find usability issues since you see whole usage flow, not just a bunch of atomic functions

The main value of writing unit tests is actually within the writing part.

That’s the old story: we suck at estimating. Our schedules tend to be wrong not only because there are unexpected issues but mostly because we underestimate effort needed to complete tasks. There’s one simple trick which allows improving quality of estimates. It’s simple. It’s reliable. It’s good. On the minus side you need some time to execute it.

Split your tasks to small chunks.

If a task lasts more than a couple of days it’s too big – split it. If it’s still too big – do it once again. Repeat. By the way that’s what agilists came with over years – initial size of user stories was intended to be a few weeks long, now it’s usually a few days at most.

Why it works?

• Smaller tasks are easier to process in our minds. As a result we understand better what we’re going to do. As a result we judge better what means are needed. As a result our estimates are better.

• Smaller tasks limit uncertainty. In smaller room there are fewer places to hide. The fewer places to hide the fewer unpredicted issues there are. The fewer unpredicted issues the more exact are estimates.

• Small tasks mean small estimates. A month-long task should be read as “pretty long but it’s hard to say exactly how long” task. Bigger numbers are just less precise. Splitting tasks ends up with smaller chunks of work. Small chunks of work end up with small-sized estimates. Small-sized estimates mean more precise estimates.

As a bonus, during task-splitting exercise, you get better understanding what should be done and you early catch some problems which otherwise would appear much later and would be more costly to fix.

And yes, the only thing you need is some time.