1. Signs of a Healthy Codebase
2. Cobertura Gottachs

1. 8 Reasons to Focus on Informal and Social Learning by Charles Jennings
2. Obsessed with Formal Learning at your Workplace?

1. Obsessed with Formal Learning at your Workplace?

1. Goodbye Simplicity; I’m Object Obsessed
2. The Bloat Effect

The recent news that Google is officially shutting down ?Wave? came as a shock.  Even though I never expected this to happen, I appreciate Google?s courage to shut down the product built with considerable amount of effort and money. This courage reminded me of the courage, one of the core values in Extreme Programming(XP).

Courage in XP is explained with as example as  :
Courage is knowing when to throw code away: courage to remove source code that is obsolete, no matter how much effort was used to create that source code

After re-reading the core values, I have been getting more questions than answers !
Do we really practice Courage in our projects ?  What fear do we have ?  Why do we hesitate to take risky decisions ? Who influences our decisions while we are on the project ? What do we need to change to practice courage ?

Coming back to topic of Google wave, the reaction to the Google Wave shutting down news has been pretty much mixed. Broadly the reactions were of 2 categories:

 

One really bashing Google for not thinking through  and finally shutting down the product

A

ppreciating Google?s courage and ability make quick decisions

I felt that these two reactions could be compared to Waterfall thinking and Agile thinking respectively.  The reason for this analogy is, Waterfall mentality is to force every one to think through all the possible things and create a plan engraved on stone. Agile being incremental and iterative in nature gathering constant feedback taking quick decisions every day. 

Even though waterfall way theoretically looks to work, it never does.  Agile thinking is all about quick action, getting the feedback and making course corrections, which I think Google did it as in the case of Google Wave.

Keeping the Google?s cue in mind, if one key value like courage is injected in Agile projects, then Agile teams will get an additional teeth to be more innovative. Without Courage, they would end up stuck with Waterfall thinking in the guise of Agile.

I have come across many projects claiming to be Agile, however they are really doing nothing more than mini-waterfalls. They do the Requirements, design, coding and Testing incrementally and in a bi-weekly fashion. If you carefully observe, still testing is done during the last days of sprint/iteration.

What is not Agile Testing ?

Testing within Sprints in projects following Agile methods is not Agile testing. 

It is disheartening to note that, many people give a little or no value to the testing in Agile projects. According to me, Agile testing is important as a practice as Scrum Meeting or retrospective.

Myth around Agile Testing
There are still some myths around Agile testing.

* It is a myth that in Agile projects all the testing would be done by developers.  
*  Testers role would become obsolete in Agile projects

Additional factors that are given importance in Agile testing includes

1. Testers are no more reactive, they are proactive.
2. The testers are not in the project to identify defects but to build the quality in the product
3. Testers participate in all the activities of software development, right from Requirement analysis to design, architecture and till the end.
4. Testers play the role of Generalized Specialists taking one or two additional responsibilities  apart from testing. 
5. Test Automation is given importance than the manual testing

Agile Tester

With so many additional factors involved in Agile testing, is it really possible for traditional testers to switch gears quickly to accommodate the new changes ?    Answer is ?NO?. 
It takes its own time and in the sense, it could take sometimes months. The rate of change depends on the support given by the management to the testing team.  More the support, smoother and quicker would be the change. 

Some of the mindset changes needed by Agile testers include
1. More stress on improving the communication skills
2. Courage to drive quality in by taking charge of projects
3. Proactive mentality rather than reactive
4. Eagerness to learn new technologies and framework to become generalized specialists.

In Summary:  Agile testing is all about change in mindset and focus on building the quality in the products.

1. User Story Mapping – Jeff Patton
2. Getting Ready to Produce
3. A Startup Journey: Evolving from Ad-hoc to Agile to Kanban
4. Using ToC and JIT Practice to Coach Agile Teams
5. Agile India 2010 Conference: Panel and Lightning Talks

I have been awarded as the Most Valuable Blogger(MVB) by DZone. I am very excited about this news.

During the touring lecture in 1972, Edsger W. Dijkstra talked about the topic ?The Humble Programmer?.  During this lecture he makes a statement, which I think is really revolutionary?.

Those who want really reliable software will discover that they must find  means of avoiding the majority of bugs to start with, and as a result the programming process will become cheaper. If you want more effective programmers, you will discover that they should not waste their time debugging ? they should not introduce bugs to start with.

Is he not talking about avoiding the wastes of Product development, one of the lean principles ?

Is he not talking about the Test Driven Development ?

Complete excepts from his lecture could be found here.

Even though such pointers to TDD has been propagated by thought leaders since 1970s, it is very sad to see hardly a few programmers follow this great practice even after 3 decades.