Going back to basics - Incremental, Iterative, Agile, Spiral

Words like Incremental, Iterative are quite often used in an Agile environment. In most cases Incremental and Iterative are used interchangeably. However it is not true that they are one and the same.

Incremental is anything that is built in small chunks, however Iterative is much more planned even though it is also built in chunks. Most of the Agile methods we see are incremental and Iterative.

There is also a debate that the current definition of "Iteration" which specifically talks about building something incrementally but in a time boxed environment is the definition introduced by Agilists, and not the true definition.

Brad Appleton has done a lot of research about the definitions and history around usage of Incremental and iterative words. Check this link out for more details

Agile, Scrum and CSM

Nowadays a lot of companies/software developers wants to get Certified Scrum Master(CSM) certifications. I don't understand why they are in such a hurry. Mostly CSM courses cost anywhere between 1000 - 2000 USD.

I have heard, The Scrum Alliance and the CSTs(Certified Scrum Trainers) are making a lot of money out of it. After looking at the commercial aspect emerging out of Agile methods, and on a lighter note,
I have come up with an analogy.

Agile could be compared to any open source software developed by a bunch of geeks to solve a specific set of problem(s).

Scrum could be compared to the companies who make use of open source softwares, and build a product around it, sell it and make money.

Importance of Scrum Meeting and Kaizen Line stoppages

Many a times Scrum meetings starts becoming boring and if you are one of them, who feel Scrum meetings look like micro management or merely a status update meeting, then this article might give you an insight into why you have such bad feelings about scrum meetings.

Scrum meetings are the backbone of any Scrum lifecycle. It is conducted on a daily basis, and the team members/product owners(as needed) and Scrum masters are expected to be part of this meeting.

I am not going to explain all the details about how to conduct the Scrum meeting but at a high level, 3 questions are answered,

• what I did yesterday,
• what I would be doing today and
• the roadblocks in achieving ones goal.
  

image copy right

Many a times Scrum meetings are converted to a status update meeting. However the intention of adding Scrum meeting to the Scrum Lifecycle seems to be to
1. Make the people to commit their goals in public. Psychologically, this would ensure that people would try to keep their word. This is done with the first and second question used in the Scrum meeting.
2. Impediments/roadblocks are brought to the forefront on a regular basis. This is brought out by answering the 3rd question in Scrum meeting.

The 2nd intention(impediments/roadblocks) mentioned above seems to be taken from the Lean/Toyota Production systems's Line stoppage concept. The idea is that a problem should be addressed and discussed as it occurs, rather than sweeping it under the rug to be forgotten. During these line stoppages all the employees and senior management would take part to understand the problem, brainstorm on the solution and, team effort is used to address the problem.

The problems that Kaizen line stoppages seek to eliminate are extremely costly to the company and ultimately grow worse as they move down the line to your final customers. By being proactive and seeking to eliminate the problem at the source, you're avoiding a lot of costs and headaches in the future. In addition, your employees will appreciate the process, as their input is being taken into account and their opinion is being listened to.

In Scrum, the question around "roadblocks" provides an opportunity to bring the issues to the forefront providing an opportunity to tackle it proactively.

If the values behind Scrum meetings are not understood properly, it merely reduces to a status update meeting, making it boring and people resisting to attend the meetings.

"World is Flat" and Distributed Agile development

I have been reading the book World is flat, since the last few weeks. In this book Thomas L. Friedman, argues the importance of outsourcing. I came across this wiki, in which the benefits of outsourcing is summarized as

Friedman argues that outsourcing has allowed companies to split service and manufacturing activities into components, with each component performed in most efficient, cost-effective way.

Many software and BPO companies globally have realized the above advantage of outsourcing. At the same time the global companies wants to improve the efficiency and productivity by applying efficient software development and industrial practices. One of the ways to reap the above benefits in software industry is by applying Agile methods. Currently there is a big hype in the software industry around Agile, and specifically in India, I am seeing a big wave of Agile hitting the software industries.

Even though I don't have statistics around outsourcing/distributed development, I strongly believe more than 60% of the software development happening in India is mostly in a distributed mode. Many of these developments are at different phases of implementing Agile practices.

Nowadays I have been hearing many Agile thought leaders arguing that "distributed" team is not a team and anything the distributed team calls as "Agile" is really not "Agile", like this one. Obviously if this is not called "Agile" then what are we practicing in this distributed mode ? So far the above mentioned argument is mainly coming from the developer community, thought leaders and not from business people. Business people seem to not care whether it is Agile or not, and at the end of the day, they want the application to be developed and want to make profit out of it. At the same time, developers don't care whether it is Agile or not and at the end of the day, they want to develop applications satisfying the needs of the stakeholder.

I agree that if some thing should be called as Agile, it needs to follow the values and principles mentioned in Agile Manifesto. I also agree that there is a value in following those principles. However if tomorrow, somebody comes and makes a rule saying that "Agile" word should not be used for projects in a distributed mode, then definitely one should start thinking about inventing a new methodology that can be tailored to distributed development.

I have started thinking, may be this is the right time to invent something new and that is more like "Agile" and somewhat like "lean" , that is flexible, efficient (like the "collocated Agile") and also mode free(collocated or distributed) !!! I don't know who else in the world is thinking about this, atleast I have started to do so.