Management - an end of year postscript

The end of the year is almost here, a year which has seen two mini-series in this blog: Management and Agile ERP. Well, I was catching up with my reading backlog a little something about management by Tim O’Reilly caught my eye.

Writing about the future of management in MIT Sloan Management review O’Reilly makes he following suggestion:

“a large part of the work of these companies [Google, Facebook, Amazon.com]— delivering search results, news and information, social network status updates, and relevant products for purchase — is performed by software programs and algorithms. These programs are the workers, and the human software developers who create them are their managers.”

O’Reilly’s argument is that the traditional management role was about organizing workers. Now the workers are often electronic systems and their work is governed by programs then the programmers are in effect the managers. Programmers - and others in the development arena - instruct the workers using algorithms and code.

In my management series one of the arguments I made was: no matter how self-organizing and managing teams are there is a residual amount of “management work”. In a team without (or just fewer) managers this work is spread around. Among the most obvious examples are the NCO managers (Scrum Masters, Technical Leads, etc.) teams often have. And, because management work is spread around among more people there are more people who need to understand management and business.

O’Reilly’s argument leads you to the same place.

If we assume more management and business decisions are being taken at-the-code-face then more programmers (and other technical staff) need to learn about management and business. Paradoxically, firms should have fewer managers but more management training.

Some aren’t going to like that, some want to take an engineering view of everything.

I suspect there is a corollary: if technical staff need to spend more time considering management and business issues then there is less time for coding, less space for technologies which require really deep understanding (e.g. C++) and fewer opportunities for those who only want to code and ignore all the management, business and political stuff.

Quite on the blog front - #NoProjects and Mimas

This blog has been a lot quieter in the last couple of months than normal. My energy has been going elsewhere.

If you would like to catch up with latest thinking - particularly #NoProjects - then please check out my latest work-in-progress book, #NoProjects: Correcting Project Myopia.

Early versions of this are available to buy and download now, most of my free time between now and the new year is directed at advancing this book (after one or two false starts.)

Come January my “spare time” time will be absorbed by reviewing the Agile on the Beach submissions (see the call for speakers). Which also helps explain the other reason for the quiet blog…

My summer programming endeavour is a thing I call Mimas - named after one of Saturn’s moons. It is a conference submission and review system for Agile on the Beach. I really should write a blog about the things I learned writing Mimas…

Like all software endeavours there is a lot more I could do. And like so many programmers I wonder…. could this be useful to other people?

Technical liabilities: not technical debt

(This is refactored version of my earlier blog post Technical Liabilities and not Technical Debt - its shorter and contains few of the references to banking and finance.)

Wherever I go I hear developers talk about "Technical debt". Unfortunately the expression isn't used in the way Ward Cunningham originally intended it.

The time has come to retire the technical debt metaphor, in its place we should talk about Technical Liabilities. This is a small change in language with big implications.

The big big problem with talking about “debt” is that debt is not necessarily a bad thing; debt is often good, particularly in a business context. This leads to misunderstanding between engineers and non-engineers and can even lead engineers into poor habbits.

To many people in business - and particularly bankers - debt is good. Debt allows you to grow business and improve earnings. When an engineer says "This will add technical debt" the engineer thinks they are warning about something bad, but to a non-engineer business person, debt is often the preferred form of funding. So buying new capability with (technical) debt sounds like a good deal.

Let me go a bit deeper...

The essential part of Wards explanation was this:

"there were plenty of cases where people would rush software out the door and learn things but never put that learning back into the program, and that by analogy was borrowing money thinking that you never had to pay it back."

However the metaphor has been widely interpreted as something you might intentionally do. "Debt thinking" goes like this:

“We are (time and money) poor, but we can borrow from tomorrow’s riches, rather than write good code today we can save time (and money) by just getting something that works and later (when we are rich) we can come back and do all that good stuff which we should do. (And by the way, if it turns out that our initiative fails then we have saved effort and money.)”

This thinking is ripe both among developers and those who employ developers.

This kind of debt thinking is, perhaps, similar to a mortgage:

"I don't have the money to buy a house right now but if I borrow the money from a bank I can pay back the money over time with the money I save on rent."

Yet many engineers are the first to bemoan the fact that despite the best intentions they never get to pay back the debt. Instead they merely service the debt, that is to say, they (at best) pay the interest but never the principle debt remains. Indeed all too often the payments are not even sufficient to pay the interest which gets added to the principle.

With any debt the important question is: can you afford to payments? The bigger the debt, the higher the interest rate the greater the amount of todays resources (time, money, effort) that needs to be devoted to servicing the debt. Yesterday you borrowed so you could buy something beyond your resources, today you must devote some of your resources to pay those who provided the loan.

Over time "technical debt" massively hinders the ability of organizations to change both the software and themselves.

Technical debt is less more like a pay-day-loan than a mortgage: a loan you take when you have no choice, the high interest rate can be crippling, payments eat into your ability to do any useful work.

Only those who are desperate and/or financially naive would accept a pay-day-loan. Let me suggest those who willingly take on technical debt similarly desperate or technically naive.

This logic is why I say: There is no such thing as quick and dirty, only dirty and slow.

So, talking about technical debt is loaded with problems, when is a debt good? when is it bad? what is the interest rate? do those who advocate incurring debt know what they are saying? And do you have a repayment plan?

Simply changing our language from Technical Debt to Technical Liability removes these problems.

Liability is something neither business and technical folk consider good. If I look at my dictionary it tells me:

"Liability:

1. Subject to an obligation

2. Exposed to a possible risk

3. Responsible for

... and some more..."

These attributes, both in a technical setting and non-technical context, can be agreed by everyone.

Businesses have to list liabilities on their balance sheet and reducing the liabilities produces a more attractive balance sheet. (Debt on the other hand is listed as an asset on bank balance sheets, and even Apple sometimes chooses to issue debt rather than use capital.)

Let us let "Technical debt" go back to Wards original meaning. Lets talk about Technical Liabilities in our systems.

Technical liabilities that cost us because they create obligations - obligation which slow us down, obligations which must be repaid; and they create risks, we don't know when an obligation is going to bite us.

