Monday, June 29, 2015

The Prolonged Death Spiral Business Model

I recent message from a friend tells me he is putting on his parachute. He can’t take it anymore. He’s tried hard, very hard, to change a challenged company. Actually, I know a little bit more about this company than I should. I once told him that working there was like being aircrew in Catch-22: Only the sane should work there because it was cruel to employ ill people, but it was such a crazy environment wanting to leave was a sign of sanity.

Unfortunately this is not the only company I have heard of, even seen inside, in the last few years that have such a business model. In fact, I’ve now seen so many that I’ve named it: The Prolonged Death Spiral Business Model.

Let me explain… this requires two or three building blocks but I’ll get there…

In Business Patterns for Software Developers I wrote:

“Most [software] companies never make it past the conception stage: ideas stay in people’s heads, business plans fail to be funded or people start but lack the energy to follow through. Even those plans that get past inception regularly flounder – products fail to make it to market, and those which do fail to sell. …

Companies can fail at any time during their existence. However the younger a company is, the more likely it is to fail. Infant mortality is high: most companies under one year old fail. However, once a company is past its first year, survival chances improve remarkably. …

Death comes to a software company when its sales do not cover its costs. Once a software product is developed and sold, companies can reduce costs and continue selling the product. Companies that have an installed user base, particularly when customers are paying regularly for support services, can stagger on for months or even years. This process can be especially prolonged when customers have data locked up in a proprietary data formats or on servers.”

When I wrote this I was thinking of the growth of successful software companies, the kind of companies I wanted to work for. I first saw a prolonged death play out when I was working at Quadratron in the 1990s. What I never realised was that a prolonged death spiral could actually be a viable business model itself.

Quadratron was dying, it eked out its last few years collecting maintenance royalties from legacy customers - one customer in particular. In fact it was dying when I joined, they lured me in with a plan to spend a lot of the remaining cash on a new product. But things were worse than that.

Like so many companies Quadratron found that once you have survived the first few years, once you conquered the risk of developing a product and have an installed user base you can continue milking that base for a long time. Provided you don’t do anything silly like trying to develop a new product that is! Quadratron had been very successful, it had a lot of customers to milk.

When you reduce a software team to care and maintenance only your costs are much lower. Importantly your risks are much lower too, and you have cashflow. Yes, an accounting term I know but it means: money is coming in. And money continues to come in because while some customers may dump your product the longer you are in place the more difficult it is to dump. This is what accountants call “free cashflow”, its how much money the company has to play with, its a better measure than profit because profit can be gamed.

Now, like many others in the software industry I think of venture capitalists as nice people who live in Sand Hill Road, Palo Alto and invest in software companies with the capacity to grow very very fast and make everyone rich. Call this the Californian model of venture capital.

OK, these guys are not so lovable that you want to take them home to meet Mum and Dad but they have financed a lot of good software companies over the years - Lotus, Yahoo, Google. They invest in 100 companies, they expect 90 to lose money - they try to minimise it - 9 to break even and one to make so much money they make up for all the losses.

Then there is another type of financier. Call them the private investor or private equity. I think of this as the European model of venture capital. They buy existing companies and milk them. In buying they look for two things: lots of free cashflow (i.e. day to day profitability) and minimum risk (i.e. they really want to limit their down side.)

As far as possibly they buy the company with debt. With other types of company assets can be used to secure debt but software companies have few assets. So debt is serviced from the cashflow, and the cashflow comes from an installed user base who cannot, and do not want to, change.

Since debt is serviced from cashflow and cashflow comes from existing customers the emphasis is on keeping customers - don’t loose them! So most development work is driven by what individual customers want. Backlogs are stuffed full of customer specific requests.

Growing the company, especially developing new products, would be really risky. The owners and managers are into revenue protection. They want any new product development to be paid for by customers, software alchemy.

Software Alchemy: When a software company believes it can develop a “product” for one customer (preferably paid for by the customer) and then sell the same “product” to multiple other companies.

You can certainly develop technology for one client, you may solve their problems, but developing a product for multiple customers is a different undertaking. Very occasionally, at the start of a technology cycle, companies pull of this trick (usually by accident or by having a very stupid customer.)

