Kanban

Kanban is a method for managing the creation of products with an emphasis on continual
delivery while not overburdening the development team. Like Scrum, Kanban is a process
designed to help teams work together more effectively.

Kanban is based on 3 basic principles:

 Visualize what you do today (workflow): seeing all the items in context of each other can be
very informative
 Limit the amount of work in progress (WIP): this helps balance the flow-based approach so
teams don€ ™t start and commit to too much work at once
 Enhance flow: when something is finished, the next highest thing from the backlog is pulled
into play

Benefits of Kanban:

Shorter cycle times can deliver features faster.

Responsiveness to Change:

When priorities change very frequently, Kanban is ideal.

Balancing demand against throughput guarantees that most the customer-centric features are
always being worked.

Requires fewer organization / room set-up changes to get started

Reducing waste and removing activities that don’t add value to the team/department/organization

Rapid feedback loops improve the chances of more motivated, empowered and higher-
performing team members
 Kanban Scrum

Pre-defined roles of Scrum master,

No prescribed roles
Product owner and team member

Continuous Delivery Timeboxed sprints

Work is € ˜ pulled€ ™ through the Work is € ˜ pulled€ ™ through the system

system (single piece flow) in batches (the sprint backlog)

Changes can be made at any time No changes allowed mid-sprint

Cycle time Velocity

More appropriate in operational More appropriate in situations where

environments with a high degree of work can be prioritized in batches that can
variability in priority be left alone

XP: Extreme Programming

Extreme Programming (XP) is an agile software development framework that aims to produce higher
quality software, and higher quality of life for the development team. XP is the most specific of the
agile frameworks regarding appropriate engineering practices for software development.
When Applicable

 Dynamically changing software requirements

 Risks caused by fixed time projects using new technology
 Small, co-located extended development team
 The technology you are using allows for automated unit and functional tests

Values
The five values of XP are communication, simplicity, feedback, courage, and
respect and are described in more detail below.

Communication
Software development is inherently a team sport that relies on
communication to transfer knowledge from one team member to
everyone else on the team. XP stresses the importance of the
appropriate kind of communication - face to face discussion with the
aid of a white board or other drawing mechanism.

Simplicity
Simplicity means “what is the simplest thing that will work?” The purpose of
this is to avoid waste and do only absolutely necessary things such as keep
the design of the system as simple as possible so that it is easier to maintain,
support, and revise. Simplicity also means address only the requirements that
you know about; don’t try to predict the future.

Feedback
Through constant feedback about their previous efforts, teams can identify
areas for improvement and revise their practices. Feedback also supports
simple design. Your team builds something, gathers feedback on your design
and implementation, and then adjust your product going forward.

Courage
Kent Beck defined courage as “effective action in the face of fear” (Extreme
Programming Explained P. 20). This definition shows a preference for action
based on other principles so that the results aren’t harmful to the team. You
need courage to raise organizational issues that reduce your team’s
effectiveness. You need courage to stop doing something that doesn’t work
and try something else. You need courage to accept and act on feedback,
even when it’s difficult to accept.

Respect
The members of your team need to respect each other in order to
communicate with each other, provide and accept feedback that honors your
relationship, and to work together to identify simple designs and solutions.

What is DSDM?

DSDM is an Agile method that focuses on the full project lifecycle, DSDM (formally known as
Dynamic System Development Method) was created in 1994, after project managers using RAD
(Rapid Application Development) sought more governance and discipline to this new iterative
way of working.

The Eight Principles of DSDM

DSDM has eight principles. They represent an ethos, a culture, a way of working. The principles
are actively managed at all times because if a principle becomes compromised it represents a risk
to the successful execution and completion of a project.

The eight Principles of DSDM are as follows:

 1. Focus on the business need

2. Deliver on time

3. Collaborate

4. Never compromise quality

5. Build incrementally from firm foundations

6. Develop iteratively

