Monday, September 22, 2014


Working of SCRUM


Scrum is an iterative and incremental framework for projects and product or application development. This is followed by many software development companies in India. It structures and manages development in cycles of work called Sprints. These iterations that are referred as sprints; are 1-4 weeks in length and take place one after the other sequentially. The Sprints are of fixed duration. They end on a specific date whether the work has been completed or not, and they are never extended. On top this, sprints are time boxed. 

At the beginning of each Sprint, a cross-functional team selects items (customer requirements or sprint scope) from a prioritized list. They commit and estimate to complete the items by the end of the Sprint. During the Sprint, the selected items or requirements do not change. Every day the team gathers briefly to report to each other on progress and update simple charts that orient them to the work remaining. At the end of the Sprint, the team reviews the Sprint with stakeholders and presents what they have built. People obtain feedback and inputs that can be incorporated in the next Sprint. 

Scrum puts emphasis on working product at the end of the Sprint that is really “complete” or “done”; in the case of software or IT product, this means code that is integrated, fully tested and potentially shippable or in position to be delivered. A major theme in Scrum is “inspect and adapt.” Since development inevitably involves innovation, learning, and surprises, Scrum emphasizes and focuses on taking a short step of development, inspecting both the resulting product and the efficacy of current practices, and thus adapting the product goals and process practices. Repeat forever (Jeff Sutherland, 2008).


software development process

Figure 6 Working of Scrum
Source: (Schwaber & Sutherland, 2010)

Tuesday, September 16, 2014

CRUX of SCRUM


Enterprise customers want a framework that is structured enough to learn on when development is chaotic, but also based on agile principles. After all, the Manifesto for Agile Software Development outlines vital principles, but it doesn't provide a framework for actually completing work. Many organizations have attempted to integrate popular management frameworks such as ITIL, Cobit, and CMMI with agile principles in order to introduce agile concepts in a less disruptive way, but the result is often waterfall. Software development companies in India have started following SCRUM and it is trending.

There is an assumption that if each individual contributor is the best, the end product will also be the best. On the flip side, some general agilist believe that churning out extremely high quality product increments will guarantee success because a high quality product is all they need. Whether a company is extremely traditional or extremely agile, it still relies on the idea that high quality parts inevitably create a high quality end product.

Scrum asks that Product Owners (POs) articulate, as specifically as possible, their vision of the product to development teams. There is an underlying assumption that the PO represents the interests of the organization at large because he or she is solely responsible for determining what direction development output will take. The PO is also responsible for prioritizing requirements that result in increments of potentially releasable product at the end of every sprint. Collectively, the PO and team members are responsible for authoring requirements that reflect both the business interests and technical interests of the organization. The team is responsible for executing on the requirements or stories to yield the highest quality product possible, while communicating concerns about quality to the PO. The tension between what the business wants and what the team can do is what makes Scrum such an effective vehicle for high quality production.

Agile engineering without Scrum's structured framework can be chaotic and tends to succeed for small organizations, in which business domain knowledge can be readily shared. Agile engineering, when coupled with the framework of traditional management processes, compromises agile’s values, forcing teams into a system that requires functional divisions and big, speculative planning up front (Danube, 2008). Agile engineering with Scrum allows agile values to spread across the organization, imbuing business practices with an unrelenting focus on people, quality, and output, rather than input-driven decision making.