Scrum and Kanban, alike or different?

One of the criteria for selecting an agile tool in terms of Kanban or Scrum can be the time required. One of these methodology works well when there is shortage of time in terms of deadlines; the other one works well in situations where more time is required to carry out tasks when a diminutive iteration cannot satisfy the work. Testing should be carried out at all levels and processes as perpetual testing can only raise the level of quality in terms of software or a code.

Kanban processes can enable enhancement of the quality of software from its commencement till project delivery. The reason, as we know, is because of its focus on system thinking. Kanban restricts the capacity of tasks which can be found anywhere in the complete cycle of the work-in-progress limit. This can be advantageous too as total focus can be directed towards solitary work packages one at a time and ensuring thus the quality of the outcome. In situations entailing releases within a less time period, Kanban is a good choice as since total focus is given toward single tasks, rendering them ‘completed’ once they are done with. So, Kanban works fine in this type of scenario.

Good quality is what one can see with relation to the work right from the conception to the end. Understanding the requirements, design related with transitioning activities, development activities, testing and ending with releasing is how the Kanban workflow would contain right from the conceptual stage.

Project managers prefer Scrum better than Kanban. It is more oriented toward systems while Scrum has a close affinity with project managers and stakeholders due to their presentation of processes and events. Both their workflows are alike, with the only exception of Scrum having their deadlines better demarcated.

Segregation of the quantity of work that would be possible to be done within a particular time frame is one of the advantages of using Scrum.

Both approaches are more or less about effective change management in the sense that they are very much alike pertaining to learning curves, focus, progress and change.

 To know more visit WWW.SCRUMstudy.com

7 C’s of Scrum

Scrum is an iterative and incremental product development framework which ensures that the highest value is delivered to the consumer or the customer. 7 C’s of Scrum are the characteristics which ensure the highest value delivery through scrum framework. These C’s are discussed below:

1. Consumer Centric: The focus of the Product Owner, Scrum Master and The Scrum Team is to understand the Consumer requirements, meet the acceptance criteria of the products, deliver high value and in turn have a satisfied customer.
2. Continuous Delivery of Value: Ship deliverable process ensures that there is continuous development and delivery of the project deliverables rather than completing the project in one go and delivering it to the client.
3. Constant Feedback: Daily Stand-up meetings are held wherein each of the scrum team members will let the other team members know about the work he completed yesterday and what he will do today. Also, he let others know about the difficulties he faced in completing the deliverable. The Scrum Master then will work to remove the impediments obstacles faced by the team members.
4. Continuous Improvement: Scrum is an iterative, incremental process in which the errors are identified quickly and also there is scope to change the features of the product under development and add new features to it with less cost. This leads to overall reduced cost of errors at the end of the project.
5. Compliance: The continuous feedback, flexibility and adaptive nature of the Scrum Teams will help in incorporating the new requirements and changes easily. There is also sprint retrospect meetings held to ensuring the deliverables are in compliance with the requirements.
6. Clarity: All the team members share their knowledge and work progress. They ensure information sources of the work in process like the Burndown chart are accessible to all the team members and hence there is clarity among the team members about the project progress.
7. Collective Ownership: The team members are involved in Estimating the tasks and efforts and approving the user stories. They are empowered to take decision and hence this allows them to take the ownership of the tasks.These are the C’s of Scrum which ensure that the products or Service developed by the Scrum Team is with minimal errors and reduced cost of errors and rejections.

To know more visit WWW.SCRUMstudy.com

What justifies your Project?

A routine question before starting a project is “Why is this needed?” Such a question might be posed by primary school students who are assigned to create a diorama about the water cycle. But the question is just as likely to be raised when dealing with large projects in the corporate world. The answer to “Why is this needed” lies in the business justification, which includes the reasons for undertaking a project, according to A Guide to the Scrum Body of Knowledge (SBOK^™).

Business justification drives decision making, so it is important to assess the potential of a project before committing to significant investment at early stages and to verify the business justification throughout the lifecycle. A project should be terminated if it is deemed unviable. The decision should be escalated to relevant stakeholders and senior management. The business justification for a project must be assessed at the beginning of the project, at pre-defined intervals and at any time when major issues or risks emerge that threaten viability.

