Lean/Agile Depth Assessment Checklist A3

Assessing the level of agility
This work is licensed under a
Creative Commons Attribution-ShareAlike 3.0 Unported License.

Why Assessing the level
of Lean/Agile?
Teams, Managers and Coaches can quickly evaluate the current
capability of a team/group, in order to:
• See how the capability measures against the recommended level
for agility
• Guide the team/group on what to improve next
• See, over time, the evolution of agility (positive or negative trend)
• See the impact of the team/group improvement work
• See the impact of organizational/structural changes that are
outside the team/group’s control (costs reductions, distributed,
etc.)
• Motivate! Get acheivements and recognition for reaching higher
agility levels (Emphasize intrinsic motivation!)

5. Build & Deployment
1. Continuous Integration – automatic build running at least
nightly
2. All code and artifacts are versioned using a single scheme
3. Build is trigged automatically upon code checked in
4. Automated regression tests run as part of build and give a
green/red binary answer (no need for analysis to determine
success/failure)
5. Frequent check-ins to common branch
6. Build failures are addressed immediately. Repeated build
failures trigger a stop the line event
3. Individuals & Interactions
Feedback Loops
1. All people involved in a work item work on it more or less in the same
time period (Developers, Testers, Functional/Product) minimizing the
overhead/waste from context switching/recalling past work.
2. 80% of the people are working on only one team at each point in time.
3. All people involved in a work item (even across silos) can collaborate
directly with each other without third parties like team leads in every
coordination/communication loop enabling faster decisions and more
scalable operation.
4. People working together act as a team with shared accountability to end
to end delivery thereby decisions are more value than silo-focused
5. Teams are relatively stable (Not ad-hoc teams recreated every couple of
weeks)
6. Significant aspects of goals and rewards are oriented towards team
performance/goals (rather than individual performance) driving
collaboration not just individualism.
7. Team environment is as collaboration friendly as possible
8. Individuals are involved in performance feedback of the people they are
working with, to encourage teamwork
4. Engineering Practices
1. There is a clear definition of what "Coding Done" means and people are
working according to it
2. People are expected to write SOLID/CLEAN code and estimations reflect it
3. Automation coverage is planned and implemented as an integral part of
production code implementation
4. Defects created as part of new development are fixed as early as possible
and in any case before considering that work item as done
5. There is a Test Automation Pyramid strategy guiding Automation coverage
decisions (Preference to Unit Tests>>API tests>>UI tests)
6. People are expected to refactor smelly code as part of "Coding Done“ and
estimations reflect it
7. Functional Design is specified Test-Driven (ATDD/BDD)
8. Sustained or improved code coverage is verified at build time using code
coverage analysis tools (e.g. Sonar)
9. Team is pro-actively and methodically improving collective ownership
10. All code is reviewed in small batches, gaps are closed within hours
11. People have access to the tools they need to do effective SW engineering
12. A prioritized backlog of Technical Debt (ugly code, missing tests, etc.) is
available and capacity is allocated to reducing it
13. Team maintains a high level of Collective ownership - most tasks can be pulled
by many members of the team without a major effect on efficiency
14. Technical Code Design is Test-Driven (TDD)
15. Regression cycle costs days at most (due to high level of automation)
6. Empowered Teams and Individuals
1. Daily planning meetings (a.k.a. Standups) are used by people to manage their day to day
work (instead of work scheduled by supervisors and pushed onto them)
2. Autonomy - People have a high degree of control over the project day 2 day execution -
Choose tasks to pull, where to focus
3. Reason/Intent is communicated as part of every requirement/work item, to increase
motivation as well as empower people to do the right thing for the context rather than
blindly follow a plan
4. People pull to capacity - by using Team Estimation approaches or just pull to WIP
5. Autonomy - People have a high degree of control over their personal & professional destiny
6. The behavior that is incentivized (formally and informally) is aligned with lean/agile thinking -
Flow, Improvement, Trust, Whole Team, Low WIP, Safe to fail experiments, etc.
7. People work in small teams (not more than 10, ideally around 5-7) enabling good
communication and direct collaboration as well as effective meetings and interaction
8. Managers are pro-actively and methodically seeking ways to improve autonomy of teams
and individuals as a way to enable faster decisions as well as higher engagement/motivation
9. People are given opportunity to improve their mastery of areas which interest them
10. People can shape their work environment – technologies, facilities, etc.
2. Business Value Driven Development
1. Product owner sees working software frequently and uses the feedback to adapt the
scope/timeline plan
2. Work items are integrative and testable cross-cutting across the architecture if necessary (e.g.
User Stories). Done = Deployable and Performant/Secure, enabling real feedback/learning.
3. Work items are integrative testable & SMALL - can be delivered in days thereby tightening the
internal team level feedback loop
4. frequent feedback from stakeholders/users is used to adapt the scope/timeline closing a real
feedback beyond the product owner.
5. Escaping Defects and other kinds of Failure Demand (Waste) are analyzed using Five Whys or
another kind of root cause analysis process in order to determine reasons for missing them earlier
in the process.
6. Value is delivered in iterative chunks using Minimally Marketable Features (MMFs) thereby
achieving business agility – faster time to market and keeping more options open to what will be
delivered after the current MMFs.
7. Requirements that are Hypothesis are validated Using MVP/MVF in a fast learning loop that
includes Beta/Early Access programs or Continuous Delivery, in order to enable safe/cheap-to-fail
experiments about risky but worthy ideas.
8. Feature Usefulness and Successfulness is evaluated as part of the development lifecycle. Learning is
applied to improve the feature and future ideas.
9. Frequent Delivery to real users - up to 8 weeks apart
10. Continuous Delivery - work items are deployed/activated/validated as part of the work life cycle - in
a matter of hours/days thereby minimizing the work done without feedback that it is in the right
direction
1. Visualize & Manage the Flow
1. Visualize who is working on what as well as in order to be aware of level of multi tasking
and dependency on specific people.
2. Commitment to finishing work over starting new (eventually reaching a WIP level that
“feels OK” for the team) to start to “weakly” constrain and improve flow.
3. Definition of what Done (Working Tested Software) means is clear and adhered to
(“DoD”) so real flow is measured and so exceptions drive discussion/improvement.
4. Visualize work flow through the different process stages (using Kanban Board or similar)
to create flow awareness
5. Use working tested software based diagrams/charts (e.g. Release Burnups, CFDs) to
provide predictability and insight into flow
6. Visualize and focus on blocked work so major flow efficiency issues are addressed
7. Visualize work that is queued/waiting between people/workflow states to start raise to
awareness reasons for queuing and identify options for reducing
8. Team is aware of different expectations for handling certain work types & people can
make intelligent flow decisions according to the context
9. Definition of what “Ready for work” means is clear and adhered to in order to minimize
rework or blocks due to unready work occupying the WIP.
10. Visualize work variability and seek to reduce it (e.g. using Velocity/Cycle Time Control
Charts) so that overall average velocity/cycle time is improved and there is less
uncertainty enabling more aggressive planning without risking predictability.
11. WIP is limited across the system e.g. using Kanban WIP Limits, Scrum Sprint Commitment.
12. Planning is Continuous – Beyond the next few weeks there is a healthy mix of committed
and uncommitted work – enabling business agility
13. Guidelines for how to pull work (selection from ‘Next’/prioritization of WIP) are clear to
everyone and adhered to so that most decisions can be decentralized and made faster as
well as driving discussion about how to work and resulting in experiments/improvements
14. Capacity is allocated to Investment Themes using work in process limits so that it is possible
to ensure certain investment in each theme.
7. Improve
1. Regular Lessons Learned events are held
frequently (every 1-4 weeks) with actionable
outcomes (e.g. Retrospectives/Kaizen)
2. People at all levels are highly aware and
involved in improvement activity
3. Actionable Improvement Work is visualized
and managed using “Stop starting start
finishing”
4. Leaders are aware of the current operational
capabilities (may require metrics)
5. Leaders have an operational capabilities goal
6. Team/Group knows the current process
challenge they are targeting
7. Team/Group knows what obstacles are
preventing them from overcoming the current
process challenge, what is currently being
addressed and how
8. Team/Group allocates capacity/time slots for
improvement work
9. Team/Group uses models to look at their
condition and suggest experiments
Agile Depth v1.1
Team:
Date:
0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
2
3
4
56
7
1

