Continuous

Improvement
Process & People
Multiple Levels of Improvement

• On IT projects continuous improvement starts at the code level with pair

programming. While one person writes the code, the other person reviews
it, critiques it, and suggests improvements in real time.
• Ona daily basis, the team members share any impediments they’re facing in
their stand-up meetings so that the ScrumMaster can quickly remove them.
• each iteration ends with a review, in which the team demonstrates their
work to the customer
• A retrospective ,in which the team members examine their process and
decide on improvements to make in the next iteration.

2
Process improvement

A lot of focus in Agile projects goes into visualizing progress (through Kanban
boards, burndown charts, CFD’s and other information radiators) that exposes
opportunities for the team to improve their way of working.

3
Kaizen

Kaizen is the practice of continuous improvement on Lean philosophy.

Kaizen is characterized by many small and continuous changes that

cumulatively result in big improvements over time

4
PDCA
Each iteration around this cycle can be viewed as a set of experiments:

❑ The "Plan” and “Develop” steps =“Plan” and “Do” steps.

❑ “Evaluate” step, we do testing and get customer feedback, =“Check.
❑ “Learn” step, we reflect on our process and immediately apply the
lessons we’ve learned =“Act" step in Deming’s cycle.
5
6
Process Tailoring

• Determine the scope – which processes to tailor based on feedback from the team

• Determine the duration – the amount of time required to tailor and observe the impact of
tailoring.

• Determine the impact – by involving and engaging stakeholders in the decision making part.

• Determine reusable resources – like organizational process assets, best practices, industry-wide
practices and see how applicable they are in the current context.

• Review and confirm that the tailored process is indeed working in the way it was envisioned to.

• Socialize the improved process to stakeholders such that it becomes well understood, accepted,
relevant and consistent – not only in the context of the current project, but also for future
projects.

7
 Value Stream Mapping
The value stream mapping process involves the following steps

1. Identify the product or service to be analyzed.

2. Create a value stream map of the current process, identifying steps, queues, delays,
and information flows.
3. Review the map to find delays, waste, and constraints.
4. Create a new value stream map of the desired future state of the process,
optimized to remove or reduce delays, waste, and constraints.
5. Develop a roadmap for creating the optimized state.
6. Plan to revisit the process in the future to continually refine and optimize it.
Value Stream Mapping
• Total cycle time: In value stream mapping, cycle time is referred to as “total cycle time” because
we are breaking cycle time into two parts—value-added time and nonvalue-added time. So, the
total cycle time for a process is the sum of its value-added time and its nonvalue-added time.

• Value-added time: This is the time during the cycle where value is being added to the process.

• Nonvalue-added time: This is all the rest of the time in the cycle, where we will find the delays,
waste, and constraints that we want to remove or reduce. »

• Process cycle efficiency: This is the value-added time divided by the total cycle time. Once we
have made improvements to the system, we can use this ratio to compare the efficiency of the
new process compared to its previous state.
Agile-Agile Hybrid: Scrum-XP

• » XP provides great technical guidance but not much in the way of project
governance guidance.
• » Scrum provides a project governance model but not much in the way of
how to do the work.
Systems Thinking
Lean 5S
Relationships between XP Practices

13
The XP framework normally involves 5 phases or
stages

• Planning
• Designing
• Coding
• Testing
• Listening

14
XP

15
The XP framework normally involves 5 phases or
stages of the development process
that iterate continuously:
• Planning, the first stage, is when the customer meets the development team and presents
the requirements in the form of user stories to describe the desired result. The team then
estimates the stories and creates a release plan broken down into iterations needed to
cover the required functionality part after part. If one or more of the stories can’t be
estimated, so-called spikes can be introduced which means that further research is
needed.

• Designing is actually a part of the planning process, but can be set apart to emphasize its
importance. It’s related to one of the main XP values that we’ll discuss below -- simplicity.
A good design brings logic and structure to the system and allows to avoid unnecessary
complexities and redundancies.