There are numerous factors a Product Owner must consider to establish the business justification for a project. Here are some of the more important ones:

• Project Reasoning: Includes all factors that necessitate the project, whether positive or negative, chosen or not. Examples include inadequate capacity to meet existing and forecasted demand, decrease in customer satisfaction, low profit and legal requirement.
• Business Needs: Those business outcomes that the project is expected to fulfill, as documented in the Project Vision Statement.
• Project Benefits: Include all measurable improvements in a product, service or result that could be provided through successful completion of the project.
• Opportunity Cost: Determine the value of the next best business option or project that was discarded in favor of the current project.
• Major Risks: Include any uncertain or unplanned events that may affect the viability and potential success of the project.
• Project Timescales: Reflect the length or duration of a project and the time over which its benefits will be realized.
• Project Costs: Investment and other development costs for a project. Business justification is first assessed prior to a project being initiated and is continuously verified throughout the project lifecycle.

Let’s take a look at how business justification is determined:

Assess and Present a Business Case: Business justification for a project is typically analyzed and confirmed by the Product Owner. It is documented and presented in the form of a project Business Case prior to the Initiate phase. Once documented, the Product Owner should create a Project Vision Statement and obtain its approval from the key decision-makers in the organization. Generally, this consists of executives or some form of a project or program management board.

Continuous Value Justification: Once the decision makers approve the Project Vision Statement, it is then baselined and forms the business justification. The business justification is validated throughout project execution, typically at predefined intervals or milestones, such as during portfolio, program and Prioritized Product Backlog Review Meetings and when major issues and risks that threaten project viability are identified. This could happen in several Scrum processes including Conduct Daily Standup and Groom Prioritized Product Backlog. Throughout the project, the Product Owner should keep the business justification in the Project Vision Statement updated with relevant project information to enable the key decision makers to continue making informed decisions.

Confirm Benefits Realization: The Product Owner confirms the achievement of organizational benefits throughout the project as well as upon completion of the User Stories in the Prioritized Product Backlog. Benefits from Scrum projects are realized during Demonstrate and Validate Sprint, Retrospect Sprint, Ship Deliverables and Retrospect Project processes. When you’re in school, you can scrap a project at any point and the only thing that’s on the line is an assignment grade. But unacceptable project results in the professional world are far-reaching. To give yourself the best opportunity for success, you should always ask “Why is this needed?” and lean on the business justification to find your answer.

 To know more visit WWW.SCRUMstudy.com

What are the Cultural Challenges in adopting SCRUM Methodology?

Scrum methodology is being used as a successful Project Management or Product Management process in many organizations. It’s been gaining in popularity over the last 15 years, as more and more organizations realize the benefits of Scrum. But before a particular team/organization embraces Scrum or any other Agile process, the biggest hindrance comes from the management, which is generally resistant to change, even in the face of evidence.

Let’s look at some of the cultural challenges and how to overcome them:

1. Independent Decision Making: Scrum encourages independent thinking and decision making, while in most corporate structure, a top-down process of decision making takes places. Also, larger the organization more will be the hierarchies, and independent decision making becomes that much more difficult. To overcome this problem, senior management buy-in is a must, and they have to be convinced of the benefits of religiously following Scrum as a practice.
2. Customer Relationship: Generally, a traditional vendor-supplier relationship between the organization and the client will not augur well for practicing Scrum. Customers have to get much more involved with the development team, and periodic feedback becomes the norm rather than exception. Here again, the client can appreciate the effort being put in by the development team, if they are closely involved in the planning the backlog and sprint items.
3. Quality Philosophy: In a traditional structure, quality teams focus a lot on metrics and charts and graphs etc., while Scrum lays emphasis on Collaborative Approach. What it means is that e.g. Testing is not done only by a Tester, but also by a Business Analyst or Technical Manager. Every member of the Scrum team takes the responsibility of bringing in Quality in the development process, and every member contributes to Quality and Process Improvement. Basically, this change of approach means delegating authority, which may face stiff resistance from QA and Testing managers.
4. Sustainable Pace of Development: In the traditional process, testing and bug fixing happens during the last few weeks of the project phase, wherein everyone from the developers to the technical architects to the testers work overtime and during weekends to complete the task. Agile on the other hand is all about sustainable pace of development, wherein every sprint, the code will be developed and tested. Although this process reduces uncertainty and hastiness, the fact that testers are not used to work in this kind of environment, and their acceptance will take time. To counter this issue, during the first few Scrum Projects, when everyone is new to Agile, testing should be handled by a team of tester rather than a single tester. They will collaborative and work on issues, which will make them comfortable in this process. Later on, they can independently handle different projects.

