About being agile

A decade or so back, agile community was small.. It was a community that knew what they do and how, and focus was on core values. But now, that does not seem to be the case any more. It looks like, agile has become struggle for learning handful of terminologies, following ritualistic practices, and getting certified for many!

Back then, common refrain when talking about being agile was “what you are talking about makes sense but, you know, our situation is different. We have our own ‘process’ certified by … and we follow the process’. Strangely enough, when I look around I find that most of them have joined the bandwagon, claiming to be agile. Yet how they go about their job remains essentially the same! That is, either they bypass documenting altogether even the very critical information in the pretext of being agile or get bogged down by documentation for compliance to standards. Adapting to change has become more of a knee-jerk reactions and continuous firefighting. Honest communication suffers with routine bullying. Unfortunately, world has not changed much for them, except for the plight of having to deal with a new set of terminologies and technologies as well and getting ‘certified’!

In this context, it is interesting to read article ‘What makes you agile‘. Indeed, it is important to bring focus back into what agile stands for.

I believe they are:
1. Being with the customer, and delivering value to customer continuously
2. Documenting information as we develop software but not getting bogged down by documentation
3. Delivering working software, and ensuring customer is able to use software to meet their needs continously
4. Working as a team with proven practices and effective level of automation
5. Adapting to change as customer needs change
6. Working as a team with honest communication all through

Technology and practices could be help these but not at the cost of these.

All too familiar management myths

1. The Myth of 100% Utilization
2. Management Myth #2: Only ‘The Expert’ Can Perform This Work
3. We Must Treat Everyone the Same Way.
4. Don’t Need One-on-Ones.
5. We Must Have an Objective Ranking System.
6. I Can Save Everyone.
7. I am Too Valuable to Take a Vacation.
8. I Can Still Do Significant Technical Work.
9. We Have No Time for Training.
10. I Can Measure the Work by the Time People Spend at Work.
11. The Team Needs a Cheerleader! 

 

Making of a professional software developer!

I came across an interesting lecture on professional software development by Robert Martin, a promotion part of video lecture series on clean code. I would recommend every software developer, and aspiring ones, to listen to. I believe that you will find this as quite thought provoking, and inspiring, just as his many other lectures are.  You would find it gently nudging you out of comfort zone into challenges of evolving into a true professional

Head count of manpower involved in software development has multiplied manifold from the time I started my career in software development more than two and a half decades back. Technology involved has changed, and software development environment has changed as well. World of software, and its role in the world, too has changed quite a lot since then…. and, as software reached out to every walk of life,   complexity and expectations too has increased manifold.

As we have reiterated many times over, software is essentially a construction in mind in first before it is executed in computer. It gets created in the minds of users, customers, developers, testers, … and often these do not connect breaking dynamic equilibrium of balance as software evolve. Making it still harder, complexity and disconnect increases exponentially with increase in the number of minds involved. It does not make any sense to wish these complexities away. These are here to stay. It can only get more complex and challenging, as we depend more and more on software.

Key to being a professional is to get on top of these. That is, a true professional would stand up for what he believe in, what he likes to do, take up the initiative, own up the commitment and deliver to the commitment. A true professional will see commitments as extremely important, not a casual word. We work as we work as a team, and a whole chain of commitments depends on your commitment. Many business, and many lives, depends on it and if commitments are not honored all of them are affected. It is your responsibility to see that commitments made by you are honored within time, budget and quality expectations.  That is, you are absolutely in charge of the situation, rather than its victim.

Note: Video of interviews with a super star from Indian film industry and another one with a master batsman from Indian cricket embedded here, both worked their way up fighting many odds. Both are involved in a profession which calls for individual excellence and team work for success. Both are professional who made indelible in their space, and are reflecting back on their rich experience. I believe spirit of professionalism cuts across many disciplines. It may differ on details but fundamentals remain the same. It is about conviction, self belief, working hard for what you believe in, working as a team and and winning against many odds, in the right spirit

I believe, technologies, processes, methodologies and tools have evolved to a great extent by now and these can help us address the key challenges, if we can put these together in the right way, as people/team enabler. Well, it is important to get it right.

Also, it is important to stay clear of dogmas, and realize that when we direct attention towards moon by pointing in that direction, the pointing finger is not moon. It might sound trivial but it is common to see finger being confused as moon. What do I mean by that?

I have seen process quality standards like CMMI degenerating into a compliance ritual. Insistence (by whom? It is interesting to know) on excessive documentation leads to outdated, and even lack of (gets postponed as it is time consuming), documentation. Later documentation is done purely to satisfy auditing needs. That is, an initiative intended to help you manage collapse on its own weight. The real problem is not with CMMI but in its adoption

I have also seen free and honest communication getting compromised in so-called ‘agile’ environment with regular meetings turn into witch hunting and ‘save my skin’ interactions. That is, the term ‘agile’ gets stripped of its core values and gets used as a matter of convenience rather than any good. Again, what fails is not ‘agile’ but its adoption

Automation initiative, that starts with purchase of a commercial software for software development, get stuck in learning some esoteric aspects of the tool rather than addressing true automation needs. Again, problem is not automation rather how automation is approached and implemented

