≡ Menu

Pawel Brodzinski on Software Project Management

No Management Mindset

No Management Mindset post image

All sort of no management approaches are hot these days. It shouldn’t come as a surprise. Self-organization, empowerment and autonomy are inherent parts of Agile and Lean approaches. If you distill the essence of these and bring them up in the hierarchy it means quite a challenge for traditional ways of managing teams.

Of course, few organizations are that far with their evolution and only handful, like Semco, Valve or (recently) Zappos, are really radical with no management. I’m not an orthodox though. I’m not going to draw a line that separates no management organizations from regular ones. I don’t see a point and I don’t care about labels anyway.

The important part here is mindset – understanding why you are changing the approach to management and what expect to achieve with that.

And honestly, I don’t expect us to see no management approach becoming a new trend in organizing companies, no matter how vocal its proponents are. There are a few reasons for that.

We are so strongly rooted in traditional approach to management that I don’t expect many would find it easy to change their mindset. And they don’t need to. We may take pretty much whatever reasonable organization’s success criteria you want. Then, basing on the criteria we’ll find the most successful companies in the world. I’m almost sure that the top ones would be those with pretty traditional management approach.

Of course statistics are against no management organization. I mean, there are only that many of them. However, if no management was so superior we should have loads of wildly successful followers. Sorry, that’s not what I see.

The reason why I don’t see a rapid adoption of no management is that it is damn hard to make it work. And it’s way harder to make it work at scale. I would say that fixing dysfunctional management of an organization without changing the whole approach to management as a whole is a task that is an order of magnitude easier than a transition to no management.

By the way, when we cease to have formalized management we flip one of systems thinking paradigms. In fact, no management means magnifying the fallacy of people versus system dichotomy. Suddenly we can’t just blame the system as everyone explicitly co-creates that system.

A simple example. It happens so often that people delegate decisions and responsibility at a workplace asking “can I…?” Obviously, each “yes” or “no” answer, besides addressing a question, sets a constraint. This is allowed here and that isn’t. By the way, that’s how we define system at our organizations.

What if there’s no definite answer? Or the only answer is that here are our high-level goals and everyone makes their own decisions so we get closer to achieving these goals? Everyone makes their own yes / no decisions and thus get involved in setting constraints. Everyone is, in fact, involved in defining and designing the system.

The interesting part is that all it takes to get there is management distributing their power across the whole team instead of executing it.

You don’t have to get rid of the management. You don’t have to become one of those hot no management organizations. It’s just a mindset change.

This is also a reason for a very limited adoption of no management approaches. A mindset change only sounds simple. It goes against almost everything that we’ve learned about leading teams. Usually it goes against team’s expectations too. Even more so when people visualize scenarios taken from Zappos or Valve or W.L. Gore.

There’s a good part too. If we are talking about mindset it means that it is applicable in all sorts of environments. You don’t have to be a full-blown no management organization to do this. You can push the limits pretty far with your team, even if you are a part of an organization that adopts more traditional way of managing teams.

All it takes is to give up on power while still taking responsibility. Would you dare?

in software business, team management
1 comment

The Fallacy of the Ideal Team Size

The Fallacy of the Ideal Team Size post image

An argument over the best team size is as active as ever. As long as we are in broadly understood context of agile the starting point usually is 7 plus or minus 2 people, which was widely popularized along with Scrum. This, by the way, leaves pretty wide margin for the optimal team size. You can find more precise answers though.

It may be 6.

My rule of thumb is that no work team should have membership in the double digits (and my preferred size is six), since our research has shown that the number of performance problems a team encounters increases exponentially as team size increases.

J. Richard Hackman

Or maybe it is 4.6. By the way, does it mean that we need part-timers to chase the ideal? Oh well…

For the contrast Larry Maccherone reported at Lean Kanban North America 2013 that his quantitative research on data from nearly 10,000 teams showed that there’s no difference in productivity and quality in teams of 5-9 people and those of 10-12 people.

Yet another argument to the discussion: Anita Woolley’s research shows that collective intelligence, which I find a key ingredient of team effectiveness, raises along with a team size. It flattens out between 10 and 11 people.

