Thursday, August 04, 2016

Software development is upside down


In the software development world a number of common management maxims need to be reversed if one is to be an effective manager. Those who manage software development - and I include all the non-commissioned managers in this, Architects, Team Leads, Scrum Masters etc. - need to turn their thinking upside down.

Here are a few I spot all the time but I’m sure there are more:

  1. Diseconomies of scale: larger teams are less productive per worker than smaller teams, larger code bases are more expensive to maintain (enhance, debug, change) than smaller code bases per unit of code, large requirement requests (documents) are more expensive per request than small requests and so on.
  2. Higher quality is faster, there is no such things as “quick and dirty”: delivering quality work is faster than delivering shoddy work because shoddy work needs fixing. Even if the first low quality piece of work does arrive more quickly, the second will be take longer down because the first gets in the way. Each shoddy piece of work will cost more because subsequent work will take longer.

Software product has many “qualities”: functionality, speed of execution, usability, etc. etc. What constitutes quality varies from product to product however… all software products exhibit two qualities in common: number of defects (bugs) and ease of maintenance (maintainability). When I talk about quality it is these last two items I am talking about.

Whenever you find a high performing software team you find a high quality code base (low defects, high maintainability). Hardly surprising if you have read the work of Capers Jones and Kent Beck.

  1. Teams over individuals: There are times when a lone developer who can sitting up all night and deliver a world beating product. Particularly at the start of a new technology: think Nick D'Aloisio writing Summly, Matthew Smith writing Manic Miner, or Dan Bricklin and Bob Frankston writing VisiCalc in two months.

We admire people like D’Aloisio, Smith and Bricklin but they are poor role models. Most serious software development is a team sport. The characteristics which make the lone developer successful are a disadvantage. Managers who believe in the Lone Hero Developer model do everyone a disservice.

The constraint in developing software is not typing speed, it is thinking speed. We need people who can share, who can discuss, who can work together. That is why Pair Programming can be far more effective than solo programming and why Mob Programming is on the rise.

  1. Doing is the quickest way of learning: when processor cycles were expensive and difficult to get (think 1970, IBM mainframes, OS/360, IMS hierarchical databases and less than a dozen internet nodes) it made sense to think through every possible angle before developing something. Back then most systems were a lot smaller than they are today.

Today processor cycles are cheap, you have more CPU power in your pocket than Neil and Buzz took to the moon.

The quickest way to find out if a technology can do something, the quickest way to learn a technology, and the quickest way to find out what customers think is to just do something and see what happens.

There is a place for planning, but planning has rapidly diminishing returns. A little bit of planning is valuable, but a lot is counter productive: the return from lots of planning is minimal and it delays learning by doing.

  1. Do it right, then do the right thing: modern development is inherently iterative. If a team can’t iterate they cannot perform. If we are to learn by doing we must iterate: plan a little, do a little, review the results, plan a little, do a little….

“Customers don’t know what they want until they see it”

Or perhaps:

“Companies don’t know what will succeed in the market until they ask people to part with money.”

Again and again we see that customers need to be shown something in order to understand what a product can do for them. And again and again we see that until a product is in the market and customers are asked to exchange money for it the true value, the ultimate “doneness” cannot be judged.

Only when we are in the market, only by showing what we have, can we refine our ideas of what is needed and what is valuable. And when we have this information it is through iteration that we act on it.

If the team can’t iterate (do it right) then they have no way of learning and validating their plans. Sure, doing the wrong thing effectively is pointless, but the only way to find out what is right and what is wrong is to do something, anything, and iterate.

  1. Worse is better: the famous Dick Gabriel from 1989:

“the idea that quality does not necessarily increase with functionality—that there is a point where less functionality ("worse") is a preferable option ("better") in terms of practicality and usability. Software that is limited, but simple to use, may be more appealing to the user and market than the reverse.”

Sometimes creating a worse product is a more effective strategy than creating a better product. Building a better mouse trap is rarely the route to success.

To a business mind this maxim sometimes seems obvious but to an engineering mind it is shocking.

And this final maxim means that all of the above propositions are sometimes reversed.

(Many thanks to Seb Rose for comments on an earlier draft of this post.)

Tuesday, August 02, 2016

Zen'in keiei - more Japanese - every person a manager

