Tag: Scrum Master

Myth about Sprint Planning consisting of three parts Part1, Part2, Part3 vs Topic1, Topic2, Topic3

Many teams imagine Sprint planning as 3 parts being done serially – one after another. However that reduces the collaboration among teams – Let us understand why

Common Misconceptions and negative implications

Most teams implement Sprint Planning as three parts – Part 1, Part 2 and Part 3. The Product Owner comes in part 1 and 2, helps with setup of the Sprint Goal (WHY) selection of functionality (WHAT) and then the Developers sits and thinks over the technical (HOW) during the Part 2 of the sprint planning. The implication of this is that PO then does not get involved in the detailing and the road-blocks that team faces and technical feasibility problems that result during the Part 3 becomes a back-and-forth discussion between PO and Developers. This obviously results in a loss of productivity.

Recommendations

  • The whole Sprint Planning process is an iterative, incremental and collaborative process and therefore there are three Topics and not three Parts to the meeting.
  • First topic – WHY – is the business objective
  • Second topic – WHAT – is the selection of the Product Backlog Items which may help achieve the goal. So, it is forecasting what items should be part of this Sprint.
  • Third Topic – HOW – is the discussion of details and feasibility of the items and the help required from Scrum Master or Product Owner to get this done.
  • So, you can consider the WHAT and HOW are iterative in nature where the HOW revolves around the WHAT and joint discussions are necessary. There are possible considerations that may happen to the WHAT because of the HOW. Technicalities do influence to a large extent on WHAT can be done and what cannot.
  • The Sprint Planning Event can end with a decision on THE WHY – Sprint Goal, a forecast of WHAT needs to be done and the HOW for at-least a few things to be done over the next few days. However, the Sprint Planning PROCESS does not end with Sprint Planning EVENT. The Product Owner and Developers keep doing the discussion on the two topics – WHAT and HOW throughout the Sprint. Many-a-times, the teams do these detailed discussions on the HOW for the WHATs after daily scrums on the plan for next 24-48 hours.

So, my recommendation is not to call the Sprint Planning as Part1, Part2 and Part3 but iterative, incremental and collaborative process of Topic1, Topic2 and Topic3 which starts with Sprint Planning and continues throughout the Sprint.

This article is re-published on WORLD OF AGILE website –https://worldofagile.com/blog/myth-about-sprint-planning-consisting-of-three-parts-part1-part2-part3-vs-topic1-topic2-topic3/

Myth about Sprint Review being a sign-off event or a demo forum

Teams some times think of Sprint Revierw as a “sign off” from the Product Owner – this reduces the opportunity to get feedback from stakeholders –

Common Misconceptions and negative implications

Sprint Review is thought to be a “sign-off event by the Product Owner” or “a demo forum by developers” by most organizations. This is an INCORRECT understanding of the Sprint Review.

Sprint Review is actually a feedback solicitation forum. The Scrum Team seek feedback from the stakeholders during the Sprint Review. This helps address the deviations. The Product Owner and Developers work together on a day-to-day basis. The Product Owner DOES NOT wait till the end of the sprint to give feedback to the Developers.

Recommendations

  • Product Owner needs to participate during the Sprint and provide feedback throughout the Sprint to the team. This gives an opportunity to the team to work on the feedback by the PO and adapt if required. This also gives opportunity for the PO to get the product ready by the time the Sprint ends.
  • Product Increment is considered as an INPUT into the Sprint Review and not an output as thought by many people. Therefore, sign offs (if any) have to be done before the Sprint Review starts. Also the sign-off – if anyone has to do – it has to be the Product Owner. That’s why the word “Owner”.
  • When the Sprint Review starts, the Product Owner and Developers have to be in sync with what is being shown to the stakeholders. If both the roles are in sync, then Sprint Review becomes an excellent opportunity to solicit feedback from stakeholders – who could be sales teams, marketing teams, sponsors, end-user representatives etc.
  • If one wants to use the word “Demo”, then my recommendation is to use the word during the Sprint when Developers demos the product continuously and seeks feedback from the PO. Demo should be ongoing and day-to-day where-as the Sprint Review is the minimum opportunity to solicit feedback from stakeholders.
  • Some may argue that getting Increment is impossible considering that stakeholder feedback happens in a Sprint Review. What we really recommend is that Sprint Review should be a “minimum” forum to seek feedback from stakeholders. Scrum does not stop you from getting more feedback from stakeholders during the Sprint.
  • The objective of the Sprint is to get a “usable” Increment at the end of the Sprint. This is possible if feedback is taken frequently from stakeholders – at a bare minimum during the Sprint Review. The Product Owner feedback should be day-to-day

