≡ Menu

I’ve been intrigued by the idea of self-guided retrospectives. Imagine motivated teams that could collect and evaluate data and reach valuable conclusions without management guidance!

It appealed to me in more ways than one – firstly, visit this to my principle of empowering teams wherever I can. It also suits my personality. I’m an introverted control-freak, apoplectic which means I risk manipulating situations even when I’d really rather not be involved at all. I’ve come across techniques by which teams could progress through a retrospective themselves, but I face the added complication that many of our projects have at least one remote team member, because our clients are usually in America or Western Europe. I seized on the idea that Kanbanery, our web-based project tracking tool, could be used to facilitate the kinds of interactions that lead to a valuable retrospective. Of course, the approach would work with any online kanban tool that provides live updates.

Our retrospectives with distributed teams were always very traditional, with either no interaction with physical objects (discussion only) or with a local proxy assisting remote participants. There’s value in collecting ideas on cards and manipulating them as a group, but I don’t like the necessity of treating remote team members differently.

Teams in Lunar Logic are using Kanbanery’s real-time updates features to collaborate effectively. Could we use the same familiar tools to hold a retrospective session? The answer came when I applied a TRIZ technique of reducing the environment to its bare essentials and asked what I had to work with within the constraints I set. If you’re of a more philosophical bent, you might say that I asked of Kanbanery: “What is this thing in itself?”

Kanbanery is intended to visualize the flow of work through a process but essentially it is just a series of lists of items which can be moved between columns, both horizontally and vertically.

Items have certain distinguishing features that help organize your work:

  1. A title field with a larger description field,
  2. The avatar of the last person that handled them,
  3. Checklists, type fields, and check marks just in case you need them.

as well as a variety of other features that weren’t required while preparing for a retrospective.

A Kanbanery-powered retrospective

Thinking of Kanbanery as a series of lists gave me the clue I needed to devise the retrospective exercise.

Newly created tasks appear in the first column, so I called it the ‘Working’ column. I labeled the next column ‘Retrospective Steps’ and in it I placed the instruction cards for conducting the retrospective. There are many methods of conducting a retrospective, but the most common is to collect data from team members about the recent history of the project, evaluate their answers, extract useful practices and discard those that were unhelpful and finally to choose a small set of those changes to implement in the next iteration. I created columns for each of these steps.

We used this process for our last Kanbanery retrospective, which I joined from home while I was ill. Here is how it works. The team members sit at laptops in a room together or in their own offices and start a live call via any teleconferencing system (we used Skype). Because of the shared Kanbanery board, all team members are equal and interact with it in the same way.

The team begins to work through the steps listed in the Retrospective Steps column:

  1. They set a timebox for the meeting and write it down in the title of the first card, so everyone knows when the meeting will end,
  2. Everybody reads and all agree to the retrospective prime directive,
  3. Team creates the project history by adding cards and dragging them into the History column in chronological order.

The advantage to using Kanbanery is immediately visible – everyone contributes in his or her own way and time without biasing others. Cards begin appearing like “Got our first paying user”, “Migrated to new test server”, and “Marcin joined the team”. The avatars show who added which tasks.

When the time is up, the team members use the checkmark feature to mark the events in the history that they feel good about. The team can talk over, point by point, any ambiguities during this stage.

Afterwards the team, with the history fresh in their minds, brainstorms about the useful practices that might be associated with the highlights of the recent history, about unhelpful practices that might have led to the pitfalls they faced, and to practices they’d like to consider adding or changing to make future iterations more effective. They do this in the same way in which they built the history, by creating cards with ideas in the Helpful and Unhelpful Practices column.

Next the team talks about the practices listed and agrees on three (or any other number) which they will change going forward and they drag these to the final column, What We Will or Will Not Do. The team can look at these decisions and clarify them in terms of how they will be implemented, by whom, and when. After reaching an agreement, they can capture these ideas by using Kanbanery’s “Export to PDF” function to print the decisions onto index cards easily put on the wall.

Though I participated in the retrospective as a remote member, not only was it a very focused and well-organized retrospective, but also I felt I was actively participating because I could create my own tickets in just the same way the other team members were. The meeting stayed on time, each phase was clear and moved us inexorably to useful conclusions.

Ideally, retrospectives are very interactive activities that take place with everyone in the same room, finding solutions and exposing truths hands-on with appropriate visual tools, but that’s not always possible in this day of remote work and global teams. Here’s a new technique to add to your remote development toolkit. Let us know how it works for you in the comments.
I’ve been intrigued by the idea of self-guided retrospectives. Imagine motivated teams that could collect and evaluate data and reach valuable conclusions without management guidance!

It appealed to me in more ways than one – firstly, visit this to my principle of empowering teams wherever I can. It also suits my personality. I’m an introverted control-freak, apoplectic which means I risk manipulating situations even when I’d really rather not be involved at all. I’ve come across techniques by which teams could progress through a retrospective themselves, but I face the added complication that many of our projects have at least one remote team member, because our clients are usually in America or Western Europe. I seized on the idea that Kanbanery, our web-based project tracking tool, could be used to facilitate the kinds of interactions that lead to a valuable retrospective. Of course, the approach would work with any online kanban tool that provides live updates.

Our retrospectives with distributed teams were always very traditional, with either no interaction with physical objects (discussion only) or with a local proxy assisting remote participants. There’s value in collecting ideas on cards and manipulating them as a group, but I don’t like the necessity of treating remote team members differently.

Teams in Lunar Logic are using Kanbanery’s real-time updates features to collaborate effectively. Could we use the same familiar tools to hold a retrospective session? The answer came when I applied a TRIZ technique of reducing the environment to its bare essentials and asked what I had to work with within the constraints I set. If you’re of a more philosophical bent, you might say that I asked of Kanbanery: “What is this thing in itself?”

Kanbanery is intended to visualize the flow of work through a process but essentially it is just a series of lists of items which can be moved between columns, both horizontally and vertically.

Items have certain distinguishing features that help organize your work:

  1. A title field with a larger description field,
  2. The avatar of the last person that handled them,
  3. Checklists, type fields, and check marks just in case you need them.

as well as a variety of other features that weren’t required while preparing for a retrospective.

A Kanbanery-powered retrospective

Thinking of Kanbanery as a series of lists gave me the clue I needed to devise the retrospective exercise.

Newly created tasks appear in the first column, so I called it the ‘Working’ column. I labeled the next column ‘Retrospective Steps’ and in it I placed the instruction cards for conducting the retrospective. There are many methods of conducting a retrospective, but the most common is to collect data from team members about the recent history of the project, evaluate their answers, extract useful practices and discard those that were unhelpful and finally to choose a small set of those changes to implement in the next iteration. I created columns for each of these steps.

We used this process for our last Kanbanery retrospective, which I joined from home while I was ill. Here is how it works. The team members sit at laptops in a room together or in their own offices and start a live call via any teleconferencing system (we used Skype). Because of the shared Kanbanery board, all team members are equal and interact with it in the same way.

The team begins to work through the steps listed in the Retrospective Steps column:

  1. They set a timebox for the meeting and write it down in the title of the first card, so everyone knows when the meeting will end,
  2. Everybody reads and all agree to the retrospective prime directive,
  3. Team creates the project history by adding cards and dragging them into the History column in chronological order.

The advantage to using Kanbanery is immediately visible – everyone contributes in his or her own way and time without biasing others. Cards begin appearing like “Got our first paying user”, “Migrated to new test server”, and “Marcin joined the team”. The avatars show who added which tasks.

When the time is up, the team members use the checkmark feature to mark the events in the history that they feel good about. The team can talk over, point by point, any ambiguities during this stage.

Afterwards the team, with the history fresh in their minds, brainstorms about the useful practices that might be associated with the highlights of the recent history, about unhelpful practices that might have led to the pitfalls they faced, and to practices they’d like to consider adding or changing to make future iterations more effective. They do this in the same way in which they built the history, by creating cards with ideas in the Helpful and Unhelpful Practices column.

Next the team talks about the practices listed and agrees on three (or any other number) which they will change going forward and they drag these to the final column, What We Will or Will Not Do. The team can look at these decisions and clarify them in terms of how they will be implemented, by whom, and when. After reaching an agreement, they can capture these ideas by using Kanbanery’s “Export to PDF” function to print the decisions onto index cards easily put on the wall.

Though I participated in the retrospective as a remote member, not only was it a very focused and well-organized retrospective, but also I felt I was actively participating because I could create my own tickets in just the same way the other team members were. The meeting stayed on time, each phase was clear and moved us inexorably to useful conclusions.

Ideally, retrospectives are very interactive activities that take place with everyone in the same room, finding solutions and exposing truths hands-on with appropriate visual tools, but that’s not always possible in this day of remote work and global teams. Here’s a new technique to add to your remote development toolkit. Let us know how it works for you in the comments.
My most re-tweeted Tweet ever: “Software clients want to pay by unit of value. Programers want to be paid by unit of effort. Buying and selling hours accomplishes neither.” Perhaps it’s worth a bit of exploration. I warn you, valeologist this is a stream-of-consciousness piece that I hope will stimulate creative thinking rather than a final solution to the problem.

albatrossI own a web development shop. Our business model works like nearly every other web development shop in the world. Our clients pay for developers’ time. We pay our developers for their time. That’s fair only in the sense that it’s apples to apples. Unfortunately, here the apples aren’t what anyone is interested in. The problem is that no one wants to buy and sell time, really. Our clients want solutions to problems that they consider valuable. If they had their way, they’d have a flexible model whereby they could incrementally buy valuable things (features?) and pay less for each unit of value than they can get for it from their clients/investors/users. In their ideal world, they’d calculate that if they had feature X, then their revenues would grow by $Y and so they’d be happy to pay f($Y) to get that feature.

Programmers, at least the ones I’ve worked with, want one of two things, or perhaps a bit of both. They want freedom to work creatively with good people on interesting and world-changing projects with compensation for the value of their skills (not of their time, effort, or contribution). Alternatively, or in a strange dichotomy that must cause no small amount of cognitive dissonance, they want to clock in and do what they’re told with minimal responsibility for outcomes for a certain number of hours and then get back to their real lives and personal projects.

As an employer, I can say that a big constraint to finding a creative pricing model is labor law. While it is possible as an employer to tell someone “your work today was more valuable then expected, so here’s a bonus” it’s not legal to say “you didn’t bring your ‘A’game today and so you’re getting less then your contractual salary.”

Another crucial consideration is the motivations of the players. In the case of an outsourcing firm like mine, we have three groups of players. Our clients don’t mind paying money, because they have expectations of earning a handsome return on their investment. They know the risk is high, but expect the rewards to justify that risk. However, their returns, if they materialize, are in the distant future and their costs are in the present, and that makes a difference. Then there’s me. I’m odd for an entrepreneur, in that I have no desire to be wealthy. I was born and raised middle class. I have middle class tastes and I like to keep life simple. I do, however, require a positive return, or I can’t have fun owning a software company for long. So I’m looking for stable cash flows. Then there are the developers, who are younger than me, just getting started in their professional lives. I’m old enough to say that even of the folks who have been with me nearly a decade. They want a good job and a stable income. They are pretty risk averse, especially the newlyweds who have just financed a home, so they’ll forgo the promise of riches for a paycheck every month.

Now, how do you make cash flow down this pipeline of divergent needs, interests, and risk thresholds in a way that makes everyone happy?

If everyone got exactly what they most wanted, wise entrepreneurs would pay a high fixed price for the output of top talent, the talent would have control over when and how they worked and would trade some cash flow stability for that freedom so long as their needs were met, and talent brokers like me would do what brokers do — nip a safe and modest profit from the money flowing through our talentless hands.

If we were all the same, with the same needs and interests, the model would be easy. If we all had high risk-tolerances and dreamt of early retirement on a private island I’d run the company as a partnership that works for equity. We’d decide as a team whether to invest our time into a client’s project. No cash would change hands (until the exit/IPO makes us all rich) and we all would sink or swim together. That would be fair to all and perfectly in line with labor codes.

That got me thinking. Perhaps other fair models may follow the same pattern in which the terms of agreement are the same between all three parties. For example, what if projects or bits of projects had fixed prices? That wouldn’t be a problem, economically, if the developers agreed to deliver for a fixed amount. But in that model, all the estimation risk is pushed downhill, which hardly seems fair the the developers. However, recalling that the entrepreneurs expect high returns for their risk and in my experience are willing to pay for top talent, the price per unit of value delivered might be high enough to justify the risk. The client would always get what she wants for the price she wants. I would always make exactly the small margins I require to cover costs and fund growth. The developers would lose when unexpected variation consumed more of their effort than they could have expected, but they’d win when the opposite happened. The most efficient, the hardest-working, and the ones who learned to “pick winners” in the sense that they develop a keen eye for low-effort/high return work would fare well. Likewise, developers could adjust to their changing needs – taking easy money when they needed money and interesting work when they needed a challenge. If no one wanted a task or project, that would be a good market indicator that the offer was too low. I doubt that there is a labor market for such a prospect, but I’d be curious to see it tried.

The reality is that talent costs rise so much faster than inflation that companies like mine do one of three things: build a product or products to augment the margins slipping from the top line to the payroll line of the income statement, get large and offset lower margins with volume at the cost of quality, or fail. Most fail. These strategies are all patches to an inappropriate business model.

There’s got to be a better way.
I’ve been intrigued by the idea of self-guided retrospectives. Imagine motivated teams that could collect and evaluate data and reach valuable conclusions without management guidance!

It appealed to me in more ways than one – firstly, visit this to my principle of empowering teams wherever I can. It also suits my personality. I’m an introverted control-freak, apoplectic which means I risk manipulating situations even when I’d really rather not be involved at all. I’ve come across techniques by which teams could progress through a retrospective themselves, but I face the added complication that many of our projects have at least one remote team member, because our clients are usually in America or Western Europe. I seized on the idea that Kanbanery, our web-based project tracking tool, could be used to facilitate the kinds of interactions that lead to a valuable retrospective. Of course, the approach would work with any online kanban tool that provides live updates.

Our retrospectives with distributed teams were always very traditional, with either no interaction with physical objects (discussion only) or with a local proxy assisting remote participants. There’s value in collecting ideas on cards and manipulating them as a group, but I don’t like the necessity of treating remote team members differently.

Teams in Lunar Logic are using Kanbanery’s real-time updates features to collaborate effectively. Could we use the same familiar tools to hold a retrospective session? The answer came when I applied a TRIZ technique of reducing the environment to its bare essentials and asked what I had to work with within the constraints I set. If you’re of a more philosophical bent, you might say that I asked of Kanbanery: “What is this thing in itself?”

