Blog Archives

The importance of communication

On an intellectual level, everyone understands that communication is important.

And everyone in a company is working together with someone else, unless it is a one man company. So without communication, nothing much would get done. Stating the obvious, right?

A recent NTNU (Norwegian University of Science and Technology) Master Thesis concluded that (paraphrased):

“Allthough all organizations think that good communication is vital in order to run projects in the direction of their organizational strategy, most do not have the desired communication systems, culture or skills(..)”

Surely that doesn’t apply to your company. You guys spend lots of time making sure everyone understands what to communicate when, and to who. You naturally share all relevant information to as many people as possible, in a way that makes sure the original message is preserved.

I’m sure that you always make sure that “what is relevant” isn’t defined to tightly, and terms as “on a need to know basis” are generally frowned upon. Informal communication is always encouraged in order to build an environment where anyone will continously voice their intent, their understanding, their worries and their questions without fear of repercussions. Right?

And your managers always make sure everyone involved knows where the team is going and why. When someone does something that is not aligned with the overall goal of the company, they do not blame the individual. They ask “What piece of information did this person not have, and why?” or “What has this person not understood, and how can we help this person understand it better in the future?”

Did I just describe how the concept of information flow works in your company?

I did?

Wow.

Don’t quit!

@TSigberg

 

We can do anything!

I recently had a heated argument with a couple of our developers. They were creating a new module in one of our systems, and were building the UI based on a screenshot from a designer.

Developer: “Here is what was auto-deployed to the development server last night. As you can see it is a somewhat working prototype.”

Me (After picking on several aspects of the design): “..so I guess we’re pretty far away from anything I can show the customer.”

Developer (groans): “As you can see, it’s perfect and doesn’t need any tweaks..”

Me: “Well, were you looking for feedback, or did you just want me to compliment you on your CSS skills?”

Developer: “I was after feedback, but I am allowed to be grumpy when I get it. So, if we change the stuff you mentioned, can we move on to the admin part after that?”

Me: “If we present it like this, we’ll be thrown under the bus. I need it to be as close to the design screenshot as possible. Now that I’m looking at it again, I’m actually worried even that won’t be good enough.”

Developer: “Seriously?! Well, God. I need a timeout. Give me two minutes to grab another coffee..”

After a lengthy discussion while looking at some state of the art, jaw dropping design templates online, we all realize that we haven’t been aiming high enough with the new design. I’ve been giving them a hard time for maybe thirty minutes, even though I know their job isn’t easy. We’re hard pressed for time, and I know I’ve said the functionality is more important. But I also know that the current design simply won’t cut it. I try to calm things down.

Me: “I know I’m being harsh here, but I needed to get the message across.”

Developer: “So, if we don’t even think the design from the designer is good enough, why do we spend time implementing it? I don’t even want to do it anymore after seeing how much better it can be done.”

Me (pointing at one of the crazy designs we checked out online): “I hear you, but can we even do anything remotely like that?”

Developer (looking straight at me): “We can do anything!”

 

“Most people fail in life not because they aim too high and miss,

but because they aim too low and hit.”

-Les Brown

@TSigberg

What does that mean, between 200 and 400 hours? Just give me a number!

I know a whole bunch of developers in different companies and different businesses. What they all love most about their jobs, is when they are asked to produce an estimate. It’s the highlight of their week! 

You’ve had a creative discussion with your boss and perhaps a couple of representatives from the customer. It’s all fun and games, until your boss turns to you and asks The Question.

“So, how long does it take?”

Did he just do that? In front of the customer, no less? How on earth are you supposed to answer that reliably without any time to analyse the details? You venture a somewhat vague answer, even though you know it’s no use.

“Hm, perhaps somewhere between 200 and 400 hours?”

“What does that mean, between 200 and 400 hours? Just give me a number!”

“Oh, uhm, I guess around 300 then?” you reply desperately, automatically reaching for the average of the first two numbers you threw out there. Surely that can’t be too much off?

Any one number representing a possible future outcome of something, will never be anything except just that. One possible outcome. That means somewhere out there, you’ve got a whole bunch of other possible outcomes as well. So If you say it might take 200 hours, without the backing of additional data, the chance of it taking more or less is about 50% either way.

So you’re giving your boss a definite number based on your guess on the outcome of something, without any information about other just as likely outcomes. Does that sound like a useful number to you? I didn’t think so.