1.Visualize who is working on what as well as in order to be aware of level of multi tasking and dependency on
specific people.
2.Commitment to finishing work over starting new (eventually reaching a WIP level that “feels OK” for the team) to
start to “weakly” constrain and improve flow.
3.Definition of what Done (Working Tested Software) means is clear and adhered to (“DoD”) so real flow is
measured and so exceptions drive discussion/improvement.
4.Visualize work flow through the different process stages (using Kanban Board or similar) to create flow awareness
5.Use working tested software based diagrams/charts (e.g. Release Burnups, CFDs) to provide predictability and
insight into flow
6.Visualize and focus on blocked work so major flow efficiency issues are addressed
7.Visualize work that is queued/waiting between people/workflow states to start raise to awareness reasons for
queuing and identify options for reducing
8.Team is aware of different expectations for handling certain work types & people can make intelligent flow
decisions according to the context
9.Definition of what “Ready for work” means is clear and adhered to in order to minimize rework or blocks due to
unready work occupying the WIP.
10.Visualize work variability and seek to reduce it (e.g. using Velocity/Cycle Time Control Charts) so that overall
average velocity/cycle time is improved and there is less uncertainty enabling more aggressive planning without
risking predictability.
11.WIP is limited across the system e.g. using Kanban WIP Limits, Scrum Sprint Commitment.
12.Planning is Continuous – Beyond the next few weeks there is a healthy mix of committed and uncommitted work
– enabling business agility
13.Guidelines for how to pull work (selection from ‘Next’/prioritization of WIP) are clear to everyone and adhered to so
that most decisions can be decentralized and made faster as well as driving discussion about how to work and
resulting in experiments/improvements
14.Capacity is allocated to Investment Themes using work in process limits so that it is possible to ensure certain
investment in each theme.

