Lean Simulation Games

L EAN S OFTWARE
D EVELOPMENT
Neal Gabriel
28 March 2017
3/28/2017
Contents
Overview........................................................................................................................................2
Eliminating Waste...........................................................................................................................2
Delay...........................................................................................................................................2
Possible reasons:....................................................................................................................2
How can you eliminate it?......................................................................................................3
Handoffs.....................................................................................................................................3
Partially Done Work....................................................................................................................4
Extra Features.............................................................................................................................5
Task Switching............................................................................................................................5
Relearning...................................................................................................................................6
Defects........................................................................................................................................6
Industry research revealed these software development wastes:.............................................7
Amplify learning.............................................................................................................................7
Decide as late as possible...............................................................................................................8
Deliver as fast as possible...............................................................................................................8
Empower the team.........................................................................................................................9
Build integrity in.............................................................................................................................9
See the whole...............................................................................................................................10
1
3/28/2017
Lean Software Development

OVERVIEW
Lean Software Development is an iterative agile methodology originally developed by Mary and
Tom Poppendieck. Lean Software Development owes much of its principles and practices to the
Lean Enterprise movement, and the practices of companies like Toyota. Lean Software
Development focuses the team on delivering Value to the customer, and on the efficiency of the
“Value Stream,” the mechanisms that deliver that Value. The main principles of Lean
methodology include:
 Eliminating Waste
 Amplifying Learning
 Deciding as Late as Possible
 Delivering as Fast as Possible
 Empowering the Team
 Building Integrity In
 Seeing the Whole
The core idea of lean is to eliminate/reduce non-value-added activities (termed "wastes") and
thus increase customer value. The Agile process itself is a lean method for the software
development life cycle, and I am sharing a couple of Agile best practices adopted by many teams
to make the Agile process extra lean
ELIMINATING WASTE
Lean philosophy regards everything not adding value to the customer as waste. Such waste may
include
Delay
Anything that causes more time to deliver a value-added activity, or delays the beginning of the
value-added activity. Up to 80% of business activity time is lost in “wait time” due to transit
and overhead not related to business. To avoid delays, start delivering smaller units of work as
frequent as possible.
Possible reasons:
 Lack of required team members
 Unwanted processes
 Too many things in progress
 External dependencies
 Lack of "value" understanding
 Assumptions/clarifications and impediments
How can you eliminate it?
 Make sure you have all the required skill sets assigned to your project. If you start a
sprint without having the required team members with the proper skill sets, this will
lead to delays.
 Identify only mandatory processes at the beginning of the sprint. For example, if you do
not need to get the code review for all of the code, then categorize the code into low
2
3/28/2017
complex, medium complex, and high complex, and send only medium and high complex
code for review. This will reduce the cycle time and increase efficiency.
 Keep only what you can handle on your plate and leave the rest open. This will help
other team members pick up the work that's based on their skill sets and bandwidth.
 Make sure to have all required external assistance available in time for your work. For
example, if you need an external architect review, plan for it up front. Similarly, if you're
working with multiple teams from different locations, then encourage stub-based
development. I have personally observed that when we have videoconferencing calls
with other teams working from different locations, usually the videos won't work, you
have to waste time to fix the problem, if it isn't fixed in a certain amount of time you
need to make alternate arrangements, etc. (One way to tackle the delays in such calls is
for the Scrum Masters from both teams go on the call two minutes beforehand and
ensure that everything is working properly. Also, always keep a conference bridge
number as backup, and after a fixed amount of time -- say, five minutes -- spent trying
to fix any problems, move to the conference bridge.)
 Always try to do value stream mapping and see what value-added time is and what is
not. This will give you an idea of what your current process efficiency is. Based on the
current state of the value stream map, and by applying Lean practices, you can improve
the cycle time and thereby reduce delays. Also, automate the test cases wherever
possible so that you can reduce a considerable amount of time when you have to run
them recursively.
 Make sure you get clarity on your assumptions and inputs for your clarifications at the
