www u Sell com Agile u Sell Akshay

www. u. Sell. com

Agile @ u. Sell Akshay Singhal May 2014

Structure • Why • What • How History geeks can read more about Winston Royce at http: //en. wikipedia. org/wiki/Winston_Royce and the original paper at http: //www. cs. umd. edu/class/spring 2003/cmsc 838 p/Process/waterfall. pdf

The “Traditional” Approach • In 1970 Dr. Winston W. Royce published a paper titled “Managing The Development of Large Software Systems”, which in later years came to be known as the “Waterfall” paper • He described a process for software development based on his experience on Spacecraft Mission software projects, with suggested additions for further improvements in the process. • His goal was to create a process that leads to success on projects, leading to systems reaching operational state within time and within budget • Over the years, using the innate human ability of selective learning, people adopted the steps described in the paper as a recipe, without understanding the context. History geeks can read more about Winston Royce at http: //en. wikipedia. org/wiki/Winston_Royce and the original paper at http: //www. cs. umd. edu/class/spring 2003/cmsc 838 p/Process/waterfall. pdf

The Relay Race • This approach resembles a Relay Race • To win, each step should execute perfectly and the handoff from one step to the other should be done perfectly • This approach has been used for years now, with varying degrees of success

The New Approach • In 1986 Hirotaka Takeuchi and Ikujiro Nonaka published a paper titled “The New Product Development Game” • They studied companies in the US and Japan which rely on developing new products for success and described a holistic or “rugby” approach “This new emphasis on speed and flexibility calls for a different approach for managing new product development. The traditional sequential or “relay race” approach to product development……may conflict with the goals of maximum speed and flexibility. Instead, a holistic or “rugby” approach—where a team tries to go the distance as a unit, passing the ball back and forth—may better serve today’s competitive requirements. ” Read more about the “New” approach here http: //hbr. org/1986/01/the-new-product-developmentgame/ar/1

The Right Approach for Product Development • The right approach depends on your problem domain • The Cynefin framework was originally developed in 1999 by Dave Snowden. The framework provides a typology of contexts that guides what sort of explanations or solutions might apply. • Using this framework, New Product Development seems to be in the Complex Domain You guessed it, more reading here http: //en. wikipedia. org/wiki/Cynefin

Manifesto for Agile Software Development • In 2001, 17 representatives from Extreme Programming, SCRUM, Adaptive Software Development, Crystal, Feature-Driven Development, Pragmatic Programming etc. met to find common ground “We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan That is, while there is value in the items on the right, we value the items on the left more. ” The whole manifesto and the back story is available at http: //agilemanifesto. org/

Agile Principles Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. Business people and developers must work together daily throughout the project. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

Agile Principles Working software is the primary measure of progress. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. Continuous attention to technical excellence and good design enhances agility. Simplicity--the art of maximizing the amount of work not done--is essential. The best architectures, requirements, and designs emerge from selforganizing teams. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

SCRUM • Jeff Sutherland created the first Scrum team in 1993, and presented the a formalized version at OOPSLA’ 95 with Ken Shwaber • Scrum is a simple, people-centric framework based on agile principles and values. • Scrum is not a standardized process where you methodologically follow a series of sequential steps to success, it’s a framework • Scrum is • Lightweight • Simple to understand • Difficult to master The official definitive description of Scrum is embodied in the Scrum Guide, managed by the creators of Scrum https: //www. scrum. org/Portals/0/Documents/Scrum%20 Guides/2013/Scrum-Guide. pdf#zoom=100

SCRUM Framework All images used in this presentation are available at http: //www. innolution. com/ , from the visual pattern language used in the book Essential Scrum

SCRUM Team • The Scrum team consists of the Product Owner, Development Team and the Scrum Master • Scrum Teams are self-organizing and cross-functional. The team model in Scrum is designed to optimize flexibility, creativity, and productivity

SCRUM Product Owner • The Product Owner is the central point of product leadership. The single authority responsible for deciding which features and functionality to build and the order in which to build them • The Product Owner maintains and communicates a clear vision of what the team is trying to achieve, and is responsible for overall success of the solution being developed • The Product Owner is the sole person responsible for managing the Product Backlog • The Product Owner may represent the desires of a committee, but those wanting to change a Product Backlog item’s priority must address the Product Owner • For the Product Owner to succeed, the entire organization must respect his or her decisions. No one is allowed to tell the Development Team to work from a different set of requirements, and the Development Team isn’t allowed to act on what anyone else says.