Technical Liabilities and not Technical Debt

My last - frustrated - post finished with this line:

“banks are collecting technical debt the way they used to collect sub-prime”

I’ve always disliked the tech debt metaphor, in part because the way it is generally used is different to Ward Cunningham original defined technical debt and in part because those using it often have a simplistic understanding of debt - for example, credit card debt (which is generally to be avoided) is different from mortgage debt (which many of readers are only too glad to take on.)

A couple of years ago Chris Matts and Steve Freeman suggested a better analogy: an unhedged call option. While technically correct this metaphor required one to understand financial markets and options, most people outside the financial arena (and a good few inside it!) aren’t familiar with such concepts and so the idea floundered because the metaphor was more difficult to understand than the thing it was describing.

Still, Chris and Steve instincts were right, especially in financial arena’s the tech debt metaphor may be doing more harm than good. For a banker collecting debt is good… let me explain.

For you and me, as individuals, a debt is something I have to repay, it is a call on my future cashflow. For individuals - and many non-financial companies - a debt is a liability. As such we would rather not have it.

But for a bank a debt is an asset.

The bank holds the debt, when I take out a loan I promise to pay a bank sums of money in the future. Therefore my liability is their asset. It is two sides of the same coin.

Conversely, for a banker liabilities are things they own other people, e.g. my savings. When I place £1000 in my savings account it is an asset for me but a liability to the bank because the bank need to pay me £1000 at some date in the future. (Importantly, I decide that date and am unlikely to forwarn them.)

Bankers want more debt because debt is an asset. Debt is good.

So every time as software engineer says to a banker: “Doing it this way will create more technical debt” the banker hears “Doing it this way created more assets.”

One of the problems that occurred in the 2000’s was that banks found a new way to take on even more debt. The debt was packaged in technical ways “collateralized debt obligation” and “tranches” and such which allowed the banks to assume more debt. Things went well for a while and bankers believed they had found new way to make money. The problem was these debt packages were hideously complicated, so complicated in fact that many of those trading in these instruments didn’t understand them.

Nor did the banks own risk officers.

Nor did the regulators.

Does this sound familiar? Isn’t this technical debt?

What happened next made things worse: new instruments were divised by some of the people who didn’t understand how the original instruments were structured. In Fools Gold Gillian Tett tells of how the original JP Morgan team who devised these debt products warned as other banks introduced products which they could see didn’t make sense.

Doesn’t that sound familiar?

Doesn’t that sound like the Chief Engineer telling the Captain “She cannae take it, Captain” and the Captain doing it all the same? (Did Star Trek condition those in command to ignore the advice of their engineers?)

Banks aren’t unique here but their business model makes the problems more acute. Even outside of banking the technical debt metaphor has encouraged “debt thinking”, i.e. the idea that one can borrow from the future to get something delivered sooner and pay back later. This might be viable if we treated such debt as a mortgage which allows an asset to be purchased now in return for a long term payments plan.

However when programmers use technical debt to borrow from the future it is more like a payday loan which very quickly balloons and demands increasing amounts of our capacity (cashflow) to service the loan.

Banks are an extreme example of debt funded businesses. Most companies balance the amount of debt they take, if they need more money they may borrow it or they may ask shareholders. In general reasonable to see companies as getting half the money they need from shareholders and half from borrowing.

But banks don’t.

Banks may get less than 10% of their funds from shareholders, they rest they borrow. Anat Admati and Martin Hellwig in Bankers new Clothes explain this in detail but basically a non-financial company couldn’t do this because there is a high risk the company would go bust. But a bank can do it because in the event of failure they believe (and RBS proved) that the government will save the bank.

In other words: banks pile on debt because there is someone else who will save them if something goes wrong. (Economists call this “moral hazard.”)

It is a common business practice to borrow (increase debt) to improve returns so bankers aren’t alone in seeing financial debt as good but they are extreme.

So the question is: Do bankers believe they can take on technical debt because someone else will save them?

I can’t answer that question but clearly engineers view debt differently to bankers. Its more complex than a simple failure to understand.

Bank IT runs on a project model: as I say in #NoProjects this model encourages cutting quality because of goal displacement and the erroneous idea that it will be “done.” Even if bank managers don’t believe it will ever be “done” they can see their involvement ending, perhaps they are contractors, or perhaps they will move onto another “project.”

There are plenty of companies out there, be they outsourcers or tool vendors, who are only too happy to say their service or tool will solve the problem:

“Tech debt too high? No problem for Far Eastern Outsourcer No.1, we can fix it!”

“Do you suffer with long testing cycles? Then get Cyber Tester 3.0, it will find your bugs and shrink the cycle quicker than you can say contingent convertible bond”

As Willy Sutton is might have said: “I sell IT to banks because thats where the money is.”

So is there a way out of this?

Well, there is one more complication that might actually offer a way out.

Another dimension to banking is time: the loans that banks make (their assets) extend over the long term (25 years for a mortgage) and the bank have little power to force repayment. They are said to be illiquid - it is difficult to cancel an existing loan so you can’t turn a loan you have extended into hard cash very easily.

But, the deposits banks accept (their liabilities) are very liquid. I can get my money out of a cash machine at any time and leave the bank with less money - ever wondered why banks pay higher interest rates on fixed savings?

Some say it is this problem that banks exist to solve: turning short term liquid deposits into long term illiquid loans; matching assets and liabilities on different time scales. (Mervyn King has as interesting discussion about this in The End of Alchemy.)

When we build a software system we are building an asset.

The system itself - retail banking systems, trading platforms, risk management systems - are long term investments and become major assets. Some last decades but they are illiquid, changing systems is hard. RBS has recently aborted a demerger because of the difficult of building a new retail system (FT: RBS chief warns it may fail to sell Williams & Glyn this year).

Conversely, defects in these systems (bugs) and poor architecture (what is often called technical debt) are liabilities. More importantly, like banks financial liabilities, these can strike at any time. I can visit the cash machine today and an unknown bug can crash the system today. Similarly, a poorly designed sub-system - say there is a singleton in the system - might not crash a system but can slow down operations, enhancements and so on.

