Software design and implementation Model

Spiral Model:

Agile Model:

Kanban Vs Scrum

Difference between Kanban and Scrum:

• Iterations : Kanban sees development as a forever ongoing flow of things to do where as in Scrum you work in iterations.
• Commitment : Kanban is ongoing where as in Scrum a team commits to what they will do during a sprint.
• Estimations : In Kanban it’s optional since focus is on time-to-market. In Scrum you need to estimate to be able to have a velocity.
• Cross-functional teams : That’s one of the pillars of Scrum. For Kanban it’s optional.
• Workflow : The Kanban Method does not prescribe any workflow. Scrum prescribes a set of activities that are performed within a Sprint.
• Roles : Kanban does not prescribe any roles. Scrum generally prescribes three roles, Scrum Master, Product Owner, and Team Member.
• System Thinking : The Kanban Method takes a system thinking approach to process problems. Scrum is team-centric.

	Kanban	Scrum
Board / Artifacts	board only	board, backlogs, burn-downs
Ceremonies	daily scrum, review/retrospeective on set frequency and planning ongoing	daily scrum, sprint planning, spring review, sprint retrospective
Iterations	no (continuous flow)	yes (sprints)
Estimation	no (similar size)	yes
Teams	can be specialized	must be cross-functional
Roles	Team + need roles	Product Owner, Scrum Master, Team
Teamwork	swarming to achieve goals	collaborative as needed by task
WIP	controlled by worklfow state	controlled by sprint content
Changes	added as nedded on the borad (to do)	should wait for the next sprint
Product Backlog	just in time cards	list of prioritized and estimated stories
Impediments	avoided	dealt with immediately

Agile Software Development using Scrum

Many software development organizations are striving to become more agile, because successful agile teams are producing higher-quality software that better meets user needs more quickly and at a lower cost than are traditional teams.
Below attributes makes transition to Scrum more difficult than other changes:

• Successful change is not entirely top-down or bottom-up.
• The end state is unpredictable.
• Scrum is pervasive.
• Scrum is dramatically different.
• Change is coming more quickly than ever before.
• Best practices are dangerous.

Despite all the reasons why transitioning to Scrum can be particularly difficult, it worth effort because it reduces time-to-martket due to higher productivity of agile teams. Below reasons shows why transitioning to an agile process like Scrum is worthwhile:

• Higher productivity and lower costs
• Improved employee engagement and j ob satisfaction
• Faster time to market
• Higher quality
• Improved stakeholder satisfaction
• What we've been doing no longer works

The five common activities necessary for a successful and lasting Scrum adoption:

• Awareness that the current process is not delivering acceptable results
• Desire to adopt Scrum as a way to address current problems
• Ability to succeed with Scrum
• Promotion of Scrum through sharing experiences so that we remember and others can see our successes
• Transfer of the implications of using Scrum throughout the company

Conveniently, these five activities - Awareness, Desire, Ability, Promotion, and Transfer - can be remembered by the acronym ADAPT. These activities are also summarized in below figure.

Agile : Planning Poker

Planning poker, also called Scrum poker, is a consensus-based technique for estimating, mostly used to estimate effort or relative size of user stories in software development. Planning Poker is a technique to determine user story size and to build consensus with the development team members. Planning poker is a popular and straightforward approach to estimating story size.

The method was first defined and named by James Grenning in 2002 and later popularized by Mike Cohn in the book Agile Estimating and Planning, whose company trade marked the term.

To start a poker planning session, the product owner or customer reads a agile user story or describes a feature to the estimators. Each estimator is holding a deck of Planning Poker cards with values like 0, 1, 2, 3, 5, 8, 13, 20, 40 and 100, which is the sequence we recommend. The values represent the number of story points, ideal days, or other units in which the team estimates. The estimators discuss the feature, asking questions of the product owner as needed. When the feature has been fully discussed, each estimator privately selects one card to represent his or her estimate. All cards are then revealed at the same time. Only the development team plays estimation poker. The team lead and product owner don’t get a deck and don’t provide estimates. However, the team lead can act as a facilitator, and the product owner reads the user stories and provides details on user stories as needed.

"Planning Poker is a good way to come to a consensus without spending too much time on any one topic. It allows, or forces, people to voice their opinions, thoughts and concerns."
- Lori Schubring, Manager, Bemis Manufacturing Company

Planning poker benefits
Planning poker is a tool for estimating software development projects. It is a technique that minimizes anchoring by asking each team member to play their estimate card such that it cannot be seen by the other players. After each player has selected a card, all cards are exposed at once. Anchoring can occur if a team estimate is based on discussion alone. A team normally has a mix of conservative and optimistic estimators and there may be people who have agendas; developers are likely to want as much time as they can to do the job and the product owner or customer is likely to want it as quickly as possible. Planning poker exposes the potentially influential team member as being isolated in his or her opinion among the group. It then demands that she or he argue the case against the prevailing opinion. If a group is able to express its unity in this manner they are more likely to have faith in their original estimates. If the influential person has a good case to argue everyone will see sense and follow, but at least the rest of the team won't have been anchored; instead they will have listened to reason.