But wait, didn’t Fred Brooks in his classic Mythical Man Month taught us that along with team size growth a number of communication paths grows exponentially? That would mean that for a team size the bigger means the worse.

This is confusing, isn’t it?

We are talking about the range between 4 and 12 already. I guess it wouldn’t take much of research to find sources that would broaden that range even more.

The tricky part, and one that often go unnoticed, is that when discussing the perfect team size we don’t ask the question: perfect for what?

Each of aforementioned sources focuses on a different angle. Be it performance issues, decision making, quality, productivity, problem solving or communication. Would optimizing any single one of these make a perfect team? I doubt it. Is it possible to optimize all of them at the same time? Well, it seems pretty unlikely. The numbers are just too far one from the other.

That’s not the fallacy of the perfect team size though. I know I’ve just introduced a complex equation with many variables to solve the ideal size problem. However, knowing our specific context we can use different weights for different parameters and solve the puzzle. Oh yes, it would be super-contextual and probably would be very hard to copy even for another team within the same organization. It doesn’t really matter though as the effort would be futile.

It doesn’t matter because the whole discussion is flawed unless we understand how our teams operate. While we typically assume that structural or hierarchical borders are what constitute a team it is a huge oversimplification.

An interesting thing happens when we observe organizations without fixed teams. One example may be Lunar Logic where people are assigned to ephemeral project teams and when a project is finished they move on to a next challenge. Another example may be Valve where someone who has an idea looks for others who are willing to develop the idea with them. These teams are even more unstructured as, at least in theory, people can come and go as they want.

Now, let’s think for a while how people work in such environments. Do they function only within a team they are currently a part of? To some point. As long as a discussion is related strictly to the matter of a project they likely keep it within a project team. However, given that the borders aren’t that strict it’s much easier to go beyond a team to look for new ideas or solutions when an issue is more general.

In other words people function in at least two different teams depending on a context. In Lunar, if I have 3 people in a project team this would be one entity they are part of. Another one would be 7 people who sit in the same room. Yet another one would be everyone within a range of a shout which is pretty much everyone in the company (yes, I know it’s easier with a small organization).

Depending on a specific situation people would organize themselves to optimize a key parameter to accomplish a task. When they are discussing the scope of new batch of work they would go to an empty room to optimize communication and focus. When they are solving issues they would have an open discussion and likely invite people from other projects to improve creativity and collective intelligence. When they want to make sure the quality stays high, they’d look for another pair (or pairs) of eyeballs to look at the code as very small teams seem to have worse quality than bigger ones.

Now, a big question: what team size we are talking about here actually?

Well, I told you. Three people. Except, when you look at a broader context, it isn’t much of answer, is it?

By the way in the context of Lunar Logic whenever I’m talking of teams I like to think of two layers of teams. One is a project team which typically is small. Two or three people per team aren’t a rare situation. Another layer is the company as a whole. In many cases we act as one big team. No hierarchy whatsoever of course helps a lot but that’s a different story. It means that we flexibly operate in 2-25 range in terms of a team size. I bet the ideal size, whatever it might be, is within this range.

Of course, an unstructured environment makes it easier to break the hierarchical borders. However, even in pretty structured organizations I know I see the same behaviors, except they are not that intensive.

The fallacy of ideal team size is that there is no such thing as the ideal team size. Instead of organizing people according to some sort of a magic number we should rather think of how to create an environment where people can easily adjust that size by themselves depending on the context.

Then the whole discussion of what’s the best size will simply be irrelevant.

in software development, team management
1 comment

Closing Leadership Gap

Closing Leadership Gap post image

A theme that pops up every now and then is a leadership gap. An organization or its part finds itself in a situation where they need more leaders that there potentially are available. They might outgrow the old model and the existing leaders just don’t scale up. They might be facing challenges when someone had left the organization. It might be a simple consequence of evolving how the organization works. A list of potential reasons is long.

A list of potential solutions is surprisingly short though. Typically it’s either hiring some people or promoting a bunch of folks to leadership positions. The former often means a lot of uncertainty. We don’t know whether a candidate would fit existing culture and pretty frequently we don’t even know how to verify that they have the right traits and skills.

The latter, while it seems safer, is commonly a root cause of having the wrong people in leadership or management positions.