Kanbanery is intended to visualize the flow of work through a process but essentially it is just a series of lists of items which can be moved between columns, both horizontally and vertically.

Items have certain distinguishing features that help organize your work:

  1. A title field with a larger description field,
  2. The avatar of the last person that handled them,
  3. Checklists, type fields, and check marks just in case you need them.

as well as a variety of other features that weren’t required while preparing for a retrospective.

A Kanbanery-powered retrospective

Thinking of Kanbanery as a series of lists gave me the clue I needed to devise the retrospective exercise.

Newly created tasks appear in the first column, so I called it the ‘Working’ column. I labeled the next column ‘Retrospective Steps’ and in it I placed the instruction cards for conducting the retrospective. There are many methods of conducting a retrospective, but the most common is to collect data from team members about the recent history of the project, evaluate their answers, extract useful practices and discard those that were unhelpful and finally to choose a small set of those changes to implement in the next iteration. I created columns for each of these steps.

We used this process for our last Kanbanery retrospective, which I joined from home while I was ill. Here is how it works. The team members sit at laptops in a room together or in their own offices and start a live call via any teleconferencing system (we used Skype). Because of the shared Kanbanery board, all team members are equal and interact with it in the same way.

The team begins to work through the steps listed in the Retrospective Steps column:

  1. They set a timebox for the meeting and write it down in the title of the first card, so everyone knows when the meeting will end,
  2. Everybody reads and all agree to the retrospective prime directive,
  3. Team creates the project history by adding cards and dragging them into the History column in chronological order.

The advantage to using Kanbanery is immediately visible – everyone contributes in his or her own way and time without biasing others. Cards begin appearing like “Got our first paying user”, “Migrated to new test server”, and “Marcin joined the team”. The avatars show who added which tasks.

When the time is up, the team members use the checkmark feature to mark the events in the history that they feel good about. The team can talk over, point by point, any ambiguities during this stage.

Afterwards the team, with the history fresh in their minds, brainstorms about the useful practices that might be associated with the highlights of the recent history, about unhelpful practices that might have led to the pitfalls they faced, and to practices they’d like to consider adding or changing to make future iterations more effective. They do this in the same way in which they built the history, by creating cards with ideas in the Helpful and Unhelpful Practices column.

Next the team talks about the practices listed and agrees on three (or any other number) which they will change going forward and they drag these to the final column, What We Will or Will Not Do. The team can look at these decisions and clarify them in terms of how they will be implemented, by whom, and when. After reaching an agreement, they can capture these ideas by using Kanbanery’s “Export to PDF” function to print the decisions onto index cards easily put on the wall.

Though I participated in the retrospective as a remote member, not only was it a very focused and well-organized retrospective, but also I felt I was actively participating because I could create my own tickets in just the same way the other team members were. The meeting stayed on time, each phase was clear and moved us inexorably to useful conclusions.

Ideally, retrospectives are very interactive activities that take place with everyone in the same room, finding solutions and exposing truths hands-on with appropriate visual tools, but that’s not always possible in this day of remote work and global teams. Here’s a new technique to add to your remote development toolkit. Let us know how it works for you in the comments.
My most re-tweeted Tweet ever: “Software clients want to pay by unit of value. Programers want to be paid by unit of effort. Buying and selling hours accomplishes neither.” Perhaps it’s worth a bit of exploration. I warn you, valeologist this is a stream-of-consciousness piece that I hope will stimulate creative thinking rather than a final solution to the problem.

albatrossI own a web development shop. Our business model works like nearly every other web development shop in the world. Our clients pay for developers’ time. We pay our developers for their time. That’s fair only in the sense that it’s apples to apples. Unfortunately, here the apples aren’t what anyone is interested in. The problem is that no one wants to buy and sell time, really. Our clients want solutions to problems that they consider valuable. If they had their way, they’d have a flexible model whereby they could incrementally buy valuable things (features?) and pay less for each unit of value than they can get for it from their clients/investors/users. In their ideal world, they’d calculate that if they had feature X, then their revenues would grow by $Y and so they’d be happy to pay f($Y) to get that feature.

Programmers, at least the ones I’ve worked with, want one of two things, or perhaps a bit of both. They want freedom to work creatively with good people on interesting and world-changing projects with compensation for the value of their skills (not of their time, effort, or contribution). Alternatively, or in a strange dichotomy that must cause no small amount of cognitive dissonance, they want to clock in and do what they’re told with minimal responsibility for outcomes for a certain number of hours and then get back to their real lives and personal projects.

As an employer, I can say that a big constraint to finding a creative pricing model is labor law. While it is possible as an employer to tell someone “your work today was more valuable then expected, so here’s a bonus” it’s not legal to say “you didn’t bring your ‘A’game today and so you’re getting less then your contractual salary.”

Another crucial consideration is the motivations of the players. In the case of an outsourcing firm like mine, we have three groups of players. Our clients don’t mind paying money, because they have expectations of earning a handsome return on their investment. They know the risk is high, but expect the rewards to justify that risk. However, their returns, if they materialize, are in the distant future and their costs are in the present, and that makes a difference. Then there’s me. I’m odd for an entrepreneur, in that I have no desire to be wealthy. I was born and raised middle class. I have middle class tastes and I like to keep life simple. I do, however, require a positive return, or I can’t have fun owning a software company for long. So I’m looking for stable cash flows. Then there are the developers, who are younger than me, just getting started in their professional lives. I’m old enough to say that even of the folks who have been with me nearly a decade. They want a good job and a stable income. They are pretty risk averse, especially the newlyweds who have just financed a home, so they’ll forgo the promise of riches for a paycheck every month.

Now, how do you make cash flow down this pipeline of divergent needs, interests, and risk thresholds in a way that makes everyone happy?

If everyone got exactly what they most wanted, wise entrepreneurs would pay a high fixed price for the output of top talent, the talent would have control over when and how they worked and would trade some cash flow stability for that freedom so long as their needs were met, and talent brokers like me would do what brokers do — nip a safe and modest profit from the money flowing through our talentless hands.

If we were all the same, with the same needs and interests, the model would be easy. If we all had high risk-tolerances and dreamt of early retirement on a private island I’d run the company as a partnership that works for equity. We’d decide as a team whether to invest our time into a client’s project. No cash would change hands (until the exit/IPO makes us all rich) and we all would sink or swim together. That would be fair to all and perfectly in line with labor codes.

That got me thinking. Perhaps other fair models may follow the same pattern in which the terms of agreement are the same between all three parties. For example, what if projects or bits of projects had fixed prices? That wouldn’t be a problem, economically, if the developers agreed to deliver for a fixed amount. But in that model, all the estimation risk is pushed downhill, which hardly seems fair the the developers. However, recalling that the entrepreneurs expect high returns for their risk and in my experience are willing to pay for top talent, the price per unit of value delivered might be high enough to justify the risk. The client would always get what she wants for the price she wants. I would always make exactly the small margins I require to cover costs and fund growth. The developers would lose when unexpected variation consumed more of their effort than they could have expected, but they’d win when the opposite happened. The most efficient, the hardest-working, and the ones who learned to “pick winners” in the sense that they develop a keen eye for low-effort/high return work would fare well. Likewise, developers could adjust to their changing needs – taking easy money when they needed money and interesting work when they needed a challenge. If no one wanted a task or project, that would be a good market indicator that the offer was too low. I doubt that there is a labor market for such a prospect, but I’d be curious to see it tried.

The reality is that talent costs rise so much faster than inflation that companies like mine do one of three things: build a product or products to augment the margins slipping from the top line to the payroll line of the income statement, get large and offset lower margins with volume at the cost of quality, or fail. Most fail. These strategies are all patches to an inappropriate business model.

There’s got to be a better way.
My most re-tweeted Tweet ever: “Software clients want to pay by unit of value. Programers want to be paid by unit of effort. Buying and selling hours accomplishes neither.” Perhaps it’s worth a bit of exploration. I warn you, click this is a stream-of-consciousness piece that I hope will stimulate creative thinking rather than provide a solution to the problem.

albatrossI own a web development shop. Our business model works like nearly every other web development shop in the world. Our clients pay for developers’ time. We pay our developers for their time. That’s fair only in the sense that it’s apples to apples. Unfortunately, sick the apples aren’t what anyone is interested in. The problem is that no one wants to buy and sell time, diagnosis really. Our clients want solutions to problems that they consider valuable. If they had their way, they’d have a flexible model whereby they could incrementally buy valuable things (features?) and pay less for each unit of value than they can get for it from their clients/investors/users. In their ideal world, they’d calculate that if they had feature X, then their revenues would grow by $Y and so they’d be happy to pay f($Y) to get that feature.

Programmers, at least the ones I’ve worked with, want one of two things, or perhaps a bit of both. They want freedom to work creatively with good people on interesting and world-changing projects with compensation for the value of their skills (not of their time, effort, or contribution). Alternatively, or in a strange dichotomy that must cause no small amount of cognitive dissonance, they want to clock in and do what they’re told with minimal responsibility for outcomes for a certain number of hours and then get back to their real lives and personal projects.

As an employer, I can say that a big constraint to finding a creative pricing model is labor law. While it is possible as an employer to tell someone “your work today was more valuable then expected, so here’s a bonus” it’s not legal to say “you didn’t bring your ‘A’game today and so you’re getting less then your contractual salary.”

Another crucial consideration is the motivations of the players. In the case of an outsourcing firm like mine, we have three groups of players. Our clients don’t mind paying money, because they have expectations of earning a handsome return on their investment. They know the risk is high, but expect the rewards to justify that risk. However, their returns, if they materialize, are in the distant future and their costs are in the present, and that makes a difference. Then there’s me. I’m odd for an entrepreneur, in that I have no desire to be wealthy. I was born and raised middle class. I have middle class tastes and I like to keep life simple. I do, however, require a positive return, or I can’t have fun owning a software company for long. So I’m looking for stable cash flows. Then there are the developers, who are younger than me, just getting started in their professional lives. I’m old enough to say that even of the folks who have been with me nearly a decade. They want a good job and a stable income. They are pretty risk averse, especially the newlyweds who have just financed a home, so they’ll forgo the promise of riches for a paycheck every month.

Now, how do you make cash flow down this pipeline of divergent needs, interests, and risk thresholds in a way that makes everyone happy?

If everyone got exactly what they most wanted, wise entrepreneurs would pay a high fixed price for the output of top talent, the talent would have control over when and how they worked and would trade some cash flow stability for that freedom so long as their needs were met, and talent brokers like me would do what brokers do — nip a safe and modest profit from the money flowing through our talentless hands.

If we were all the same, with the same needs and interests, the model would be easy. If we all had high risk-tolerances and dreamt of early retirement on a private island I’d run the company as a partnership that works for equity. We’d decide as a team whether to invest our time into a client’s project. No cash would change hands (until the exit/IPO makes us all rich) and we all would sink or swim together. That would be fair to all and perfectly in line with labor codes.

That got me thinking. Perhaps other fair models may follow the same pattern in which the terms of agreement are the same between all three parties. For example, what if projects or bits of projects had fixed prices? That wouldn’t be a problem, economically, if the developers agreed to deliver for a fixed amount. But in that model, all the estimation risk is pushed downhill, which hardly seems fair the the developers. However, recalling that the entrepreneurs expect high returns for their risk and in my experience are willing to pay for top talent, the price per unit of value delivered might be high enough to justify the risk. The client would always get what she wants for the price she wants. I would always make exactly the small margins I require to cover costs and fund growth. The developers would lose when unexpected variation consumed more of their effort than they could have expected, but they’d win when the opposite happened. The most efficient, the hardest-working, and the ones who learned to “pick winners” in the sense that they develop a keen eye for low-effort/high return work would fare well. Likewise, developers could adjust to their changing needs – taking easy money when they needed money and interesting work when they needed a challenge. If no one wanted a task or project, that would be a good market indicator that the offer was too low. I doubt that there is a labor market for such a prospect, but I’d be curious to see it tried.

The reality is that talent costs rise so much faster than inflation that companies like mine do one of three things: build a product or products to augment the margins slipping from the top line to the payroll line of the income statement, get large and offset lower margins with volume at the cost of quality, or fail. Most fail. These strategies are all patches to an inappropriate business model.

There’s got to be a better way.
I’ve been intrigued by the idea of self-guided retrospectives. Imagine motivated teams that could collect and evaluate data and reach valuable conclusions without management guidance!

It appealed to me in more ways than one – firstly, visit this to my principle of empowering teams wherever I can. It also suits my personality. I’m an introverted control-freak, apoplectic which means I risk manipulating situations even when I’d really rather not be involved at all. I’ve come across techniques by which teams could progress through a retrospective themselves, but I face the added complication that many of our projects have at least one remote team member, because our clients are usually in America or Western Europe. I seized on the idea that Kanbanery, our web-based project tracking tool, could be used to facilitate the kinds of interactions that lead to a valuable retrospective. Of course, the approach would work with any online kanban tool that provides live updates.

Our retrospectives with distributed teams were always very traditional, with either no interaction with physical objects (discussion only) or with a local proxy assisting remote participants. There’s value in collecting ideas on cards and manipulating them as a group, but I don’t like the necessity of treating remote team members differently.

Teams in Lunar Logic are using Kanbanery’s real-time updates features to collaborate effectively. Could we use the same familiar tools to hold a retrospective session? The answer came when I applied a TRIZ technique of reducing the environment to its bare essentials and asked what I had to work with within the constraints I set. If you’re of a more philosophical bent, you might say that I asked of Kanbanery: “What is this thing in itself?”

Kanbanery is intended to visualize the flow of work through a process but essentially it is just a series of lists of items which can be moved between columns, both horizontally and vertically.

Items have certain distinguishing features that help organize your work:

  1. A title field with a larger description field,
  2. The avatar of the last person that handled them,
  3. Checklists, type fields, and check marks just in case you need them.

as well as a variety of other features that weren’t required while preparing for a retrospective.

A Kanbanery-powered retrospective

Thinking of Kanbanery as a series of lists gave me the clue I needed to devise the retrospective exercise.

Newly created tasks appear in the first column, so I called it the ‘Working’ column. I labeled the next column ‘Retrospective Steps’ and in it I placed the instruction cards for conducting the retrospective. There are many methods of conducting a retrospective, but the most common is to collect data from team members about the recent history of the project, evaluate their answers, extract useful practices and discard those that were unhelpful and finally to choose a small set of those changes to implement in the next iteration. I created columns for each of these steps.

