Work Together To Be An Agile Team

The principle we cover in this episode is short but powerful.  It is also one that goes to the heart of defining an Agile team.  We do not focus on the technical staff and developers.  There also needs to be an inclusion of the business people.  Therefore, development in a vacuum is not valid.  Regular communication with the customer or their representatives is essential.

Business people and developers must work together daily throughout the project.

The Agile Team

Software development has progressed to where subject matter experts and business analysts are a typical piece of the puzzle.  That has not always been the case.  Thus, it is worth looking at how defining the team as we do today is beneficial to building a solution.

The Agile process often is seen as a technical one.  We started down this path for many years before the business side was pulled into it and educated on how they are needed.  This change has made a positive impact on software success rates.  However, it is hard to quantify the improvement when you have to also factor in the changes to software projects.  Smaller projects have become more prevalent.  Likewise, other Agile principles are being adopted in more projects.

A Quick Turn-Around

We have already talked about the regular delivery of a working product.  One of the primary reasons for this tactic is to provide a way for the customer to give feedback early and often.  When you include representatives on the team, you reduce this feedback loop even more.  There is an on-going discussion of sorts that is created when you work within a group.  There are challenges, solutions, and items that can be mulled over.  These are easy for team members to discuss and delve into.  On the other hand, those outside the team will need to be "brought up to speed."  You will find that the large number of discussions and decisions needed during a project makes it worthwhile to reduce those ramp-up times.

A Different Point Of View

One of the reasons projects failed in the past was missed expectations.  Developers would go into a cube for a while and then come out with a product.  This approach left it open for a developer to drift too far away from the "why" of the project.  This concept is not different from builders using a cornerstone or keystone.  When you do not measure against the foundation on a regular basis, it is easy to get off track.

The Twelve Principles and Overall Manifesto