What makes the your team so important? And what is the backlog?

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!

Citations:

Backlog Pyramid [Image]. (2012). Retrieved Sepetember 21, 2014,

from: https://www.scrumalliance.org/system/resource_files/0000/4009/Give_life_to_your_product_backlog1-1.jpg

(Primary)

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

(Secondary)

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

What is Agile and what are user stories?

(Agile, 2012)

At first glance, Agile is a methodology in which a costumer specifies requirements and the development team creates these requirements in numerous iterative cycles. Between each iteration the team and costumer meet to evaluate a tangible product and determine whether or not changes need to be made to the requirements.

A key feature of the Agile methodology is the ability of the development team to work closely with the customer. Agile facilitates this close interaction via “user stories.” Agile utilizes user stories in order to envision a feature or requirement of a product from the point of view of the costumer, user stories hone in on the customer’s requirements rather than attempting to nail down every detail. The tiny details of how a requirement functions are susceptible to a great deal of change as the costumer sees this system start to come to life, Agile is designed to handle this change. As Laurie Williams, head of a Software Engineering Research group at NCSU, points out: the costumer prioritizes a number of these user stories to be the target of a release plan and the team then begins the process of iterating through development cycles, or Sprints as they are formally known.

Sprints are another key feature of Agile. Dividing up the development process into pieces, based on the priority of user stories, gives the team and the customer opportunities throughout the project to re-evaluate any and all aspects of the software in order to determine if the user stories and/or release plan need to be modified. Between the planned Sprints the team and the customer can meet and evaluate the current state of the product. Based on this evaluation, the costumer and team can take a number of actions such as modifying, adding, or re-prioritizing requirements. According to Williams, this ability to deliver function software and prioritizing them is credited as being the largest success factor when developing software with the Agile methodology.

(Agile Method, 2013)

In a sequential development approach the development teams only have one chance to accomplish each goal, sequential methodologies work under the assumption that all software requirements can be foreseen at the start. This is what gives Agile an edge: the methodology is designed with the intent of creating functional, but not necessarily ready-to-ship, products at the end of each Sprint so that the team and costumer can meet and re-evaluate the needs of the product based on tangible software rather than theoretical ideas. At the start of a project, the costumer could have a reasonable idea of what they want out of the product. However, as software developers, we know all too well that the initial vision of a software product can crumble in a moment’s notice due to an unforeseen detail and that is why the Agile methodology exists; to provide a flexible system that can deal with change and keep the project on track.

 

Citations:

Agile[Image]. (2012). Retrieved Sepetember 14, 2014, from: http://andydowson.blog.com/2012/10/05/agile-methodology/

Agile Method[Image]. (2013). Retrieved Sepetember 14, 2014, from: http://www.thinkinc.com/blog/squiggles-and-diamonds-and-sprints-how-interdisciplinary-teams-visualize-design-process/

(Secondary)

Chow, T., & Cao, D. (2007). A Survey Study Of Critical Success Factors In Agile Software Projects. Journal of Systems and Software, 81, 961-971. Retrieved September 15, 2014, from http://www.ccunix.ccu.edu.tw/~kcchen/PM/Presentations/2012.05.25/Team4.pdf

(Primary)

Williams, L., & Cockburn, A. (2003). Agile software development: It’s about feedback and change. Computer, 36(6), 39-43. (2003, June). Retrieved September 15, 2014, from http://www.computer.org/csdl/mags/co/2003/06/r6039.html