Estimates are usually needed to figure out wether to invest in something, and to set a budget. If you give me a number where it’s a 50% chance of me blowing my budget, then I’d say you’re not really helping me over here. It’s heads or tails wether I’m in trouble with the customer for overspending. So when I ask for an estimate, it’s implied that I need a number that isn’t very likely to be too low.

So if your boss (or your customer) insists on getting that one number, what to do? First we need to understand more about the problem of “just give me a number”. More on that in part #2 on this mini-series about estimating!

@TSigberg

Read part #2: “Exactly HOW likely is the most likely outcome?” 

I’m in the business of a little bit better

So, what’s it all about, this software business? Making money? Isn’t any business? Figure out how to bleed the customer of as much money as humanly possible, while doing as little as you can get away with. It’s a bit of an art, really.

It doesn’t matter if you’re buying software services for your company, or a carpenter to remodel your house. They strip you naked and hang you out to dry. That’s just the way modern business works, I guess.

Or is it?

At Revio we have a set of core values. One of them is Proud. By the end of the day, we need to be able to stand up straight, and be proud. Proud of who we are. Proud of what we accomplished.

Proud of how we have treated others, and proud of what we have delivered to you.

As much as we would like to be flawless, we are not. There are times when we look at the result of a project, a system update or some other deliverable, and must admit that it falls short. We ask ourselves if we can be proud of that delivery, and the answer is No, we can not.

I hold both myself and the rest of the team to high standards, so when that happens I feel really, really bad. Then our COO looks at me and says:

“Meanwhile in Africa..”

What he means is that sure, our server is down, our customer is furious, and it sucks. But while the customer may very well be furious, he’s not dead. He is not being killed in front of his wife and children in Libya, and luckily – neither are we.

When we’ve reminded ourselves that no matter how bad we screw up, most of the planet is still doing quite a bit worse than we are, it’s time to get back to work. Whatever was wrong must be put right, and whatever the customer is expecting, we must try to achieve.

Our way of conducting business may not be saving lives. However, by being honest, dependable and proud of what we do – we hope we are able to make yours at least a little bit better.

@TSigberg

The middle manager. The useless fat of any bloated organization

Image

The middle manager. The useless fat of any bloated organization. They delegate all their work to other people, and then they wander around aimlessy, doing nothing at all expect worry about what happens if the delegated work doesn’t get done in time.

Being useless fat can be both rewarding and fun, but most of the time it is a difficult job. Even so, it must be done. After all, stuff doesn’t get delegated by itself..

It’s an interesting and not entirely new question. What to do with middle management in a company that is agile, stuffed with self organizing teams that in turn are made up of super-cool and smart people that don’t really care very much for authority figures who try to tell them what to do. Do we really need them around?

In an “agile organization” (whatever that is), stuff still needs delegating. But perhaps you are delegating goals and projects, instead of tasks. Less time is spent reporting against imaginary project plans, more time is spent actually creating value for the customer. Sharing information, explaining goals. Discussing possible solutions. Developing said solutions, showing them to the customer early and often.

As an agile or lean manager, I’m not really the boss of someone else. I am simply responsible for other parts of the value delivering process. I am also responsible for optimizing the process itself. I also try to inspire everyone else to optimize their part of the process, whenever that is possible without hurting the process as a whole.

My job is to protect tech people from nosy sales people, help sales people understand difficult tech people, explain to owners how a little money now isn’t always better than a lot of money later, and that more quality actually equals less cost in the long run. If all of the above goes well, the result is surprisingly often that we deliver valuable and useful software to customers who don’t always know what they need, but always know where it hurts.

Basically it is understanding, sharing and aligning goals and mindsets. And that is a really fancy way of saying that you need to talk a lot. I don’t really like talking to people very much, so I guess that explains why I spend half the time worrying instead.

It may not be very effective, but at least worried people look busy. And looking busy is important when you are useless fat.

@TSigberg

We already do Scrum, but what is this thing called Kanban?

“In Scrum we <insert Scrum practice here>, would we still do that if we switched to Kanban?”