There are a few words of Japanese that have permeated the lingo of Agile and Lean folk - Kanban and Kaizen being probably the two best know. Well, I recently discovered another one I think we should embrace.

A family friend works at Uniqlo in Moscow and I recently noticed a Japanese word on her LinkedIn profile and so I asked:

Zen'in keiei

This translates, broadly as: every person participates in decision making.

At Uniqlo - and it seems to be a Uniqlo only concept - this means "everyone manages", every staff member should be a business leader, act like owner, like manager, participate in decision making.

There are other explanations of this elsewhere on the Internet:

“Being the main players in the company, at all level” (Uniqlo values statement.)

“UNIQLO’s Zen-in Keiei philosophy, under which every employee adopts the mindset of a business manager, regardless of his or her position.” (Uniqlo HR documentation.)

“Zen-in Keiei: Everybody as a business leader...everybody should feel accountability and ownership as a part of UNIQLO” (Quizlet)

"One of the reasons for Uniqlo’s success in Japan is the notion of ‘zen-in keiei,’ which translates to “everyone as a business leader.” In Japan, people who are hired in the stores are told that they are a part of management, that they make very important decisions, and that they have the potential of making it all the way to the top. I think this concept is very foreign outside of Japan." Professor Hirotaka Takeuchi quoted on Reilly Brennan’s blog

Hopefully that give you a better idea of what we are talking about. I like the idea that everyone is in part a business leader and manager.

And look at that last quote, look at who said it, Hirotaka Takeuchi, better know to me as one of the authors of The Knowledge Creating Company and better know to many in the Agile community as one of the two authors of The New New Product Development Game.

I think this idea fits right in with how decisions are made in an effective modern (agile) software development environment. Its not about management, its about pushing authority and decisions down to the most appropriate level, and that level is the level the people actually doing the work - the people who are faced with the decision here and now.

These people need a decision now, and they have the most information about wha needs to be decided. Managers should be there to help them make good decisions not to make he decisions for them.

If this is good in a shop, in a retail environment, then isn’t it good for highly skilled technology workers?

This doesn’t remove the need for managers or management structures but it does change what management does - see my management series from earlier this year. And it also implies that many of those doing the work need more understanding of business and management and they need management skills - management for the masses!

Thursday, July 21, 2016

Magic software dust or a bashed up Peugeot?


Creating a new software application… is that a glass is half-full or a glass is half-empty thing to you?

Does the thought of actually employing programmers fill you with joy or with dread?

Get it right and software technology is magical, get it right and software technology can change the world.

The browser you are reading these words with.

The phone in your pocket.

The GPS signal which will help you go… well… anywhere!

Some technology is absolutely magical. And some software development teams are absolutely magical. They really can get things done - “hyper productive” as they say. The Alpha AXP compiler team (“commitment management”) or the Quattro Pro development team are two of my favourite better known teams but I know a few others who nobody will ever hear of.

Done right software technology is like magic dust, a little bit of software sprinkled about in the right place, in the right way and Magic!

But many, probably most, never experience this. Such people don’t know how good it can be.

The science fiction author Iain M Banks novel Excession is about an “outside context problem” - a situation which is so far outside ones experience that one cannot even start to comprehend it.

For people who’ve never seen a great software team it can be hard to comprehend what software development can be. The closest these people ever get it is using Google Maps on their iPhone to find a beer.

This is sad, so sad, because it colours peoples view: software development is seen as an expensive painful exercise destined to disappoint.

Most teams aren’t hyper-productive, rather than working on a mission to change the world they remind me of an old Peugeot 206 advert - its on YouTube:

If you’ve not seen it it goes like this: Man looks at a picture of a beautiful Peugeot 206 car in a magazine. He looks at his old heap… and then sets about smashing his car up, driving it into a wall or two, then setting about it with a hammer while people laugh at him.

At the end of the advert his old car kind of resembles the Peugoet 206 - it helps if you squint.

Unfortunately an awful lot of software teams seem to be stuck in this model. They seem intent on smashing something into the shape they want rather than building it right.

Things can be better, so very much better.

Those who believe software is a painful glass-half-empty exercise make it worse for themselves:

  • they try to constrain the builder by giving them a long elaborate “requirements” document
  • they sign contracts to protect themselves, they specify what, when, how much and even how
  • they drive price down because at least it if costs less the pain will be less which often means things end up in some cheap offshore location, out-of-sight, out-of-mind, out-of-control
  • they compromise on quality left, right and centre
  • quantity over quality is the mantra
  • and they blame the coders: after all, everyone knows they are a bolshy bunch opinionated overpaid factory line workers (think Red Robbo) who always mess up

