Two types of demand: Value Demand and Failure Demand

There are two broad types of demand on any service centre - value demand, the calls we want and failure demand, that calls we don't want.  Value demand is what the xervice center exists to serve; it represents the demands customers made for things they want, things that are of value to them.  Failure demand is created by the organisation not working properly.  I define it as follows:

Failure demand is demand caused by a failure to do something or do something right for the customer.

John Seddon - Freedom from Command and Control: Rethinking Management for Lean Service 

Posted via web from What Stringer's Reading

Adventures in Agile (with me!)

Max St John, one of the extremely talented bunch over at NixonMcInnes in Brighton has written a blog about the real nitty gritty experience of implementing Agile practices on a large, multi-stakeholder web development project.

Very kindly, he gives me a name check.

For further information, contact mark.stringer@gmail.com (07736 807 604)

Tuesday night #xtc after the innovation games

I was talking to @benjaminm and telling him how excellent I thought his rendition of the red bead game was. And I was also talking to him about how I thought John Seddon's ideas were great but that I didn't think telling people that they were stupid (which is what he seems to do in his talks) is a particularly effective method of helping them change. Benjamin said that Seddon doesn't do that when he's actually consulting. He keeps quite and tries to find people that he calls "curious" members of management that might not be so hypnotised by the system that they're in that they can't still be interested in the actual problems of the work.

Benjamin seemed to like the comment I'd made at the red bead game about the RBG being a way of teaching Learned Helplessness as it's described in Seligman's book. I wondered if the people that Seddon finds in big organisations are the people who refuse to learn helplessness - just as about one third of Seligman's miserable electrocuted dogs refuse to learn it. I also talked about "The Psychology of Military Incompetence" and how some people must somehow manage to not get crushed by what Dixon calls "bullshit" otherwise we would never get any good military leaders.

Oh dear, sounds like I did most of the talking.

For further information, contact mark.stringer@gmail.com (07736 807 604)

4 Reasons for Doing Anything (and why you should attend Building the Lean Web Development Team)

I recently read somewhere that there are only four kinds of reasons that persuade anybody to do anything. Since I sincerely think that anybody who has anything to do with web development should DO MY COURSE - Building the Lean Web Development Team, I thought I'd try all four of them.

Everybody is Doing this Course

Well, actually they're doing similar courses. Almost everybody involved with software development is now taking a look at Lean and Kanban. If you do this course, you'll be joining hundreds of thousands, if not millions of people worldwide who are realising that the approach of the Toyota Motor Company has something to teach them about their own business. But Shhh. Don't tell everybody this. Hang on a minute, what am I saying do tell everybody this. It's really important: Web development is different from making cars. Lots of people are talking about Lean and Kanban getting in consultants and going on courses, but they're trying to take what worked for making cars and clumsily attach it with staples and masking tape to the rather different process of software development. The differences between traditional software development and web development are mere details: kinds of details that Toyota's process guru Taiichi Ohno made a world-beating company by paying attention to.

Nobody is Doing this Course

If you do this course, you'll be in an elite minority. You'll be a rebel, a revolutionary, a true visionary. Almost nobody else is actually taking the principles that Taiichi Ohno used to develop the world's biggest car company and using them to actually understand and radically change the way people do web development. What most people are trying to do is to modify the practices which is, to be frank, just a little bit crazy. If you do this course, you won't just be giving your company a head start, because most companies will never be able to see web development this way. This course will teach you to look at your web development team in a way that will allow you to massively improve the effectiveness of what you do.

If you don't DO THIS COURSE Bad things will happen

If you don't do this course, or apply the kind of the ideas that we deal with in this course, bad things will happen to your Web development team. Quite simply, you will be overtaken by the web development companies and teams that do start to shape the way they work by the unique nature of web development problems. You won't be able to compete with these teams in terms of quality, cost or speed of turnaround. You know what's even worse? Evidence from what happened in the car industry is that even when things are utterly disastrous, you won't be able to see the problem.

If you do DO THIS COURSE Good things will happen

Lean web development is about learning to see web development for what it really is. Once you start to understand that "project management" is not a set of rules which you can learn on a course, but an attitude, once you decide to shape your team so that it is continually changing to match the shape of the problems that you have to solve, things get better. Once you start to understand concepts that are particularly pertinent to web development and not particularly pertinent to car manufacture, such as the difference between value demand and failure demand, you are in a position to give your customer what they want and to make money doing it.

Money, Money, Money

Number 5 of the 4 reasons why anybody does anything. I'm not that big a fan of using money as a way of motivating people but... Once you understand what the value is that you're delivering to your customer, you can work on getting that value to flow through your team really fast. The more value the work you do has to your customers, the more they'll want from you, the more they'll pay you.

