The agile manifesto has been around for quite some time and is being hailed as the biggest revolution since stored program concept. My personal experiences around agile never felt like a revolution. If one looks at the sparsely available data related to project success rates in IT, one finds that agile projects did have higher success rates but not as high that they could be called revolutionary.
So I decided to look at the agile manifesto again.
Changing Requirements
I agree that there is a need for the software teams to adapt to changing requirements but I would not go as far as to say that we need to welcome requirement change. Agile or traditional, any change in requirement does cause disturbance to the ongoing problem and agile teams may be better placed to handle that change but it is the adaptability comes from underlying software architecture and design rather than the agile process per say. I have good agile teams having underlying architecture and designs that result in the complete team being thrown off course as soon as a requirement change is encountered.
Business and Developers must work together daily
In most of the agile teams that I have worked on, business people can't afford to work with developers on a daily basis and hence the voice of business people is carried to developers through the product managers. The original intent of "the individual with the problem" working together with "the person who can code" is not achieved anyway. There is still content lost in translation.
Motivated Individuals
I think this is the most important aspect of any agile team. This also overpowers all the other principles of the agile manifesto. If I can gather a group of motivated individuals, I don't need to really worry about most of the other stuff. If the team is motivated to build the right thing that the customer wants, all our problem would be solved. If I was running a non-agile, traditional project and I had a set of motivated individuals, I would still most probably end up with a successful project.
Best architecture, requirements, designs emerge from self-organizing teams
I think there is very little difference between a team in chaos and a self-organizing team. When a team delivers with best architecture, requirements, and design, we call them self-organizing team otherwise they are labeled a chaos. I think this principle of the agile manifesto cannot be operationalized because if we give the freedom to self-organize to a team, whether they are effective or they have descended into chaos will only know once they produce their output and by that time it is too late.
In my view, the biggest problem staring the agile manifesto today is that it has become almost akin to a religion. People fight battles whether something should be called an Epic, Story or Task. People fight over what can be discussed in a standup. It is almost like the process has become most important aspect, nobody is worried about the end result.
Most people working in agile teams think that agile is all about coding, the thinking required to build a good product is considered a waste of time. People build bad software proudly claiming, we will refactor it later. In the name of backlog list, the visibility in the project tracking is completely lost. It has almost become a voodoo.
I believe the point of the agile manifesto was to eliminate activities that were not adding anything positive to the product. For example, there was absolutely no point in writing an interface control document because, C headers, Java interfaces could be used to explain interfaces better and they were easily manageable. But unfortunately, it has been taken as execute to eliminate activities that were actually contributing to product quality. In the end, we have not made gains that agile should have given us.
So I decided to look at the agile manifesto again.
As we carefully look at the above principles of the agile manifesto, there can't be any quarrels about 1, 3, 6, 7, 8, 9, 10, 12. These are just good principles for any project team. Nothing to do with agile versus traditional. Let's look at other items in the agile principles.
- Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
- Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
- Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
- Business people and developers must work together daily throughout the project.
- Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
- The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
- Working software is the primary measure of progress.
- Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
- Continuous attention to technical excellence and good design enhances agility.
- Simplicity--the art of maximizing the amount of work not done--is essential.
- The best architectures, requirements, and designs emerge from self-organizing teams.
- At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
Changing Requirements
I agree that there is a need for the software teams to adapt to changing requirements but I would not go as far as to say that we need to welcome requirement change. Agile or traditional, any change in requirement does cause disturbance to the ongoing problem and agile teams may be better placed to handle that change but it is the adaptability comes from underlying software architecture and design rather than the agile process per say. I have good agile teams having underlying architecture and designs that result in the complete team being thrown off course as soon as a requirement change is encountered.
Business and Developers must work together daily
In most of the agile teams that I have worked on, business people can't afford to work with developers on a daily basis and hence the voice of business people is carried to developers through the product managers. The original intent of "the individual with the problem" working together with "the person who can code" is not achieved anyway. There is still content lost in translation.
Motivated Individuals
I think this is the most important aspect of any agile team. This also overpowers all the other principles of the agile manifesto. If I can gather a group of motivated individuals, I don't need to really worry about most of the other stuff. If the team is motivated to build the right thing that the customer wants, all our problem would be solved. If I was running a non-agile, traditional project and I had a set of motivated individuals, I would still most probably end up with a successful project.
Best architecture, requirements, designs emerge from self-organizing teams
I think there is very little difference between a team in chaos and a self-organizing team. When a team delivers with best architecture, requirements, and design, we call them self-organizing team otherwise they are labeled a chaos. I think this principle of the agile manifesto cannot be operationalized because if we give the freedom to self-organize to a team, whether they are effective or they have descended into chaos will only know once they produce their output and by that time it is too late.
In my view, the biggest problem staring the agile manifesto today is that it has become almost akin to a religion. People fight battles whether something should be called an Epic, Story or Task. People fight over what can be discussed in a standup. It is almost like the process has become most important aspect, nobody is worried about the end result.
Most people working in agile teams think that agile is all about coding, the thinking required to build a good product is considered a waste of time. People build bad software proudly claiming, we will refactor it later. In the name of backlog list, the visibility in the project tracking is completely lost. It has almost become a voodoo.
I believe the point of the agile manifesto was to eliminate activities that were not adding anything positive to the product. For example, there was absolutely no point in writing an interface control document because, C headers, Java interfaces could be used to explain interfaces better and they were easily manageable. But unfortunately, it has been taken as execute to eliminate activities that were actually contributing to product quality. In the end, we have not made gains that agile should have given us.
