≡ Menu

Pawel Brodzinski on Software Project Management

Hyperproductivity Myth

Hyperproductivity Myth post image

If you are in broadly understood context of Agile you eventually has had to hear about being hyperproductive. Sources reporting a few hundred, or even as much as more than a thousand, percent productivity improvement aren’t unusual. In fact, 200% improvement seems to be “guaranteed” by some.

That’s great! Good for them! They’re going to get hyperproductivity badge or something. Yay!

What Hyperproductivity Is

Let’s start with the basics though. What is this whole thing? When a team becomes hyperproductive? How much do they have to improve? Oh, and by the way, if a super-crappy team improves three times and guys that were already great only by 20% would that mean that hyperproductivity was reached by the former, the latter, or both?

The most common metric I hear about in the context of hyperproductivity is velocity. Actually, I consider using velocity to measure productivity evil or dumb. How much should my team improve? By the factor of three? Nothing easier. Oh, and by the way, we don’t use our estimation poker card worth 1 that often anymore.

Note: I don’t deny teams improve. I merely point that stating so purely on a basis of velocity improvement is naive at best. There are so many potential dysfunctions of such approach that I don’t even know where to start. How the scope of work is split into individual tasks? What is a distribution of point estimates? How has it changed over time? What do we understand as a task in the first place? How do we account for rework?

In other words without understanding a specific context mentioning hyperproductivity is meaningless. Just a marketing fad, which it might have been in the first place.

Efficiency As a Goal

Even if we agreed on a reasonable proxy for measuring productivity there’s a bigger problem ahead. We are not in a business of writing most code, delivering most features or achieving best velocity. If you think you are, go talk to your clients, but this time try to actually listen to them.

If you spend about 5 minutes looking for sources pointing how notorious software industry is in not building the right stuff you may change your mind. Is a half of the stuff we build utterly useless? How about two third? Oh, and by the way the rise of the methods that are literally aimed to avoid building things unless we know we’re going to need them tells a story as well.

So yeah, focus purely on productivity and you’re going to achieve your goal:

Processing waste more effectively is cheaper, neater, faster waste.

Stephen Parry

The most painful problem of software industry is not efficiency. If it was, we’d already be in haven, given how much easier it is to build a software app these days than it was a couple decades ago. The problem is we are building wrong stuff.

We may as well be efficient, but unless we are effective in the first place, i.e. doing the right thing, there’s no glory waiting for us.

How We Create Value

This brings me to the utter failure of pursuing hyperproductivity. Let’s (safely) assume that our goal is to deliver value to our clients. We do that by building stuff. Except the value almost never is clearly defined. In almost every case software development is a knowledge discovery process.

This has some serious consequences. If we go by this assumption we may take all the functional specifications with a tongue in a cheek. It’s just a sketch of a map and most of the time not even an accurate sketch. This also means that amount of artifacts, like code, features, etc., we produce is not nearly as important as figuring out where exactly the value is, which bits and pieces we should build and which should be ignored.

This happens when we discuss the features, look for solutions, research options, prototype, A/B test, change stuff back and forth to see what works. This happens when we don’t score on velocity or any other productivity metric.

But wait, to become hyperproductive we should rather avoid that…

That’s exactly why I don’t give a damn about hyperproductivity.

I use to say software development is a happiness industry. We thrive only as long as our clients are continuously happy. We don’t make them happy by delivering more stuff. We make them happy by delivering stuff that has value for them and their customers.

in software business
7 comments

Personal Ritual Dissent

Personal Ritual Dissent post image

If I got a dollar each time I heard someone mentioning that they’d like to get more feedback I would be filthy rich by now. Heck, if I got a dollar each time I personally said that I would still got a decent sum. Most of us do want and like to get feedback. Most of us would love to get more of that.

There’s obviously one thing to consider, which is what kind of feedback and received in what context is most useful for us. I’ve heard a lot of theories on that. One example is that we should always focus on positive or supportive feedback as people would improve their weaknesses subconsciously while they’re working on their strengths. Another is infamous feedback sandwich, which tells that each critical bit should but in the middle of two supportive ones. There are dozens of these.

On one hand there’s a bit of truth in each. On the other I call bullshit.