What is a leader anyway?

The problem of a leadership gap is actually deeper than we think. A part of it is how we constrain our understanding of leadership. In vast majority of situations when I hear about leadership debt a story is about leadership positions.

You know, it’s about a position of a technical leader, line manager or something along these lines. This will never scale well.

Even if scaling wasn’t an issue a situation when a team relies on a single leader is a huge risk itself. I would simply question that any single person is competent to make all the leadership calls you can think of. For example, on any given team I’m likely one of the last folks you want to enlist to lead with a technical issue.

My answer to leadership gap starts with defining leadership as a contextual role and not position. This means that depending on circumstances anyone can act as a leader. It doesn’t matter what position they are in, what their tenure is or how much formal power they have. The only thing that matters is that within a given context they are the right ones to lead a team.

Suddenly leadership gap doesn’t exist anymore as basically everyone is a leader and acts as one in appropriate moments.

Where Leaders Thrive

Obviously it’s not that easy. The magic won’t happen without a right environment. There are two critical bits to make it happen.

The first is empowerment. Everyone has to know that they are supposed to be leaders whenever they feel like it. It starts with formal leaders, people in leadership positions, ceasing to execute their power. It’s not dodging the responsibility. Pretty much the opposite. It’s taking responsibility for decisions made by someone else. That’s quite a challenge for most of us.

The best summary of such attitude are Grace Hopper’s famous words:

“It’s easier to ask forgiveness than it is to get permission.”

If your people believe in that and act accordingly, they truly are empowered. It also means that from time to time they will make you willing to yell at them: “Why the hell hadn’t you asked before you did something so utterly dumb?” What you should do instead is shut up. Don’t ruin that.

The second bit is trust. If you don’t trust your team you will always be struggling with a leadership gap. Without trust the empowerment part would be meaningless empty words. No one would attempt to play a role of a leader and even if they do it once there wouldn’t be a second attempt.

This is difficult because it means giving up control. But wait, we want more leaders so we are talking exactly about this – giving up control. How is anyone supposed to lead if their every action is double-checked by someone else?

Closing Leadership Gap

I have an idea for you. Instead of asking how to close a leadership gap think whether your people feel empowered or rather carefully managed. Ask yourself how you react when they screw something up and how it affects their future actions. Finally, be brutally honest with yourself: do you trust your people?

The leadership gap problem is never solved by getting more leaders. The solution is creating an environment where leadership thrives.

In other words the key to this puzzle is not outside the system but within it – in a way existing leaders act. And obviously the more senior the leaders the more they influence the situation. If you are complaining that you lack leaders in your team it’s likely your fault.

in software business, team management
3 comments

What Value Is Exactly

What Value Is Exactly post image

One of arguments that I repeat in different contexts is that our ultimate goal should be delivering value to our customers. At the end of the day it doesn’t matter how many lines of code or features we’ve built. What matters is how much value has been delivered.

The concept seems to be pretty challenging in software development communities. In Lean or Agile communities it gets closer to stating the obvious. Nevertheless we don’t do that much with the obviousness. Product development, portfolio management or work organization on a team level are oh so often all about efficiency and not much more.

After all it is way more difficult to assess value we deliver than simply count features. The interesting thing happens when we try to define what value is exactly.

The question we should hear over and over again but don’t is: value for whom?

A common setup is: a vendor a.k.a. a software development company, a client paying to have a product built and its users. There are obviously more complicated scenarios as well as simpler, e.g. a company developing their own product. I’ll focus on the scenario with three key groups of interest though.

Let me give you a few examples.

The software development company built a product for the client. It is high quality, it does the job and paying users seem to be signing up in big numbers. The only problem is that the client was toxic thus big chunk of people working on the app left the vendor. Despite the fact that value is there for the client and users the balance of value on the software development company is negative.

If I saw such a project at Lunar Logic I would find our way out of the arrangement. By the way, it basically means that I don’t consider value for a client / users as the ultimate goal we should strive for. There has to be alignment with value on the other end as well.

There is another product for another client. Again it was delivered with high quality, users really like it except they’re not willing to pay for the service. This time collaboration went exceptionally well. On the top of that the product was fun to build for the team. It seems that the software development company got value on their end. Users, to some point, too. But the client? Not really. This business doesn’t scale.

