The main role in Agile Teams is Scrum Master or Process Coach. The KRA or responsibility for this role is simple : be the custodian of Agile or Scrum. The Scrum Master or Process Coach [hereafter referred to as Scrum Master], basically guides the team’s use of Agile [Scrum], helps them identify obstacles or barriers to their success and work with them to overcome these obstacles or barriers. In essence, the Scrum Master helps the team become great at their use of Agile [Scrum] and makes good teams great. And how exactly does a Scrum Master do this? The Scrum Master does this without coercing, brainwashing or directing the team in doing all this as well as preventing anyone else from doing the same. The Scrum Master would work with the team as a whole and each member of the team as well, to identify issues, raise them openly, face them and then find out innovative ideas and solutions for them. The Scrum Master would typically do this during the Sprint at:

• Sprint Planning - The focus here is to get the team to estimate and commit fairly to the requirements. Hence, the Scrum Master would:
  • Invite subject master experts after discussing with the team but not allow them to over rule the team.
  • Keep product owner from influencing teams committment to upside
  • Keep the team from undercommitting
  • Have everyone in the team participate rather than having only one or two members as active
• Daily Stand Up - The focus here is to keep the stand up to 15 minutes, team focused collaboration opportunity as well as identify any obstacles quickly. Hence, the Scrum Master would:
  • Everyone updates the sprint backlog
  • Everyone updates status to everyone else
  • Note obstacles raised by team members and work with them over the sprint to overcome these
  • Keep the stand up less than 15 minutes
  • Have stand up start and end on time
  • Encourage members with obstacles to seek help or collaborate after stand up
• During the sprint : The focus during the sprint is to keep the team stable. Hence, a Scrum Master would
  • Stop product owner from making any changes
  • Work with product owner on her availability for team to answer questions and provide feedback
  • Work with the team to ensure motivation and committment
• Sprint Review : During the sprint review, the goal is to keep the team from presenting non-working artifacts or product owner from assessing team performance unfairly. Hence, Scrum Master would
  • Arrange the room and other facilities keeping team focused on developing working software
  • Get the product owner and other stake holders
  • Present the agenda
  • Moderate any discussions, if needed
• Sprint Retrospective : In addition, the Scrum Master would be a central point during Retrospectives. The goal during Retrospectives is to help the team identify patterns and practices that helped them do well during the sprint, ones which did not help them or stopped them from doing well. Hence, the team identifies what worked well that was already working well, what worked well that was not working well, what is not working well [was working well, or was not working well even before]. The team then identifies some solutions and ideas and committs to trying these out over next sprints.

Hence, we can see that Scrum Master is its roots in servant leadership. Like with every other role in Agile or Scrum, this is a role rather than a designation. Hence, for one project the team can decide on having one person as a Scrum Master/ Process Coach and for another, some one else. The Scrum Master does not necessarily need to be a technical geek but someone who can understand team issues and can effectively facilitate and counsel enabling good teams become great.

Popularity: 9%

Posted on March 17th, 2008 by admin
Filed under: Introduction, Leadership | 2 Comments »

The Product Owner is the wringable neck in Scrum. They are responsible for:

• Write down the requirements for the project
• Prioritize the requirements
• Release schedule for the project
• Be available during the sprint and sprint planning meeting to:
  • Explain business context of each requirement to the team
  • Explain acceptance test criteria for each requirement to the team
• Provide feedback on working features developed by the team during sprint review

As seen above, the Product Owner controls the release schedule and requirements or “what is to built” and “when it is to be built“. She leaves “how it is to be built” generally to the team. The team can provide the Product Owner feedback on these two dimensions, but it is primarily Product Owners call on these two issues.  It is important to note that although Scrum and Agile are collaborative processes, the Product Owner holds the final authority for determining the value, priority and details of all work done by an Agile team. The Product Owner wields this authority by virtue of a deep knowledge of the goal and end results desired as well as a respected position among all the stakeholders. This is one of the pivots for “business alignment” in an Agile Process. Although, the term Product Owner is used mostly in Scrum, it is increasingly being used to reference a “Marketing or Business role” in most Agile teams.

Another important aspect with most software projects is that there may be more than one stakeholder for the project. However, in this case as well, there would be only one product owner. As discussed before, the product owner can discuss with as many people as she likes and use any medium to arrive at her list of requirements and their priority, but only one product owner would ideally prioritize the requirements as well as set acceptance criteria for each requirement. This is to ensure that “what is being built” and “when it is being built” are very clear through out the project. In case there are more than one stakeholders/ customers, the product owner can work with them during the sprint writing the requirements or getting market feedback on requirements for prioritization.

A product owner is sometimes also aided by testers [who help frame acceptance tests for requirements] and business analysts [who help frame requirements, business context]. That is why most business analysts and testers are ideal people to graduate to a product owner role. An ideal product owner would combine business analyst, testers and marketing profile. In addition, here are some things the product owner should not do:

• Pressurize the team into committing to more requirements than they are comfortable with for a sprint. If she feels, the team is under committing, she can bring this to Scrum Master or Agile Coache’s attention and discuss during Sprint Review. The idea is to discuss the issue, rather than use subversive and non-collaborative tactics.
• Make changes during the sprint. This is done to keep the team focused. In case the product owner feels the need to make changes to the sprint regularly, the team might want to consider whether their sprint length is too long that does not allow product owner opportunity to inspect and adapt at her end.
• Be unavailable during the sprint. It is important that the product owner or proxies are available to answer any team questions as they arise. The idea is to keep the keep on track and empowered to keep moving without having to wait for information.

A product owner hence is the window through which the Agile team interacts and integrates market dynamics in a software project.

Popularity: 12%

Posted on February 29th, 2008 by admin
Filed under: Introduction, Leadership | 2 Comments »