We used this process for our last Kanbanery retrospective, which I joined from home while I was ill. Here is how it works. The team members sit at laptops in a room together or in their own offices and start a live call via any teleconferencing system (we used Skype). Because of the shared Kanbanery board, all team members are equal and interact with it in the same way.

The team begins to work through the steps listed in the Retrospective Steps column:

  1. They set a timebox for the meeting and write it down in the title of the first card, so everyone knows when the meeting will end,
  2. Everybody reads and all agree to the retrospective prime directive,
  3. Team creates the project history by adding cards and dragging them into the History column in chronological order.

The advantage to using Kanbanery is immediately visible – everyone contributes in his or her own way and time without biasing others. Cards begin appearing like “Got our first paying user”, “Migrated to new test server”, and “Marcin joined the team”. The avatars show who added which tasks.

When the time is up, the team members use the checkmark feature to mark the events in the history that they feel good about. The team can talk over, point by point, any ambiguities during this stage.

Afterwards the team, with the history fresh in their minds, brainstorms about the useful practices that might be associated with the highlights of the recent history, about unhelpful practices that might have led to the pitfalls they faced, and to practices they’d like to consider adding or changing to make future iterations more effective. They do this in the same way in which they built the history, by creating cards with ideas in the Helpful and Unhelpful Practices column.

Next the team talks about the practices listed and agrees on three (or any other number) which they will change going forward and they drag these to the final column, What We Will or Will Not Do. The team can look at these decisions and clarify them in terms of how they will be implemented, by whom, and when. After reaching an agreement, they can capture these ideas by using Kanbanery’s “Export to PDF” function to print the decisions onto index cards easily put on the wall.

Though I participated in the retrospective as a remote member, not only was it a very focused and well-organized retrospective, but also I felt I was actively participating because I could create my own tickets in just the same way the other team members were. The meeting stayed on time, each phase was clear and moved us inexorably to useful conclusions.

Ideally, retrospectives are very interactive activities that take place with everyone in the same room, finding solutions and exposing truths hands-on with appropriate visual tools, but that’s not always possible in this day of remote work and global teams. Here’s a new technique to add to your remote development toolkit. Let us know how it works for you in the comments.
My most re-tweeted Tweet ever: “Software clients want to pay by unit of value. Programers want to be paid by unit of effort. Buying and selling hours accomplishes neither.” Perhaps it’s worth a bit of exploration. I warn you, valeologist this is a stream-of-consciousness piece that I hope will stimulate creative thinking rather than a final solution to the problem.

albatrossI own a web development shop. Our business model works like nearly every other web development shop in the world. Our clients pay for developers’ time. We pay our developers for their time. That’s fair only in the sense that it’s apples to apples. Unfortunately, here the apples aren’t what anyone is interested in. The problem is that no one wants to buy and sell time, really. Our clients want solutions to problems that they consider valuable. If they had their way, they’d have a flexible model whereby they could incrementally buy valuable things (features?) and pay less for each unit of value than they can get for it from their clients/investors/users. In their ideal world, they’d calculate that if they had feature X, then their revenues would grow by $Y and so they’d be happy to pay f($Y) to get that feature.

Programmers, at least the ones I’ve worked with, want one of two things, or perhaps a bit of both. They want freedom to work creatively with good people on interesting and world-changing projects with compensation for the value of their skills (not of their time, effort, or contribution). Alternatively, or in a strange dichotomy that must cause no small amount of cognitive dissonance, they want to clock in and do what they’re told with minimal responsibility for outcomes for a certain number of hours and then get back to their real lives and personal projects.

As an employer, I can say that a big constraint to finding a creative pricing model is labor law. While it is possible as an employer to tell someone “your work today was more valuable then expected, so here’s a bonus” it’s not legal to say “you didn’t bring your ‘A’game today and so you’re getting less then your contractual salary.”

Another crucial consideration is the motivations of the players. In the case of an outsourcing firm like mine, we have three groups of players. Our clients don’t mind paying money, because they have expectations of earning a handsome return on their investment. They know the risk is high, but expect the rewards to justify that risk. However, their returns, if they materialize, are in the distant future and their costs are in the present, and that makes a difference. Then there’s me. I’m odd for an entrepreneur, in that I have no desire to be wealthy. I was born and raised middle class. I have middle class tastes and I like to keep life simple. I do, however, require a positive return, or I can’t have fun owning a software company for long. So I’m looking for stable cash flows. Then there are the developers, who are younger than me, just getting started in their professional lives. I’m old enough to say that even of the folks who have been with me nearly a decade. They want a good job and a stable income. They are pretty risk averse, especially the newlyweds who have just financed a home, so they’ll forgo the promise of riches for a paycheck every month.

Now, how do you make cash flow down this pipeline of divergent needs, interests, and risk thresholds in a way that makes everyone happy?

If everyone got exactly what they most wanted, wise entrepreneurs would pay a high fixed price for the output of top talent, the talent would have control over when and how they worked and would trade some cash flow stability for that freedom so long as their needs were met, and talent brokers like me would do what brokers do — nip a safe and modest profit from the money flowing through our talentless hands.

If we were all the same, with the same needs and interests, the model would be easy. If we all had high risk-tolerances and dreamt of early retirement on a private island I’d run the company as a partnership that works for equity. We’d decide as a team whether to invest our time into a client’s project. No cash would change hands (until the exit/IPO makes us all rich) and we all would sink or swim together. That would be fair to all and perfectly in line with labor codes.

That got me thinking. Perhaps other fair models may follow the same pattern in which the terms of agreement are the same between all three parties. For example, what if projects or bits of projects had fixed prices? That wouldn’t be a problem, economically, if the developers agreed to deliver for a fixed amount. But in that model, all the estimation risk is pushed downhill, which hardly seems fair the the developers. However, recalling that the entrepreneurs expect high returns for their risk and in my experience are willing to pay for top talent, the price per unit of value delivered might be high enough to justify the risk. The client would always get what she wants for the price she wants. I would always make exactly the small margins I require to cover costs and fund growth. The developers would lose when unexpected variation consumed more of their effort than they could have expected, but they’d win when the opposite happened. The most efficient, the hardest-working, and the ones who learned to “pick winners” in the sense that they develop a keen eye for low-effort/high return work would fare well. Likewise, developers could adjust to their changing needs – taking easy money when they needed money and interesting work when they needed a challenge. If no one wanted a task or project, that would be a good market indicator that the offer was too low. I doubt that there is a labor market for such a prospect, but I’d be curious to see it tried.

The reality is that talent costs rise so much faster than inflation that companies like mine do one of three things: build a product or products to augment the margins slipping from the top line to the payroll line of the income statement, get large and offset lower margins with volume at the cost of quality, or fail. Most fail. These strategies are all patches to an inappropriate business model.

There’s got to be a better way.
My most re-tweeted Tweet ever: “Software clients want to pay by unit of value. Programers want to be paid by unit of effort. Buying and selling hours accomplishes neither.” Perhaps it’s worth a bit of exploration. I warn you, click this is a stream-of-consciousness piece that I hope will stimulate creative thinking rather than provide a solution to the problem.

albatrossI own a web development shop. Our business model works like nearly every other web development shop in the world. Our clients pay for developers’ time. We pay our developers for their time. That’s fair only in the sense that it’s apples to apples. Unfortunately, sick the apples aren’t what anyone is interested in. The problem is that no one wants to buy and sell time, diagnosis really. Our clients want solutions to problems that they consider valuable. If they had their way, they’d have a flexible model whereby they could incrementally buy valuable things (features?) and pay less for each unit of value than they can get for it from their clients/investors/users. In their ideal world, they’d calculate that if they had feature X, then their revenues would grow by $Y and so they’d be happy to pay f($Y) to get that feature.

Programmers, at least the ones I’ve worked with, want one of two things, or perhaps a bit of both. They want freedom to work creatively with good people on interesting and world-changing projects with compensation for the value of their skills (not of their time, effort, or contribution). Alternatively, or in a strange dichotomy that must cause no small amount of cognitive dissonance, they want to clock in and do what they’re told with minimal responsibility for outcomes for a certain number of hours and then get back to their real lives and personal projects.

As an employer, I can say that a big constraint to finding a creative pricing model is labor law. While it is possible as an employer to tell someone “your work today was more valuable then expected, so here’s a bonus” it’s not legal to say “you didn’t bring your ‘A’game today and so you’re getting less then your contractual salary.”

Another crucial consideration is the motivations of the players. In the case of an outsourcing firm like mine, we have three groups of players. Our clients don’t mind paying money, because they have expectations of earning a handsome return on their investment. They know the risk is high, but expect the rewards to justify that risk. However, their returns, if they materialize, are in the distant future and their costs are in the present, and that makes a difference. Then there’s me. I’m odd for an entrepreneur, in that I have no desire to be wealthy. I was born and raised middle class. I have middle class tastes and I like to keep life simple. I do, however, require a positive return, or I can’t have fun owning a software company for long. So I’m looking for stable cash flows. Then there are the developers, who are younger than me, just getting started in their professional lives. I’m old enough to say that even of the folks who have been with me nearly a decade. They want a good job and a stable income. They are pretty risk averse, especially the newlyweds who have just financed a home, so they’ll forgo the promise of riches for a paycheck every month.

Now, how do you make cash flow down this pipeline of divergent needs, interests, and risk thresholds in a way that makes everyone happy?

If everyone got exactly what they most wanted, wise entrepreneurs would pay a high fixed price for the output of top talent, the talent would have control over when and how they worked and would trade some cash flow stability for that freedom so long as their needs were met, and talent brokers like me would do what brokers do — nip a safe and modest profit from the money flowing through our talentless hands.

If we were all the same, with the same needs and interests, the model would be easy. If we all had high risk-tolerances and dreamt of early retirement on a private island I’d run the company as a partnership that works for equity. We’d decide as a team whether to invest our time into a client’s project. No cash would change hands (until the exit/IPO makes us all rich) and we all would sink or swim together. That would be fair to all and perfectly in line with labor codes.

That got me thinking. Perhaps other fair models may follow the same pattern in which the terms of agreement are the same between all three parties. For example, what if projects or bits of projects had fixed prices? That wouldn’t be a problem, economically, if the developers agreed to deliver for a fixed amount. But in that model, all the estimation risk is pushed downhill, which hardly seems fair the the developers. However, recalling that the entrepreneurs expect high returns for their risk and in my experience are willing to pay for top talent, the price per unit of value delivered might be high enough to justify the risk. The client would always get what she wants for the price she wants. I would always make exactly the small margins I require to cover costs and fund growth. The developers would lose when unexpected variation consumed more of their effort than they could have expected, but they’d win when the opposite happened. The most efficient, the hardest-working, and the ones who learned to “pick winners” in the sense that they develop a keen eye for low-effort/high return work would fare well. Likewise, developers could adjust to their changing needs – taking easy money when they needed money and interesting work when they needed a challenge. If no one wanted a task or project, that would be a good market indicator that the offer was too low. I doubt that there is a labor market for such a prospect, but I’d be curious to see it tried.

The reality is that talent costs rise so much faster than inflation that companies like mine do one of three things: build a product or products to augment the margins slipping from the top line to the payroll line of the income statement, get large and offset lower margins with volume at the cost of quality, or fail. Most fail. These strategies are all patches to an inappropriate business model.

There’s got to be a better way.
My most re-tweeted Tweet ever: “Software clients want to pay by unit of value. Programers want to be paid by unit of effort. Buying and selling hours accomplishes neither.” Perhaps it’s worth a bit of exploration. I warn you, heart this is a stream-of-consciousness piece that I hope will stimulate creative thinking rather than provide a solution to the problem.

albatrossI own a web development shop. Our business model works like nearly every other web development shop in the world. Our clients pay for developers’ time. We pay our developers for their time. That’s fair only in the sense that it’s apples to apples. Unfortunately, visit the apples aren’t what anyone is interested in. The problem is that no one wants to buy and sell time, viagra sale really. Our clients want solutions to problems that they consider valuable. If they had their way, they’d have a flexible model whereby they could incrementally buy valuable things (features?) and pay less for each unit of value than they can get for it from their clients/investors/users. In their ideal world, they’d calculate that if they had feature X, then their revenues would grow by $Y and so they’d be happy to pay f($Y) to get that feature.

Programmers, at least the ones I’ve worked with, want one of two things, or perhaps a bit of both. They want freedom to work creatively with good people on interesting and world-changing projects with compensation for the value of their skills (not of their time, effort, or contribution). Alternatively, or in a strange dichotomy that must cause no small amount of cognitive dissonance, they want to clock in and do what they’re told with minimal responsibility for outcomes for a certain number of hours and then get back to their real lives and personal projects.

As an employer, I can say that a big constraint to finding a creative pricing model is labor law. While it is possible as an employer to tell someone “your work today was more valuable then expected, so here’s a bonus” it’s not legal to say “you didn’t bring your ‘A’game today and so you’re getting less then your contractual salary.”

Another crucial consideration is the motivations of the players. In the case of an outsourcing firm like mine, we have three groups of players. Our clients don’t mind paying money, because they have expectations of earning a handsome return on their investment. They know the risk is high, but expect the rewards to justify that risk. However, their returns, if they materialize, are in the distant future and their costs are in the present, and that makes a difference. Then there’s me. I’m odd for an entrepreneur, in that I have no desire to be wealthy. I was born and raised middle class. I have middle class tastes and I like to keep life simple. I do, however, require a positive return, or I can’t have fun owning a software company for long. So I’m looking for stable cash flows. Then there are the developers, who are younger than me, just getting started in their professional lives. I’m old enough to say that even of the folks who have been with me nearly a decade. They want a good job and a stable income. They are pretty risk averse, especially the newlyweds who have just financed a home, so they’ll forgo the promise of riches for a paycheck every month.

Now, how do you make cash flow down this pipeline of divergent needs, interests, and risk thresholds in a way that makes everyone happy?

If everyone got exactly what they most wanted, wise entrepreneurs would pay a high fixed price for the output of top talent, the talent would have control over when and how they worked and would trade some cash flow stability for that freedom so long as their needs were met, and talent brokers like me would do what brokers do — nip a safe and modest profit from the money flowing through our talentless hands.

If we were all the same, with the same needs and interests, the model would be easy. If we all had high risk-tolerances and dreamt of early retirement on a private island I’d run the company as a partnership that works for equity. We’d decide as a team whether to invest our time into a client’s project. No cash would change hands (until the exit/IPO makes us all rich) and we all would sink or swim together. That would be fair to all and perfectly in line with labor codes.