Should I as the vendor’s representative reject to build such a project? I mean, a product idea is always a bet so you never quite know how it’s going to play out.

The value equation is again imbalanced though.

Yet another product was built in a very collaborative manner with a high quality and both the software development company and the client were happy. Except the users wouldn’t come. Why was the client happy then? They treated the product as an experiment that should verify a hypothesis. Even though the product wasn’t a success the main goal was knowledge discovery and from this perspective value was there.

Once again one of the parties – users – didn’t get value, yet it doesn’t render the whole endeavor senseless.

Of course, an ideal case is when not only is it a win-win-win kind of situation but also each win is roughly equally valued by each party. My experience is that it doesn’t happen very often.

In fact, value for money metric would differ depending on how much one values money. If a few hundred dollars for a day of work of a developer seems to me like a fortune I would expect miracles for my money. If it seems like a decent or even affordable rate my expectations of value I’m going to get are different.

When you talk about value, make it clear what value you are talking about exactly.

To make such a clarification you first need to understand that there are different sorts of value and they are driven by different factors. Then a natural next step is to ask what these factors are. Once again it will differ much. It may be profits, employee retention, number of users, knowledge discovery, solving a problem that people have, or hundreds of different things. Only if you are able to tell which factors are important in a given context you can come up with reasonable measures of value.

Without that value will be an ephemeral concept that we can’t assess in any meaningful way.

This also means that we can have a discussion on how value differs for all the parties involved and which bits are the most important for us. Because most of the time we have to choose.

in project management, software business
2 comments

Portfolio Management: The Search for Value

Portfolio Management: The Search for Value post image

I am talking about the cost of multitasking pretty frequently. This discussion gets even more interesting when we are in portfolio management context. Why? It is so because we are dealing with extremes more frequently on that level.

Cost of Multitasking

Let’s imagine a situation when a software developer is dealing with three tasks concurrently. We know that it isn’t efficient. It may be based on our knowledge how multitasking affects our work but it may as well be our intuition.

Now, would we have the same intuition if we changed the context and we were discussing a team working concurrently on three different projects? Interestingly enough, we’d be looking for arguments why in such a context it isn’t that much of a problem. Stuff like: part of the team would work on one project and another part on another project. Sounds familiar, doesn’t it?

Thing we typically forget about is how team members would interact with each other. They wouldn’t think of themselves as of isolated sub-teams. They will be frequently looking for colleagues’ help thus they will make other people switch projects for a while every now and then. Finally, we have the coordination effort that has to done. Who is working on what, what is the status of everything, etc.

This gets even worse when the distribution of people across the projects isn’t fixed. Then people would be thrown to one or the other initiative depending on the current situation. Why is it costly? Zeigarnik Effect describes that we, as humans, have intrusive thoughts about stuff that we left unfinished.

In other words, if I change a project but I haven’t wrapped up my part in the current initiative I will likely be interrupting myself thinking about the old tasks. In fact, I don’t need any external factors to incur the context switching cost to my work.

There’s more than just efficiency penalty though. The teams that are working on more than one project deliver lower quality results, as Larry Maccherone points in the results of the research run across thousands of agile teams.

Cluttered Portfolios

Things get even more interesting when look at the big picture – not a single team but all the teams within one organization. It’s enough to ask two questions. How many teams are there? How many active projects or initiatives are run concurrently?

The answers with the ratio in a range about 10:1 (ten projects per team on average) aren’t uncommon. It means that our forces are spread very thin, the coordination effort is significant and the frequency of people switching projects is fairly high.

Another question may be: what is the percentage of people assigned to more than a single project?

Either way, in some cases we’d find that not only do we have more projects than teams but also we have more projects than people working on them. Some extreme examples I know of would show that there are 4 times more ongoing projects than there are people available to work on these projects.

How efficient is that?

No reasonable person would do such a thing on purpose. Yet, this is happening pretty often.

Project Attractiveness

If we assume the goodwill of people managing project or product portfolio, there must be something wrong with the approach we typically use to manage the portfolio. Let’s think for a while data we use to inform our decisions on starting new initiatives.