In making these assumptions, in protecting themselves from these beliefs the glass-is-half-empty people create a self-fulfilling prophecy. Each and every one of these actions will make the development process worse.

On the other side, those who see magic at work see software development as a glass-is-half-full thing and will work with the team who understand what is needed, they will be flexible on expectations and they will understand that high quality is faster and cheaper, they will see the development team are experts in the technology and how the technology can deliver benefit.

This too is a self-fulfilling prophecy. Treat the team as adults and they will respond as adults.

Its up to you: your beliefs will determine the result.

Tuesday, July 19, 2016

Surge or pivot? - notes on failure

Failure is good.

We learn from failure.

Failure is learning; the information content of a failure may be more than the information content of success.

Failure isn’t failure, it’s an opportunity to pivot.

Failure is capitalism’s Darwinian evolutionary mechanism to remove the less productive, the less relevant.

Fail fast, fail cheap, learn, try again.

Creative Destruction is the way capitalism remove legacy companies to create space for the new by allowing resources to be redeployed.

All true… well at least to some degree but lets not argue about that today.

The problem is: How do you know you’ve failed?

Or to put it another way: What does failure look like?

Or: When do you know its time to pivot?

Some failures are clear cut: customers don’t buy your product, or too few customers buy your product to allow you to stay in the market.

Our software does not perform as expected, it doesn’t process transactions fast enough, or a rocket blows up.

As engineers we like clear cut failure and success. We look for clear failures or at least clear bottlenecks if only because we are certain they exist. But that isn’t always the case. Sometimes there are no clear success or failure states. And sometimes we don’t call it a failure because we really think we can make it work.

Rationally the business plan or strategy should allow us to know what success loos like and what failure looks like. But what if the strategy is itself flawed?

Flawed strategy might be obvious to one person but hidden to another. When strategy is flawed it runs like a fault-line under everything that is being done. One clue is that lots of little failures keep appearing, seemingly unconnected perhaps but actually connected because they are originate in the fault line.

(Think if this like a stack corruption bug, you don’t normally know you’ve got stack corruption but you get apparently random failures. When you chase these failures they move. Back when I was still programming I knew I had stack corruption because the fault moved every time I thought I was getting close.)

Even when surrounded by failure we look to explain it away, we believe (hope?) we can fix it - after all, we are learning from those failures and we are trying to fix them aren’t we? And people like me (consultants!) asked to help you address your problems and fix your faults.

But when do you call time? When do you say things are irreparable? When do you stop trying?

To use a better know example: When is a war won? And when is it lost?

In 1945 Victory meant the Allies taking Berlin. Once Berlin was taken and the genocidal Government was disposed the war was over.

In 1991 Victory meant retaking Kuwait.

Afghanistan 2015? - some say success, the west was victorious! and some say it was a failure. Failure and success is not clear cut. For the generals and politicians its hard to walk away from a failured war, far better to find some success, get out and disown the subsequent failure - like the 1973-1975 gap in the fall of Vietnam.

Since failure is not clear, and especially since victory could be grasped out of the jaws of defeat by calling in more troops, more consultants, better consultants, more expensive consultants how do we know it is time to pivot?

When do we pivot and when do we surge?

And since failure is still failure, and no matter how much we call it a pivot or repeat that we learn from failure we still don’t like it; when, o when, do we call failure failure and when do we call it pivot?

And like Generals, Senior Managers can’t walk away from a failure, that would be career threatening. Far better to surge, get to something which looks like victory, get out and disown what happens next. (If you are spending your own money you have an incentive to get out quick, if you are spending someone elses money…).

When pivoting is unattractive, when pivoting means people loose jobs, when pivoting means executives have to explain to their board, when pivoting means shaman consultants no longer take their cut… why pivot when you can surge?

Surge - call for help.

When we are failing without a clear cut failure we see problem after problem and each one is explained away.

When do you declare failure and pivot?

Undercover Economist Tim Hartford had a good piece recently: “You don’t know when to quit”. The true grit, carry on trying idea doesn’t seem to stand up to analysis. Rather than persevering at something difficult a better strategy might be to try something else.