Sure these problems might not appear today, but they might, likewise I might not visit an ATM and withdraw cash today, but I might.

Therefore, let me suggest that we drop the language or Technical Debt. (Or perhaps let Technical Debt return back to Ward’s original meaning.)

Lets instead talk about Technical Liabilities:

Technical liabilities, in software, are sections of code, even entire systems, which because of their (poor) design are difficult to change, significantly hinder enhancement and are fertile ground for defeats. Such code often lacks unit tests and coherent design.

Such liabilities are highly liquid and problems may transpire at any time - impeding performance of the system itself or enhancements by programmers.

In building an asset some liabilities will be incurred. But,

• a) it is possible to minimise these liabilities while building and
• b) these liabilities can be reduced with investment.

Reducing the liabilities will make the asset more valuable itself and enhance the asset’s ability to change in future.

Replacing the words “technical debt” with “technical liabilities” is a small change to our language, one we can all understand easily, removes a poorly understood metaphor that is open to misinterpretation.

Banking systems stink - the pain of an botched HSBC release

I’ve had a very frustrating morning, and it all comes down the failure of bank IT systems - particularly a software release failure at HSBC. Gee, their systems are flaky.

I was trying to buy tickets at Eurostar.com for my trip to Lean Kanban France in a few weeks. First I tried to use my American Express card (I hate it, I only use it for work expenses) and I got the now traditional “Service not available -Unhandled Java exception …gavity.exceptions…” at the final payment stage - you know the pocky little box you have to put three letters into? - I’ve had this error before elsewhere and I think its because I block pop-ups on Firefox. Annoying but nobody at AMEX care so that is that.

So I repeated the transaction using Chrome and my Mastercard - issued by HSBC but branded John Lewis.

And again at the final security page - Arcot’s 3D Verified by Mastercard bit - the page errored. Not a horrible unhandled Java exception but an error just the same.

So I called Eurostar - because something similar happened a few weeks ago and they took my booking by phone. Only this time they insisted that it was the banks fault - like two banks fail? Didn’t anyone ever tell them “Select isn’t broken”?

This time they insisted the problem was with the banks, to make a booking over the phone would cost me £10 - something they waived last month. I even went as far as to speak to a supervisor who continued to insist he wouldn’t waive the fee - which I know from last month he has the ability to do.

Instead he told me it was probably my Mac that was the problem.

Seriously, he told me to use a phone instead. 10 years ago saying “don’t use a Mac” might have been acceptable but now?

Bad customer care on both points.

I gave up, I fell back on Safari and another card altogether to make the booking.

After several tries and a long wait I finally got to speak to HSBC Mastercard and this is what I discovered…

• HSBC Mastercard don’t currently use Arcot security but intended to start on 9 November
• But the release has been pulled because of technical difficulties, they don’t know when it will occur
• But the message had gone out to retails that they were to start (remember, today is 1 November so they change wasn’t scheduled for 7 more days)

This also explains a couple of other recent online purchase problems I’ve had with this card.

This implies that either:

• When a seller system (e.g. Eurostar) calls the HSBC system (“is_using_arcot_security()”) the HSBC system is replying “True” when it should say “False”

Or

• There is a piece of system configuration that HSBC publishes to sellers (“<is_using_arcot_security>True</is_using_arcot_security>”) which has been pushed out prior to the update and that a) this config has been released too early (its not 9 November yet!) or b) else has not been rolled back.

Either way HSBC have bungled a software release. Of course, it might not be HSBC, it could be Arcot, or rather their current owner CA - who were fingered in the RBS outage a couple of years ago.

Which also might explain why I spent over 30 minutes on hold to the call centre (plenty of failure demand).

And we still haven’t discussed by HSBC pulled their release in the first place, clearly something went wrong to cancel the 9 November release - my money is on low quality.

When will these companies learn: high quality in software is faster and cheaper.

Continuous delivery is about risk reduction.

(Well, they are probably mainframe systems so maybe I should be a little forgiving on the second point.)

Now someone at HSBC will probably get into trouble for sharing so much information with me. Well its a good thing they did because I wasn’t going to hang up until they did. Thank you, you did the right thing - unlike Eurostar.

I write this both to relieve my frustration and in the hope that it might make HSBC (and AMEX) do something about this.

(I should also point out: none of these companies have ever hired me. If they had I’d probably keep quite because I avoid blogging to specifically about clients.)

But you know the really worrying thing about all this:

Our modern banking system is based on the assumption that the Government will always bail out a failing bank - the fear of the payments system failing is so great governments will do anything, thats why we rescued RBS.

Now it seems banks are failing to maintain the payments system anyway. The banks are collecting technical debt the way they used to collect sub-prime. Central bankers throwing money around won’t work.

Who will save us this time?

Lean Product Manager - a new endeavour:

The state of Product Management in the UK has long been on of my bugbears. Anyone who has seen my “Requirements: Whose job are they anyway?” will have picked up on some of my concern. Well, I’ve finally decided to do something about it…

Together with Monika Turska I’ve been putting together a two-day course focused on modern product management called “Lean Product Management.” We are going to be running it with Learning Connexions in London at the start of December. For the first run or two you’ll have both of us delivering the course, after that we’ll see what happens.

Whether your title is actually Product Manager or if you are a product manager labouring under the title Product Owner or Business Analyst we think you’ll learn something on this course.

We’ve structured the course around three themes which we see as key to filling the Product Manager role well but poorly understood:

• The Product Manager’s role: understanding the purpose of the role and how product manager interacts with the customers, market and their organisation in order to maximise the value of the product.
• The Product Lifecycle: how to choose the right tools, measure progress, set actionable metrics through the product life cycle from a prototype, MVP, maturity and product decline, and how to identify opportunities for product business pivots.
• The Customer Lifetime Value (LTV): identifying and optimising the value proposition and customer engagement, and how this changes for innovators, early adopters, through maturity and laggard adopters.