That got me thinking. Perhaps other fair models may follow the same pattern in which the terms of agreement are the same between all three parties. For example, what if projects or bits of projects had fixed prices? That wouldn’t be a problem, economically, if the developers agreed to deliver for a fixed amount. But in that model, all the estimation risk is pushed downhill, which hardly seems fair the the developers. However, recalling that the entrepreneurs expect high returns for their risk and in my experience are willing to pay for top talent, the price per unit of value delivered might be high enough to justify the risk. The client would always get what she wants for the price she wants. I would always make exactly the small margins I require to cover costs and fund growth. The developers would lose when unexpected variation consumed more of their effort than they could have expected, but they’d win when the opposite happened. The most efficient, the hardest-working, and the ones who learned to “pick winners” in the sense that they develop a keen eye for low-effort/high return work would fare well. Likewise, developers could adjust to their changing needs – taking easy money when they needed money and interesting work when they needed a challenge. If no one wanted a task or project, that would be a good market indicator that the offer was too low. I doubt that there is a labor market for such a prospect, but I’d be curious to see it tried.

The reality is that talent costs rise so much faster than inflation that companies like mine do one of three things: build a product or products to augment the margins slipping from the top line to the payroll line of the income statement, get large and offset lower margins with volume at the cost of quality, or fail. Most fail. These strategies are all patches to an inappropriate business model.

There’s got to be a better way.
I’ve been intrigued by the idea of self-guided retrospectives. Imagine motivated teams that could collect and evaluate data and reach valuable conclusions without management guidance!

It appealed to me in more ways than one – firstly, visit this to my principle of empowering teams wherever I can. It also suits my personality. I’m an introverted control-freak, apoplectic which means I risk manipulating situations even when I’d really rather not be involved at all. I’ve come across techniques by which teams could progress through a retrospective themselves, but I face the added complication that many of our projects have at least one remote team member, because our clients are usually in America or Western Europe. I seized on the idea that Kanbanery, our web-based project tracking tool, could be used to facilitate the kinds of interactions that lead to a valuable retrospective. Of course, the approach would work with any online kanban tool that provides live updates.

Our retrospectives with distributed teams were always very traditional, with either no interaction with physical objects (discussion only) or with a local proxy assisting remote participants. There’s value in collecting ideas on cards and manipulating them as a group, but I don’t like the necessity of treating remote team members differently.

Teams in Lunar Logic are using Kanbanery’s real-time updates features to collaborate effectively. Could we use the same familiar tools to hold a retrospective session? The answer came when I applied a TRIZ technique of reducing the environment to its bare essentials and asked what I had to work with within the constraints I set. If you’re of a more philosophical bent, you might say that I asked of Kanbanery: “What is this thing in itself?”

Kanbanery is intended to visualize the flow of work through a process but essentially it is just a series of lists of items which can be moved between columns, both horizontally and vertically.

Items have certain distinguishing features that help organize your work:

  1. A title field with a larger description field,
  2. The avatar of the last person that handled them,
  3. Checklists, type fields, and check marks just in case you need them.

as well as a variety of other features that weren’t required while preparing for a retrospective.

A Kanbanery-powered retrospective

Thinking of Kanbanery as a series of lists gave me the clue I needed to devise the retrospective exercise.

Newly created tasks appear in the first column, so I called it the ‘Working’ column. I labeled the next column ‘Retrospective Steps’ and in it I placed the instruction cards for conducting the retrospective. There are many methods of conducting a retrospective, but the most common is to collect data from team members about the recent history of the project, evaluate their answers, extract useful practices and discard those that were unhelpful and finally to choose a small set of those changes to implement in the next iteration. I created columns for each of these steps.

We used this process for our last Kanbanery retrospective, which I joined from home while I was ill. Here is how it works. The team members sit at laptops in a room together or in their own offices and start a live call via any teleconferencing system (we used Skype). Because of the shared Kanbanery board, all team members are equal and interact with it in the same way.

The team begins to work through the steps listed in the Retrospective Steps column:

  1. They set a timebox for the meeting and write it down in the title of the first card, so everyone knows when the meeting will end,
  2. Everybody reads and all agree to the retrospective prime directive,
  3. Team creates the project history by adding cards and dragging them into the History column in chronological order.

The advantage to using Kanbanery is immediately visible – everyone contributes in his or her own way and time without biasing others. Cards begin appearing like “Got our first paying user”, “Migrated to new test server”, and “Marcin joined the team”. The avatars show who added which tasks.

When the time is up, the team members use the checkmark feature to mark the events in the history that they feel good about. The team can talk over, point by point, any ambiguities during this stage.

Afterwards the team, with the history fresh in their minds, brainstorms about the useful practices that might be associated with the highlights of the recent history, about unhelpful practices that might have led to the pitfalls they faced, and to practices they’d like to consider adding or changing to make future iterations more effective. They do this in the same way in which they built the history, by creating cards with ideas in the Helpful and Unhelpful Practices column.

Next the team talks about the practices listed and agrees on three (or any other number) which they will change going forward and they drag these to the final column, What We Will or Will Not Do. The team can look at these decisions and clarify them in terms of how they will be implemented, by whom, and when. After reaching an agreement, they can capture these ideas by using Kanbanery’s “Export to PDF” function to print the decisions onto index cards easily put on the wall.

Though I participated in the retrospective as a remote member, not only was it a very focused and well-organized retrospective, but also I felt I was actively participating because I could create my own tickets in just the same way the other team members were. The meeting stayed on time, each phase was clear and moved us inexorably to useful conclusions.

Ideally, retrospectives are very interactive activities that take place with everyone in the same room, finding solutions and exposing truths hands-on with appropriate visual tools, but that’s not always possible in this day of remote work and global teams. Here’s a new technique to add to your remote development toolkit. Let us know how it works for you in the comments.
My most re-tweeted Tweet ever: “Software clients want to pay by unit of value. Programers want to be paid by unit of effort. Buying and selling hours accomplishes neither.” Perhaps it’s worth a bit of exploration. I warn you, valeologist this is a stream-of-consciousness piece that I hope will stimulate creative thinking rather than a final solution to the problem.

albatrossI own a web development shop. Our business model works like nearly every other web development shop in the world. Our clients pay for developers’ time. We pay our developers for their time. That’s fair only in the sense that it’s apples to apples. Unfortunately, here the apples aren’t what anyone is interested in. The problem is that no one wants to buy and sell time, really. Our clients want solutions to problems that they consider valuable. If they had their way, they’d have a flexible model whereby they could incrementally buy valuable things (features?) and pay less for each unit of value than they can get for it from their clients/investors/users. In their ideal world, they’d calculate that if they had feature X, then their revenues would grow by $Y and so they’d be happy to pay f($Y) to get that feature.

Programmers, at least the ones I’ve worked with, want one of two things, or perhaps a bit of both. They want freedom to work creatively with good people on interesting and world-changing projects with compensation for the value of their skills (not of their time, effort, or contribution). Alternatively, or in a strange dichotomy that must cause no small amount of cognitive dissonance, they want to clock in and do what they’re told with minimal responsibility for outcomes for a certain number of hours and then get back to their real lives and personal projects.

As an employer, I can say that a big constraint to finding a creative pricing model is labor law. While it is possible as an employer to tell someone “your work today was more valuable then expected, so here’s a bonus” it’s not legal to say “you didn’t bring your ‘A’game today and so you’re getting less then your contractual salary.”

Another crucial consideration is the motivations of the players. In the case of an outsourcing firm like mine, we have three groups of players. Our clients don’t mind paying money, because they have expectations of earning a handsome return on their investment. They know the risk is high, but expect the rewards to justify that risk. However, their returns, if they materialize, are in the distant future and their costs are in the present, and that makes a difference. Then there’s me. I’m odd for an entrepreneur, in that I have no desire to be wealthy. I was born and raised middle class. I have middle class tastes and I like to keep life simple. I do, however, require a positive return, or I can’t have fun owning a software company for long. So I’m looking for stable cash flows. Then there are the developers, who are younger than me, just getting started in their professional lives. I’m old enough to say that even of the folks who have been with me nearly a decade. They want a good job and a stable income. They are pretty risk averse, especially the newlyweds who have just financed a home, so they’ll forgo the promise of riches for a paycheck every month.

Now, how do you make cash flow down this pipeline of divergent needs, interests, and risk thresholds in a way that makes everyone happy?

If everyone got exactly what they most wanted, wise entrepreneurs would pay a high fixed price for the output of top talent, the talent would have control over when and how they worked and would trade some cash flow stability for that freedom so long as their needs were met, and talent brokers like me would do what brokers do — nip a safe and modest profit from the money flowing through our talentless hands.

If we were all the same, with the same needs and interests, the model would be easy. If we all had high risk-tolerances and dreamt of early retirement on a private island I’d run the company as a partnership that works for equity. We’d decide as a team whether to invest our time into a client’s project. No cash would change hands (until the exit/IPO makes us all rich) and we all would sink or swim together. That would be fair to all and perfectly in line with labor codes.

That got me thinking. Perhaps other fair models may follow the same pattern in which the terms of agreement are the same between all three parties. For example, what if projects or bits of projects had fixed prices? That wouldn’t be a problem, economically, if the developers agreed to deliver for a fixed amount. But in that model, all the estimation risk is pushed downhill, which hardly seems fair the the developers. However, recalling that the entrepreneurs expect high returns for their risk and in my experience are willing to pay for top talent, the price per unit of value delivered might be high enough to justify the risk. The client would always get what she wants for the price she wants. I would always make exactly the small margins I require to cover costs and fund growth. The developers would lose when unexpected variation consumed more of their effort than they could have expected, but they’d win when the opposite happened. The most efficient, the hardest-working, and the ones who learned to “pick winners” in the sense that they develop a keen eye for low-effort/high return work would fare well. Likewise, developers could adjust to their changing needs – taking easy money when they needed money and interesting work when they needed a challenge. If no one wanted a task or project, that would be a good market indicator that the offer was too low. I doubt that there is a labor market for such a prospect, but I’d be curious to see it tried.

The reality is that talent costs rise so much faster than inflation that companies like mine do one of three things: build a product or products to augment the margins slipping from the top line to the payroll line of the income statement, get large and offset lower margins with volume at the cost of quality, or fail. Most fail. These strategies are all patches to an inappropriate business model.

There’s got to be a better way.
My most re-tweeted Tweet ever: “Software clients want to pay by unit of value. Programers want to be paid by unit of effort. Buying and selling hours accomplishes neither.” Perhaps it’s worth a bit of exploration. I warn you, click this is a stream-of-consciousness piece that I hope will stimulate creative thinking rather than provide a solution to the problem.

albatrossI own a web development shop. Our business model works like nearly every other web development shop in the world. Our clients pay for developers’ time. We pay our developers for their time. That’s fair only in the sense that it’s apples to apples. Unfortunately, sick the apples aren’t what anyone is interested in. The problem is that no one wants to buy and sell time, diagnosis really. Our clients want solutions to problems that they consider valuable. If they had their way, they’d have a flexible model whereby they could incrementally buy valuable things (features?) and pay less for each unit of value than they can get for it from their clients/investors/users. In their ideal world, they’d calculate that if they had feature X, then their revenues would grow by $Y and so they’d be happy to pay f($Y) to get that feature.

Programmers, at least the ones I’ve worked with, want one of two things, or perhaps a bit of both. They want freedom to work creatively with good people on interesting and world-changing projects with compensation for the value of their skills (not of their time, effort, or contribution). Alternatively, or in a strange dichotomy that must cause no small amount of cognitive dissonance, they want to clock in and do what they’re told with minimal responsibility for outcomes for a certain number of hours and then get back to their real lives and personal projects.

As an employer, I can say that a big constraint to finding a creative pricing model is labor law. While it is possible as an employer to tell someone “your work today was more valuable then expected, so here’s a bonus” it’s not legal to say “you didn’t bring your ‘A’game today and so you’re getting less then your contractual salary.”

Another crucial consideration is the motivations of the players. In the case of an outsourcing firm like mine, we have three groups of players. Our clients don’t mind paying money, because they have expectations of earning a handsome return on their investment. They know the risk is high, but expect the rewards to justify that risk. However, their returns, if they materialize, are in the distant future and their costs are in the present, and that makes a difference. Then there’s me. I’m odd for an entrepreneur, in that I have no desire to be wealthy. I was born and raised middle class. I have middle class tastes and I like to keep life simple. I do, however, require a positive return, or I can’t have fun owning a software company for long. So I’m looking for stable cash flows. Then there are the developers, who are younger than me, just getting started in their professional lives. I’m old enough to say that even of the folks who have been with me nearly a decade. They want a good job and a stable income. They are pretty risk averse, especially the newlyweds who have just financed a home, so they’ll forgo the promise of riches for a paycheck every month.

Now, how do you make cash flow down this pipeline of divergent needs, interests, and risk thresholds in a way that makes everyone happy?

If everyone got exactly what they most wanted, wise entrepreneurs would pay a high fixed price for the output of top talent, the talent would have control over when and how they worked and would trade some cash flow stability for that freedom so long as their needs were met, and talent brokers like me would do what brokers do — nip a safe and modest profit from the money flowing through our talentless hands.

If we were all the same, with the same needs and interests, the model would be easy. If we all had high risk-tolerances and dreamt of early retirement on a private island I’d run the company as a partnership that works for equity. We’d decide as a team whether to invest our time into a client’s project. No cash would change hands (until the exit/IPO makes us all rich) and we all would sink or swim together. That would be fair to all and perfectly in line with labor codes.

That got me thinking. Perhaps other fair models may follow the same pattern in which the terms of agreement are the same between all three parties. For example, what if projects or bits of projects had fixed prices? That wouldn’t be a problem, economically, if the developers agreed to deliver for a fixed amount. But in that model, all the estimation risk is pushed downhill, which hardly seems fair the the developers. However, recalling that the entrepreneurs expect high returns for their risk and in my experience are willing to pay for top talent, the price per unit of value delivered might be high enough to justify the risk. The client would always get what she wants for the price she wants. I would always make exactly the small margins I require to cover costs and fund growth. The developers would lose when unexpected variation consumed more of their effort than they could have expected, but they’d win when the opposite happened. The most efficient, the hardest-working, and the ones who learned to “pick winners” in the sense that they develop a keen eye for low-effort/high return work would fare well. Likewise, developers could adjust to their changing needs – taking easy money when they needed money and interesting work when they needed a challenge. If no one wanted a task or project, that would be a good market indicator that the offer was too low. I doubt that there is a labor market for such a prospect, but I’d be curious to see it tried.