The more money that has been sunk into the initiate the greater the difficulty in pivoting - nobody likes sunk costs, why sink the money?

For a Silicon Valley start-up living on credit cards illusions are painful, there can be very little tolerance for failure, failure must result in a pivot or death.

But for a corporation, for an established vendor, a brand, a reputation; failure might mean they are simply not trying hard enough - and heaven knows some companies tie themselves in knots. Why not through more money at the problem? More people, more experts - surge!

And so we are back to Do it Right and then Do the Right Thing (blog) (and Do Things Right Thing and then Do the Right Thing presentation.)

For a software team capability means: delivering working software. If you can’t deliver working software you have a clear failure. But if you are delivering software slowly, so, slowly, how do you know? What software developer or product manager hasn’t wanted to deliver more faster?

If you lack the capability to iterate then you can’t deliver.

If you lack the capability to iterate you cannot build feedback loops.

If you can’t build feedback loops then you cannot validate your market or your product.

If you can’t validate product or market then your strategy is high risk.

If your strategy is high risk then you really need a high pay-off to justify it. But if you can’t iterate then its likely your costs are going to absorb far more of that pay-off.

You might be able to buy victory but the price will be so high it is worth asking: is it a victory you want? Is it a victory you can recognise?

Tuesday, July 05, 2016

Using cost of delay to determine schedule

“When does the business need it?” is far more important than “When will the developers have it ready?”. Business needs should drive schedules, engineers need to create solutions which fit within business schedules. That does not mean cutting corners, it does not mean shipping with bugs or technical debt. Its the art of the possible and its what engineers have always done.

One of the tenets of #NoProjects is that work should be guided by business benefit, better still value delivered.

That very quickly means that one need to start talking about opportunity cost of delay. As I’ve said before, I don’t think “cost of delay” is the best name for this idea, (I’d rather it was called something like “benefit foregone through delay” but cost of delay is the name we have.)

Once one starts discussing business value and how potential revenue changes over time it very quickly becomes clear that business need and value should drive the development schedule not developer estimates.

Rather than saying:

"How long will X take to build?"

We need to be saying:

"Given that there is M money to capture, in timeframe T, what can we build for that much money in that much time and have a respectable profit left?"

Time and money are inherently linked. Everyone gets that more time creates more costs but fewer people get that more time probably means less revenue.

To put this more succinctly

"How much of X can we build in time Y and how much of the total potential value M will that capture?"

Lets me do an example analysts to show how a cost of delay analysis - with value estimates - can be used to substitute effort estimates. So here goes, I'm putting on my economist hat... lets set up the scenario…

Image its Christmas 2016, at one of those family gathering you see Uncle George who works for a successful start-up. George says the back-end he has been working on is great and has a nice REST API. The start-up wants to grow an ecosystem and the company is about to open the API up to third party apps. The startup will pay a small "finders fee" from 1 February for the first few months to each of these third parties for each customer they bring in.

Back in the office on 2 January you make some calls and find everything Uncle George said is true. In fact the start-up is falling over himself to help you, they are desperate for apps.

You have an opportunity. And you have at least a four week head start on any competitor.

Some quick "what if" calculations tell you there is €10,000 a week to be made. But you also know that competitors will come into the market the finders fee will decline. As you have a 4 week head start you probably have 4 weeks from the start of February before your revenue starts to fall off.

Some more analysis and you conclude competitors will steal increasing chunks of your revenue, you think it will decline €1,000 a week after February. Thus you can draw the following graph:


The blue bars show the weekly revenue. The red line shows the total lifetime revenue - the lifetime being from the start of February to early May. What happens after May is uncertain so to play it safe you have assumed no revenue at all.

The red line is important - note: this chart uses two axis, the one on the left is for the blue bars, the one on the right for the red line. The red line shows the maximum revenue you could make, it forms an upper boundary.

It doesn't matter whether you release your product tomorrow or 31 January, there is no extra revenue to be made during January. As long as you have a product in the market on 1 February you can start to capture some value. If you have a fully functional product then you can capture €10,000 a week.

Yes the delivery date is important, earlier is better, but so is the amount of product. Since revenue declines from March onwards delivering something smaller sooner may well make more total revenue than delivering more later. Less (functionality) may well mean more (revenue).

