How kanban is used to increase productivity?

Other advantages to using Kanban revolve around productivity and efficiency, two concepts that also
tie back to the reduction of waste. The Kanban system focuses on the reduction of waste in all its
forms: over-production, unnecessary motion, defects, over-processing and waiting. In terms of
software development and project management, waste can be thought of as:

 Work that is not needed

 Work that is incorrect
 Time spent doing the wrong work (work that has less value), rather than focusing on the work with
more value

When waste is eliminated from a process, project or workflow, productivity goes up, people are able to
focus more on the work that matters, and efficiency is improved in the way people manage their time
and in the way they do their work. Finally, when work is properly re-prioritized as needed and
communicated visually using a kanban system or task board, an individual doesn’t have to question
what he/she should work on next. Instead, the team member pulls the next kanban card from the top of
the queue without spending any time considering which task to pull next.

7 advantages of TDD
 Writing tests first require you to really consider what you want from the code
 Short feedback loop
 Creates a detailed specification
 Reduced time in rework
 Less time spent in the debugger and when it is required you usually get closer to problem quickly
 Tells you whether your last change (or refactoring) has broken previously working code
 Allows the design to evolve and adapt to your changing understanding of the problem.

Main pillar of agile manifesto

 Individuals and Interactions Over Processes and Tools
Individuals and interactions are considered as the best way over the processes and tools as it
makes the procedure responsive. If clients and development teams are aligned together then
once they understand each other, the development team can resolve any issue related to tools
and processes.

 Working Software Over Comprehensive Documentation

Traditional project management included extensive documentation which involved a slack of
months. This used to affect the project delivery and the after delays were inescapable.

 Customer Collaboration Over Contract Negotiation

No doubt negotiations are important as they happen in a situation when a client and a product
manager work together with all the details but things have not been finalized yet. There is still
the possibility of renegotiation, but once the negotiation is done, the discussion is over.
However, agile manifesto is completely different as it favors customer collaboration over
contract negotiations.

 Responding to Change Over Following a Plan

 The standard manner of thinking is that the progressions are costly and we ought to evade
changes no matter what. That is the thing that the unnecessary focus is on documentation and
detailed plans to deliver by staying onto the product particulars and the timelines. Whereas
Agile enables us to make changes as they are not too costly. In fact, feedbacks have always
welcomed that help the project to grow. It can’t be avoided but it adds value. As indicated by
Agile, the crispness of emphasis means preferences can be shifted from iteration to iteration
and different features can be included in the next iteration. Alterations improve a project and
give extra worth.

DSDM life cycle

Feasibility Phase
The Feasibility phase is intended primarily to establish whether the proposed project is likely to be
feasible from a technical perspective and whether it appears cost-effective from abusiness perspective.
The effort associated with Feasibility should be just enough to decide whether further investigation is
justified, or whether the project should be stopped now, as itis unlikely to be viable.
6.4 Foundations Phase
The Foundations phase takes the preliminary investigation from Feasibility to the next level. It is
intended to establish a fundamental (but not detailed) understanding of the business rationale for the
project, the potential solution that will be created by the project, and how development and delivery of
the solution will be managed. By intentionally avoiding low levels of detail, the Foundations phase
should last no longer than a few weeks - even for large and complex projects. The detail associated with
requirements, and how they should be met as part of the solution, is intentionally left until the
Evolutionary Development phase of the project.
It may sometimes be necessary to revisit Foundations after a Deployment phase. The decision to revisit
Foundations may be planned in from the start of the project; for example, on aproject where the business
environment is sufficiently dynamic that the Foundations are expected to encounter significant change
during the life of the project. Alternatively, the decision to revisit Foundations may be taken after a
Deployment has produced an unexpected outcome.
Returning to the Foundations phase to re-affirm and, where necessary, refine the foundations of the
project normally takes significantly less time than establishing them in the first placeand may be as
short as a single Workshop.
For smaller, simpler projects, the Feasibility and Foundations phases can often be merged into a single
phase.
The aim of Foundations is to understand the scope of work, how it will be carried out, by whom, when
and where. The Foundations phase also determines the project lifecycle by agreeing how the DSDM
process will be applied to the specific needs of this project.
6.5 Evolutionary Development Phase
Building on the firm foundations that have been established for the project, the purpose of the
Evolutionary Development phase is to evolve the solution.
The Evolutionary Development phase requires the Solution Development Team(s) to apply practices
such as Iterative Development, timeboxing, and MoSCoW prioritisation, togetherwith Modelling and
Facilitated Workshops, to converge over time on an accurate solution that meets the business need and
is also built in the right way from a technical viewpoint.
Working within Timeboxes, the Solution Development Team create Solution Increments, iteratively
exploring the low-level detail of the requirements and testing continuously as they move forward.
6.6 Deployment Phase
The objective of the Deployment phase is to bring a baseline of the Evolving Solution into operational
use.
The release that is deployed may be the final solution, or a subset of the final solution.
Some examples of what can be deployed are:

 Business change - introducing a new way of working into a factory (deploying a business
change as a single release)
 The early deployment of a corporate intranet, providing a limited number of features, with more
