Sunday, January 22, 2017

Clinic: Agile Coaches, Scrum Masters, Delivery Managers...

​From time to time questions show up in my mailbox from people asking questions. I like to post the questions and answers here in the hope that others might benefit. I’ve done this a few times before (“Agile Clinic: problem with our agile…”)

I’m always glad to help but it can be hard to find time, plus, not everyone wants to talk about this in public. So, before I jump into this clinic Q&A, I should mention that members of part of Alex Pappworth’s “Be a Brilliant Business Analyst” group can now book one-on-one online consultations with me.

Anyway, to today’s question….

“[We are a Drupal based software development organization in India. It is 150 member team with representations in South East Asia and the US. We have 2 Agile coaches in the organization who are stretched in time managing different projects.”

Hardly surprising, 150 people, multiple projects, multiple locations. I don’t know what the “right” ratio of coaches to teams/people - there probably isn’t one single answer, not least because it will depend a lot on the maturity of the teams, i.e., established teams will need less help than new teams but all teams should have a coach to call on.

“We are looking at restructuring our organization so that these coaches can be supported for project delivery. As of now the Agile coaches have 3 primary responsibilities - 1)project delivery 2) Agile process coaching and 3) people management. Of these 3, project delivery and people management is the most time consuming and exhaustive.”

This is worrying. To my mind Agile coaches should be spending most of their time on process coaching and helping people - not helping with their work, helping them improve, maybe one-on-one coaching or maybe team coaching. I wouldn’t call “helping people” people management, that sounds like line-management or traditional project management.

So first off: get some project managers.

Regular readers will probably be surprised to hear me say that, and I am a little but there are times when a project manager is the right solution. One example, as in this case, when there is a client-supplier relationship and expected deliverables within a project model.

Yes, I question whether the project model is the best model to be using, and I’ll even question whether this company really does projects, but based on this information they do, they should have project managers.

Once you have project managers then the coaches can work with the project managers to improve team performance.

“We have contemplated separating the people management piece by placing a Delivery manager between a coach and scrum master.”

Scrum Masters too? Can’t they pick up some of the project delivery work in the absence of project managers?

One problem with “Delivery manager” is that the role is not well defined or even understood. It is a new role and one which is still emerging. We will probably never have a universal standard delivery manager role but right now it is ill defined.

If you were to add a Delivery Manager I think they would end up becoming a type of Project Manager. In which case we’ve both identified a missing role in your organization, the question is: who are the right people to fill it? Whether you call them project or delivery managers there it seems there is a missing role here.

Line management is a more difficult problem. Here we really have an evolving field.

So far I’ve not heard of any good solutions to “Who is the line manager?”

• Project Managers aren’t line managers because they lack the skills, plus projects are temporary and you want some continuity here.
• Scrum Masters and Coaches aren’t line managers because the type of coaching they (should) use shuns authority.
• Delivery managers…. well if I ever find out what a Deliver Manager does I’ll let you know.

Since Agile as a whole aims for self-organization the issue of line management, and there in some authority, has received little attention. Arguably you should drop the role all together but that is quite radical.

One solution I’ve heard is to make one manager responsible for all line management. At the same time moving towards greater self-organization reduces the need for line management.

“In the existing system scrum masters do not have the maturity or the experience of people management. Since we are still trying to figure our way out keeping in mind that we don’t increase our overheads I have the following questions to ask of you-“

Good call, if the people don’t have the maturity yet don’t make them line managers. And as I said, Scrum Masters probably shouldn’t have that role anyway.

“a) Is an Agile coach expected to do all 3. i.e delivery management of projects, people development(career progression, feedback in retros, conflict mgt) and Agile process coaching ( tech forums, building an Agile culture etc)?”

Well… that all depends how you define the Agile Coach role. I’d ask the coaches to sit down together and draw up a list of things they think they should do, and a list of things they do not to. Similarly I’d do this with the Scrum Masters.

As I’ve said, in my view, most of the time coaches should not be managing the delivery of projects or people development (line management). They will run some retrospective and feedback sessions, although I’d expect the Scrum Masters to take on most of this. And I would expect them to work on process, culture, etc.

(This old post might be useful What does an Agile coach do?).

“b) Given our geographical spread should we be hiring more Agile coaches?”

Yes, at least one per location.

Even if you don’t have developers in one location you will have some people - analysts? sales? - who would benefit from better understanding of the new way of working. And in a location with multiple teams you probably need multiple coaches, but not necessarily 1-to-1, as the teams have Scrum Masters, and some new managers of some sort, the coaches should focus their attention supporting these roles and the teams.

“c) If we were to get a delivery manager in between a SM and Agile coach, people management should be whose responsibility? (We are facing a huge challenge in finding the ideal combination of tech skills and people leaders)”

I don’t think so, this isn’t a hierarchy or chain-of-command. Project/Delivery Managers and Coaches are peers, they each have a different focus but have overlapping responsibilities. On any one team the Scrum Master and Project/Delivery Manager will need to decide between them they work together and which responsibilities they pick up.