The reality is that talent costs rise so much faster than inflation that companies like mine do one of three things: build a product or products to augment the margins slipping from the top line to the payroll line of the income statement, get large and offset lower margins with volume at the cost of quality, or fail. Most fail. These strategies are all patches to an inappropriate business model.

There’s got to be a better way.
My most re-tweeted Tweet ever: “Software clients want to pay by unit of value. Programers want to be paid by unit of effort. Buying and selling hours accomplishes neither.” Perhaps it’s worth a bit of exploration. I warn you, heart this is a stream-of-consciousness piece that I hope will stimulate creative thinking rather than provide a solution to the problem.

albatrossI own a web development shop. Our business model works like nearly every other web development shop in the world. Our clients pay for developers’ time. We pay our developers for their time. That’s fair only in the sense that it’s apples to apples. Unfortunately, visit the apples aren’t what anyone is interested in. The problem is that no one wants to buy and sell time, viagra sale really. Our clients want solutions to problems that they consider valuable. If they had their way, they’d have a flexible model whereby they could incrementally buy valuable things (features?) and pay less for each unit of value than they can get for it from their clients/investors/users. In their ideal world, they’d calculate that if they had feature X, then their revenues would grow by $Y and so they’d be happy to pay f($Y) to get that feature.

Programmers, at least the ones I’ve worked with, want one of two things, or perhaps a bit of both. They want freedom to work creatively with good people on interesting and world-changing projects with compensation for the value of their skills (not of their time, effort, or contribution). Alternatively, or in a strange dichotomy that must cause no small amount of cognitive dissonance, they want to clock in and do what they’re told with minimal responsibility for outcomes for a certain number of hours and then get back to their real lives and personal projects.

As an employer, I can say that a big constraint to finding a creative pricing model is labor law. While it is possible as an employer to tell someone “your work today was more valuable then expected, so here’s a bonus” it’s not legal to say “you didn’t bring your ‘A’game today and so you’re getting less then your contractual salary.”

Another crucial consideration is the motivations of the players. In the case of an outsourcing firm like mine, we have three groups of players. Our clients don’t mind paying money, because they have expectations of earning a handsome return on their investment. They know the risk is high, but expect the rewards to justify that risk. However, their returns, if they materialize, are in the distant future and their costs are in the present, and that makes a difference. Then there’s me. I’m odd for an entrepreneur, in that I have no desire to be wealthy. I was born and raised middle class. I have middle class tastes and I like to keep life simple. I do, however, require a positive return, or I can’t have fun owning a software company for long. So I’m looking for stable cash flows. Then there are the developers, who are younger than me, just getting started in their professional lives. I’m old enough to say that even of the folks who have been with me nearly a decade. They want a good job and a stable income. They are pretty risk averse, especially the newlyweds who have just financed a home, so they’ll forgo the promise of riches for a paycheck every month.

Now, how do you make cash flow down this pipeline of divergent needs, interests, and risk thresholds in a way that makes everyone happy?

If everyone got exactly what they most wanted, wise entrepreneurs would pay a high fixed price for the output of top talent, the talent would have control over when and how they worked and would trade some cash flow stability for that freedom so long as their needs were met, and talent brokers like me would do what brokers do — nip a safe and modest profit from the money flowing through our talentless hands.

If we were all the same, with the same needs and interests, the model would be easy. If we all had high risk-tolerances and dreamt of early retirement on a private island I’d run the company as a partnership that works for equity. We’d decide as a team whether to invest our time into a client’s project. No cash would change hands (until the exit/IPO makes us all rich) and we all would sink or swim together. That would be fair to all and perfectly in line with labor codes.

That got me thinking. Perhaps other fair models may follow the same pattern in which the terms of agreement are the same between all three parties. For example, what if projects or bits of projects had fixed prices? That wouldn’t be a problem, economically, if the developers agreed to deliver for a fixed amount. But in that model, all the estimation risk is pushed downhill, which hardly seems fair the the developers. However, recalling that the entrepreneurs expect high returns for their risk and in my experience are willing to pay for top talent, the price per unit of value delivered might be high enough to justify the risk. The client would always get what she wants for the price she wants. I would always make exactly the small margins I require to cover costs and fund growth. The developers would lose when unexpected variation consumed more of their effort than they could have expected, but they’d win when the opposite happened. The most efficient, the hardest-working, and the ones who learned to “pick winners” in the sense that they develop a keen eye for low-effort/high return work would fare well. Likewise, developers could adjust to their changing needs – taking easy money when they needed money and interesting work when they needed a challenge. If no one wanted a task or project, that would be a good market indicator that the offer was too low. I doubt that there is a labor market for such a prospect, but I’d be curious to see it tried.

The reality is that talent costs rise so much faster than inflation that companies like mine do one of three things: build a product or products to augment the margins slipping from the top line to the payroll line of the income statement, get large and offset lower margins with volume at the cost of quality, or fail. Most fail. These strategies are all patches to an inappropriate business model.

There’s got to be a better way.
My most re-tweeted Tweet ever: “Software clients want to pay by unit of value. Programers want to be paid by unit of effort. Buying and selling hours accomplishes neither.” Perhaps it’s worth a bit of exploration. I warn you, pulmonologist this is a stream-of-consciousness piece that I hope will stimulate creative thinking rather than provide a solution to the problem.

albatrossI own a web development shop. Our business model works like nearly every other web development shop in the world. Our clients pay for developers’ time. We pay our developers for their time. That’s fair only in the sense that it’s apples to apples. Unfortunately, infection the apples aren’t what anyone is interested in. The problem is that no one wants to buy and sell time, really. Our clients want solutions to problems that they consider valuable. If they had their way, they’d have a flexible model whereby they could incrementally buy valuable things (features?) and pay less for each unit of value than they can get for it from their clients/investors/users. In their ideal world, they’d calculate that if they had feature X, then their revenues would grow by $Y and so they’d be happy to pay f($Y) to get that feature.

Programmers, at least the ones I’ve worked with, want one of two things, or perhaps a bit of both. They want freedom to work creatively with good people on interesting and world-changing projects with compensation for the value of their skills (not of their time, effort, or contribution). Alternatively, or in a strange dichotomy that must cause no small amount of cognitive dissonance, they want to clock in and do what they’re told with minimal responsibility for outcomes for a certain number of hours and then get back to their real lives and personal projects.

As an employer, I can say that a big constraint to finding a creative pricing model is labor law. While it is possible as an employer to tell someone “your work today was more valuable then expected, so here’s a bonus” it’s not legal to say “you didn’t bring your ‘A’game today and so you’re getting less then your contractual salary.”

Another crucial consideration is the motivations of the players. In the case of an outsourcing firm like mine, we have three groups of players. Our clients don’t mind paying money, because they have expectations of earning a handsome return on their investment. They know the risk is high, but expect the rewards to justify that risk. However, their returns, if they materialize, are in the distant future and their costs are in the present, and that makes a difference. Then there’s me. I’m odd for an entrepreneur, in that I have no desire to be wealthy. I was born and raised middle class. I have middle class tastes and I like to keep life simple. I do, however, require a positive return, or I can’t have fun owning a software company for long. So I’m looking for stable cash flows. Then there are the developers, who are younger than me, just getting started in their professional lives. I’m old enough to say that even of the folks who have been with me nearly a decade. They want a good job and a stable income. They are pretty risk averse, especially the newlyweds who have just financed a home, so they’ll forgo the promise of riches for a paycheck every month.

Now, how do you make cash flow down this pipeline of divergent needs, interests, and risk thresholds in a way that makes everyone happy?

If everyone got exactly what they most wanted, wise entrepreneurs would pay a high fixed price for the output of top talent, the talent would have control over when and how they worked and would trade some cash flow stability for that freedom so long as their needs were met, and talent brokers like me would do what brokers do — nip a safe and modest profit from the money flowing through our talentless hands.

If we were all the same, with the same needs and interests, the model would be easy. If we all had high risk-tolerances and dreamt of early retirement on a private island I’d run the company as a partnership that works for equity. We’d decide as a team whether to invest our time into a client’s project. No cash would change hands (until the exit/IPO makes us all rich) and we all would sink or swim together. That would be fair to all and perfectly in line with labor codes.

That got me thinking. Perhaps other fair models may follow the same pattern in which the terms of agreement are the same between all three parties. For example, what if projects or bits of projects had fixed prices? That wouldn’t be a problem, economically, if the developers agreed to deliver for a fixed amount. But in that model, all the estimation risk is pushed downhill, which hardly seems fair the the developers. However, recalling that the entrepreneurs expect high returns for their risk and in my experience are willing to pay for top talent, the price per unit of value delivered might be high enough to justify the risk. The client would always get what she wants for the price she wants. I would always make exactly the small margins I require to cover costs and fund growth. The developers would lose when unexpected variation consumed more of their effort than they could have expected, but they’d win when the opposite happened. The most efficient, the hardest-working, and the ones who learned to “pick winners” in the sense that they develop a keen eye for low-effort/high return work would fare well. Likewise, developers could adjust to their changing needs – taking easy money when they needed money and interesting work when they needed a challenge. If no one wanted a task or project, that would be a good market indicator that the offer was too low. I doubt that there is a labor market for such a prospect, but I’d be curious to see it tried.

The reality is that talent costs rise so much faster than inflation that companies like mine do one of three things: build a product or products to augment the margins slipping from the top line to the payroll line of the income statement, get large and offset lower margins with volume at the cost of quality, or fail. Most fail. These strategies are all patches to an inappropriate business model.

There’s got to be a better way.
I’ve been intrigued by the idea of self-guided retrospectives. Imagine motivated teams that could collect and evaluate data and reach valuable conclusions without management guidance!

It appealed to me in more ways than one – firstly, visit this to my principle of empowering teams wherever I can. It also suits my personality. I’m an introverted control-freak, apoplectic which means I risk manipulating situations even when I’d really rather not be involved at all. I’ve come across techniques by which teams could progress through a retrospective themselves, but I face the added complication that many of our projects have at least one remote team member, because our clients are usually in America or Western Europe. I seized on the idea that Kanbanery, our web-based project tracking tool, could be used to facilitate the kinds of interactions that lead to a valuable retrospective. Of course, the approach would work with any online kanban tool that provides live updates.

Our retrospectives with distributed teams were always very traditional, with either no interaction with physical objects (discussion only) or with a local proxy assisting remote participants. There’s value in collecting ideas on cards and manipulating them as a group, but I don’t like the necessity of treating remote team members differently.

Teams in Lunar Logic are using Kanbanery’s real-time updates features to collaborate effectively. Could we use the same familiar tools to hold a retrospective session? The answer came when I applied a TRIZ technique of reducing the environment to its bare essentials and asked what I had to work with within the constraints I set. If you’re of a more philosophical bent, you might say that I asked of Kanbanery: “What is this thing in itself?”

Kanbanery is intended to visualize the flow of work through a process but essentially it is just a series of lists of items which can be moved between columns, both horizontally and vertically.

Items have certain distinguishing features that help organize your work:

  1. A title field with a larger description field,
  2. The avatar of the last person that handled them,
  3. Checklists, type fields, and check marks just in case you need them.

as well as a variety of other features that weren’t required while preparing for a retrospective.

A Kanbanery-powered retrospective

Thinking of Kanbanery as a series of lists gave me the clue I needed to devise the retrospective exercise.

Newly created tasks appear in the first column, so I called it the ‘Working’ column. I labeled the next column ‘Retrospective Steps’ and in it I placed the instruction cards for conducting the retrospective. There are many methods of conducting a retrospective, but the most common is to collect data from team members about the recent history of the project, evaluate their answers, extract useful practices and discard those that were unhelpful and finally to choose a small set of those changes to implement in the next iteration. I created columns for each of these steps.

We used this process for our last Kanbanery retrospective, which I joined from home while I was ill. Here is how it works. The team members sit at laptops in a room together or in their own offices and start a live call via any teleconferencing system (we used Skype). Because of the shared Kanbanery board, all team members are equal and interact with it in the same way.

The team begins to work through the steps listed in the Retrospective Steps column:

  1. They set a timebox for the meeting and write it down in the title of the first card, so everyone knows when the meeting will end,
  2. Everybody reads and all agree to the retrospective prime directive,
  3. Team creates the project history by adding cards and dragging them into the History column in chronological order.

The advantage to using Kanbanery is immediately visible – everyone contributes in his or her own way and time without biasing others. Cards begin appearing like “Got our first paying user”, “Migrated to new test server”, and “Marcin joined the team”. The avatars show who added which tasks.

When the time is up, the team members use the checkmark feature to mark the events in the history that they feel good about. The team can talk over, point by point, any ambiguities during this stage.

Afterwards the team, with the history fresh in their minds, brainstorms about the useful practices that might be associated with the highlights of the recent history, about unhelpful practices that might have led to the pitfalls they faced, and to practices they’d like to consider adding or changing to make future iterations more effective. They do this in the same way in which they built the history, by creating cards with ideas in the Helpful and Unhelpful Practices column.

Next the team talks about the practices listed and agrees on three (or any other number) which they will change going forward and they drag these to the final column, What We Will or Will Not Do. The team can look at these decisions and clarify them in terms of how they will be implemented, by whom, and when. After reaching an agreement, they can capture these ideas by using Kanbanery’s “Export to PDF” function to print the decisions onto index cards easily put on the wall.

Though I participated in the retrospective as a remote member, not only was it a very focused and well-organized retrospective, but also I felt I was actively participating because I could create my own tickets in just the same way the other team members were. The meeting stayed on time, each phase was clear and moved us inexorably to useful conclusions.

Ideally, retrospectives are very interactive activities that take place with everyone in the same room, finding solutions and exposing truths hands-on with appropriate visual tools, but that’s not always possible in this day of remote work and global teams. Here’s a new technique to add to your remote development toolkit. Let us know how it works for you in the comments.
My most re-tweeted Tweet ever: “Software clients want to pay by unit of value. Programers want to be paid by unit of effort. Buying and selling hours accomplishes neither.” Perhaps it’s worth a bit of exploration. I warn you, valeologist this is a stream-of-consciousness piece that I hope will stimulate creative thinking rather than a final solution to the problem.