To know more visit WWW.SCRUMstudy.com
 

Is ‘Change’ accepted in Scrum?

Every project, regardless of its method or framework is exposed to change. It is imperative that project team members understand that the Scrum development processes are designed to embrace change. Organizations should try to maximize the benefits that arise from change and minimize any negative impacts through diligent change management processes in accordance with the principles of Scrum.

In today’s hypercompetitive world where technology, market conditions, and business patterns are continuously shifting, change is the only constant. A primary principle of Scrum is its acknowledgement that a) stakeholders (e.g., customers, users, and sponsors) do change their minds about what they want and need throughout a project (sometimes referred to as “requirements churn”) and b) that it is very difficult, if not impossible, for stakeholders to define all requirements during project initiation.

Scrum development projects welcome change by using small development cycles that incorporate customer feedback on the project’s deliverables after each Sprint. This enables the customer to regularly interact with the Scrum Team members, view product increments as they are ready, and change requirements earlier on in the development cycle. Also, the portfolio or program management teams can respond to Change Requests pertaining to Scrum projects applicable at their level.

 To know more visit WWW.SCRUMstudy.com

Ensuring your team does not have too much or too little to do!

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.

Scrum Time-Boxes

Sprint—A Sprint is a Time-boxed iteration of one to six weeks in duration, during which the Scrum Master guides, facilitates, and shields the Scrum Team from both internal and external impediments during the Create Deliverables process. This aids in avoiding vision creep that could affect the Sprint goal. During this time, the team works to convert the requirements in the Prioritized Product Backlog into shippable product functionalities. To get maximum benefits from a Scrum project, it is always recommended to keep the Sprint Time-boxed to 4 weeks, unless there are projects with very stable requirements, where Sprints can extend up to 6 weeks.

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:

1. What did I complete yesterday?
2. What will I complete today?
3. Am I facing any impediments?

This meeting is carried out by the team as part of the Conduct Daily Standup process.

Sprint Planning Meeting—This meeting is conducted at the beginning of a Sprint as part of 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:

1.               I.      Objective Definition—During the first half of the meeting, the Product Owner explains the highest priority User Stories or requirements in the Prioritized Product Backlog to the Scrum Team. The Scrum Team in collaboration with the Product Owner then defines the Sprint goal.
2.            II.      Task Estimation—During the second half of the meeting, the Scrum Team decides “how” to complete the selected Prioritized Product Backlog Items 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 that is 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 (or product increment) 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 gets together to review and reflect on the previous Sprint in terms of the processes followed, tools employed, collaboration and communication mechanisms, and other aspects relevant to the project. The 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. Some improvement opportunities or best practices from this meeting could also be updated as part of the Scrum Guidance Body documents.

 To know more visit WWW.SCRUMstudy.com

How to form a Scrum Team?

Forming a Scrum Team, is nothing but another process in the Scrum Project. It is one of the 6 process in the Initiate Phase. In this process, Scrum Team members are identified. Normally the Product Owner has the primary responsibility of selecting team members, but often does so in collaboration with the Scrum Master.

The Scrum Team is the core of any Scrum project and getting the right team members is important for successful delivery of Scrum projects. Scrum Team members are generalist-specialists in that they have knowledge of various fields and are area experts in at least one.

Beyond their subject-matter expertise, it is the soft skills of team members that determine the success of self-organizing teams.

Ideal members of the Scrum Team are independent, self-motivated, customer-focused, responsible, and collaborative. The team should be able to foster an environment of independent thinking and group decision-making in order to extract the most benefits from the structure.

The Scrum Team, sometimes referred to as the Development 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.

