Volumes were spoken about the features that make agile what it is in my previous entry. In this entry I will explore two of these features more in-depth; the team and the backlog.
Let’s start with the team, the true muscle of the project. Agile has lots of rules and processes for promoting productivity and camaraderie in a team. However, agile can only do so much for the individuals in your team. It is ultimately the team that makes the product, not agile nor an individual in the team. Alistair Cockburn and Jim Highsmith found in their study that where developers lacking skill and experience fail, a team of developers working together will fare far better than the former. They say that this is due to things like good communication and interaction. With that in mind, one must bring people together who can communicate with each other and interact well with each other in order to fully utilize the benefits of agile, it cannot be implemented into just any team and expected to improve their throughput. Although that doesn’t mean agile isn’t flexible enough be compatible with different teams; Cockburn and Highsmith also point out that agile is designed to capitalize on the unique strengths of the individuals on the team where other processes standardize the process to each team.
The team’s morale is another important factor identified by Cockburn and Highsmith; they cited a study that concluded agile methodologies score higher than others in terms of employee morale and deliver an even better product. The promotion of close interaction, daily scrum meetings, and meetings with the clients are all factors that bring the parties involved on the project closer together which, not only improves communication, but also improves the team morale by having them know each other on a more personal level.
The next major feature I want to talk about is the backlog. The backlog is essentially a prioritized to-do list usually populated by user stories, features to implement, bugs to fix, or things to change. The nice thing about the backlog is that, only a select few high priority items are selected to be developed in each sprint and they’re locked in. Ideally, so that the client cannot reach into the backlog mid-sprint and tell you they want something else implemented. This isn’t to say that the client can’t make changes to work that has been done, they just have to wait until the current goal has been finished. That way the developers don’t get reallocated or sidetracked mid-development from some feature and the client is more likely to have a tangible product to assess at the end of the sprint. Yet another part of agile geared towards keeping everyone happy and promoting teamwork!
Backlog Pyramid [Image]. (2012). Retrieved Sepetember 21, 2014,
Cockburn, A., & Highsmith, J. (2001). Agile software development, the people factor. Computer, 34(11), 131-133.
Retrieved September 21, 2014 from http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=963450
Keith, C. (2006). Agile Methodology in Game Development: Year 3 [Powerpoint slides]. Retrieved September 21,
2014 from: http://www.clintonkeith.com/resources/GDC2006-AgileGameDevelopmentYear3.pdf
Team[Image]. (2012). Retrieved Sepetember 21, 2014, from: http://www.warrioresports.com/Images/team.jpg