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. 


No comments:

Post a Comment