Fundamentals of AGILE S/W DEV PROCESS

Agile software development:

Agile is a type of software development methodology that anticipates the need for flexibility and applies a
level of pragmatism to the delivery of the finished product. Agile software development requires a cultural
shift in many companies because it focuses on the clean delivery of individual pieces or parts of the software
and not on the entire application.

Benefits of Agile include its ability to help teams in an evolving landscape while maintaining a focus on
the efficient delivery of business value. The collaborative culture facilitated by Agile also improves
efficiency throughout the organization as teams work together and understand their specific roles in the
process. Finally, companies using Agile software development can feel confident that they are releasing a
high-quality product because testing is performed throughout development. This provides the opportunity
to make changes as needed and alert teams to any potential issues.

Agile has largely replaced waterfall as the most popular development methodology in most companies, but
is itself at risk of being eclipsed or consumed by the growing popularity of Dev-Ops.

The Agile development methodology represents the convergence of incremental, iterative, and adaptive
software development along with the fundamentals of evolutionary project management. The resulting
methodology has seen widespread use since the introduction of the Manifesto for Agile Software
Development in 2001, and it has viable applications in everything from DevOps and project management
to large-scale construction projects, manufacturing, biopharmaceutical research, and more.
The four values of Agile

In 2001, 17 software development professionals gathered to discuss concepts around the idea of lightweight
software development and ended up creating the Agile Manifesto. The Manifesto outlines the four core
values of Agile, and although there has been debate about whether the Manifesto has outlived its usefulness,
it remains at the core of the Agile movement. The four core values outlined in the Agile Manifesto are as
follows:

Individual interactions are more important than processes and tools. People drive the development
process and respond to business needs. They are the most important part of development and should be
valued above processes and tools. If the processes or tools drive development, then the team will be less
likely to respond and adapt to change and, therefore, less likely to meet customer needs.

A focus on working software rather than thorough documentation. Before Agile, a large amount of
time was spent documenting the product throughout development for delivery. The list of documented
requirements was lengthy and would cause long delays in the development process. While Agile does not
eliminate the use of documentation, it streamlines it in a way that provides the developer with only the
information that is needed to do the work -- such as user stories. The Agile Manifesto continues to place
value on the process of documentation, but it places higher value on working software.

Collaboration instead of contract negotiations. Agile focuses on collaboration between the customer and
project manager, rather than negotiations between the two, to work out the details of delivery. Collaborating
with the customer means that they are included throughout the entire development process, not just at the
beginning and end, thus making it easier for teams to meet the needs of their customers. For example, in
Agile, the customer can be included at different intervals for demos of the product. However, the customer
could also be present and interact with the teams daily, attend all meetings and ensure the product meets
their desires.

A focus on responding to change. Traditional software development used to avoid change because it was
considered an undesired expense. Agile eliminates this idea. The short iterations in the Agile cycle allow
changes to easily be made, helping the team modify the process to best fit their needs rather than the other
 way around. Overall, Agile software development believes change is always a way to improve the project
and provide additional value.

The 12 principles of Agile

The Agile Manifesto also outlined 12 core principles for the development process. They are as
follows:

1. Satisfy customers through early and continuous delivery of valuable work.

2. Break big work down into smaller tasks that can be completed quickly.

3. Recognize that the best work emerges from self-organized teams.

4. Provide motivated individuals with the environment and support they need and trust them to get
the job done.

5. Create processes that promote sustainable efforts.

6. Maintain a constant pace for completed work.

7. Welcome changing requirements, even late in a project.

8. Assemble the project team and business owners on a daily basis throughout the project.

9. Have the team reflect at regular intervals on how to become more effective, then tune and adjust
behavior accordingly.

10. Measure progress by the amount of completed work.

11. Continually seek excellence.

12. Harness change for a competitive advantage.

 Challenges of Stakeholders in AGILE
Stakeholders in Agile development face a unique set of challenges compared to more traditional project
management approaches. Here are some of the key challenges stakeholders may encounter in Agile:

1. Changing Requirements: Agile embraces change, which means that requirements can evolve throughout
the project. This can be challenging for stakeholders who are accustomed to fixed project scopes and may
require them to continuously adapt their expectations.
2. Frequent Feedback: Agile encourages regular feedback from stakeholders. While this is valuable for
ensuring the project aligns with their needs, it can also be demanding in terms of their time and attention.
3. Limited Upfront Planning: Agile projects often have less upfront planning compared to traditional
methodologies. Stakeholders may find it challenging to predict project timelines and outcomes with a high
degree of certainty.
4. Involvement and Availability: Agile requires active stakeholder involvement throughout the
development process. Stakeholders may struggle to allocate the necessary time and resources for ongoing
collaboration with the development team.
5. Prioritization: Agile projects prioritize features and tasks based on value to the customer. Stakeholders
may find it challenging to prioritize among competing requirements and may need to make difficult
decisions about what to include in each iteration.
6. Team Autonomy: Agile teams are often self-organizing and make decisions about how to accomplish
their work. Some stakeholders may have difficulty relinquishing control and trusting the team's expertise.
7. Continuous Delivery: Agile emphasizes delivering working software frequently. Stakeholders may need
to adjust to a continuous delivery model rather than waiting for a single, final release.
8. Uncertainty: Agile projects acknowledge and embrace uncertainty. Stakeholders may need to tolerate a
higher level of uncertainty about project outcomes and be comfortable with the iterative nature of
development.
9. Communication: Effective communication is crucial in Agile. Stakeholders need to maintain open and
transparent communication with the development team and other stakeholders, which can be a challenge in
larger or distributed teams.
10. Resource Allocation: Stakeholders may need to allocate resources, including budget and personnel,
differently in an Agile project. Traditional project management practices may not align with Agile resource
needs.
key stakeholders
In an Agile project, stakeholders can be classified as either internal or external. Internal stakeholders have a direct
relationship with the project and are interested in its outcomes. On the other hand, external stakeholders may not
work directly with the project team and may not be aware of the product being developed but will still be impacted
by its outcomes in the future.

The key to effective work in Agile is an interaction between all people who affect or are affected by the project.
Stakeholders should be deeply involved in the software development process to distribute responsibilities and
achieve the needed project results. The main Stakeholders in Agile: who are they?

In Agile development stakeholders can be represented by a wide range of people interested in project results:

• People funding the project;

• Business Managers and Business Architects;

• Data Architects and Database Administrators;

• Portfolio and Project Managers;

• Direct and indirect Users;

• Account and Sales Managers;

• Developers’ team including Engineers, Designers and PM/BA, etc.

Let’s have a look at the most involved in Agile Product Development.

Project Sponsors

Project Sponsors are people that have an interest primarily in the success of the project rather than in its development
process. They are usually called external stakeholders. Sponsors allocate the needful finances to the project according
to the scope and expected results (that is, of course, if they believe in its success). They can also offer an alternative
for the cost overruns.
Product Owner

Product Owner is the core stakeholder from the client’s side. Product Owner participates in story mapping activities
and specifies tasks. He should share his vision of the ongoing project, set goals and business strategy. He keeps
backlogs clear so that the team can understand what to do and why.

Development Team

In the Agile approach, a developers’ team works in sprints. After every finished sprint, the team discusses what is
done and what is to be done. Software developers should be involved in discussing the development backlogs from
the start. It makes the software development process efficient. The engineering team may also include Team Leads,
Designers and Testers. The most important role of developers as stakeholders is timely software delivery and
estimation. The quality estimation provides a clear vision of the whole development process, scope of work and
resources needed.

Project Manager and Business Analyst

The Project Manager handles planning, organization and control of activities following the estimated deadlines. He
should know all the necessary information about the project: requirements, scope, goals. In Agile projects, PM is
related to internal stakeholders as he participates in the development process. He communicates with external ones
and links them with the developers’ team. Business Analysts make predictions to understand the budget and the time
that should be spent on the project. They work on detailed requirements and create project decomposition.