Occasionally I’m approached by people curious about Kanban, and more often than not they are already familiar with Scrum. They may have read some brief blog posts about Kanban, but are left wondering what it’s really about. What are the rules? What do we have to change? Can we still do Scrum? Help! So I decided to write a blog post looking into some of the stuff you would usually be doing in a Scrum team. Would you still be doing it if you were doing Kanban, or would there be an alternative approach to achieving the same goal?

“In Scrum we divide our project into sprints. I’ve heard that you don’t do that in Kanban?”
The answer to this is, it depends. Many teams find it useful to establish a regular delivery cadence to either test or production, while others deliver when it makes sense to do so. The general rule is, the more often you deliver value to the customer, the better. The biggest difference is that with Scrum, all the practices (planning, retrospectives, releases) are tightly coupled to the sprint. With Kanban it is 100% decoupled, and everything is optional.

“I heard that with Kanban, you don’t do estimates. How does that work?”
There are no rules in Kanban explicitly saying that you can’t do estimates. In many situations it will make sense to do some form of estimating up front, or during a project. If feasible in your setting, we would however prefer to focus on what is important, and the assumed cost of delay . What would it cost us either in direct cost or lost revenue to NOT do this task now? In 3 weeks? In 3 months?

“I attended a conference once, and some weirdo on stage claimed we shouldn’t prioritize items in our backlog?”
In a large project you may well have tens, or even hundreds of individual items in your backlog. For the sake of argument, let’s say you have 50 items. To follow Scrum, you need to order all 50 items according to priority. This is typically done several times during the project, maybe as often as once per sprint. Let’s say that you on average deliver 5 items per sprint. So in reality, for any given sprint it adds little (no) value to order anything below the top 5 items in the backlog. In Kanban we prefer to ask our product owner “What is the most important task(s) for you right now?”. Answering that question is usually easier (and faster) than ordering 50 items.

“In Scrum we have a Scrum Master. Is there such a thing as a Kanban Master?”
In Kanban we recognize the fact that change is hard. People naturally resist anything that threatens their identity. Asking people to change their professional roles would do just that. When implementing Kanban, everyone involved keeps their current roles and titles. There are no formal roles. A basic principle is “Start with what you do now”.

“In Kanban you apparently have a board to visualize tasks, like we usually have in scrum?”
Yes, but with one crucial difference. Scrum has a lot more formal “rules” than Kanban, but they’re missing one – and it’s an important one. Limit Work In Progress. In Kanban we define a workflow, and we limit the work allowed in each state. As a result, we implement a pull process. Whenever there is room for more work in a board column, more work can be pulled from an upstream state (typically to the left on the board). Limiting WIP and pulling work prevents overburdening, reduces multitasking, decreases lead time (the time it takeS from we start something until it is finished) and increases flow through the system. It will also quickly uncover flow problems. If an item is impedimented for some reason, it will quickly stop or limit the flow of the entire system.

(illustration below stolen from Henrik Knibergs excellent post One day In Kanban land)

onedayinkanbanland

“That answered some of my questions, but I’m still a bit confused. What are the RULES of Kanban?”
I’m not sure there is an answer to that. Kanban is a management and change management technique that require some time to fully understand. There are few explicit rules as to exactly what to do, but Kanban will help you figure out what works for you. There’s no one right way, the context of your situation is always unique. Does it make sense to always have sprints with a committed list of deliverables? Probably not. Does it make sense to have stand up meetings? Probably, but maybe not every day in any context. Does it make sense to have a retrospective after each delivery? Who knows what’s right for you? Only you.

“So are there any rules at all?”

We have what we call principles:

  1. Start with what you do now (No set rules or processes. Start from where you are, and improve from there)
  2. Agree to pursue incremental, evolutionary change (Make a small change, see if it is an improvement, then try another)
  3. Respect the current process, roles, responsibilities and titles (Don’t manage by fear and force, build trust and understanding. Respect persons and identities)
  4. Leadership at all levels (Delegate, build trust, encourage acts of leadership at all levels of your organization)

And six core practices:

  1. Vizualise the workflow (Without understanding what happens, it is hard to implement change)
  2. Limit work in progress (Implement a pull system, typically a kanban system)
  3. Manage flow (monitor and measure how work flows through the system, in order to detect problems and opportunities for improvement)
  4. Make policies explicit (Document how the system works, thereby creating a common basis for understanding and improvement)
  5. Implement feedback loops (Regular collaboration and review at both team and company level is important to facilitate continous improvement)
  6. Improve collaboratively, evolve experimentally (Involve and inspire everyone to suggest improvements, and experiment to validate theories)