There is not “Agile” in the title for two reasons, a) the focus is on “what should be built” and b) Agile is pretty much a given in innovative environments. If you are not actively doing “Agile” your probably doing something better, or else you’ve already gone out of business.

Anyway, let me know what you think, or better still: book a place today.

Feedback & testing wanted - please help!

Can I ask for some help, please?

Some testing? Some feedback? Please

Here is where I need the help: http://mimas-aotb.appspot.com/ - now let me explain…

Agile on the Beach 2017 is in July next year so the whole organization schedule has to move up two months: we’ll be opening the call for papers towards the end of November or start of December.

But I have a problem.

Last year we had close to 250 submissions from over 100 potential speakers. We have six committee members voting in two rounds on the submissions. And I try to give as much feedback to those who submit as I can - this year it took nearly six hours to give feedback to everyone who wanted it.

As a result I have a lot of work in the background.

After 2015 I thought: we need some tool to support us. But when I looked none of the submission review systems I found really fitted our needs. For 2016 I’d left it to late so we had to do the same as 2015 but it got me thinking…

Add to this, we’d like to involve more reviewers to spread the load and get better reviews, the current system would make too much work for me, i.e. its not scalabe.

In the summer I started writing my own system: Mimas - named after on of Saturn’s moon.

Here it is: http://mimas-aotb.appspot.com/

Its on Google App Engine and you’ll need to log in with a Google account.

I’d like to invite you all to play with it and let me know what you think. And especially let me know if find something that doesn’t work.

A Dummy AOTB 2017 conference is set up but you can create your own conferences which you and everyone else can see them too. There are some permission controls in place but any conference with the word “Dummy” in the titles will relax permissions so you can try it with as a speaker or reviewer.

Note: each conference has state, there are some things you can only do in some states, e.g. conferences start closed and then need to be opened for submissions. No reviews can occur until submissions are closed and round 1 starts, and of course, round 2 cannot start until round 1 is complete.

Please send me any feedback, all is very much appreciated: allan@allankelly.net.

One more thing: In writing this I kept telling myself “This is only for AOTB, do what AOTB needs, nothing more.”

Inevitably, now it is nearly finished I do wonder “Umm, could others find this useful?”

If you think you might find this system useful, or just if you have an opinion on whether you or others would find this useful please mail me and let me know. I’m interested to hear anything and everything.

Were I to make this more widely used the first thing to change would be the track listing, they would need to be configurable, I’d also need to revise the voting methods, at the moment it is set up for the Agile On The Beach procedure, and and and, …. please mail me if you think of something.

Software diseconomies of scale - any research?

To say last October’s post “Software has diseconomies of scale - not economies of scale” has been my most popular post ever is something of an understatement! It has been read tens of thousands of times after being picked up by some very popular publications and newsletters.

When I wrote the piece I was writing largely on intuition. That software development experiences diseconomies of scale started as hunch, gradually I could see more evidence but when I published last October I didn’t have anything that would stand up to academic scrutiny - not that I was aiming for a peer reviewed publication.

Since then I’ve become aware of several pieces of research which do show the same phenomenon and do stand up to academic standards, plus I’ve become aware of several people who have made the claim earlier than myself.

So, for those who want to dig into this subject some more let me record the evidence.

“From Aristotle to Ringelmann” (or better an open download of a preprint version): in this paper Ingo Scholtes, Pavlin Mavrodiev and Frank Schweitzer at ETH in Zurich examined open source code bases and team sizes. In their abstract they conclude:

“Our findings confirm the negative relation between team size and productivity previously suggested by empirical software engineering research, thus providing quantitative evidence for the presence of a strong Ringelmann effect.”

The term “Ringelmann effect” is new to me but describes what is seen in software teams - and elsewhere:

“The Ringelmann effect is the tendency for individual members of a group to become increasingly less productive as the size of         their group increases” Wikipedia

Another academic paper is Economies and diseconomies of scale in software development by Comstock, Jiang and Davies. Unfortunately, despite the title this paper focused on constructing a model for effort and value in software development than drawing conclusions about economies and diseconomies. So yes it is about software economics but not a lot about economies and diseconomies, more software accounting. The authors offer no conclusion of their own in that respect.

That said there is some evidence here. The authors note several earlier studies which had mixed results, some showed diseconomies of scale but some also showed economies. They also point out that at least two of the more established forecasting models (from traditional backgrounds), the Putnam and CJD models, assumed diseconomies of scale (I’d never heard of either of these models before!).

It a shame that some of this knowledge has existed in some academic circles for several years, it seems to be another example of how academic papers hidden behind paywalls prevent the spread of useful knowledge. (My initial attempts to get this paper met with paywalls but in the link above I tracked down a downloadable version.)

There is an important observation built into this paper, almost by accident: the optimal team size is not fixed, it will depend on the size of the undertaking and the duration of the effort. I am often asked “What size should a team be?” and several Scrum advocates have stated “the team should be 7 people plus or minus 2.” Clearly the right size for any undertaking will depend on multiple factors.

Away from the academic world there is some more support for diseconomies from other observations.

In a blog post about two and a half years before mine Jesus Gil Hernandez made exactly the same point, “Diseconomies of Scale in Software Development.” Jesus also makes the point that if we want to forecast and plan large software initiatives we need to take such diseconomies into account.

“Diseconomies of Scale and Lines of Code” is blog post from further back, 10 years ago, from Jeff Atwood’s Coding Horrors blog. Jeff also suggests diseconomies of scale but then his blog goes on to focus on lines of code and why its a poor metric (and it is). Jeff also points out that Steve McConnell discussed diseconomies of scale in his 2006 book, Software Estimation.

What is becoming clear is that the possibility of diseconomies of scale in software development have been known about for a long time and my argument has some validity. What we need now is more research to get to the bottom of this…

Unfortunately I don’t have the time or resources to get do such research, I’m happy to collaborate, any academic or PhD student out there fancy picking this up as a research question?

Conclusion: Agile & ERP, part 5

The story so far…

1. Agile & ERP?
2. The Good News about Agile & ERP
3. ERP Culture v. Agile Culture
4. Th Bad News about Agile & ERP        5.        