End user

Your target audience is an essential link to the success of your project. That is why it is useful to engage end users in
testing MVP or product beta-version to receive the initial feedback. Users’ feedback allows reviewing the work done
and improve user experience. You may also test your project with different focus groups and analyze received
feedback.

High stakeholder engagement and understanding project roles are necessary for developing quality software
solutions. In Time & Material and Dedicated Team models of cooperation, Exposit works using Agile methodology.
We can adapt to your specific process according to your needs for the most productive collaboration.
Scrum and how scrum facilitates Communication
Scrum

Scrum is a management framework that teams use to self-organize and work towards a common
goal. It describes a set of meetings, tools, and roles for efficient project delivery. Much like a sports
team practicing for a big match, Scrum practices allow teams to self-manage, learn from experience,
and adapt to change. Software teams use Scrum to solve complex problems cost effectively and
sustainably.

Scrum methodology

Certain principles and values characterize Scrum methodology:

Scrum principles for project success

Transparency

Teams work in an environment where everyone is aware of the challenges that others might be
experiencing. Regular face-to-face conversations between cross-functional team members and project
owners prevent miscommunication and information bottlenecks.

Reflection

Frequent reflection points are built into the framework to allow team members to review their progress.
Project managers use insights from these review meetings for estimation and future planning. As a result,
projects can run more efficiently, within budget, and on schedule.

Adaptation

Team members can reprioritize tasks based on changing customer requirements. They decide which tasks
to complete first and which to revisit in the future.

Scrum values for project teams

Scrum Teams follow five core values.

Commitment

Scrum Team members are committed to time-based tasks and goals and are dedicated to continuous
improvement to find the best solution.
Courage

Scrum Teams show courage by asking open, challenging questions. They have honest and transparent
discussions to arrive at the best solution.

Focus

During any given period, team members will work from a Product Backlog of tasks. They will focus on the
selected tasks to provide deliverables within a limited time frame.

Openness

Scrum Team members are open to new ideas and opportunities that support individual learning and overall
project quality.

Respect

Team members respect the project managers, each other, and the Scrum process. This culture of respect
creates a spirit of mutual collaboration and cooperation within the team.

How does Scrum work?

Scrum is a framework that is easy to learn but difficult to become an expert in. The co-creators of scrum,
Jeff Sutherland and Ken Schwaber, have explained the underlying concepts in The Scrum Guide. The guide
gives a detailed overview of scrum processes and how to implement them effectively.

The essence of Scrum is a self-organizing team delivering customer value in a time-boxed period called
a Sprint. Scrum defines artifacts, roles, and events associated with each Sprint. Let’s look at each of these
in detail.

What are Scrum artifacts?

Scrum Teams use tools called Scrum artifacts to solve problems and manage projects. Scrum artifacts
provide critical planning and task information to team members and stakeholders. There are three primary
artifacts:

Product Backlog

The Product Backlog is a dynamic list of features, requirements, enhancements, and fixes that must be
completed for project success. It is essentially the team’s to-do list, which is constantly revisited and
reprioritized to adapt to market changes. The product owner maintains and updates the list, removing
irrelevant items or adding new requests from customers.

Sprint Backlog
 The Sprint Backlog is the list of items to be completed by the development team in the current Sprint cycle.
Before each Sprint, the team chooses which items it will work on from the Product Backlog. A Sprint
Backlog is flexible and can evolve during a Sprint.

Increment

The Increment is a step towards a goal or vision. It is the usable end product from a Sprint. Teams can adopt
different methods to define and demonstrate their Sprint Goals. Despite the flexibility, the fundamental
Sprint Goal—what the team wants to achieve from the current Sprint—can’t be compromised.

For example, some teams choose to release something to their customers at the end of the Sprint, so their
Sprint Goal would be completed once the software change is released. Other teams might work on
completing a set of features that will be released together. In this case, the Sprint Goal would be completed
when a feature is tested successfully.