It is curious to see the patterns of wrong adoption repeating itself. While technologies, processes, methodologies and tools can help us in addressing key challenges, often, it is the related technical details grab attention through advocacy of vociferous loyalists and marketing machinery, rather than applying them right. The fact that these are enablers in the first place is conveniently forgotten

Looking around, it look forward to a phase in software development, a phase that physics had gone through between Galileo Galilei and Isaac Newton … a phase of consolidation, period of drastic and intense changes with far reaching impact. We have seen some of these continuing even into early 20th century through Albert Einstein, Werner Heisenberg , et al…. and as an industry, we continue to deal with more unknown factors than known ones, till the dust settle

I hope to see software development eventually settling down to become a profession, in its true sense… It has changed over years but still it needs to go a long way before it can truly be called a responsible profession.

Lifecycle of a buzzword: A cynical perspective

In my tenure in IT industry spanning more than two decades by now, I have seen rise and fall of many buzzwords. Some of them are: Artificial Intelligence and Knowledge Base Computer Systems in 1980s, Rapid Application Development and Object Orientation in 1990s, Use cases and Stories in 2000s, … and the list goes on… debate goes on ‘object oriented or structured?’, ‘agile or CMMI?’, ‘agile or UP?’, ‘use cases or stories?’

I am not disputing the value of these but rather questioning the hype that comes around these as they emerge. These hype help business of promoters but adversely affect their proper interpretation and implementation. It is equivalent to percolating modern innovations and approaches in healthcare through marketing machinery, skilled in marketing than healthcare.

Hardly any scientific analysis can happen without demystifying buzzwords first, and that requires going to its very origin. I do this regularly, try to see through these hype, just as I am sure many others like me in the industry also do. In the process, I have also noticed a pattern to meteoric rise and fall these buzzwords, going through different phases as below. Quite often, this is carefully orchestrated for obvious reasons.

Discovery: Each of these emerge out of experiments in a relatively small group; some one or a team taking extra care to pull out key factors those helped and those worked against. Those helped soon are packaged into best practices, spiced up with adequate marketing masala .

Evangelization: At this point, it takes a curious turn that marketing machinery is now active looking for ‘nails’ for this new found ‘hammer’ . That is, inventing problems for new found ‘silver bullet’ is a business imperative to justify cost put into packaging the solution!

Adoption: This effort, in general, is richly rewarded, finding fertile ground in the minds of ‘managers’ looking for ‘quick-fix silver bullets’.

In most of the cases that I have come across, problems are project specific though might have some resemblance to problems elsewhere. Solutions from outside, based on experiences in solving similar problems elsewhere, can help providing objective assessment and guidance but cannot simply solve these problems, by themselves. It is so because problems, in their very nature, are unique, intrinsic and integral to the project. External agencies (consultant, contractor, methodology, tool, ..) can help to identify but uprooting must necessarily be internal act.

At Mount Everest: What follows is a war of buzzwords; at times, one winning over another at times in terms of mind share to become ‘de facto’ standard…. Curiously, this is beginning of decay and rotting starts within, largely unnoticed… Each buzzword acquire new meanings far away from its original form….Originators are now caught between dilemma of what they created or dumping it…They go about issuing clarifications and revisions, further adding to noise…

Big Bang: What follows is disillusion and decline. Horror stories of failure emerge out of cupboard and world is on the look out for a new buzzword … and the life starts all over again.

Happy New Year!

Happy New Year!

Again, another year is coming to a end. It is time for a new beginning.

Personally for me, 2008 represented a successful completion of a journey commenced in 2002, and 2009 was a new beginning. Foundation is being built yet for my new dream, and realization of that is a long journey; a journey that may probably take about 10 years. Therefore, 2010 represents a continuity for me personally rather than totally a new beginning

Yet it make sense to look back into the times gone by and then look ahead. Year 2009 started on a gloomy note with the world in the grip of recession. As we see the world gradually wriggling out of recession, the coming year 2010 promises to be better.

2009 was a mixed bag, in general. As I look back into 2009, what comes to the top of my mind, on a positive note, is Oscar awards coming to India for the first time. What I recall on a melancholic note is the unexpected loss of an icon of our times ‘Michael Jackson’

Professionally, software development is poised for further challenges with computing set to scale new horizons in collaboration and natural user interface. Software engineering has undergone severe churning under apparently conflicting pulls from visionaries, theoriticians, methodologists, practitioner and tool vendors. It seems now that world of software engineering is ready to be settling into a dynamic equilibrium centered around delivering value to success critical stakeholders in a healthy business environment

Future beckons and that seems to exciting!

Happy new year!

Agile approach and Learning systems

I came across an interesting write up on ‘Agile Design: An Ethos for Creating Learning Platforms‘; a welcome initiative to bring agile approach into learning systems

Going my recent exploration in eLearning space, of late, I believe that this space is set to change with convergence of information and communication technologies and rapid changes taking place in related technologies. But I have not come across any product (commercial or otherwise) nor I have seen (or read about) any implementation, leveraging these even to a reasonable extent. Many, as I know, are in the research labs. Well, that is precisely my point.

