Scrum Project Roles

Understanding defined roles and responsibilities is very important for ensuring the successful implementation of Scrum projects. There are three central roles in Scrum that are eventually responsible for meeting the project objectives. The core roles are the Product Owner, Scrum Master, and Scrum Team. Together they are referred to as the Scrum Core Team. It is important to note that, of these three roles, no role has authority over the others.

1.    Product Owner

The Product Owner is the person responsible for maximizing business value for the project. He/she is responsible for articulating customer requirements and maintaining business justification for the project. The Product Owner represents the Voice of the Customer.

Corresponding to a Product Owner role in a project, there could be a Program Product Owner for a program or a Portfolio Product Owner for a portfolio.

2.    Scrum Master

The Scrum Master is a facilitator who ensures that the Scrum Team is provided with an environment conducive to completing the product’s development successfully. The Scrum Master guides, facilitates, and teaches Scrum practices to everyone involved in the project; clears impediments for the team; and, ensures that Scrum processes are being followed.

Note that the Scrum Master role is very different from the role played by the Project Manager in a traditional Waterfall model of project management, in which the Project Manager works as a manager or leader for the project. The Scrum Master only works as a facilitator and he/she is at the same hierarchical level as anyone else in the Scrum Team—any person from the Scrum Team who learns how to facilitate Scrum projects can become the Scrum Master for a project or for a Sprint.

Corresponding to a Scrum Master role in a project, there could be a Program Scrum Master for a program or a Portfolio Scrum Master for a portfolio.

3.    Scrum Team

The Scrum Team is a group or team of people who are responsible for understanding the business requirements specified by the Product Owner, estimating User Stories, and final creation of the project Deliverables.

A Guide to the Scrum Body of Knowledge (SBOK^TM) suggests the following roles guide for the three core roles:

1. Product Owner—It is imperative for Product Owners to read the entire chapter 3 of the guide to SBOK.
2. Scrum Master—The Scrum Master should also be familiar with the entire chapter 3 with primary focus on sections 3.5, 3.6, 3.7, 3.8, and 3.9 of the guide to SBOK.
3. Scrum Team— The Scrum Team should mainly focus on sections 3.6, 3.7, and 3.8 of the guide to SBOK.

Ancillary roles are other stakeholders who are involved in the scrum project, but who are not committed. Normally, ancillary roles comprise of customers, management and members of the executive team who are active participants and they collectively work towards the objectives of consulting, progress reporting and feedback collection to better work toward providing the highest value conceivable.

To know more please visit,www.SCRUMstudy.com

Daily Scrum Update Using Scrumboard

The Daily Scrum is one of the most important aspects of the Scrum framework. Scrum’s transparency comes from openly viewable information tools such as the Scrumboard, which shows the progress of the team. The team uses a Scrumboard to plan and track progress during each Sprint.

The Scrumboard usually contains four to five columns to indicate the progress of the estimated tasks for the Sprint:

1. A ‘Stories’ column for the list of tasks (optional, usually a part of the Prioritized Product Backlog)
2. A ‘To Do’ column for tasks not yet started
3. An ‘In Progress’ column for the tasks started but not yet completed
4. A ‘Testing’ column for tasks completed but in the process of being tested, and
5. A ‘Done’ column for the tasks that have been completed and successfully tested.

At the beginning of a Sprint, all tasks for that Sprint are placed in the ‘To Do’ column and are subsequently moved forward according to their progress.

The Scrumboard should preferably be maintained manually on paper or a white board, but can also be maintained electronically in a spreadsheet.

The Scrum Team should change or add to the Scrumboard as required so that the board provides visual information and control about the work going on as agreed and committed by the team. Updating or referring to the Scrumboard during the Daily Scrum keeps the team focused on the tasks that remain and their priorities.

For interesting articles about Scrum and Agile, visit www.scrumstudy.com/blog

Why Empirical Process Control is Important in SCRUM?