1.Product owner sees working software frequently and uses the feedback to adapt the
scope/timeline plan
2.Work items are integrative and testable cross-cutting across the architecture if necessary (e.g. User
Stories). Done = Deployable and Performant/Secure, enabling real feedback/learning.
3.Work items are integrative testable & SMALL - can be delivered in days thereby tightening the
4.frequent feedback from stakeholders/users is used to adapt the scope/timeline closing a real
5.Escaping Defects and other kinds of Failure Demand (Waste) are analyzed using Five Whys or another
kind of root cause analysis process in order to determine reasons for missing them earlier in the
process.
6.Value is delivered in iterative chunks using Minimally Marketable Features (MMFs) thereby achieving
business agility – faster time to market and keeping more options open to what will be delivered after
the current MMFs.
7.Requirements that are Hypothesis are validated Using MVP/MVF in a fast learning loop that includes
Beta/Early Access programs or Continuous Delivery, in order to enable safe/cheap-to-fail experiments
about risky but worthy ideas.
8.Feature Usefulness and Successfulness is evaluated as part of the development lifecycle. Learning is
9.Frequent Delivery to real users - up to 8 weeks apart
10.Continuous Delivery - work items are deployed/activated/validated as part of the work life cycle - in
direction

Feedback Loops
1.All people involved in a work item work on it more or less in the same time period
(Developers, Testers, Functional/Product) minimizing the overhead/waste from
context switching/recalling past work.
2.80% of the people are working on only one team at each point in time.
3.All people involved in a work item (even across silos) can collaborate directly with
each other without third parties like team leads in every
coordination/communication loop enabling faster decisions and more scalable
operation.
4.People working together act as a team with shared accountability to end to end
delivery thereby decisions are more value than silo-focused
5.Teams are relatively stable (Not ad-hoc teams recreated every couple of weeks)
6.Significant aspects of goals and rewards are oriented towards team
performance/goals (rather than individual performance) driving collaboration not
just individualism.
7.Team environment is as collaboration friendly as possible
8.Individuals are involved in performance feedback of the people they are working
with, to encourage teamwork

