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 please 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 please visit www.SCRUMstudy.com

Various Activities in Scrum Processes

Scrum processes address the specific activities and flow of a Scrum project. In total there are 19 processes which are grouped into five phases.

Please take a look at these processes and the activities listed under to them in order to understand the flow of a Scrum Project better.

Initiate

1. Create Project Vision—in this process, the Project Business Case is reviewed to create a Project Vision Statement that will serve as the inspiration and provide focus for the entire project. The Product Owner is identified in this process.
2. Identify Scrum Master and Stakeholder(s)—in this process, the Scrum Master is identified using specific Selection Criteria.
3. Form Scrum Team—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.
4. Develop Epic(s)—in this process, the Project Vision Statement serves as the basis for developing Epic(s). User Group Meetings may be held to develop Epic(s).
5. Create Prioritized Product Backlog —in this process, Epic(s) are refined, elaborated, and then prioritized to create a Prioritized Product Backlog for the project. The Done Criteria is also established at this point.
6. Conduct Release Planning—in this process, the Scrum Core Team reviews the User Stories in the Prioritized Product Backlog to develop a Release Planning Schedule, which is essentially a phased deployment schedule that can be shared with the project stakeholders. Length of Sprint is also determined in this process.

Plan and Estimate

1. Create User Stories—In this process User Stories and their related User Story Acceptance Criteria are created. User Stories are usually written by the Product Owner and are designed to ensure that the customer’s requirements are clearly depicted and can be fully understood by all stakeholders. User Story Writing Exercises may be held which involves Scrum Team members creating the User Stories. User Stories are incorporated into the Prioritized Product Backlog.
2. Approve, Estimate, and Commit User Stories—In this process the Product Owner approves User Stories for a Sprint. Then, the Scrum Master and Scrum Team estimate the effort required to develop the functionality described in each User Story, and the Scrum Team commits to deliver the customer requirements in the form of Approved, Estimated, and Committed User Stories.
3. Create Tasks—In this process the Approved, Estimated, and Committed User Stories are broken down into specific tasks and compiled into a Task List. Often a Task Planning Meeting is held for this purpose.
4. Estimate Tasks—In this process the Scrum Core Team, in Task Estimation Meetings, estimate the effort required to accomplish each task in the Task List. The result of this process is an Effort Estimated Task List.
5. Create Sprint Backlog—In this process the Scrum Core Team holds Sprint Planning Meetings where the group creates a Sprint Backlog containing all tasks to be completed in the Sprint.

Implement

1. Create Deliverables—In this process, the Scrum Team works on the tasks in the Sprint Backlog to create Sprint Deliverables. A Scrumboard is often used to track the work and activities being carried out. Issues or problems being faced by the Scrum Team could be updated in an Impediment Log.
2. Conduct Daily Standup—In this process, everyday a highly focused, Time-boxed meeting is conducted referred to as the Daily Standup meeting. This is the forum for the Scrum Team to update each other on their progress and any impediments they may be facing.
3. Groom Prioritized Product Backlog—In this process, the Prioritized Product Backlog is continuously updated and maintained. A Prioritized Product Backlog Review Meeting may be held, in which any changes or updates to the backlog are discussed and incorporated into the Prioritized Product Backlog as appropriate.

Review and Retrospect

1. Convene Scrum of Scrums—In this process Scrum Team representatives convene for Scrum of Scrums Meetings in predetermined intervals or whenever required to collaborate and track their respective progress, impediments, and dependencies across teams. This is relevant only for large projects where multiple Scrum Teams are involved.
2. Demonstrate and Validate Sprint—In this process, the Scrum Team demonstrates the Sprint Deliverables to the Product Owner and relevant stakeholders in a Sprint Review Meeting. The purpose of this meeting is to secure approval and acceptance from the Product Owner for the Deliverables created in the Sprint.
3. Retrospect Sprint—In this process, the Scrum Master and Scrum Team meet to discuss the lessons learned throughout the Sprint. This information is documented as lessons learned which can be applied to future Sprints. Often, as a result of this discussion, there may be Agreed Actionable Improvements or Updated Scrum Guidance Body Recommendations.

Release

1. Ship Deliverables—In this process, Accepted Deliverables are delivered or transitioned to the relevant stakeholders. A formal Working Deliverables Agreement documents the successful completion of the Sprint.
2. Retrospect Project—In this process, which completes the project, organizational stakeholders and Scrum Core Team members assemble to retrospect the project and identify, document, and internalize the lessons learned. Often, these lessons lead to the documentation of Agreed Actionable Improvements, to be implemented in future projects.

To know more please visit www.SCRUMstudy.com

How can marketing team benefit from Scrum?