In today’s rapidly changing market trends, the customer may imagine an ‘apple’ and the finished product made by the project team may be an ‘orange’. This though is not the main problem. If the customer is aware of what’s cooking from the start he can steer the team to the ‘apple’ side. But in actuality the customer finds out about the ‘orange’ only too late. In other words if inputs and processes are in control and are reliable, we can get reliable outputs (which are generally the case with Waterfall model). The problem arises when inputs and processes cannot be controlled rigidly which generally means that the outputs would be unreliable (the Agile/Scrum scenario). In such circumstances we need to look beyond the waterfall model and focus on Empirical Process Control which simply means you need to look at the outputs more frequently and if it is not as per your liking you go back to inputs and processes and tweak it accordingly.

In Scrum, decisions are made based on observation and experimentation rather than on detailed upfront planning. Empirical process control relies on the three main ideas of transparency, inspection, and adaptation.

Transparency allows all facets of any Scrum process to be observed by anyone. This promotes an easy and transparent flow of information throughout the organization and creates an open work culture. In Scrum we have a Project Vision Statement which can be viewed by all stakeholders and the Scrum Team; an open Product Backlog with prioritized User Stories, both within and outside the Scrum Team; clearly visible Scrumboards, Burndown Charts, and other information radiators; Daily Standup Meetings conducted making sure everyone’s aware of everything; and Sprint Review Meetings in which the Scrum Team demonstrates the potentially shippable Deliverables.

The following figure summarizes the concept of transparency in Scrum

Inspection in Scrum is depicted through the use of a common Scrumboard; collection of feedback from the customer and other stakeholders; review and approval of the Deliverables by the Product Owner and the customer.

The following figure summarizes the concept of inspection in Scrum:

Adaptation happens as the Scrum Core Team and Stakeholders learn through transparency and inspection and then adapt by making improvements in the work they are doing. In Daily Standup Meetings, Scrum Team members openly discuss impediments to completing their tasks and seek help from other team members. Risk identification is performed and iterated throughout the project. Improvements can also result in Change Requests, which are discussed and approved. The Scrum Guidance Body interacts with Scrum Team members during many processes to offer guidance and also provide expertise as required. During the Sprint Retrospective, agreed actionable improvements are determined.

The following figure summarizes the concept of adaptation in Scrum:

These three pillars of Empirical Process Control ensure that the problems which projects face in the Traditional Waterfall way of doing things do not happen in Scrum Projects.

To know more please visit www.SCRUMstudy.com

What is Agile methodology?

The term “agile” generally refers to being able to move or respond quickly and easily; being nimble. In any kind of management discipline, agile as a quality should therefore be a good thing to aim for. Agile project management specifically, involves being adaptive during the creation of a product, service, or other result.

A number of Agile methodologies originated and gained traction in the 1990’s and the early 2000’s. Here are the various popular Agile methods being used.

Lean Kanban: Lean concept optimizes an organization’s system to produce valuable results based on its resources, needs, and alternatives while reducing waste. Kanban literally means a “signboard” or “billboard” and it espouses the use of visual aids to assist and track production.

Extreme Programming (XP): Originated in Chrysler Corporation, gained traction in the 1990′s. XP makes it possible to keep the cost of changing software from rising radically with time. The key attributes of XP include incremental development, flexible scheduling, automated test codes, verbal communication, ever-evolving design, close collaboration, and tying in the long- and short-term drives of all those involved.

Crystal Methods: Introduced by Alistair Cockburn in the early 1990s, Crystal methods have four roles—executive sponsor, lead designer, developers, and experienced users. Crystal Methods recommend various strategies and techniques to achieve agility.

Dynamic Systems Development Methods (DSMD): This framework was initially published in 1995 and is administered by the DSDM Consortium. DSDM sets quality and effort in terms of cost and time at the outset and adjusts the project deliverables to meet set criteria by prioritizing the deliverables into “Must have,” “Should have,” “Could have,” and “Won’t have” categories