As you can see, releasing a product anytime before the end of January will result in €85,000 of revenue in total. After this the later the product is released the less revenue if will make. Your deadline is not a binary event, it is an elastic range of options which each produce a different outcomes.

Time is money but money is both cost and revenue: The longer you spend developing your product the greater the costs, but more importantly if the product is not in the market by 1 February you are loosing revenue. The longer you go without a product the greater the costs and the lower the revenue.

This is a simple model, like any good economist I have confined my analysis. I have assumed "all other things being equal", specifically I have assumed other competitors do not spot the opportunity before 1 February; I have assumed your product could grab the entire market on day-1 without a ramp up time; I have also assumed that even launching in March, when there are other competitors in the market you can still grab sizeable market share an day-1.

These assumptions do not invalidate the model. These assumptions may all be relaxed with a more complex model but the basic message will still be the same.

This analysis does not use any effort estimates. It does use value estimates. So lets now consider effort.

In the first instance, armed with this analysis, you go to you development team and instead of saying:

"How long will it take to build this?"

You say

"Given this analysis, what can we build in the next four weeks which can capture some of this value?"

It is not a question of: "Can you build X?"" but "What can you build in this time for this much money?"

Lets suppose you and the team quickly envisage a product, a product that can be rolled out in stages, say 10% per week. Even the first 10% will be useful. Lets assume a perfect correlation between the percentage of product built and the revenue captured and lets add this to the model.


Notice in this model it is impossible to capture all the €85,000 potential revenue because the product cannot be ready in full on 1 February. If you wait until the product is 100% complete before releasing it will be mid-March and you will only make €28,000 in total. This contrasts with the €64,400 you could make by launching with reduced functionality earlier, i.e. launching a smaller incomplete product earlier allows the capture of €36,400 more.

As I said before I could relaxed some of my assumptions and enhance the model but I’m keeping this simple.

You can also play what if games, for example, what if you halted development at the half way point?

  • If development halted at the beginning of February at 50% done
  • and the product remained in use until May
  • then it would generate €41,500 of revenue (64% of the total that could be made)
  • This does not consider the savings in development costs. Perhaps more significantly, the same people would be available to work on something with greater returns.

After all the product only has an anticipated lifespan of three months. Once March arrives the product revenues are falling, why would continue to invest?

There are many directions you can take this analysis and I’m not denying the effort and cost estimates have a role to play in the complete analysis. However benefit estimates and cost of delay analysis can be performed without any effort estimates, when value analysis is available it can be used to inform the effort estimation process.

Monday, July 04, 2016

#NoProjects: an update

Several things have been happening in the #NoProjects world of late it seems fitting to record these things here.

  1. As mentioned recently Evan Leybourn has created a NoProjects website. This is becoming a repository of various NoProjects things.
  2. At the moment the NoProjects website is little more than a placeholder for a Slack community.
  3. After months of saying “No I will not write a book” I’ve started to write a #NoProjects book. This is currently an early stage LeanPub endeavour. You can sign up for notification at the moment, I’m still drafting and getting my thoughts together. When it does start to appear it will be in the classic LeanPub form: small and growing.

Monday, June 27, 2016

Servants, not leaders, not managers

Sharp eyed readers of my management mini-series will have noticed I referred to managers doing administration several times, Peter Hilton mailed me to ask me more about this. Let me image such a manager, let me imagine the worst possible scenario…

This manager spends a lot of time involved in admin. Finance forms a lot of this, juggling a budget, allocating “resources” (people to you and me), calculating totals, staying within limits. Some of this is straight admin, it could be done by anyone semi-competent with spreadsheet but some of this work demands knowledge of what the organization is trying to do and, importantly it demands authority. Would you like your team composition to be determined by a finance clerk?

While the manipulation of the spreadsheet could be done by a finance clerk the result would not have the same authority. At the very least the clerk would to work under the direction of someone with authority.

Some of the work requires authority too because the organization has put a number of checks in place which require authority to overcome. Purchase orders need to be raised, but to raise them statement of works need to be raised, and once raised these artefacts require authority to approve them. The approval authority rests several steps up the management chain but it is not possible to jump to the top, the higher levels only give authority when the lower levels have.

And sometimes the machine breaks down and someone needs to use chase, and sometimes chasing requires authority.

In fact it appears the more the organization has tried to streamline its internal processes the more authority is needed to make anything happen. A finance clerk breaking rules and pushing senior staff for authorization wouldn’t get far, they may even be viewed as a fraud problem.

