How to Support Your Backlog

Last time I got an advice for those who want to fight with their backlog. Today I’d like to share some ideas with those who like their backlogs and want them to prosper in great condition.

1. I’ll do it on evening. Yeah, sure. As you wouldn’t have a million better things to do on evening. As you wouldn’t be tired. As you wouldn’t think about a beer and a good book instead of another boring Excel sheet. Yes, that’s a good idea. Go for it.

2. I’ll die here but I’ll do it. What a consequence! Even if you are tired and ineffective consequence will allow you to... well, at least it’ll allow you to go to bed late. Or maybe, just maybe you’ll just die before you do it. And definitely all those stories you’ve heard from developers who found the bug fix while they were resting or even dreaming are just fiction.

3. Complain. I have wild loads of work. I’m so poor. I just cannot complete that on time. I try, but it surpasses me. At least you moved some pressure from your back. It was so big you just couldn’t work. And now, when everyone has heard you complaining you feel much better. Even if it took 2 hours.

4. Give me more, I’m the hero. You’re cool. And you help everyone. Hey, that’s what heroes do. You’re full anyway so another tiny task won’t do a difference, right? And you build your reputation.

5. Don’t delegate. You want something done well? Do it yourself. Delegating is overrated. You never know when someone screws something up. It’s better if you won’t allow others to do anything with your tasks.

Feel free to mix all of those. The more of them you use the better you support your backlog.

How to Deal with Backlog

You probably experienced that. Loads of work, limited time and no light at the end of the tunnel. For each thing you do there’s another one or even a couple of them which arrive to your inbox. The Mighty Backlog has taken you under control. Nowhere to run, nowhere to hide.

There are several techniques you can employ to do something with the problem.

1. Do it now day. A last-in-first-out model. You manage each new thing as fast as possible digging deeper to your todo list. Theoretically it shouldn’t work, but practically that’s great solution. You set up your mind to kill each incoming email and magic happens. You go through tasks faster than you’d think. There can be a problem with that approach if a big piece of work arrives but no excuses here. Last in, first out.

2. Begin with smallest ones. Start cleaning with managing the smallest tasks. The list will shrink soon and with less clutter it’ll be much easier to manage the rest. And you won’t need to answer all people who asked you for those little favors when you’ll be able to do it.

3. Follow the flow. That’s hardly controllable, but there are days when you’re on fire. You work more effectively than every day. Try to exploit those days to do the most important things or shorten your backlog.

4. Plan. Make a detailed plan for a several hours which things you’ll work on. One after another. Follow the plan. Make a remorse-list and put in on sight. Cross out each completed task.

5. Turn off disturbers. Messengers, websites, sometimes even email clients. Turn off everything which distracts you and isn’t crucial. Don’t go for a coffee. Don’t engage each discussion you hear.

You can try to mix a couple of those techniques but do it wisely. If you go for a do it now day, don’t try to fix the easiest thing first.

The one general advice is: don’t wait. Try to defeat your backlog as soon as possible. Other way that darn thing will grow and the task will be harder.

Ask Your People

I’ve seen a million decisions affecting employees which were made without any consultation with people. Majority of them were made for the sake of employees. You know, like parents who always know the best choice for children without asking them about their opinion. Even when children are in their thirties. And married. And have their own children.

I know you can’t debate with everyone every single decision you make, but sometimes you just go to hit the wall hard with your head just because you don’t feel like asking if your actions make any sense.

I can recall a couple of reporting processes which wouldn’t have been implemented if someone had asked people what they think about the idea and why it is a piece of crap. Most of organizational changes could be at least improved if not avoided if managers were talking with their people. Actually each process which touches employees is vulnerable to that risk.

I don’t say you should run a survey whenever you want to invite some organizational change but asking several persons during informal chant in a kitchen what they think about the idea wouldn’t be a poor choice. What would you think if we implemented that kind of reporting process? What’s your opinion about code review? Would you like to have a chance to rate your colleagues?

Ask. Listen to answers. Reevaluate your ideas.

Don’t Confuse Users

“Let’s add some function here. It’ll work that way for the first 15 minutes since the service activation and another way later. We’ll have to teach users only one function instead of two.”

And you’ll have your users wandering why the heck that feature works differently each time they use it.

“Let’s put a menu here. User will be able to choose what exactly he wants to do. Menu will appear each time a user enters as it should be possible to choose each option even if the first one will be chosen in a vast majority of cases.”

And you’ll have your users swearing each time they’re choosing the default option as they always do.

Make your users’ life easier. Give them simple unambiguous paths and shortcuts. If you have two different functions give two different buttons, menu options or short-codes to invoke them. If you have one option used much more often give a shortcut by adding another easier method of calling it.

Users like simple operations. If you need to teach users for more than several seconds how to launch your new cool feature it’s too difficult. Note that I’m telling about launching a function, not describing what it does and how it works.

If you ask me, leave ideas as those mentioned above and try to find a way to have each feature, which is extensively used available under one click.

Ever-Changing Business Requirements

A typical time-span for projects we deliver here in Wind Mobile is about six months. That’s considered rather as an average size when talking about systems for mobile operators. However that’s definitely enough to see significant changes in this competitive business environment between the beginning and the end of the project.