What are Scrum roles?

A Scrum Team needs three specific roles: a Product Owner, Scrum leader, and development team.

Product Owner

The Product Owner focuses on ensuring the development team delivers the most value to the business.
They understand and prioritize the changing needs of end users and customers. Effective product owners
do the following:

• Give the team clear guidance on which features to deliver next.

• Bridge the gap between what the business wants and what the team understands.
• Decide when and how frequently releases should happen.

Scrum leader

Scrum leaders are the champions for Scrum within their teams. They are accountable for the Scrum Team’s
effectiveness. They coach teams, Product Owners, and the business to improve its Scrum processes and
optimize delivery. Scrum leaders are also responsible for doing the following:

• Schedule the resources needed for each Sprint.

• Facilitate other Sprint events and team meetings.
• Lead digital transformation within the team.
• Facilitate any team training when adopting new technologies.
• Communicate with external groups to solve any challenges the team might be facing as a whole.
 Scrum development team

The Scrum Team consists of testers, designers, UX specialists, Ops engineers, and developers. Team
members have different skill sets and cross-train each other, so no one person becomes a bottleneck in
delivering work.

Jeff Bezos, the founder of Amazon, recommends the two-pizza rule when deciding team size:A team should
be small enough to share two pizzas.

Scrum development teams do the following:

• Work collaboratively to ensure a successful Sprint completion.

• Champion sustainable development practices.
• Self-organize and approach their projects with an evident we attitude.
• Drive the planning and estimating for how much work they can complete for each Sprint.

Scrum events

Scrum events or Scrum ceremonies are a set of sequential meetings that Scrum Teams perform regularly.
Some Scrum events include the following:

Sprint Planning

In this event, the team estimates the work to be completed in the next Sprint. Members define Sprint Goals
that are specific, measurable, and attainable. At the end of the planning meeting, every Scrum member
knows how each Increment can be delivered in the Sprint.

Sprint

A Sprint is the actual time period when the Scrum Team works together to finish an Increment. Two weeks
is the typical length for a Sprint but can vary depending on the needs of the project and the team. The more
complex the work and the more unknowns, the shorter the Sprint should be.

Daily Scrum or stand-up

A Daily Scrum is a short meeting in which team members check in and plan for the day. They report on
work completed and voice any challenges in meeting Sprint Goals. It is called a stand-up because it aims
to keep the meeting as short as practical—like when everybody is standing.

Sprint Review

At the end of the Sprint, the team gets together for an informal session to review the work completed and
showcase it to stakeholders. The Product Owner might also rework the Product Backlog based on the
current Sprint.
Sprint Retrospective

The team comes together to document and discuss what worked and what didn’t work during the Sprint.
Ideas generated are used to improve future Sprints.

4. Short note on XP and necessary practices of Extreme Programming

The origins of XP date back to the late 1990’s, when Kent Beck created it to manage the development of a
payroll software system for Chrysler called the C3 project. The goal with XP was (and still is) to remove
the resistance to changing code within development projects. In more traditional software development
methods, you’ll often leave code alone once it’s written (except for debugging). With XP, you scrutinize
the code so carefully that developers may decide to re-write it entirely after a single iteration.
 XP Extreme programming

Because extreme programming focuses on software development, it's typically only used by engineering
teams. Even in software teams, it only works in certain settings. To get the most value out of extreme
programming, it’s best to use it when you:
• Manage a smaller team. Because of its highly collaborative nature, XP works best on smaller teams of under
10 people.
• Are in constant contact with your customers. XP incorporates customer requirements throughout the
development process, and even relies on them for testing and approval.
• Have an adaptable team that can embrace change (without hard feelings). By its very nature, extreme
programming will often require your whole team to toss out their hard work. There are also rules that allow
other team members to make changes at any time, which doesn’t work if your team members might take
that personally.
• Are well versed in the technical aspects of coding. XP isn’t for beginners. You need to be able to work and
make changes quickly.