Where does this leave us?

For a modern software developer, who understand agile and is well versed in the current ways of working encountering an ERP system is like stepping back 20 or perhaps 30 years.

The mindset of in ERP is more akin to the software development mindset when I started working in IT. It is as if the last 20 years have passed them by - the technology is dated, the agile revolution hasn’t happened, users should be grateful for what they are given and the vendor is all powerful.

The deal with ERP is: the ERP system does so very much, why reinvent the wheel? Writing software is expensive (and fraught with failure) so why not use one we made earlier?

It’s the software reuse argument written BIG.

The downside is: the ERP is all encompassing, you need to use particular technologies and these technologies haven’t really advanced in 20 years. The skills are in short supply. Most importantly: all the ways we have found to make software development more effective are absent.

Let us be very clear: there are massive benefits from using an off-the-shelf system. ERP systems are big, really big, and complex, general ledgers, multi-country/multi-currency payroll, etc. etc. Why would you want to rebuild this stuff?

But: there are also massive costs.

The ultimate question is: are the benefits greater than the costs?

Its worth repeating what Capers Jones says at this point:

“As a rule of thumb, if COTS [Common Of The Shelf] packages require modification by more than 25% it may be less expensive in the long run to build the same kind of application.” Applied Software Measurement, Jones, 2008

Unfortunately he doesn’t elaborate on how the 25% is calculated, he probably means function points. He continues:

“Package modification is a high-risk activity with a significant chance of failure and disaster. Not only is productivity normally low for modifying purchased packages, but if the vendors are reluctant to provide support, modification can easily be more expensive than customer development.” Applied Software Measurement, Jones, 2008

When answering this question please remember licenses for ERP systems are far from cheap, and they reoccure. Plus, vendors may well charge extra fees to support parts of the system which have been changed or to ensure backward compatibility.

Once installed clients can be very, very, reluctant to update ERP system. This is hardly surprising once you realise that “configuring” a system like SAP may mean having developers change SAP code in the base system. If SAP release a new version they may have changed that code, you are lucky if you can get away with a merge from hell.

When you buy an ERP system you buy an existing legacy system. You then attempt to configure it to be your legacy system. (See my Peugeot post.)

This sounds like a bad deal but its a deal that makes sense for a lot of companies and has done for 20 or 30 years.

Now, here is my conclusion:

20 years ago buying a legacy ERP system and configuring it to be your own legacy may well have made financial sense.

But in the last 20 years technology has advanced, not just the CPUs but the programming languages, the programming tools and even the programming processes.

Buying a legacy ERP system today means buying into a legacy development process with legacy tools. You step back 20 years.

In the last 20 years the tools and techniques have got a lot better. While buying an ERP system may look like a sensible decision you also shackle yourself to 20 year old tools and processes.

The tools and processes have improved so much in the last 20 years that the equation has changed. Modern approaches (i.e. agile and test driven) using modern technology means the cost and time gap between a) developing your own system using modern techniques (including microservices, existing libraries, open source, etc.) and b) choosing legacy ERP system (reoccuring license fees plus configuration costs) is far smaller than it was.

I conjecture that the gap is getting smaller as we speak.

Since ERP systems last decades the 20 year old ERP system you are buying today might be expected to last another 20 years. Who knows how much better things will get in two decades.

This also means there is a market opportunity for “modern ERP” systems which use modern technologies (Java, JavaScript, Micro-services, etc.) to support modern working practices. Microsoft, Oracle and SAP are all trying to move forward but the legacy is very profitable.

Finally, one might ask: given all these problems, and the changes in technology why do companies buy these systems?

Nobody ever asked my opinion on this so I can’t really say but let me float an idea.

Only companies of a certain size, say $1 billion revenue can afford these systems. When a company reaches that size they are expected to buy such a system - having an expensive system is a sign that your company has arrived.

These systems are driven by the finance departments, the CFO. As companies get big they need such systems to control the company. But also, the CFO of a $1bn company wouldn’t look serious if he didn’t have one - after all, all the other $1bn companies have an ERP system so why not yours?

If you are the CFO of a $1bn company without an ERP system and something goes wrong it will look irresponsible. Having an expensive ERP system allows the CFO to say “We followed best practice and bought Oracle”. It reduces the risk of the CFO losing their job.

And buying an ERP system allows the CFO to claim more resources for his department.

And it allows the CFO to say at his next job interview “I introduced an ERP system to a $1bn company.”

So the next time you get appointed CFO of a company which as just broken the $1bn revenue barrier and you find there is no ERP system in place what are you going to do?

Engineers might think: I’ll set up a small team and start growing our own ERP system using modern technology.

To the engineering mind that approach stands the best chance of working and is financially the best route.

But it is also high risk simply because nobody else does it.

Everyone else says: “I’ll call SAP, I’ll spend a lot of money with them, Accenture, Cap-Gemini and CSC. When it goes wrong I can blame them. After all, thats what everyone else does so doing anything different would be high risk.”

The Bad News: Agile & ERP, part 4

The story so far…

• Part 1: Agile & ERP introduced
• Part 2: Good News: Agile can work with ERP!
• Part 3: Culture: How Agile & ERP cultures conflict

In this mini-series I’m discussing Agile development on ERP systems. If you are doing this and you’ve just Googled “Agile and ERP” there is a good chance you’ve found this blog because… bad news… there isn’t a lot of experience of doing Agile in an ERP environment.

Sure people have done it, sure some people have written about it in blog and journals but I said: “some”. Some means “not many”. One of the problems of doing Agile in an ERP setting is that there is a lack of knowledge and experience. People have done this, I’ve “done” it several times myself but… not as many people have done Agile in ERP as have done, say, Agile in Java Banking or some other domain. And very few of them have written their experience up. And even fewer have good stories to tell.

Partly it comes down to a question of “What do you mean by Agile?”. Sure you can do Agile in ERP if you define “Agile” as those “agile” practices which work in the ERP setting. On the other hand, when you do find the examples that are out there you will find many practices missing, specifically the technical practices.