If you are ready to dig deeper into how Kanban may help you and your organization, I suggest you start by reading: “Kanban” by David J. Anderson

Now you may proceed with your day, I wouldn’t want you to miss your daily Scrum!

@TSigberg

Me, a leader?

I’ve been a manager for several years now. A leader? That, I’m still working on.

Leading is difficult stuff. Managing, I’m actually quite good at. Leading people, now that’s a totally different ball game. There are all sorts of mushy, feely stuff involved. And when I said it was a different ball game, I did that because I’ve heard there’s coaching involved. It’s not enough to find great people, apparently you need to help them get even better. This isn’t going to end well.

As I mentioned recently, I just want us to not suck. Surely people should be able to do that all by themselves. No? So now I have to pretend to like people (I’m a hopeless introvert that would probably be better off living in a cave on the top of some remote mountain) and even try not to hurt their feelings when I tell them to suck it up and.. well, not suck.

Luckily, I read a lot of books (good cave activity). The other day I found one that reminded me that even as a leader, especially as a leader, you’ve got to tell people what they need to hear, not what they want to hear. You just got to tell them nicely.

So when I tell people I don’t want them to suck, I try to do so nicely. I start by asking them about their day. And then I tell them please don’t suck.

Seriously, I tell people when I’m not happy about something, but I try my best to assume good intent. If someone did something wrong, they probably didn’t mean to. And if someone did something wrong, at least they’re doing something. And they’ll most likely do it different next time around. So by doing the wrong stuff, they’re actually improving. Hey, that’s what I was supposed to help them with, wasn’t it?

Maybe I can become a leader, after all?

Rest assured that on those rare occasions I do come across as a leader, I will be dead set on coming across as a good one. There are so many bad bosses out there, I’m not sure there are even room for more.

Even though I still find it challenging to improve others, I work hard on improving myself. In one year, I will be a better leader than I am today. In three years I will be even better. In five, the people who work for me will go “Hey, that shit you just said actually made sense!” when I tell them stuff.

Until then, I guess when I’m not managing, I’ll be in my cave. Reading. Probably about self managing teams and silly stuff like that. I mean, if the guys managed themselves, what on earth would I do?

Lead?

@TSigberg

I hate it when we suck

I’ve been around my fair share of useless people, I’m sure you have as well.
I don’t know about you, but I hate it.

I can handle people who are genuinely useless, but useless people who are actually intelligent and could have been competent, those guys I really hate. I hate it when people do a crap job even though I know they could do so much better. It’s amazing how much you can’t get done when you’re armed with a lack of motivation combined with a healthy dose of ignorance.

I hate leaders and managers who think they are doing a great job, but actually suck at it, and blame their employees for their own shortcomings.

When I started out as a manager (and to a certain extent even today), I always took the blame for anything my employees did wrong. When you made an error, so did I. Why is that? Because I hate it when we suck. I try to do my very best, every day, all day. I seldom succeed, but at least I try. I want you to try too. Hard.

So when I take the blame for your mistake, that isn’t right, is it? I don’t want to take responsibility for your mistakes, I want you to take responsibility. Own up, move on, do better next time.

You’re at the office doing whatever it is you do most of your waking hours anyway, so you might as well be passionate about it, right? It wouldn’t kill you, would it? If it did, at least you’d die doing something you were passionate about. It sure beats being bored to death.

The next time someone gives you feedback (that’s a nice word for someone shouting at you and telling you that you suck), hold back on that excuse for just a minute. Because they already know the specification wasn’t perfect. They know the customer is a jerk. They know you have a cold. And deep down you both know that you are capable of doing a better job. That’s probably why the guy is shouting at you in the first place. It’s no use shouting at an idiot, but he knows you can do better. So why the hell didn’t you?

I’d love for us to just get rid of all the terrible excuses and blame games (even though I still catch myself participating in them from time to time). And just. Get. Better.

So whenever you get yelled at, tell them that yes sir, you are exactly right. It was my responsibility to identify that the specification was incomplete. It was my responsiblity to figure out what the customer really wanted. It was my responsibility to make sure this new feature didn’t break anything else. I will go out of my way to do better.

I for one, will love you for it. And I will do my best to follow your lead.