Of course keeping customers means you need to persuade customers your product has a future so you need a bit of a roadmap, a bit of a vision but its weak and flexible. If an existing customer doesn’t like it change it! Forwards the end, like when I jumped from Quadratron, even maintaining the pretence of a future for the product is jettisoned to save money. The final few customers are trapped.

Because the company is now loaded down with debt (and needs to pay interest) they find making any sort of profit impossible. Actually, if there was some more free cash then the private equity owners would leverage it by taking on more debt and paying it out as dividend, or they would re-leverage the company - possibly by selling it to another private buyer.

Another trait you sometimes see with these companies is acquisitions: when they can these companies buy related companies who also have products which are past their best but have an installed base. Again they can do this with debt. They hope to get some technology crossover but in reality the people who run these companies don’t have the skills to do that so the mess gets bigger.

By the way: since the companies are loaded with debt they pay no tax because tax can be offset against debt.

These companies chase EBITDA - Earnings Before Interest Tax Depreciation and Amortisation. Because that is the only valuation which makes sense when the company has been leveraged to the hilt.

In short the company is being run as by “financial engineers” - and thats the polite term.

These people know a lot about debt structures and taxation but nothing about software businesses. Today they may be running a software business, tomorrow it could be toothpaste.

Its worth noting these companies want to be Agile because even these guys have heard that Agile will result in lower costs, faster delivering (faster cashflow), and happier customers (even fewer losses and even more reoccurring cashflow.) But they aren’t prepared to make the necessary changes, perhaps a little Agile training or coaching but anything that requires serious investment (e.g. TDD) is off the table.

These companies are a success by some criteria: they people running them and the people who buy them stand to make lots of money. Financially they look good - except the debt. And customer continue to use the products they want to use. They exist, they employ people. By some criteria they are a success, we should not forget this.

They can be miserable places to work in because real engineering is not a consideration. And pity the poor customers who are being led up the garden path about future products.

It would be criminal for any of these companies to take advantage of an ill person by offering them employment. As a sane consultant I’ve even tried to help a few of these companies. However, not wanting to work with these companies - as an employee, contractor or consultant - is a sign of sanity.

If you work for a company which is run by financial engineers in Britain, Europe, America, London, Cambridge, Cheshire or anywhere, you know what you should do for the sake of your sanity.

Thursday, June 18, 2015

Xanpan update

I’m glad to say I’ve just completed a minor update to Xanpan: Team Centric Agile Software Development. The new version is available right now from LeanPub, updates to the physical copy on Lulu will follow in time.

These changes are really just to make the book a bit more professional. The new version has:

  • A new professionally designed cover; this will end the situation where the physical and ebook versions had different covers (both of which were thrown together by me on wet afternoons.)
  • The ebook versions have genuine ISBN numbers; again this will follow for the physical version.

As to the future, I hope to put Xanpan on Amazon in time and I still have more draft chapters for Xanpan 2: The Means of Production but combination of being busy with work this year and moving house means progress is slow.

Tuesday, June 16, 2015

Scarcity, not Slack

Question: What is the opposite of Slack?

Or, perhaps a better question: What is the problem to which Slack is the answer?

Lots of software people like to advocating the benefits of slack for development teams. I’m not talking about the popular collaboration tool Slack, rather I’m talking about Slack in the sense discussed by Tom DeMarco in his book. DeMarco’s is a good book and has some good arguments but on the whole I’ve never been a fan of introducing random slack into the development process. (Have a look at my comments on Seb Rose’s blog post from a few years back to see what I mean.)

Now I’ve found a book, and two academics, who have done the hard work of creating an anti-dote:

Scarcity: Why having so little matters so much by Sendhil Mullainathan and Eidar Shafir (this is the UK edition, in the US the publishers have a different name slightly, Scarcity: The New Science of Having Less and How It Defines Our Lives)

Scarcity is the opposite of slack, and just maybe, scarcity is the problem which requires slack.

This book is highly recommended. Although it has nothing to do with the software community this book deserves to be essential reading for everyone who claims to know something about software management and in particular Agile.

The authors are ambitious if nothing else: they set out to create a new discipline, the study of scarcity. Although most of their experiments, examples and studies concern scarcity of money and/or time they endeavour to project their arguments into a more general space, scarcity of anything.