I don’t believe there’s a single, universal way of delivering and / or receiving feedback that works in majority of cases. Personally, while I like to hear positive feedback as it makes me feel good, I really learn when I get critical feedback. In fact, it doesn’t even have to be very constructive or factual feedback; I typically can make much sense out of non-constructive opinions too. And I don’t give a damn whether you add a sandwich to the mix.

There are better ways of delivering feedback when we thank about an individual context but not in a general case. This means that the most useful feedback should be adjusted to the person who receives it. A nice thing is that we can tweak the situation so we get what works for us.

If you learn from feedback in a similar way that I do, meaning that critical feedback is what makes you change, the following part is for you.

I learned about the idea of ritual dissent some time ago. Back then I didn’t even know that it is Dave Snowden who should be attributed for creating it. Anyway, the basic idea is to create a situation where a group tears an idea apart looking for all the potential risks or holes. After a spokesperson presents an idea while everyone else remains silent, there’s a part when everyone dissents the idea while a spokesperson remains silent.

There may be two goals in doing that. One is obviously improving the idea itself by making it risk-proof. The other part is that ritual dissent can be treated as a listening exercise. It’s not that easy to remain silent when someone disses your idea. At the same time this is what differentiates it from a futile discussion full of personal opinions.

So here’s an idea: if you look for critical feedback you can use the same pattern in a personal context.

No, it’s not a theoretical idea. I’ve done that.

It hurt. A freaking lot.

And I got more of what I wanted in half an hour than over the course of past year.

And it was awesome. Once emotions wore out.

The thing is that adopting ritual dissent in personal context is, well, very personal. I was asking to be criticized. In fact, not-critical feedback was forbidden. No matter how much I learn from critical feedback it was nothing pleasant.

I would even consider that idea as “don’t try that at home” one unless one has self-awareness in terms of how they’re going to react for such critique. Having a psychologist around when doing that wouldn’t be a bad idea.

There are a couple things that make it work but two are essential. One is trust. I don’t say that everyone needs to fully trust a person being dissed. What is full trust anyway? However, there has be a decent level of trust so that anything that gets said won’t be used again anyone in any way. It may make the whole thing a bit tricky especially for managers or leaders where some sort of power relationship is involved.

At the same time there’s a lot of followership. Once a few people who feel safe start dissenting others join. Especially when they see that a dissented person doesn’t break the rules and keeps the mouth shut.

Another thing that makes personal ritual dissent work is listening, which is an inherent part of the exercise. It is a double-edged sword. On one hand the dissed person remains silent so the whole thing doesn’t turn into futile discussion. On the other the silence creates the pressure on the group. Someone eventually has to speak up even if it means going out of their comfort zone.

An interesting thing is that it’s nothing pleasant on either end. The exercise, which we run mid-day, was basically a killjoy. At the same time it spurred a lot of spin-off discussions afterwards, which is a reason why I wouldn’t do it at the very end of a day.

The best part is that getting critical feedback is not the ultimate value of the exercise. Since it creates a lot of tension and moves people out of the comfort zones it breaks some mental barriers that people had, thus makes sharing feedback later way easier.

After all sharing one critical opinion is nowhere close to dissing someone collectively for half an hour in a row.

Finally, some of feedback won’t be really addressed to the person who asked for a personal ritual dissent. It may be formulated in a way as it was so, but the real addressee would be somewhere else in a room and hopefully they’d get it too.

So if feeling like shit for (at least) a few hours is a price you’re willing to pay for a ton of valuable feedback, this is an idea for you. Would you dare?

in communication, personal development
4 comments

Unscaling Agile

Unscaling Agile post image

A theme of scaling Agile, or Lean for that matter, is all hot these days. You will hear it all sorts of contexts: as broad as Agile and as specific as one of the methods we use. No wonder. It sells.

You can tell that looking at tracks at Agile or Lean conferences. You can tell that looking at a rise of approaches that specifically aim at the big scale as their main target (SAFe, anyone?)

The interesting part of the whole dispute is how rarely we question scaling up strategy. I mean it seems to be some sort of unquestionable paradigm and when you decide to go against that everyone looks at you as you were an alien. I sometimes feel like rolling out a huge program to introduce Agile or Lean in the whole organization was the only thing there was for big companies.

