On Stupidity (and Web Development Project Management)

I was thinking about stupidity. What is stupidity? One way of looking at it is that it's when a model is being over-used, despite lots of evidence that the model might be inadequate to the task.

Here's an example. Say you arrived in France the first time – perhaps out of the channel tunnel and for some reason no one in your whole life had mentioned to you that they drive on the right-hand side of the road. You might be fine driving on the left-hand side of the road – for a while. When you meet the first car coming toward you on the "wrong" side of the road you might think "What an idiot!" But by the time you get to the third or fourth avoidance of a head-on collision, if you've survived that long, you might be ready to question your model of what's going on. If you weren't, then I think it would be perfectly OK to say that YOU were really stupid.

Stupid huh? Who lives for free with all the Whiskas they can eat? (photo courtesy Barbour)

This is very relevant to web development, since so many of my clients, who develop websites for a living, are so anxious to tell me that their clients are really stupid. Just stop for a minute and ask yourself.

"Who's really stupid here?"

Really? If you've had the equivalent of five or six, or twenty or thirty "head-on" collisions with clients, who is it who needs to change their model?

Building the Lean Web Development Team, helps you look at managing web development in a totally different way. Book now for the course on 20th January 2010.

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

5 things to do to improve the management of your web development projects

Here are 5 things to do to improve the management of your web development project.  They all point to articles in this blog that go into each point in more depth.  Enjoy.

First, don't catch your lemon: 

don't take on projects that you already know won't make money.

Difficult, difficult, lemon difficult (picture courtesy of wikimedia commons)

Understand the importance of flow:

if you're going to count anything, count how long it takes for a project to get from start to finish.

Know your onions (and clients):

  find out as much as you can about your client before you even start work.

Control your client using creativity: 

stop moaning about your client and try to come up with new ways of dealing with the problems that he/she gives you.

Get control of the ″wildcards″:

understand the three main causes of delay in web projects that are outside your control - and how to deal with them.

Sign up for my course "Building the Lean Web Devlepment Team":

  (I know, I know, this is six)

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

Getting the right project management method for Web Development

Many web development companies would accept that their approach to managing projects could be improved. But the project management methodologies that are out there don't seem to fit well with the real experience of delivering web development projects:

PRINCE2 (initially designed for large government IT projects) seems to focus almost entirely on the production of documentation and seems to have almost nothing to say about getting things done.

Agile methods (initially designed for large corporate IT projects) have a much better focus on getting software written, but seem to have very little to say about the integrative nature of web development.

My own solution, based many experiences of helping web development companies is to derive inspiration from Lean. Lean is the name given to a set of project management principles derived from the hugely successful way that the Toyota Motor company produce cars. Car manufacture might seem like an initially unpromising place to look for ideas on how to run a web development company, but concentrating on the principles of the Toyota Production System, Value, Flow, Poke Yoke (mistake proofing) and What is it? rather than the practices, produces a powerful set of approaches for substantially improving the effectiveness of a web development team.

Find out more about my course, and book a place here: "Building the Lean Web Development Team".


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

Brownout on Agile Boulevard

Watching the tweets from #xpdays leads me to think that there is strong and growing interest in Agile and Lean Methods. I think this is a good thing.

But there is a problem, and the problem is confusion. There are a lot of supposedly ″different″ Lean and Agile methods and each one comes with an army Lean and Agile Coaches, Consultants and Trainers, all claiming that their method and their method only is the best.

The result of this confusion seems to be what I have called ″Agile Brownout″.

″Brownout″ is a term that used in countries where the electricity supply is less than perfect. A brownout isn't a black out. All the lights don't go off. But because too many outlets are drawing from the same source, all the lights go yellow and dim. And in the Lean/Agile field it seems that now there are more lights drawing on the grid than at Blackpool 'luminations. Scrum/XP/Lean/Kanban/TDD/BDD to name just a few.

The solution to this problem for many consultants seems to be to shout very loudly and insist that all the other lights should be switched off. Theirs is the one true light and it can only made to shine by extinguishing the others. My solution is a little different. To struggle on with the metaphor, my solution is to point out that:

depending what it is you want to see, you probably want to use a different light.