7. Communicate continuously and clearly

8. Demonstrate control

What is Test Driven Development (TDD)?

TDD can be defined as a programming practice that instructs developers to write new code
only if an automated test has failed. This avoids duplication of code. TDD means “Test
Driven Development”. The primary goal of TDD is to make the code clearer, simple and
bug-free.

Test-Driven Development starts with designing and developing tests for every small
functionality of an application. In TDD approach, first, the test is developed which specifies
and validates what the code will do.

In the normal Testing process, we first generate the code and then test. Tests might fail since
tests are developed even before the development. In order to pass the test, the development
team has to develop and refactors the code. Refactoring a code means changing some code
without affecting its behavior.
The simple concept of TDD is to write and correct the failed tests before writing new code
(before development). This helps to avoid duplication of code as we write a small amount of
code at a time in order to pass tests. (Tests are nothing but requirement conditions that we
need to test to fulfill them).

Test-Driven development is a process of developing and running automated test before actual
development of the application. Hence, TDD sometimes also called as Test First
Development.

In this tutorial, you will learn-

 What is Test Driven Development (TDD)?

 How to perform TDD Test
 TDD Vs. Traditional Testing
 What is acceptance TDD and Developer TDD
 Scaling TDD via Agile Model Driven Development (AMDD)
 Test Driven Development (TDD) Vs. Agile Model Driven Development (AMDD)
 Example of TDD
 Benefits of TDD

How to perform TDD Test

Following steps define how to perform TDD test,

1. Add a test.
2. Run all tests and see if any new test fails.
3. Write some code.
4. Run tests and Refactor code.
5. Repeat.
TDD cycle defines

1. Write a test
2. Make it run.
3. Change the code to make it right i.e. Refactor.
4. Repeat process.

Some clarifications about TDD:

 TDD is neither about "Testing" nor about "Design".

 TDD does not mean "write some of the tests, then build a system that passes the tests.
 TDD does not mean "do lots of Testing."

TDD Vs. Traditional Testing

TDD approach is primarily a specification technique. It ensures that your source code is
thoroughly tested at confirmatory level.
  With traditional testing, a successful test finds one or more defects. It is same as
TDD. When a test fails, you have made progress because you know that you need to
resolve the problem.
 TDD ensures that your system actually meets requirements defined for it. It helps to
build your confidence about your system.
 In TDD more focus is on production code that verifies whether testing will work
properly. In traditional testing, more focus is on test case design. Whether the test will
show the proper/improper execution of the application in order to fulfill requirements.
 In TDD, you achieve 100% coverage test. Every single line of code is tested, unlike
traditional testing.
 The combination of both traditional testing and TDD leads to the importance of
testing the system rather than perfection of the system.
 In Agile Modeling (AM), you should "test with a purpose". You should know why
you are testing something and what level its need to be tested.

What is acceptance TDD and Developer TDD

There are two levels of TDD

1. Acceptance TDD (ATDD): With ATDD you write a single acceptance test. This test
fulfills the requirement of the specification or satisfies the behavior of the system.
After that write just enough production/functionality code to fulfill that acceptance
test. Acceptance test focuses on the overall behavior of the system. ATDD also was
known as Behavioral Driven Development (BDD).
2. Developer TDD: With Developer TDD you write single developer test i.e. unit test
and then just enough production code to fulfill that test. The unit test focuses on every
small functionality of the system. Developer TDD is simply called as TDD.

The main goal of ATDD and TDD is to specify detailed, executable requirements for
your solution on a just in time (JIT) basis. JIT means taking only those requirements
in consideration that are needed in the system. So increase efficiency.
Scaling TDD via Agile Model Driven Development
(AMDD)
TDD is very good at detailed specification and validation. It fails at thinking through bigger
issues such as overall design, use of the system, or UI. AMDD addresses the Agile scaling
issues that TDD does not.

Thus AMDD used for bigger issues.