1.There is a clear definition of what "Coding Done" means and people are working according to it
2.People are expected to write SOLID/CLEAN code and estimations reflect it
3.Automation coverage is planned and implemented as an integral part of production code
implementation
4.Defects created as part of new development are fixed as early as possible and in any case before
considering that work item as done
5.There is a Test Automation Pyramid strategy guiding Automation coverage decisions (Preference to
Unit Tests>>API tests>>UI tests)
6.People are expected to refactor smelly code as part of "Coding Done“ and estimations reflect it
7.Functional Design is specified Test-Driven (ATDD/BDD)
8.Sustained or improved code coverage is verified at build time using code coverage analysis tools (e.g.
Sonar)
9.Team is pro-actively and methodically improving collective ownership
10.All code is reviewed in small batches, gaps are closed within hours
11.People have access to the tools they need to do effective SW engineering
12.A prioritized backlog of Technical Debt (ugly code, missing tests, etc.) is available and capacity is
allocated to reducing it
13.Team maintains a high level of Collective ownership - most tasks can be pulled by many members of
the team without a major effect on efficiency
14.Technical Code Design is Test-Driven (TDD)
15.Regression cycle costs days at most (due to high level of automation)

1.Continuous Integration – automatic build running at
least nightly
2.All code and artifacts are versioned using a single
scheme
3.Build is trigged automatically upon code checked in
4.Automated regression tests run as part of build and
give a green/red binary answer (no need for analysis
to determine success/failure)
5.Frequent check-ins to common branch
6.Build failures are addressed immediately. Repeated
build failures trigger a stop the line event

1.Daily planning meetings (a.k.a. Standups) are used by people to manage their day to day work
(instead of work scheduled by supervisors and pushed onto them)
2.Autonomy - People have a high degree of control over the project day 2 day execution - Choose
tasks to pull, where to focus
3.Reason/Intent is communicated as part of every requirement/work item, to increase motivation
as well as empower people to do the right thing for the context rather than blindly follow a plan
4.People pull to capacity - by using Team Estimation approaches or just pull to WIP
5.Autonomy - People have a high degree of control over their personal & professional destiny
6.The behavior that is incentivized (formally and informally) is aligned with lean/agile thinking -
7.People work in small teams (not more than 10, ideally around 5-7) enabling good communication
and direct collaboration as well as effective meetings and interaction
8.Managers are pro-actively and methodically seeking ways to improve autonomy of teams and
individuals as a way to enable faster decisions as well as higher engagement/motivation
9.People are given opportunity to improve their mastery of areas which interest them
10.People can shape their work environment – technologies, facilities, etc.

7. Improve
1.Regular Lessons Learned events are held frequently (every 1-4 weeks)
with actionable outcomes (e.g. Retrospectives/Kaizen)
2.People at all levels are highly aware and involved in improvement activity
3.Actionable Improvement Work is visualized and managed using “Stop
starting start finishing”
4.Leaders are aware of the current operational capabilities (may require
metrics)
5.Leaders have an operational capabilities goal
6.Team/Group knows the current process challenge they are targeting
7.Team/Group knows what obstacles are preventing them from overcoming
the current process challenge, what is currently being addressed and how
8.Team/Group allocates capacity/time slots for improvement work
9.Team/Group uses models to look at their condition and suggest
experiments