To my mind, each of the delineated Lean/Agile methods tends to have a niche where it works best. But for any kind of project, there's probably a bit of each that could be useful. Really, if you're a project manager, you owe it to yourself to check out what each of the methods offers. Since my specialist focus area is on tiny-to-small-to-medium sized web development teams, I'm just going to run over what I think are the good bits from a range of approaches.

PRINCE2

This is the language big organizations speak. You have to write the kind of documents that PRINCE2 recommends if you're ever going to have a chance of pulling down any big money for a project. And as a means of reporting progress on a project back to a big organization. But that doesn't mean you have to use this method to manage development for that, you should use scrum.

Scrum

Daily stand-up meetings, regular sprint planning, demonstrations and retrospectives are all good ways of managing actual development and tracking its progress. Extracting stories into a prioritized, effort-estimated backlog is enormously valuable by itself, if you institute no other Agile practice. Even if a team is working on multiple projects (as web development teams often are) the relief of stress and increase of focus that instituting this kind of basic management can produce is still powerful and heartening (and surprising).

XP (Extreme Programming)

Practices that are often labeled as Extreme Programming, such as TDD, Continuous Integration and Re-factoring are very useful if the software component of the web dev that you're doing is of any reasonable size or complexity. The thing to remember here is that any test coverage is better than none. And the emphasis on delivering working software at the end of iteration? That's gold.

Lean

For me, with Lean, it's the ideas and the huge benefits of an alternative view of what we're trying to do. Seeing web development as a value stream makes you focus on the value that you're delivering to your customer. This makes you look at the things you're doing day-to-day in a very different light. Focus on flow makes delivering (working? Right?) websites to the customer as soon as is absolutely possible a top priority and this in turn highlights obstacles. Remove those obstacles and you're in the money.

Kanban

Before you do anything else, limit the work in progress. I was especially impressed by David Anderson's point that you don't have to persuade anybody about the benefits of Agile methodologies to just start reducing the work in progress and seeing the benefits of that single move. Using a simple physical display to show everybody (including yourselves) what you're working on and limit the number of things that you're working on is almost equally simple and powerful.

John Seddon

This isn't a method, it's a person. It's worth reading his book if only to be introduced to the concepts of value demand and failure demand (slaps forehead). Why didn't I think of that? Seddon says you should try to solve the problems presented by the work and so, unless you're trying to make cars in Japan at the rate of demand, you're probably going to be solving a set of problems not directly addressed by the Toyota Production System.

I cover all of these approaches on my upcoming course ″Building the Lean Web Development Team″, running in central London on 20th January 2010.

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)

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)

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)

Very Pleased (Again)

Just finished the sprint planning and review meeting. It was another blinder. We identified more problems and R [project manager] came up with a really good idea to solve one of them.

All's good... your help has been really fantastic in improving our team's process, reducing stress and making visible where we're losing profit and morale so we can improve even more in the future.

Rachel Collinson - from http://www.rechord.com/


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

Notes on Value from worskhop 14/10/09 - Building the Lean Web Development Team

Notes from my Beta Workshop - "Building the Lean Web Development Team".

We talked about four general areas on Wednesday:

• Values
• Flow
• What is it?
• Poke Yoka

Values

When we talked about Values we said that one of the important aspects of the Toyota Production System.

The Toyota Production System insists on seeing the world of business as a value-stream. Each activity in the value stream either adds value, or it doesn't. If it doesn't, it is a candidate for removal and reduction. The way to identify these candidates is to create a value stream map of your organisation (this is very similar to a "Brown Paper Exercise" done by many management consultants). We did this in the class and this is what we came up with:

We then highlighted the areas that we thought were adding value in the process [in red]. Then we highlighted the areas that we didn't think added value to the process. Quite a few of these were activities to do with planning and assessing the work that came in. The very radical idea occurred to us - "What if we didn't do those bits?" What if we just "Exposed our development capacity" to our clients - this brings in some of the Kanban thinking - "here are the slots, it's obvious when we're available and when we aren't." How do we figure out whether we can do a piece of work or not? By trying to do it.

When you look at things in this way, planning and estimation look really pointless. If your capacity is really obvious, then the option of figuring out how long something will take by trying it presents itself.