@TSigberg

How to make sure projects run late

The main problem with sharing information, is that most of the time people just don’t listen very well.

“What do you mean the project is late?!”

“Boss, It was always going to be late. It was doomed from the start.”

“So why the hell didn’t you say so?”

“Actually, I did.”

Being a software developer isn’t easy. Working on projects that don’t deliver as expected are common. However, most software projects don’t end up late unexpectedly – they were bound to be late before they even started.

Let me share a few typical reasons:

  • The project manager allocates 8 hours of your time to the project each day, even though he knows all too well that you spend 2 and sometimes even 3 hours per day handling support, production issues and answering questions from management and sales. Some days you even have lunch, even though it’s against company policy. Now you’re 20-30% behind schedule already. Swell!
  • Someone set a deadline before anyone have a clue what to solve, and much less how. In reality, most deadlines don’t even signify an important event for the project or product. It’s just an artifical date set because the customer decided “It has to be done by December 1st!”. No, it really doesn’t.
  • You’re only allowed to spend an absolute minimum amount of time analyzing customer needs. And by all means, don’t attempt to figure out the best way to solve the problem. “The deadline is set already, we don’t have time to sit around thinking and wiggling our toes! Start DOING something, for heavens sake!”
  • Management ignores any concern or warning voiced by the development team, and the team accepts any assignment, however unreasonable. “But boss, this is never going to be done on time!” “Well, it has to be! You’ll just have to find a way!” “Oh, okay. I guess we’ll have to figure out a way to deliver everything you’ve promised on our behalf without reducing quality or functionality. I mean after all, we’re basically wizards over here.” No, I’m afraid you’re not.

Bosses and sales people insist that you try to deliver, however unrealistic the goal may be. “We can’t let the customer down!” In the long run, giving in to unrealistic expectations actually hurts the customer. Each time the development team takes on more than it can handle, it compromises either quality or time. More time spent on one customer, means less time spent on another. Delivering bad quality and bugs, means even less predictable availability later on.

In order to satisfy all our customers in the long run, we need to be as effective as we possibly can, and deliver consistent quality at a pace that the team can handle over time. That may mean some difficult discussions and difficult decisions. However, it is better to adjust the expectations of the customer now, than to disappoint him with an inferior product or a missed deadline later.

 

@TSigberg

Does Systems Thinking Apply To Small Companies?

W. Edwards Deming (Wikipedia) 

The system. W. Edwards Deming claimed that 95% of the performance of an organisation is based on the system, and only 5% is based on the people. I won’t dare go so far as to contradict Mr. Deming, but as a manager in a small company, I am tempted to look at it from a slightly different angle.

A brilliant employee will never perform in a mediocre system, and a mediocre employee will do a decent job in a brilliant system. But if your company is twenty, ten or maybe just five guys (or girls) – surely, people must matter?

You can not blame the worker for wrongdoing, most defects and quality problems are a result of the system. But if you are five guys sitting in the same room trying to make your company succeed – well, you are the system. The five of you. When Joe screws up and says to the other four guys, “Sorry, I’m a victim of the system!” they will probably look around the room and go “Uh, what system?”

But wait a minute. However small a company, there are someone in management, there are someone in sales, you have a customer department, and you’ve (hopefully) got someone actually producing whatever it is you are attempting to sell. Maybe Joe is both management, sales and customer department, but those roles still exist in the company. So however small, your company is an ecosystem. And if you haven’t given that much thought,  possibly not a very good one.

You may just be ten guys, or just five. That doesn’t really matter. You should already be thinking structure. Processes. Quality. Why didn’t Joe tell Pete about the complaint from their most important customer? Why did Pete forget to test the new software that Mike just hacked together? And why did he hack it together when they all agreed last month that the software needed to be robust and well built?

I can hear you shout: “We can’t afford all that stuff, we’re just a small startup company!” Well, to paraphrase old William Edwards Deming: If you focus on quality, quality increase and costs fall over time. However, if you focus on cost, costs will rise and quality decline over time. Surely, that’s not what you want?

So did I answer my own question? Well, kind of. Even though “people are only 5% of the performance”, in those early days you need people who understand just that. That takes us back to where we started, perhaps having gained somewhat of a paradox along the way:

People are helpless to fight a faulty system, but to build the right system, you need the right people. 

@TSigberg