Money Back

I'm so convinced that this course is going to help you build a better, more effective, web development team that makes you lots and lots of money that I'm offering a money back guarantee - if you come on this course and you don't feel that it's delivered what it promised, I'll give you your money back. No arguments. No hassles, no questions asked.

Money for Free

If you don't think this course is right for you, but you know somebody who it would suit to a tee. Tell them to mention your name when they book the place and I'll give you a 10% affiliates fee.


For further information, contact mark.stringer@gmail.com (07736 807 604)

Do we need one?

When I talked about difficult conversations at Agile Yorkshire last week, the subject of "Hero Programmers" (HPs) came up. What is a "hero programmer"? Lets give ourselves a working definition. A Hero Programmer is someone who:

• Is deferred to by all the other programmers
• Has deep technical knowledge of the product/system.
• Very busy, he works long hours, he pulls all-nighters for the good of the company – hey, he’s a HERO.
• Widely regarded as indispensable by other people in the company.
• Rarely takes holidays.

Sounds great. A hard-working, highly-skilled and very valuable member of the team. So what’s the problem? Well, there can be a few problems. Here are some other possible features of the Hero programmer.

• Makes big technical decisions without consultation (i.e. changing the implementation language for the entire project).
• Saves technically difficult work for himself rather than distributing it through the team.
• Decides what features get worked on next
• Regards himself as the architectural (or even moral, aesthetic) guardian of this system. And regards these ideas as higher than any mere “business” goals.
• Refuses to pair program (often suggests code reviews as an alternative, though they rarely actually happen).
• Rejects as a "waste of time" or a "fad" any of the basic technical improvement practices suggested by Agile: continuous integration, refactoring, Test Driven Development and even sometimes source code control.
• Is DEEPLY suspicious of consultants.

Do any of these sound familiar? Is this you?

When I talked at Agile Yorkshire the subject of "Hero Programmers" (HPs) came up when I was talking about issues around identity. I talked about 5 identity dimensions which I got from this book - "Beyond Reason":

• Appreciation
• Autonomy
• Status
• Affiliation
• Role

And when you think of Hero Programmers in line with these identity dimensions you can see how difficult it is to budge an HP. Along each of these dimensions, our HP is strongly rewarded. They get lots of appreciation – bosses, project managers, customers are grateful when they finally get the functionality that they want. Because the HP is the only one that can do a lot of the trickier bits of development they have the autonomy to decide what gets done, in what order. In the company and sometimes also by customers the HP is regarded with high status.

Very often, the HP's affiliations are not to the team that he works with. He may also feel an affiliation to an international band of coding gurus whom he talks to daily online and sees at conferences. To him, what they think of what he does is far more important than his work colleagues. And this brings us to his role as he sees it – keeper of the pure flame of the architectural (or sometimes even artistic, ethical) integrity of the project.

He probably gets very sniffy whenever anybody talks about money.

So, along 5 different measures of positive identity, the position of HP buries the needle. No wonder HP’s don’t want to change. From the HP’s point of view, the only direction is down. If he changes the way he works, if he gets promoted, he moves away from things that he knows (software development) to things he doesn't know (business, team-leading, management).

Do you have a problem with an HP? Here are some things you might try that I know have worked elsewhere. Most of these suggested approaches involve increasing the HPs status and autonomy rather than attacking and restricting them, which is what the usual (and greatly feared) move into team-leading and project management threatens:

• Reduce the work load for the HP: Insist that he take his holiday. When he is at work, he shouldn’t be max-ed out, he should be given time to teach others what he knows and think strategically.
• Turn the HP into an internal consultant – whose job is to roam between projects and solve the really hard problems.
• Turn the HP into a "fellow" who's job is to think great thoughts and come up with new ideas.
• Get him to talk and teach, write books, to your staff and on the conference circuit. It will be worth the travel expenses.
• Turn the HP into an external consultant, hire out his specific, excellent skills to other companies.
• Turn the HP into an open source guru – put some aspect of your project out in the public domain and give your HP the task of leading it.
• Turn your Hero Programmer from a Code Geek into a Business Geek. A friend of mine used to write the software for the hedge fund that he part-owns, but now he involves himself far more in the minutiae of the tax laws and the mechanics of limited liability partnerships.

One thing that occurs to me is that if you keep seeing the same situation again and again, it must be a "stable" situation – what John Nash would call an "equilibrium". There are powerful the drivers are to keep somebody in this role (run through the identity list and think about the role of project manager – why would anybody want to be one?). The trouble is that it's a local equilibrium that prevents any kind of positive change. If a team that has formed around a "hero" programmer, out of frustration with this stability and stuck-ed-ness, very bad things can happen.