What are our values? I used an activity that I'd learned from reading "Sources of Power" by Gary Klein to come up with a bunch of values for the group. We wrote these on a set of index cards.

Web Developers' Values

• Software engineering best practice
• Customizable
• We're a learning company
• New People
• Good solutions in non-perfect situations
• Dealt with unexpected problems
• Customer delighted
• Generic
  
• Flexible Code
• Speed
• Setting an example to other developers
• Adding structure
• Product
• New challenge
• Taking a risk

We then asked if these were the values of our customers, or our suppliers?

Customer's Values

We thought our customer's values were probably very different - this is the list that we came up with:

• Easy Life
• Shiny Fun Web
• Rounded Corners
• Blue
• Verdana
• On-Time
• To-Budget
• Free Food
• Good Coffee
• Regular Updates
• Non-Threatening
• Lack of Jargon
• Learning Jargon to impress Boss

Who are your suppliers?

I'd talked to some of the people who turned up at the course - a woman who owned her own web development business and she'd told me with a shrug that she didn't really have any suppliers. After thinking about it for a while, I realised that this was very wrong. One of the things that Toyota does that makes it very different from other companies is that it has very involved, very long-term relationships with its suppliers. Here are some suppliers that you have that you might not have thought of:

• Universities (supply you with staff). Universities supply you with staff. Are the universities teaching their students the kind of things that you need them to know? Are the universities picking the right kind of people to come on their courses - are they a good "fit" with the organisation. We talked about the value of having interns - I asked if anybody had ever had interns and there was a general agreement that when they do have interns, they're given "grunt work" rather than anything that might allow them to learn, or show off their abilities.
• Other Web development companies (supply you with staff). People come to you from these companies - the better you know them, the better chance you have of good people coming to you from them.
• Software manufacturers (Apple, Microsoft and Adobe)
• Hosting. I hear lots, I mean LOTS of stories about last minute changes to hosting requirements that come from a client and derail a project. Do you have a really good relationship with your hosting supplier? Alternatively, are you permanently chasing problems with a very cheap hosting supplier?
• Me, and people like me (I supply you with training and consultancy). How do you make sure that I know enough about your company to do my job properly. What sort of experience and abilities do you need in a consultant?

Value Dynamics

What are you supplier's values? How do they change throughout a project? This seems to be a crucial part of the business of web development in a way that it isn't in other industries such as car manufacture where buying the product is a quick process rather than the long, drawn out process that it can be with web development. I think a lot more work needs to be done on this, but for now, what we came up with was as follows:

Beginning of a project: What's important to customers at the beginning of a project is price and feature list, and impressive pitches.

Middle of a project: What's important to customers in the middle of a project is understanding the trade-off between features and price (although this sounds like a web developer-view to me).

End of a project: At the end of a project there are a whole different bunch of things that are now on the client's mind. Now they need to be able to show some working software to their bosses, and also, possibly some return on investment (ROI). We all agreed that if there is working software that is generating value, then the budget is much less of an issue.

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

Do you speak organisation?

Having gone to Andy Murray's Prince2 refresh talk at the BCS, I'm starting to think that the issue between Prince2 and Agile might be slightly more subtle than I thought. Prince2 is a method of talking to organisations.  Agile is a set of methods for delivery, especially for software.  Both methods claim to be able to do the job of the other.  Both are bluffing.

Yeah right, I know, Scrum of Scrums.

Also, as far as I can see (my knowledge of Prince2 is very sketchy) there's nothing in the method to say how you actually get the work done, so what's to stop prioritised lists, Kanban-style displays of work in progress and strict limits to how much of that work is in progress?  I think this is what the guys at e2x were trying to tell me last time I talked to them, but I wasn't ready to get it.

Maybe Prince2 is a bit like Old Entish. Maybe arguments between Agilistas and the gentlemen of Prince2 is a bit like the battle between materialists and idealists in philosophy of mind.


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

Free (and Nearly Free) Stuff!

Agile Lab is giving away free stuff.

Here's the situation.  The more that I've read about Lean, Kanban and Taiichi Ohno and the Toyota Production System, the more convinced I've become that there's a way of using these ideas to create a web development agency that would be massively more efficient and productive than most of the ones that I've seen, even ones that have adopted Agile methods as fully as they possibly can.