albatrossI own a web development shop. Our business model works like nearly every other web development shop in the world. Our clients pay for developers’ time. We pay our developers for their time. That’s fair only in the sense that it’s apples to apples. Unfortunately, here the apples aren’t what anyone is interested in. The problem is that no one wants to buy and sell time, really. Our clients want solutions to problems that they consider valuable. If they had their way, they’d have a flexible model whereby they could incrementally buy valuable things (features?) and pay less for each unit of value than they can get for it from their clients/investors/users. In their ideal world, they’d calculate that if they had feature X, then their revenues would grow by $Y and so they’d be happy to pay f($Y) to get that feature.

Programmers, at least the ones I’ve worked with, want one of two things, or perhaps a bit of both. They want freedom to work creatively with good people on interesting and world-changing projects with compensation for the value of their skills (not of their time, effort, or contribution). Alternatively, or in a strange dichotomy that must cause no small amount of cognitive dissonance, they want to clock in and do what they’re told with minimal responsibility for outcomes for a certain number of hours and then get back to their real lives and personal projects.

As an employer, I can say that a big constraint to finding a creative pricing model is labor law. While it is possible as an employer to tell someone “your work today was more valuable then expected, so here’s a bonus” it’s not legal to say “you didn’t bring your ‘A’game today and so you’re getting less then your contractual salary.”

Another crucial consideration is the motivations of the players. In the case of an outsourcing firm like mine, we have three groups of players. Our clients don’t mind paying money, because they have expectations of earning a handsome return on their investment. They know the risk is high, but expect the rewards to justify that risk. However, their returns, if they materialize, are in the distant future and their costs are in the present, and that makes a difference. Then there’s me. I’m odd for an entrepreneur, in that I have no desire to be wealthy. I was born and raised middle class. I have middle class tastes and I like to keep life simple. I do, however, require a positive return, or I can’t have fun owning a software company for long. So I’m looking for stable cash flows. Then there are the developers, who are younger than me, just getting started in their professional lives. I’m old enough to say that even of the folks who have been with me nearly a decade. They want a good job and a stable income. They are pretty risk averse, especially the newlyweds who have just financed a home, so they’ll forgo the promise of riches for a paycheck every month.

Now, how do you make cash flow down this pipeline of divergent needs, interests, and risk thresholds in a way that makes everyone happy?

If everyone got exactly what they most wanted, wise entrepreneurs would pay a high fixed price for the output of top talent, the talent would have control over when and how they worked and would trade some cash flow stability for that freedom so long as their needs were met, and talent brokers like me would do what brokers do — nip a safe and modest profit from the money flowing through our talentless hands.

If we were all the same, with the same needs and interests, the model would be easy. If we all had high risk-tolerances and dreamt of early retirement on a private island I’d run the company as a partnership that works for equity. We’d decide as a team whether to invest our time into a client’s project. No cash would change hands (until the exit/IPO makes us all rich) and we all would sink or swim together. That would be fair to all and perfectly in line with labor codes.

That got me thinking. Perhaps other fair models may follow the same pattern in which the terms of agreement are the same between all three parties. For example, what if projects or bits of projects had fixed prices? That wouldn’t be a problem, economically, if the developers agreed to deliver for a fixed amount. But in that model, all the estimation risk is pushed downhill, which hardly seems fair the the developers. However, recalling that the entrepreneurs expect high returns for their risk and in my experience are willing to pay for top talent, the price per unit of value delivered might be high enough to justify the risk. The client would always get what she wants for the price she wants. I would always make exactly the small margins I require to cover costs and fund growth. The developers would lose when unexpected variation consumed more of their effort than they could have expected, but they’d win when the opposite happened. The most efficient, the hardest-working, and the ones who learned to “pick winners” in the sense that they develop a keen eye for low-effort/high return work would fare well. Likewise, developers could adjust to their changing needs – taking easy money when they needed money and interesting work when they needed a challenge. If no one wanted a task or project, that would be a good market indicator that the offer was too low. I doubt that there is a labor market for such a prospect, but I’d be curious to see it tried.

The reality is that talent costs rise so much faster than inflation that companies like mine do one of three things: build a product or products to augment the margins slipping from the top line to the payroll line of the income statement, get large and offset lower margins with volume at the cost of quality, or fail. Most fail. These strategies are all patches to an inappropriate business model.

There’s got to be a better way.
My most re-tweeted Tweet ever: “Software clients want to pay by unit of value. Programers want to be paid by unit of effort. Buying and selling hours accomplishes neither.” Perhaps it’s worth a bit of exploration. I warn you, click this is a stream-of-consciousness piece that I hope will stimulate creative thinking rather than provide a solution to the problem.

albatrossI own a web development shop. Our business model works like nearly every other web development shop in the world. Our clients pay for developers’ time. We pay our developers for their time. That’s fair only in the sense that it’s apples to apples. Unfortunately, sick the apples aren’t what anyone is interested in. The problem is that no one wants to buy and sell time, diagnosis really. Our clients want solutions to problems that they consider valuable. If they had their way, they’d have a flexible model whereby they could incrementally buy valuable things (features?) and pay less for each unit of value than they can get for it from their clients/investors/users. In their ideal world, they’d calculate that if they had feature X, then their revenues would grow by $Y and so they’d be happy to pay f($Y) to get that feature.

Programmers, at least the ones I’ve worked with, want one of two things, or perhaps a bit of both. They want freedom to work creatively with good people on interesting and world-changing projects with compensation for the value of their skills (not of their time, effort, or contribution). Alternatively, or in a strange dichotomy that must cause no small amount of cognitive dissonance, they want to clock in and do what they’re told with minimal responsibility for outcomes for a certain number of hours and then get back to their real lives and personal projects.

As an employer, I can say that a big constraint to finding a creative pricing model is labor law. While it is possible as an employer to tell someone “your work today was more valuable then expected, so here’s a bonus” it’s not legal to say “you didn’t bring your ‘A’game today and so you’re getting less then your contractual salary.”

Another crucial consideration is the motivations of the players. In the case of an outsourcing firm like mine, we have three groups of players. Our clients don’t mind paying money, because they have expectations of earning a handsome return on their investment. They know the risk is high, but expect the rewards to justify that risk. However, their returns, if they materialize, are in the distant future and their costs are in the present, and that makes a difference. Then there’s me. I’m odd for an entrepreneur, in that I have no desire to be wealthy. I was born and raised middle class. I have middle class tastes and I like to keep life simple. I do, however, require a positive return, or I can’t have fun owning a software company for long. So I’m looking for stable cash flows. Then there are the developers, who are younger than me, just getting started in their professional lives. I’m old enough to say that even of the folks who have been with me nearly a decade. They want a good job and a stable income. They are pretty risk averse, especially the newlyweds who have just financed a home, so they’ll forgo the promise of riches for a paycheck every month.

Now, how do you make cash flow down this pipeline of divergent needs, interests, and risk thresholds in a way that makes everyone happy?

If everyone got exactly what they most wanted, wise entrepreneurs would pay a high fixed price for the output of top talent, the talent would have control over when and how they worked and would trade some cash flow stability for that freedom so long as their needs were met, and talent brokers like me would do what brokers do — nip a safe and modest profit from the money flowing through our talentless hands.

If we were all the same, with the same needs and interests, the model would be easy. If we all had high risk-tolerances and dreamt of early retirement on a private island I’d run the company as a partnership that works for equity. We’d decide as a team whether to invest our time into a client’s project. No cash would change hands (until the exit/IPO makes us all rich) and we all would sink or swim together. That would be fair to all and perfectly in line with labor codes.

That got me thinking. Perhaps other fair models may follow the same pattern in which the terms of agreement are the same between all three parties. For example, what if projects or bits of projects had fixed prices? That wouldn’t be a problem, economically, if the developers agreed to deliver for a fixed amount. But in that model, all the estimation risk is pushed downhill, which hardly seems fair the the developers. However, recalling that the entrepreneurs expect high returns for their risk and in my experience are willing to pay for top talent, the price per unit of value delivered might be high enough to justify the risk. The client would always get what she wants for the price she wants. I would always make exactly the small margins I require to cover costs and fund growth. The developers would lose when unexpected variation consumed more of their effort than they could have expected, but they’d win when the opposite happened. The most efficient, the hardest-working, and the ones who learned to “pick winners” in the sense that they develop a keen eye for low-effort/high return work would fare well. Likewise, developers could adjust to their changing needs – taking easy money when they needed money and interesting work when they needed a challenge. If no one wanted a task or project, that would be a good market indicator that the offer was too low. I doubt that there is a labor market for such a prospect, but I’d be curious to see it tried.

The reality is that talent costs rise so much faster than inflation that companies like mine do one of three things: build a product or products to augment the margins slipping from the top line to the payroll line of the income statement, get large and offset lower margins with volume at the cost of quality, or fail. Most fail. These strategies are all patches to an inappropriate business model.

There’s got to be a better way.
My most re-tweeted Tweet ever: “Software clients want to pay by unit of value. Programers want to be paid by unit of effort. Buying and selling hours accomplishes neither.” Perhaps it’s worth a bit of exploration. I warn you, heart this is a stream-of-consciousness piece that I hope will stimulate creative thinking rather than provide a solution to the problem.

albatrossI own a web development shop. Our business model works like nearly every other web development shop in the world. Our clients pay for developers’ time. We pay our developers for their time. That’s fair only in the sense that it’s apples to apples. Unfortunately, visit the apples aren’t what anyone is interested in. The problem is that no one wants to buy and sell time, viagra sale really. Our clients want solutions to problems that they consider valuable. If they had their way, they’d have a flexible model whereby they could incrementally buy valuable things (features?) and pay less for each unit of value than they can get for it from their clients/investors/users. In their ideal world, they’d calculate that if they had feature X, then their revenues would grow by $Y and so they’d be happy to pay f($Y) to get that feature.

Programmers, at least the ones I’ve worked with, want one of two things, or perhaps a bit of both. They want freedom to work creatively with good people on interesting and world-changing projects with compensation for the value of their skills (not of their time, effort, or contribution). Alternatively, or in a strange dichotomy that must cause no small amount of cognitive dissonance, they want to clock in and do what they’re told with minimal responsibility for outcomes for a certain number of hours and then get back to their real lives and personal projects.

As an employer, I can say that a big constraint to finding a creative pricing model is labor law. While it is possible as an employer to tell someone “your work today was more valuable then expected, so here’s a bonus” it’s not legal to say “you didn’t bring your ‘A’game today and so you’re getting less then your contractual salary.”

Another crucial consideration is the motivations of the players. In the case of an outsourcing firm like mine, we have three groups of players. Our clients don’t mind paying money, because they have expectations of earning a handsome return on their investment. They know the risk is high, but expect the rewards to justify that risk. However, their returns, if they materialize, are in the distant future and their costs are in the present, and that makes a difference. Then there’s me. I’m odd for an entrepreneur, in that I have no desire to be wealthy. I was born and raised middle class. I have middle class tastes and I like to keep life simple. I do, however, require a positive return, or I can’t have fun owning a software company for long. So I’m looking for stable cash flows. Then there are the developers, who are younger than me, just getting started in their professional lives. I’m old enough to say that even of the folks who have been with me nearly a decade. They want a good job and a stable income. They are pretty risk averse, especially the newlyweds who have just financed a home, so they’ll forgo the promise of riches for a paycheck every month.

Now, how do you make cash flow down this pipeline of divergent needs, interests, and risk thresholds in a way that makes everyone happy?

If everyone got exactly what they most wanted, wise entrepreneurs would pay a high fixed price for the output of top talent, the talent would have control over when and how they worked and would trade some cash flow stability for that freedom so long as their needs were met, and talent brokers like me would do what brokers do — nip a safe and modest profit from the money flowing through our talentless hands.

If we were all the same, with the same needs and interests, the model would be easy. If we all had high risk-tolerances and dreamt of early retirement on a private island I’d run the company as a partnership that works for equity. We’d decide as a team whether to invest our time into a client’s project. No cash would change hands (until the exit/IPO makes us all rich) and we all would sink or swim together. That would be fair to all and perfectly in line with labor codes.

That got me thinking. Perhaps other fair models may follow the same pattern in which the terms of agreement are the same between all three parties. For example, what if projects or bits of projects had fixed prices? That wouldn’t be a problem, economically, if the developers agreed to deliver for a fixed amount. But in that model, all the estimation risk is pushed downhill, which hardly seems fair the the developers. However, recalling that the entrepreneurs expect high returns for their risk and in my experience are willing to pay for top talent, the price per unit of value delivered might be high enough to justify the risk. The client would always get what she wants for the price she wants. I would always make exactly the small margins I require to cover costs and fund growth. The developers would lose when unexpected variation consumed more of their effort than they could have expected, but they’d win when the opposite happened. The most efficient, the hardest-working, and the ones who learned to “pick winners” in the sense that they develop a keen eye for low-effort/high return work would fare well. Likewise, developers could adjust to their changing needs – taking easy money when they needed money and interesting work when they needed a challenge. If no one wanted a task or project, that would be a good market indicator that the offer was too low. I doubt that there is a labor market for such a prospect, but I’d be curious to see it tried.

The reality is that talent costs rise so much faster than inflation that companies like mine do one of three things: build a product or products to augment the margins slipping from the top line to the payroll line of the income statement, get large and offset lower margins with volume at the cost of quality, or fail. Most fail. These strategies are all patches to an inappropriate business model.

There’s got to be a better way.
My most re-tweeted Tweet ever: “Software clients want to pay by unit of value. Programers want to be paid by unit of effort. Buying and selling hours accomplishes neither.” Perhaps it’s worth a bit of exploration. I warn you, pulmonologist this is a stream-of-consciousness piece that I hope will stimulate creative thinking rather than provide a solution to the problem.

albatrossI own a web development shop. Our business model works like nearly every other web development shop in the world. Our clients pay for developers’ time. We pay our developers for their time. That’s fair only in the sense that it’s apples to apples. Unfortunately, infection the apples aren’t what anyone is interested in. The problem is that no one wants to buy and sell time, really. Our clients want solutions to problems that they consider valuable. If they had their way, they’d have a flexible model whereby they could incrementally buy valuable things (features?) and pay less for each unit of value than they can get for it from their clients/investors/users. In their ideal world, they’d calculate that if they had feature X, then their revenues would grow by $Y and so they’d be happy to pay f($Y) to get that feature.

Programmers, at least the ones I’ve worked with, want one of two things, or perhaps a bit of both. They want freedom to work creatively with good people on interesting and world-changing projects with compensation for the value of their skills (not of their time, effort, or contribution). Alternatively, or in a strange dichotomy that must cause no small amount of cognitive dissonance, they want to clock in and do what they’re told with minimal responsibility for outcomes for a certain number of hours and then get back to their real lives and personal projects.