This hypothetical manager spends a chunk of his day in discussing seating plans. Such work could be devolved to teams but why disturb busy programmers and testers with seating plans of little interest too them?

Such work could he given to an office administrator or a personal assistance (if he had one). But who would like their desk decided by a secretary?

And if you have several self-organizing teams who is going to resolve conflicts? Who is going to represent the teams when they need to ask for more space?

Our hypothetical manage spends a lot of time on the phone, to colleagues, some managers, some non-managers who require updates on what is happening. Not just about software progress but about budgets, seating, recruitment and all the rest. Yep anyone could answer the phone but again, who wants to be interrupted? And who wants to speak to the office secretary? How do you know the secretary has the most up to date information?

Sure in an ideal company there would be little or no hierarchy, people would happily ask questions of those with knowledge rather than those with status but you only need a few people who stand on status, on hierarchy, and it spreads. A Director expects to speak to a fellow Director not to an NCO team lead. And if the Director wants to know about several teams who does he call?

Many of those phone calls involve recruitment, in particular recruitment agents, resources, head hunters, call them what you will. Job descriptions go out, CVs (resumes) come in, even if this manager does review them (and he does some) who is going to communicate with the agents?

If you’ve ever tried to hire someone via recruitment agents you will know: these guys don’t let go. If they get a whisper that you are recruiting they will call you. Once you have a CV from them for a candidate they will call you day-and-night until they know whether you will interview them. And if you say No they will try and change your mind.

Sure good personnel, sorry human resources, staff can help, but a) very few IT staff trust HR, b) many HR people do not feel competent to hire IT staff and c) recruitment agents will find a way around HR staff if they possibly can, and they usually can. (If recruiters have the names of multiple people in the same office they will call them all until one gives the decision they want.)

Who wants to be interrupted by these people?

I could go on but my point is made.

Now an organization could seek to remove a lot of this work from such a manager. After all: you could have an office admin person, a finance specialist, a recruitment person, you could move a lot of this work to specialists, but…

In a small company this often doesn’t make sense. You don’t do enough recruitment to have a specialist, you don’t rejig the money often enough to have a clerk.

Sometimes these issues are interlocking: recruitment effects the budget, the budget effects office desk space and so on. There may be a logic to bringing it together.

Then there is the question of authority. If we delegate the office seating plan to an administrator and an Architect doesn’t like it will they go running to the Manager to have it changed? Or maybe they will talk to the Admin directly.

To complicate matters many companies have actually stripped out these supporting roles over the last 20 or 30 years. Secretaries are increasingly rare but they can be the oil that makes things work efficiently.

In stripping these people out they may have been replaced by machines executing business processes. That may be fine when things work but what when things don’t? Like in code exceptions don’t happen very often but they do take up a lot of energy and effort. In a corporation handling such an exception may also require authority.

Coincidentally I saw Mike Burrows talk the other night about Servant-Leaders. It occurs to me that we don’t actually need Servant-Leaders so much as we need a few more Servants, or rather, support staff to help things work efficiently: secretaries, office admin, finance clerks and recruitment people to name a few.

We need these people embedded with the teams were they can address issues first hand. Putting them offshore or outsourced to another company may make them cheaper by the hour but it will increase the number of hours that are needed.

Not all work can be delegated in this way but a lot of it can. If our hypothetical manager was supported by a good assistant a lot of the admin work could be lifted off his shoulders. This would then allow the manager to devote more time to the important things. In time such a change might even remove the need for a manager altogether.

Now I’ve seen teams with embedded support. A company I worked for in California had a development assistant. She was personal assistant to the whole team. If we needed stationary or a white board she’d get it, if we needed lunch brought in she did it, if we had a problem with expenses or accounts she’d have the first shot at addressing it, and so on.

Before we rush for more Servant-Leaders lets get a few more Servants.

Thursday, June 23, 2016

Management - a lesson from BHS

No sooner have I said I’m closing off my management mini-series than things come to light that need saying! Arrh well, I did say it wasn’t my last word on software management, i just didn’t to be revisiting the subject to soon.

The reason for this rapid revisit is the news from BHS, formerly known as British Home Stores, for those who don’t know it, BHS was for about 100 years a standard part of the UK high-street. Growing up we bought as much there as the better known, and more expensive, Marks & Spencer.