Obviously we know the client and, at least roughly, the scope of the project. On that basis we come up with the idea how much the project would cost and what revenue we can get out of it. How do we do this? Well, we estimate.

One problem is that, as Daniel Kahneman points, we are biased toward the most optimistic scenarios. Another one is when we do these estimates. Johanna Rothman phrases it:

If you fall for estimation as your way of valuing projects in the portfolio, you are doomed to fail. Why? Because you are trying to predict the cost or the date when you know the least about the project.

Typically, we base on insufficient data and use our flawed estimation skills to come up with the measures that are supposed to help us assess value of projects. That doesn’t sound like an extremely useful approach if you ask me.

The problem is that pretty frequently that’s all we have in our toolboxes: an unreliable total cost estimate and expected income based on that very estimate. If we are really lucky we can say a bit about high-level risks too. However, if nothing else is in place the only application of risks assessment on this stage would be tweaking the income expectations so it includes potential screw ups.

All in all we end up looking at projects through attractiveness glasses. It’s all about how much profit we can potentially earn doing this or that project. Given that we model income on expected total cost almost all of the projects will look reasonably profitable, thus all of them will be considered attractive.

There’s a pattern our brain follows, called What You See Is All There Is (WYSIATI). It basically says that whenever we are judging something we take into consideration only evidence that we have at hand and omit data that we could potentially gather to inform our decisions better. In other words, if what we see is cost and profit we won’t automatically be looking for other data points that can tell us something about value of the project. We will just do our judgment on information we have at hand.

If we put WYSIATI on the top of our limited and unreliable data almost every initiative would look appealing. It is no surprise that we end up with heavily overloaded portfolios.

Where Value Is

The question we should be addressing is not the one about expected profit, but about expected value. The problem is that the latter is more difficult to answer. On different occasions, during my presentations, I’ve had a chance to ask audiences whether they know what the value of features they build for their clients is. Few people do.

We simply don’t think about our products and projects in such terms. Even when we do though, it solves only a part of the puzzle. One oversimplification I often notice is that we boil down the discussion about value to the users or clients only. The problem is that both parties will define value differently. Let me give you an example.

At Lunar Logic we build web applications for our clients. We can build a product for a client that delivers valuable features in a predictable fashion. We can even help the client shape the product so we avoid the non-value adding functionality. The client would be happy – they’d got what they define as value. At the same time though, the client may simply be a toxic person who would make the team’s life miserable. Now, on our end, depending on a situation, it means that overall value of such a project may as well be negative: we would have gotten the money (one aspect of value) but lose a part of the team (another aspect of value). It is likely that the former wouldn’t compensate for the latter.

I don’t have all the answers for the questions about value. The cases when I’d disagree with how our clients define value aren’t rare. On my end, while I can say what we value as the company, sometimes it is very difficult to assess value for initiatives we undertake. It’s not as bad as it looks though.

We don’t need to define value in absolute numbers. If the goal is to improve the way manage portfolio most of the time we will need to answer only relative questions, e.g. which project is more valuable given the criteria that are important in a given context?

In fact, the most valuable outcome of the discussion will not be the exact assessment. It will be a discussion itself as it will likely cover the areas we typically ignore, thus will yield in the better understanding of the situation.

It won’t happen though unless we understand the limitations of our decision-making process on a portfolio level. Otherwise we will keep doing even more of the same thing make our teams even more inefficient and miserable.

in project management
0 comments

Why People Don’t Learn

Why People Don’t Learn post image

Josh Bradley in a comment under one of my older posts made me realize an interesting thing. Let me do the weirdest thing ever and quote myself a few times.

“In general, people don’t care if you want to (and can) teach them something. They don’t want to learn.”

Pawel Brodzinski, 2010

“People are lazy. They don’t learn because it’s easier to leave things as they are.”

Pawel Brodzinski, 2010

Theory X tells us that people are lazy and we need to supervise them otherwise they’d do nothing. If you ask me, that’s total bullshit.”

Pawel Brodzinski, 2013

Now I feel so much better – someone has just quoted me. Wait, wasn’t it auto-quotation? Oh well…

The point is that three years later I seem to have completely opposite point of view. I used to think that people are inherently lazy and now I consider that absurd. Embarrassing, isn’t it?

