Conflict Management and SCRUM

Organizations applying the Scrum framework encourage an open environment and dialogue among employees. Conflicts among Scrum Team members are generally resolved independently, with little or no involvement from management or others outside the Scrum Team.

 Conflict can be healthy when it promotes team discussions and encourages debates, as this usually results in benefits for the project and the respective team members. It is therefore important that the resolution of conflicts be encouraged, promoting an open environment where team members feel welcome to express their opinions and concerns with each other and about the project, and ultimately agree on what is to be delivered and how the work in each Sprint will be performed.
Usually there are four approaches to managing conflict in an organization applying Scrum processes:

Win-Win

It is usually best for team members to face problems directly with a cooperative attitude and an open dialogue to work through any disagreements to reach consensus. This approach is called Win-Win. Organizations implementing Scrum should promote an environment where employees feel comfortable to openly discuss and confront problems or issues and work through them to reach Win-Win outcomes.

Lose-Win

Some team members may at times feel that their contributions are not being recognized or valued by others, or that they are not being treated equally. This may lead them to withdraw from contributing effectively to the project and agree to whatever they are being told to do, even if they are in disagreement. This approach is called Lose-Win. This situation may happen if there are members in the team (including managers) who use an authoritative or directive style of issuing orders and/or do not treat all team members equally. This approach is not a desired conflict management technique for Scrum projects, since active contribution of every member of the team is mandatory for successful completion of each Sprint. The Scrum Master should encourage the involvement of any team members who appear to be withdrawing from conflict situations. For example, it is important for all team members to speak and contribute at each Daily Standup Meeting so that any issues or impediments can be made known and managed effectively.

Lose-Lose

In conflict situations, team members may attempt to bargain or search for solutions that bring only a partial degree or temporary measure of satisfaction to the parties in a dispute. This situation could happen in Scrum Teams where team members try to negotiate for suboptimal solutions to a problem. This approach typically involves some “give and take” to satisfy every team member—instead of trying to solve the actual problem. This generally results in an overall Lose-Lose outcome for the individuals involved and consequently the project. The Scrum Team should be careful to ensure that team members do not get into a Lose-Lose mentality. Scrum Daily Standup and other Scrum meetings are conducted to ensure that actual problems get solved through mutual discussions.

Win-Lose

At times, a Scrum Master or another influential team member may believe he or she is a de facto leader or manager and try to exert their viewpoint at the expense of the viewpoints of others. This conflict management technique is often characterized by competitiveness and typically results in a Win-Lose outcome. This approach is not recommended when working on Scrum projects, because Scrum Teams are by nature self-organized and empowered, with no one person having true authority over another team member. Although the Scrum Team may include persons with different levels of experience and expertise, every member is treated equally and no person has the authority to be the primary decision maker.
Conflict management techniques are used by team members to manage any conflicts that arise during a Scrum project. Sources of conflict evolve primarily due to schedules, priorities, resources, reporting hierarchy, technical issues, procedures, personality, and costs.

For more informative articles on Scrum and Agile, 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.

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

All about Agile Methodologies

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 methodologies 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.

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

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

Who is a Product Owner?

Before we read about how to be an effective product owner, let us first understand who a product owner is and what he/she does.  A product owner is not a separate title but is a role that can be performed by a business analyst or even a representative of an end user.

A product owner is a stakeholder who acts as an interface between the business representatives and the project team. A product owner understands the business requirements and communicates it to the team for development on behalf of the customer. A product owner is responsible for creating Prioritized Product Backlog, attending daily standup meetings, and steering the development process successfully to meet the customer’s requirements. The product owner communicates the progress of the team to the sponsor and key stakeholders. He or she also continuously refines product requirements. It is also important that a product owner has  good business sense which is important while prioritizing user stories based on cost and functionality.

A product owner must be actively involved-

The test of an effective product owner is how well he/she balances the expectations of business representatives and capability of the team to deliver. There are several ways a product owner can be more effective. A common mistake product owners make is not committing enough time to understand the requirements of the Scrum Team. Product owners should be as hands-on as possible and schedule sufficient time to holding estimation workshops, planning sprints, and providing feedback for the team.

An empowered product owner nurtures an empowered team-

Customers most often expect more value to be delivered than what the team  is capable of delivering or might suggest several changes that can slowdown the speed of the development team. A product owner supports his team by managing customer’s expectations so that workflow is not affected due to unreasonable expectations. A product owner allows the team to estimate the effort required to complete the product backlog items identified for a particular sprint. At the same time, a product owner motivates the team to deliver the product backlog items committed fora sprint on time.

Technical knowledge is essential-

It is also important that product owners have some technical knowledge, though he/she does not necessarily have to be a developer themselves. Since, they will be interacting with the team on a regular basis, having a technical background can serve well while resolving issues. Technical knowledge can also help a product owner bridge the gap between technical and business aspects of a project while liaising with developers and business representatives.

To know more,Please visit-www.scrumstudy.com

Scrum Teams Are Always Up for Time-boxing

American football teams trailing late in games often rely on a clock-management strategy known as the two-minute drill. They run hurry-up, no-huddle offenses and execute plays that involve running out of bounds (thereby stopping the clock) whenever possible. While working the ball downfield, time can become more formidable than the opposing defense.

