Applying the Agile Manifesto to your Projects

October 27, 2014 Adam D'Angelo 0 Comment

Agile Development has become a popular methodology to apply to software projects, but to really take advantage of all Agile has to offer, it is helpful to be reminded of the problems the founders of Agile were trying to resolve and how this applies to our projects. The manifesto states the following values:

  • Individuals and interactions over processes and tools
  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.The following scenarios are real-life examples of how applying the Agile manifesto can help build better software.

Individuals and interactions over processes and toolsDoes anyone know where the requirements analyst sits?

Arrows and people

In Agile development, it is important for the team to interact through concepts like co-location and pair programming. The ability to constantly share ideas, communicate with fewer boundaries, and collaborate constantly will allow the team to create better software. Some of us have become used to remote teams, but with Agile, we need the team to work from a central location. The difference between being able to speak with someone face-to-face to discuss a problem versus over instant message, email, or the phone is vast. The conversations that your team will have and the ideas they’ll share will drive a more cohesive vision of the software and a better quality product.

One effective approach to Agile that I took part in involved the team sitting at a series of long tables without partitions in a large open room. Because my team members were so close and accessible, I could easily ask others questions as soon as I had them. On occasion, our conversations would be overhead by other developers, and frequently they would walk over to join the conversation to share their assumptions. This setup allowed us to quickly and easily engage in ad-hoc meetings, sometimes with half a dozen or more individuals, to discuss the problems, create new assumptions, resolve issues, and move forward knowing that essential personnel were all on the same page. Though I have been part of successful projects involving a remote team, co-location and the interactions fostered in an open environment allow Agile teams to quickly identify and resolve the problems that frequently arise during the development of complex software systems.

Working software over comprehensive documentationI have never met a developer who enjoys writing documentation.

In Waterfall, there is a strong emphasis on creating documentation before development. These types of documents can include requirements traceability matrices, design documents, and others. Few people read these documents, they are burdensome to write, and rarely allow members of the development team or the stakeholders to better understand what was being developed.

Often required by clients, documentation is important. Rather than unwieldy documentation, however, a team can find ways to reduce or eliminate bulky material and introduce lighter more valuable documents for the client through Agile. Development teams should allow documentation to grow to its project needs to continue to develop and change throughout the process. Your documentation should be living and growing alongside the software.

Customer collaboration over contract negotiationJust tell us what the system should do already!

Even on some of the smallest projects I have worked on, the requirements have changed during development. These changes are not usually because of a whim the customer had (sometimes it is), but rather because as the project progressed certain problems require a greater level of clarification. It is difficult to capture the full scope of requirements before development begins on a project, so involving the customer to collaborate with the team throughout development is critical to success. In the co-located team environment I spoke about earlier, there were business owners sitting at the tables with our technical team. They were there so that if a business process needed clarification beyond what the requirements team could answer, these stakeholder representatives could quickly answer our questions. Having the customer there with our team to answer questions or expand on details allowed us to develop software with a greater understanding of the underlying business processes driving the creation of the system better than any static requirements document ever could.

Responding to change over following a planLook at this beautiful Microsoft Project schedule I made. We’re guaranteed to hit our release milestone.

Over the course of a project, requirements become more defined, priorities shift, and schedules becomes another outdated artifact. In Agile, we try to focus on quick responses to change through continuous development. The focus is on working software being delivered frequently at the end of every Sprint, and this working software is the measure of success. Circumstances on the project will change over time, and our team’s ability to adapt to change will eventually be why we are successful in delivering quality software our customer can use. This principal is more successful when the three other principals are successfully implemented.


This is the first post in a series where Adam D’Angelo–one of Dev Technology’s Project Managers and an experienced developer–shares his experience using Agile development over the years to continue the conversation on how we can use Agile to build better software. View the full series here.