But my ideas aren't properly developed yet.  I'm reading everything I can about Lean and Kanban.  I'm talking to people who are doing this stuff inside their organisations. I'm listening carefully to the war stories of others who are trying to introduce Lean ideas.  Trouble is, experiences of Lean inside a web development agency are few and far between.  Most case studies seem to come exclusively from large organisations who are developing large stand-alone software projects albeit with some kind of web front-end.  Nobody seems to have done this yet with a 'typical' web development agency that builds lots of web sites that don't just involve software, but also combine design, marketing and PR.  This seems to me a great pity, because I think this might just be where Lean ideas could be most powerfully effective.

Over the two years that Agile Lab has been running, its area of expertise and focus has been on web development agencies.  I want to work with them to understand how Lean ideas can be made to work in a small web development agency that typically has several small projects on the go and short turn-around times.

I don't think anybody has successfully applied Lean, Kanban and other Toyota Production System methods to this kind of web development.

I want to be one of the first, and I want to get there in the most professional way possible.  For me, that means without using paying customers as guinea pigs. In order to do that, I'm prepared to give away considerable chunks of

FREE

yes, that's

FREE

consultancy, to any web development company that's prepared to come with me on this journey and allow me to use details of the experience as case study material.

What's in it for you?  You get to explore the way your company works.  You get the benefits that come with bringing in an outside consultant: someone who helps you step back from your day-to-day concerns and works with you to make your company the best it can be. You also get to experiment with the ideas that made Toyota the worlds biggest and most successful car company. Ideas that hold out the possibility of allowing you to "perfect" web development in the way they other companies like Porsche have used Lean to perfect car manufacture.

Oh - did I mention the course!  Gah! I can't believe I forgot about the course!  On the 14th October 2009 at the Watershed in Bristol I'll be running a workshop course on:

Lean Approaches to agency Web Development

The idea is that I talk through the basics concepts of a Lean approach: why anybody who does web development should take any notice of a car company? Then we'll do a bunch of workshop activities to explore these ideas, this will almost certainly include a value stream mapping exercise and an exercise to demonstrate the importance of even, continuous flow. Maybe some other stuff- not sure yet.

This course isn't FREE - but it is available to you for the stunning bargain price of £50 which will just about cover my expenses and make sure people turn up.

Contact me now if you're interested in signing up.

Especially if you bring along several members of your team

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

Testing Times for Testing

Went to the Extreme Tuesday Club (XTC) last night. Talked to a couple of guys from the Big Media Company and then to a couple of guys from uSwitch.com. There was also a bloke from an investment bank (Josh, not his real name).

The bottleneck was the QA guy

Curiously, all the conversations - I don't know whether there had been a talk about it or something before I arrived - were about testing. The Big Media Company guys were doing Kanban and Kanban had shown them that the bottleneck was "the QA guy". And they were wondering how to get round this. The guys from uSwitch.com had taken what sounds like a really radical decision and just got rid of their dedicated testers. But they said that the result was that the developers took responsibility for the code. Of course, you can only really do this if you've got TDD (they were calling it BDD) in place. You write your automated acceptance tests with the business people and then you code until the tests past - a common theme from both the uSwitch.com and Big Media Company guys was that you release stuff when it's ready, you don't wait for the end of and iteration.

Testers focus on finding bugs without regard to value

Why did uSwitch.com get rid of their testers? Well, the testers weren't really on board with Agile, and one thing you have to careful of is anti-Agile diehards who bring progress to a halt, but the testers were also focussing on bugs without regard to value. The developers at uSwitch.com keep an eye on the error logs from the live site and they keep an eye on the conversion rate - how many people who visit the site actually make a purchase. If something causes the error logs to spike, or the conversion rate to drop, they're on it. The focus is on delivering value to the site. Another knock-on effect of not having any testers is that the business people, the product owners, have to "be their own domain experts". Again, another theme that emerged from last nights discussions is that there is a temptation to leave final responsibility for the product with the testers. Testers can be expected to have a detailed knowledge of how the system should work, but they're unlikely to have a detailed understanding of which bits of the system are of value to the business.

Offshore testers, are "paid by the bug"