As you might expect, I read this as a software engineer. I read the book applying their thinking to the world of software and specifically Agile Software development. And after all, so much of managing software development comes down to the scarcity of time and the scarcity of money even if it manifests itself as a scarcity of people and excessive demands.

Now there is good news and bad news for software people.

First a little theory: the authors suggest that when people encounter scarcity they “tunnel”. In other words their mind starts devoting a lot of capacity to the resource which is in short supply. This has advantages: our focus increases, our productivity increases, some of judgement (yes estimating) skills improve and overall our effectiveness increases. Yes, scarcity can create productivity improvements. Scarcity is not all bad, it can be beneficial.

But there is a downside. For people in the scarcity tunnel their mind devotes a lot of time to thinking about this problem. As a result there are negative effects. Anything that doesn’t effect the short term tunnel is pushed to one side. So, for example, the short term benefits of taking a payday loan displace the long term problems which will be made worse.

This creates what the authors calls a “bandwidth tax”: so much of the mental energy is devoted to the tunnel and scarcity that less capacity is available for other things. For example, parents who have to juggle childcare arrangements for children are less effective at work.

The authors present serious evidence that the bandwidth tax reduces intellectual capacity, i.e. IQ, intelligence quotient. Perhaps controversial this leads them to suggest the poor are poor because they are poor, a vicious circle develops which is difficult to escape and traps people.

OK, enough of the book, read it yourself. What about software development? What does this book mean to software?

I see that tunnel a lot with development teams, they are doing stuff they know they shouldn’t but they feel they can’t afford to do the right thing. As a result they never get out of the mess they are in.

It is immediately obvious that one of the ways Agile Software Development - specifically iteration based Scrum, XP and my own Xanpan - work is by creating a short term scarcity of time (two weeks!) which causes tunnelling. Effectiveness goes up as items outside the tunnel are pushed out.

Work in progress limits (whether flow based or velocity/points based) are another form of induced scarcity. They force managers and product people specifically to tunnel on what is important, what needs going an they push less important items out.

But this comes at a cost.

One clear implication is that activities with benefits which will fall outside the tunnel will be dropped, skipped or minimise. And the obvious thing here is Technical Quality and improving the Technical Infrastructure. For example, adding automated tests, applying test driven development, improving the build system, refactoring, the list could go on.

(Indeed, it was worry about not investing in these which causes Seb Rose to advocate Slack.)

Mullainathan and Shafir give examples of poor farmers who save money by not taking out insurance against crop failure, drought or other possibilities. They also show how the same farmers would benefit and save money by taking out insurance.

They give example of vaccination programmes where those who will benefit - and know they will benefit - do not partake.

When they need the benefits of such insurance it is too late, they are tunnelling and cannot afford to invest. When they have the time or money to invest in insurance it seems unnecessary. People are optimistic and under estimate the risk to small problems occurring.

This is the same as teams who don’t do practices such as Test Driven Development. They are tunnelling.

There is more evidence here about the role of deadlines and routines: deadlines and routines help us manage our time and ensure things happen. The research presented in the book complement my own notes on time estimation (Notes on Estimation and Retrospective Estimation and More notes on Estimation Research). (It is because of such finding that I cling to fixed length iteration in Xanpan rather than going abandoning them like Kanban.)

And those vicious circles which keep poor people poor parallel software teams too. Poor people find problems which can be solved with a little money become very disruptive because even a little money is hard to find, they tunnel more, more problems are ignored. The current fire is extinguished but other problems are worse now.

I see the same thing with software teams. Projects run late and over budget so managers tunnel on the project, while this is happening other problems are building up, quality is neglected, technical debt is incurred, support tickets are left unanswered, changes which could help are put off until the fire is extinguished.

Sometimes I think the answer is simple: choose not to enter the scarcity trap, choose not to firefight, choose to do the right think. It reminds me of the talk JB Rainsberger gave on his 2015 European tour “Just Stop It.” It reminds me of Renton in Train Spotting: Choose Life. It reminds me of Joe Bergin’s (in)famous “Do the Right Thing.

Perhaps easier said than done, personally I have one piece of advice for these companies: Stop Thinking Projects. Project thinking obscures the problems and solutions.

The authors have some advice, some solutions, but they don’t have a complete solution. I find myself in the same boat: I can see how their arguments play out in software and I have some solutions but I don’t have them all.

