Plan do check act (sometimes PDCA) is Deming's cycle of continuous improvement:

It's a key part of most TQM and kaizen models - a way of ensuring experience actually makes a difference. Once again I'm reminded of educational theory's take on the same subject: people and organisations learn in the same way.

It doesn't matter where you start on the cycle, or even what you call the steps. PDCA is probably the cleanest description model I've seen (Deming had knack for that) but they're all pretty similar. People learn but looking at what went right or wrong, figuring out why, planning what to do differently and then doing it again. I guess it shouldn't be a surprise that collections of people and processes 'learn' in the same way.

My evidence of this is anecdotal, but it appears as if an increasing number of developers describe their process as "agile, but with a small 'a'", "agile-like, but with ..." or something similar.

These processes have a lot in common:

Initial specification documents are functional rather than detailed, business needs orientated rather than technical. Checked in code should always compile and basically work. A continuous integration server runs all the time and regularly checks this.

There appear to be two broad models in Agile for how blocks of functionality are managed. In most variants there is a backlog of requested features that is compiled into a single block of work and a date that work will be completed by. There are various names for this but I'm going to refer to it as a sprint. Features not completed by the deadline are dropped, and by completed I mean thoroughly quality tested as well as functionally complete.

無駄 (muda) is a Japanese term for wasteful activity. Time and resources lost on such activity are being spent on the wrong things. Muda was conceived as part of a manufacturing model but I think it still has some application to software development.

Muda commonly focuses on the 7 wastes:

Defects

These are a double hit - wasted time putting them in and wasted time finding and fixing them.

It always comes as a surprise when other departments describe developers as arrogant. It shouldn't, I've seen it quite a few times in teams I was part of, teams that I was managing and teams that I had nothing to do with. It's too common a pitfall.

Part of it is due to a perception of elitism. It would be unfair to generalise developers as elitist, but they universally have very high IQs and are very knowledgeable about their chosen subjects.

Douglas McGregor's Theory X & Y is something I've written about before: basically a manager's view of people is what governs how they manage. X is cynical of people, Y is more positive.

On the surface Agile is extremely theory Y. It's all about developers participating in the product management process. However I think there's two camps within Agile, and these fall down roughly similar lines - again based on the assumptions managers make about their teams.
4

What does "methodology" mean? The -ology bit is Greek, and means "study of". So as geology is the study of geo and biology is the study of bio, methodology is the study of method.

Why do people keep using methodology to mean method or process. People say "A development methodology", our "let's apply a new methodology" when they mean method, process or philosophy. I think they think methodology means "method plus a bit more" when they say it.
2

W. E. Deming is the father of Total Quality Management. Deming is a hero in Japan, his teachings are such a part of the culture that they're taught in primary schools and the Deming Prize is one of their highest accolades for industry. Yet he lived in America where no-one had heard of him until he was in his 80s!

Deming went over to Japan after WWII to help re-build their industry. At the time American industry ruled the world.

Unit testing is programmer code that tests other code. For instance: if you're writing software to do financial calculations you might have more code that checks the results of those methods.

I started using unit testing as a standard programming tool about 7 years ago. Back then I would have described myself as doing Test Driven Development (or TDD), although I'm not too sure that I was now.

TDD has 3 laws:

You may not write production code unless you've first written a failing unit test.

When I started at my current company YAGNI was core to their agile process. YAGNI stands for "You Ain't Gonna Need It", and the principal is basically that you only code the features that you know that you need right now. It doesn't matter if you're sure that you're going to need to change it later - only code for the current needs.
Label Cloud
Label Cloud
Blog Archive
Blog Archive
About Me
About Me
Blogroll
Blogroll
Loading