Almost all the reports of Agile in ERP you will find are about process - much like my previous post . Doing ERP with test driven development, acceptance test driven development, simple design, emergent design and refactoring is almost unheard of.

Sure there are a few blogs out there which discuss it a bit but there is not much. I briefed a recruiter to find someone with (A)TDD and ERP experience. He came back a couple of weeks later and said “Its like looking for Unicorns, these people don’t exist.”

In part this is because ERP systems are sold on the promise of EVERYTHING. Their design dates back decades so they are monolithic and the culture that surrounds them is 20 or 30 years behind the current thinking.

My most recent run at this problem was the best yet but here is the bad news: with an ERP system once you move away from the Agile processes practices and start to look at the Agile technical practices things get very difficult.

The cultural problems (corporate IT and ERP specific) don’t help but the technology is the major obstacle. Lets start with testing…

Some test frameworks do exist (e.g. ABAP Unit and X++ Unit) but they are limited and, as with other languages, only a fraction of developers use them, and only a few of them do it properly.

One of the problems is an old one: Mocking and Stubbing. But in an ERP system the Mocking and Stubbing problems are far far worse because the system is provides so much already you need to do more mocking, the system is pervasive, there is just more system to mocks and stub.

Since ABAP is effectively Cobol you can forget reflection, annotation and polymorphic substitution. Heck, I don’t think it even supports macros!

Part of this problem is because of the architecture of ERP systems. The architecture is decades old, its decidedly not Object Oriented, as closer to working in embedded C than Java.

Another problem is because of lot of the system isn’t programmed in text. Remember I said some of the programming was table based? And some was pointy-clicky? That stuff is super difficult to test because it exists in a different paradigm. In some cases even when the “configuration” exists as a code like fragment it is considered data by the system and cannot be extracted.

In once case we exported “the code” only to find it wasn’t coded in ASCII. And if you’ve exported it you might not be able to import it again.

The designers of these systems actually expect their production code to be changed, tinkered with, messed with, hacked, by those configuring the system. Let me repeat: production code from the vendor may be changed as part of a configuration effort. Imagine that when you wanted to write a macro in Microsoft Word VBA you were allowed access to the underlying Microsoft Word code.

These systems are the exact opposite of what John Vlassides would advocate:

"the hallmark of good code is that it is changed by adding to it, not hacking it" John Vlassides, The C++ Report

Changing code by adding to it is a new idea in the ERP world, both for those “configuring” it and those building the product.

But the problems of Automated Unit Testing TDD pale into insignificance when compared to the problems of doing automated Acceptance Test Driven Development (ATDD).

Because ERP systems are monoliths it is hard, if not impossible, to find a way in to add ATDD style tests. These systems don’t just predate microservices they predate components, COM, CORBA, DLLs, shared libraries and even static libraries.

I’ve seen automated test tools work at the highest level, the UI level. I’ve heard Quick Test Pro can run against the UI on Windows interfaces and I’ve seen Selenium run against a Microsoft front end, I’ve even seen Selenium execute a Given-When-Then test but…

This is all at the UI level.

It seems impossible to set up tests anywhere between the very lowest level and the very highest.

If you are lucky the ERP system exposes some services or interfaces you can connect to, for example Rocket U-2 lets .NET code connect to it in places. But such interfaces are not always there, or if they are they are undocumented and subject to change. So most higher level testing needs to be at the UI level….

Since its at the UI level the tests are slow, fragile, slow, difficult to create in advance and slow; the whole system needs to brought up to run them so if something is found its a big pond to fish in.

Since the whole system is being powered up for a test you need test data and this is a problem. If you are very lucky you might be able to get to a relational database and insert your own data, if you are unlucky you won’t be able to access the database or you’ll find its an old propriety hierarchical database and you will need to load lots of data.

And did I mention its slow?

It is not just ATDD tests which are slow the build is slow too. Hours not minutes.

Building might not be much like you know it, I once had to explain source code control to an SAP team. Because all configuration is considered “data” the very idea of source code control can be strange - you are dependent on the vendor actually supporting source control which at one point SAP did not.

Sometimes actually saving “configuration” and loading it into another instance of the system isn’t supported to start with. You may need to build that plumbing.

And remember, these ideas may be completely foreign to the people “configuring” the system. These people are HR or supply chain experts who happened to pick up a bit of ERP and found it pays well. They don’t understand many software engineering concepts, they may not particularly want to learn them and their employers may not want them to either.

As I said before: these systems are large monoliths.

Many of the tools and techniques which software developers have created to manage large systems, to modularise them, to control them, to isolate parts of them, to allow change at different rates are simply absent. ERP systems are not just monoliths the are monopolies, they are intended to form the central nervous system of an organization and run the organization, they are a single thing.

That is their nature, their culture, their technology, even their raison d'être.

That might seem strong but think about it… Senior managers buy these systems to provide insight and control over large organizations. They want the large organization to function as a single entity, they don’t want duplication, they don’t want variation, they want a monolith and that is what the ERP sales people sell them.

So while you might be able to bring some Agile to ERP implementation there is a very deep seated conflict between the agile means and the decidedly non-agile end.

Culture problems: Agile & ERP part 3

I suggested some cultural problems with software development in an ERP setting in my second post on Agile and ERP, this time I want to look more closely at the differences in the two cultures.

Many of the cultural issues revolved around the fact that ERP tends to happen in a corporate IT environment, and since corporate IT is a more challenging place to develop software anyway an ERP system is going to have “the usual” corporate IT problems.

However ERP systems seem to be prone to even more cultural problems.

I’ve already said that ERP systems are monoliths, and I’ve also hinted at the fact that they are hierarchical in nature. In part this is a historical hang over, they come from the Cobol mainframe world when systems were written like that.

If you know Conway’s Law what I am about to say is obvious: organizations developing, sorry, configuring, ERP systems are themselves hierarchal and monolithic. Separating the HR development from the Logistics development is hard.

This is actually a great example of Reverse Conway’s law (sometimes called Yawnoc): the organization is a copy of the system architecture.

