Archive for the ‘Agile’ tag
The Model does not matter: Projects and JKD
Again let me remind you Jeet Kune Do is just a name used, a boat to get one across, and once across it is to be discarded and not to be carried on one’s back
- Bruce Lee, while describing Jeet Kune Do (JKD)
Over the last couple of months, I have been reading a large number of blogs, discussions, arguments, between purists on either side of the “Process fence” as well as middle-of-the-road liberals on what development model is best suited.
There are thousands of successful projects delivered using Agile, CMMI, SPICE, RUP and the hybrids in between, so clearly there is no single silver bullet. That begs the question, is there a single best way to develop software? Increasingly, I feel the answer is No. Even if you decide to go one way due to the needs of the project, it is not necessary to abide by a rigid set of rules prescribed in general by experts in that model.
How then do you decide how to develop software? The answer may lie in adapting JKD’s “The Way of the intercepting fist” philosophy, which, I believe, is closely aligned to Lean “thinking.”
Some thoughts:
- Start with understanding the nature of the project, the clients, the project teams and management needs
- Let this understanding drive the selection of the overall framework. For instance, if the project is to develop against an evolving standard, one of the Agile methods may be suitable. But if the team is not mature in terms of development practices, one of the iterative-but-process-oriented methods like the 2I or RUP may be better
- For engineering practices, use concepts and tools proven within the organization
- For project management, the established way within the organization or PMI’s methodology would be a good start
- Don’t be afraid in discarding practices if they are not useful, but be sure to substitute them with more useful ones. The easiest example I could think of is integration. A big-bang integration is not the norm these days, even in most process-oriented shops, but you can institute multiple daily builds instead of weekly or monthly ones. Another example is using Failure Modes Analysis (FMEA) to drive design decisions in iterations to prevent too much refactoring
There must be a term in psychology to describe this behavior: the moment we associate ourselves with something, we start believing that we must adhere to it 10o%, else the skies will fall on our heads!
As project managers, we must be careful not to fall into this trap, but carry a “toolbox” of practices which can be used in different situations. I am told that successful managers have this toolbox subconsciously, but are unable to spell it out exactly.
What about you? Do you think it is advisable to go with a single system of tried-and-trusted practices or have an assorted toolbox?
Lean, Kanban and Agile – An interview on MSDN Radio
This blog is usually a mouthpiece for my ramblings, but sometimes it is good to simply listen to others. I found out that MSDN had a radio channel and considering that Kanban is the new black, this is a good interview of 3 lean/kanban guys. Exciting folks to follow!
[If you cannot see the audio player below, you can listen to the audio-only interview at MSDN Radio Special - Kanban Lean or Mean]
