Is Planning an old idea whose time is up?
In the age of nano attention-spans of people, the tendency and respect for planning things upfront has taken a serious beating. The mainstream logic is to simply “play by the ear” because there are far too many moving parts to be completely accounted for and properly factored-in - and in any case, by the time the plan goes to execution, ground realities would have changed beyond recognition, thereby rendering the plan completely useless by that time. In software development, an inaccurate predictive long-range model such as Waterfall has been replaced by more accurate adaptive short-range Agile methods that solve the line-of-sight problem but don’t address the original problem - that of planning a large project with its own share of uncertainties. While none of those arguments might be wrong par se, we conveniently ignore the fact that that is the nature...
Why are we in this mess?
Prior to the industrial age, the world was essentially an agrarian and a trading economy. Production methods were often a craft and top secret, fiercely protected within a family and handed down from a master craftsman to his sons, and with no machinery for mass production, pretty much every product was handmade and unique, perhaps also customized, for its intended user. Industrial revolution made mass production and rapid movement of goods possible, and among other things, catapulted Britain into forefront of global economies. Gutenburg’s printing press was perhaps the first mass production system built by man. Subsequent inventions like harnessing of steam power made railways possible, spinning machines, and other advances in iron founding and chemicals pushed the envelope. However, a lot of these advances were limited to Europe and even more within the UK, which thrived on these advances and...
Our methodology is 100% pure, our result is another thing!
What is worse then an anarchy ? You might say that is the absolute abyss, but I think blind allegiance is even more dangerous (and that includes following the letter but tweaking the spirit - things like ‘creative accounting‘ or its parallels in every field). Anarchy at least allows for things to become ‘better’ in order to survive - whether it is the idealogy, resistance, or even musclepower, or any other ills (and hopefully at some point, social forces of constructive destruction take over). But in a land where unquestionable compliance and blind allegiance rule the roost, IMNSHO, is like a terminal patient off the ventilator support. When people are on their deathbed, they don’t regret things that they did but much rather the things they did not do! In project management, life is no less colorful. We have...
Codifying Agile Skills or creating more checklists ?
Did you check out the Agile Skills Projects yet ? It seems to be a new and interesting initiative to “… establish a common baseline of the skills an Agile developer needs to have, including a shared vocabulary and understanding of fundamental practices”. They talk about Agile Skills Matrix that has seven essential skills, or the Seven Pillars, organized into five skill levels. Seven Pillars include: Like this:Like Loading......
How Lean thinking improves productivity in software teams?
At its core, productivity for a software team (often wrongly termed as programming productivity because software development is much more than mere programming) looks like a great idea. In its simplest form, it compares output of the team (amount of useful and usable software created, amount of unnecessary rework done, number of defects produced, etc.) to the input (time, effort and resources invested in producing software) factored-in by the uniqueness of the given software endeavor and other external environmental factors (complexity of the software being produced, impact due to team sizes, nature of team spread and its familiarity with the problem at hand, problem domain, and so on). Unless you are willing to discount software development as a non-business critical activity undertaken purely for the labor of love that should not be ‘measured’ lest it dilutes the very ethos of software development as a creative cognitive endeavor,...
Some ‘universal truths’ of software development
 Over the years, I have had the good fortune of stumbling upon several universal truths of software development. that have stood the test of time. While some of them were gratefully borrowed from other more competent professionals, several of them have been earned first-hand I offer them here for your critique: Like this:Like Loading......
What is the Inventory of your Software Development project ?
 Like this:Like Loading......
Is Scrum serving your Software Development, or the other way round ?
There was a question on the group Scrum Practitioners on LinkedIn if “…implementing Scrum as a whole should be our goal or would you use aspects of the Scrum methodology to realise an agile culture change ?†Looking at the disproportionately large number (with an increasing trend) of posts on popular mailing lists on Scrum and Agile software development, I am alarmed that most energy and thought is being spent on figuring out “how Agile you are”, how should the user stories be worded, and whether one uses planning poker or not ? I mean…does it really matter whether you use ‘deal hours’ or ‘story points’ whatever that means ? If your team members are not speaking out ‘impediments’ in daily scrum…come on…that was the case in good old days also…expecting that Scrumifying the process will make everyone speak...
When you still can’t develop quality software from Requirement Specs, how do you build it right using Test Specs ?
Test-Driven Development (TDD) is the new silver bullet in town. While several ‘obvious’ advantages are being cited in several articles, I fail to understand one simple fact: when we have not yet quite figured out how to develop good-quality software from requirement specs, how do you really use TDD to develop it using Test Specs ? Bertrand Meyer has a point in case in a recent article, “Seven Principles of Software Testing” in IEEE Computer, August 2008: “…Test-driven development, given prominence by agile methods, has brought tests to the center stage, but sometimes with the seeming implication that tests can be a substitute for specifications. They cannot. Tests, even a million of them, are instances; they miss the abstraction that only a specification can provide.” Like this:Like Loading......