16
The XP framework normally involves 5 phases or
stages of the development process
that iterate continuously:
• Coding is the phase during which the actual code is created by
implementing specific XP practices such as coding standards, pair
programming, continuous integration, and collective code ownership (the
entire list is described below).
• Testing is the core of extreme programming. It is the regular activity that
involves both unit tests (automated testing to determine if the developed
feature works properly) and acceptance tests (customer testing to verify
that the overall system is created according to the initial requirements).
• Listening is all about constant communication and feedback. The customers
and project managers are involved to describe the business logic and value
that is expected.

17
Roles

1. Customers are expected to be heavily engaged in the development process by creating user stories,
providing continuous feedback, and making all the necessary business decisions related to the
project.

2. Programmers or developers are the team members that actually create the product. They are
responsible for implementing user stories and conducting user tests (sometimes a
separate Tester role is set apart). Since XP is usually associated with cross-functional teams, the skill
set of such members can be different.

3. Trackers or managers link customers and developers. It’s not a required role and can be performed by
one of the developers. These people organize the meetups, regulate discussions, and keep track of
important progress KPIs.

4. Coaches can be included in the teams as mentors to help with understanding the XP practices. It’s
usually an outside assistant or external consultant who is not involved in the development process,
but has used XP before and so can help avoid mistakes.

18
Values and principles of extreme programming

19
20
21
Process analysis

• Agile teams look to improving the efficiency and effectiveness of their

processes by
• identifying and removing overheads,
• constraints, or
• anything that does not add value.
• how code changes are deployed to the test environments.
• use and configure a build-and-deployment tool

22
Kanban Kata
Kanban Kata is another continuous improvement strategy that uses a series of questions to help
improve in small steps such that day-to-day work and improvements happen simultaneously.

A set of Kata questions could look like as follows:

• What is the target state that we are trying to achieve?
• What is the current state?
• What are the impediments or blockers on the way?
• What is the next step to resolve the impediment?
• When can we see what we learned from taking that step?

23
Pareto Diagrams (80-20 rule)

• The Pareto principle, also called the 80-20 rule is based on

measuring the frequencies or occurrences that cause the
most of the problems.
• The rules state that 80% of the problems are due to 20% of
the causes.
• Alternatively stated, 80% of the system errors can be
removed by resolving 20% of the defects.

24
Control charts

• The tool used for process diagnosis and quality improvement is the
statistical process control chart or Shewhart chart.
• This is used to determine whether the performance of a process is within
the expected range demarcated by upper and lower limits.
• Usually the upper and lower limits are specified at a three-sigma value
(sigma is standard deviation) on either side of the mean.
• If the measured parameter has a value within this range it is said to be
stable or under control.

25
CONTROL CHARTS

26
Pre-mortem / Pre-failure analysis

• A project premortem analysis is a meeting that occurs prior to a project’s

start date. Here, the whole team discusses and ‘imagines’ scenarios that
may cause the project to fail. Team members are encouraged to speak
freely.
• Pre-mortems are logically opposite to retrospectives.
• In a pre-mortem, the team members are asked to determine possible
reasons what can go wrong or why the project could fail in future.
• Pre-mortems, logically, are similar to risk identification and analysis, since
they happen before the possible occurrence of failure in the project.
• Based on the ideas collected, team members can take actions to change
their plan or to mitigate the causes for failure.
Pre-mortem Procedures

2.

3.
1.

4
Imagine Generate Consolidate Revisit the
the Failure the the List Plan
Reasons for
Failure
People: Feedback
Agile practices are characterized by rapid feedback loops at
various stages. H
• Make the feedback constructive in nature. The person receiving the feedback should be receptive
and feel comfortable that the feedback and suggestions are being given for their improvement.