Feature Driven Development (FDD): Introduced by Jeff De Luca in 1997 and operates on the principle of completing a project by breaking it down into small, client-valued functions that can be delivered in less than two weeks’ time. FDD has two core principles—software development is a human activity and software development is a client-valued functionality.

Test Driven Development (TDD): Also known as Test-First Development, and was introduced by Kent Beck, one of the creators of Extreme Programming (XP). It is a software development method that involves writing automated test code first and developing the least amount of code necessary to pass that test later.

Adaptive Software Development (ASD): This method grew out of the rapid application development work by Jim Highsmith and Sam Bayer. The highlights of ASD are constant adaptation of processes to the work at hand, provision of solutions to problems surfacing in large projects, and iterative, incremental development with continuous prototyping.

Agile Unified Process (AUP): Evolved from IBM’s Rational Unified Process and developed by Scott Ambler, AUP combines industry-tried-and-tested Agile techniques such as Test Driven Development (TDD), Agile Modeling, agile change management, and database refactoring, to deliver a working product of the best quality.

Domain-Driven Design (DDD): This approach was meant for handling complex designs with implementation linked to an evolving model. It was conceptualized by Eric Evans in 2004 and revolves around the design of a core domain.

All these methods of Agile differ from each other in a variety of aspects but their commonality stems from their adherence to The Agile Manifesto.

To know more, please visit www.SCRUMstudy.com

All About Prioritized Program Backlog

The Prioritized Program Backlog plays a very similar role at the program level as the Prioritized Product Backlog does on project level. It identifies the requirements for the program and their priorities.

The items in the Prioritized Portfolio Backlog provide inputs to the various Prioritized Program Backlogs and, through Prioritized Program Backlogs, to Prioritized Product Backlogs of individual projects. As described for Prioritized Program Backlogs only minimal, if any, refinement of User Stories is done at this level, because the refinement is done in the projects and their specific Prioritized Product Backlogs.

There are a few differences, though:

The creation of the respective deliverables and their acceptance is done in the projects of the program. The done or acceptance criteria for each Product Backlog Item / User story may be defined on the program level.  Projects have to adhere to them but can add their own criteria.

The length of a Sprint is project specific and, generally, varies from project to project in a program. In addition, the velocity of different teams is, normally, not the same. Therefore, it is not necessary to have very granular User Stories at the program level. The refinement of User Stories at the program level goes only far enough to ensure that the respective story is clearly understood and tangible acceptance criteria for the program can be defined.

To know more www.SCRUMstudy.com

What is Servant Leadership?

The preferred leadership style for Scrum projects is Servant Leadership. This term was first described by Robert K. Greenleaf in an essay entitled The Servant as Leader. Below is an excerpt where he explains the concept:

The servant-leader is servant first…It begins with the natural feeling that one wants to serve, to serve first. Then conscious choice brings one to aspire to lead. That person is sharply different from one who is leader first, perhaps because of the need to assuage an unusual power drive or to acquire material possessions…The leader-first and the servant-first are two extreme types. Between them there are shadings and blends that are part of the infinite variety of human nature….

The difference manifests itself in the care taken by the servant-first to make sure that other people’s highest priority needs are being served. The best test, and difficult to administer, is: Do those served grow as persons? Do they, while being served, become healthier, wiser, freer, more autonomous, more likely themselves to become servants? And, what is the effect on the least privileged in society? Will they benefit or at least not be further deprived? (Greenleaf 1970, 6)

Elaborating on the writings of Greenleaf, Larry Spears identifies ten traits that every effective servant-leader should possess:

1.  Listening—Servant leaders are expected to listen intently and receptively to what is being said, or not said. They are able to get in touch with their inner voice to understand and reflect on their own feelings.
2.  Empathy—Good servant leaders accept and recognize individuals for their special and unique skills and abilities. They assume workers have good intentions and accept them as individuals, even when there are behavioral or performance issues.
3.  Healing—The motivation and potential to heal oneself and one’s relationship with others is a strong trait of servant leaders. Servant leaders recognize and take the opportunity to help their colleagues who are experiencing emotional pain.
4.  Awareness—Awareness and particularly self-awareness is a trait of servant leaders. This allows them to better understand and integrate issues such as those related to ethics, power, and values.
5.  Persuasion—Servant leaders use persuasion, rather than their positional authority to gain group consensus and make decisions. Rather than forcing compliance and coercion as is typical in some authoritarian management styles, servant leaders practice persuasion.
6.  Conceptualization—The ability to view and analyze problems (in an organization) from a broader conceptual and visionary perspective, rather than focusing on merely the immediate short-term goals, is a unique skill of good servant leaders.
7.  Foresight—Their intuitive minds allow servant leaders to use and apply past lessons and present realities to foresee the outcome of current situations and decisions.
8.  Stewardship—Stewardship demands a commitment to serving others. Servant leaders prefer persuasion over control to ensure that they gain the trust of others in the organization.
9.  Commitment to the growth of others—Servant leaders have a deep commitment to the growth of people within their organization. They take on the responsibility of nurturing the personal, professional, and spiritual growth of others (e.g., providing access to resources for personal and professional development, encouraging workers to participate in decision making).
10.  Building community—Servant leaders are interested in building communities within a working environment, particularly given the shift in societies away from smaller communities to large institutions shaping and controlling human lives.

Scrum believes that all leaders of Scrum projects (including the Scrum Master and Product Owner) should be servant-leaders who have the above traits.

For more informative articles on Scrum and Agile, please visit www.scrumstudy.com

Various Dimensions of Team Specialization

In a large SCRUM project, Team Specialization may be required. There are three dimensions of Team Specialization.

The first dimension is the need for accomplishing specific tasks. For example, one Specialized Team might be an integration team that has specialized knowledge of continuous integration.. That knowledge could be especially important when and if there is a Release Readiness Sprint.

The second dimension is the need for special skills of single team members. Theoretically, all Scrum Team members are generalists and specialists in that they have knowledge of various fields and are experts in at least one. However, this might not be the case in a large project. Members of Specialized Teams may need to possess specific skills—such as special domain knowledge like security—which may not be available with all large project teams for which it is needed. For a large project, it would be extremely costly to train everybody in all domains. These experts with special skills and knowledge may work as temporary team members in different teams, and sometimes it may be necessary to hire them from external sources. Adding a new team member will impact the team velocity.

The third dimension is that there may be limitations in team flexibility. As mentioned above, in a large project it would be extremely costly to train everybody in all domains. That means that every team will have one or more domains they are good at, a few domains they can and will work on with some inputs and training, and other domains they cannot work on. When it comes to Sprint planning, every team will have a subset of User Stories that are naturally theirs, some that they can work on, and some they can’t work on because they don’t have the knowledge/skills.

The project will have to take the risk that they may not be able to get all the top-priority User Stories done in a Sprint due to these limitations and may need to develop some User Stores of lower priority while waiting for the availability of team members with specialized skills.

To know more,please visit www.SCRUMstudy.com

All about Time-boxing in SCRUM

Scrum treats time as one of the most important constraints in managing a project. To address the constraint of time, Scrum introduces a concept called ‘Time-boxing’ which proposes fixing a certain amount of time for each process and activity in a Scrum project. This ensures that Scrum Team members do not take up too much or too little work for a particular period of time and do not expend their time and energy on work for which they have little clarity.

Some of the advantages of Time-boxing are as follows:

• Efficient development process
• Less overheads
• High velocity for teams

Time-boxing can be utilized in many Scrum processes, for example, in the Conduct Daily Standup process, the duration of the Daily Standup Meeting is Time-boxed. At times, Time-boxing may be used to avoid excessive improvement of an item (i.e., gold-plating).

Time-boxing is a critical practice in Scrum and should be applied with care. Arbitrary Time-boxing can lead to de-motivation of the team and may have the consequence of creating an apprehensive environment, so it should be used appropriately.

To know more, please visit www.SCRUMstudy.com