features to be provided later (deploying the first release of many)
 A complex product - e.g. the launch of a new mobile phone, bringing together par ts of the
solution from multiple projects run in different locations (deploying a new product as a single
release)

The Deployment phase comprises three main activities: Assemble, Review and Deploy. In addition,
after the last release, the project is formally closed.
6.6.1 Assemble
Before a physical deployment, there are usually activities that take place to ensure that what is being
delivered is coherent.This may also include bringing together any relevant supporting information.
Assemble encompasses the work to “bring together” what is to be released.
On a small simple project, the work involved during Assemble may be minimal. On larger more
complex projects or programmes where multiple projects are feeding into a single release, the amount
of work to assemble a number of Solution Increments into a single release could be significant e.g.
combining a new business process, a schedule of training, user guides and a new IT solution.
6.6.2 Review
Once all the elements of a release have been assembled, in most circumstances there will be some form
of “approval to deploy”.This will be based on a final review of the solution before it goes into
operational use - to ensure the proposed release meets the appropriate standards and is complete enough
to be viable. In a simple environment, this can be very informal – a basic checklist - but in a more
complex environment, it may be as formal as a go/no-go checkpoint workshop.
At this point, the team also carries out a retrospective for the Project Increment, focusing on ways of
working and potential areas for improvement.
Information from both the retrospective and the formal review of the product help shape plans for future
increments and can be used to facilitate learning across projects within a portfolio.
6.6.3 Deploy
Once approval has been given, Deploy is the physical act of putting what has been assembled (the
release) into operational use. It includes any technical work, such as transfer of the solution into the live
(production) environment, but also the enactment of any plans for business change.

Responsibilies of product owner and product ambassador

Product owner
Activity and resource planning

Planning is instrumental for meeting project deadlines, and many projects fail due to poor planning.
First and foremost, good project managers define the project’s scope and determine available resources.
Good project managers know how to realistically set time estimates and evaluate the team or teams’
capabilities.

They then create a clear and concise plan to both execute the project and monitor its progress. Projects
are naturally unpredictable, so good project managers know how to make adjustments along the way as
needed before the project reaches its final stages.

2. Organizing and motivating a project team

Good project managers don’t get their teams bogged down with elaborate spreadsheets, long checklists,
and whiteboards. Instead, they put their teams front and center. They develop clear, straightforward
plans that stimulate their teams to reach their full potential. They cut down on bureaucracy and steer
their teams down a clear path to the final goal.

3. Controlling time management

Clients usually judge a project’s success or failure on whether it has been delivered on time. Therefore,
meeting deadlines is non-negotiable. Good project managers know how to set realistic deadlines, and
how to communicate them consistently to their teams.

4. Cost estimating and developing the budget

