Blogging from Hyederabad airport

I am quite amazed to see indian airports becoming hi-fi day by day. On my way to Dallas, while waiting for my next flight I could see many people browsing in the lounge. I wanted to give it a try, and upon switching my laptop I could clearly was able to get atleast 2 signals, and one of them helped me to blog this post !!

During my journey from Bangalore to Hyderabad, I was able to read some 20 pages of Goldratts book Goal. The book kind of takes your through a trance, you will forget your surroundings !

Importance of coaching in distributed agile development

When an organization starts a new practice or introduces a new process into software development team, there would be some slack time before it really sees some gain. This is true especially when an organization decides to move from traditional development to Agile methodology. The practices like test driven development, refactoring are not so easy to learn without a coach in place.

In a distributed agile development scenario, one needs to be careful about the gap about the knowledge of agile methods between onsite customer and offshore customer. More the gap, more resistance resulting in reduced productivity. Generally this type of productivity problem happens, if both the onsite customer and the offshore team are new to agile methods. If one of them has really mastered agile methods then the gap can be reduced fast and there would be a productivity gain.

For Ex: if the onsite team coordinator "thinks" TDD is good, and starts pushing offshore team to practice "TDD". The offshore team, which is new to TDD would not only resist this, but also will try to write code to make the coordinator happy. This results in overstepping the values behind TDD or any other agile practice for that matter.

Agility and maturity

I keep hearing from people time and again that agile methods are for matured teams. My immediate reaction to such conversations is, agile makes the team more matured. I have been applying agile methods from the last two years, and each one of the team member (including myself) had come from CMM (or synonymously called traditional water fall model) have changed a lot after certain time. When I say change, it is not only the ability to deliver quality software but a mindset to learn and adapt. The reason being, the key practice, I would like to put it as "heart" of any agile methods practice is the "iteration". The rhythm and responsibility that gets created within an iteration makes the team more responsible and matured.

I am becoming more and more confident with great stories to prove that, one can apply agile methods to any projects and any "type" of people, and the result from it is always going to be something positive "on" the mindset of the team.

Valtech Days Conference Dallas Oct 2-3

I have prepared couple of presentations to share at Valtech Days conference going to be held on Oct 2-3. I would be presenting paper on "Monitoring distributed agile projects - tools comparison". I would be leaving India on Sept 29th and planning to be back by mid october.




I have done enough research in the last few weeks comparing various Agile PM tools available in the market(both open source and commercial). I was amazed to see that there are nearly 20 tools available and in various stages of development.

Valtech cockpit is tremendously ahead of other tools when it comes to third party integrations.

What is Agile

I know that you would be surprised to see the title !!! But, if you read the article by David Anderson you would definitely realize that most of us are forgetting the goal that was created to create agility in software development.

Just to summarize the point from the above article,
A process is agile if it

* enables companies to easily respond to change
* delivers working code to market faster (than previously or with other methods)
* delivers high quality working code
* improves productivity
* improves customer satisfaction
* and provides an environment for a well motivated team with high job satisfaction

Here is a good comparison between defined process and agile from Mishkin Berteig

Agile Axioms: We are Creators, Reality is Perceived, Change is Natural
Defined Process Axioms: Humans are Resources, Reality can be Legislated, Change is Bad

Agile Disciplines: Empower the Team, Amplify Learning, Eliminate Waste
Defined Process Disciplines: Enforce the Process, Avoid Experiments, Eliminate Variance

Looks like I am able to blog again

From the last couple of days, the entire blog thingy was working weird. All my posts seemed to get into some kind of black hole not able to see the outside world. Hopefully this should work now.

Benefit of tools in Software development

Today we were having a great debate on features and flaws of several tools. One thing I noticed during the discussion was, tools are being developed to control the people and process. I am feeling there is something terribly wrong in this concept. Even though I have been using several tools from many years, I had never noticed such a huge influence of tools in software development.


Many a times, the management decision to use a particular set of tools in the organization forces the development team to constrain themselves to adopt to the tool. This constraint reduces the creativity, productivity and enthusiasm in teams.

Difference between Test First programming and TDD

I have seen people using the words "Test First Programming" and "Test Driven Development" interchangeably, which is wrong. There is a subtle difference between the two.

In Test first programming, you just write the test using xUnit family(mostly) and then you write your code. There is not much rule associated with it.

Test Driven Development is a special case of test first programming where there are certain rules defined. For Ex: You write the test first, ensure that the program fails, then you write the code to make the test work, and finally refactor. This cycle is continued.

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.

Motivation behind scrum meetings

Scrum meeting is just not "Standing up" ,"meet" and ask 3 questions. There is certain motivation behind this meet. While reading an article I found one of the motivation to be:

When one team member shares an obstacle in the Scrum meeting, the entire team’s resources come together to bear on that problem. Because the team is working together toward a shared goal, every team member must cooperate to reach that goal. The entire team immediately owns any one individual’s problems. [Rising and Janoff, 2000]

This is also in accordance with the lean thinking, Toyota way !!

Agile Pit fall

Even though Agile methods are supposed to reduce the risk of the project, improve the quality of the deliverables, one thing I feel which would complement agile is "measuring the quality in each step". Agile principles and values never talk about any particular "measurement", and the Agile methods who have tons of practices have not given much importance to "measurable result".

Quality

I am sure you would be using the word "quality" hundreds of times a day if you are in software industry. Even though there are various definitions of quality from various school of thoughts, for example:

Quality is conformance to requirements.

and the other one here

Quality is the capacity to remain robust and conformant, while adapting to new requirements.

.

I strongly agree with the second definition. The reason being, I can write my program to conform to requirements but what if, the design is poor ? what if the code is crappy ?

Toyota Way and the Stand up meeting

I remember somebody telling me that, in Toyota manufacturing plant and in the assembly line if somebody discovers some fault in the product, immediately they would raise an alarm. This in turn signals everybody to stop what they have been doing, and approach the person who raised the alarm. All of them in that shop floor in turn would discuss and help the person in resolving the fault he/she has seen.

I believe the same principle is being applied in our daily stand up meeting. Most of the time, the daily stand up meeting is considered as "status meeting". In fact it is not, especially if you look at the third question "Any obstacles stopping the developer from proceeding further?". The reason I believe behind this question is to make the other team members aware of this issue, and in turn all of them can jump together in helping this person out. This is in line with the Toyota manufacturing analogy shown above.

Until we don't understand the principles behind practices, practices remains as practice !!

Discussion with Craig Larman

Nowadays I am working closely with Craig to get a deeper understanding of Agile and Scrum. Here is the summary of key what I understood

1. There is nothing called agile "method". Agile provides principles and values. There are agile methods like XP,Scrum,etc

2. Most of the time people who go through scrum master certification end up becoming "Project managers having Scrum master certification"

3. Scrum Masters are obstacle removers in a project rather than managers controlling the project. I can clearly see in my surroundings, how difficult it is to achieve this particular goal. The reason being most of the people are coming from "Project Management" background !!

Becoming a scrum master is not "practicing some things", it needs total change of mindset, the way we lead life at work, the way we think.

I have started working on implementing "Virtual Lava Lamp", and it looks like a lot of configuration changes needs to be done while integrating Cruise control with lava lamp.