• Positive feedback is easy to communicate. But negative feedback should be carefully delivered,
otherwise it can get misconstrued very easily. One prevalent technique is the ‘sandwich method’
where the corrective feedback is sandwiched between layers of praise. The goal is not to sugar-coat,
but to make it easier to deliver and accept, as the recipient feels that the feedback is well rounded.

• Make the feedback relevant and related to the overall goals and objectives of the individual and
that of the project.

• Exhibit care as it is important that the feedback contains proper choice of words and body
language. Use of negative words and judgment could have a discouraging effect.

29
People: Feedback
• • Be specific, back up with sufficient data and give instances of observations and
examples as that is how the receiver and the feedback giver can connect better.

• • Praise in public, but criticize in private – human beings feel good receiving admiration in
public, but negative comments in public hurt them more deeply. A private space is the
best spot to deliver corrective feedback.

• • Give the feedback at the appropriate time such that the issue can be addressed
promptly. Waiting too late could have a detrimental effect on the consequences.

• • Let the feedback be regular. Especially in the team environment, it is helpful to have
one-on-one sessions at least once every 2 weeks. Feedback twice a year during the
midyear and annual performance cycles, could some with surprise, making them seldom
effective.

• • Follow up after some time to see if the feedback has been actioned or not.

30
Shore’s Team Self-Assessment Scoring Model
Tabaka’s Team Self-Assessment Model
• Self-organization: Is the team self-organizing, rather than functioning in a command-and-control, top down
organization?
• Empowered to make decisions : Is the team empowered to discuss, evaluate, and make decisions, rather
than being dictated to by an outside authority?
• Belief in vision and success: Do team members understand the project vision and goals, and do they truly
believe that, as a team, they can solve any problem to achieve those goals?
• Committed team: Are team members committed to succeed as a team, rather than being committed to
individual success at any cost?
• Trust each other: Does the team have the confidence to continually work on improving their ability to act
without fear, anger, or bullying?
• Participatory decision making: Is the team engaged in participatory decision making, rather than submitting
to authoritarian decision making or the decisions of others?
• Consensus-driven: Are the team decisions consensus-driven, rather than leader-driven? Do team members
share their opinions freely and participate in the final decision?
• Constructive disagreement: Is the team able to negotiate through a variety of alternatives and impacts
surrounding a decision, and craft the one that provides the best outcome?
Failure modes and alternatives
• Making mistakes – it is natural that people • being good at looking around
make mistakes, so there needs to be a • being able to learn
mechanism (like iterative delivery) to take
corrective actions quickly. • being malleable
• Preferring to fail conservatively – • taking pride in work
generally people are risk averse, but when
they fail, they have a tendency to revert • taking pride in contributing
back to safe and suboptimal methods • being good citizens
instead of researching further.
• taking initiative
• Inventing rather than researching – refers
to the tendency of people to reinvent the
wheels rather than looking around for
solutions that are already in place.
• Being inconsistent creatures of habit –
making it difficult to adopt new approaches.
Agile coaching and Mentoring
Individual coaching vs. team coaching
 Groundwork for one-on-one coaching

• Meet them a half-step ahead – Agile coach uses their knowledge and experience
to help team members take the next step from where they are currently.
• • Guarantee safety – Agile coaches need to maintain sensitivity and
confidentiality of the coaching conversation. Team members should be able to
openly share their thoughts and feelings without any fear of reprisal or
retribution.
• • Partner with managers – Often team members may be line managed by the
managers of other departments. It is important for the coach to collaborate with
the managers to understand their approach, rewards and strategy such that the
team member is able to receive a holistic and joined-up support from the coach
and the manager.
• • Create a positive regard – Agile coach has to maintain professionality and
positive regard of team members who need coaching, even if they are disliked.
The focus should be on helping people improve themselves in their current roles.
Agile coaching - failure modes
Agile coaching - success modes
Thank you
Muhammad Mustain Billah
+8801715524279
[email protected]
ThePMON