In Defence of Target Setting

I have read multiple blog posts about how bad it is to set annual targets and even worse to tie them to monetary rewards. I agree with most of those writings. But still I find myself motivated by targets.

Maybe this depends on how the targets are set. I see a sales budgets as a suboptimal solution (for the company). As a salesman, why on earth would you care how much it costs to develop something you sell? Even if it doesn't exist yet. And you can even give the customer a big fat discount. It's anyway better for you to close the deal than not to.

For sales teams I'd definitely like to have some targets that take into account the overall situation of the company better, the big picture. In addition to the money received from the customer, also the amount of work needed to deliver the product should be taken into account. Preferably the sales bonuses would be counted AFTER the product has been delivered and measured how much the sale really affected the bottom line of the company.

But let me get back to those individual targets that I was excited about. I can openly admit that I have plans for the future. In my role I get to actually affect the operations in my company rather much. I have a vision how I’d like to see things happen. And I spend a lot of effort to make that vision come true.

Then let’s say this vision is well in line with the overall company vision. Both aim to make the company profitable while delivering high quality and desirable products for the customer. In this case I see the target setting as a win-win deal. My internal ambition and the benefit of the company go hand in hand. That's why I have a good feeling that we will both will help each other out.

In short my message is: targets aren’t bad. They are like chainsaw. You can use one to cut trees or for a massacre. Let’s hope the chainsaw is in good hands.

Realism in Software Development

I have earlier written about how hard it seems to be to understand the reality in software development. This time I'd like to share some more examples I have either shamelessly copied from different sources or come up myself.

It is possible to create releases very often without taking them into deployment. Of course this is not something you aim to do, but it is somewhat easy none the less. There can be various reasons, but probably most common is some bottleneck in the process or in the interface between two processes.

If you have a conveyor belt that transports boxes, what will happen if you don't move the boxes away from the other end? They will pile up. Before you know it, if you don't stop the belt, you'll have a mountain of boxes. You probably react in time before this happens. (Also in software development you can utilize for example Kanban to visualize things and to identify the bottlenecks.)

Another example. Let's say you participate in a testing of a new mobile phone model. You get a brand new toy to play with. But then you find out there is a nasty flaw in your product. An irritating bug that destroys your user experience. Naturally you inform the manufacturer. And then they send a person to your home to fix your phone.

Or maybe they will not send anyone to repair it. Probably they will actually just send you another phone. With software products we sometimes don't operate as pragmatically. Instead of just sending a new version, we make a correction to the existing version. This is called patching. Sometimes it just cannot be avoided, but the need should always be carefully assessed.

Keep things visible. Aim to increase transparency. Think carefully about what is really happening and how you could tweak the system to reach a whole new level in efficiency!

Personal Communication and Decision Making

Individuals and interactions. Customer collaboration. I find it really hard to do that without meeting the other person. And if at all possible I prefer meeting them one on one. Or if that is not possible, I usually call using phone or voip. Why? Because it is so much more efficient than writing emails! ..or instant messages or anything else in writing.

I use such tools as JIRA, Lync and Flowdock quite a lot during my days. They are all great for asynchronous communication. And so is this blog post. But getting feedback for anything is a bit too slow to be really agile. Maybe one of the most frustrating features in instant messaging clients is to see that the other person is writing. Then you look at that and wait. If the other person has lot to say, you wait for a long time. But if you go and just have a quick chat it will all be done in no time. Simple and you get to do some nice human interaction also. I count it as a plus!

Well, you cannot always win. Sometimes the face to face conversations may not be pleasant. Sometimes you and the other person just disagree and there might be no getting past it. Or you need to give the other person some feedback that is not so easy to swallow. During those times I suggest just to focus on the facts. Don't get angry or frustrated, just deliver your message. Then you might want to let the other person to cool down before attempting anything mentally challenging. Because frustration simply blocks down our ability to think clearly.

Another interesting topic is the decision making. If I haven't totally misunderstood things, it's actually rather central topic in Agile. Empowering teams gives the teams (and individuals working there) power to make decisions. And thinking about it with some common sense, it does seem wise to do the decisions where the best knowledge is: in the teams. In Scrum the role of the Scrum Master is to remove impediments. A pending decision is an impediment. It's better to make a decision and move on than to waste time in pondering. So, Scrum Master can help facilitate decision making in order to keep team moving.

And I think the same principle applies when going "up in the food chain". Management should provide people with decisions. That's their job. Creating a better working environment through making decisions. Or empowering other people to make those decisions. But that's already a valid decision (and often a very good one.)

Finally I'd like to share this interesting link. Cult of Done. So simple yet so powerful! Starting things is easy. Anyone can do that. But what really counts is getting things Done! Finish starting and start finishing. Have working software as your only metric of progress. Done is the engine of more!

Successful Pre-Planning

Sometimes things just go smoothly! Today was one such day. Today was the Pre-Planning of our next Release. Everyone was well prepared. As I have previously written, we are currently experimenting with Scaled Agile Framework (SAFe). We have Product Visions and Roadmaps. This is an area where we have especially put our efforts on lately and it really starts paying off!

We had a two hour session. First some general information about the schedule and then introduction to not yet so familiar concepts of Themes and Roadmaps. Then the Product Managers introduced their latest Roadmaps and explained the business drivers. It was nice to see the leap in the quality since the previous Release.

After the Roadmaps, the Product Owners shared their teams' draft Release Plans. Some of them were not yet very realistic or contained way too many things, but it was good to have visibility to this none the less. Seeing some draft gives a lot more possibilities for improvement than having nothing at all.

Hopefully this two hour event gave the whole company a better view on where we are and where we want to go next. As the coordinator and facilitator of the event I felt it hit the spot. But I have a tendency of being over-optimistic from time to time. ;)

On a side note, I finished reading Management 3.0 by Jurgen Appelo. Great book! I can already see myself trying this stuff in action.