Lifecycle of XP
The XP lifecycle encourages continuous integration where the team member integrates almost constantly,
as frequently as hourly or daily. But the full lifecycle breaks down as follows:
• Pull unfinished work from user stories
• You prioritize the most important items
• Begin iterative planning
• Incorporate honest planning
• Stay in constant communication with all stakeholders and empower the team
• Release work
• Receive feedback
• Return to the iterative planning stage and repeat as needed.

5 values of extreme programming

Extreme programming is value driven. Instead of using external motivators, XP allows your team to work
in a less complicated way (focusing on simplicity and collaboration over complex designs), all based on
these five values.

1. Simplicity

Before starting any extreme programming work, first ask yourself: What is the simplest thing that also
works? The “that works” part is a key differentiator—the simplest thing is not always practical or effective.
In XP, your focus is on getting the most important work done first. This means you’re looking for a simple
project that you know you can accomplish.

2. Communication
 XP relies on quick reactivity and effective communication. In order to work, the team needs to be open and
honest with one another. When problems arise, you’re expected to speak up. The reason for this is that other
team members will often already have a solution. And if they don’t, you’ll come up with one faster as a
group than you would alone.
Read: How to improve team communication: 6 strategies and tips

3. Feedback

Like other Agile methodologies, XP incorporates user stories and feedback directly into the process. XP’s
focus is producing work quickly and simply, then sharing it to get almost immediate feedback. As such,
developers are in almost constant contact with customers throughout the process. In XP, you launch
frequent releases to gain insights early and often. When you receive feedback, you’ll adapt the process to
incorporate it (instead of the project). For example, if the feedback relieves unnecessary lag time, you’d
adjust your process to have a pair of developers improve lag time instead of adjusting the project as a whole.
Read: Don’t like giving feedback? These 20 tips are for you

4. Courage

XP requires a certain amount of courage. You’re always expected to give honest updates on your progress,
which can get pretty vulnerable. If you miss a deadline in XP, your team lead likely won’t want to discuss
why. Instead, you’d tell them you missed the deadline, hold yourself accountable, and get back to work.
If you're a team lead, your responsibility at the beginning of the XP process is to set the expectation for
success and define "done." There is often little planning for failure because the team focuses on success.
However, this can be scary, because things won’t always go as planned. But if things change during the XP
process, your team is expected to adapt and change with it.

5. Respect

Considering how highly XP prioritizes communication and honesty, it makes sense that respect would be
important. In order for teams to communicate and collaborate effectively, they need to be able to disagree.
But there are ways to do that kindly. Respect is a good foundation that leads to kindness and trust—even in
the presence of a whole lot of honesty. For extreme programming, the expectations are:

• Mutual respect between customers and the development team.

• Mutual respect between team members.
• A recognition that everyone on the team brings something valuable to the project.
5. FDD and comment on on-time Delivery

FDD in Agile
FDD, which stands for Feature-Driven Development, is a framework in the Agile methodology. As the
name suggests, it focuses on developing working software with features that satisfy client needs. FDD aims
to ensure regular and on-time delivery to customers, in line with the values and principles of the Agile
Manifesto.
IT strategist Jeff de Luca originally devised the FDD concept in 1997 to organize a project for a bank in
Singapore. The 15-month Agile project included 50 team members, and its success led to widespread
adoption of the FDD model.
The iterative and incremental development process is central to FDD. Teams break their projects down into
smaller increments that are easier to manage. The workload is divided into short Agile iterations, where
developers repeat steps until the final deliverable is deemed fit for release. FDD teams also prepare progress
reports and carry out regular inspections to ensure a high standard of quality.
Domain object modeling is one of the best practices of FDD. Inspired by Peter Coad’s research on object-
oriented design, domain object modeling is when teams outline the domains of the problems they are hoping
to solve. This enables them to create a model where they can add corresponding features.
FDD is a solid alternative to the more well-known Agile frameworks such as Scrum and Kanban.
Some Agile practitioners prefer FDD to Scrum because it relies on documentation to communicate rather
than daily meetings, which can be time-consuming. FDD is suitable for large-scale, long-term projects, as
it enables teams to manage changing requirements on an ongoing basis.