Josh worked for a merchant bank that was still clinging to traditional waterfall models of development. He'd had some success on a few projects in introducing some Agile practices, but again, testing was a problem. In order to make sure that everything worked as it was specified, testing was done offshore and the offshore testing company were pretty much paid to find bugs. It would be very hard to expect this company to know, or to care about the business objectives of the company. So the list of bugs that was sent back by this offshore company had no prioritisation in terms of business value.

Josh also raised the problem of time with the traders being very valuable, that all the time that a trader was talking to them, he was losing money. We talked about whether the amount of time the trader spent on the software was going to be the same in an Agile project and in a conventional waterfall project. The guy from uSwitch.com told a story about some work he'd done at a previous company, where he'd traded in his desktop machine for a laptop and just gone and sat with the guys who needed the software. He'd watch what they were doing and occasionally ask them questions, he'd also get to show them the software he was writing as he was writing it.

Quick - we need a crisis!

We talked about there being no way of persuading people to go for this without actually giving them the experience of doing it. You could try to explain the benefits of an Agile/Lean approach until you were blue in the face, and it probably still would do any difference. One thing that we thought might make even a merchant bank take such an approach was if it was seen and understood that their competitors were doing something similar. We agreed that very few people take such radical approaches when they're already making money. Even the Japanese (and then only some Japanese) only tried these methods when their country had been defeated in a war and economically ruined. We discussed some ways of artificially creating these crises. The second time I'd had this discussion in a week.

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

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)

Trying to Understand Kanban in Software

I was very interested to hear Karl Scotland's talk yesterday at Minispa2009 about Kanban. I think he's a addressing some very important issues, but as I've said on Twitter, I wasn't quite convinced by his talk. I think he's nearly there and can't quite make out whether the problems are in my understanding; his communication; or in the actual ideas themselves. Anyway, here are some notes on things that I think at the moment are an issue.

Software components aren't car parts

One of the way I try to explain stories when I'm doing agile training or consultancy is that stories are stories. A story is an out-of the ordinary situation which needs resolution. It's news. Software development spends most of it's time dealing with "Man Bites Dog" cases because "Dog Bites Man" cases are already catered for in the language libraries and the API. Software people, project managers and the people who support them with training and consultancy are all what Peter Drucker called "Knowledge workers". Ironically, that means we spend most of the time NOT knowing what we're doing. I'm not sure how well this fits with manufacturing car parts, or assembling cars.

Toyota Production System is a "That would never work for us" method

Anybody who has ever tried to advocate any kind of project management method to someone in an organisation will be familiar with the "That would never work here, that would never work for us," response. What isn't perhaps discussed so much is that exactly that attitude is the root of the Toyota Production System from which Lean and Kanban ideas are extracted.

As I understand it from my reading of Taiichi Ohno's book and from reading "The Machine that changed the world." One of the original spurs for the Toyota Production Method was an understanding that the way that Ford made cars wouldn't work in Japan. They simply couldn't make enough cars to get the economies of scale that Ford (claimed) he was getting. Another realisation was that Japan's demand for manufactured goods was extremely cyclical and so Toyota needed a method that could "smooth" out these oscillations in demand. But Ford's model of hiring and firing low-skilled workers as the need arose simply didn't fit with Japan's cultural understanding of what work was. People worked for the same firm and stayed loyal to it all their lives. Enormous value was placed in the deep knowledge and mastery of skills. Toyota decided to put together a system valued skilled workers and held onto them through all stages of the economic cycle.

This is what I don't see in Lean and Kanban approaches to software. It doesn't say "We need to design our own Toyota Production System that reflects our culture, values and economic cycles," rather it says "we need to use theirs!".

Flow vs frame. How do you know what you're capable of?

This maybe not so much an objection as a lack of understanding. I didn't quite understand what Karl meant by the term "cadence". It seemed to be something like an iteration, but of variable length. I sat up and paid very close attention at this because one of the things that you're always asked when consulting and training about Agile methods is "How long should iterations be?" And so some kind of rule - even a rule of thumb for working this out would be interesting to know about. But at the same time I'm worried that giving up on the idea of fixed-length iterations, results in the loss of information about velocity. And one of the things that I think is vitality important about Agile methods is the ability to get better and better understandings of what you're capable of as a team.