Importantly they do identify Slack as part of the answer to Scarcity. Anyone who has studied queuing theory knows this.

Not only does this book deserve to be widely read in the software community - and specifically the Agile community - but I hope to see these two authors appearing at software conferences before long.

Finally, I consider myself lucky to have found this book. After several years where I struggled to find books which said something new I’ve been lucky enough to read three in the last year. (I blogged about Scaling Excellence last year (another must read), I didn’t blog about Joy by Richard Sheridan but his book deserves reading just for the share life affirming enjoyment, a reminder that software development can be and should be joyous! OK, I enjoyed it for another reason, Richard and I both had our lives changed by the same events on 2 January 2001, but that is a long story!)

Thursday, June 04, 2015

Agile is Punk - Agile is Democracy

From time to time I’ve been heard to say: “Agile is Punk.” But I’ve never explained myself.

I’ve also been heard to say things life “Agile is about democratising the workplace” but I’ve never explain myself there either.

Let me try…

What I mean when I say this is: Agile (software development) has a lot in common with Punk rock.

To me the important thing about punk rock was that it was about people trying it - music, their own thing. Anybody trying to play music, anybody forming a band, anyone who had a novel idea trying to get a record contract. Yes, even if they couldn’t play an instrument they could have a go, and who knows, maybe they would learn as they went.

(I should say that while I’m old enough to have been around when punk was I’m not old enough to have been there. Both post-punk and post-disco influences were at work in the New Wave music which was common when I came music listening.)

Punk had a democratising effect on music. Music has aways been of the people, anyone can listen, anyone can try to sing - although I’m not very good at it even I can try! But the music industry was something different, performing, recording - there were barriers there! Punk tore down barriers.

Punk opened up the recording industry. Punk opened up music.

Agile opened up the software process industry.

Before Agile official software processes were pretty locked down. You had to be an academic or expert/consultant to dabble in that space. Programmers who worked in under official software processes were on the receiving end.

Agile said: “Your opinion is important too.”

In truth music has always was been open to everyone, just not the recording industry. And in software development processes were open to anyone, most programmers did not work under an official process, mostly it was common practices which, if they worked, were probably more effective than official ones.

Unfortunately these unofficial work practices came with guilt: because we did not do it the way the books said we should. When faults occurred we blame ourselves for “not doing it properly”.

Agile says: “Everyone involved with software development should have a voice in deciding how to work, it can be improved and you don’t need to be an expert, academic, consultant or certified member of some body to express that view.”

That also makes it democratic.

I don’t mean democratic in the sense that we all get to vote, I mean democratic in the sense that it is power is vested in the hands of the collective people. Everyone has a voice, everyone can participate, and those who hold executive power do so by the will of the people.

Agile is about giving everyone a voice. Like Punk that means accept that those who don’t have much skill are also entitled to a voice.

Funnily enough, I’ve long held that any punk band that made a second album weren’t punk anymore because they were part of the industry, they were now experts! The same is true with Agile, hang around for long enough (like me) and you are no longer an outside but an insider, an expert.

Increasingly we see Agile heading outside of software development. When this happens it becomes necessary to ask: What is Agile?

My answer is: Democracy.

Agile is about valuing everyone, agile is about giving everyone a voice, agile is about putting the power to change the workplace (process, systems, norms) into the collective hands of the people who work there.

Yes at times it feels revolutionary, but there are fellow travellers, it is all a Theory-Y movement.

Wednesday, June 03, 2015

Agile Banking conference

For the record… OK, so I don’t loose the URL…

Despite my scepticism about Agile in Banking environments, particularly investment banking, I’ve also become convinced that those who are attempting Agile enablement/transition/working/change in a banking environment need help!

Specifically I think they need their own conference. Having looked at some of the available conferences I think they are rubbish. So I’ve prodded the good people at Software Acumen to make it happen. I also intend to keep a big dirty finger in the pie to make sure they come up with a good programme - although I don’t plan to speak myself.

So, if you want for a bank, and you are trying Agile of any description mark your calendar with Friday 20 November and sign-up for notifications at the Agile Banking conference website - http://agileinbanking.net/2015/.

Friday, May 15, 2015

Some notes on Taking the Temperature