Good project managers know how to keep a project within its set budget. Even if a project meets a
client’s expectations and is delivered on time, it will still be a failure if it goes wildly over-budget. Good
project managers frequently review the budget and plan ahead to avoid massive budget overruns.

5. Ensuring customer satisfaction

In the end, a project is only a success if the customer is happy. One of the key responsibilities of every
project manager is to minimize uncertainty, avoid any unwanted surprises and involve their clients in
the project as much as is reasonably possible. Good project managers know how to maintain effective
communication and keep the company’s clients up-to-date.

6. Analyzing and managing project risk

The bigger the project is, the more likely there are to be hurdles and pitfalls that weren’t part of the
initial plan. Hiccups are inevitable, but good project managers know how meticulously and almost
intuitively, identify and evaluate potential risks before the project begins. They know how to then avoid
risks or at least minimize their impact.

7. Monitoring progress During the initial stages, project managers and their teams have a clear vision
and high hopes of producing the desired result. However, the path to the finish line is never without
some bumps along the way. When things don’t go according to a plan, a project manager needs to
monitor and analyze both expenditures and team performance and to always efficiently take corrective
measures.

Business ambassador
The Business Ambassador is the key representative of the business needs within the Solution
Development Team and, as such, they need to have the desire, authority, responsibility and knowledge
to fulfil the role.
During Foundations, the Business Ambassador has significant input into the creation and prioritisation
of requirements. Once the requirements have been agreed and baselined (by the end of Foundations),
the Business Ambassador then provides the day-to-day detail of the requirements during timeboxed
development. This is either based on their own knowledge and experience, or drawing on the experience
of the Business Advisors.
Responsibilities

 Contributing to all requirements, design and review sessions

 Providing the business perspective for all day-to-day solution development decisions
 Providing the detail of business scenarios to help define and test the solution
 Communicating with other users, involving them as needed and getting their agreement
 Providing day-to-day assurance that the solution is evolving correctly
 Organising and controlling business acceptance testing of the solution

Explain

Sprint backlog

The sprint backlog is a list of tasks identified by the Scrum team to be completed during the
Scrum sprint. During the sprint planning meeting, the team selects some number of product
backlog items, usually in the form of user stories, and identifies the tasks necessary to complete each
user story.

An Epic can be defined as a big chunk of work that has one common objective. It could be a feature,
customer request or business requirement. ... These details are defined in User Stories. An epic usually
takes more than one sprint to complete.

At the end of each iteration, the team adds up effort estimates associated with user stories that were
completed during that iteration. This total is called velocity. Knowing velocity, the team can compute
(or revise) an estimate of how long the project will take to complete, based on the estimates associated
with remaining user stories and assuming that velocity over the remaining iterations will remain
approximately the same. This is generally an accurate prediction, even though rarely a precise one.

In the simplest definition the Scrum Product Backlog is simply a list of all things that needs to be done
within the project. It replaces the traditional requirements specification artifacts. These items can have
a technical nature or can be user-centric e.g. in the form of user stories.
 A stand-up meeting is a meeting in which attendees typically participate while standing. The discomfort
of standing for long periods is intended to keep the meetings short.

What is agile?

Agile is a process by which a team can manage a project by breaking it up into several stages and
involving constant collaboration with stakeholders and continuous improvement and iteration at every
stage. The Agile methodology begins with clients describing how the end product will be used and what
problem it will solve. This clarifies the customer's expectations to the project team. Once the work
begins, teams cycle through a process of planning, executing, and evaluating — which might just
change the final deliverable to fit the customer's needs better. Continuous collaboration is key, both
among team members and with project stakeholders, to make fully-informed decisions

Difference between Agile and Waterfall Model:

Agile Waterfall

It separates the project development Software development process

lifecycle into sprints. is divided into distinct phases.

It follows an incremental approach Waterfall methodology is a

sequential design process.

Agile methodology is known for its flexibility. Waterfall is a structured

software development

methodology so most times it can be quite rigid.

Agile can be considered as a collection of many different projects. Software development will be completed as one
single project.