When an organization buys an ERP system they buy a large, monolithic, hierarchal system, the investment (financial and personal) required from senior managers mean the homomorphic force is strong. Therefore the organization which engages with the system becomes a copy of the system - reverse Conway’s.

(On the bright side, since these systems are designed to serve yesterdays needs using technology based on yesterday’s paradigms there should be an opportunity to disrupt this model - but that is another topic for another day.)

Lets talk about some details…

The first problem hits you right out of the box, literally.

An ERP system is sold and marketed as an application which does not require programming, it only requires configuration. Take careful not of that word: configuration, not even customisation and certainly not programming. This is very sophisticated marketing.

ERP systems cost millions of dollars to buy and operate them. Very few technical people will ever have a say in the purchase of such a system. The sales people deliberately talk of such systems being configured (without programming) in order to say to the buyers “Look you don’t need any pesky (expensive) programmers.”

Instead they plant the idea that you install SAP, go to the tools menu, select options, choose the right tab, click on the box and … et voila! — the system is configured. OK, its a big system so it needs a “lot” of configuration but you get the idea.

This isn’t so.

The kind of configuration required by ERP system is far more akin to programming than any ERP seller would ever admit. It might not be the kind of programming recognisable to a Java developer but it is programming in a different paradigm.

Sometimes it is table based programming - a kind of predicate Prolog rules system.

Sometimes it is lots of parameters - think .ini or XML files but probably in some arcade syntax.

Sometimes it is quite literally lots of pointing and clicking.

And sometimes it is actual coding, usually in the systems only language, SAP uses a Cobol like language called ABAP while Microsoft Dynamics uses Frankenstein version of C++ called X++.

Note also, that because just about every ERP system I know of is actually an assembly of multiple different products built by different companies at different times and smashed together by the current vendor you are likely find all these approaches and multiple languages on the inside.

The first big problem to overcome when faced with an ERP system can be simply convincing people that programming is required. Or rather, that the kind of rules and thinking which apply to major programming efforts need to be taken here.

That programming is required is provable because there are always Testers. If configuration really was straight forward no testing would be required. Since ERP systems are always tested that which is called “configuration” is clearly more than tools, options, click. Clearly there is the possibility that two different pieces of “configuration” interact in unexpected ways.

Because ERP systems emphasis the business functionality and disclaim programming they claim to be configurable by practitioners, e.g. accountants, HR professionals, logistic experts. etc. Indeed you probably need to have domain skills to configure it but you also need technical skills.

Thus the people doing the “configuration” do not see themselves as programmers. They rarely have a programming background, concepts like cohesion, coupling, separation of concerns, interfaces, etc. are foreign to them and they wouldn’t know dependency inversion if it is turned them upside down - or any other pattern for that matter.

It is not that these people are stupid, actually they are experts in their own fields; rather because they do not believe they are programmers they take little interest in software engineering concepts. And since their education was in their expert field (logistics, accountancy, human resources, etc.) they they never learned these concepts at school.

Unfortunately when you program a big system, a big anything, having software engineering knowledge really helps - that is why the discipline came into being.

Worse than this, because the “no programming required” concept is encouraged by the vendors the programming systems inside the ERP systems also lack modern software engineering concepts. Remember: ABAP is Cobol, Cobol is not a modern language.

Like Cobol, ERP languages such as ABAP and X++ have a “commercial orientation” and lack the idioms required for engineering. On one ERP implementation I came to feel the whole thing was just Visual Basic on steroids - and VB6 at that! Such languages are Turning complete so you can do (in theory) do everything but somethings these things are damn hard.

The ERP culture creates other problems too.

There is no OpenSource for ERP. Nobody ever went home at night and wrote ABAP for release under the GNU license. As a consequence the kind of tools modern software engineers expect do not exist.

While ABAP-Unit and X++Unit exists they are not as widespread or as usable as JUnit.

Nor will you find Stackoverflow full of ABAP or X++ questions and answers. Sure there are a few but only fraction of what you will find for Python. To be fair, the number of ABAP or X++ programmers is only a fraction of Python, C# or Java programmers anyway so while some public resources exist there are tiny.

Many ERP “developers” work for system integrators (CapGemini, Accenture and countless small shops). They charge high rates for their people and take a very fluid approach to staffing. For example, an SAP HR “consultant” on a team I was working with had a two week holiday. The consultancy company sent another consultant to fill in for the two weeks she was away. I find it hard to believe the stand-in consultant could usefully do anything for the client in that time but by being there they could bill time for the system integrator.

A side effect of this is that the consultants are often in high demand, they may work on multiple client projects at once, and they are internationally mobile, they get lots of frequent flyer points.

This has some very practical limitations, these people may not devote 100% of their headspace to the client and getting a standup meeting to start early or at a regular time is hard it may depend on Heathrow congestion.

And because they work for someone else the client and the consultancy may not agree on who pays for any Agile training or workshops. I’ve found myself giving Agile workshops to client staff where the ERP consultants are excluded because they work for a supplier. Even when the client hires the staff directly, or the client and supplier agree, the ERP Consultants may resist learning about Agile, and especially technical considerations, because they do not consider themselves technical!

And when the ERP consultants do engage its is like stepping back 10 or 15 years, all the “old” arguments appear: “how can we do something in 2 week?”, “we must design the whole”, “the business must fix its requirements”, etc. etc.

In the next instalment we’ll turn to the bad news, the technology…

The Good News - Agile & ERP, part 2

First the good news: there is a lot of Agile practices which work just fine in an ERP environment. These are mostly the process practices and some from the demand side (i.e. requirements, “what are we going to build”).

All of the following work just fine and will improve work of teams in ERP:

• Stand-up meetings work just fine, but stand-up meetings alone do not make a team Agile.
• Iterations (Sprints) work just fine; and that includes starting them with a planning meeting and ending them with a retrospective. (You can do estimation with planning poker if you like, I’ve no evidence that it is accurate in this environment but it might be effective at persuading people you are taking estimates seriously.)
• Visual boards work just fine and will improve work.
• User Stories, i.e. small pieces of business valuable work, are fine; you can also use Epics and Tasks too, and you can do Xanpan style urgent-but-unplanned work too.
• Defining acceptance criteria (conditions of satisfaction) works too.
• Pushing authority down, encouraging teams to take on more responsibility is all good too. But note: ERP and big company culture make this a challenge
• Agile Coaching works just fine too.
• Product Owners work; and as usual in a corporate you will probably find a Business Analyst filling the role day to day. However, ERP culture is document centric and added together with authority problems means POs might not have, or at least feel they do not have, the authority to make decisions.
• As always co-located teams work best, pair programming and mob programming work fine too.