For those who don’t know the story (the BBC has lots) a sort introduction to the key points: Entrepreneur retail billionaire Philip Green owned BHS for over a decade (directly and indirectly) before selling it to a completely new venture, Retail Acquisitions Ltd. for £1. Well, BHS was in trouble (it missed e-retailing) and had big debts (largely in the pension plan.) Surprise surprise, the company collapsed leaving angry pensioners and politicians set about investigating.

The executives and owner of BHS were called in to answer questions. This is where my point really begins…

The BHS CEO told that inquiry that a few days before the collapse the new owner told him to transfer £1,500,000 to a Swedish company. The CEO complained saying the UK company needed the money. The Owner then threatened him, told him to stop making trouble and just do it.

To those outside of management discussions it can look really simple. The money is either needed in the UK or not. Managers and Owners are supposed to think alike, indeed all managers are supposed to speak with one voice. Management, and owners, are supposed to act both rationally and consistently.

It may come as a surprise to find that managers are flawed, managers, disagree and sometimes the managers and the owners have conflicts. Indeed, whole volumes of business literature is devoted to the “agency problem”: how to make sure managers do what is in the best interest of the owners and not what is in their own best interest.

Engineers often dismiss all this as “politics.” They assume there is a rational cause of action and if only all parties could work through a rational process everything would be alright.

But this just isn’t so.

Management is fuzzy

There are few, if any, solid rules in management. Even those that have the force of law can and do get broken - think Enron and Anderson Consulting.

Unlike programming there is no machine to pull you up short when you make a syntax error.

And the feedback looks can be long, real long. Decades.

So often management decisions come down to opinion. Sometimes it is the opinion of someone in authority, sometimes its the opinion of someone interpreting authority or someone trying (successfully) to influence authority.

To an engineer all this is ripe for re-engineering, replace these broken systems. However: just because you want management to always be rational it isn’t going to be so, no rational system can operate in such a fuzzy world.

Imposing rules isn’t going to help, they will just get broken.

Systems will get gamed.

This is not a problem with management, these are the problems management exists to address. Removing management does not remove all the problems - it might remove a few, it may also make them worse. If we remove all the management and give all the power to engineers they will wrestle with the same problems.

Tuesday, June 21, 2016

#NoProjects applies to bread machines too

#NoProjects continues to attract an increasing amount of attention. In fact the idea now has its own NoProjects website - many thanks to Evan Leybourn for that.

From time to time I get asked:

“Surely #NoProjects doesn’t apply to embedded software? After all, the software is installed, the device ships, end of story.”

Maybe, but as in other cases I would argue that the software only stops changing if the product is unsuccessful. If the product is successful one can expect the software to continue changing, sure the device that shipped with version 1.0 of the software might never receive a software update but if the device is successful there will be future devices in the same product line and they will most likely contain enhance software.

For example, one of my favourite kitchen devices is a Panasonic bread machine my wife bought me a about 7 years ago for my birthday. A few months ago we noticed the bread wasn’t coming out right, after a bit of investigation I diagnosed the motor was wearing out. A few days layer I was the owner of a brand new Panasonic bread machine and it was producing great bread again.

The new device shares many similarities to the old it replaced but also has some differences. In particular the user interface is very similar - although this one contains more bread programmes and a modified selection procedure.

Although I don’t know for sure I am happy to bet money that the software inside this one - and lets be honest, there really is a lot of software inside a bread machine - is a later version of the software in the earlier machine. Why wouldn’t it be?

Panasonic produces a range of bread machines, they change from time to time. Would it seriously rewrite from scratch the software each time?

Sure the software in my new bread machine will never change. The project to create the software for my current machine has ended but the software hasn’t. I have but one version that will not change but it is just one release of a living system, an evolving system.

And in seven years time when I need to replace this bread machine, what is the betting Panasonic will be selling Internet connected bread machines that they can update over the Internet of Things?

As the internet of things rolls out fewer and fewer devices will not be capable of update.

The internet of things will drive another nail in the projects coffin.

Wednesday, June 15, 2016

Some things can never be spoken

“Some things can never be spoken

Some things cannot be pronounced

That word does not exist in any language

It will never be uttered by a human mouth”

        Talking Heads, Give me back my name, Little Creates 1985