Scrum as an Agile methodology is currently most popular in IT development teams. However, that does not mean that it cannot be effectively used in other domains. In fact, as an Agile methodology of managing projects, it can be used wherever people work on projects on a regular basis. It can be used in a particular division of a company – like new product development in an automobile company, and can also be used in a particular function of a company – like marketing. This article will highlight how Scrum methods can be used very effectively to manage marketing projects.

Marketing as a function revolves around projects. Marketing professionals work on a variety of projects – ad campaigns, email campaigns, product prototyping, market research etc. More time is spent on projects rather than operational activities. Hence, Scrum can be especially beneficial for marketing teams.

Let’s say the marketing team is tasked with the project of launching a new car model. How can it use Scrum? Well, it actually is quite simple (one of the basic objectives of Scrum – to keep it simple). You start off with stating the project vision – launching the car in a defined area, say, the state of California. Then you need someone to spearhead the whole project – the Scrum Master. He/she will decide who all will be part of the Scrum team. These have to be people who will actually be doing the various tasks in the project and not the ones who simply have an interest in the project.

So now you have the people who will be working on the Scrum project. What next? The team needs to understand the customer requirements. These are defined in the form of User Stories. In our case, two of the user stories might be ‘I need to test drive the car before I buy it’ and ‘I need to know all its performance specifications’.

The User Stories are approved and entered into what is called the Prioritized Product Backlog. It is the master document which guides the team in the project. It contains the User Stories and the tasks which are required to fulfill the requirements for each of the user stories. So in our example, the first User Story about test drives will include tasks like ‘Decide number and variants of test cars needed’, ‘Brand the test cars’, ‘Create a test drive feedback form’, ‘Decide on the tasks to be performed by the salesperson before the test drive’, etc. It then decides on a Release Planning Schedule which lays out the schedule of shipping out completed deliverables to the customers. The team then estimates the time required for the various tasks. Based on the above, a collective decision is taken on which all tasks will be taken up in the first round – called Sprint in Scrum. A Sprint duration can vary from a week to a few weeks.

The team then works on completing the tasks in a particular Sprint. To ensure that things are on track, the Scrum team has a Daily Standup Meeting which is time-boxed to normally 15 minutes to half an hour, in which all the members stand around and discuss the status of the different tasks. Tasks are entered in post-it notes and stuck on to a whiteboard with 3 columns – ‘To be done’, ‘In Process’ and ‘Completed’.  The team then works on the tasks from the first column to the third column. At the end of a Sprint, when the team has hopefully completed all the tasks, a Sprint Review Meeting takes place where the team discusses what went right and what are the improvement opportunities. At designated points in time as laid out in the Release Planning Schedule, the team ships out completed deliverables.

This process continues till all the deliverables and tasks are completed in the Scrum project. The high level of involvement and communication involved in the Daily Standup Meetings is the key to an effective implementation of Scrum. Thus, by following the above process, marketing teams can ensure speedy completion of projects with high quality outputs without getting bogged down by a lot of documentation and processes.

To know more please 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 please 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 please visit www.SCRUMstudy.com

Roles and Responsibilities of a Scrum Master

The first thing we have to be sure when dealing with SCRUM master is whether they have a full time Scrum masters, and the second question we have to ask is if what do they do?

We usually don’t find a full time scrum master.  Scrum master is described by scrum guide as one who teaches, facilitates and removes impediments. When the team is relatively new it takes time and the team follows scrum religiously. This is when the team needs a scrum master who can teach scrum full time.

Facilitating is necessary, though it takes only 20 to 30 % of the time. The issues tend to lessen as the team learns to resolve them.

If a person puts 100% of his efforts being a scrum master, i.e. if he is training, facilitating that takes up only 20 to 25% of his time. He has to devote himself in helping the team with their work.

The first step is to train the project managers in Agile. Try to get them to be certified scrum masters, and agile project managers, preferably from Project Management Institute.

Thus the project managers become the first scrum masters.  At first the scrum master shouldn’t be assigned to one team.

Probably assign two to three teams to one project managers. Their role is to train the team in Scrum.

This has to be followed for the initial six months, until the team gets used to the concept of Scrum.

Then once you are past the first 6 to 9 months have one of the team members to be a scrum master, it would be ideal if the team was allowed to select the scrum master from their team.

Then elevate the project manager to the level of program manager. This would enable them to become accountable for cross team initiatives,

Rearrange management structure, now instead of a functional manager we have a delivery manager.

The delivery manager is now accountable for training agile.

Thus Scrum Masters was underway as a position and evolved to be a role as the team becomes more Agile mature.

The bottom line here is we have less people doing same amount of work. This is without the need of a dedicated scrum master, Along with this we need to have a contingent plan.

To know more please visit www.SCRUMstudy.com