Agile Coaches don’t have any additional authority however they are not under taking the day-to-day work, their job is different again.

Right now I think you need to untangle the Agile Coach role first, give it a few months and revisit these questions.

Can’t say I’m surprised you are finding it hard to get the right combination of tech skills and people leaders. Such people are few and far between, sometimes it seems the two are mutually exclusive. Could you work with the existing tech leaders to improve their people skills? - training, coaching, etc.?

“d) Would it be a better idea to identify SMs with potential to be groomed into people managers and move them to a delivery manager role? My concern is that an Agile coach should not be stepping on the toes of a delivery manager.”

Certainly you could help the Scrum Masters grow in that direction. Whether they stay Scrum Masters or become something else I don’t know. And since you don’t have any delivery managers (yet) you talk that through when you are recruiting people (i.e. don’t hire people who have strong beliefs on this!)

(And, by the way, avoid the word “grooming”, in English English it has a very specific, very negative, meaning these days.)

Pheww…

In summary:

  • More Agile coaches

  • Have the coaches define their responsibilities

  • Educate and grow the Scrum Masters

  • Add a new role: perhaps experiment with one or two hires at first

I hope that helps.

Wednesday, January 18, 2017

A sad Cobol story

This isn’t a happy story, it has no happy ending, I suffered personally, its personal but I want to share.

Its about trying to solve a problem with the fashionable solution rather than rolling back the last fashionable solution you applied which created the problem to start with…

A long time ago, well, the best part of 10 years ago, in a town far far away (actually the other side of London) I went to help a small part of a very large company “become agile”.

The managers wanted to be “agile” and insisted they knew what it meant and what the implications were. So my job was merely to help the change resistant workers change.

Now this company, like so many others, had decided that coding was expensive and should be done in a far away place, and this time I do really mean far away, far enough away to be cheaper.

The system in question was big, and old, over 20 years old, and millions of lines of Cobol. Fortunately the company still employed most of the people who had built the system over 20 years. Unfortunately they were to forbidden to code. They were too expensive for that. So the far away cheap people coded. I forget the job title the old coders were given, maybe it was SME but I thought of them as Architects - although Systems Analyst might have been a better title.

The far away coders, employed by a “partner” (outsourcer) were young, they lack programming experience. I suspect they had learned Java at college and been given a Cobol boot camp when they joined the partner. From what I could tell they were quite capable of making a code change at the function level but… anything involving system structure, multiple functions or some of the larger (too big) functions required help.

They needed to talk to the architects.

To avoid this the big company had the architects write “design” documents. But still the coders needed regular conference calls.

These coders also had a habit of changing, after 18 months on the contract the outsourcer moved them on. But then, many of them didn’t last that long; many left of their own accord before then. Consequently, just as one of the coders got to the point off properly understanding Cobol and the system they were gone.

To make sure the right work was done the big company had Business Analysts detail the need in big documents. Lots more to read.

Of course all this required a lot of testing for the partner, plus another partner (in a third location), and internal “user acceptance testing” (in a fourth location.) Implicitly the process and managers accepted lots of failure and expected testing to generate a lot of (re)work.

Now something else happens when you use an outsourcer and so many people: you need more management, at both the client and supplier.

All this complexity (not to mention cost) piled up and made them unresponsive. Hence they wanted to be Agile! That’s why I was there.

Every so often one of the projects would get into a real mess and the architects would be allow to take over and code. When this happened it was completed in a few weeks.

Most of the offshore efforts took months.

Yes the company was saving money on programmers but…

• They were spending more on business analysts and architects

• They were spending a lot on test

• They were spending a fortune on managing

But most of all they were paying in late deliveries, new products not in the market, delayed cost reduction initiatives and so on. Plus they were pained by poor completing date forecasts.

And it was getting worse.

So of course Agile was the answer.

But the problem the company faced wasn’t one Agile sets out to solve. The problem was one of knowledge: the company had the knowledge but wasn’t using it effectively. While they didn’t use the knowledge they were losing the knowledge. Knowledge couldn’t just be moved from the heads of people in London to the heads of people in a far away place.

The company ignored knowledge, or at least thought it could be written down. They saw the problem as expensive typists.

And me?

I diagnosed the problem as managers failing to understand, hence I wanted to spend time talking to managers. But they said they already understood and Agile was the answer so my wanted to talk to them was not what they wanted.

I crashed and burned.

Sunday, January 15, 2017

Kodak and The Mayor of Rotterdam problem

In The Living Company (one of my favourite business books, highly recommended) Arie de Geus describes the Mayor of Rotterdam Problem, it goes like this.

Imagine you have perfect foresight. You can see the future accurately. It is 1920 and you visit the Mayor of Rotterdam. You tell the mayor about how the events of the next 25 years, specifically about the destruction Rotterdam will suffer during 1940-1945.

de Geus asks: What is it reasonable to expect the major to do?

Think about this for a moment.

de Geus draws the following lesson:

The future cannot be predicted. But, even if we could, we would not dare act on the prediction.

So, I might say “You project is a train crash and destined to fail.” But if you have invested $100million do you dare to act on my information?