Technology is only one of the influencing factors. It is, primarily, an enabling factor rather than a driving factor. Key is appreciation of its business potential, realization of business need and implementation of a solution to meet this need. This gives a clear business focus. Without such a focus, I find that, eLearning initiative gets pulled in different directions, especially given that eLearning represents confluence of many specialization. Resulting system becomes a skewed implementation influenced by political rather than business considerations.

Most significant influence of agile approach in software development, as I see it, is bringing focus back, from excessive documentation in the name of process and engineering, into delivering business value with honest communication and teamwork. I believe adoption of agile approach would help eLearning space as well, bringing focus back into business considerations especially given diverse, sometimes conflicting interests, of stakeholders of eLearning space

Top challenges for software engineering

Following are my comments on discussion “Top challenges for software engineering” in ‘Agile CMMI’ group in Linkedin

I agree with the importance of alignment. A reasonable (perfect would be rather idealistic) alignment of organizational and individual’s values, culture, and goals is critical..

My observation is that it generally seen in small organizations. As it grows in size, alignment is lost in the crowd. This may not be unique to software development organization but what is more intriguing is that this tendency is acute in software development organization

In general, at the very top, you would find more or less the same team, the same culture and the same values. As you look down the line, you could see compromises on the very culture and values that made them successful . Experience that I mentioned earlier is from a large organization that claims to be at CMMI level 5.

Equally, I have seen organization/project that claim to adopt agile approach missing out on team work and honest communication, going against the very values that agile approach stands for.

At the bottom most, it is just a job to do, skill to learn and move on to the next assignment.

No blasphemy is intended by these counter examples; I have seen good ones as well. I am focusing on counter examples as we are discussing challenges. A distinguishing pattern that I find in bad ones as compared with good is that CMMI, agile etc are used for marketing purpose rather than for value in itself.

My experience and stance is that process, methods, standards, technology and tools have matured to a reasonable stage by now and, for engineering to be successful, we need to adopt engineering practices with scientific spirit, teamwork, honest communication, continuous observation, objective analysis, and continuous refinement.

Measuring agile project manager’s success

Following are my comments on discussion “What’s a good measure of an Agile project manager’s success?” in ‘Agile CMMI’ group in Linkedin

I had been with agile approach all along, enamored by the simplicity. Do we need to complicate?

I like it because it has brought trust and communication back into our business which was lost into documentation in the name process. To me, our job is to deliver value to our customer on time and budget.

What am I going to do measuring my project manager whom I trust? What is the point in finding out that he/she measure up or does not? We are delivering or we are not. If we are not, we need to find that out ASAP and make amends.

Let us measure project (not project manager) and help project manager

Elements of engineering discipline

As per IEEE definition, software engineering is “systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software, and the study of these approaches; that is, the application of engineering to software”. There is still ongoing debates on how much engineering can apply to software development, and what would applying engineering mean.

Let us put it this way. Being “systematic, disciplined, quantifiable” is more of a business need. As software is getting increasingly pervasive to every aspect of life, business wants software development to be more repeatable and predictable.

Computing, business and software development environment has been undergoing drastic changes. We have attained some level of repeatability and predictability in software development though that may be far below the level desirable from business standpoint. This was due to untiring efforts of many great brains.

Looking back, what helps us towards being “systematic, disciplined, quantifiable”? “repeatable and predictable”?

I would classify progresses into following categories, with progress made in each of them:
1. Processes (who does what and when) and methods (how)
2. Standards (with standards like CMMI levels on one side of the spectrum and coding standards at the other side)
3. Proven practices (Harvest success patterns)
4. Tools (Software tools that help us do our work better and faster)
5. Metrics (Measures helping in objective observation and decision making)
6. Body of knowledge
7. Code of ethics

These are what I am calling elements of engineering discipline.

Let us not have any illusions.

Methodology/process wars are far from over. Proliferation of programming languages would continue. Computing technologies would continue to evolve.

There is a long way to go before software engineering would stabilize as a true engineering discipline but essential ingredients are getting to be in place and there is business need…

Let us move on…

Consortium for IT Software Quality

As software permeates every aspect of daily life and as we depend more and more on software in all walks of life, quality of software gets to be of utmost importance.

World has come a long way from the early perceptions of quality as a natural consequence of following a good process. Agile community has asserted umpteen times, reflecting in manifesto of software craftsmanship and agile manifesto, quality of software that add value to users in their context is far more importance than religious, and often dogmatic, adherence to process.

People, process and automation are three different, orthogonal but often inseparably interrelated, factors of what goes into making of a quality software. These form different dimensions that call for attention of a manager of software development project, and not conflicting goals as they are sometime made out to be. Managing software development project is not progressing on one dimension at the cost of another but working with a dynamic balancing of these dimensions through the course of project

Three dimensions of software quality

It is interesting to note, in this context, emergence of a consortium focused on software quality. It is a step in the right direction. I hope that this would help in making life better for its users and customers