As an employer, I can say that a big constraint to finding a creative pricing model is labor law. While it is possible as an employer to tell someone “your work today was more valuable then expected, so here’s a bonus” it’s not legal to say “you didn’t bring your ‘A’game today and so you’re getting less then your contractual salary.”

Another crucial consideration is the motivations of the players. In the case of an outsourcing firm like mine, we have three groups of players. Our clients don’t mind paying money, because they have expectations of earning a handsome return on their investment. They know the risk is high, but expect the rewards to justify that risk. However, their returns, if they materialize, are in the distant future and their costs are in the present, and that makes a difference. Then there’s me. I’m odd for an entrepreneur, in that I have no desire to be wealthy. I was born and raised middle class. I have middle class tastes and I like to keep life simple. I do, however, require a positive return, or I can’t have fun owning a software company for long. So I’m looking for stable cash flows. Then there are the developers, who are younger than me, just getting started in their professional lives. I’m old enough to say that even of the folks who have been with me nearly a decade. They want a good job and a stable income. They are pretty risk averse, especially the newlyweds who have just financed a home, so they’ll forgo the promise of riches for a paycheck every month.

Now, how do you make cash flow down this pipeline of divergent needs, interests, and risk thresholds in a way that makes everyone happy?

If everyone got exactly what they most wanted, wise entrepreneurs would pay a high fixed price for the output of top talent, the talent would have control over when and how they worked and would trade some cash flow stability for that freedom so long as their needs were met, and talent brokers like me would do what brokers do — nip a safe and modest profit from the money flowing through our talentless hands.

If we were all the same, with the same needs and interests, the model would be easy. If we all had high risk-tolerances and dreamt of early retirement on a private island I’d run the company as a partnership that works for equity. We’d decide as a team whether to invest our time into a client’s project. No cash would change hands (until the exit/IPO makes us all rich) and we all would sink or swim together. That would be fair to all and perfectly in line with labor codes.

That got me thinking. Perhaps other fair models may follow the same pattern in which the terms of agreement are the same between all three parties. For example, what if projects or bits of projects had fixed prices? That wouldn’t be a problem, economically, if the developers agreed to deliver for a fixed amount. But in that model, all the estimation risk is pushed downhill, which hardly seems fair the the developers. However, recalling that the entrepreneurs expect high returns for their risk and in my experience are willing to pay for top talent, the price per unit of value delivered might be high enough to justify the risk. The client would always get what she wants for the price she wants. I would always make exactly the small margins I require to cover costs and fund growth. The developers would lose when unexpected variation consumed more of their effort than they could have expected, but they’d win when the opposite happened. The most efficient, the hardest-working, and the ones who learned to “pick winners” in the sense that they develop a keen eye for low-effort/high return work would fare well. Likewise, developers could adjust to their changing needs – taking easy money when they needed money and interesting work when they needed a challenge. If no one wanted a task or project, that would be a good market indicator that the offer was too low. I doubt that there is a labor market for such a prospect, but I’d be curious to see it tried.

The reality is that talent costs rise so much faster than inflation that companies like mine do one of three things: build a product or products to augment the margins slipping from the top line to the payroll line of the income statement, get large and offset lower margins with volume at the cost of quality, or fail. Most fail. These strategies are all patches to an inappropriate business model.

There’s got to be a better way.
This will be a really short one, look but as I’ve just written to a friend who’s learning about agile and lean topics on the job and it’s fresh in my mind, tadalafil I’ll share what I think are the most common misconceptions about agile and lean software development.

If you, capsule or anyone to whom you report, believes any of the following, then it’s probably a very good idea to ask an agile coach to help with your agile transformation:

Agile is about delivering fast.
Agile folks welcome chaos (usually takes the form of a boss throwing out random change requirements and saying “Hey, I thought you guys were agile!” when the team complains).
Lean is about eliminating waste and saving money.
Scrum equals agile and agile equals Scrum.
Agile and lean are competing processes.
I’ve been intrigued by the idea of self-guided retrospectives. Imagine motivated teams that could collect and evaluate data and reach valuable conclusions without management guidance!

It appealed to me in more ways than one – firstly, visit this to my principle of empowering teams wherever I can. It also suits my personality. I’m an introverted control-freak, apoplectic which means I risk manipulating situations even when I’d really rather not be involved at all. I’ve come across techniques by which teams could progress through a retrospective themselves, but I face the added complication that many of our projects have at least one remote team member, because our clients are usually in America or Western Europe. I seized on the idea that Kanbanery, our web-based project tracking tool, could be used to facilitate the kinds of interactions that lead to a valuable retrospective. Of course, the approach would work with any online kanban tool that provides live updates.

Our retrospectives with distributed teams were always very traditional, with either no interaction with physical objects (discussion only) or with a local proxy assisting remote participants. There’s value in collecting ideas on cards and manipulating them as a group, but I don’t like the necessity of treating remote team members differently.

Teams in Lunar Logic are using Kanbanery’s real-time updates features to collaborate effectively. Could we use the same familiar tools to hold a retrospective session? The answer came when I applied a TRIZ technique of reducing the environment to its bare essentials and asked what I had to work with within the constraints I set. If you’re of a more philosophical bent, you might say that I asked of Kanbanery: “What is this thing in itself?”

Kanbanery is intended to visualize the flow of work through a process but essentially it is just a series of lists of items which can be moved between columns, both horizontally and vertically.

Items have certain distinguishing features that help organize your work:

  1. A title field with a larger description field,
  2. The avatar of the last person that handled them,
  3. Checklists, type fields, and check marks just in case you need them.

as well as a variety of other features that weren’t required while preparing for a retrospective.

A Kanbanery-powered retrospective

Thinking of Kanbanery as a series of lists gave me the clue I needed to devise the retrospective exercise.

Newly created tasks appear in the first column, so I called it the ‘Working’ column. I labeled the next column ‘Retrospective Steps’ and in it I placed the instruction cards for conducting the retrospective. There are many methods of conducting a retrospective, but the most common is to collect data from team members about the recent history of the project, evaluate their answers, extract useful practices and discard those that were unhelpful and finally to choose a small set of those changes to implement in the next iteration. I created columns for each of these steps.

We used this process for our last Kanbanery retrospective, which I joined from home while I was ill. Here is how it works. The team members sit at laptops in a room together or in their own offices and start a live call via any teleconferencing system (we used Skype). Because of the shared Kanbanery board, all team members are equal and interact with it in the same way.

The team begins to work through the steps listed in the Retrospective Steps column:

  1. They set a timebox for the meeting and write it down in the title of the first card, so everyone knows when the meeting will end,
  2. Everybody reads and all agree to the retrospective prime directive,
  3. Team creates the project history by adding cards and dragging them into the History column in chronological order.

The advantage to using Kanbanery is immediately visible – everyone contributes in his or her own way and time without biasing others. Cards begin appearing like “Got our first paying user”, “Migrated to new test server”, and “Marcin joined the team”. The avatars show who added which tasks.

When the time is up, the team members use the checkmark feature to mark the events in the history that they feel good about. The team can talk over, point by point, any ambiguities during this stage.

Afterwards the team, with the history fresh in their minds, brainstorms about the useful practices that might be associated with the highlights of the recent history, about unhelpful practices that might have led to the pitfalls they faced, and to practices they’d like to consider adding or changing to make future iterations more effective. They do this in the same way in which they built the history, by creating cards with ideas in the Helpful and Unhelpful Practices column.

Next the team talks about the practices listed and agrees on three (or any other number) which they will change going forward and they drag these to the final column, What We Will or Will Not Do. The team can look at these decisions and clarify them in terms of how they will be implemented, by whom, and when. After reaching an agreement, they can capture these ideas by using Kanbanery’s “Export to PDF” function to print the decisions onto index cards easily put on the wall.

Though I participated in the retrospective as a remote member, not only was it a very focused and well-organized retrospective, but also I felt I was actively participating because I could create my own tickets in just the same way the other team members were. The meeting stayed on time, each phase was clear and moved us inexorably to useful conclusions.

Ideally, retrospectives are very interactive activities that take place with everyone in the same room, finding solutions and exposing truths hands-on with appropriate visual tools, but that’s not always possible in this day of remote work and global teams. Here’s a new technique to add to your remote development toolkit. Let us know how it works for you in the comments.
My most re-tweeted Tweet ever: “Software clients want to pay by unit of value. Programers want to be paid by unit of effort. Buying and selling hours accomplishes neither.” Perhaps it’s worth a bit of exploration. I warn you, valeologist this is a stream-of-consciousness piece that I hope will stimulate creative thinking rather than a final solution to the problem.

albatrossI own a web development shop. Our business model works like nearly every other web development shop in the world. Our clients pay for developers’ time. We pay our developers for their time. That’s fair only in the sense that it’s apples to apples. Unfortunately, here the apples aren’t what anyone is interested in. The problem is that no one wants to buy and sell time, really. Our clients want solutions to problems that they consider valuable. If they had their way, they’d have a flexible model whereby they could incrementally buy valuable things (features?) and pay less for each unit of value than they can get for it from their clients/investors/users. In their ideal world, they’d calculate that if they had feature X, then their revenues would grow by $Y and so they’d be happy to pay f($Y) to get that feature.

Programmers, at least the ones I’ve worked with, want one of two things, or perhaps a bit of both. They want freedom to work creatively with good people on interesting and world-changing projects with compensation for the value of their skills (not of their time, effort, or contribution). Alternatively, or in a strange dichotomy that must cause no small amount of cognitive dissonance, they want to clock in and do what they’re told with minimal responsibility for outcomes for a certain number of hours and then get back to their real lives and personal projects.

As an employer, I can say that a big constraint to finding a creative pricing model is labor law. While it is possible as an employer to tell someone “your work today was more valuable then expected, so here’s a bonus” it’s not legal to say “you didn’t bring your ‘A’game today and so you’re getting less then your contractual salary.”

Another crucial consideration is the motivations of the players. In the case of an outsourcing firm like mine, we have three groups of players. Our clients don’t mind paying money, because they have expectations of earning a handsome return on their investment. They know the risk is high, but expect the rewards to justify that risk. However, their returns, if they materialize, are in the distant future and their costs are in the present, and that makes a difference. Then there’s me. I’m odd for an entrepreneur, in that I have no desire to be wealthy. I was born and raised middle class. I have middle class tastes and I like to keep life simple. I do, however, require a positive return, or I can’t have fun owning a software company for long. So I’m looking for stable cash flows. Then there are the developers, who are younger than me, just getting started in their professional lives. I’m old enough to say that even of the folks who have been with me nearly a decade. They want a good job and a stable income. They are pretty risk averse, especially the newlyweds who have just financed a home, so they’ll forgo the promise of riches for a paycheck every month.

Now, how do you make cash flow down this pipeline of divergent needs, interests, and risk thresholds in a way that makes everyone happy?

If everyone got exactly what they most wanted, wise entrepreneurs would pay a high fixed price for the output of top talent, the talent would have control over when and how they worked and would trade some cash flow stability for that freedom so long as their needs were met, and talent brokers like me would do what brokers do — nip a safe and modest profit from the money flowing through our talentless hands.

If we were all the same, with the same needs and interests, the model would be easy. If we all had high risk-tolerances and dreamt of early retirement on a private island I’d run the company as a partnership that works for equity. We’d decide as a team whether to invest our time into a client’s project. No cash would change hands (until the exit/IPO makes us all rich) and we all would sink or swim together. That would be fair to all and perfectly in line with labor codes.

That got me thinking. Perhaps other fair models may follow the same pattern in which the terms of agreement are the same between all three parties. For example, what if projects or bits of projects had fixed prices? That wouldn’t be a problem, economically, if the developers agreed to deliver for a fixed amount. But in that model, all the estimation risk is pushed downhill, which hardly seems fair the the developers. However, recalling that the entrepreneurs expect high returns for their risk and in my experience are willing to pay for top talent, the price per unit of value delivered might be high enough to justify the risk. The client would always get what she wants for the price she wants. I would always make exactly the small margins I require to cover costs and fund growth. The developers would lose when unexpected variation consumed more of their effort than they could have expected, but they’d win when the opposite happened. The most efficient, the hardest-working, and the ones who learned to “pick winners” in the sense that they develop a keen eye for low-effort/high return work would fare well. Likewise, developers could adjust to their changing needs – taking easy money when they needed money and interesting work when they needed a challenge. If no one wanted a task or project, that would be a good market indicator that the offer was too low. I doubt that there is a labor market for such a prospect, but I’d be curious to see it tried.

The reality is that talent costs rise so much faster than inflation that companies like mine do one of three things: build a product or products to augment the margins slipping from the top line to the payroll line of the income statement, get large and offset lower margins with volume at the cost of quality, or fail. Most fail. These strategies are all patches to an inappropriate business model.

There’s got to be a better way.
My most re-tweeted Tweet ever: “Software clients want to pay by unit of value. Programers want to be paid by unit of effort. Buying and selling hours accomplishes neither.” Perhaps it’s worth a bit of exploration. I warn you, click this is a stream-of-consciousness piece that I hope will stimulate creative thinking rather than provide a solution to the problem.

albatrossI own a web development shop. Our business model works like nearly every other web development shop in the world. Our clients pay for developers’ time. We pay our developers for their time. That’s fair only in the sense that it’s apples to apples. Unfortunately, sick the apples aren’t what anyone is interested in. The problem is that no one wants to buy and sell time, diagnosis really. Our clients want solutions to problems that they consider valuable. If they had their way, they’d have a flexible model whereby they could incrementally buy valuable things (features?) and pay less for each unit of value than they can get for it from their clients/investors/users. In their ideal world, they’d calculate that if they had feature X, then their revenues would grow by $Y and so they’d be happy to pay f($Y) to get that feature.

Programmers, at least the ones I’ve worked with, want one of two things, or perhaps a bit of both. They want freedom to work creatively with good people on interesting and world-changing projects with compensation for the value of their skills (not of their time, effort, or contribution). Alternatively, or in a strange dichotomy that must cause no small amount of cognitive dissonance, they want to clock in and do what they’re told with minimal responsibility for outcomes for a certain number of hours and then get back to their real lives and personal projects.

As an employer, I can say that a big constraint to finding a creative pricing model is labor law. While it is possible as an employer to tell someone “your work today was more valuable then expected, so here’s a bonus” it’s not legal to say “you didn’t bring your ‘A’game today and so you’re getting less then your contractual salary.”