I draw another lesson from this story:

There is nothing we can do to change the future, even when one has considerable power.

Most people regard a Mayor as a powerful figure. But what could the mayor do in 1920 to stop Great Depression, the rise of Fascism and the pending war?

And thats assuming people believe you.

Why bring this up now?

Well… increasingly some of our most established companies face exactly this dilemma. The raise of digital business, coupled with disruptive innovation, agile working and new management models place CEOs of some of the largest business in exactly the Mayor’s position.

If you are the CEO of a business with a few million customers and you can see how digital disruptors will steal your business over the next 10 year d you dare act on the information?

Acting now might mean destroying profits for years to come, acting now might mean laying off thousands of workers and dropping millions of customer. Success if very very far from guaranteed. And thats assuming you can persuade people you were right.

There is one company where this has already happened: Kodak.

A recent MIT Sloan Review piece Willy Shih gave an account of Kodak which differs substantially to the commonly received view. Kodak is regularly held up as an example of a company that failed to recognise how digital would change their world and as a result went bankrupt. But…

Shih describes it differently, he says that Kodak managers did understand what was happening - after all they invented digital photography. The problem was: Kodak couldn’t change direction because of their ecosystem and the economics of their business.

Part of the Kodak problem was that had Kodak publicly acknowledged the decline in their traditional market they would have accelerated the change.

Kodak did try use their legacy business as a cash cow did enter the digital market this left a big problem: how do you manage, and motivate, people in the legacy business who will never make the transition?

The question to ask right now is: • What other Kodaks are there out there? - unable to change direction because of their legacy. • Which CEOs are Mayors of Rotterdam? - unable to act on accurate predictions of the future.

If you are the CEO of a Kodak an alternative strategy might be ignore the future, crank up the machine and do even more of the same - whatever your current business model is. Aim in the short run to minimise risk while maximising your personal return. Plan to jump out of the business yourself before it goes bang or just plan to blame the failure to predict the future.

Saturday, January 07, 2017

My dyslexia inside the corporation

This is the first blog post of 2017 so something a little different, a little more personal, a little speculative…

I’ve written before about my dyslexia (Dyslexia makes me stronger) and I’ve also noted that what is good for dyslexics what helps them learn, is usually good for the wider population too; i.e. if you make things dyslexic friendly non-dyslexics also find things easier.

A corollary for that might be: reading which many find a little difficult dyslexics find very difficult.

Now I’ve stumbled on something that has got me thinking, let me explain…

Something really unusual has happened to me for the second time within a year. I find myself working regularly inside a big corporate organization, specifically, I’m working with the same company regularly enough for them to have given me a company e-mail address, which means I need to log into corporation Outlook. It also means the corporation is sending me lots of internal stuff and people are communicating with me via e-mail and by referring me anonymous webpages and and and…

OK, for most of you this is normal, it was once too for me but I’ve spent most of the last 10 years working either with companies which aren’t big enough to do this sort of stuff or, I was wasn’t working with companies enough to get into this position.

I’ve noticed that I’m ignoring much of this material, I sometimes feel like I’m drowning. And I notice that I only skim read (at best) much of the stuff that is thrown at me. Its overwhelming and I have a very low tolerance level, perhaps because…

Above all what I notice is I feel troubled inside when confronted with pages and pages of corporate text. I even feel like crying. I switch off.

Little companies, growing companies, have this stuff too but much less of it. And usually you can find someone to ask. In the big company not only is there lots and lots but asking is hard - try calling IT support and you find out how much these people don’t want you to.

I’ve had this before but only now have I made a connection with my dyslexia because I’ve remembered where I’ve had these feeling before: at school and at University.

I realise that confronted with this mass of text I feel like I did when confronted with books at school.

It is not about reading, I love reading, I am reading several books for enjoyment at the moment and I continue to read the news papers and websites.

But confronted with masses of material I need to read, which not reading makes me in some way a failure, school text books and corporate webpages I feel inadequate, I feel intimidated, I want to cry and a bit of me feels like I’m at school.

It occurs to me that as companies rely more on automated systems, documented processes and policies, and they move away from conversation and human interaction then those of us who are dyslexic are at a disadvantage.

Sure I can read the words but I can’t process them.

Ironically, as I mentioned when I blogged about my dyslexia before, I think my dyslexia is an asset, I think dyslexia made me a better programmer. But equally dyslexia makes it harder for me to operate in a modern corporate environment. So by documenting themselves big corporates could be deterring or disabling the very people they want.

(I say disabling very specifically: Dyslexia is a socially constructed disability, it is only a disability because of the society we have created, in earlier, pre-text, societies it may be considered an advantage.)

Or is it just me? Do other dyslexics feel this? And what about the mass of non-dyslexics? - maybe they feel the same

This blog contains a lot of conjecture, free thinking if you prefer, I write to find out if others think this way - please comment.

Friday, December 23, 2016

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.

Monday, December 19, 2016

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?

Sunday, December 04, 2016

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.

Sunday, November 27, 2016

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.

Wednesday, November 02, 2016

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?

Monday, October 24, 2016

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.