1. Continuous Integration – automatic build running at least
nightly
2. All code and artifacts are versioned using a single scheme
3. Build is trigged automatically upon code checked in
4. Automated regression tests run as part of build and give a
green/red binary answer (no need for analysis to determine
success/failure)
5. Frequent check-ins to common branch
6. Build failures are addressed immediately. Repeated build
failures trigger a stop the line event
Feedback Loops
1. All people involved in a work item work on it more or less in the
same time period (Developers, Testers, Functional/Product)
minimizing the overhead/waste from context switching/recalling
past work.
2. All people involved in a work item (even across silos) can
collaborate directly with each other without third parties like team
leads in every coordination/communication loop enabling faster
decisions and more scalable operation.
3. People working together act as a team with shared accountability
to end to end delivery thereby decisions are more value than silo-
focused
4. Significant aspects of goals and rewards are oriented towards team
performance/goals (rather than individual performance) driving
collaboration not just individualism.
5. Team environment is as collaboration friendly as possible
6. Individuals are involved in performance feedback of the people they
are working with, to encourage teamwork
1. There is a clear definition of what "Coding Done" means and people are
working according to it
2. People are expected to write SOLID/CLEAN code and estimations reflect it
3. Automation coverage is planned and implemented as an integral part of
production code implementation
4. Defects created as part of new development are fixed as early as possible
and in any case before considering that work item as done
5. There is a Test Automation Pyramid strategy guiding Automation coverage
decisions (Preference to Unit Tests>>API tests>>UI tests)
6. People are expected to refactor smelly code as part of "Coding Done“ and
estimations reflect it
7. Functional Design is specified Test-Driven (ATDD/BDD)
8. Sustained or improved code coverage is verified at build time using code
coverage analysis tools (e.g. Sonar)
9. Team is pro-actively and methodically improving collective ownership
10. All code is reviewed in small batches, gaps are closed within hours
11. People have access to the tools they need to do effective SW engineering
12. A prioritized backlog of Technical Debt (ugly code, missing tests, etc.) is
available and capacity is allocated to reducing it
13. Team maintains a high level of Collective ownership - most tasks can be pulled
by many members of the team without a major effect on efficiency
14. Technical Code Design is Test-Driven (TDD)
15. Regression cycle costs days at most (due to high level of automation)
1. Daily planning meetings (a.k.a. Standups) are used by people to manage their day to day
work (instead of work scheduled by supervisors and pushed onto them)
2. Autonomy - People have a high degree of control over the project day 2 day execution -
Choose tasks to pull, where to focus
3. Reason/Intent is communicated as part of every requirement/work item, to increase
motivation as well as empower people to do the right thing for the context rather than
blindly follow a plan
4. People pull to capacity - by using Team Estimation approaches or just pull to WIP
5. Autonomy - People have a high degree of control over their personal & professional destiny
6. The behavior that is incentivized (formally and informally) is aligned with lean/agile thinking -
7. People work in small teams (not more than 10, ideally around 5-7) enabling good
communication and direct collaboration as well as effective meetings and interaction
8. Managers are pro-actively and methodically seeking ways to improve autonomy of teams
and individuals as a way to enable faster decisions as well as higher engagement/motivation
9. People are given opportunity to improve their mastery of areas which interest them
10. People can shape their work environment – technologies, facilities, etc.
1. Product owner sees working software frequently and uses the feedback to adapt the
scope/timeline plan
2. Work items are integrative and testable cross-cutting across the architecture if necessary (e.g.
User Stories). Done = Deployable and Performant/Secure, enabling real feedback/learning.
3. Work items are integrative testable & SMALL - can be delivered in days thereby tightening the
4. frequent feedback from stakeholders/users is used to adapt the scope/timeline closing a real
5. Escaping Defects and other kinds of Failure Demand (Waste) are analyzed using Five Whys or
another kind of root cause analysis process in order to determine reasons for missing them earlier
in the process.
6. Value is delivered in iterative chunks using Minimally Marketable Features (MMFs) thereby
achieving business agility – faster time to market and keeping more options open to what will be
delivered after the current MMFs.
7. Requirements that are Hypothesis are validated Using MVP/MVF in a fast learning loop that
includes Beta/Early Access programs or Continuous Delivery, in order to enable safe/cheap-to-fail
experiments about risky but worthy ideas.
8. Feature Usefulness and Successfulness is evaluated as part of the development lifecycle. Learning is
9. Frequent Delivery to real users - up to 8 weeks apart
10. Continuous Delivery - work items are deployed/activated/validated as part of the work life cycle - in
direction
1. Visualize main Work types (using Kanban Board or similar) to create flow awareness
2. Definition of what Done (Working Tested Software) means is clear and adhered to
(“DoD”) so real flow is measured and so exceptions drive discussion/improvement.
3. Visualize who is working on what in order to be aware of level of multi tasking and
dependency on specific people.
4. Commitment to finishing work over starting new (eventually reaching a WIP level that
“feels OK” for the team) to start to “weakly” constrain and improve flow.
5. Use flow diagrams/charts (e.g. CFDs) to provide predictability and insight into flow
6. Visualize and focus on blocked work so major flow efficiency issues are addressed
7. Visualize work that is queued/waiting between people/workflow states to start raise to
awareness reasons for queuing and identify options for reducing
8. Awareness of Work Types and Work Items and differences in handling, in order to enable
expectation setting with different stakeholders for different needs & allow people to make
intelligent flow decisions according to the context
9. Some areas in the flow have local work in process (WIP) limits - leading to lower WIP and
cycle times and more explicit opportunities to learn from the (lack of) flow
10. Visualize work variability and seek to reduce it (e.g. using Cycle Time Control Charts) so that
overall average cycle time is improved and there is less uncertainty about velocity/cycle
times enabling more aggressive planning
11. Explicit WIP limit at workflow level - Single workflow full pull – catching more flow
problems and driving WIP/cycle time even lower.
12. Next is re-prioritized continuously (no commitment in Next)- Deferred Pull decisions
(dynamic prioritization) in order to enable business agility.
13. Definition of what “Ready for work” means is clear and adhered to in order to minimize
rework or blocks due to unready work occupying the WIP.
14. Guidelines for how to pull work (selection from ‘Next’/prioritization of WIP) are clear to
everyone and adhered to so that most decisions can be decentralized and made faster as
well as driving discussion about how to work and resulting in experiments/improvements
15. Capacity is allocated to Investment Themes using work in process limits so that it is possible
to ensure certain investment in each theme.
7. Improve
1. Regular Lessons Learned events (frequency of
no less than every 1-4 weeks) with actionable
outcomes (e.g. Retrospectives/Kaizen)
2. People at all levels are highly aware and
involved in improvement activity
3. Actionable Improvement Work is visualized
and managed using “Stop starting start
finishing”
4. Leaders are aware of the current operational
capabilities (may require metrics)
5. Leaders have an operational capabilities goal
6. Team/Group knows the current process
challenge they are targeting
7. Team/Group knows what obstacles are
preventing them from overcoming the current
process challenge, what is currently being
addressed and how
8. Team/Group allocates capacity/time slots for
improvement work
9. Team/Group uses models to look at their
condition and suggest experiments
Agile Depth
Team: Sky1
Date: Sep 2013
0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
2
3
4
56
7
1
6
4
3
4
2
2
1

References/Attribution
• http://www.slideshare.net/ChrisAch/depth-
of-a-kanban-implementation
• http://limitedwipsociety.ning.com/photo/albu
ms/kiviat-diagrams-depth-of-kanban
• http://www.djaa.com/sites/ltdwip/DepthOfKa
nban.pdf

Lean/Agile Depth Assessment Checklist A3

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Lean/Agile Depth Assessment Checklist A3

Similar to Lean/Agile Depth Assessment Checklist A3 (20)

More from Yuval Yeret

More from Yuval Yeret (20)

Recently uploaded

Recently uploaded (20)

Lean/Agile Depth Assessment Checklist A3