Software Engineering weblog

Following are my comments on “Why do you want to adopt both CMMI and Agile ?” in Agile CMMI for Software Professionals group in Linkedin

CMMI is about measured capability maturity, primary beneficiary being the organization/project itself, and marketing advantage being a by-product.

I have worked with customers on their way up the CMMI levels. For some of them, I am sure, primary motivation for going on with CMMI was not marketing but rather demonstrated/proven capability maturity.

Agile approach is about effectively doing software development, being open and honest with all stakeholders across the board; focus being brought back from documentation (at times, misinterpreted to mean process) to customers, milestones, deliverables and team.

Fundamentally, being agile is a statement by yourself, about yourself, to yourself. You are not agile because someone wants you to but you believe you are doing the right things by adopting agile practices and you follow them for their benefit

I consider both as two sides of the same coin (software engineering), rather than conflicting interests

One does not adopt knowledge base and process framework. Rather, you pick and choose from it. I agree, “extract any element of RUP you think you need on a given project and add it to Scrum”, as pointed out by Richard, is the right way to use it. Meaning, in that case you are using RUP as a reference, and not as a textbook or bible. Again, you need not worry about size of encyclopedia if you know what you need from that

Again, I believe, good architecture and design is important for software development and role of architect, for me, is in war front (and therefor, hands on and continuous; again in sync with RUP), and not in the control room. Such architecturally-orientation is not in conflict with agile practices. In my understanding, what agile practices stand for is ‘right sized” architecture or design, rather than discounting their value.

Incidentally, I do not ask my customers to adopt RUP but I present to them as a knowledge base only. I also use it as a knowledge base, at the back of my mind, in my consulting service.

I would like to hear from you on your thoughts and on what you find in as conflicting

Following are my comments on “This is our chance – how we pitch architecture value to the masses” in International Association of Software Architects group in Linkedin

Business requires and would demand value now and value later, and shrinking time line is a force (like many other) that architect needs to negotiate and balance. Architecture, as a subject of study and profession, is of no practical relevance unless it is translated into tangible value in the context of current and future business realities.

I believe, architecture continues to be relevant. Architects need to identify the value in concrete terms and communicate to other stakeholders, to be relevant

Following are my comments on “Are Developers good testers… and can test better than a QA guy…??” in Software Testing & Quality Assurance group in Linkedin

I continue to be a designer, programmer, and tester. My experience is:

Coding as a mix of translation, derivation, and synthesis; essentially a creative and optimistic track. Testing is an act of what I call a “constructive destruction”.

Slips from development are not, typically, intentional. My code is my baby and I would like it be the best… this is also cause, at times, for developer-tester chasm; question on my baby is considered as question on me.

Human mind is at work and it has limitations. Human mind works best on terrain it is familiar with. You train it on coding; it will adapt to that. You train it on testing; it will adapt to that. It is difficult to be both at the same time.

Again, typically programmer works on smaller unit, whether he/she is aware of and involved in larger picture or not. Focus of testing, therefore, from developer is restricted to that unit (or a similar unit from peer). This is and needs to be done

Testing of the whole software is different from testing individual unit. Perspective now has to change to whole system and its desired business value. Typically difficult for a person to be both at the same time.

If trained well, one person can do both, in two different points in time but details, perspective and approach needs to change

Following are my comments on ‘A Tester’s Observations in an Agile Environment’ in Software Testing & Quality Assurance group in Linkedin

I have seen successful and failed agile environments. Problems occur when fundamentals are compromised.

Agile approach has put focus back on individuals, rather than process/documentation; quite rightly so.

Therefore, success in agile approach depends on motivation (very critical) and skill levels of individuals involved, team synergy and agility, and very short feedback/correction cycles. Quite ironically though, I have seen in many such projects go on downward spiral with process (I do not mean documentation here) getting ritualistic and viscosity setting in the team (may be, a human tendency). This happens over time, as project complexity increases, defeating the very foundation on which agile approach is built. Given the above, I consider effect on testing is natural and incidental, though disastrous; meaning, root of the problem lies elsewhere. I consider this tendency fatal, unless immediate remedial steps are taken.

I had been asking a stock question to many agile teams that I have come across. Question is, does you testers ACTIVELY participate in the meetings. On probing (and, only on probing), it comes out that testers participate but participation is rather ritualistic. They do not dare to ask uncomfortable questions. It is important to ask uncomfortable questions, even if sugarcoated, and get answers to those questions. After all, no one else but only testers can claim to know the software as it is (rather than, what it should be/have been), its shortcomings/pitfalls, testability issues

It does not matter to me, as a tester, whether answers (to the uncomfortable questions that I ask) come to me as documents or it comes from discussions but if answers not coming from project team, irrespective of methodologies, project is running on dangerous track.

Then, it is time for a serious jolt; a jolt from above. If jolt does not occur naturally, it needs to be made to happen. In my experience, I find that someone, somewhere is always listening. But we need to set alarm bell ringing!

About

Software engineer referred here is not a person with designation “software engineer” or similar but a practitioner in perpetual quest in balancing academic interest with business priorities.

This is blog of my forays into software engineering!! Indeed, software engineering is not new; it is there for decades now… to be precise, since NATO conference 1968. But does it make sense? does it have practical relevance? in the context of business imperatives? what does practical adoption involve? … and many more questions follow

In my business, my endeavor to deliver business success to my customers leveraging software engineering principles, best practices, tools, technology and so on… and my learning and experiences are what I seek to share here