There is a technique sometimes used in retrospectives, and sometimes called “Taking the temperature” but in truth it can be used in many settings and I’m sure it goes by various names. Basically, you pose some question to a group, for example:

“How well do we feel the last iteration went?”

“How much do you know about Agile?”

“Are you confident we can meet this objective?”

Everyone takes a piece of paper - usually a sheet of post-it paper - and writes a number from 1 to 10. Depending on your question the number 1 means: bad, nothing, unlikely, while 10 means something like: brilliant, everything, certain.

The papers are folded (its anonymous), collected and opened.

The anonymous bit is important: I once sat with a team where everyone answered 6 to the question “How did this sprint go?”. In my opinion the sprint was horrid, indeed the whole initiative was a mess but I too answered 6. Maybe I answered 6 because the people before me had anchored my answer, maybe I answered 6 to conform with the group, maybe I didn’t want to rock the boat. But probably I answered 6 because in my opinion the manager running the team, the initiative, and this meeting was the cause of most of the problems and I felt that anyone who tried to speak up would be quizzed as to “Why do you say that?” and the answer “Because you really don’t get it you silly old …” was not very useful.

The thing is, once you have those numbers they are a talking point. I like to post them up on a board, in order, where we can see them and discuss them. If the question is “Are we confident in our ability to meet this goal?” and I am faced with a lot of scores around 6 or 7 I might say: “What could we do to increase our confidence?” and we could have a general discussion about this.

I usually use this technique at the start of a training session to judge the knowledge of Agile in the room. That helps me adjust my level of delivery to the audience.

The thing about this technique that I wanted to bring up today is this: the mean isn’t particularly interesting, i.e. summing all the number and dividing by the number of votes to achieve a mean average isn’t very useful. In part this is because the average does’t tell us much, regression to mean will happen and it doesn’t really give you anything to talk about.

Sure, its a bit of a vanity metric: “Look we scored 6.8 which is up from 6.65 last iteration!”

Median (ordered middle) might be more interesting. And mode (most common) is certainly more interesting. They are things to talk about. Faced with 8, 6, 6, 6, 5, 3: “Why do most people think this iteration went well but not everyone?”

There may be value in recording an average to track the ups and downs over time. I’m not sure there is but if I was I’d rant to track the median rather than the mean, to my mind that will contain more information than a mean. (However even here I’d get worried about Goodhart’s Law and goal displacement, someone might think the aim of an iteration was to have a good iteration.)

But what is really interesting, and the reason why all averages aren’t that interesting is because it is the extremes which are the most interesting.

“Why do we think that someone thought the iteration was not very good?”

“What could have caused someone to rate the iteration as high as 8?”

“How could we have a good (8) and a poor (3) in the same iteration?”

The extremes, particularly when there are opposing answers, make a good talking point. They are something to talk about. Remember of course to keep it anonymous: don’t ask “Will who ever scored 3 explain why they dissent?”, ask instead “What do we think made someone rate the iteration as a 3?”

So if you are going to use this technique please:

  • Keep it anonymous
  • Share the results with the whole group
  • Avoid the mean
  • Talk about the extremes
  • Talk about how you could score higher in future

Monday, April 27, 2015

The Kanban paradox

I’m a big fan of David Anderson’s Kanban method, I always said my brand of “Agile” was heavily infused with Lean before David presented Kanban. In the same way that Kent Beck said Extreme Programming was about “turning the dials up to 10” David turned the Lean ideas behind Agile up to 10 and in the process dropped a lot of we (the Agile community) had come to regard as accepted wisdom - stuff like iterations and estimation techniques.

From my vantage point, sitting on the side of the Kanban community all these years, I’ve noticed two trends. Firstly Kanban as stripped itself down. I seem to recall someone saying the way to start Kanban was to “visualise your work in progress and take it from there.” Second, Kanban has relaxed its focus on software development. It now bills itself as a management method or even a “change management” method. The net result is that even as Kanban itself has slimmed its applicability has broadened.

Stripping away non-essential elements makes Kanban simpler to communicate and understand but at the same time says less about what you should actually do. Kanban is getting closer and closer to its Lean roots. I’ve long considered Lean to be more of a meta-method than a method, that is to say: Lean doesn’t tell you how to work (unlike say Scrum) but it tells you how to think about how you work. I sometimes say “Scrum and XP tell you what to do at 9.30am tomorrow morning while Lean tells you how to think about what you will do at 9.30 tomorrow morning.”

