This post is in response to the following link: http://agilehandbook.com/agile-handbook.pdf
This was a very quick read and mostly reinforced the previous readings. However, the condensed version is really telling to the misconceptions that people have of the Agile method.
The developers were the ones that make the decision was an interesting point. This acknowledges the customer’s needs and visions and ensures that the development team is on point with the expectations. Considering that one of the key aspects of Agile is to meet the expectations of the customer. If the customer does not get what they want, then you can’t possibly be properly compensated for the work completed.
The concept that Scrum doesn’t consider the long-term was an odd one to me. The Agile method is scalable by design. Identify the portions of the product needing to be done, break them down into manageable chunks, develop them, and then deploy a working prototype of the work completed. If this is done consistently and methodically, there is no reason how a large or long term project couldn’t be completed under the agile practice.
I do enjoy the concept of speed to market. I consider a lot of my projects to be a modularized development series. I have always broken down a problem into smaller problems. As I work, I solve each problem individually until it is to a working state. Once I have that I can move on to the next problem, and integrate that into my system. Every step of the way I make sure everything is working exactly as engineered before I move on. By allowing a nonfunctional system, or ill-designed system to persist, I limit what I can do with the next step of development. After awhile, it will become harder to track down bugs and figure out where the conflicts in coding arise.
I can see why the agile method has become a very popular way of working in many companies. It is flexible, scalable, and it makes sense for a business. It makes it very easy to plan but allows for changes along the way.
Knowing what I know now, I am more confident that I could better work in an agile environment. In some ways, I already have been working this way. What this does is helps to formalize the practice and gives well-defined bounds to participants. Otherwise, this would be confusing, and obnoxious in the application.
Seeing how the other Haggis team employed this method, I can see where it can fall apart as well. It has to be clearly defined and appropriate. It also needs to be adhered to. When a team changes direction with a project mid-development, it becomes very difficult for everyone to continue to be on the same task. The results may vary, and when all the parts are brought together, may not work as expected.