Yeah, yeah, he's a life-saver, but you don't have to work with him

If the HP is a founder they can be ousted in a coup by other board members. Or if the company finds finance, or is taken over, they are swiftly removed (VC’s have developed the sharpest skills for dealing with HPs through sheer necessity). Often the team or the company around the HP just evapourates, the juniors get less junior, read the writing on the wall and walk away. But these are actually good outcomes compared to the most likely outcomes in the short term.

Things carry on as they are.

Slides for Tonight's Talk - Software without (so many) Tears

Here are the slides for tonight's talk - Software without (so many) tears.

For further information, contact mark.stringer@gmail.com (07736 807 604)

Affiliate Policy

OK, this is my affiliate policy, which, as far as I can see is far more generous than some people's, not mentioning no names, Amazon.

It's this: if someone books a course with me and they mention your name, I send you 10% of the course fee (so with my current course: "Building the Lean Web Development Team", if you send someone in my direction, I would send you £35).  If you were to send a big chunk of consultancy my way - your cut could be considerably more than that.

So please, if you know anybody who's working in web development, or trying to manage a web development team, or trying to work with a web development team, send them in my direction and tell them to mention your name. 

It'll be worth your while.

If you know anybody who wants someone to help them get their web or software development teams working in a more Lean, more Agile way and needs a consultant, or coach to help them do it, again:

I'm your man

And there could be something in it for you.

Disclaimer: If I think you're doing anything dodgy, or spamming people, or trying to trick people into buying my courses or for any other reason I think that you're not being perfectly above board and honest in your recommendation, not only will I be very annoyed, I reserve the right not to pay you. Be nice.


For further information, contact mark.stringer@gmail.com (07736 807 604)

Comments on John Seddon's Re-Thinking Lean Service

We'll cover the differences between failure demand and value demand, and how you might look harder at the nature of demand in your organisation in my course on 27th November - "Building the Lean Web Development Team"

Things I get out of this Podcast, my instinct was right. In order to get the best out of the Toyota Production System, you have to stick with the meta-principles. The details, about how to build cars of the rate of demand, rather unsurprisingly don't apply to software development - or web development.

His major insight, which doesn't attack "genuine" lean thinking, but which completely alters the way that it's implemented in software is saying that the Toyota Production System was shaped by the shape of demand. Curiously, although Womack and Jones and Taiichi Ohno talk about the nature of the economic cycle being the reason that Taiichi Ohno approached building cars in the way he did, Seddon doesn't mention this. But this is important as well. It's what I call the "Delta Blues" it's not enough to know what demand is now, or what it has been, you need to know how it changes over time. Is there a pattern? This isn't the stock market. Previous performance is a guide to future performance.

The other major, contribution of this piece which is especially important for web developers is the distinction between value demand and failure demand. I see now that the lack of this distinction has almost made a nonsense of trying to implement Agile practices in a web development environment. When you're making things in a factory in a "traditional" way, a substantial amount of the work that you do is work that you've planned to do (value demand). In web development, when I sit in on sprint retrospectives, it turns out that about half of the work that was done in any sprint wasn't planned, it was reactive to the customers need, mostly because things hadn't gone the way they should have (failure demand). A large amount of this seems to be farting about with hosting, browser compatibility, caching causing old files to still be visible. All that kind of stuff.

Seddon's point is that if you really want to improve the efficiency of your service company (and lets for now, assume that a web development company is a service company) then you have to understand and tackle the failure demand and set up systems to deal with it. There's hardly anything about this in Agile, there's nothing about this that I've seen in the writing about Lean for software.

One thing that you can do, which I'm certain is not being done, is to train the people who field the reports of failure demand in the technologies and techniques that they need to deal with the most common failure demand problems.

What Seddon says is that you have to look hard at your business and see what the crucial problems are. Then you have to try to find solutions. One of the ways to find solutions is hypothesis testing - try a bunch of different solutions, but make it clear to yourself what solutions you are trying and that they are just hypotheses.

Some counter-intuitive things that emerged form Taiichi Ohno's investigations which probably do transfer to services is that end-to-end time is cost, not activity. So many companies that I go into are obsessed with keeping their designers and programmers busy the whole time. Even some of the programmers and designers don't like to be seen to not be scheduled at capacity, or over-capacity. Some managers have seriously said to me that they don't think their developers will work hard enough unless they schedule for them far more work than they can possibly do in the time. Obsession with activity cost obscures the end-to-end cost. i

Some questions that you need answers to if you're a web development agency.