right time. Raise the red flag before you get into the danger zone, and get proper
attention from respective stakeholders. Track your impediments effectively; the Scrum
Master is responsible for resolving the team's impediments.
Handoffs
Handoffs means, passing the work from person to another, after completing the first person's
work. Teams using a sequential development process have become accustomed to handoffs
between specialists. Analysts hand their work to designers, who hand it to programmers, who
pass it on to testers. Teams that are new to Scrum often do not go far enough in eliminating
these handoffs, wrongly assuming, for instance, that the programmers should finish
programming a product backlog item before handing it off to the testers or that analysts should
work at least one sprint ahead of the rest of the team.
Possible reasons:
 The nature of the tasks required for a story
 Teams working from different locations
 Lack of visibility of the information
 Sometimes it is unavoidable, and different tasks have to be done by different team
members (e.g., analysis, UI, client-side coding, server-side coding, etc). It's good to have
cross-functional teams so that, over a period of time, the handoffs can be reduced.
 When teams are working from different locations (time zones), if the information is not
properly handed over, then this will lead to waiting. So make sure there is a proper
hand-off process, and obtain confirmation from the other side of the team. Also make
sure to execute the tasks at one location as much as possible, as this will reduce hand-
offs and waiting time.
3
3/28/2017
 Try to keep important flowcharts and wireframes visible and clear. This can also be
helpful to reduce hand-off time. Your Kanban task board, with regular updates, will
really help here, along with your Definition of Done.
Partially Done Work
It generally means that the work (story) that is not completely done as per your Definition of
Done, and hence you cannot demo it or you cannot release it. This can include code that is not
refactored, code that is not unit tested/integration tested, code that is not properly
documented, code that is not deployable, etc.
Possible reasons:
 Prioritizing a story without having complete information about that story from the
product owner
 Technical complexity that was not analyzed properly during the sprint planning
 Wait time between the tasks that are identified to complete the story
 Improper dependencies for this story based on other stories
 Removing an existing story that is halfway done and getting a new story into the sprint
 Incomplete/inadequate tasks identification
 Try to have a detailed discussion with product owner to understand the functionality of
the story, and also to understand what value it adds to the product. Then prioritize it for
a sprint. This calls for great coordination and collaboration between the team and the
product owner.
 Try to evaluate the technical complexity of the story based on its functionality. If
required, go for a technical spike before you arrive at the estimate. This will, at the least,
help you assess how complex it is so that you can either pick it up directly or ask the
product owner to split it -- or go with some other technical implementation approach.
 Try to do tasks in parallel as much as possible. This should be the true Agile way and not
a Mini-Waterfall way. When you are stuck somewhere, look for help. Develop he cross-
functional teams that can address this point effectively, because anyone can pick up any
task at least to some extent.
 Manage your product backlog in such a way that the dependencies among various
stories are clearly identified before the stories are picked up for a sprint. Again, this
needs lot of coordination and collaboration between the team and the product owner.
Sometimes the product owner may not have understood the technical dependencies, so
in such scenarios the team should help the product owner. Example: Log-in cannot be
prioritized without registration.
 When you have stories lined up (committed) for a sprint, do not try to manipulate them
during the sprint. It will add unnecessary rework and will lead to a loss in velocity.
 When you decompose the story into tasks in your sprint planning meeting, try to spend
a good amount of time and involve all the team members. This will help you to come up
with all the required tasks to complete the story. If you do not do this, you will have an
insufficient list of tasks but, in reality, you will have to perform every task to complete a
story. So the tasks that are not identified in your sprint planning may lead to additional
effort that is not planned, so it may ultimately push your story to an "incomplete" state.
Extra Features
Providing more than what is being asked for. Remember the Pareto principle (80 percent of
users use only 20 percent of the product features).
4
3/28/2017
Possible reasons:
 Lack of understanding of the product vision
 Who is in your product's "target audience"?
 Gold-plating by the development team
 Wrong prioritization of product features
 The product backlog is the baby of the product owner, who should map it to the product