Some practices are always more difficult, perhaps in ERP they are more difficult.

Identifying and delivering small, thin, slices of business functionality works, almost. Two problems appear. First because the nature of ERP systems is all encompassing business representatives are even more resistant than usual to accepting anything less than everything. Second, architecturally ERP systems do not lend themselves to working on things piecemeal. You can do some of this but its even more difficult than usual.

Emergent design is hard, largely because refactoring is still a new idea, the tools, techniques and most importantly mindset and understanding for incremental, evolutionary, organic style growth are not there. Therefore all the old arguments about “we must design the big picture” are very much in play.

Multi-skilled individuals and cross-functional teams: as with “normal” software development getting people to work outside their core skill-set helps smooth the flow of work; and as with normal software development there are limits to this both because of the learning curves involved and because of individual preferences and identity questions.

With ERP systems these issues seem to be more difficult partly because the skills involved in ERP work are even more different and - to preview something I will say later - there are greater cultural issues. Many ERP developers come from domains other that software engineering and therefore lack some of the basic understanding that one might expected of them.

Secondly, because ERP is normally done inside a corporate environment people are more conscious of their defined roles. In typical software companies individuals are more prepared to try doing something different because the aim is to ship a something. In all corporate environments people are more prone to limit themselves to their defined job roles and titles.

Corporate environments typically bring another problem too. Not in every case, but in the majority of cases, the quality (depth of skills, ability to learn fast, and such) of people inside corporate IT tends to be lower than that in specialist software development organizations. I tend to believe this is more a function of the organization than the individuals and it is not true in every case but it certainly seems that good technologists tend to gravitate towards specialist organizations.

This might be a function of recruitment practices, it might be a function of expenditure on training and skills, it might be a function of corporate mission, it may well be a function of the corporate environment or the specialist development environment, or something else altogether.

And because the corporate environment limits the teams ability to resolve impediments. Implementing a commitment model is extraordinarily difficult. This doesn’t worry me much because I’m not a keen fan of the commitment model anyway - see my Commitment Considered Harmful post.

The net result is: ERP teams don’t have as many high performing environment or individuals and teams as a specialist IT shop. (Obviously those two things go hand in hand but unravelling cause and effect is hard.)

And thats the good news, the next post will discuss culture before I turn to the bad news.

Agile & ERP? - part 1

This is the first of several blog posts about working in an Agile way with ERP systems…

Most of the developers, testers, BAs and managers I know have little, if any, awareness of ERP: Enterprise Resource Planning. The big software systems sold by SAP in particular but also by Oracle, Microsoft and others.

Strictly speaking ERP is a specific application for planning and scheduling resources usually in manufacturing, but many in the industry use the term “ERP” is used as a generic shorthand for a whole host of large enterprise applications beside strict ERP: CRM (customer relationship management), financial accounting, payroll, human resources, asset management, logistics and supply chain management, and more.

Over time the big players tend to have swallowed the more successful ones, so Oracle now owns JD Edwards and Peoplesoft, Microsoft swallowed Great Plains and Navision, The products tend get recycled… but I digress.

While most developers can happily spend their entire career avoiding these packages those that encounter them find two things. Firstly they very pay well, exceptionally well in some cases. Second these systems are all embracing: the database is probably hidden well down, it may well be hierarchical rather than relational; they usually come with their own language, SAP has ABAP and Microsoft X++

Over the years I’ve touched a few of these systems, some of the big names, some of the smaller names, some of the “modern” systems and some so old they predate the ERP classification - anyone for Rocket? Or Comet?

This year I’ve had an chance to work for an extended period with a team using Microsoft Dynamics and attempting Agile and I think its worth a few comments, partly about the state of “agile and ERP” but also about ERP in general.

In the next few blogs I’m going to say something about my experiences, I want to talk about the common issues with these systems, not specific problems of one team or another. Here are a few of the key-points:

• Stepping into the ERP world from the Agile world is like stepping back 20 years, or maybe 30.
• You can do Scrum in an ERP environment but it seems impossible to do XP, i.e. getting the technical practices to support your efforts does not seem possible.
• Testing, automated testing is only possible in very limited amounts, its an uphill challenge.
• Configuration is a form of programming but many people in the ERP space reject the idea that they are programming and therefore reject (or probably never knew) the engineering approaches that programmers (should) take.
• Systems Analysts are alive and well in the ERP world: such analysts are rarely found in development teams any more, they role has fractured in two, some of the work has gone to Business Analysts and some to Architects and Senior Developers or just “the team”.
• Release cycles are long and the monolithic nature of ERP systems means they resist attempts to reduce them. The monolithic nature bits these teams again and again.
• Culture: the culture that surrounds ERP systems is the antithesis of Agile culture. In part this is because only large corporates have ERP systems; Agile can work in the large but it is more difficult, Agile can work in a corporate culture but it is more difficult, in ERP you start off down two and then you add ERP culture.

Reverse Conway’s Law means that the organizations which develop in ERP systems themselves take on the attributes of the system, namely they are hierarchical and monolithic.

ERP systems and Agile is a big topic and I’ve plenty to say so I’m going to blast out a series of blogs in the next couple of weeks, they are all drafted so watch this space:

• Part 1: Agile & ERP? (this introduction)
• Part 2: The Good News -(practices) Agile & ERP
• Part 3: Culture problems - Agile & ERP
• Part 4: The Bad News - Agile & ERP
• Part 5: Conclusion - Agile & ERP

(Update: having now published those posts I’ve updated these links.)

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.”https://en.wikipedia.org/wiki/Worse_is_better

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.)

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!