Ce diaporama a bien été signalé.
Nous utilisons votre profil LinkedIn et vos données d’activité pour vous proposer des publicités personnalisées et pertinentes. Vous pouvez changer vos préférences de publicités à tout moment.

Agile scrum mythbusters

Agile scrum mythbusters

Livres associés

Gratuit avec un essai de 30 jours de Scribd

Tout voir
  • Soyez le premier à commenter

  • Soyez le premier à aimer ceci

Agile scrum mythbusters

  1. 1. Agile Scrum Mythbusters
  2. 2. Topics to cover Starting with.. Done! Agile Myths Sprint Planning Daily Scrum Sprint Review Sprint Retrospective Learning board
  3. 3. Topics to cover Starting with.. Done! Agile Myths Sprint Planning Daily Scrum Sprint Review Sprint Retrospective Learning board
  4. 4. ● ScrumMaster draws the burn-down & burn-up charts ○ No. ScrumMaster is a facilitator. Everybody owns the Burndown chart and Scrum Master may help the team in drawing it if needed ● Product Owner and Scrum Master can be same person ○ Never do that. That is disaster. It’s a conflict of interest for both the parties. Product Owner tends to be demanding role and Scrum Master is neutral who helps the team to push back demands more than they could commit Agile Myths ● Only those could be a Scrum Master who are certified in this role ○ Well it’s funny to hear such points. Anybody who has a trait to help others, believes in openness, motivates the team and passionate to facilitate and move the team towards the desired goal faster and quicker could be a good Scrum Master. Scrum Master ensures that the team become self-organizing, adaptable to change, highly performing and always focused towards delivering the better version of product in short intervals of time. Even a 8 year old kid can be a better scrum master than a 55 years experienced professional
  5. 5. ● Daily stand-ups running more than 15 min ○ The whole idea is to have a quick connect and that’s why it is named standup ○ Everyone quickly updates on what they have done last day, what’s their plan for today and if they have any blockers they can talk about that ○ We do not do technical discussions. You need to flag it and park it for the stand-up to over. Then whoever is interested would join your conversation ● ScrumMaster takes the updates in the daily standup meetings ○ Well if this is how you are doing then you are not doing it appropriately at all. ○ Daily standup is a team meeting where ultimate goal is to find out how much work remained to achieve the goal of the sprint and do the replan to move toward it Agile Myths ● User stories are requirement documents ○ User stories are one liners written in the end user’s perspective ○ here is a value that a story talks about and that is something we deliver ○ User stories are not requirement documents but they could help you in writing the document very effectively if you want
  6. 6. ● Agile says no documentation ○ Well this is very much misunderstood ○ Agile says no comprehensive documentation as time to know everything is high which is actually impossible to know upfront, then time to write everything is high, time to read everything is high and so on ○ Documentation is LIVE here. It is always getting updated as we incrementally grow towards the end goal ○ Agile emphasis more on conversation and confirming the understanding by clearly written acceptance criteria against each story Agile Myths ● Awards based on agile audits ○ Well it is very debatable topic. Audit happens against set parameters and guidelines. Agile is a continuous journey where one team who is highly performing could get stuck in very next sprint or there may be some reason which could turn down their agility ○ Failure is OK and in agile we believe in failing faster which I believe the audit reports may not like ○ Ofcorse there could be practices and parameters that could help you in knowing Agility Health of your team or organization but they should help team to introspect and find their own answers which they could then vote and decide to improve. It could happen every quarter or month but absolutely not a stricter way and should respect the anonymity if ever conducted
  7. 7. ● We can only do scrum but not Kanban Or Kanban but not XP or something like that ○ Well, our focus is to BE AGILE. Scrum, Kanban ,XP are different approaches which has practices that helps us in becoming agile. So, we choose which practice we could use, which one we couldn’t and something that you use now may not be needed tomorrow or maybe you create your own version ○ I have seen teams practicing Scrum and have visual boards and define WIP limits which are Kanban practices and also do TDD, CI, Refactoring and often play planning poker to estimate stories and tasks. Now, these are all XP practices which they may not be even aware of but believe in it Agile Myths ● We CAN NOT DO AGILE because... ○ Agile is a mindset that helps us in creating a culture. Now there could be many reasons where you feel you could not agile like ■ We are Production Support team, we are not creating software, we are just 2-3 people team, We do not have roles like scrum in our team, Yada Yada Yada ○ Knowingly unknowingly we all are agile and that may not be quoted into approaches or different practices but we are handling changes in many ways. You need to tailor your process, the way you want to be, the degree of change you could bring in and needless to use the terms and jargons that others are using ○ Be a smart agile carpenter where Scrum, Kanban, XP, Lean ,DSDM and many others are different tools in your box. You may choose any tool you want in whatever combination that works for you and if it doesn’t you make your own but just DO NOT GET STUCK. FAIL FASTER and CREATE SUSTAINABLE solutions.
  8. 8. Topics to cover Starting with.. Done! Agile Myths Sprint Planning Daily Scrum Sprint Review Sprint Retrospective Learning board
  9. 9. Sprint Planning ● We can have it in 3 sections: ○ Section A: Discuss on ‘WHAT?’ - 1.5 hours ■ Product Owner (PO) sharing the goals of the sprint, work that need to be finished to achieve the goals (stories, tasks, features, prod defects etc) ■ Development team (DT) clarifies the requirement by asking questions and we call come up to mutual consensus on scope ■ Participants: PO, DT, PM, Architect, Leads, SM/Coach ○ Section B: Discuss on ‘HOW? & HOW MUCH?’ - 2-3 hours ■ Development Team identifies the capacity - how much could we commit? ■ Breaks big items into smaller items & record all queries ■ Estimate the work items ■ Draft the commitment based on estimate and capacity ■ Participants: DT, Leads, Architect, PM, SM/Coach ○ Section C: ‘Commitment’ 1.5 hours ■ Scrum Team agrees on commitment post clarifying their queries ■ Start the sprint in JIRA ■ Participants: PO, DT, PM, Architect, Leads, SM/Coach
  10. 10. Quiz 1. In the first half of sprint planning, the team asks questions to Product Owner to clarify what is to be built. 2. While estimating product backlog items size in sprint planning is technically allowed, it’s best to estimate prior to planning. 3. The product owner assigns development tasks to the team. 4. The product owner is involved in figuring out how code is written. 5. In the second half of sprint planning, the product owner may be needed to help further clarify questions the team has. 6. The second half of sprint planning is for the team to break product backlog items down into development tasks. 7. Development tasks can be estimated in hours. 8. Instead of estimating tasks in hours, some teams find it easier to count up the # of tasks for a given sprint. They then use that number for their sprint Burndown. 9. Sprint planning for a 2 week sprint should be time boxed to 4 hours. 10. Adding a backlog refinement session half way through your sprint can help with making sprint planning shorter and more effective.
  11. 11. Topics to cover Starting with.. Done! Agile Myths Sprint Planning Daily Scrum Sprint Review Sprint Retrospective Learning board
  12. 12. Daily Standup ● Co-located Product Owners need to participate almost everyday ● Distributed Product Owners may need to respect the convenience of the development team while they can expect the summary of updates from Scrum Master ● It may go beyond 15 min. Its Ok. Still try to flag technical discussion and park them for later ● Scrum Master may need to call out names to structure the conversation ○ We may go person by person or story by story ● Since physical board will not be used, hence we need to keep the JIRA board up-to-date ○ It is everyone’s shared responsibility ○ Any misleading or incorrect information needs to flagged and immediately corrected ● JIRA screen must be shared at the start of the session ● Ensure the zoom/ bluejeans link is added in invite
  13. 13. Quiz 1. It’s fine for the daily scrum to last up to 45 minutes. 2. People from outside the team may attend, provided it’s okay with the team and they don’t interfere. 3. The daily scrum is one of the 3 important inspects and adapt loops in scrum. 4. The daily scrum is sometimes referred to as the “Stand-up” or “Daily Standup” 5. The 3 questions answered in daily scrum are: a. What did you do since our last scrum? b. What do you plan to do until our next scrum? c. Do you have any impediments? 6. Discussions of how to resolve issues should be done during a sidebar after the daily scrum. 7. Teams usually don’t benefit from this daily sync up. 8. It’s helpful for the daily scrum to be in the same location, at the same time every day. 9. Managers should attend the daily scrum to help ensure everyone is doing enough work. 10. The Daily Scrum shouldn’t start until all participants arrive.
  14. 14. Topics to cover Starting with.. Done! Agile Myths Sprint Planning Daily Scrum Sprint Review Sprint Retrospective Learning board
  15. 15. Sprint Review ● It happens at the end of the sprint and it needs to be prepared well ● We need to do a pre-review event, a day before the Review meeting where the intent is to enable development team to prepare well for the review meeting and check if the experience is getting affected due to poor connection, infrastructure setup, if any pre- recorded video is needed ● Incase the multiple team members are presenting then how are we going to orchestrate the experience when all of us are distributed? ● We can not have just one person who is recording the feedbacks and almost everyone need to attempt to collect the feedback as there may be call drops or poor audio connectivity ● Post Sprint Review, the Scrum team need to have a meeting to collate all the review feedbacks
  16. 16. Quiz 1. It’s expected that a team will demo a feature even if they didn’t finish it in the sprint. 2. The product owner accepts a feature based on the conversations and acceptance criteria that was previously discussed with the team, not by some criteria the team hasn’t known before. 3. Stakeholders are welcome at the review as long as they don’t interfere. Their feedback can be helpful for shaping the product moving forward. 4. Teams should spend at least 4 hours preparing for the review, and the review should include powerpoint slides. 5. If the team can’t demo a feature because it wasn’t completed, it’s okay for a manager to question the team’s approach in this meeting. 6. The sprint review is mainly for show and has little impact on the product. 7. A manager should pick who does the demos during the sprint review. 8. Feedback from stakeholders during the sprint review should be collected and put on the backlog for consideration by the product owner instead of spawning long conversations during the review. 9. Most sprint reviews last only 10 minutes. 10. The scrum master should be in charge of running the sprint review and making sure the team demos what they need to demo.
  17. 17. Topics to cover Starting with.. Done! Agile Myths Sprint Planning Daily Scrum Sprint Review Sprint Retrospective Learning board
  18. 18. Sprint Retrospective ● We need to focus on video conferencing ● Will be great if we all come prepared with points to discuss ● We should ensure that all gets chance to speak ● Focus should be more on learning how we are doing and identifying few points that we can improve upon to enhance our experience ● Participants: Scrum Team only ● The summary of the meeting could be shared with all (also on confluence)
  19. 19. Quiz 1. Anyone who wants to attend should be able to show up. 2. The retrospective is confidential. Whatever happens in the retrospective stays in the retrospective, unless the team agrees to share it. 3. The purpose of the retrospective is tell people what they did wrong during the last sprint. 4. Your scrum master should use the same exercise for the retrospective every time for consistency. 5. The retrospective is one of the 3 important inspect and adapt loops in scrum 6. Trust is essential for a good retrospective. 7. A sprint retrospective is optional for a highly performing team. 8. Retrospectives can benefit from snacks. 9. The scrum master should always be the one to facilitate the Retrospective. 10. No one but the team members should ever be invited to the retrospective.
  20. 20. Topics to cover Starting with.. Done! Agile Myths Sprint Planning Daily Scrum Sprint Review Sprint Retrospective Learning board
  21. 21. Backlog Refinement ● It usually happens in the mid-sprint where the Product Owner educates development team about future work and want to keep transparency on any changes in backlog. We need to revisit the backlog based on our experience so far as we want to achieve the product goal over finishing planned work items ● Participants: PO, DT, PM, Architect, Leads, SM/Coach ● This event can also happen in many sections: ○ Section A: PO shares the information with team, collects the queries and respond if possible - 1.5 hours ○ Section B: PO responds to pending queries and check the possibility of spike and confidence of team to deliver the work in future sprints - 1.5 hours
  22. 22. THANK YOU www.Benzne.com Anuj M Ojha