Another way of thinking of iterations is a frame that you put around the work that would be getting done anyway that allows everybody (developers, project manager, clients) to talk about it in an different way, to reflect on progress, to decided on changes of emphasis and direction.

The aim of these comments and objections isn't to dismiss Kaban/Lean approaches because I think they would be particularly well-suited to settings such as web development agencies, where the work tends to turn up in a continuous flow and doesn't necessarily fit itself into time-boxed. Iterations.

Thanks to Karl for an interesting talk.

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

Timing and Music - The Tunnel and the Timeline

Following on from my posting last week about different ways of seeing time - it occurred to me that these two ways of seeing music are in fact different ways of seeing time. Why did the designers of "Guitar Hero" choose a tunnel view of music rather than a time line view?

Is it because a lot of people find it much easier to deal with than a time line view? Why didn't they extend it to 8 notes? Does it break down and get too complicated? This is the way you store music, for example on a pianola.

Guitar Hero - Tunnel Vision? The notes you have to play flow towards you

Why is conventional music notation stored on a timeline? What are the benefits?

Manuscript Music. Remind anyone of a Gant chart? OK, a very, very busy one.

Coming back to Agile, is Agile a method of taking a tunnel view on a time line? Hmmph. Dunno, and that's all I've got time for today. Still think good project management is about knowing when to use which view and how to switch between the two.

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

Trade-offs

A really good way of improving the exchange of information between clients and suppliers is to try to get them to tell each other about trade-offs. Every business has them.

When you're buying a car or a coat - do you buy the cheapest? Thought not. So what's wrong with the cheapest car? What's wrong with the cheapest coat? OK let's make a list: horsepower, features, handling, quality, style, having to wrestle someone for it in Primark.


Primark - Pile it high... (pic courtesty of adotjdotsmith)

Do you buy the absolutely best quality? No. The most possible horsepower no. Do you by any chance instinctively understand that when it comes to cars or clothes there are whole bunch of trade-offs? You can have cheap, but it won't be fancy. The faster it goes, the less likely it is that you can get a baby seat in it (or get baby vomit out out of the carpet). You can have top-quality cashmere haut-couture but it won't be cheap and you probably won't want to wear it when you go to the gym. You can have cheap, but don't expect it to fit.

Get the idea? It isn't just one trade off, there are lots. You don't really understand anything, until you understand the tradeoffs. And it's more complicated that that. In software development they're very often three way rather than two-way trade-offs.

I took part in a panel discussion where one of the other members - Chris Heilmann - said that whenever he starts talking to clients about writing software, he draws three circles and labels them "Cheap", "Fast" and "Good". Then he tells his clients that they can have any two - that's at least a start at getting his clients to understand that there are trade-offs.


Expensive? Yes. Stylish? Yes - but maybe not the right thing for the beach...(pic courtesy of Tammy Manet)

When we first started doing Agile training, we had great difficulty explaining the difference between the Agile concept of stories and terms used in other design methodologies such as "Use cases". Things got much easier when we started to talk about stories as "negotiations" (or trade-offs) between scope, priority and effort. Stories are dynamic. Each story is an exploration of a possible trade-off. When you start to think about things like this, you begin to realise what an improvished, static and inadequate thing a specification is.

For more about trade-offs, read from Gerald M. Weinberg - Secrets of Consulting.


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

This is just a list - but a very good one

Just sent this list of references out in an email to my students on the Managing Digital Projects course. I think it's a good list, so I'll share it here as well.

Difficult Conversations - http://bit.ly/17jqqB
Getting to Yes - http://bit.ly/8DBgb
Sources of Power - http://bit.ly/LcK9H
The Web 2.0 Paper by Tim O’Reilly - http://bit.ly/ICDiz
The sceptical Facebook article - http://bit.ly/2088J
Extreme Programming - http://bit.ly/H0JV1
Scrum and XP from the Trenches - http://bit.ly/20k7hl
The Strength of Weak Ties by Mark Granovetter - http://bit.ly/wGxX

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

What's in a name?

[Sitting is Starbucks in Leeds - up here to run an Introduction to Agile Course]