SCRUM Development Team • The Development Team consists of professionals who do the work of delivering a potentially releasable Increment of “Done” product at the end of each Sprint • Development Teams are structured and empowered by the organization to organize and manage their own work. The resulting synergy optimizes the Development Team’s overall efficiency and effectiveness • Scrum recognizes no sub-teams in the Development Team, regardless of particular domains that need to be addressed like testing or business analysis; there are no exceptions to this rule • Individual Development Team members may have specialized skills and areas of focus, but accountability belongs to the Development Team as a whole.

SCRUM Scrum Master • The Scrum Master is responsible for ensuring Scrum is understood and enacted in the organization • The Scrum Master is a servant-leader for the Scrum Team. The Scrum Master helps those outside the team understand which of their interactions with the Scrum Team are helpful and which aren’t • The Scrum Master assists the Product Owner find techniques for effective Product Backlog management, helping the team understand the need for clear and concise Backlog Items • The Scrum Master coaches the development team in self organizing and cross functionality and removes impediments to the Development Team’s progress • The Scrum Master practices agility and facilitates Scrum events as requested or needed

SCRUM Activities and Artifacts • Product Backlog • Backlog Grooming • Sprint Planning • Sprint Backlog • Sprint • Daily Scrum • Sprint Review • Sprint Retrospective

SCRUM Product Backlog and Grooming • Product Backlog is an ordered list of items that represent changes / additions that need to be made to the product • Highest value items are at the top • Large items are broken down into smaller pieces • Priorities are changed based on feedback from each release, changing markets etc. • Rinse - repeat

SCRUM Product Backlog and Grooming • Features in the backlog are described as user stories. A User Story has the format As a <type of user>, I want <some goal> so that <some reason> • Stories in the backlog start as an Idea, or an Epic. At this stage the feature is abstract, incomplete and / or not actionable. • Through requirement gathering discussions and grooming, Epics are split into smaller stories that satisfy the definition of “Ready” • All “Ready” stories are then ordered to reflect the value of each story, ensuring the highest value stories are developed first

Definition of “Ready” • For a Story to be “Ready”, following criteria have to be met • The story should reasonably show INVEST characteristics I – Independent / Immediately actionable N – Negotiable V – Valuable to the customer, user or product E – Estimable S – Sized to fit T – Testable • The business implications of the story have been discussed, any impacts to finance, customer care have been addressed • The User Interaction Design is ready (At the very least wireframes covering all interactions of the story should be available) • Any design assets needed for the story have been prepared to a reasonable degree (PSDs for some if not all pages in the Story should be available)

Definition of “Ready” • In case the story includes interactions with a third party API, technical feasibility has been completed, and a testing strategy is in place • Release dependencies have been resolved, to ensure the story is released to production in a sequence that makes business sense • Grooming is a collaborative process

SCRUM Sprints • A Sprint is time-boxed iteration or cycle of up to 1 month • The work completed in each sprint should create something of tangible value to the customer or the user of the product • Sprints have a fixed start and end date, and are usually of the same duration • No goal-altering changes in scope or personnel are allowed during a sprint • A sprint consists of following activities • Sprint Planning • Daily Scrum • Sprint Review

SCRUM Sprint Planning • Work to be done in the Sprint is planned at Sprint Planning • The Scrum Team reviews the product backlog and determines the highest priority items that the team can realistically accomplish in the upcoming Sprint • Work selected to be part of the Sprint is called Sprint Backlog. It contains the stories and tasks needed to be accomplish those stories • For a Story to be allowed to enter the Sprint Backlog, it needs to pass the definition of “Ready”

SCRUM Sprint Execution • After planning, the Development team gets down to the business of getting stories in the sprint backlog “Done”. The scrum team agrees on a definition of “Done”. A story is considered to be complete, only when it satisfies this definition • Each day of the Sprint, ideally at the same time, the Scrum Team hold a timeboxed daily Scrum, where each development team member answers the following questions: • What did I accomplish since the last daily Scrum? • What do I plan to work on by the next daily Scrum? • What are the obstacles or impediments that are preventing me from making progress? • The daily scrum is an inspect-adapt tool for the team to self-organize, it is not an update meeting for higher ups. Through his participation in the meeting, the Product Owner gets visibility into the current state of the sprint • The Development Team does most of the talking, the Product Owner answers questions, and the Scrum Master facilitates

SCRUM Sprint Execution • By the end of the Sprint, all items that are “Done” become part of the shippable increment of the product • Any not done items are carried over to the next sprint for further work

SCRUM Sprint Review and Retrospective • At the end of the Sprint, in Sprint Review, the product increment is reviewed to inspect and adapt the product. The Scrum Team presents the increment to stakeholders, sponsors, customers etc. Their feedback is solicited and used to update the product backlog • After the Review, the Development team meets to conduct a Retrospective. This is another inspect and adapt tool used by the Development Team and Scrum Master to fine tune the development process.

Thank you