Like the scenario above, Scrum involves teams that seek to meet a goal while battling the constraint of time. But instead of scoring touchdowns the team is creating deliverables, and instead of the two-minute drill it uses a concept called “Time-boxing.”

Time-boxing 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. Advantages include an efficient development process, less overhead and high velocity for teams.

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. Time-boxing can be used in many Scrum processes. Let’s take a look at some examples.

Sprint: A Sprint is a Time-boxed iteration of one to six weeks during which the Scrum Master guides, facilitates and shields the Scrum Team from both internal and external impediments during the Create Deliverables process. During this time, the team works to convert the requirements in the Prioritized Product Backlog into shippable product functionalities.

Daily Standup Meeting: The Daily Standup Meeting is a short daily meeting, Time-boxed to 15 minutes. The team members get together to report the progress of the project by answering the following three questions: What did I complete yesterday? What will I complete today? What impediments or obstacles (if any) am I currently facing?

Sprint Planning Meeting: This meeting is conducted prior to the Sprint as part of the Create Sprint Backlog process. It is Time-boxed to eight hours for a one-month Sprint. The Sprint Planning Meeting is divided into two parts: Objective Definition (the Scrum Team and Product Owner define the Sprint goal) and Task Estimation (the Scrum Team decides how to fulfill the Sprint goal).

Sprint Review Meeting: The Sprint Review Meeting is Time-boxed to four hours for a one-month Sprint. During the Sprint Review Meeting conducted in the Demonstrate and Validate Sprint process, the Scrum Team presents the deliverables of the current Sprint to the Product Owner. The Product Owner reviews the product against the agreed Acceptance Criteria and either accepts or rejects the completed User Stories.

Retrospect Sprint Meeting: The Retrospect Sprint Meeting is Time-boxed to 4 hours for a one-month Sprint and conducted as part of the Retrospect Sprint process. During this meeting, the Scrum Team discusses what went well during the previous Sprint and what did not go well, the goal being to learn and make improvements in the Sprints to follow.

Sports teams and Scrum Teams alike benefit from a healthy respect for the clock. When working in a Sprint, it is important for Scrum Team members to focus on velocity as much as quality. When this is achieved, add one to the win column.

To know more,Please visit-www.scrumstudy.com

How to Estimate Project Value

Business justification is first assessed prior to a project being initiated and is continuously verified throughout the project lifecycle. This is a very important step in Scrum framework. The project should make business sense in each and every part of its lifecycle. Estimation of the project value is a major way of establishing business justification. Estimating the project value helps the decision makers make the vital decision such as to continue with the existing project or not.

The guide to Scrum body of knowledge (SBOK) provides insights into various methods which can be used to effectively measure the project value to aid the Scrum team in making very important strategic decisions. The value to be provided by business projects can be estimated using various methods such as Return on Investment (ROI), Net Present Value (NPV) and Internal Rate of Return (IRR).

The value to be provided by business projects can be estimated using various methods such as Return on Investment (ROI), Net Present Value (NPV), and Internal Rate of Return (IRR).

1.       Return on Investment (ROI)

Return on Investment (ROI) when used for project justification, assesses the expected net income to be gained from a project. It is calculated by deducting the expected costs or investment of a project from its expected revenue and then dividing this (net profit) by the expected costs in order to get a return rate. Other factors such as inflation and interest rates on borrowed money may be factored into ROI calculations.

ROI formula: ROI = (Project Revenue – Project Cost) / Project Cost

Here is an example for ROI:

The ROI for a project that will cost $125,000 to develop, with expected financial benefits estimated at $300,000 is calculated as follows:

ROI = ($300,000 – $125,000) / $125,000 = 1.4

Therefore, the ROI is 1.4 times the investment (or 140%).

Frequent product or service increments is a key foundation of Scrum that allows earlier verification of ROI. This aids in assessing the justification of continuous value.

2.       Net Present Value (NPV)

Net Present Value (NPV) is a method used to determine the current net value of a future financial benefit, given an assumed inflation or interest rate. In other words, NPV is the total expected income or revenue from a project, minus the total expected cost of the project, taking into account the time-value of money.

Here is an example for Net Present Value:

Which of the following two projects is better to select if NPV is used as the selection criterion?

• Project A has a NPV of $1,500 and will be completed in 5 years.
• Project B has a NPV of $1,000 and will be completed in 1 year.

Solution: Project A, since its NPV is higher; the fact that Project B has a shorter duration than Project A is not considered here, because time is already accounted for in the NPV calculations (i.e., due to the fact that it is the current, not future value that is being considered in the calculation).

3.       Internal Rate of Return (IRR)

Internal Rate of Return (IRR) is a discount rate on an investment in which the present value of cash inflows is made equal to the present value of cash outflows for assessing a project’s rate of return. When comparing projects, one with a higher IRR is typically better.

Though IRR is not used to justify projects as often as some other techniques, such as NPV, it is an important concept to know.

Here is an example for Internal Rate of Return:

  Based on IRR, which project is most desirable?

• Project A, which has an IRR of 15% and will be completed in 5 years.
• Project B, which has an IRR of 10% and will be completed in 1 year.

Solution: Project A, since its IRR is higher; the fact that Project B has a shorter duration than Project A is not considered here because time is already taken into account in the IRR calculations (i.e., as with NPV, it is the current, not future value that is used to determine the IRR).

To know more,Please visit-www.scrumstudy.com