Scrum Teams are cross-functional and self-organizing. The team decides the amount of work to commit to in a Sprint and determines the best way to perform the work. The Scrum Team consists of cross-functional team members, who carry out all the work involved in creating potentially shippable deliverables including development, testing, quality assurance, etc.

Identifying the Scrum Team is the responsibility of the Product Owner, often in consultation with the Scrum Master.

Team Building Plan

Since a Scrum Team is cross-functional, each member needs to participate actively in all aspects of the project. The Scrum Master should identify issues with team members and address them diligently in order to maintain an effective team.

To build team cohesion, the Scrum Master should ensure that relationships among the team members are positive and that the team members are unified in achieving the overall project and organizational goals, thus leading to greater efficiency and increased productivity.

In this context, it is important to study popular HR theories and their relevance to Scrum. Continue with our posts to learn more on Scrum Methodology, Scrum Certification and Scrum Management.

To know more visit WWW.SCRUMstudy.com
 

Is Value-Driven Delivery the Key to Scrum’s Success?

One of the aspects of Scrum that attracts business stakeholders is the delivery of maximum business value in minimum span of time. To achieve this goal, Scrum is relies on the principle of value-driven delivery. Also, as projects involve collaborative effort to either create new products or services or to deliver results as defined in the Project Vision Statement, they are usually affected by constraints of time, cost, scope, quality, people and organizational capabilities.

To overcome these constraints, value-driven delivery must be the main focus. Scrum facilitates delivery of value very early on in the project and continues to do so throughout the project lifecycle. One of the key characteristics of any project is the uncertainty of results or outcomes. It is impossible to guarantee project success at completion, irrespective of the size or complexity of a project. Considering this uncertainty of achieving success, it is therefore important to start delivering results as early in the project as possible. This early delivery of results, and thereby value, provides an opportunity for reinvestment and proves the worth of the project to interested stakeholders.

In order to provide value-driven delivery, it is important to:

• Understand what adds value to customers and users and to prioritize the high value requirements on the top of the Prioritized Product Backlog
• Decrease uncertainty and constantly address risks that can potentially decrease value if they materialize. Also work closely with project stakeholders and show them product increments as each is created and allow them to manage changes effectively.
• Create deliverables based on the priorities determined by producing potentially shippable product increments during each Sprint so that customers start realizing value early on in the project.

The concept of value-driven delivery in Scrum is quite different when compared with the principles of traditional project management models where:

• Requirements are not always prioritized on the basis of business value.
• Changing requirements after project initiation is difficult and can only be done through the implementation of a time consuming change management process.
• Value is realized only at the end of the project when the final product or service is delivered.

Thus value-based delivery helps in delivering the maximum business value in the least amount of time to the customers and becomes one of the key aspects behind the success of Scrum.

To know more visit WWW.SCRUMstudy.com

Business Justification in SCRUM

Business justification is first assessed prior to a project being initiated and is continuously verified throughout the project lifecycle. The following steps capture how business justification is determined:

1. Assess and Present a Business Case

Business justification for a project is typically analyzed and confirmed by the Product Owner. It is documented and presented in the form of a project Business Case prior to Initiate phase and involves considering the various factors. Once documented, the Product Owner should create a Project Vision Statement and obtain approval of the Project Vision Statement from the key decision-makers in the organization. Generally, this consists of executives and/or some form of a project or program management board.

2. Continuous Value JustificationOnce the decision makers approve the Project Vision Statement, it is then baselined and forms the business justification. The business justification is validated throughout project execution, typically at predefined intervals or milestones, such as during portfolio, program, and Prioritized Product Backlog Review Meetings and when major issues and risks that threaten project viability are identified. This could happen in several Scrum processes. Throughout the project, the Product Owner should keep the business justification in the Project Vision Statement updated with relevant project information to enable the key decision makers to continue making informed decisions.

3. Confirm Benefits Realization

The Product Owner confirms the achievement of organizational benefits throughout the project, as well as upon completion of the User Stories in the Prioritized Product Backlog.