I have no disagreement with the way Kanban is going, I still like it as an approach and I think the people who are changing it are doing the right thing. (The opportunist side of me might even reason that as Kanban distances itself from software development it leaves a gap in the market that Xanpan is ideally placed to exploit, but that would be incredibly cynical of me and risks all my credibility!)

(I should mention that while I’ve been invited to a couple of Kanban “Leadership Summits” I’ve never attended, a combination of my natural Groucho Marx tendency and family commitments means I’ve opted not to contibute.)

But… and here is the meat of this blog post…. I think the way Kanban is going creates a paradox.

As Kanban gets briefer and smaller then implementing Kanban requires more expert knowledge.

You can put up a Kanban board and track your flow and work in progress. You can set WIP limits. But if you don’t know how to read the board you don’t know how to act on it. And if you do know how to read the board acting on it isn’t always a rationale engineering discussion: acting on the board often involves office politics.

For example, I once helped a company create a Kanban board with many (too many) steps and (too) many queues. After a few weeks the problems were obvious. But instead of acting to remove the problems the board was used in evidence to apportion blame.

Kanban can generate many metrics: cycle time, lead time, utilisation, etc. etc. But if you don’t know what these metrics mean they are pointless. And even if you do know what they mean knowing how to act on them is another matter.

For example, Kanban relies on queueing theory, some of the things queuing theory suggest you do is counter-intuitive like reducing work in progress, and therefore worker utilisation to speed throughput.

Sure you can learn queueing theory, you can read the books, you can learn about metrics, you can reason about your own board but these things take time. Even then I doubt if any book, course or programme can give you the knowledge and understanding that comes form experience, from seeing it done before and from seeing multiple implementations.

In at full-throttle Kanban teams dispense with iterations and estimation. They substitute statistical analysis for estimation - and I believe that is a “better” approach but that also requires a good understanding of statistics. Most people are pushed to remember one distribution and when they do its standard-distribution but software work is unlikely to follow standard distribution so unless you know there are others you will come unstuck.

Then take value, Kanban - like Lean - aims to enhance value. But how do you define value? What is valuable to your organization? Is value quantity? What do you do when you can’t put a dollar amount on value? Someone needs to understand value and how to work with it.

And then there is software development itself. Implementing Kanban in a software development environment has many more issues. You need an understanding of quality, an understanding of software products (features or solutions) and more - even before you get to the technical stuff!

To my mind this makes Kanban difficult. It requires expert knowledge. Sure you can learn this stuff - book your Kanban course now! - but it takes time. I started studying software development properly in the reading room of Liverpool Library nearly 30 years ago and I still don’t know everything.

And its not only my study of software development that I find essential in helping teams with Kanban. Years spent studying economics, years spent reading management books and yes, time spent at business school earning a degree so many in our profession (not without reason) rubbish but which equipped me with understanding I use regularly. When I help teams with Kanban I draw on all these sources.

Sure this is good news for me, it makes work for Agile/Kanban Consultants (sorry, Coaches) but it also makes harder for non-experts to practise. And most people trying to do Kanban are experts in software technologies not process and flow.

So here is the Kanban paradox again: as Kanban gets briefer and simpler practicing Kanban requires more expert knowledge.

The beauty of Scrum and XP was that you could practice them quite well without expert knowledge. You may never be the greatest team on earth but frankly most businesses don’t care about that, they want something (anything!) better than what went before.

You don’t need to be great at Scrum/XP to get benefit: stick to a two week iteration cycle (most of the time), get a clear steer on work prioritisation once every two weeks, hold some kind of regular meeting, thats about it. Sure its good if the stand-ups a short, if you don’t work from a requirements document, if you do retrospectives, and especially if you do some of the technical practices. But, just doing the basics it is democratic and everyone can understand it.

Scrum and XP made the development process accessible to those who practice it, they can reason about it. Kanban done well is far far better, but Kanban done badly, without understanding? I suspect it is dangerous.

I’m not sure Kanban is the same, I think understanding Kanban requires a lot more understanding, therefore Kanban is not democratic, it is more of a management method, more of an experts approach. And this its a paradox.