Some things shouldn’t be spoken. Some things shouldn’t be targeted, some things should be created as a side effect. In Life, the Universe and Everything Douglas Adams explains the secret of flying:

“The Guide says there is an art to flying", said Ford, "or rather a knack. The knack lies in learning how to throw yourself at the ground and miss.”

Throwing yourself at the ground and missing.

Its important not to try to try:

“One problem is that you have to miss the ground accidentally. It's no good deliberately intending to miss the ground because you won’t.”

In business, in software development, there are similar problems. There are some things we should try to hard to achieve. There are some things we shouldn’t speak.

We may want to achieve these things but they should be side effects of something else. Usually the thing we want to achieve is important but to set out to achieve it has nasty side effects. The solution is to do something else which has the nice side effect of creating the thing you want.

Got it?

Following me so far?

Think of it as an anti-dote for Goodhart’s Law: "When a measure becomes a target, it ceases to be a good measure."

Lets try some examples.

Profit is something that shouldn’t be aimed for. Its easy to increase profit, just fiddle the accounting rules, ask Enron, WorldCom (classify expenditure as capital investment) or Lehman Brothers.

Its even easy to reduce costs, just reduce travel allowances, freeze wages.

Another easy way is just to fire people. You will instantly reduce costs - redundancy payments can be made to disappear under “exceptional” items in the accounts - and it will be months if not years before the negative effects cut in.

Its often easy to increase sales: reduce price.

But all of these things will have a counter effect, maybe not today, maybe not tomorrow, or next week but sooner or later. People will become demoralised, people will communicate less, people will leave the company, customers will get dissatisfied and your auditors might catch you out.

The secret to making lots of profit is to not try. Try instead to make for a positive work environment, make your employees happy. Better still try and make your customers happy, make your customers lives better. Do the right thing by your customers and employees and you should expect profit to follow.

And if delivering profit means doing the wrong thing by your customers and employees then ask yourself: should we be in this business? Is this business sustainable?

Its not only profit.

Take another one popular with executives: Culture.

Company Culture is most definitely one of these things. Don’t set out to create a culture. Set out to create the kind of company you want and in the process you will create the right culture. But abstract this to a culture and you have failed.

Who gets up in the morning to go and work in a culture?

Who, for that matter, gets up in the morning and says “Gee, today I’m going to make the company another $10,000”? (OK, sales folk do.)

Rather than set out to create a culture set out to create something else: create a passion for delivery, a fervour for innovation, a zest for pleasing customers.

Don’t call it culture and don’t set out to create a culture which is passionate about delivery. Do the thing itself and the culture will follow.

Communities of Practice, CoPs, is another one.

CoPs periodically become fashionable, I’ve founded and run a few CoPs in my time and I’ve studied, them, heck I think I even wrote about them in Changing Software Development. But… whenever I’ve seen someone set out to create a community of practice they fail.

The trick is not to call it a CoP. Call it a group, a study group, a tech group, a community, just about anything but a community of practice. A community of practice is semi-academic term to describe an observed phenomenon. Decide one what you really want not an abstract idea.

In fact, teamwork, is probably be another of these things. Don’t set out to create good teamwork. Set out to make your team better at what they do.

Create a purpose to your work not teamwork, not culture and not profit.

Servant-Leadership is most definitely another - talk about it in your Manager Anonymous sessions but don’t use it in the office. I know one company where the Project managers got very confused when they were told they were now Servant-Leaders.

Don’t tell people you are now a Servant-Leader. Change your behaviour, become the servant leader you wish to be. It will take the team time to notice the change but it will take you time to change. Simply announcing you are now a Servant-Leader will not make it happen, it will only confuse people - and perhaps make you look arrogant.

My own #NoProjects is another. As Joshua Arnold said recently: The first rule of #NoProjects is don’t talk about #NoProjects. The corollary is: don’t talk about Projects. Don’t talk about them. Talk instead about product, talk about teams, or stream teams, or amoeba teams. Just don’t talk about No Projects.

This isn’t an exhaustive list, these are just things I’ve noticed again and again, I’ve seen others - and I hope you will too.

Think, if you like, of these things as attributes - teamwork, culture, profit, community - or better still qualities, qualities that should remain nameless, naming them kills them. The trick to all of them is not to try too hard, focus on something else, focus on something more concrete and let the abstract notion follow.

Qualities without a name.