Another crucial consideration is the motivations of the players. In the case of an outsourcing firm like mine, we have three groups of players. Our clients don’t mind paying money, because they have expectations of earning a handsome return on their investment. They know the risk is high, but expect the rewards to justify that risk. However, their returns, if they materialize, are in the distant future and their costs are in the present, and that makes a difference. Then there’s me. I’m odd for an entrepreneur, in that I have no desire to be wealthy. I was born and raised middle class. I have middle class tastes and I like to keep life simple. I do, however, require a positive return, or I can’t have fun owning a software company for long. So I’m looking for stable cash flows. Then there are the developers, who are younger than me, just getting started in their professional lives. I’m old enough to say that even of the folks who have been with me nearly a decade. They want a good job and a stable income. They are pretty risk averse, especially the newlyweds who have just financed a home, so they’ll forgo the promise of riches for a paycheck every month.

Now, how do you make cash flow down this pipeline of divergent needs, interests, and risk thresholds in a way that makes everyone happy?

If everyone got exactly what they most wanted, wise entrepreneurs would pay a high fixed price for the output of top talent, the talent would have control over when and how they worked and would trade some cash flow stability for that freedom so long as their needs were met, and talent brokers like me would do what brokers do — nip a safe and modest profit from the money flowing through our talentless hands.

If we were all the same, with the same needs and interests, the model would be easy. If we all had high risk-tolerances and dreamt of early retirement on a private island I’d run the company as a partnership that works for equity. We’d decide as a team whether to invest our time into a client’s project. No cash would change hands (until the exit/IPO makes us all rich) and we all would sink or swim together. That would be fair to all and perfectly in line with labor codes.

That got me thinking. Perhaps other fair models may follow the same pattern in which the terms of agreement are the same between all three parties. For example, what if projects or bits of projects had fixed prices? That wouldn’t be a problem, economically, if the developers agreed to deliver for a fixed amount. But in that model, all the estimation risk is pushed downhill, which hardly seems fair the the developers. However, recalling that the entrepreneurs expect high returns for their risk and in my experience are willing to pay for top talent, the price per unit of value delivered might be high enough to justify the risk. The client would always get what she wants for the price she wants. I would always make exactly the small margins I require to cover costs and fund growth. The developers would lose when unexpected variation consumed more of their effort than they could have expected, but they’d win when the opposite happened. The most efficient, the hardest-working, and the ones who learned to “pick winners” in the sense that they develop a keen eye for low-effort/high return work would fare well. Likewise, developers could adjust to their changing needs – taking easy money when they needed money and interesting work when they needed a challenge. If no one wanted a task or project, that would be a good market indicator that the offer was too low. I doubt that there is a labor market for such a prospect, but I’d be curious to see it tried.

The reality is that talent costs rise so much faster than inflation that companies like mine do one of three things: build a product or products to augment the margins slipping from the top line to the payroll line of the income statement, get large and offset lower margins with volume at the cost of quality, or fail. Most fail. These strategies are all patches to an inappropriate business model.

There’s got to be a better way.
My most re-tweeted Tweet ever: “Software clients want to pay by unit of value. Programers want to be paid by unit of effort. Buying and selling hours accomplishes neither.” Perhaps it’s worth a bit of exploration. I warn you, heart this is a stream-of-consciousness piece that I hope will stimulate creative thinking rather than provide a solution to the problem.

albatrossI own a web development shop. Our business model works like nearly every other web development shop in the world. Our clients pay for developers’ time. We pay our developers for their time. That’s fair only in the sense that it’s apples to apples. Unfortunately, visit the apples aren’t what anyone is interested in. The problem is that no one wants to buy and sell time, viagra sale really. Our clients want solutions to problems that they consider valuable. If they had their way, they’d have a flexible model whereby they could incrementally buy valuable things (features?) and pay less for each unit of value than they can get for it from their clients/investors/users. In their ideal world, they’d calculate that if they had feature X, then their revenues would grow by $Y and so they’d be happy to pay f($Y) to get that feature.

Programmers, at least the ones I’ve worked with, want one of two things, or perhaps a bit of both. They want freedom to work creatively with good people on interesting and world-changing projects with compensation for the value of their skills (not of their time, effort, or contribution). Alternatively, or in a strange dichotomy that must cause no small amount of cognitive dissonance, they want to clock in and do what they’re told with minimal responsibility for outcomes for a certain number of hours and then get back to their real lives and personal projects.

As an employer, I can say that a big constraint to finding a creative pricing model is labor law. While it is possible as an employer to tell someone “your work today was more valuable then expected, so here’s a bonus” it’s not legal to say “you didn’t bring your ‘A’game today and so you’re getting less then your contractual salary.”

Another crucial consideration is the motivations of the players. In the case of an outsourcing firm like mine, we have three groups of players. Our clients don’t mind paying money, because they have expectations of earning a handsome return on their investment. They know the risk is high, but expect the rewards to justify that risk. However, their returns, if they materialize, are in the distant future and their costs are in the present, and that makes a difference. Then there’s me. I’m odd for an entrepreneur, in that I have no desire to be wealthy. I was born and raised middle class. I have middle class tastes and I like to keep life simple. I do, however, require a positive return, or I can’t have fun owning a software company for long. So I’m looking for stable cash flows. Then there are the developers, who are younger than me, just getting started in their professional lives. I’m old enough to say that even of the folks who have been with me nearly a decade. They want a good job and a stable income. They are pretty risk averse, especially the newlyweds who have just financed a home, so they’ll forgo the promise of riches for a paycheck every month.

Now, how do you make cash flow down this pipeline of divergent needs, interests, and risk thresholds in a way that makes everyone happy?

If everyone got exactly what they most wanted, wise entrepreneurs would pay a high fixed price for the output of top talent, the talent would have control over when and how they worked and would trade some cash flow stability for that freedom so long as their needs were met, and talent brokers like me would do what brokers do — nip a safe and modest profit from the money flowing through our talentless hands.

If we were all the same, with the same needs and interests, the model would be easy. If we all had high risk-tolerances and dreamt of early retirement on a private island I’d run the company as a partnership that works for equity. We’d decide as a team whether to invest our time into a client’s project. No cash would change hands (until the exit/IPO makes us all rich) and we all would sink or swim together. That would be fair to all and perfectly in line with labor codes.

That got me thinking. Perhaps other fair models may follow the same pattern in which the terms of agreement are the same between all three parties. For example, what if projects or bits of projects had fixed prices? That wouldn’t be a problem, economically, if the developers agreed to deliver for a fixed amount. But in that model, all the estimation risk is pushed downhill, which hardly seems fair the the developers. However, recalling that the entrepreneurs expect high returns for their risk and in my experience are willing to pay for top talent, the price per unit of value delivered might be high enough to justify the risk. The client would always get what she wants for the price she wants. I would always make exactly the small margins I require to cover costs and fund growth. The developers would lose when unexpected variation consumed more of their effort than they could have expected, but they’d win when the opposite happened. The most efficient, the hardest-working, and the ones who learned to “pick winners” in the sense that they develop a keen eye for low-effort/high return work would fare well. Likewise, developers could adjust to their changing needs – taking easy money when they needed money and interesting work when they needed a challenge. If no one wanted a task or project, that would be a good market indicator that the offer was too low. I doubt that there is a labor market for such a prospect, but I’d be curious to see it tried.

The reality is that talent costs rise so much faster than inflation that companies like mine do one of three things: build a product or products to augment the margins slipping from the top line to the payroll line of the income statement, get large and offset lower margins with volume at the cost of quality, or fail. Most fail. These strategies are all patches to an inappropriate business model.

There’s got to be a better way.
My most re-tweeted Tweet ever: “Software clients want to pay by unit of value. Programers want to be paid by unit of effort. Buying and selling hours accomplishes neither.” Perhaps it’s worth a bit of exploration. I warn you, pulmonologist this is a stream-of-consciousness piece that I hope will stimulate creative thinking rather than provide a solution to the problem.

albatrossI own a web development shop. Our business model works like nearly every other web development shop in the world. Our clients pay for developers’ time. We pay our developers for their time. That’s fair only in the sense that it’s apples to apples. Unfortunately, infection the apples aren’t what anyone is interested in. The problem is that no one wants to buy and sell time, really. Our clients want solutions to problems that they consider valuable. If they had their way, they’d have a flexible model whereby they could incrementally buy valuable things (features?) and pay less for each unit of value than they can get for it from their clients/investors/users. In their ideal world, they’d calculate that if they had feature X, then their revenues would grow by $Y and so they’d be happy to pay f($Y) to get that feature.

Programmers, at least the ones I’ve worked with, want one of two things, or perhaps a bit of both. They want freedom to work creatively with good people on interesting and world-changing projects with compensation for the value of their skills (not of their time, effort, or contribution). Alternatively, or in a strange dichotomy that must cause no small amount of cognitive dissonance, they want to clock in and do what they’re told with minimal responsibility for outcomes for a certain number of hours and then get back to their real lives and personal projects.

As an employer, I can say that a big constraint to finding a creative pricing model is labor law. While it is possible as an employer to tell someone “your work today was more valuable then expected, so here’s a bonus” it’s not legal to say “you didn’t bring your ‘A’game today and so you’re getting less then your contractual salary.”

Another crucial consideration is the motivations of the players. In the case of an outsourcing firm like mine, we have three groups of players. Our clients don’t mind paying money, because they have expectations of earning a handsome return on their investment. They know the risk is high, but expect the rewards to justify that risk. However, their returns, if they materialize, are in the distant future and their costs are in the present, and that makes a difference. Then there’s me. I’m odd for an entrepreneur, in that I have no desire to be wealthy. I was born and raised middle class. I have middle class tastes and I like to keep life simple. I do, however, require a positive return, or I can’t have fun owning a software company for long. So I’m looking for stable cash flows. Then there are the developers, who are younger than me, just getting started in their professional lives. I’m old enough to say that even of the folks who have been with me nearly a decade. They want a good job and a stable income. They are pretty risk averse, especially the newlyweds who have just financed a home, so they’ll forgo the promise of riches for a paycheck every month.

Now, how do you make cash flow down this pipeline of divergent needs, interests, and risk thresholds in a way that makes everyone happy?

If everyone got exactly what they most wanted, wise entrepreneurs would pay a high fixed price for the output of top talent, the talent would have control over when and how they worked and would trade some cash flow stability for that freedom so long as their needs were met, and talent brokers like me would do what brokers do — nip a safe and modest profit from the money flowing through our talentless hands.

If we were all the same, with the same needs and interests, the model would be easy. If we all had high risk-tolerances and dreamt of early retirement on a private island I’d run the company as a partnership that works for equity. We’d decide as a team whether to invest our time into a client’s project. No cash would change hands (until the exit/IPO makes us all rich) and we all would sink or swim together. That would be fair to all and perfectly in line with labor codes.

That got me thinking. Perhaps other fair models may follow the same pattern in which the terms of agreement are the same between all three parties. For example, what if projects or bits of projects had fixed prices? That wouldn’t be a problem, economically, if the developers agreed to deliver for a fixed amount. But in that model, all the estimation risk is pushed downhill, which hardly seems fair the the developers. However, recalling that the entrepreneurs expect high returns for their risk and in my experience are willing to pay for top talent, the price per unit of value delivered might be high enough to justify the risk. The client would always get what she wants for the price she wants. I would always make exactly the small margins I require to cover costs and fund growth. The developers would lose when unexpected variation consumed more of their effort than they could have expected, but they’d win when the opposite happened. The most efficient, the hardest-working, and the ones who learned to “pick winners” in the sense that they develop a keen eye for low-effort/high return work would fare well. Likewise, developers could adjust to their changing needs – taking easy money when they needed money and interesting work when they needed a challenge. If no one wanted a task or project, that would be a good market indicator that the offer was too low. I doubt that there is a labor market for such a prospect, but I’d be curious to see it tried.

The reality is that talent costs rise so much faster than inflation that companies like mine do one of three things: build a product or products to augment the margins slipping from the top line to the payroll line of the income statement, get large and offset lower margins with volume at the cost of quality, or fail. Most fail. These strategies are all patches to an inappropriate business model.

There’s got to be a better way.
This will be a really short one, look but as I’ve just written to a friend who’s learning about agile and lean topics on the job and it’s fresh in my mind, tadalafil I’ll share what I think are the most common misconceptions about agile and lean software development.

If you, capsule or anyone to whom you report, believes any of the following, then it’s probably a very good idea to ask an agile coach to help with your agile transformation:

Agile is about delivering fast.
Agile folks welcome chaos (usually takes the form of a boss throwing out random change requirements and saying “Hey, I thought you guys were agile!” when the team complains).
Lean is about eliminating waste and saving money.
Scrum equals agile and agile equals Scrum.
Agile and lean are competing processes.
I was just re-reading Clifford Geertz’ most famous essay while on holiday and the opening passage, buy which I can’t resist quoting in full, diagnosis takes on a new significance for me after a decade of watching “agile” and then “lean” strive to change the faces of IT.

Put on your “agile” hat and give this a read:

In her book, hospital Philosophy in a New Key, Susanne Langer remarks that certain ideas burst upon the intellectual landscape with a tremendous force. They resolve so many fundamental problems at once that they seem also to promise that they will resolve all fundamental problems, clarify all obscure issues. Everyone snaps them up as the open sesame of some new positive science, the conceptual center-point around which a comprehensive system of analysis can be built. The sudden vogue of such a grande idee, crowding out almost everything else for a while, is due, she says, “to the fact that all sensitive and active minds turn at once to exploiting it. We try it in every connection, for every purpose, experiment with possible stretches of its strict meaning, with generalizations and derivatives.”

After we have become familiar with the new idea, however, after it has become part of our general stock of theoretical concepts, our expectations are brought more into balance with its actual uses, and its excessive popularity is ended. A few zealots persist in the old key-to-the-universe view of it; but less driven thinkers settle down after a while to the problems the idea has really generated. They try to apply it and extend it where it applies and where it is capable of extension ; and they desist where it does not apply or cannot be extended. It becomes, if it was, in truth, a seminal idea in the first place, a permanent and enduring part of our intellectual armory. But it no longer has the grandiose, all-promising scope, the infinite versatility of apparent application, it once had.

The second law of thermodynamics, or the principle of natural selection, or the notion of unconscious motivation, or the organization of the means of production does not explain everything, not even everything human, but it still explains something; and our attention shifts to isolating just what that something is, to disentangling ourselves from a lot of pseudoscience to which, in the first flush of its celebrity, it has also given rise.

-taken from “Thick Description: Toward an Interpretive Theory of Culture” by Clifford Geertz

{ 0 comments }