Let me start with defending my younger self. On one level lazy, not willing to learn attitude is as ubiquitous as it was. I still look at the vast majority of people and see the same dysfunction. People would complain how their organizations don’t support their intrinsic urge to learn. At the same time they’d idly sit looking as learning opportunities as they pass by making a swooshing sound.

The symptoms haven’t changed.

What has changed is how much of a cause I ascribe to the people.

I’m not a systems thinking junkie. I do consider people co-creators of the system they operate in. At the same time though they start with a given situation and can’t change it freely, thus the system constrains them on many accounts.

How does it translate to laziness and reluctance to learn? Well, the questions we should ask are how the organization supports learning and what the rewards (or punishments) are when one decides to invest their time to self-development.

There are (many) companies which don’t support personal development of their employees. This makes the game whole more challenging. At the same time I’m yet to see an organization where there is virtually no opportunities to learn.

In fact, I think these two perspectives are inseparably connected. An organization that doesn’t support learning would discourage people with an urge to learn to stay there in a longer run. What’s more people who rarely give a damn about learning would thrive there sustaining the existing culture. Obviously, the opposite is true as well.

As Jim Benson said “people build systems build people.” Both of them have to be in place to see continuous learning culture flourish.

in personal development, software business
10 comments

Why Bonus Systems Don’t Work

Why Bonus Systems Don’t Work post image

The last time I shared my advice on how to fix a bonus system it was something along the lines “get rid of that crap altogether; it is beyond any repair.” The system I’ve just mentioned wasn’t extraordinarily flawed – an incentive money system in the company next door can work exactly like that one.

Still, get rid of that crap.

It may even be way above average bonus system.

Get rid of it.

It doesn’t work. It can’t.

OK, let me start with a confession. Throughout my career I designed a couple of bonus systems. For quite a lot of time I was a firm believer that this is the way to go. The simple observation that every single bonus system I’d seen was flawed big time was more a motivation to finally get it right than a source for doubts that we may be trying to do the wrong thing righter.

Eventually I started questioning the role of money as a motivational mechanism. Dan Pink’s TED talk is a classic on this subject.

OK, I get the message already. Money doesn’t motivate. It doesn’t mean that it doesn’t yield positive outcome. I mean, it makes people happier, doesn’t it?

Well, sort of.

I think we should start with how people perceive the money they get. Is $100 worth the same for everyone in a team? I guess we all sense that this isn’t the case.

“People’s choices are based not on dollar values but on the psychological values of outcomes, their utilities.”

~Daniel Kahneman

In other words everyone may translate $100 to something different. In fact, I might have been happy with such a bonus last year but now, since my salary is higher, I’d need to get higher bonus to be equally happy.

It basically means that we just can’t get the incentive money distribution right. Depending on who performed best, a different amount of money would be needed to make people feel equally happy. At the same time it means that people who performed equally well should get different bonuses because they have different concepts of utility. That just doesn’t feel right.

By the way this is exactly why we typically speak about money in terms of percentages, not the absolute values. “I got 10% raise,” not “I got $100 raise.” The former gives at least some insight how much I value the raise.

That’s not all though.

“For financial outcomes, the usual reference point is the status quo, but it can also be the outcome that you expect, or perhaps the outcome to which you feel entitled, for example, the raise or bonus that your colleagues receive.”

~Daniel Kahneman

Even bigger problem is with the reference point we use. Not only is it about how much I value $100 but also how much I expect I deserve. In other words, in a normal situation I might have been totally happy with $100 but I know that everyone around is getting $500. This means that it is suddenly only $100 and I’m going to feel miserably.

There are many drivers to what we consider the reference point. One very interesting thing is that after a couple of situations when I got bonus money it becomes the new normal. I expect to get it again. I doesn’t matter that my performance in the next project wasn’t that stellar anymore. My reference point evolved.

Believing that, in this case, incentive money is still completely optional and the default situation is that I don’t get any is just fooling oneself. In fact, every fat bonus I get simply makes me adjust my reference point. It isn’t something managers would like to see I guess.

Unfortunately, it’s even worse than that.

