The Extreme Programming methodologies can produce working software in as little as the first week after project analysis and design has begun. It is advantageous to show the software to the customer for immediate feedback. “Through frequent unit testing and interactions with clients, developers continually refine (that is “refactor”) their products into extremely high quality software.” (McCauley, 2001) As the development of these key project pieces are conceived and presented, the developers can learn so much more from the stakeholders about what the core requirements are in the context of a working software model. Any changes that are implemented may become more valuable to the system as a whole.
“XP seeks to solve many of the problems of traditional software development by combining the best practices from the past research and practice of ISD. First, XP aims at employing participatory design by really engaging the business or end users in the IS development process. Second, XP seeks to add flexibility to the development process and to organize the work into small packages with clear deliverables.” (Hikka, 2005)
In the context of the agile methods, Scrum is most often used in tandem with Extreme Programming (XP). Next we will review Scrum’s background and its impact on agile systems analysis. “Scrum is not a process or a technique for building products; rather, it is a framework within which you can employ various processes and techniques. The role of Scrum is to surface the relative efficacy of your development practices so that you can improve upon them while providing a framework within which complex products can be developed.” (Schwaber, 2010)
The Scrum methodology dictates there are three distinct groups or role players. The Product Owner, ScrumMaster and the Team are altogether known as the Scrum Team.
The Product Owner is never more than one individual and has several responsibilities to the Scrum Team. Depending on the size of the project, committees may be formed to advise or influence the individual acting as the Product Owner. However, if other Scrum Team members want to change a product feature they must convince the Product Owner. For a project to be successful, the Product Owner must command the respect for their decisions from everyone in the organization.
The primary responsibility for the Product Owner is to maximize the project return on investment (ROI) by making sure the right features make it into the product backlog for development. They are also tasked with accepting the software at the end of each iteration and then preparing the Team for the next round of features from the product backlog. In addition, they manage the release plan and are responsible for the overall quality of the project.
The ScrumMaster’s goal is to take any necessary action to make sure that the Team and the Product Owner are successful. “The ScrumMaster is not the manager of the Team or a project manager; instead, the ScrumMaster serves the Team, protects them from outside interference, and educates and guides the Product Owner and the Team in the skillful use of Scrum.” (Deemer, 2010) The ScrumMaster reinforces the Scrum practices to everyone involved in the project including the Product Owner as well as management staff. They also lead the group through the difficult changes often required to have a successful agile development project. The Scrum process divulges many impediments and threats to the effectiveness of the Team and Product Owner, and it is vital that the ScrumMaster work diligently to resolve the issues before they become impassable. If the ScrumMaster does not handle this task well, the Team and Product Owner will find it difficult to have a successful project.
"They are from my son. He's a Business Analyst."
"Oh... What does he do?"
"I have no idea!"