Agile product development and management

  • 853 views
Uploaded on

This presentation covers Scrum for developers, project managers, product managers. Scrum made simple ! Highly appreciate your feedback.

This presentation covers Scrum for developers, project managers, product managers. Scrum made simple ! Highly appreciate your feedback.

More in: Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
  • Presentation is simply superb!
    This explains all in one shot and this is really helping me in implementing AGILE with no knowledge.

    Thanks for creating beautiful ones like this
    Are you sure you want to
    Your message goes here
    Be the first to like this
No Downloads

Views

Total Views
853
On Slideshare
0
From Embeds
0
Number of Embeds
1

Actions

Shares
Downloads
31
Comments
1
Likes
0

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. Agile Product Management & Development in a nut shell ―Where common sense prevails, so shall Agile‖ Ashwinee Kumar 6 Jan 20124/19/2012 * I have used ideas, & content from other resources in this presentation. 1
  • 2. Agenda• Agile Manifesto• Types of Agile• Best practices of Agile• Scrum • Documentation • Sprint details • User Stories • Planning & Estimations • Metrics • Product Backlog• Appendix • Best Practices of Distributed Scrum • Non-functional Requirements • Product Requirement Document • Product Vision • Benefits to Marketing & Sales4/19/2012 2
  • 3. Realities of Projects• Requirements/scope changes frequently due to factors beyond our control• Defects are expensive – Defect found during test phase could cost 10–15 times more than if found and fixed during implementation phase. – Fixing defects in the field can cost 10–100 times more than fixing the same defect in the coding phase• 20% of your features will give 80% of a product’s value• Artifacts such as Detailed design, Requirement document do not add value to the product• Features not meeting customer expectation leaves him dissatisfied, irrespective of what is in the contract4/19/2012 3
  • 4. Agile Manifesto• Individuals and interactions over processes and tools• Evolving - Working software over comprehensive documentation• Collaborative - Customer collaboration over contract negotiation• Adaptive - Responding to change over following a plan4/19/2012 4
  • 5. Types of Agile• Lean Software Development – evolved from the ideas of lean manufacturing in automotive industry – includes thoughts on eliminating waste, adding customer value, and empowering workers.• The Agile Unified Process combines a process with tools and is a derivate of Rational’s Unified Process.• Test Driven Development emphasizes the definition of test cases even prior to the actual implementation of the code.• Extreme Programming is a toolbox of engineering practices like pair programming, or continuous integration• Scrum is an extremely efficient and streamlined process of managing and tracking teams.4/19/2012 5
  • 6. Best Practices of Agile• Search for the root cause of failure• Focus on the customer value and avoid any waste• Decentralize responsibility and accountability• Focus on teaming and collaboration rather than splitting work• Continuous improvement (Kaizen)• Flexibility to react to changing customer requirements• Standardization of processes• Planning and anticipatory thinking• Simple and pragmatic tools4/19/2012 6
  • 7. Scrum• Roles - Product owner (play customer), team (implement), scrum master (manage project)• Teams – Cross functional – entrust individual teams with entire end-to-end tasks• Documents - product backlog, sprint backlog, sprint result, stories, test cases, user documentation• Sprints are broken into stories, stories are broken into tasks• Large, loosely defined stories are known as epics. Epics are broken into stories in product backlog• Tasks can be bug fixes, Features are user stories• Sprint size - 2 weeks• Meetings - Sprint planning, daily scrum meeting, sprint review, scrum of scrum• Tracking – Burn down chart• A task or a user story is only counted as complete if it is completely done – including automated test cases, all tests executed, all documentation done, and all remaining defects fixed4/19/2012 7
  • 8. Documentation in Scrum• Backlog lists and team charters will provide a prioritized list of use cases that are to be delivered.• Continuously updated burn down charts provide data to assess the project status and help to uncover risks and delays.• Defect documentation keeps a record of bugs that are being resolved• Design documents share architectural decisions and technical details with a larger community and are an excellent source of information for those who will use the resulting implementation.• Coding guidelines are useful to achieve a common programming model. They will help to write consistent code that considers aspects like accessibility, translation, performance, etc.• Specifications describe programming interfaces and are needed if other teams will re- use code provided as a common component.• Test scenarios describe test cases to be executed.• Checklists include a lot of know-how that was gained in the past. It absolutely makes sense to leverage them to make sure that nothing has been forgotten.4/19/2012 8
  • 9. Sprint/IterationIteration 0 Iteration 2 … Iteration n •Continuous iterative and adaptive planning •Continuous designIteration Test 1 Iteration Test 2 … Iteration Test n •Continuous testing (automated) •Continuous listening Function and System Verification •Continuous conversation and collaboration •Continuous demos •Continuous consumption of our own output Translation Test •Continuous status •Continuous feedback Final Functional & •Continuous learning System Regression •Continuous progress Performance Testing • The idea of iterations is to create an even and steady rhythm of progress in a sustainable, constant pace – repetitively and predictably • Development proceeds by designing and implementing small chunks of code, which are immediately tested and continuously integrated into the code base, without lag time in between • All teams and their daily work are synchronized in the common schedule of iterations – the heartbeat of the project • Sprint Length – thirty days for a "traditional" software product – two weeks for a fast moving web service – weekly iterations might be appropriate for an early stage product, or for delivering rapid fixes on a project that has a frustrated customer base and/or is in jeopardy of being cancelled. – iteration cycles longer than four weeks risk behaving like traditional software projects. 4/19/2012 9
  • 10. Sprint/Iteration• Company Vision -> Product Visions -> Product Strategy-> Release Plan -> Product Requirement Document (PRDs) -> Product Backlog -> Iteration Backlog -> Epic -> User Stories -> Tasks• As the goal is to have a customer-ready deliverable at the end of each iteration, it is paramount to have all the user stories of an iteration completed at the end of that iteration• Get together with the project sponsor and create a joint vision for the project• Write the resulting requirements into user stories that should on the one hand be complete but also as simple as possible• Acceptance test criteria should be defined for each story before the sprint to allow a clean sprint exit• The Sprint Fest is organized as an event in which all development teams give a demo of the use case they have implemented in the most recent iteration – Participants - entire team, including testers, product management, executive management, and -if possible- customers as well – Respective stakeholders get first hand information on the project progress4/20/2012 10
  • 11. User Stories• Story has to be INVEST – Independent - Avoid dependencies between stories – Negotiable - They are not a command. Open to alternatives that might work better and/or require less effort – Valuable—Always demonstrate why the story is worth implementing – Estimable—The story should be small enough and contain enough detail that the development team can estimate the effort. – Small—A story should represent between a half-day and two weeks. Should fit into an iteration – Testable—Acceptance criteria for the story should be able to be tested• Each user story is now broken into tasks. These tasks are sized(and estimated) and assigned to team members• MMF (Minimal Marketable Feature) is a good way to start the story. MMF is normally an epic.• Non-functional requirements (QOS) are written on the User Story as a constraint – PAPRMIC - Performance, Accuracy, Portability, Reusability, Maintainability, Interoperability, Capacity Sample User Story Sample NFR As an end user, I would like to calculate the value my As a customer, Id like to be able to use the browser of my stocks based on the real-time value at the Stock Exchange choice so I dont have to download a new browser. so I can see the accumulated loss or gain. Sample Constraint Sample Tasks The application shall run on Internet Explorer 7.x and - Write test cases higher, Firefox 3.x and higher, and Safari 4.x and higher. - Integrate into test framework - Get all stocks - Get the current value - Get exchange rates - Calculate value - Handle exceptions4/19/2012 11
  • 12. User Story Estimation – Ideal Days• Ideal time is: – The time it takes you to completely finish the user story or tasks. – The time required to complete design, coding, automated test cases, testing, and documentation and everything else the task requires. – The time needed for just doing the work, without breaks, meetings, emails, other parallel activities, colleagues asking you for advice, and all the other things that usually stop you from completing the task.• Ways to estimate – Planning Poker – Estimate by Analogy4/19/2012 12
  • 13. Metrics for Scrum Projects• In a project, there should be a clear separation between Defects: Something that prevents the product from functioning as specified. Features: New functionality that is either in addition to what the product provides so far or a change of behavior. Refactoring needs: The program works as designed, but there are things that the team wants to improve, for example to improve the maintainability or to remove unused code.4/19/2012 13
  • 14. Product Backlog Repriori Add tize High priority, high level of Remove detail Low priority, low level of detail Pick the highest priority work item4/20/2012 14
  • 15. Adopting Agile Waterfall Model Development Defect Backlog Effort •Huge efforts in development during first half •Huge efforts in testing and defect fixing during second half •Large number of open defects towards the end Open Defects •No scope for significant scope changes during second half Testing EffortProject Start Project End Agile Model •Development, testing, defect fixing efforts evenly distributed Development Effort •Small number of open defects towards the end Defect Backlog •Scope changes possible any time Testing EffortProject Start Project End 4/20/2012 15
  • 16. Pitfalls• If team tries to deliver more in haste in an iteration, they can only deliver less in the next iteration due to the bugs introduced in this iteration• Agile does not mean NO documentation• Rushing into implementation before stable design• Bug fixing is non-productive. Customers pay us for adding feature not for fixing bugs. Minimizing bugs maximizes time for features• Jumping to a new functionality without resolving pending quality issues4/20/2012 16
  • 17. Nitty-gritty of Sprint• Throughout the release, the teams maintain their team charter document, which includes the prioritized product backlog with all use cases they tentatively want to address in the foreseeable future.• Team elaborate a rough high-level design outlining all items of their focus area .• Only the current iteration is being precisely planned, confirmed, and detailed into an iteration backlog, which lists the low-level use case descriptions.• Iterations are time-boxed. They have a defined start and end date. Usually, all teams operate on the same iteration schedule.• The content of each iteration is defined at the beginning of each iteration. A team picks the top use cases from the prioritized product backlog in their team charter and starts designing and coding those items.• Large user stories are broken in to into smaller, digestible chunks to ensure that a use case can be implemented within an iteration.• The teams continuously integrate their code throughout the iteration, documentation, and automated test cases into a common code stream. There are daily builds of the entire product. Continuous integration with immediate testing is done to avoid destabilization.• Ensuring the stability of each build is everyone’s responsibility. Disruptive changes must be avoided by all means. Every single developer will plan and perform thorough unit testing and automated regression for the code he is delivering.• It is a mandate to focus on any open issues and bugs first, before proceeding with the development of new functionality• Functional verification testing is part of the iteration within the team. Only tested and properly working use cases are accepted as a delivered achievement.• Performance and documentation are further aspects to be covered within the iteration.• An ―Sprint Fest‖ is held at the end of each iteration• Each iteration will be signed-off by the stakeholders, confirming that the delivered use cases are working properly4/19/2012 17
  • 18. Appendix A – Best Practices of Distributed Scrum teams• Each site conducts a local standup in their morning to address immediate issues.• All teams join a daily teleconference standup, ideally scheduled at a common work time for all. A video-conference standup is better.• Each location has a Scrum Master Proxy and a Product Owner Proxy. The proxies synch with their counterparts regularly and learn to guide their local teams and keep them productive.• Team members visit other sites to deepen relationships and information exchange.• VOIP and webcams can go along way to overcoming cultural awkwardness and maintaining a co- located feel• Distributed teams also need to implement a collaboration tool to function as a virtual task board. Eg. Rally Software, VersionOne, Xplanner.org, and Atlassian Jira with the GreenHopper plugin• The Scrum of Scrums is a meeting of Scrum Masters (or other appropriate leads) from all the product and shared resource teams. Unlike the Daily Scrum that meets every day, the Scrum of Scrums is generally held between one and three times a week.4/19/2012 18
  • 19. Appendix B – Non-functional Requirement (PAPRMIC)• Functional Requirement = "what the system will do"• Non Functional Requirement = "how well the system will do it" 1. Performance: Ninety percent of product searches will return results in less than three seconds. 2. Accuracy: The software will dynamically generate and adjust reorder points to provide in stock levels of 98 percent for all standard products while maintaining less than fourteen days inventory on hand for 95 percent of all standard products. 3. Portability: The software shall be designed to be ported to Android. 4. Reusability: The graphics rendering engine will be reusable by our other applications. 5. Maintainability: Automated unit tests must be written for all new code and be run after each build. 6. Interoperability: All documents shall be stored in XML. 7. Capacity: The data mart must be able to store one hundred and eighty million per month for five years) and support the real-time analytics tools.4/19/2012 19
  • 20. Appendix C –PRD1. Project goals—tie project to product strategy with measurable goals, such as market share, revenue, customer satisfaction, productivity improvement, time to deployment, etc.2. Timeline—target dates for key milestones.3. Product Background and scope of release—describe whether this is a new product, next release, or an extension of an existing product, and if it will complement or replace any existing products.4. User interface constraint—any standards to which the user interface must comply5. Compatibility constraint—any external and internal interfaces and backwards compatibility that must be developed or maintained and may impact on other systems.6. Scalability—system quality defining user, data volume, or transaction levels.7. Usability and learnability—system quality definition for ease of use or ease of learning the system for a defined persona.8. Performance—system quality defining performance goals.9. Documentation—any documents that must be created, consumer of documents, and intended use.10. Security—any security issues that must be accommodated and standards that must be observed.11. Regulatory—any regulation that must be supported.12. Manageability—any requirements for customer support, account management, or operations to manage the system and support customers.13. Reporting—any new metrics that need to be captured and reported against.14. International—any issues that must be accommodated to support international markets.15. Assumptions—any assumption that could impact the project.16. Open Issues—any unresolved issues that could impact the project.4/19/2012 20
  • 21. Appendix D - Product Vision• Company vision might be: "Helping digital photography enthusiasts fulfill their passion.―• The product vision, which might be considered the corporate mission (i.e., how we will fulfill the corporate vision) might be: "The most comprehensive selection of equipment combined with the right advice to guide purchase for the digital photography enthusiast.―• This statement says a lot. – First, we are going to carry a lot of products; – second, we are targeting hobbyists; – third, we will be providing advice that goes beyond the typical product catalog.• As this translates into product trade-offs, we will emphasize making products easy to find and providing guidance to help customers find the right product for their skill levels and interests.• This is very different from – choosing to be the low cost leader, – choosing to serve the professional photography market, – choosing to take a more paternalistic approach by carrying a limited set of "best in class" products.4/19/2012 21
  • 22. Appendix E – Impact of Agile on Marketing & Sales• Increased revenue, as a result of capturing more customers sooner• Lower costs by not over-building the product (ultimately you will realize more value for less development effort);• Better resource and prioritization decisions due to faster feedback cycles.4/19/2012 22
  • 23. Thank You4/20/2012 23