How does it work for us so far? Not so well. We don’t have lots of success stories and those few that are available seem to be share at pretty much every Agile or Lean event there is. This tells a story about our success rates with scaling agile too.

Unscaling strategies are almost never mentioned in the dispute. It is so despite the fact that we actually know at least a couple of different approaches we can use there.

One is skunk works. The basic idea is to create a group within a company that operates pretty independently on the rest of the organization. This creates an opportunity to try out a lot of stuff that would be hard to implement in a broader context. At the same it creates an environment of much smaller scale.

Applying Lean Startup within a big organization goes along the same lines. On the top of a product development strategy we create a context of work that is autonomous and that operates in small scale.

Quite a different approach is when an organization decides to find a partner to outsource some of their work to. With such a situation one thing that is easily done is scaling the context down. A difficult part is to find a partner that would live be the right values and employ the right practices. But then again, it may be used as a viable unscaling strategy too.

Interestingly enough, such approaches are rare. One exception may be outsourcing. However, outsourcing done in a common way has nothing to do with scaling down and very frequently criteria used to choose an outsourcing partner only make the whole situation worse. Believe me, I’m actually in this business on a receiving end so I’ve heard all the motivations for sending the work near-shore or off-shore.

If you wonder why unscaling is so unpopular you aren’t going to be surprised with the answers. Either of these scenarios means losing control and that is something that management is generally allergic to. Also to make it work you need trust as high autonomy is one of key parts of the setup. Finally, there’s a risk of doing something not exactly in a standardized way which may produce unpredictable outcomes.

Have I just said between the lines that one of the main drivers of scaling up Agile and Lean is complacency? Oh well…

Anyway, unscaling strategy not only makes it much easier to adopt Lean or Agile but at the same time it enables fresh ideas as many constraints are typically relieved. Not to mention that it goes along the lines of autonomy, mastery and purpose which drives individual motivation.

So the next time you hear about scaling Agile why not consider unscaling it?

in project management, software business
9 comments

Why Your Change Program Will Fail

Why Your Change Program Will Fail post image

Most change initiatives fail. How many of them? Well, let’s see.

In 1995, John Kotter published research that revealed only 30 percent of change programs are successful. Fast forward to 2008. A recent McKinsey & Company survey of business executives indicates that the percent of change programs that are a success today is… still 30%

This is from a McKinsey report. How about different sources?

According to international management consultants Bain & Co, 70 to 90 per cent of organizational change initiatives fail.

Now, obviously these statistics receive some criticism. After all, what is a change initiative? What is a success? My point is that what we see is that in different context we suck big time at improving how we work.

What’s more we are not improving really. Over the course of past 15 years we’ve seen a huge rise of the methods and approaches that are specifically aimed toward driving the change management.

Agile proposed a neat value container quickly filled with specific methods that should change and improve the way we work. Lean offered a thinking pattern focused on continuous improvements. Both are more and more frequently considered table stakes than game changers. Why nothing is changing then?

First, let me make a bold observation: neither Agile nor Lean seem to be making a difference. In fact, that’s not only my observation. Daniel Mezick points that:

If current approaches actually worked well, then by now, thousands of organizations would have reached a state of self-sustaining, “freestanding” agility.

We have to be doing something wrong. Dave Nicolette offers some ideas what that might be. Anyway with such a wild popularity of Agile and Lean we should expect to do better than that. The problem is that most of the time we don’t even try to understand what made them work in the first place.

That’s a sad observation, but most of the time when I hear an Agile or Lean experience report it simply covers methods, practices and tools. The problem is that neither of these is pivotal in any change initiative. Basically, adopting practices and tools is simply a cargo cult. That’s not going to work unless there’s something more, the same way as it didn’t work for the Pacific tribes after the World War II.

In agile context we often mention values as the missing bit. I sort of agree with that. Sort of because the way Agile Manifesto is formulated it creates false dichotomies, yet it points us the right direction.

There’s a problem with values though. You don’t introduce values simply stating that you have them. You don’t incept them through mission statements and stuff. By the way, do any of you know value statement of your org by heart? Values are derivative of everyone’s behaviors and attitudes, thus they are a result of organizational culture.