The five steps in FDD

There are five key activities in Feature-Driven Development:

1: Develop the overall model

Here, an FDD team will determine the project scope. Multiple models will be proposed and merged to
create one overall model.

2: Build the features list

Next, the team members will outline the customer-focused features to be developed. They will be small
functions that can be completed in a short period of time. An example could be to create an automatic
reminder for subscription renewal.

3: Plan by feature
The team will assess the individual features in the list and arrange them in the appropriate order. Then, the
features will be assigned to team members.
4: Design by feature
At this stage, the team’s chief programmer will choose which features to develop within a two-week period.
A design package will be created for each feature, and team members will conduct a review before building
commences.

5: Build by feature
Developers work to build the code for the aforementioned features. This code will be tested before the final
version is created.

FDD team roles

In an FDD team structure, there are six chief roles. These are:

• Project manager

• Chief architect

• Development manager

• Chief programmer

• Class owner

• Domain expert
In FDD, individual team members will be assigned to a particular feature, but small feature teams will also
help make design decisions.
Kanban Framework
Kanban Definition and Brief Introduction

Kanban Definition

The Japanese word “kanban”, meaning “visual board” or a “sign”, has been used in the sense of a process
definition since the 1950s. It was first developed and applied by Toyota as a scheduling system for just-in-
time manufacturing. On the other hand, the capitalized term “Kanban” is known and associated with the
emergence of the “Kanban Method,” which was first defined in 2007.

The Genesis of Kanban

Initially, it arose as a scheduling system for lean manufacturing, originating from the Toyota Production
System (TPS). In the late 1940s, Toyota introduced “just in time” manufacturing to its production. The
approach represents a pull system. This means that production is based on customer demand rather than the
standard push practice of producing goods and pushing them to the market.
Their unique production system laid the foundation of Lean manufacturing or simply Lean. Its core purpose
is minimizing waste activities without sacrificing productivity. The main goal is to create more value for
the customer without generating more costs.

The Kanban Method

At the beginning of the 21st Century, key players in the software industry quickly realized how Kanban
could positively change the way products and services were delivered.
With an increased focus on efficiency and by harnessing advances in computing technology, Kanban left
the automotive industry's realm and was successfully applied to other complex commercial sectors such as
IT, software development, R&D, and others.

Indeed, what we now recognize as the Kanban Method emerged at the beginning of 2007. It is a result of
years of testing, experience, and joint efforts of leading figures in the Lean and Agile community, including
David Anderson, Dan Vacanti, Darren Davis, Corey Ladas, Dominica DeGrandis, Rick Garber, and others.

You can start building your Kanban system by setting up the most straightforward Kanban board with three
basic columns – “Requested”, “In Progress” and “Done”. When constructed, managed, and functioning
correctly, it serves as a real-time information repository, highlighting bottlenecks within the system and
anything else that might interrupt smooth working practices.
Let’s discover more about the fundamental Kanban principles and practices.
The Kanban method is based on six foundational change management and service delivery.

1. Start with what you do now: Kanban is about continuous improvement, but it starts with an
understanding of the current processes and workflows.
2. Agree to pursue incremental, evolutionary change: Rather than attempting a large-scale
transformation all at once, Kanban advocates for small, incremental changes that build on each
other over time.
3. Encourage acts of leadership at all levels: Kanban is not just for managers or team leads but for
everyone involved in the work. Anyone can take leadership and suggest improvements based on
their observations.
4. Focus on customer needs and expectations: Kanban promotes understanding the needs and
expectations of your customers to elevate the quality of the provided services and the value it
creates.
5. Manage the work, not the workers: Kanban respects the existing roles and responsibilities of
team members and empowers people’s abilities to self-organize around the work.
6. Regularly review the network of services: Kanban encourages collaboration and encourages team
members to share their observations, ideas, and feedback for improving the work through regular
reviews of the entire network of services.

