All sports buffs know how important a formation is, to win the game of Soccer. When a formation brings success to Rugby, why not try it for software development? For every team or in software industry terms, for every customer’s need, there is a need for a customized formation. Just like in the game of Rugby, the need for a formation that is highly comfortable with rotating pieces, one that is ready to handle all the quick moves formed the basis for inventing Agile’s Scrum. As we all know, Scrum was defined as holistic or Rugby approach by Hirotaka Takeuchi and Ikujiro Nonaka in the “New product development game”. Later in 1995, Jeff Sutherland and Ken Schwaber of Easel corp. merged their experiences and industry best practices into what is now known as the Scrum methodology. The principles of Scrum not only give Rugby but also software development teams the chance to huddle around and plan for frequent deliveries. Scrum also wraps several existing engineering practices and development methods. Heading on with Scrum and its global rollout in both large and small software companies, an organization always looks for software cycles that provide visibility into early error detection, a delivery method for frequent releases and a real good solution that actually fits their customers. The one shot solution for all of these business needs comes with Scrum and in the near future, Scrum will grab the trust of stake holders by its empirical process control.
With several applications from different genres invading the market and ever changing technologies and techniques, methodologies have to take large strides to keep up to them. Traditional models like waterfall and v-models seems to be no longer in the picture. Agile and its processes have the limelight now. It is sailing past the others and, in particular, Scrum is what is trending in the software development lifecycle. Scrum and its formations have attracted several software development organizations and it has lived up to its origin proving that formation is what it is all about.
Software companies that want to boost their operating efficiency need to advance and streamline their software development practices. Agile has helped leading industry players overcome dependencies and steep overheads. This has helped to meet industry regulations providing an opportunity to improve collaboration and enhance user experience.
Supported by a case study, this paper helps measure speed, performance, quality, etc. across some of the popular methods in Agile such as Scrum, Kanban and XP and it illustrates how Scrum is better in its own way therefore ultimately leading to the most important aspect – Focused Releases – thereby winning over also in cost.
SPEED OF DEVELOPMENT
When it comes to development, Scrum, XP and Kanban are on the same lane. Scrum plans and assigns prioritized backlog to releases and teams, using a simple drag- and-drop whiteboard planning environment. Scrum is based on having a fixed iteration cycle. You can choose the length of the iteration, but the general idea is to keep the same length of iteration over a period of time and thereby establish a cadence. Beginning of Iteration: An iteration plan is created, the team pulls out a specific number of items from the product backlog based on the product owner’s priorities and on how much the team thinks it can complete. During Iteration: Team focuses on completing the items they committed to. End of Iteration: Team demonstrates working code to the relevant stakeholders, ideally this code should be potentially shippable (i.e. tested and ready to go). The team then does a retrospective to discuss and improve their process. So Scrum iteration is one single cadence combining three different activities: planning, process improvement, and (ideally) release. Because the length of the iteration cannot be altered, with Scrum one knows how much time he has exactly at hand (we have a 30 day cycle which will not be altered) and the Scrum master carefully prioritizing the story points, a majority (about 75% – 37 story points) of them in the backlog will get into the iteration grouped based on modules.
In Scrum the items for a sprint are chosen by the Scrum master and he controls the product development and manages the tram. The Scrum master knows the output of his product therefore there wouldn’t be a problem in selecting the right item at the right time. Scrum also closely tracks progress by making use of its board or wall as it is called, keeping everyone on the same page. This not just helps to see where we are but also helps anticipate risk.
In Scrum, the sprint backlog is just one part of the picture – the part that shows what the team is doing during the current sprint. The other part is the product backlog – the list of things that the product owner wants to have done in future sprints. The product owner gains an insight into the sprint backlog but he cannot alter it when already made part of a sprint. Here the Scrum master has complete control on what should and should not get into a sprint. Referring back to our cases study the 4 modules picked – Order Entry, Pricing, License, Report (75% of the backlog) – are made part of the committed list. Once this is picked, there is no change in the list. It moves from Committed to Ongoing to Done.
Control in Scrum vs. XP
The main disadvantage here in XP is the ownership of selecting items from backlog is in the developers’ control. This practice may lead to trivial selection of product backlog and customer may not get the desired product at the right time.
XP does not have sets of specific development process that gives importance to defined roles, conducts frequent meetings and monitors the progress constantly. While poor communication between the team is one of the main reasons for poor outputs in XP, good communication is stressed between all the members but this is very hard to achieve because there is no set role specified.
Several software development companies and organizations have adopted Scrum as the preferred method to produce functioning, deliverable products in an environment where system requirements are not fully defined at the beginning of the development process. Scrum achieves this flexibility and adaptability through a well-defined development process designed to recognize and respond to changes in the environment. Practicing Scrum can therefore assure confident delivery taking quality to the next level.