My reference point may change the utility of a bonus I get to negative values. I would consider outcomes that are better than the reference point as gains. Those that are worse than the reference point are loses. In other words if my status quo is set at $500 and I got only $100 I feel like I’ve lost $400. Someone paid me money just to make me feel miserable. Congratulations!

“The happiness (people) experience is determined by the recent change in their wealth”

~Daniel Kahneman

Considering the fact that change in the wealth isn’t measured in absolute numbers but against the reference point I see two ways to keep people happy. One would be to pay them more and more every single time, because then we don’t need to care about their raising expectations. Another one would be to set expectations on a constant level and focus on all the other happiness drivers that are available.

I don’t think I need to mention how much “brilliance” is in the former idea. The latter means no bonus system at all.

We can’t make bonus system right. The best we can do is damage control. The obvious follow-up question would be: so why the hell are we spending money to make people unhappy and harm our organization?

One common answer I hear is that getting rid of bonus system would make people unhappy too. Oh yes, it will. I mean you’ve set that expectance that people would get bonuses. You’ve changed their reference point. Yet still the choice you have is between keeping (most) people unhappy in the long run (and continuously paying for that) and getting rid of the dysfunctional mechanism. The latter may be painful in a short term but at least that’s one-time change.

So yes, this is my advice: get rid of that crap altogether.

When you think how people perceive money you understand that no matter how hard you try you’re not going to make it work.

in team management
2 comments

Multitasking Teams

Multitasking Teams post image

There’s one question I ask pretty frequently during my presentations or trainings: do you think that context switching comes for free? I’m yet to see a single hand up after the question.

Not that I believe that this is universally accepted point of view. In fact, there is a follow-up question which is: who has a boss who thinks that context switching comes for free? I do get positives for the latter.

I’d also assume that some people, even if they believe in free context switching simply wouldn’t raise their hands. Peer pressure, you know.

I’m happy with the assumption that awareness of costliness of context switching isn’t ubiquitous and definitely there are different assessments of how costly it is exactly. Still, I’d say that basic understanding that we pay a context switching tax is pretty common.

Context Switching Cost

After all, it oh so obvious to predict how texting on the mobile while walking through a crowded street is going to end. Or playing Angry Birds while driving. Or driving, having a call, lighting a cigarette, overtaking another car and shifting gears, all at the same time (a true story; I’m glad that the passengers made it alive).

It gets a bit less obvious when it comes to our workplaces. On occasions you’d hear things like “do it in the meantime” or “can’t you work on both of these things concurrently?” (Sure, I can. As long as you want both of them to be late, that is.)

The real fun starts on yet another level though. Concurrent projects. When we aren’t discussing individuals but teams and not atomic tasks but projects, suddenly the assumptions that concurrent work on them doesn’t hurt becomes surprisingly common.

The reasoning is that one team member will be working on one project and another team member on the other project. I’m always astonished that this thinking pattern is there even when there are more projects than team members… Anyway, let’s assume the situation is not that dramatically bad.

There is still a problem of multitasking on a few different levels. First, there’s planning and coordination. Who should do what for how long? Even if team members typically do have comfort of being able to focus on a single thing there are people on the team who constantly switch context between all the projects that are run.

Then, there’s regular communication. Typically ad-hoc communication can be a distraction. We willing pay the price for the distractions because we get value of those discussions. They are relevant for people because they touch the matter of the project they run. Well, as long as it is about the project they run. That isn’t necessarily true if a team run a few projects.

Finally, there are situations when people would change the context of the project even if we don’t plan they would. What happens when someone is stuck? They’d ask for help. Whom? The person who is likely to help them. Does it mean only people from the same project? Not really.

Obviously we’d get some of that even if a team works on a single endeavor, but such cross-team interactions are usually way less frequent, thus way less costly, than those within the team.

This is sort of a gray area that is often forgotten even in organizations that are aware of the cost of multitasking. This is one of the reasons why visualization of project portfolio is so important. Each case where a team is coping with a few different projects or products at the same time should at least spring a discussion, as this is an obvious inefficiency.

Multitasking on a team level is no less painful than on any other.

in project management, team management
0 comments

Estimation Quality

Estimation Quality post image