Kanban Practices
For a successful Kanban implementation, the method relies on six essential practices:

1. Visualizing the workflow: Creating a visual representation of the workflow helps to identify
bottlenecks, visualize the flow of work, and make the work more transparent.
2. Limiting work in progress: Limiting the amount of work in progress helps to prevent multitasking
and improve focus on completing one task at a time, thereby improving efficiency and reducing
lead time.
3. Managing flow: Kanban aims to help in optimizing flow which can be achieved by monitoring
flow metrics, identifying and addressing bottlenecks, and continuously improving the workflow.
4. Making process policies explicit: Defining and communicating process policies clearly helps to
ensure that everyone understands how work is supposed to be done, which reduces
misunderstandings and promotes consistency.
5. Implementing feedback loops: Kanban emphasizes the importance of getting feedback from
customers, stakeholders, and team members as a way to identify areas for improvement.
6. Improving collaboratively: Kanban is a continuous improvement process that encourages
collaboration and experimentation to identify and solve problems, improve continuously, and
evolve their processes to better meet the needs of their customers.

Top 6 Benefits of Kanban

According to the 1st State of Kanban report, the leading reasons for adopting the Kanban method are the
need for enhanced visibility of work and continuous improvement. Let’s reveal some more of the
benefits of using Kanban today.
Image Credit: State of Kanban
 • Increased visibility of the flow
• Improved delivery speed
• Alignment between goals and execution
• Improved predictability
• Improved dependencies management
• Increased customer satisfaction

Increased Visibility of the Flow

The basic idea of Kanban is visualizing every piece of work. This way, the Kanban board turns into a central
informational hub, and everyone is on the same page. All tasks are visible, and they never get lost, which
brings transparency to the whole work process. Every team member can have a quick update on the status
of every project or task.

Improved Delivery Speed

Kanban offers multiple ways for project managers to closely monitor and make informed analyses of the
distribution of work. With a clear view over the work items completed for a certain period of time, the
stages where tasks spend the longest, and bottlenecks are easy to identify. Teams are enabled to tackle these
challenges to improve their workflow and, ultimately, their delivery rate.

Alignment between Business Goals and Execution

Promoting transparency, encouraging feedback, and regular review meetings, Kanban practices enable
aligning the company’s strategic goals with teams' day-to-day work. This alignment between the business
direction and execution enhances the agility of an organization. It allows teams to adapt to changing
priorities and reorganizations due to changes in the market or customers’ requirements.

Improved Predictability

Once you create a Kanban board and start accumulating work items on it, you’ll be able to understand your
process in depth with flow metrics. Analyzing the time tasks spend in your workflow (cycle time) will
enable you to improve your predictions on how much work you can deliver in the future. Understanding
your delivery rate consistency (throughput) will make your forecasts more accurate and your decisions
based on historical data.

Improved Ability to Manage Scale and Dependencies

The intrinsic Kanban practice of visualization is also applied when it comes to mapping and managing
dependencies. Starting with what you do now means visualizing the present dependencies and managing
the flow between them. Managing dependencies provides both insights into the present state of a workflow
and ideas for improvement. On the other hand, it also enables full transparency for strategic management
over the workflow and the existing links between teams.
Increased Customer Satisfaction
The origin of the Kanban method - the pull system it is based on implies that work is done when there’s a
demand. In other words, Kanban navigates you to reduce waste by working solely on tasks that are needed
at present. Furthermore, by applying visualization techniques and introducing work-in-progress limits to
the process, you will ensure that the end result is fine-tuned to your customer’s expectations.
Scrum vs. Kanban
The most important difference between Kanban and Scrum is that the former is a method, while the latter
is a framework. As an Agile methodology, Kanban builds a continuous delivery model where teams release
value as soon as they are ready, while Scrum organizes work in Sprints. Applying either one depends on
the nature of your process, however, it can be said that Kanban offers a more tailor-made approach while
Scrum relies on predetermined rules. Another key distinguishing characteristic between the two is the
mindset and founding belief systems of Scrum and Kanban.