vision. He or she is also responsible for the product ROI. So the product owner is
responsible for managing the product backlog according to the product vision. He
should prioritize the stories as per the value.
 Every product will have its own target audience, the primary users of the product. The
product owner has to make sure to identify the target audience, and only then start
creating the product backlog. If required, use personas to identify the features based on
the target audience.
 Gold-plating generally comes from the development team, and sometimes it can be
unintentional. While prioritizing the stories for a sprint, the product owner and the
development team have to come to a common agreement on the stories for that sprint,
and they must stick to that list.
 Right from the release planning, the product features have to be carefully prioritized.
The keys to prioritizing these stories are value, cost, and risk.
Task Switching
Team members moving from one task to another without completing the first task properly.
Possible reasons:
 Interruptions in the ongoing tasks
 Lack of ground-level analysis of the tasks required for the stories
 A shared team working on more than one project at a time
 Lack of proper coordination between the product owner and development team
 Interruptions can be due to many reasons, including lack of complete information about
the task, hardware-related dependencies, etc. Make sure the tasks are detailed enough
in the sprint planning meeting and identify any external dependencies up front. Raise
them as impediments and let the Scrum Master work on them.
 Make sure to spend enough time when you're splitting the stories into tasks during your
sprint planning meeting. You need to identify all the possible tasks, and also identify the
order of those tasks, so that you can work on one story until it's completely done
without any task switching.
 Ideally, Scrum teams should be dedicated teams. If you have shared teams, then
naturally that leads to task switching.
 If the product owner does not provide the priority of the stories during the sprint
planning, this may lead to juggling between stories during the sprint. This, in turn, leads
to task switching. So try to have the stories prioritized by the product owner. For this
the value, cost, and risk are the key factors, as mentioned above.
Relearning
Not using the knowledge that is available within the team members, trying to reinvent the
wheel.
5
3/28/2017
Possible reasons:
 Lack of a proper knowledge-sharing process within the team
 Lack of required documentation
 Missing information radiation and osmatic communication
 Distributed teams
 The team should share knowledge continuously throughout the sprint. The best places
for knowledge sharing are the daily Scrum meeting and the task board. All the team
members should participate in all team meetings. This will enhance knowledge sharing.
 The general myth about Agile is: "Agile is anti-documentation." This is not true. The
team should prepare all the required documentation, but it should always be "just in
time."
 Try to keep all important information displayed in a team space so that everyone has
equal access. Osmatic communication plays a vital role in information sharing and
knowledge distribution. Make sure to document the "tacit knowledge" that will be
repeatedly required. You can use tools such as SharePoint, Wiki, etc.
 Co-location is the best approach for executing agile projects. If this isn't possible, due to
any practical reasons, use tools like videoconferencing so that knowledge sharing is
easier.
Defects
Erroneous functionality that produces wrong output.
Possible reasons:
 Lack of understanding on the story
 The story does not satisfy the INVEST principle
 Lack of engineering practices such as TDD, refactoring
 Missing acceptance criteria
 Lack of technical skill sets for team members
 Late involvement of testers
 Inattention to the automation testing
 Don't jump in to story development until you have a complete understanding of the
story. Refer to the tenth agile principle -- simplicity, or maximizing the amount of work
undone. Wherever more complexity is involved, then go with the "specification by
example" approach.
 The product owner has to ensure that the story follows the INVEST principle. If not, then
try to split it into more granular stories.
 Be strict about making test-driven development, pair programming, and refactoring part
of your development plan. These are powerful engineering practices.
 The product owner must attach the acceptance test criteria to each story that is
prioritized for a sprint. This will help the developer understand the story in more detail
from the implementation point of view.
 Make sure you have right skills on the team and also have suitable coding standards and
guidelines in place up front.
 It is always good to have the testers involved right from the sprint planning stage. It will
help them engage in the largest possible test coverage, which reduces defects.
6
3/28/2017
 Make sure to have an automated test suite created from the very first sprint. For any