Sprint Review therefore, is an informal opportunity for the Scrum Team to solicit feedback from stakeholders and make sure that the deviations are addressed.

This article is re-published on WORLD OF AGILE website –https://worldofagile.com/blog/myth-about-sprint-review-being-a-sign-off-event-or-a-demo-forum/

Myth about Scrum Master being a renamed Project Manager role

A commom question often asked – Can we treat the Scrum Master as “The Project Manager in Scrum World?” – Let us understand how the world differs

Common Misconceptions and negative implications

  • Organizations implement Scrum Master role by renaming all their Project Managers as Scrum Masters just because they want to do Scrum or try Scrum. Scrum Master is the most mis-understood role in the industry.
  • Scrum Master remains the same “Command and Control” role
  • Scrum Master is made accountable for Product Scope, Product Delivery, Product Quality, Product Budgets and Project Timelines. Management holds one neck and that is Scrum Master’s neck
  • Scrum Master becomes a coordinator as the Project Manager used to be

Recommendations

  • Scrum Roles are designed in such a way that the right role takes the right accountability. The Project Management was a centralized accountability model where Project Manger was made accountable for everything. Scrum is a distributed accountability model. The Product is owned by the Product Owner. So, the accountability of Scope, Cost and Time is given to the PO. The Developers is made accountable for the delivery. So, Quality is the accountability of the Developers. Scrum Master is the guardian of Scrum. He/she is a coach and facilitator who makes things happen by making the right role take up the right accountability.
  • As a Coach, Scrum Master is a leadership role who guides the PO and Developers into following the Scrum Framework. Scrum Master makes the PO, Development Team and the Organization aware of the self-organized model, cross-functional teams, product accountability, complexity handling, importance of timeboxing, tools, techniques – in general Scrum framework as a whole.
  • As a Facilitator, Scrum Master makes sure that focus on getting decisions done and progressing towards goal. Scrum facilitates meetings, communications and helps the PO and Developers to come to conclusions. Many a times, the delay in decision making is the major cause of productivity issues. People don’t come to conclusions. Scrum Master’s job is to get the people to conclusions.
  • As an Impediment Solver, Scrum Master reaches to the right entities of the organization and gets right help at the right time so that team can proceed.
  • Scrum Master is a Servant Leader whose job is “to serve”. The accountability of doing the product work is given to  the Product Owner and Developers. Since Project Manager is responsible for Scope, Cost, Time, naturally it becomes a “Command and Control” role. The leadership styles are completely different.
  • Scrum is based on the “Fail-Fast ” model vs the Project Management which is based on “Don’t Fail” model. Scrum encourages the team to fail and let the team learn from mistakes. Project Manager makes sure that as much risk mitigation is done so that mistakes don’t happen. Scrum Master’s job is to allow mistakes and let the team learn from mistakes. Project Manager’s job is to prevent mistakes. They are diametrically opposite in the thought processes.

With so many drastic differences, if the Project Managers are renamed as Scrum Masters, the way people think is no different than what used to happen in waterfalls. Naturally done, we are setting up things for failure if Project Managers are renamed as Scrum Master. Lot of training and mentoring of Project Managers is to be done so that the Project Managers think differently to what they used to do while they were project managers.

This article is re-published on WORLD OF AGILE website –https://worldofagile.com/blog/myth-about-scrum-master-being-a-renamed-project-manager-role/