Lean conversation with @flowchainsensei (Bob Marshall)

This is an email conversation that I had with @flowchainsensei (Bob Marshall of http://www.fallingblossoms.com) Following his talk about Lean at Skills Matter on Tuesday night.

Hi Bob

Just a few thoughts on your talk on Tuesday night - I'll share these with you privately, but would actually like to post them (or some bits) as a blog post if you were OK with that.

Convincing people that you're an authority on the problem

I think you did this pretty well. Let me give you my paraphrasing of what the problem is and see if you agree with it. By removing wasted effort from a project, projects can be easily 2-3 times as productive, quite easily 5 times as productive, and possible 1000 times as productive. The bulk of project teams are manager to remove only about 20% of the waste.

Not too sure you've paraphrased what I was trying to say - although you may have paraphrased what I actually did say - or more importantly what you and some other folks heard at the time... :} For the avoidance of confusion though, please allow me to recap:

The problem (as I see it) is that people in tech businesses across the board, but particularly people in positions of "responsibility" don't realise just how much time, effort , money, human potential, etc. their businesses are wasting presently just doing "business as usual". This lack of realisation stems, at least in, part from a lack of awareness of just how much more effective some (few) organisations are than their business is.

So the typical (near-median) organisation is wasting around 80% of all the effort, etc. it's putting into developing software-intensive products and services. Every day.

Note in particular my focus on life (and effectiveness) at the organisational level, as compared to the project level - where most of the agile folks, including the industry's thought leaders, tend to dwell. Indeed it is my assertion that organisations cannot get past x3 on the Rightshifting scale by optimising at the local (project) level.

Convincing people that you're an authority on the solution

The result of this claim from the audience was "OK, who are these people. What are they doing that is so different?" I think here you were missing war stories. Don't you think, this is a substantial part of what people want to hear from a consultant? I think here, people would want to hear about super-performing teams, especially super-performing teams inside big organisations that didn't bring about their own destruction or removal. I think you could have "Landed the plane" if you could have had some good war stories about teams that were around 100% phase, you, or someone else suggested they do some stuff and then they moved to the 200% phase. then they got stuck, then some crisis happened and they realised that they could move to the %500 phase, and now they've all retired to the Maldives.

You're so right about the value of war stories and how these help people relate, engage. Unfortunately there just aren't many (any?) of these stories to be had. At least, I can't find them - not about highly effective organisations anyhow. One or two do spring to mind (Motek, GE Engines North Carolina) so I'll remember to mention these in future. And of course there's FlowChain - which is more a work of Science Fiction than fact at present, but hopefully a compelling story nonetheless. Hope to do a FlowChain session soon.

"The System"

If the system isn't the people, then what is it? You might have a very good answer to this, but I don't think you made this clear. I think you can image what this might be for a Ford-style production line, but in the TPS, surely the people and the knowledge and practices that they have are an integral part of "the" system. I think I read an article in the Economist which cited the lack of sufficiently-trained sensei as a reason why Toyota have stumble as they became world's biggest car producer.

Also, I can understand that there's a tier or management that needs to look at the organisation as a "system" and to some degree not think about the individuals and their talents - this wasn't your audience here. These were people inside the system.

I like to think I have a good answer to this. Thanks for point out my lack of clarity here. Ben and David Joyce have been talking about introducing folks to Deming's Red Bead experiment btw. And Martine Devos is looking for helpers to devise a Lean game to this end too. In the same way that a "team" is people, but more than just the people, for me a "system" of work is a similarly distinct thing.

And no coincidence that I'm FlowChainSensei :)

As for the demographic of the audience, yes my message has most value for executives, and they just don't go to these kind of events. I'm speaking at a Valtech event at the end of September where the the demographic might be more closely aligned. But I disagree fundamentally that people inside the system should not concern themselves with that system.

Books

You mentioned a lot of books. This is good for me because I read a lot of books, but many people who can read chose not to - especially, the kind of people who buy consultancy and attend talks and training. You can't answer their questions by pointing them to a book. I (ha ha) read somewhere that people divide into how, why, what and what if. I think there are readers in all those categories but readers tend towards the "why"/"what if" categories. I struggle especially with "how" people because the only way that you can get through to them is to actually physically get them to do it themselves. You can give them reasons until you're blue in the face.

I point people to books as a short-cut to me taking time to explain a certain topic, issue, subject or solution. Not that I resent the time necessary for effective explanation, (just the opposite, in fact) - it's just that in a time-limited session like Tuesday, I prefer to cover ground rather than dwell on one thing for too long. Agree with your observation about "how" people. Although I'd say that most people are "how" people to some extent.

I think if you want to reach everybody you need some kind of activities that let the "how" people feel what it's like to make processes more effective in a Lean way. "What" people are in some ways even more difficult, because they want to know exactly what they should do in their own situation. This is made even harder since I got the feeling that many people in the audience were middle-level people in big organisations. What's the one thing they can do to improve their team and make the organisation more Lean?

Agree with your point about activities. I like practical workshops with games, simulations, etc. Again a time thing (although maybe that's too glibly dismissive an answer? - for which I apologise). What's the one thing? In my opinion: Learn to see waste (or in TOC terms, learn to see bottlenecks). Hence one justification for the Rightshifting "campaign": To present people with the mere possibility that there could be much more waste in their organisations that they've heretofore realised / considered / conceived. Once someone accepts that this possibility exists, they may just be inclined to keep an eye out for waste.

If this is so great, why isn't everybody doing it?

I wasn't convinced by your explanations of why the hump is focussed around 20% efficiency. Is it really "inertia" or that "people are just stupid?" Do you really have to bomb a country flat and then get control of 90% of a country's capital in one room before you can make a change (as Deming supposedly did with Japan)?

Honestly, I just don't KNOW why organisations (and more relevantly, executives) are prepared to tolerate 80% waste (or more) in their organisation approach to software and tech product development. Other aspects of organisational ineffectiveness are less tolerated, I'd say. So why is the problem so acute in our "profession"? I have a coherent theory (see "Current Reality Tree" document http://www.fallingblossoms.com/opinion/content?id=1003 on my website), which involves a number of factors. And Rightshifting is my solution.

One way that I think about this is to think that however appallingly an organisation works, there is a sense in which it's "working perfectly" that is, it's in some form of equilibrium. Of course, one way to shift an equilibrium is to create a crisis, but another is to gently change a whole bunch of things until a new, higher stable state suddenly reveals itself - Jeff Sutherland talks about these "punctuated equilibria". Again, I think this might be rich territory for a set of "calls" to action for mid-level people. How can they move to make the ground more fertile for a shift towards being a Lean organisation. Otherwise, there's a danger that the message is "you can't get there from here."

Agreed. And the most common equilibrium state is generally round the 80% waste mark for tech businesses. :(

I many organisations I have seen, I truly believe that they "can't get there from here" - and their only future is to remain at their present level of equilibrium and hope that their left-drift remains slow enough that they can stay in business.

I think we have to accept that organisations generally have a (latent, hidden) reason for being, often far removed from their ostensible purpose of making a profit, or whatever. And often, that latent purpose is dysfunctional (from a societal point of view, not least). In people we call the resulting discomfort "cognitive dissonance". I'd go so far as to say that in organisations, the result of such dysfunction is ineffectiveness.

Regards,

Mark.

PS Lets meet up and chat soon.

Would love to! Just not this week - too much Python to do, deadline approaches! :)

For further information, contact Mark@agilelab.co.uk (07736 807 604)

Towards the Lean Web Development Team

I've been reading "Lean Thinking". and at the same time, I'm trying to figure out how to put together a highly-functioning web-development team - I think there might considerable demand for one if one existed. Also, because I'm a consultant, I'm trying to figure out how I could take an existing web team and make it more like a highly functioning web development team. I wouldn't claim to be au fait with all the Lean terms, and as I've mentioned previously I still have some questions and doubts. So this is my first stab at this - any Lean gurus, please feel free to comment or correct.


I'm going to run a workshop in Bristol to investigate these ideas further. Because, obviously, these ideas are very much still in Beta, I'll run it at cost (about 50 pounds per seat). Let me know if you're interested in attending.

Lean Concept: Value Streams

The software is only one part of a website. Design, Marketing and PR integration. While there is almost always some custom software that needs to be written in a website of any complexity at all, the aim of the website is normally some kind of "human" goal, either a marketing goal, or a humanitarian goal. All sorts of value gets added to a website at many different points in its lifespan. A lot of this value is added after the website goes live and in an ongoing process.

Lean Concept: Multi-skilling, cross functional teams

It's not your skills. It's not your talent. It's the way you fell out of the Victorian hopper. The education system is still generating tradesmen who describe themselves as developers or designers or testers or project managers or salesmen (people from design agency backgrounds have a different set of titles).

Lean concept (my words, my gloss): Big pipes

Another thing that Toyota do is have high bandwidth communication with their customers (through a programme of visiting salesmen that encourages

Your first (last and only?) job is talking to your customers. How are you communicating with your customers? What aspects of that communication are valuable? How can they be increased? What aspects of communication with your customers is NOT valuable? How can that be decreased?

Your first (last and only?) job is talking to each other. If you can figure out how to communicate with each other and improve each other's skills and add value to each other's work you'll be in great demand.

How fat is your pipe? What's the fattest pipe you could give to your customer? What would the customer actually want i.e. to keep changing the design, to be able to add and remove complex features at the very last minute? Is it possible? Would your team have to work evenings, weekends, shifts? Could you organise yourselves to do that? How would you charge for it? How would you explain these charges to your customers?

Lean Concept: What is it?

One way of thinking about Taiichi Ohno, the guru behind the Toyota Production method is that he is the man who had the best understanding ever of what a factory is and what it produced.

What is your organisation? Think of some more metaphors? Hunting party? platoon? String quartet? Dance troupe? What are you making? Cakes? Cuckoo clocks? Spaceships? Fanzines? Architecture? You've got a metaphor. A model for what kind of organisation you work in, you've got a metaphor, a model for what it is you make. Are they the right ones?

Use the metaphor of an engine. What do the dashboard instruments measure? What are the dipsticks? What is visible? What should be visible? How does everybody in the team know how they're doing? How does the customer know how you're doing?

Lean Concept: Kanban, simple visual workflow ordering

Does it make sense to pull work through your organisation at the rate that it can be delivered at rather than pushing it through at the rate you win it? What things that weren't "wasteful" could your programmers and designers be doing while they were waiting for work?

Lean Concept: Waste - identifying it get rid of it

Where are you wasting your time? Overworking? Arguing? Using the wrong tools?

For further information, contact Mark@agilelab.co.uk (07736 807 604)

Of Pigs and Chickens and Groups and Teams

Pigs and Chickens

One of the things that I talk about in my Introduction to Agile Methods course is the importance for the project manager of identifying the pigs and chickens in your meetings. The idea is that you tell the difference between a pig and a chicken the way that you tell them apart in an English breakfast: :the pig has got it's bacon on the line - the chicken is just involved.There are lot of reasons why people who don't directly have their "bacon" on the line might want to get involved in your project and turn up to some of your meetings. Here are some that I can think of.

1. They've heard your project is really cool and so they want to be associated with it.
2. They've heard your project is really cool and so they want to stop it.
3. They've heard your project is really cool - so they want to steal your people, or the project.
4. They're worried that the project is going badly, and they think they can save it by having lots of senior people who aren't quite sure what the project is about turning up to meetings.
5. They want to show how important they are by derailing your project.
6. They want to know what's going on.

Reasons 1-5 need to be stopped by the project manager. Reason 6, might, sometimes be OK, but probably won't be, because, although idea is that senior people can drop into meetings to "Just Observe" the truth of that matter is the people are going to end up seeking their opinion on what font the submit button should be in, or they're going to blurt out their opinion and that's going to be that - until the next meeting which consist of only committed team members, which will probably decide that Century Gothic isn't the best font after all.

Project delivery - not a vegetarian affair.

Groups and teams

As if that weren't bad enough, there's the difference between groups and teams. Now I think about it, it seems obvious, but it was drawn to my attention by Dave Dawes. Any bunch of people (including an collection or pigs and chickens) can be a group. But in order to be a team a group has to go through a bunch of messy and - seemingly unproductive - processes. Bruce Tuckman refers to these stages as "forming", "storming" and "norming". After which follows, finally, "performing". A team also needs a permanence to its membership and a common goal which a group doesn't necessarily have. If your meetings are chicken-infested, there's a very good chance that they are getting in the way of the important forming, norming and storming tasks that the team has to do before it gets round to any performing. If you're the project manager, and you don't make it your job to ensure that meetings are filled with pigs that are turning from group into a team, you shouldn't be surprised if they don't perform at all.For further information, contact Mark@agilelab.co.uk (07736 807 604)

Why Agile Methods are Tip Top and EVERYONE should give learning them a go

This my 100 word entry for the School of Everything Paragraphs Mean Prizes competition:

I teach Agile methods. Agile is a set of project management methods that can deal with constant change. Everything changes. The people you work with change. The aims of the project change. The economic climate changes. Most important, our understanding of what we're trying achieve changes as we're achieving it. Agile provides a clear robust mechanism for dealing with this kind of radical change and for continuously assessing and improving performance. Agile is well-suited to complex fluid tasks like software development and website production but also useful to just about anybody who works in a world where things change.


For further information, contact Mark@agilelab.co.uk (07736 807 604)