There’s one more layer to that. Values can’t be inconsistent with the culture. Otherwise authenticity is gone and your claims about values have little to do with reality.

In other words a company can’t adopt Agile Manifesto simply by stating so. Not a surprise that change initiatives around Agile so frequently boil down to methods and tools. Not a surprise they fail at a high rate.

We see the same story with Lean as well. The bits that get traction are tools and techniques. It is so often when I see teams acting like limiting work in process, doing Gemba walks and having Kaizen boards was everything there was to improve continuously.

It’s not going to fly, sorry. We are back to organizational culture and everyone’s everyday behaviors. What do people do when they see an issue? Do they feel empowered to do whatever the hell they believe is the right thing to do to fix that issue? Do they even know what is the ultimate value they produce so they get good guidance on what is an issue in the first place?

These behaviors tell a lot about the culture. Unfortunately most of the time answers for the questions above suggest that there’s no freaking chance to make the tools work the way we intend them to. Typically we see over-constrained, siloed organizations where one neither knows what is the right thing to do nor has courage to go beyond the constraints.

I keep getting flak for bringing this up over and over again but I will do it once more.

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

Grace Hopper

Grace Hopper’s famous words are, in my opinion, the essence of the bit we are missing when introducing Lean or Agile to our organizations. That very bit is responsible for the appalling rate of success of change initiatives.

You can have all the hot tools and practices in place but when your people are driven by fear of consequences of their actions nothing will change. “Fear” may sound harsh but that’s what it is. It doesn’t mean that changing status quo by a tiny bit scares the crap out of me. It’s enough that I start thinking about potential consequences, what my bosses would think about that and whether they would even be happy. This is fear too.

When I think about the situation from a perspective of my experience as a manager I’m not surprised. I mean, really, promoting this whole “don’t ask permission” attitude is going to backfire on you on occasions. What’s more it means giving up control. Even worse, it assumes trust. It assumes trust to everyone, not only to few trusted people. Now, this is a huge leap of faith management has to take.

If you are thinking about continuous improvement or making your change initiatives work start with this leap of faith. If you can’t make it work don’t bother with all the tools, methods, practices and stuff. It’ll be just a waste of time. And the best part is that to make this work leaders have to start with themselves.

Only then you can dream of influencing culture so that it supports the everyday acts of leadership on all levels. If you got it right you may actually start thinking about all the helpful stuff you can introduce to keep the changes running. In fact, it’s pretty likely that you won’t need so much guidance as lots of them will emerge.

Oh, and if you wonder whether that change among leaders and managers is easy, well, it involves lots of pain and suffering. It is against of what we’ve been (wrongfully) taught for years. Sorry.

in software business
1 comment

(Don’t) Change Your Job

(Don’t) Change Your Job post image

Few of us have comfort not to worry, or think, of changing a job ever again. If you’re not one of those few, this post is for you.

I have easily gone through way more than a hundred of exit interviews. No, it doesn’t mean that I changed job that many times. This means that so many people left my teams. Nothing to brag about, I guess. Anyway, if there’s a reason for leaving one’s job I’ve heard it. And I’ve heard it from a person who I knew and worked with for quite a while.

Obviously, more often than not I tried hard to keep people around and missed those who decided to leave. This wouldn’t make me an objective adviser at a time. However, from a perspective of time, once what had been about to happen already happened, I believe I can go beyond emotions and biases and be pretty objective.

There’s one thing that I noticed in my attitude when I talk to people about leaving. I feel and act differently when I try to keep on board someone who I believe may be making a good decision than in cases when I’m pretty sure they are making a mistake. While I don’t think any of you would find my feelings even mildly amusing, what is interesting is that my compass seems to be working surprisingly well.

So how the hell do I sense whether changing a job is a good idea or not?

It’s pretty much one thing. What’s more it sounds obvious. Surprisingly enough people very rarely follow the hunch.

It’s all about how values of an organization one is about to join are aligned with their own values.

Yup, that’s it.

I mean, seriously. Ask people what they value. It’s an individual thing so they’d come up with all sorts of stuff, like respect, safety, trust, transparency, challenges, health, happiness, authenticity, quality, learning, perspectives and whatnot. Interestingly, very, very few people I know would say “more money” and in such cases they’d likely have pretty good reason for that (which is fair enough too).