OK, so I am on yet another agile event. I’m sitting there in the last row and a guy on the stage starts covering estimation. That’s interesting, I think, maybe I’ll learn something. After all estimation is something that bothers me these days.

Planning poker, here it comes. Yawn. People would pull the card with their estimate, yadda, yadda, yadda, they’d discuss and agree on a story point value. Yawn. The distribution of estimates would be normal.

Wait, now the guy has my attention.

So apparently he knows the distribution of the estimates. Good. How about checking what the distribution of lead times for historical data is. Because, you know, there are people who have done that, like Troy Magennis, and it seems that this distribution isn’t normal (Troy proposes Weibull distribution as the closest approximation).

In short: if your estimates have a different distribution than historical data for the tasks that the team has completed the estimates are crap.

Back to the presentation. The guy points how estimates for big tasks are useless in his context. Well, yes, they are. All the estimates in his context are crap from what I can tell. Then he points that we should be splitting tasks to smaller ones so planning poker makes sense and produce more reasonable estimates.

Um, sorry sir, but you got it wrong. If you are using estimates that are distributed differently than historical lead times you are overly optimistic, ignorant, or both.

How about this: I will not poke you in the eye with my pen but you will check the distribution of the estimates and the past lead times. Then you will recall some basic stuff from statistics course and stop selling crap that we can’t possibly answer the question: “when will it be done?”

OK, rant aside. I don’t say that coming up with the idea how long it will take to build something is easy. Far from that. I just say that there are pretty simple things that can be done to verify and improve the quality of the estimates.

Once you got the estimates look at their distribution. If it is different than what you know of historical data (because you’ve checked historical data, haven’t you?) the estimates don’t bear much of value.

In fact, you can do better. Once you know the distribution of historical lead times you may use that to model estimates for a new project. You don’t really need much more than simply basic work break down. You can take the worst case scenario from the past data and assume the best case scenario is 0 days and let the math do its magic. No guesswork whatsoever needed.

The credit for this post should go to Troy Magennis, who opened my eyes to how much use we can make out of limited data we have at our hands.

in project management
0 comments

5-Minute Board Test

5-Minute Board Test post image

I discuss different Kanban boards or task boards with their teams pretty often. It’s not uncommon for me to see a board of a team that I know nothing of. I like these moments. I typically challenge myself to make sense out the visualization as I stare at it.

Some parts are rather obvious. Typically the process isn’t that difficult to figure out. Usually I can tell who is working on what at a glance too. On the other hand something that should be obvious, but often isn’t, are classes of service – what they are and which items are of which class. And then there are lots of small different artifacts like blockers, comments, subtasks and what have you. Those do require some additional explanations.

One of common sins of teams adopting Kanban is making visualization too complex. We do say visualize everything, but obviously it means “as long as it adds value.” Boards tend to get more and more complex over time as we typically want to track more information as we understand better how the work gets done. We really don’t need to complicate things more than necessary on the day one.

So what makes a board a good one? The board is good when it does its job as an information radiator. This happens only when it is easy to comprehend and understand for the team members.

This is a core of my 5-minute test to verify whether the board is designed well. The test is simple.

A random team member should describe what is happening on the board to an outsider – someone who neither is a part of the team nor works with it regularly. If the outsider has any questions about specific things in the board they should ask and get the answers from the team member. The whole activity is time boxed to 5 minutes (thus the name).

The board passes the test if at the end of the task the outsider can tell what exactly is happening in the team: who works on what, what are the problems (if any), what is the progress of work, how the team knows what to do, etc.

One could argue that for bigger, more complex boards 5 minutes is not enough. I don’t agree. When we are interacting with the boards we rarely have more than just a couple of minutes. Of course team members would know part of the design without any explanation. That is why I’m giving an outsider full 5 minutes.

The more stuff there is to take into consideration when making routine, atomic, everyday project decisions the bigger the chance someone would misinterpret part of that. That’s the point where understanding the board, and the process, isn’t fully shared across the team anymore. That’s the point where people start acting differently despite identical input.

This is exactly the problem we tried to address when introducing information radiators in the first place. If the board doesn’t solve that problem it simply doesn’t work.

Would your Kanban or task board pass the 5-minute test?

in kanban, project management
0 comments