Agile Development and Implementing Scrum

Editor's Notes

• #4: Software Development can be more challenging than other industries
• #5: Agile’s roots go back to Deming’s Toyota Production System after World War II. In 90s Waterfall was failing a lot due to changing requirements and needs. Customers were getting to see the first results years after requesting something. [what the customer really needed] And Agile was born as a reaction to the failures of traditional project management methods In 2001, in Utah, Agile manifesto was published. Agile is a philosophy, not a method.
• #6: In traditional management methods, process and tools, comprehensive documentation, contract negotiation and following a plan is a base and valued. In agile, the base of the philosophy is individuals and interactions, working software, customer collaboration and responding to change. When seen this way, one may think that there is no documentation in Agile then? The answer is no. Agile does not say «forget the items on the right side», Agile says that there is vaue in the items on the right side and we value the items on the left more.
• #7: 1. Highest priority is to satisfy the customer through early and continous delivery 2. Welcome changing environments, use it for the customer’s advantage 3. Deliver working software frequently 4. Working software the primary measure of progress 5. Sustainable development 6. Business people and developers should work together 7. Work with motivated individuals, give them the environment and support and trust them. 8. Most effective way of communication is face-to-face. 9. Technical excellence. 10. Make it simple. 11. Self-organize. 12. Inspect and adapt.
• #8: XP: short, incremental cycles with frequent testing. Collaborative and self-organizing team. Pair programming and refactoring. Communication, simplicitiy, feedback and courage Scrum: simple, flexible and concentrated on management aspects rather than engineering. Time-boxed, fixed length, Sprint. Prioritized backlog. Release early and often. Kanban: Originally used in automotive industry. Core concept is visualizing workflow, limiting WIP and measuring lead time. Lean: pioneered by Toyota as Lean manufacturing which is later used for software development. The purpose is to achieve quality, speed and customer alignment. Agile is an umbrella term and there are more Agile methodologies.
• #9: Going Agile increases productivity and quality, improves employee job satisfaction, lowers costs, improves customer satistaction, improves feedback received.
• #10: PMI’s survey in 2015 shows that organizations that are more agile are more successful than their less agile counterparts. And Robert Winter shows that only 14% of projects managed with waterfall are successful while this is 42% for Agile managed projects.
• #12: Scrum has 5 values also listed in the Scrum Guide by Ken Schwaber and Jeff Sutherland Courage: Have the courage to change when needed. Focus: Focused to achieve goals. Commitment: Committed to succeed. Respect: Respect each other. Openness: Transparent and available for inspection and improvement. A Scrum Team can achieve a goal together efficiently and use Scrum successfully if it embraces, learns and lives by these values. The Scrum Team will learn these values more and more by using the Scrum Artifacts and participating in the Scrum Events. Pillars of Scrum Transparency: Presenting the facts as is, being open and letting everyone involved see what is going on. Inspection: Everyone in the Scrum Team can inspect the parts of the project for improvement. Adaptation: Continous improvement. Adapting based on the results of inspection.
• #13: No team leaders, task managers or product managers like in traditional methods. Three roles and coequal, must work closely. Together they make the Scrum Team and they are all responsible for delivering a complete and quality product. Product Owner: Sets the vision of the project, owns the Product Backlog. Scrum Master: Keeper of the process. Makes sure Scrum process is followed correctly. Removes impediments. Servant leader. Development Team: Consists of the professionals who do the work and work towards the Sprint Goal. No-one tells them how to do their job. Optimal size is 5 to 9. Scrum Guide also mentions it shouldn’t be fewer than 3 and more than 9.
• #14: Sprint: The looping arrow which is a container of all other events, time-boxed, ideally 2 to 4 weeks. Sprint Planning Meeting: A meeting held at the beginning of every sprint to create the Sprint Goal and the Sprint Backlog, time-boxed. Daily Scrum: Every 24 hours a a time-boxed(15 minutes) daily stand-up meeting is held ideally at the same time, at the same place. Anyone can join this meeting but only the Development Team can participate. It is the Development Team’s responsibility to have this meeting and the SM needs to make sure the DT has this meeting every day. 3 questions; What did I do yesterday for the Sprint Goal? What will I do today for the Sprint Goal? Is there any impediments that prevents the team to move towards the Sprint Goal? Sprint Review: Time-boxed, product owner can invite key end users. The DT presents what they prepared during the Sprint. An informal meeting to bring people together and discuss what should be done next. Sprint Retrospective: Time-boxed, inspect and improve. The Scrum Team joins this meeting, PO optional. 2 questions; What went well? What could be improved?
• #15: Oranges are the artifacts Blues are the events Product Backlog: List of features, functionalities, requirements etc. Owned by the PO, prioritized list. Prepared by the PO by communicating with key stakeholders and end-users. Sprint Backlog: Set of items selected from the Product Backlog to be implemented in the Sprint along with a plan about how they will be implemented. Created during the Sprint planning meeting. Increment: is the actual software delivered at the end of the Sprint. It is integrated with the increments of all prior Sprints. Definition of Done: is used to have a common understanding among the Scrum Team to decide when a PBI is done. For instance; when a PBI is done everyone understands that it is coded, tested and matches coding standards.
• #18: Product Backlog creation and prioritization is PO’s job. However, it is a good practice to create the PB as a whole Scrum Team in Product Backlog Refinement.
• #19: The input to Sprint Planning Meeting is the capacity/velocity of the Development Team. The Development Team does not have a planned off-day in the following month. The output of Sprint Planning Meeting is the Sprint Goal and Sprint Backlog.
• #20: The first thing to do in the Sprint Planning Meeting is to decide the Sprint Length. The Scrum Team together agrees to have 1 week Sprints
• #22: Since the Development Team does not know its velocity they want to take as few items as possible to not disappoint PO at the end of the Sprint They need to make sure that they take enough items to be busy until the end of the Sprint as well.
• #24: The output of Sprint Planning Meeting is the Sprint Goal and Sprint Backlog.
• #25: 79 hours of work. D1 will handle user interface, D2 will handle database design, D3 will handle manual tests, D1 and D2 will prepare automated tests. Talk about Workspace and Tools at the end of this slide.