Usually before we finish deployment we get a list of features which are to be ordered just after final acceptance. These are either new ideas which appeared during implementation or features forgotten during initial negotiations or things which appeared not very useful or usable during tests and need to be improved.

A great environment for agilists you would say.

Well, yes indeed. Except of I’m yet to see mobile operator which would agree on that methodology for a typical business project. Quite often it’s hard enough to break even a little step in implementation procedures, not to mention putting a whole thing upside down.

What option you have then?

• Go for agile. At least you can try. With typical business project it can be hard, but for projects which can be classified as R&D it’s easier. I’m lucky enough to work with that kind of approach with at least one of our customer. And for goals we put on our roadmap it works great. Unfortunately in most cases I can say you won’t be allowed to use agile approach with that kind of customers.

• Manage it. You work with one of old-fashioned ways. You have scope, you have schedule and here you go. Each time when new requirement appears you manage it – add to the list, decide whether to implement it or not. And once decision is made you take whatever it brings. Additional effort, retests, changes in other functionalities or... nothing. As far as you decide consciously you shouldn’t cry about it.

• Scope creep. That’s the previous option but left alone without any control. Sure, they will try to put in as much new features as possible. Sure, being a naysayer is unwise but so is the other end of the scale. If you enter to uncontrolled scope creep you won’t reach the goal in fair condition. It’s a difficult decision to set up the best point when you start to reject but a crucial one.

• Be a naysayer. Talking about naysayers... you can always say: “Hey, there’s an agreement and I can’t see even a word about the feature, so you better forget that until we see a signed purchase order.” You’d be surprised how often this approach is used. I’m not sure which scenario is worse – this one or scope creep. When you have a standard answer for every question, most of the time this answer won’t be any good.

It’s always worth to look for the most reasonable way of working with changing requirements. Agile brings very good answer for that, unfortunately its implementation quite often isn’t feasible (that’s subject for another post by the way). But each process which involves a common sense and a bit of analysis to decide individually what to do with new or changed requirement should work well.

I’m curious what your approach in that area is.

Who Is On the Other Side?

Our team was reinforced lately by an experienced project manager. He worked in his previous company with one of our clients. I’d add that our client works in formalized environment where compliance with procedures is (usually) very important, which should limit freedom in project management. The interesting thing is we can confront our experience.

If I had to give one general conclusion I would say that the way the project is run is highly dependent on people, especially project managers, on client side.

Project manager’s strengths and weaknesses have great impact on the whole project. With a great organizer you won’t need to ping them for each delivery you’ve agreed. With a PM with wide technical knowledge most issues can be resolved in small group and there’s no need to check every little thing with specialists. Person who work in the organization for years will know each shortcut and backdoor within procedures and will be able to exploit them. Overloaded project manager won’t push a project very hard as he’s, well, overloaded. Guy who’s not liked much among colleagues will find hard to organize help whenever needed.

Project we compared were run completely different. While general procedures which applied were exactly the same project managers had different profiles. By the way, I guess if we had other guy on the other side we would finish our project later.

On a side note I’m sure the same rule applies when you’re a client and you look at vendor’s project manager.

That’s why it’s so important to know who is on the other side. You want it or not you’ll have to adjust to people you work with. You’ll need to exploit their strengths and mitigate impact of their weaknesses. And I’ve seen enough different types of PMs to believe that depending on people on the other side project implementation can look dramatically different.

Who is on your other side?

A Couple of Tips for (Not Only) Managers

Ray White gives a tip for managers:

“Love what you do. And show it.”

I wouldn’t limit it for managers only. No matter if you have to show leadership or expertise or engagement. As far as you like what you do and you’re able to show it to others people will appreciate your efforts. It is true when you’re a leader and you try to fire up your team. It is true when you’re a team member and you look for support from your boss and colleagues.

Scott Berkun comes with another law of management. A true gem:

“It is your fault.”

Whenever you screw something up take the responsibility instead of looking for an excuse. Another time I definitely don’t leave that for managers only. Your colleagues should appreciate your ability to admit your failure. Your bosses should appreciate that too. And of course most of all your team will appreciate when “you take enough bullets for them.”

When I read Ray and Scott I realized once again these are things I look for whenever I recruit. And I do it partially unconsciously. Except of expertise in specific area I want to work with people, who love what they do and are able to admit it’s their fault.

It makes a better team that way.

Flexible Working Hours: Worthwhile or Not?

I hear that question a lot during interviews.

What’s your working hours here?

And my answer is always the same.

Whichever suit you fine.

Of course flexible work-time brings some issues. It will be harder to organize meeting when you have in the team a person who starts at 7am and another who starts at noon if you’re lucky. It can happen that you’ll end up with sleep lovers only and no one would react early in the morning. You won’t predict exactly when your colleagues will be at work.

But these are rather small issues when compared with making people a bit happier. People able to wake up late if they like that. People able to go on errands for themselves during workday whenever they need. You can’t count that in money. It’s hard to verify productivity growth. But making people a happier always works.

There’s one trap here. Flexi hours are often a name for working overtime. Then, well, it’s not so good idea. I prefer to tell honestly: sometimes we do work overtime. It happens. We don’t treat as a normal situation but it happens from time to time. And we don’t call it flexi time.

As far as a deal is fair it is definitely worthwhile. Especially when you work in IT environment where you can find more people who appreciate freedom. If it doesn’t kill your work processes, go for it.