project, a certain number of test cases (sanity tests) will have to run more than once, so
automating them will save time and also reduce defects.
Industry research revealed these software development wastes:
 Building the wrong feature or product
 Mismanaging the backlog
 Rework
 Unnecessarily complex solutions
 Extraneous cognitive load
 Psychological distress
 Waiting/multitasking
 Knowledge loss
 Ineffective communication.
In order to eliminate waste, one should be able to recognize it. If some activity could be
bypassed or the result could be achieved without it, it is waste. Partially done coding eventually
abandoned during the development process is waste. Extra processes like paperwork and
features not often used by customers are waste. Switching people between tasks is waste.
Waiting for other activities, teams, processes is waste. Motion required to complete work is
waste. Defects and lower quality are waste. Managerial overhead not producing real value is
waste.
A value stream mapping technique is used to identify waste. The second step is to point out
sources of waste and to eliminate them. Waste-removal should take place iteratively until even
seemingly essential processes and procedures are liquidated.
AMPLIFY LEARNING
Software development is a continuous learning process based on iterations when writing code.
Software design is a problem solving process involving the developers writing the code and what
they have learned. Software value is measured in fitness for use and not in conformance to
requirements.
Instead of adding more documentation or detailed planning, different ideas could be tried by
writing code and building. The process of user requirements gathering could be simplified by
presenting screens to the end-users and getting their input. The accumulation of defects should
be prevented by running tests as soon as the code is written.
The learning process is sped up by usage of short iteration cycles – each one coupled with
refactoring and integration testing. Increasing feedback via short feedback sessions with
customers helps when determining the current phase of development and adjusting efforts for
future improvements. During those short sessions both customer representatives and the
development team learn more about the domain problem and figure out possible solutions for
further development. Thus the customers better understand their needs, based on the existing
result of development efforts, and the developers learn how to better satisfy those needs.
Another idea in the communication and learning process with a customer is set-based
development – this concentrates on communicating the constraints of the future solution and
not the possible solutions, thus promoting the birth of the solution via dialogue with the
customer.
7
3/28/2017
DECIDE AS LATE AS POSSIBLE

As software development is always associated with some uncertainty, better results should be
achieved with an options-based approach, delaying decisions as much as possible until they can
be made based on facts and not on uncertain assumptions and predictions. The more complex a
system is, the more capacity for change should be built into it, thus enabling the delay of
important and crucial commitments. The iterative approach promotes this principle – the ability
to adapt to changes and correct mistakes, which might be very costly if discovered after the
release of the system.
An agile software development approach can move the building of options earlier for customers,
thus delaying certain crucial decisions until customers have realized their needs better. This also
allows later adaptation to changes and the prevention of costly earlier technology-bounded
decisions. This does not mean that no planning should be involved – on the contrary, planning
activities should be concentrated on the different options and adapting to the current situation,
as well as clarifying confusing situations by establishing patterns for rapid action. Evaluating
different options is effective as soon as it is realized that they are not free, but provide the
needed flexibility for late decision making.
DELIVER AS FAST AS POSSIBLE

