Fake Email Server for TDD

I found this nice tool called Dumbster which is a fake SMTP server. This can be used for unit and system testing applications that send email messages.

Agile 2.0 ?

Recently buzz about Agile 2.0 is going around in agile community, looks like sponsored by Microsoft. Here are my thoughts about Agile 2.0

1. From the above article, it looks like MSF is concentrating on agile practices. This would the right recipe for failure. Agile manifesto never talked about practices but only on principles and values which are global and constant. Practices needs to be tailored to individual project environments based on principles and values. A practice that works in one environment may not work on the other

2. Name Agile 2.0 itself is a misnormer. In continuation of point 1 above, there was no such thing called Agile 1.0 before !! We had just agile principles and values.

Law of diminishing marginal returns

I found this nice article on wikipedia about law of diminishing returns.

Quoting from wikipedia:

The "law" of diminishing marginal returns says that after a possible initial increase in marginal returns, the MPP(Marginal Physical Product) of an input will fall as the total amount of the input rises (holding all other inputs constant)

Here are some of the examples from software development environment where we can see the above law in practice:

1. Addition of new team members to the project "seems" to increase productivity marginally but reduces over a period of time.
2. Developers excited about implementing the new technology, and after a while losing interest in it. For ex: implementing Webservices

Software development and mass production mentality

In the last few decades the mass manufacturing industries went on a spree to create "intelligent" machines. The intention of this creation was to solve complex industrial problems quickly, and reduce the manufacturing defects. The only thing the "isolated" worker would do in the assembly line, was to pickup the parts from one line and feed it to next. There was no need to "talk" or "communicate" to the fellow worker. Can you see any similarity between the above example and, "traditional" software development teams ? . The traditional software development is plagued by "mass production mentality". The requirements team would feed set of documents to analysts, who in turn analyze and feed to design team. The design team would feed the high level and low level design docs to development team, etc. Each team has there own specialty and is happy doing the routine work !.

In the lean enterprise, the employees would talk and take help from each other while solving complex problems. They would make use of big visible "andan" systems to constantly monitor the status of production, defects, inventory information. This leads to better communication, leading to creative solution.

I have become Scrum Master HEY !!!

Craig conducted the course on "Scrum Master Certification" in Taj Gateway on Residency road. We were around 40 people, mostly from Valtech India. It was fun and also learnt a lot. Since, I have been working with Craig from the last 6 months, I knew many of the concepts and much more. I was really moved when Craig gifted me the Critical Chain book. Looks like he is asking me to start looking towards next wave coming up in process improvement !!

Finally I can call myself as "SCRUM MASTER" HEY....HEY.. I am just excited about this.

Agile journal article

My article on Benefits Of Tool Integration In Distributed Agile Development was published, and so far received good feedback from friends and well wishers !

Technology experts rescuing process team

From the last couple of months, I have been working closely with Craig Larman and I got a chance to learn not only about Agile methods but also a lot about OOA and OOP. I am also a big fan of people like Martin Fowler, Ron Jefferies, Jeff Sutherland who have contributed a lot to Agile methods. If you carefully observe their past life, they all come from technological background rather than the pure process background. This is leading me to believe that a person with both technology and process background could contribute more to software development world than being purely in one of them. I would like to quote one of the real world examples, I was having a chat with group of SQA team, and still they think TDD is testing rather than a design !!. I saw today Craig checking the code of a team member and smoking code smells out, and I don't think this could be handled by a "pure" QA person.