Nov 1st, 2008 | 1 Comment

Few days back I wrote on Agile Development, but there are some myths associated with it,

Myth one: Agile means you never have to write documentation. Both sides were briefly covered by the panel. The audience was asked and 79% said it is false. However, it is documentation at can be done at the right time when the system is ready. There is less editing and revisions.

Myth Two: Agile is more disciplined than other methods. Again, both sides were briefly covered. The audience was asked. 43% said false and 41% said true. The panel believes that Agile is more disciplined but it is bottom up discipline rather than imposed discipline. There is more feedback and engagement. This is a common, and counter intuitive, aspect of enterprise 2.0. With transparency you get accountability and more discipline. It results in greater productivity. I have seen many examples of the switch to more transparent project management leading to significant increases in productivity.

Myth Three: Agile means I can change my mind whenever I want to. Both sides were briefly argued. The audience was asked and 79% said it is false. There needs to be some stability. Within the sprints in Agile development, change needs to be on hold. Then there can be times for change.

Myth Four: Agile works on all sizes of projects. Both sides were debated. The audience was asked and 59% said true. You need to recognize that there are greater needs for large projects for them to succeed. The key differential is that you can keep Agile teams small and link together these teams to handle size. One large project had 27 teams successfully linked together.

Myth Five: Agile means teams cannot be controlled by management. Both sides were debated. The audience was asked and 72% said false. Agile is about control through planning, monitoring, and adapting. Management is about getting more done by removing obstacles. There is a different style of management.

Myth Six: Agile requires detailed architecture and design. Both sides were briefly debated. The audience was asked and 55% said true.  There is less architecture and design. You need architecture but it is not the driver. Architecture needs to come out from working through the problems and should not be a guiding factor. Let architecture emerge and be open to change.

Myth Seven: Agile is just the latest hype. Both sides were debated. The audience was asked and 62% said false.  It has been around for a while. There are demonstrated successes. Most employees like it and there are productivity improvements.

Myth Eight: Agile works on complex projects. After the opening debate, the audience was asked and 71% said true. However, complex projects do require more management, even with Agile.

Myth Nine: Agile teams do not work hard, they just play football. The debate got more humorous here The audience was asked and 75% said false.  There is balance of work and fun required. Focus is key. However, they did say that Agile developers are more likely to have fun outside work and sleep better at night as there less worries about errors.

Myth Ten: Agile is only used for mission critical projects. After the opening debate, the audience was asked and 95% said false. It works for all types of projects.

Written by Ajay Matharu

November 1st, 2008 at 10:28 am

Oct 28th, 2008 | 5 Comments

Agile software development refers to a group of software development methodologies that are based on similar principles. Agile methodologies generally promote: A project management process that encourages frequent inspection and adaptation; a leadership philosophy that encourages team work, self-organization and accountability; a set of engineering best practices that allow for rapid delivery of high-quality software; and a business approach that aligns development with customer needs and company goals.

There are many specific agile development methods. Most promote development iterations, teamwork, collaboration, and process adaptability throughout the life-cycle of the project.

Agile chooses to do things in small increments with minimal planning, rather than long-term planning. Iterations are short time frames (known as ‘timeboxes’) which typically lasts from one to four weeks. Each iteration is worked on by a team through a full software development cycle, including planning, requirements analysis, design, coding, unit testing, and acceptance testing when a working product is demonstrated to stakeholders. This helps to minimize the overall risk, and allows the project to adapt to changes more quickly. Documentation is produced as required by stakeholders. An iteration may not add enough functionality to warrant releasing the product to market, but the goal is to have an available release (with minimal bugs) at the end of each iteration. Multiple iterations may be required to release a product or new features.

Some principles of Agile Development

  • Customer satisfaction by rapid, continuous delivery of useful software
  • Working software is delivered frequently (weeks rather than months)
  • Working software is the principal measure of progress
  • Even late changes in requirements are welcomed
  • Close, daily cooperation between business people and developers
  • Face-to-face conversation is the best form of communication (Co-location)
  • Projects are built around motivated individuals, who should be trusted
  • Continuous attention to technical excellence and good design
  • Simplicity
  • Self-organizing teams
  • Regular adaptation to changing circumstances

You can get more information on Agile Development from,

http://en.wikipedia.org/wiki/Agile_software_development and http://msdn.microsoft.com/en-us/architecture/bb404166.aspx

Written by Ajay Matharu

October 28th, 2008 at 3:49 pm