Is your company Agile? Yes, I thought it would be. I don't think I've talked to anyone who didn't claim that their company was. Of course, further questioning would often reveal that they weren't actually doing fixed-length iterative development, weren't actually planning in terms of stories or any of the other things in the Nokia test. It took me a long time to realise why I wasn't getting an honest answer: no one is ever going to say that they're not agile. How likely is this?

Q: Is your company Agile?
A: No, not us, we're lethargic and arthritic.

The word "agile" perhaps betrays the movements American roots. It has lots of positive connotations: energy, intelligence, responsiveness. But (perhaps this betrays my British roots) this means that admitting you're not agile has all the opposite connotations: lethargy, stupidity, unresponsiveness. Nobody's going to admit to that - even if it's actually how they feel. And lets be honest, we all feel like that some of the time.

Trying to make people feel bad about themselves before you try to sell them something guaranteed to make them feel good is a standard sales technique. Whether you're selling soap powder of salvation it can be very effective.

We believe that (almost) all our potential customers are very clever people. They are doing a pretty good job with the tools that they have at their disposal. They don't need salvation - they need some new techniques. What we try to do is give them better tools, not software tools, not technological tools, but conceptual tools that allow them to do a better job.

Best feet forward?

Please don't anyone take this as advice of road safety. It's just an exercise.

Push your chair back from the computer. Just relax. Imagine that you're driving along in your car down a very familiar stretch of road. A journey that you've done lots and lots of times. Yes, that's it, mime holding the steering wheel. You can't close your eyes, because then you won't be able to read this, but in your mind's eye, imagine what you can see. Familiar roads, familiar corners, and junctions. Then suddenly, something jumps out in front of you. It's a toddler, chasing a ball. Stop! Stop! You have to STOP!

If you're used to driving a manual transmission car you probably wanted to stamp both feet straight out in front of you. One on the brake. One on the clutch. When we want to stop a car in a hurry that's our instinctive reaction. We tend not to think about it, there isn't time. But is it the best?

If the road conditions are good, it's probably the best, most effective strategy, but what if the road conditions aren't good? What if it's raining? What if it's snowing what if there's an inch of ice on the road? If the road's slippery, it's best to pump the brakes. But what do you do if you thump both feet to the floor and you start to skid? Apparently, you're supposed to turn into the skid to regain control even though this feels like exactly the wrong thing to do. People can learn to drive in wet and icy conditions, they can learn to resist their first instincts, pump the brakes and turn into the skids but it takes time and practice, rarely do people spontaneously do the right thing.

Someone was asking me yesterday why so many projects use a waterfall approach rather than an agile one. I think it's for similar reasons. In industrial societies waterfall methods are deep down in our brains. We just assume that the way that anything complicated gets done is by putting together a long, complicate plan and then trying to deliver on it. No matter how many times the result of this is the project management equivalent of skidding into a ditch, because this is our hard-wired, instinctive approach, we carry on doing it.

Agile is the project management equivalent of pumping the brakes and steering into the skids.

Baby Steps: Agile and the Small Creative Business

The founding idea of Agile Lab was to take innovative thinking from Agile methods such as XP and Scrum and introduce them to a wider constituency.

We worked together with an organisation called Creative Northants to understand the issues facing five small creative businesses in Northamptonshire. None of these businesses had any connection with software development or computing. We visited each business at their premises and interviewed them about the challenges that they faced as creative businesses in Northamptonshire. The resulting report was described by our client Will Pearson at Creative Northants as "excellent" and "very helpful".

We identified three areas in which these small creative businesses were having difficulty: business networking, marketing and knowledge of IT. We are obviously not the first to identify this kind of problem, especially with regard to marketing. A great deal of arts funding seems to require the businesses to produce a "business plan". Several of our interviews had been required to produce such plans to get government funding. None of them had delivered on these plans. In one case we heard of a major arts organisation that had been required to produce a detailed business plan in order to get funding, but had then not taken any steps to execute the plan for over two years (and counting).