Analysis of business justification helps decision makers in understanding the business need for a change or for a new product or service and the need for moving forward with a project. It also helps the Product Owner to create a Prioritized Product Backlog along with the business expectations of Senior Management & Stakeholder(s).

 To know more visit WWW.SCRUMstudy.com

What is Self-Organizing?

Scrum believes that employees are self-motivated and seek to accept greater responsibility. So, they deliver much greater value when self-organized. The preferred leadership style in Scrum is “servant leadership”, which emphasizes achieving results by focusing on the needs of the Scrum Team. Self-organization does not mean that team members are allowed to act in any manner that they want to. It just means that once the Product Vision is defined, the Product Owner, Scrum Master, and Scrum Team get identified. Also the Scrum Core Team itself works very closely with relevant Stakeholder(s) for refining requirements better. Team expertise is used to assess the inputs needed to execute the planned work of the project. This judgment and expertise are applied to all technical and management aspects of the project.

Self-organization as an essential principle in Scrum leads to the following:

• Team buy-in and shared ownership
• Motivation, which leads to an enhanced performance level of the team
• Innovative and creative environment conducive to growth

Although prioritization is primarily done by the Product Owner who represents the Voice of Customer, the self-organized Scrum Team is involved in task breakdown and estimation. During these processes, each team member is responsible for determining what work he or she will be doing. During the execution of a Sprint, if team members need any help with completing their tasks, Scrum addresses this through the regular interaction mandatory with the Daily Standup Meetings. The Scrum Team itself interacts with other teams through the Scrum of Scrums (SoS) Meetings and can look for additional guidance as required from the Scrum Guidance Body.

Finally, the Scrum Team and Scrum Master work closely to demonstrate the product increment created during the Sprint where properly completed deliverables are accepted. Since the Deliverables are potentially shippable, (and the Prioritized Product Backlog is prioritized by User Stories in the order of value created by them), the Product Owner and the customer can clearly visualize and articulate the value being created after every Sprint; and Scrum Teams in turn have the satisfaction of seeing their hard work being accepted by the customer and other stakeholders.

 To know more visit WWW.SCRUMstudy.com

Tools to Create Project Vision

A Guide to the Scrum Body of Knowledge (SBOK™) suggests four tools for the Create Project Vision process: Project Vision Meeting, JAD sessions, SWOT Analysis and Gap Analysis. With some soft skills and reliance on the dozen or more inputs possible for this process, you can keep the statement focused and usable.

The Project Vision Meeting

This meeting pulls together the Program Stakeholders, Program Product Owner, Program Scrum Master and Chief Product Owner or company equivalents. These participants help identify the business context, business requirements, and stakeholder expectations in order to develop an effective Project Vision Statement. Scrum believes in closely engaging and collaborating with all business representatives to get their buy-in for the project and to deliver greater value.

JAD Sessions

A Joint Application Design (JAD) Session is a requirements gathering technique. It is a highly structured, facilitated workshop that enables Stakeholders and other decision makers to arrive at a consensus on the scope, objectives and other specifications of the project.

Each session consists of methods for increasing user participation, speeding development and improving specifications. Relevant Program Stakeholders, Program Product Owner, Program Scrum Master and Chief Product Owner often use these sessions to outline and analyze desired business outcomes and focus their vision for the Scrum project.

SWOT Analysis

SWOT is a structured approach to project planning that helps evaluate the Strengths, Weaknesses, Opportunities and Threats related to a project. This type of analysis helps identify both the internal and the external factors that could impact the project. Strengths and weaknesses are internal factors, whereas opportunities and threats are external factors. Identification of these factors helps stakeholders and decision makers provide direction to the processes, tools and techniques to be used to achieve the project objectives. Conducting a SWOT Analysis allows the early identification of priorities, potential changes and risks.

Gap Analysis

This tool is a technique used to compare the current, actual state with some desired state. In an organization, it involves determining and documenting the difference between current business capabilities and the final desired set of capabilities. A project is normally initiated to bring an organization to the desired state, so conducting a Gap Analysis would help decision makers determine the need for a project. A Gap Analysis can look at current offerings and identify opportunities for products that are lacking in a particular market. Likewise, it can be used to identify missing software functionalities that can be developed into profitable products or services.

To know more visit WWW.SCRUMstudy.com