A nice thing is we can get pretty good hints whether these values are respected and embraced at our workplaces-to-be.

“You can’t know” one would say. Well, you can. It’s enough to realize one thing. Every publicly or semi-publicly known action of a company is emanation of how it operates inside. In other words if you want to know what is valued in any given org just pay attention to how that company acts publicly.

Are they worth of trust as a business partner? Why should they be as an employer? Do they care about well-being of their clients? Why should they care about yours? Do they respect any partner they work with? If not, why would you assume their respect would be extended to employees?

I don’t say that without a reason. It’s not a rare occasion when there’s a value match or at least there’s nothing that would indicate the opposite. At the same time I’ve seen way too many bad decisions ignoring the obvious hints. As you may guess it didn’t work very well.

So here’s my advice: ask yourself what is important for you. If an employer-to-be shares the key values with you then go for it. And yes, I do understand that I actually may be encouraging some of my people to look for alternatives. I don’t mind. After all, if I consider myself a leader I should care about well-being of my team, shouldn’t I?

At the same time if your employer-to-be doesn’t seem to share your values this is a single most powerful signal to take into consideration. It means that the whole setup would suck eventually.

And yes, it’s enough to look at, or ask about, relationships with partners or clients.

It’s all about values and you can’t lie about values. If you are fair to your partners you’re going to be fair to your employees. And vice versa.

Few people would take consider it when thinking about changing a job. Don’t be one of them.

in team management
1 comment

Why Kaizen Boards (Typically) Don’t Work

Why Kaizen Boards (Typically) Don’t Work post image

A Kaizen board is a neat concept. It’s a visual tool that keeps track of all the ideas for improvements gathered across a team and then helps to analyze the status of ongoing improvement experiments. What we get from using a Kaizen board is we encourage everyone to participate in improvement process, visualize ongoing and planned improvements and give ourselves some sort of a tracking mechanism.

That’s the theory.

In practice I haven’t seen such a board that would work well.

I don’t say it isn’t possible to make it work. I just say it’s unlikely.

To answer why I think so, I have to bring the old story repeated multiple times in the context of Lean. When Japanese started kicking Americans’ butts in automotive industry in the second part of twentieth century Americans sent their managers to see what’s so different in factories in Japan. Surprisingly enough Japanese were super-open and transparent with all the tools and practices they had in place. Americans meticulously noted all the novel stuff they learned and implemented the same tools and methods back home. Guess what. It didn’t work.

It didn’t work because all these practices weren’t really game changers. The real game changer was underlying mindset that actually made these tools and methods work. By the way, this was also a reason why sharing all the secrets about practices wasn’t a problem. They weren’t nearly enough to make a difference.

We pretty much recreate the same story when we try tools like Kaizen boards or when we create Kaizen teams. We introduce a tool and believe it will change the game. It won’t.

The magic behind thousands and thousands of improvements implemented in Toyota every year is not any of the tools. It is a culture that supports trying stuff out. It is mindset that enables that. All that continuous improvement is happening not because people submit improvement ideas to Kaizen boards but because people are actively experimenting. They do stuff.

If you tried using a Kaizen board this picture may be familiar. There was lots of stuff submitted to the board but very few, if any, real changes were observable in your working environment. Now ask yourself: what would it take for any team member to try something out. Would people need to get permission and a blessing before they changed the way they worked? And then, when the thing failed, would they need to explain or ask forgiveness? Would they feel that they were co-creating the system they were a part of?

In most organizations I know these answers would tell you why your Kaizen board or Kaizen team or Kaizen whatever doesn’t have a slightest chance to work. In fact, in such a situation a Kaizen board would just be a nice excuse. I’d had that awesome idea but it wasn’t accepted. I’d come up with that great improvement but there wasn’t time to implement it.

Except then you shouldn’t call it a Kaizen board but an excuse board.

And the best part is: if you have right mindset and the right culture in place a Kaizen board isn’t needed at all. People just run their improvement experiments. Of course some of them last and some of them don’t. Then you obviously can use a Kaizen board as a tracking and visualization tool. Unless you get there though – don’t bother.

in software business
6 comments

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