In the era of rapid technology evolution, it is not the biggest that survives, but the fastest. The
sooner the end product is delivered without major defects, the sooner feedback can be
received, and incorporated into the next iteration. The shorter the iterations, the better the
learning and communication within the team. With speed, decisions can be delayed. Speed
assures the fulfilling of the customer's present needs and not what they required yesterday. This
gives them the opportunity to delay making up their minds about what they really require until
they gain better knowledge. Customers value rapid delivery of a quality product.
The just-in-time production ideology could be applied to software development, recognizing its
specific requirements and environment. This is achieved by presenting the needed result and
letting the team organize itself and divide the tasks for accomplishing the needed result for a
specific iteration. At the beginning, the customer provides the needed input. This could be
simply presented in small cards or stories – the developers estimate the time needed for the
implementation of each card. Thus the work organization changes into self-pulling system –
each morning during a stand-up meeting, each member of the team reviews what has been
done yesterday, what is to be done today and tomorrow, and prompts for any inputs needed
from colleagues or the customer. This requires transparency of the process, which is also
beneficial for team communication. Another key idea in Toyota's Product Development System
is set-based design. If a new brake system is needed for a car, for example, three teams may
design solutions to the same problem. Each team learns about the problem space and designs a
potential solution. As a solution is deemed unreasonable, it is cut. At the end of a period, the
surviving designs are compared and one is chosen, perhaps with some modifications based on
learning from the others - a great example of deferring commitment until the last possible
moment. Software decisions could also benefit from this practice to minimize the risk brought
on by big up-front design.
EMPOWER THE TEAM
8
3/28/2017
There has been a traditional belief in most businesses about the decision-making in the
organization – the managers tell the workers how to do their own job. In a "Work-Out
technique", the roles are turned – the managers are taught how to listen to the developers, so
they can explain better what actions might be taken, as well as provide suggestions for
improvements. The lean approach follows the Agile Principle find good people and let them do
their own job, encouraging progress, catching errors, and removing impediments, but not micro-
managing.
Another mistaken belief has been the consideration of people as resources. People might be
resources from the point of view of a statistical data sheet, but in software development, as well
as any organizational business, people do need something more than just the list of tasks and
the assurance that they will not be disturbed during the completion of the tasks. People need
motivation and a higher purpose to work for – purpose within the reachable reality, with the
assurance that the team might choose its own commitments. The developers should be given
access to the customer; the team leader should provide support and help in difficult situations,
as well as ensure that skepticism does not ruin the team’s spirit.
BUILD INTEGRITY IN
The customer needs to have an overall experience of the System. This is the so-called perceived
integrity: how it is being advertised, delivered, deployed, accessed, how intuitive its use is, its
price and how well it solves problems.
Conceptual integrity means that the system’s separate components work well together as a
whole with balance between flexibility, maintainability, efficiency, and responsiveness. This
could be achieved by understanding the problem domain and solving it at the same time, not
sequentially. The needed information is received in small batch pieces – not in one vast chunk -
preferably by face-to-face communication and not any written documentation. The information
flow should be constant in both directions – from customer to developers and back, thus
avoiding the large stressful amount of information after long development in isolation.
One of the healthy ways towards integral architecture is refactoring. As more features are
added to the original code base, the harder it becomes to add further improvements.
Refactoring is about keeping simplicity, clarity, minimum number of features in the code.
Repetitions in the code are signs of bad code designs and should be avoided. The complete and
automated building process should be accompanied by a complete and automated suite of
developer and customer tests, having the same versioning, synchronization and semantics as
the current state of the System. At the end the integrity should be verified with thorough
testing, thus ensuring the System does what the customer expects it to. Automated tests are
also considered part of the production process, and therefore if they do not add value they
should be considered waste. Automated testing should not be a goal, but rather a means to an
end, specifically the reduction of defects.
SEE THE WHOLE

Software systems nowadays are not simply the sum of their parts, but also the product of their
interactions. Defects in software tend to accumulate during the development process – by
decomposing the big tasks into smaller tasks, and by standardizing different stages of
development, the root causes of defects should be found and eliminated. The larger the system,
the more organizations that are involved in its development and the more parts are developed
by different teams, the greater the importance of having well defined relationships between
9
3/28/2017
different vendors, in order to produce a system with smoothly interacting components. During a
longer period of development, a stronger subcontractor network is far more beneficial than
short-term profit optimizing, which does not enable win-win relationships.
Lean thinking has to be understood well by all members of a project, before implementing in a
concrete, real-life situation. "Think big, act small, fail fast; learn rapidly"[9] – these slogans
summarize the importance of understanding the field and the suitability of implementing lean
principles along the whole software development process. Only when all of the lean principles
are implemented together, combined with strong "common sense" with respect to the working
environment, is there a basis for success in software development.
10

Lean Simulation Games

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Lean Simulation Games

Uploaded by

Copyright:

Available Formats

L EAN S OFTWARE

Lean Software Development

DECIDE AS LATE AS POSSIBLE

DELIVER AS FAST AS POSSIBLE

EMPOWER THE TEAM

SEE THE WHOLE

You might also like