At Agile Lab we felt that there were ways of helping these organisations without the need for a detailed long-term plan. Using the extreme programming principle of "start from where you are" and "you can always do something" we ran a workshop for our five interviewees. For each category of business networking, marketing and IT knowledge we asked them to write a short statement of something that they would like to do in that area - in Agile we call these statements "stories". We then asked them to write a "test" - how they would know when they had done that thing. This is something that is very different from a test for a piece of software. A piece of software either works or it doesn't, a conversation at a networking event make take years to pay off. We also asked them to estimate how much effort each task would take. Then (if you know anything about Agile, this won't be a surprise) we asked our workshop participants to prioritise their stories and come up with a set of stories that they feel they could deliver on in a period of three months.

Three months later we ran another workshop. In one-on-one interviews we carried out a retrospective on the iterations that our interviewees had put together. We were pleased to see that each of our participants had made progress in line with the iterations that they'd outlined. Each of our participants had done some marketing and some networking. Using the Agile concepts of story writing, prioritisation and iteration planning we managed to break an intimidating task that was at risk of not being done at all into manageable pieces.

Pitcher's Poker - Part 4: The Other Side of The Table.

How does all this look from the side of the customer?

Well, I'm the customer. We looked at 6 pitches. Surprise, surprise, they all looked great. Music, visuals, promises, promises. But unfortunately, I've been here before, I've seen fabulous pitches in the past and selected the company with the most fabulous pitch. That project cost us a lot of money – twice what we budgeted for it. In the end it got canned. We don't talk to that company any more. In my head, now, when I think of the budget for some new web project, I'm thinking – yes, but that's actually going to cost three times that isn't it?

So this guy turns up. He doesn't have a laptop. He doesn't have a pen drive. He doesn't have a presentation! He has a flip chart and a marker pen.
“In one sentence, what is it you want?” He says. There's four of us watching the presentation. It doesn't make me comfortable that we all say four different things. He writes them all down.
Now things get really weird.
“Who's the pig?” he says.
“We beg your pardon” we say.
He explains the difference between pigs and chickens. It's like bacon and eggs. The pig is committed, the chicken is only involved.
“Who's the pig?” He says again. Who's bacon is on the line? My boss starts preening himself. But the finance director and the HR director point at me. My boss doesn't say anything. They're right. It's me.
He makes me put stars next to the four things on the flow chart. Then he draws a ring around the two with the most stars.
“Give us X amount of money and we'll demo something that does these two things by the end of next week,” he says.

Then he picks up his flow chart and leaves.

Read a Book

I've just read the excellent "Top 10 Team Practices" post in the Leading Answers blog.

I am a bit worried about leaders who "do not get the time they want or need to read about these topics." What are they doing? Do they really not have three or four hours and a few pounds (or dollars) to step back from what they're doing and get a different perspective? The best you can hope for is that they're too busy taking Agile leadership courses ;-)

Buildling Agile Relationships with Suppliers: A Lesson from Toyota

Toyota didn't start making cars until the 1930's. Now they're the biggest car company in the world.

I just recently read a Boston Consulting Group white paper about the way that Toyota treats its suppliers which I think is really interesting. It's not easy to become a Toyota supplier. They have very exacting standards and expect to be given very deep access to the inner workings of any company that wants to become a supplier. Toyota's goal is to avoid "information hiding" allowing information that is useful to Toyota to flow from the supplier and vice versa. Once a company is a Toyota supplier Toyota work very hard on two things. They work very hard to improve the design and production of whatever components a supplier makes for them. As a result of this, they also seek to share the benefits of these productivity increases between Toyota and the supplier and maintain the suppliers profitability.

The relationships between customers and suppliers, especially for IT services is often very fraught. It's quite usual for "information hiding" to be built into the way that work is bid for and commissioned. A client asks suppliers to pitch for a piece of work and very often, price is used as the sole piece of information on which to make a decision. It's easy for the seeds of future disaster to be sown at this point. The client has just commissioned a piece of software that they don't fully understand from a supplier who has either bid so low because they have no idea of the full costs of implementing what the client wants, or they are "low-balling" to get the work with the hope that they can ask the client for extra money for changes further down the line. This isn't a good basis for a successful project.

Agile methods can get round this problem. Agile methods encourage information sharing between client and supplier. By delivering software in small iterations, Agile methods allow the suppliers to get paid a reasonable rate for what they do at a low risk to the client who gets to see working software early in the process. Once they see some software working, they have a chance to change their mind before it's too late.

Agile, Lean, Kanban feed

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