And what of Xanpan?

Does my Xanpan approach suffer the same problem?

Well maybe, but I am the worst person to ask, I’m biased. Xanpan is “the way Allan Kelly does it” - well, it was, a few others are now trying it now. Maybe Xanpan does, after all Xanpan tries to have its cake and eat is, I give detailed description of how to do Xanpan but at the same time say “make your own method.” I sincerely hope I can keep Xanpan democratic.

Maybe Xanpan is just a training version of Kanban. Maybe Xanpan is a cut down Kanban, maybe its a neutered Kanban. Maybe when you’ve practiced Xanpan for a bit you can mutate so its more Kanban. Anyway, who cares what you call it.

Thursday, April 16, 2015

Managers are not homogenous

(If you are not a coder please bear with me…. we’ll get to the business point in a moment.)

When a programmer finds a class named Manager in a code base they know - or at least should know - that it is probably a smell. It might be innocent but until proven so it should be considered guilty.

For example…

SecurityManager

LogManager

DatabaseManager

I’ve written a few of these myself in my time, and I may even write some more in future. But that does not make them good.

The problem with “manager objects” is that they are usually a vaguely connected set of functionality which either deserves a better name (SecurityValidator, Logging, or some such) or they are worth breaking up into multiple classes each of which has its own clearer purpose (DatabaseUser, DatabaseConnection, DatabaseFinder….). And sometimes, some of those functions would be better off as a stand alone function not bundled into a class because it happens to share part of a name.

Now let me suggest the same is true of job titles and roles which include Manager in the title.

For example: I am writing this on a train, my ticket has just been checked by the “Train Manager”. This is a position that used to be called “Train Guard.” I must assume that the Train Manager’s job entails more than just checking tickets, similarly the Guards job entailed more than just loading the guard van with good.

Does the Train Manager have the authority to order the train driver to pass a red signal? - I don’t know but I assume (and hope) not.

Does a Train Manager have the authority to order the catering crew to reduce prices? - I don’t know but would expect prices to be decided centrally or for catering staff to have the authority - perhaps under standing orders - to reduce prices under some circumstances.

Personally I prefer the old title “Guard” but perhaps there is some reason - other than presentation - why the position is is no longer called a guard. But since I have no deep insights into exactly what actions this person undertakes or what their responsibilities are I can’t really comment.

In the same way that I don’t really know your code base so shouldn’t really comment on your class naming. However, I can say, that given my limited knowledge I detect a smell.

Now there are a lot of people in the Agile community who are very anti-manager. They see self-organizing teams etc. as a way of removing managers. While I have understand their position and think maybe some “managers” would be better removed and the teams allowed to “get on with it” I don’t think its that simple.

But I also think when developing software, when doing many other activities too, and in an organization, be it big or small there are often many vaguely related things what need to be looked after. Big organizations tend to have more of these than small because of their nature. Some of these things that need doing are the result of people inside the team and some from outside. Resolving many of these things requires being in possession of information, it requires a degree of authority and more importantly competence. What do we call someone who deals with all this? Well, a Manager.

For a few years I’ve been trying to find the time and energy to write a comprehensive blog series on the topic of managers in software development but I can’t. I see another land mine, if I weigh in on this debate I expect both sides will attack me and neither will really appreciate my position. So you may have to wait a bit longer but I think the above discussion illustrates an important point…

The formal title of “Manager” (and even the informal use of “Manager”) hides a lot. Some of those roles, like Product Manager or Build Manager, can be quite focused and specific. But many of those roles are catch all roles with mixed responsibilities which may, or may not, be better filled by a specialists or by devolving authority to do the work to others.

Some of these tasks - like checking tickets on a train - should not be needed and should not exist, everyone should buy a ticket and pay the fare! Much of the train manager role is because we don’t live in a utopian socialist society. (Although history shows managers were just more to running of socialist societies as capitalist ones.)

So please, before anyone tries to remove a manager please examine what they actually do, and whether the role would benefit from a better, specific title. Or whether it actually makes sense to have a someone catching all the other stuff in a vaguely defined role.

Saturday, April 11, 2015

Agile on the Beach voting procedure

Nothing exciting but to save me from explaining this again and again….