• What is the normal relationship between value demand and failure demand? I.e. If a project seems to be a "£10K" value demand project, how much failure demand will it generate?
• What is the nature of that failure demand? How much of it is preventable through changes in procedures?
• What is the pattern of demand throughout the year? Even over the years? What can you do in times of low demand to improve the performance of the company?

Some criticisms of Seddon's approach. He's an academic. So he assumes that everybody else in the world is stupid. I think most of the people I meet are pretty smart and doing the best they can with the information they have. Telling people that they're STOOPID just doesn't work as a consultancy approach. But for me, having thought about this a lot over the last few years, his analysis is compelling. I think the division between value demand and failure demand is absolutely crucial for web development companies to understand.

For further information, contact mark.stringer@gmail.com (07736 807 604)

Building the Lean Web Development Team - 27th November central London

This course will be run at The Hatton

This course is the v1.0 of the beta course that I ran in Bristol 6 weeks ago.  Improved as a result of the great feedback that I got from that course.


Waste

This is the focus of a lot of discussions about Lean, but it's not the focus of this course. The focus is on:
* understanding what it is that you do
* which bits of that are actually of value to your customer
* how can you let them flow through your organisation quicker and more smoothly
* how can you stop yourself doing the things that don't add value

Value Stream Mapping

One way of looking at a business is an entity that creates value. A very simple scheme for reducing waste is to map what the value is that you're providing to your customers and then doing what you can to reduce, or completely eliminate any other activities which do not provide value to the customers.

Another way of improving the value stream is to make sure that value work flows steadily through the organisation with value being added at each stage. Through mapping the stream we can see how it can be reconfigured so that value added at one stage flow directly into the next stage where value is added.

With web development teams, my experience is that there can be problems here with flow of value into and out of the development team, there can be also problems with the timing of adding in design elements and content elements that are not independent from software functionality.

Flow

A central concept in the Toyota Production system is that work is carried out most efficiently if it flows through the team. It follows that this can't be done if every part of the process is running at 100% because, inevitable, the capacity of some parts of the chain will have higher capacity and some other parts of the chain will have lower capacity. The very first thing to do to improve flow through a team is to look at points along the production chain where work is building up.

In web development, this point is often testing. There are several ways of reducing this bottle neck:

* training up the whole team so that they can work in testing when there is work building up there.
* Abandoning testing as a separate function all together and relying on a comprehensive approach to Test Driven Development
* Pulling work through the system only at the rate that the lowest capacity section of the chain can deal with.
* Reducing the workload for the most experienced team members and using their extra capacity to improve the skills of less-experienced team members.


Kanban

I'm reluctant to use Japanese words when talking about Lean - as you see I've used very few - because one of my rules is that "Agile is not a license to speak Elvish or Klingon". Kanban simply ways of signalling what work needs doing and also of communicating to the team how they are performing.

Kanban is the system of signals that create flow of value through a team. One way of using a Kanban system is to create "pull" through the team so that work is only initiated when there is capacity further down the stream for it to be dealt with.

Continual Re-skilling

The rate at which required web-related skills change is extremely fast. In my experience with "old fashioned" software development there was a tendency for management to actually try to prevent its staff for from re-skilling (e.g. so that they would be available to work on COBOL projects, ADA projects, I've done them both). Now this would be an extremely dangerous thing to do - for both management and employees.

At the same time, the depth and variety of skills required means that it is very difficult for employees to acquire these skills "in their own time". One of the challenges of applying Lean to Web development is to figure out how to include continual improvement in the skills of the team into the web development process. It may be that this involves allowing some team members to work at less than full capacity (as the requirement for even flow through the process might dictate anyway) and expecting that the team members fill this time with re-skilling activities.

What is it?

One way of thinking about Taiichi Ohno - the inventor of the Toyota Production System - is that he was someone who really knew what a car factory was, what it was supposed to do, and how to make it do those things better. I'm not sure anybody knows what a web development team is (if there's only one kind of thing), what it's supposed to do, and how to make it better. I think this is really good news in some sense because people who can work this stuff out will be in a very competitive position - as are Toyota.

One of the areas we discussed here was that everybody I talked to in web development either doesn't know which bits make money, or knows that it is the bits other than bespoke web development.

Structure of "Building the Lean Web Development Team"

Session 1

Run through Lean Concepts

* Brief History of Lean and the Toyota Production System
* Value Streams, Waste and Flow
* How does Lean relate to web development

Session 2

Approaches to identifying the Value stream

Value stream mapping exercise

Session 3

Benefits of Flow

Flow and Kanban exercise

Mistake-Proofing and Poka Yoke

Session 4

What is it?

Open discussion

* Possible problems with adoption
* identification of next steps


For further information, contact mark.stringer@gmail.com (07736 807 604)