Kanban Scrum

Kanban is an adaptive Scrum is a prescriptive

Nature
method framework

1. Start with what you do

now
2. Agree to pursue
evolutionary change
1. Empiricism
3. Encourage acts of
2. Transparency
Principles leadership at all levels
3. Inspection
4. Focus on customer’s
4. Adaptation
needs
5. Manage the work
6. Regularly review the
network of services

- Sprint with a fixed

length
- Team-level cadences - Sprint planning
Cadences
- Service-oriented cadences - Daily Scrum
- Sprint Review
- Sprint Retrospective

- Service Delivery
Manager*
- Product Owner
- Service Request
Roles - Scrum Master
Manager*
- Development Team
(*no pre-defined roles are
required)

- Cycle Time
- Velocity
Metrics - Throughput
- Planned Capacity
- Work In Progress
 Lean S/W development Framework
Lean Software Development is a framework that draws its inspiration from Lean
manufacturing principles and applies them to software development processes. It
focuses on eliminating waste, improving efficiency, and delivering value to customers.
Here's a short note on Lean Software Development:

Key Principles of Lean Software Development:

1. Eliminate Waste: Lean principles emphasize the removal of any activities or processes
that do not add value to the product or project. This includes unnecessary
documentation, code, features, and waiting times.
2. Build Quality In: Quality is a top priority in Lean. Rather than fixing defects after they
occur, Lean promotes building quality into the software from the start. This reduces
rework and enhances customer satisfaction.
3. Create Knowledge: Lean encourages a culture of learning and continuous
improvement. Teams are encouraged to gather data, analyze it, and use the insights to
make informed decisions and drive improvements.
4. Defer Commitment: In Lean, decisions are deferred until the last responsible moment,
allowing for flexibility and the incorporation of new information. This minimizes
premature or unnecessary commitments that can lead to waste.
5. Deliver Fast: Lean aims to deliver value to customers as quickly as possible. This often
involves breaking projects into small, manageable pieces and delivering them
incrementally.
6. Respect People: Lean recognizes that people are the most valuable asset in the
development process. It promotes collaboration, teamwork, and empowerment of
individuals to make decisions and solve problems.
7. Optimize the Whole: Instead of focusing on individual components or processes, Lean
looks at the entire value stream. It seeks to optimize the end-to-end process to deliver
maximum value to the customer.

Lean Software Development Practices:

• Value Stream Mapping: Teams map out the entire development process to identify
bottlenecks, waste, and opportunities for improvement.
• Pull Systems: Work is pulled into the system based on actual customer demand rather
than being pushed in, which helps prevent overproduction.
• Kanban: Visual boards are used to visualize work in progress, making it easier to
manage flow and identify issues.
• Continuous Delivery: Frequent, small releases are made to deliver value to the
customer more rapidly.
• Limit Work in Progress (WIP): By limiting the number of tasks in progress, teams
can improve focus and reduce multitasking, leading to better efficiency.
• Kaizen: Continuous improvement is an essential aspect of Lean, with teams regularly
reflecting on their processes and making incremental enhancements.

Benefits of Lean Software Development:

• Reduced Waste: Lean principles help eliminate waste, leading to more efficient use of
resources and reduced costs.
• Improved Quality: Building quality in from the start reduces defects and rework,
resulting in a higher-quality end product.
• Faster Delivery: Lean practices often lead to faster project delivery, which can improve
time-to-market and customer satisfaction.
• Increased Flexibility: By deferring decisions and embracing change, Lean makes it
easier to adapt to evolving customer needs and market conditions.
• Enhanced Collaboration: Lean's focus on teamwork and communication fosters a
more collaborative and empowered work environment.

In summary, Lean Software Development is a framework that prioritizes efficiency,

quality, and customer value by eliminating waste, embracing continuous improvement,
and optimizing the entire development process. It offers a valuable alternative to
traditional software development approaches.