Agile is quite a flexible method which allows changes to be made in the There is no scope of changing the requirements
project development requirements even if the initial planning has been once the project development starts.
completed.

Agile methodology, follow an iterative development approach because All the project development phases like designing,
of this planning, development, prototyping and other software development, testing, etc. are completed once in
development phases may appear more than once. the Waterfall model.
Test plan is reviewed after each sprint The test plan is rarely discussed during the test
phase.

Process of software development under scrum

 Scrum software development starts with a wish list of features — a.k.a. a product backlog. The
team meets to discuss:
o The backlog.
o What still needs to be completed.
o How long it will take.
 Scrum relies on an agile software development concept called sprints:
o Sprints are periods of time when software development is actually done.
o A sprint usually lasts from one week to one month to complete an item from the backlog.
o The goal of each sprint is to create a saleable product.
o Each sprint ends with a sprint review.
o Then the team chooses another piece of backlog to develop — which starts a new sprint.
o Sprints continue until the project deadline or the project budget is spent.
 In daily scrums, teams meet to discuss their progress since the previous meeting and make plans
for that day.
o The meetings should be brief — no longer than 15 minutes.
o Each team member needs to be present and prepared.
o The ScrumMaster keeps the team focused on the goal.
What is Agile Testing?
Agile testing is a software testing process that follows the principles of agile software
development. Agile testing aligns with iterative Development Methodology in which
requirements develop gradually from customers and testing teams. The development is
aligned with customer requirements.
Behavior Driven Development (BDD)
Behavior Driven Development (BDD) improves communication amongst project
stakeholders so that all members correctly underst and each feature before the
development process starts. There is continuous example -based communication
between developers, testers, and business analysts.
Acceptance Test Driven Development (ATDD)
ATDD focuses on involving team members with different pers pectives such as the
customer, developer, and tester. Three Amigos meetings are held to formulate
acceptance tests incorporating perspectives of the customer, development, and
testing. The customer is focused on the problem that is to be solved, the deve lopment
is focused on how the problem will be solved whereas the testing is focused on what
could go wrong.

Exploratory Testing
In this type of testing, the test design and test execution phase go hand in hand.
Exploratory testing emphasizes working softwa re over comprehensive documentation.
The individuals and interactions are more important than the process and tools.
Customer collaboration holds greater value than contract negotiation. Exploratory
testing is more adaptable to changes. In this testers identify the functionality of an
application by exploring the application. The testers try to learn the application, and
design & execute the test plans according to their findings.

Key skills of a successful agile project manager

Regardless of how an organization defines the role of agile project manager, anyone tasked
with managing projects in an agile environment should possess the following qualities for
success:

 Exceptional organizational skills, including the ability to prioritize. In an agile

environment, it becomes imperative that project managers be laser-focused on essential
components of the project and let go of unnecessary or distracting work.

 The ability to thrive—and remain calm—under pressure.

 Excellent communication skills and the ability to work well with others.

 Superior critical thinking capabilities, including the ability to think on his or her feet.

 Comfort with quickly changing priorities and a high level of adaptability and flexibility.

13 Project requirements are conditions or tasks that must be completed to ensure the success
or completion of the project. They provide a clear picture of the work that needs to be done.
They're meant to align the project's resources with the objectives of the organization. The benefits
of effectively gathering project requirements include cost reduction, higher project success rates,
more effective change management, and improved communication among stakeholders.
Types

functional requirement defines a system or its component. It describes the

functions a software must perform. A function is nothing but inputs, its
behavior, and outputs. It can be a calculation, data manipulation, business
process, user interaction, or any other specific functionality which defines what
function a system is likely to perform.

Non-Functional Requirement?
A non-functional requirement defines the quality attribute of a software
system. They represent a set of standards used to judge the specific operation
of a system. Example, how fast does the website load?

A non-functional requirement is essential to ensure the usability and

effectiveness of the entire software system. Failing to meet non-functional
requirements can result in systems that fail to satisfy user needs.