Yesterday the Agile on the Beach conference committee finalised the speaker lineup. I’ve just this morning sent the acceptances and the “Sorry” e-mails. Since there were about 150 submissions and only 41 slots to speak in we cold only accept less than a third of the submissions - even fewer actually because some sessions are doubles.

Here is how we came to our decisions.

We have five committee members - you can see who on the website. Each of these was given electronic copies of all the submissions - including long and short synopsis, speaker bio, travel origin (implying how expensive it might be for us to bring someone in) and other details.

Each committee member independently scored each submission on a scale from -2 (I don’t think this should be at the conference) to +2 (I really want to see this myself.) By making Zero the default any reviewer who didn’t review a session or felt they did not have the knowledge to pass judgement didn’t bias the results. Sometimes reviewers made a comment as to why they had given this score but not always.

I took these scores and added them together. In the first review meeting (two weeks ago) we reviewed the total scores, debated a few sessions and the top scoring sessions were short listed.

In the product track 17 were shortlisted, business 13 and for the team track 27 made the shortlist. Again each reviewer independently reviewed the shortlist. Software was slightly different because we again decided to make extra space to keep our technical side, more to follow. Since Product expanded from one day to two days this year it means the conference has grown again.

But this time instead of scoring the sessions reviewers ranked them. Each track has 9 sessions (if all are single) and each reviewer ranked the sessions knowing this.

For the second meeting I took these rankings and averaged them for each session then in each tack ordered the track. At this point we had some clear accepts. At the 9 mark things became fuzzy, in one track we had a double in position 9, in another track one person had three slots in the top 9 and so on. So some manual adjustments were made. We also made a call on some things we thought should be in the conference or developed mini-themes.

In the end a lot of sessions didn’t make the cut simply because they were out competed. Everything that made the shortlist was strong, a lot that didn’t make the shortlist was strong too. We just don’t have space for everything we would like and can’t expand the conference every time, sorry.

Anyway, I hope that explanations helps.

Wednesday, April 08, 2015

Thoughts on 6-Sigma and Agile

Question that comes up from time to time:

"Does anyone have Agile project which is Six Sigma? How these two things Six Sigma and Agile complement each other on software product development project? “

My answer:

In theory Agile and 6-Sigma should fit, they both have their roots in the quality movement.

A cursory glance at the 6-Sigma toolset reveals similarities to the Lean toolkit - continuous improvement, root course analysis, statistical methods, so at first it looks good but…

While there are a few stories of Agile and 6-Sigma working successfully together my own experience, and the majority of the stories I hear are that they are contrary.

Let me briefly share my experience....

I did some work with a financial services company which was a big believer in 6-Sigma. Any change had to be set up as a 6-Sigma change, with a business objective, current status measurement, target, approach, etc. Its difficult to argue with such a rational position but it was hard to pull all these bits together.

The change then needed to be signed off by more senior managers as a 6-Sigma effort. And it was hard to get the necessary managers in the same room at the same time. Which meant efforts didn't get signed off.

And with all this effort you needed to put a lot of effort into any change which meant even thinking about change was expensive.

The net effect was to freeze the status quo. Six-Sigma had the effect of preventing change not supporting it.

On a day to day level the attention paid to variance was highly detrimental. Teams adopted behaviours designed to minimize variance (e.g. differences between estimated effort and actual effort) which both made measurements unreliable and made people wary of any change, experimentation or risk. (They had bonuses related to variance reduction.)

It seems there are some big difference between 6-Sigma and Agile, if not in intent then in implementation:

  • 6-Sigma is very top down, Agile is traditionally bottom up (although this is changing)
  • 6-Sigma is process and plan driven, 6-Sigma demands evidence; Agile is more “experiment and see what happens”, in other words Agile is happier with failed experiments
  • 6-Sigma demands study from its devotees (all those belts!) while Agile benefits from study it is a free-for-all when it comes to what to do (this may well be a disadvantage)
  • 6-Sigma anoints experts (black belts) while Agile is much more egalitarian (or at least should be)

So while Agile and 6-Sigma may have somethings in common they are culturally incompatible.

And as for the newer mutant form of 6-Sigma known as “Lean 6-Sigma”, well let me quote something I heard Dave Snowden say at a conference a couple of years back:

“Lean 6-Sigma is about removing all the waste that 6-Sigma introduces.”