LEAN VS AGILE

Why Lean Is Different Than Agile

Is Agile a part of Lean? Is Agile the same as Scrum, or a part of Kanban? What is “Waterfall?”
There has been a lot of confusion over these terms, and the processes behind them. A lot of the
confusion is caused by the way they frequently overlap. Let’s take a look at the definitions for
each of these terms, and then expand on each for a clearer understanding of which of these, or
what combination of them, would be a best fit for you. We’ll first give a brief definition for each
of these terms, and then explore them a little more fully.

Agile - Development methods in which requirements and solutions evolve from collaboration
between self-organizing, cross-functional teams. (production model)

Kanban - is an inventory-control scheduling system for lean manufacturing and just-in-time

manufacturing. Kanban is used to control the supply chain and improve manufacturing
efficiency. (system)

Lean - A set of principles or fundamental truths that defines behavior. Eliminating waste.
Project management principles for achieving quality, speed & customer alignment. (strategy)

Scrum - A flexible, holistic product development strategy where a development team works as
a unit to reach a common goal," as opposed to a "traditional, sequential approach. (strategy)

Scrumban - a software production model based on scrum and kanban especially suited for
maintenance projects or (system projects) with frequent and unexpected work items or
programming errors. (scheduling process)

Scrum-But - a term to describe the approach of a team who have modified parts of the
standard scrum process to adapt it to their unique needs.

Waterfall - Traditional approach to software development where all analysis and design are
done prior to beginning development. (production model)

Waterfall+Agile Hybrid - Combining the best virtues of both methods. (method)

Waterfall Project Management

Back in the early days of the original World Wide Web (Web 1.0) HyperText Markup Language
was the only available language used to create websites. The process of developing the website
was front-end heavy with extensive highly detailed design planning. The process was also
usually rife with angst for both the developer and the product owner as they attempted to
identify every tiny detail of the project so a development timeline and budget could be
developed.

LEAN VS AGILE 2
That process is now called the “Waterfall method” of software development. It was based on the
original form of sequential production management used for manufacturing dating back to
Ransom Old’s introduction of assembly line style production in 1901. The efficiencies gained
from the assembly line proved that working on things in the correct order helps ensure that you
deliver value to the customer at every stage. The Waterfall assembly process is maximized by
establishing a system that works smoothly and efficiently, and then creating a strategy to make
it repeatable.
According to a book entitled Michigan Yesterday & Today authored by Robert W. Domm, Olds
invented the assembly line process in order to build the first mass-produced automobile, the
Oldsmobile Curved Dash in his Olds Motor Vehicle Company factory. This fact is often
overshadowed by Henry Ford’s, steam powered conveyor belt assembly line that could produce
a Model T in 93 minutes. Ford’s “automated” assembly line began operation on December 1,
1913 and had an immense influence on the manufacturing world.
Ford was said to have been inspired by the animal "disassembly" line of Chicago's meatpacking
operations. The production techniques he observed there were adapted to his manufacturing
process which lowered unit production costs, and allowed the Ford Motor Company to thrive.

Made in Chicago: The Slaughterhouse Disassembly Line

Chicago pork packers created a labor-intensive, lightning-fast

disassembly line. The Union Stockyards routinely processed
5,000 or more hogs every day, taking just 15 minutes to
slaughter each animal.
Hundreds of workers, many of them immigrants, performed
specialized tasks in the 13-step process: hanging the live hog
by its leg, cutting its throat, scalding it, attaching it to a cable,
scraping, cleaning, washing, inspecting, de-gutting, de-larding,
decapitating, splitting, and, finally, chilling. CHICAGO HISTORICAL SOCIETY

Using this sequential process, activities were scheduled one after the other in the proper order.
Design always started when analysis was done, and Requirements identified. Coding followed
design, etc. The idea was to plan how many hours it would take to do the work, finish on time,
and then show the final product to the customer and see if they liked it.
This sequential production process was also applied to early software development, although it
never did quite fit the needs of an industry where technology and advancements were
progressing at a pace described by Moore’s Law. That manufacturing process just couldn’t keep
pace, and software code was usually outmoded before the product was completed.

Sequential Software Development

In this sequential assembly line method we can visualize what specialists will be needed at each
stage of the project, so we can change the team members as each phase is finished.
Unfortunately, most software projects never reached that level of efficiency because
requirements got changed before the project ended, and, often right from the very beginning
of production. Often as one team worked on the next stage of development, the previous team
was going back and changing things in the earlier stage(s).

LEAN VS AGILE 3
 Requirements

Design

Implementation

Verification

Maintenance

Many organizations, agencies and customers, suffered financial loss because of rapidly
changing requirements in the code to keep up with new capabilities that were becoming
available. Software development agencies struggled under customer requests for changes to
projects underway to ensure they weren’t outmoded when released. Customers usually didn’t
realize the cost to the development agency for this additional unplanned work, and often
balked at reimbursing the developer for these additional work hours.
In an attempt to make the Waterfall process work more efficiently, agencies then added
Statements of Work (SOW) to the Requirements stage to better define what is included in a
project, and what is not included. Potential changes during development could not be divined
in advance, so the SOW provided for a Change Control Process, which allowed the agency to
identify and charge for billable work that was not included in the original estimate or price
quote. Unfortunately, this process was “sticky,” and added to the minutia and paperwork, which
often slowed projects down to a crawl, and forced budgets to burst at the seams.
Those problems led to the Waterfall method being largely abandoned for most software
projects, in favor of other methods that were more adaptable to the needs of the software
developer. And, that has further led to modification and a resurgence of the Waterfall process
to incorporate applicable merits of these better suited processes, which we will discuss later in
this document.
The Lean Methodology

Meanwhile, as software developers struggled with how to manage the Waterfall Method, the
assembly line manufacturing process was also changing, largely due to automation, and robots
becoming widely adopted by the automotive companies to gain higher efficiency,
competitiveness, and, thus, profitability.

According to Wikipedia, lean manufacturing or

TPS
lean production is a systematic method for the
Goal: Highest Quality, Lowest Cost, Shortest Lead Time elimination of waste within a manufacturing
Just-in-Time Jidoka system. Lean also takes into account waste
Stop and notify of created through overburden and waste created
Continuous Flow
abnormalities
Takt Time Separate human through unevenness in work loads. Working
work and machine
Pull System
work from the perspective of the customer who
Heijunka Kaizen consumes a product or service, "value" is any
Standardized Work
action or process that a customer would be
Stability willing to pay for.

Essentially, lean is centered on making obvious what adds value by reducing everything that
doesn’t. The Lean Methodology is derived mostly from the Toyota Production System (TPS)

LEAN VS AGILE 4
Toyota Production System
Toyota Motor Corporation's TPS is a production system steeped in the philosophy of the
complete elimination of all waste in pursuit of the most efficient methods. It’s a way of "making
things" in a "Just-in-Time (JIT) system." If you don’t need it, you don’t make it.
This production control system was established by Toyota based on years of continuous
improvements, with the objective of making vehicles in the quickest and most efficient way, as
quickly as possible.
TPS is based on two concepts: The first is called "jidoka" (which can be loosely translated as
"automation with a human touch") which means that when a problem occurs, the equipment
stops immediately, preventing defective products from being produced; The second is the
concept of "Just-in-Time," in which each process produces only what is needed by the next
process in a continuous flow.
Based on the basic philosophies of jidoka and Just-in-Time, the TPS can efficiently and quickly
produce vehicles of sound quality, one at a time, that fully satisfy customer requirements.
Renowned for its focus on reduction of the original process to improve overall customer value,
with varying perspectives on how this is best achieved, this methodology was widely studied
and identified as "Lean" in the 1990s.

Lean Software Development

The Lean methodology for software project management is a set of principles for achieving
quality, speed & customer alignment by 1) eliminating waste, 2) building quality in, 3) creating
knowledge, 4) deferring commitment, 5) delivering fast, 6) valuing people, and 7) optimizing the
whole.
Mary & Tom Poppendieck first adapted the principles of Lean Manufacturing to fit software
development and their adaptations provide effective premises behind why Agile works with
Lean. More about this in a moment.
Lean practices tirelessly eliminate anything that isn’t adding value to the task being done, and
provides resources only to what needs to be done at any time. Eliminating waste includes
eliminating wasteful sit-down meetings, tasks and documentation. It also means eliminating
resource time spent building what might be needed in the future.
Change is happening at a faster rate than ever today, and what we think we’ll need can be made
completely irrelevant by the next app that hits the market, or the next new gizmo that changes
everything. Thirdly, it also means eliminating inefficient ways of working, like multitasking, so
we can remain focused and deliver fast.
Lean also puts a very strong emphasis on “the
Principles of Lean Thinking
system,” or, in other words, the way the team
1. Eliminate Waste operates as a whole; always looking at each
2. Increase Feedback task from a top level to ensure they are
3. Delay Commitment optimizing for the whole. Lean also says to
4. Deliver Fast respect that the people doing the work are
those that know best how to do it; give them
5. Build Integrity In
what they need to be effective and then trust
6. Empower the Team
them to do it.
7. See the Whole

LEAN VS AGILE 5
Finally, develop a process that ensures that quality is built into the product. There’s no way to
continuously deliver fast if you have to keep going back to clean up messes in the code. Test
Driven Development and Continuous Integration lend themselves very well to the Lean
ecosystem, as they greatly reduce the occurrence of residual errors and aim to improve the
overall quality of software. They reduce the time taken to deliver software by replacing the
traditional practice of applying quality control only after completing development.
Basically, it comes down to building the right way and building the right product. A major factor
in the Lean approach is that it often requires a change in mindset by managers. Traditionally
managers have been tasked with the responsibility to “optimize” individual workers by ensuring
they’re always producing 100% of the time. This can be highly counterproductive in software
development.
In fact, there is the obvious case to be made for giving developers the freedom to surf the web,
or do other mind-clearing activities, so they can tackle code with renewed energy. Justin
Litchfield, a senior software developer writing about productivity, blogged, “I know that when I’m
on, I’m ON, and I can produce prodigiously. If I’m dragging my feet, I write garbage.”

Where to Start?
There are many excellent resources available to help startups learn how to run lean, including
books, white papers, blog articles, and websites. We will list a few here, but use your favorite
search engine to research the topic, and you’ll find a wealth of information to help you.
An excellent resource we have used ourselves is the Lean Canvas business planning process
created by Ash Maurya of Leanstack. The Lean Canvas. It is a delightfully quick way to define
your business without the administrivia of a full business plan. It uses a 1-page business model
that helps you iterate quickly through your challenges and target markets, define your unique
value proposition, test assumptions, and ultimately arrive at your first iteration Minimum Viable
Product.
“Organizations that are truly lean have a strong competitive advantage because they respond very
rapidly, and in a highly disciplined manner to market demand, rather than try to predict the future.”
– Mary Poppendieck

The Agile Methodology

Agile refers to a set of values and principles put forth in the Agile Manifesto which places
primary value on
1) Individuals and interactions rather than processes and tools;
2) working software rather than comprehensive documentation;
3) customer collaboration rather than contract negotiation; and,
4) responding to change rather than following a plan.

These values change our focus to managing goals rather than managing activity. Visualize the
process itself as being the constant. Then apply the process to the user stories in sequence. The
activities are ongoing and the user stories get whatever they need.

LEAN VS AGILE 6
The Agile process takes the traditional development process and turns it 90 degrees on its side.
This allows managers to get an estimated cost per feature instead of per activity. Customers can
then make the difficult decisions about what can be left undone in a more intelligent way.
Agile methods are more flexible than the original Waterfall method which means that
customers’ requests for change are more likely to be easily met. Even when requirements
change, the team’s constant focus on value means what they’ve already delivered should have
been worthwhile. And the underlying rhythm that Scrum creates helps build highly motivated
teams where productivity increases over time.

Agile Principles
Agile software development is a group of software development methods in which
requirements and solutions evolve from collaboration between self-organizing,
cross-functional teams. It promotes adaptive planning, evolutionary development, early
delivery, continuous improvement, and rapid and flexible response to change. The Agile
Manifesto first laid out the underlying concepts of Agile development in 2001 as an adaptation
of Lean manufacturing principles modified to fit software development.
There are five Agile principles that provide direction and structure for creating an agile software
development process: 1) Iterate, 2) Learn, 3) Defer Decisions, 4) Deliver Fast, and, 5) Eliminate
Waste. Sound familiar? Let’s take a closer look at these principles.
• Iterate. An agile business tosses away routine, by working incrementally and iteratively.
That means breaking production down into pieces, working on those pieces, called an
Iteration, one at a time, and getting each piece right before moving on to the next one. An
iteration is a single development cycle, typically measured as one or two weeks, and also
often called a sprint. The iteration process lends itself very well to software development, in
which a team often has to actually write and test draft code before discovering the right way
to form it.
• Learn. Place a very high value on learning from doing your business. Experiment, try, test,
revise, solicit feedback, evaluate data, and learn. Being agile isn’t always easy. In fact, it often
requires a complete revision of one’s mindset. Not only are you relearning operating
methods, you also have to think about managing your business differently. We humans prefer
success over failure, but we can also learn a great deal from our efforts that don’t work.
For example, traditional managerial emphasis on failure avoidance fails to recognize failure
as an essential requisite for effective organizational learning and adaptation. Sim B. Sitkin,
writing in Learning Through Failure, states that small failures may actually be a safety and
survival-enhancing asset. The key is to learn from those errors, adapt, adjust and hone to
replace those failures with processes or products that work properly.
• Defer Decisions Until the Last Responsible Moment. It feels great when we think we’ve
worked out all the answers and know what we’re doing. But, that’s a false sense of security
when everything is changing so much every day. Agile is about expecting to being a little
unsettled about where we are today, and recognizing that we need to constantly adapt, and
be ready to evolve to our own next iteration. Who we will be tomorrow depends greatly on
what happens today outside our own control. Planning, then, takes on a sense of
immediacy, and should be deferred until the last responsible moment.

LEAN VS AGILE 7
 • Deliver Fast. In software development, we know that customers are going to change their
direction, needs and desires during the project. A part of the reason this happens is that
new interests and capabilities arrive every day in this fast changing world. Since we know
there’s a very high probability that we’re going to make changes, then it makes sense to get
iterations out there quickly so we can test, get feedback, learn from it and make
improvements to add value to the product owner and the end user.
• Eliminate Waste. Based on the seven wastes of manufacturing industry, Mary and Tom
Poppendieck defined seven wastes that are appropriate for software development.
Waste #1: Partially done work - coding that is not “done,” as per your Definition of
Done, and hence you cannot demo it or you cannot release it. This includes code that is
not refactored, or not unit tested/integration tested, or not properly documented, or,
for whatever reason, is not deployable.
Waste #2: Extra features - providing more than what is being asked for. This is always a
temptation due to new features and capabilities coming into the development
ecosystem, and of course, we want to provide our customers with the latest and
greatest.
Waste #3: Relearning (Retraining) - not using the knowledge that is available within the
team members due to a lack of a proper knowledge-sharing processes within the team
Waste #4: Handoffs - passing the work from one person to another, due to a lack of
cross-functional teams, shared flowcharts and wireframes., and a Kanban task board,
with your Definition of “Done.”
Waste #5: Delays - anything that requires more time to deliver a value-added activity, or
delays the beginning of the value-added activity.
Waste #6: Task Switching - team members moving from one task to another without
completing the prior task.
Waste #7: Defects - erroneous functionality that produces wrong output due to:
1. Lack of understanding of the User Story
2. The story does not satisfy the INVEST principle
3. Lack of engineering practices such as TDD and refactoring
4. Missing acceptance criteria
5. Lack of technical skill sets for team members
6. Late involvement of testers
7. Inattention to the automation testing
For a more detailed examination of these principles, see Vijay Bandaru’s article, “How to
Manage the "7 Wastes" of Agile Software Development” on Scrum Alliance’s blog.

Applying The Agile Mindset Framework

A mindset is a set of assumptions, methods, or notions that create a powerful motivation to
adopt certain behaviors or practices. The Agile Mindset Framework relates to how you
incorporate Agile in creating and operating your business. Key components of the Agile Mindset
can be divided into personal mindsets, and team mindsets.

LEAN VS AGILE 8
 The Agile Mindset

PEOPLE TEAMS

• Enjoy coding and collaborating • Embrace change

• Communicate openly
• Willingly share knowledge
• Are interesting in learning
• Take pride in code perfection
• Have fun at work
• Welcome diverse thinking
• Practice "brutal" transparency
• Work at a sustainable pace
• Identify and correct Agile antipatterns
• Use failure as a learning opportunity

The agile mindset can be applied, not only to software development, or manufacturing, but also
to establishing your business. By creating the Agile framework for daily operations, you can
ensure that your business is able to respond to changing market conditions and survive
disruption that is occurring at an ever increasing rate.
• Vision. By creating a vision for your business, you create an objective, a destination, and
establish long term goals. When you have clearly defined your vision along with core
values, you have everything you need to get started. Successful visions are built around
what a business wants to do for their customers. Mission statements are the public face of
a business, and present the vision in simple, easy-to-understand, language. more
• Focus. Then, you need to put in place processes and procedures to help you focus on how
to deliver on that vision. The initial goal isn’t to build software, but rather, to discover needs
and wants that people will pay you to satisfy. Agile developers have conversations with
markets and user communities they are focusing on. They use new iterations to advance
the discussion by encouraging feedback. Users will respond with, “I love A, Hate B, and How
in the world did you miss C?” They review and evaluate the collected data, release another
iteration and ask, “Does this better fit your needs?” And so the conversation goes, week
after week, iteration after iteration. more
• Risks. Be sure to identify your biggest risks and address those in the early stages of
planning. We typically think of our biggest risks being competitors, customers, disruptive
technology, staff and team members. But, scope creep and erroneous project estimating
are also potential company killers. Processes, procedures and strategies to address all
these critical pieces of your business are essential to success. Agile processes like Extreme
Programming (XP) and Scrum accept that requirements will change and create
opportunities for improvement and competitive advantage. more
• Value. You want to always have in mind what your unique value proposition is, and that
every effort is being made to consistently deliver that value in every instance. Also, keep in
mind that your customer and the end-user of your product or service may not be the same.
This is true for most apps on the market today. Differentiating between what your customer
and the end-user perceive as value can help you communicate your value proposition more
effectively. Dave McClure’s “Pirate Metrics” is a great tool for capturing the data that will
help guide you. Leanstack’s Lean Canvas is a tool to help you build a one page business
plan, including identifying your unique value proposition. more
• Sequence. Working on things in the correct order helps ensure that you are proving your
value to the customer at every stage. The traditional process for product management
sequence looks something like this:

LEAN VS AGILE 9
 • Sequence. Working on things in the correct order helps ensure that you are proving your
value to the customer at every stage. The traditional process for product management
sequence looks something like this:
1. Detailed Planning
2. Detailed Analysis
3. Design
4. Development
5. Testing
6. Release
7. Maintenance

The Agile sequence differs in methodology and practicality:

1. High Level Planning
2. High Level Analysis
3. Plan
4. Iterate
5. Release
6. Repeat steps 3, 4, & 5

High level High level analysis

Planning (Product Backlog) Iteration 1 Iteration 2, etc ...

Plan Iterate Release Plan Iterate Release

Test Analyse Test Analyse Test Analyse Test Analyse

Feature 1 Feature 2 Feature 1 Feature 2

Develop Design Develop Design Develop Design Develop Design

Test Analyse Test Analyse

Feature 3 Feature 3

Develop Design Develop Design

There aren’t any really distinctive stages during the development. Instead, each feature is
taken from start to finish within an iteration, with the software usually being released at the
end of each iteration. An iteration is simply a fixed, short period of time that the team
chooses to work within. Typically for agile teams, an iteration is between one and two
weeks.
• Flexibility. Ensure that you’re really employing those agile principles, like starting small and
testing early, so you can learn along the way and grow your startup into the Next Big Thing.
You may want to test several small markets to discover an opportunity to dominate a very
small market where you can go deep, really understand the problem, and how to reach
those customers. Work with early adopters in each test market to learn what works and
what doesn’t. Once you’ve been able to dominate that small market, you can build upon
that success to become a market leader.

Can Lean Startup and Agile Methodology Work Together?

“In today’s dynamic business world, we transform our project planning focus from an expanding
control change process to an adaptive process that embraces change: a process that responds to
business requests whenever they are made, a process that is flexible enough to change even the
process itself. That process entails practicing Lean Startup with the Agile Methodology, Satish
Kodukula.”

LEAN VS AGILE 10
David Hawkes, of Agile Velocity in Austin TX, sees Lean and Agile as individual, enjoined, loops:
“As it applies to software development I see two main cycles that should be working in
conjunction (imagine two loops with overlap). The first loop is Lean Product Discovery and the
second is Agile Execution.”
“For years Agile and Scrum,” he continued, “have focused on optimizing the Agile Execution
loop. We have shortened delivery time, increased productivity and become more predictable.
We have learned how to build the product the right way.”
“SaaS/ Cloud environments has allowed us to run quicker experiments on our ideas of what to
build, leading to new techniques like Lean Startup and User Story Mapping in the last few years.
These new techniques allow us to quickly determine if we are even building the right product.
I call this the Lean Product Discovery loop,” he concluded.
Ash Maurya, of LeanStack, and author of Running Lean, describes the synergy of Lean and Agile
this way: “Lean is the agile mindset applied for business where the business model, not just the
solution, is the product. While agile focuses on build velocity, lean focuses on customer traction
velocity.”

Deep Woods Analogy

Imagine being deep in unfamiliar woods. The dense trees loom high overhead, and you can only
see a few yards away. You’re going to have to walk out to find safe haven. But, which way to go?
You don’t have a compass, and you never really paid much attention to moss growing on trees,
or that the afternoon sun shines in the West. Or, is it East? Which wild berries can you eat safely?
The tendency is to just start walking and figure it out along the way. But, that can be really
dangerous. Most folks in that situation make a big circle and wind up right where they started.
That’s why the compass is so important. It can keep you headed in the direction you determine
to take. But, it’s one thing to be able to navigate, but another to know where to go. Which
direction to take? What’s your goal? Before you start out you need to have a good sense of
where you should be headed. So, you study everything you can use to help you; the sun, a knife,
map, walking stick, etc. Only after analyzing all the resources available to you would you start
your journey.
This example is analogous to the Lean development process; minimizing wasted time or
resources, studying data and making well informed decisions to maximize your chances of
success. It is important to be aware of your surroundings at all times so you can understand the
terrain, which changes with every step you take, to avoid or control obstacles, accelerating or
slowing as needed to reach the goal safely.
If you think of navigating with the compass as a skill that you’ve honed into an effective process,
and correct adjustment of your speed to adapt to the ever-changing situation as another
process, you can see how these information producing systems feed information to each other.
The same is true of Lean and Agile methods working together. Each is a separate system, doing
what it does well, but, together they make a whole new, more effective, method that establishes
the direction, navigates through obstacles, slowing and speeding up as needed, while always
keeping the goal in sight.

LEAN VS AGILE 11
 Taking the discussion of Lean and Agile to the next level,
our founder, Lance Vaughn, was featured in a series of

cu
ED
podcasts exploring the aspect of software ruggedness.

sto
nig

LE deve
m
es
When most folks think of “ruggedness” they visualize
GG

er
d

ANlopm
re
military or law enforcement gear built to operate in all
RU
a
ftw

types of conditions. Software has to be rugged, too.

so

en
Learn more about Rugged on these links:

t
AGILE Rugged Software
project management

Rugged Manifesto
Society of Rugged Developers podcasts

Other Resources for Lean:

The Lean Startup by Eric Ries
The Lean Startup.com
Leanstack (Running Lean and Lean Canvas) by Ash
Maurya

Other CabForward blog posts on Lean topics:

Lean Software
Seven Principles of Lean Software Development
Product Development Special Projects
Continuous Integration
8 Steps to a Lean Canvas Business Plan
Unique Value Proposition
Minimum Viable Product

Additional Information on Agile Methods:

Agile For Dummies - Learn the Fundamentals of Agile
- (IBM e-Book)
Fixed Mindset vs Agile Mindset

Other CabForward blog posts on Agile topics:

Agile Development
Agile Based Applications
The Power of Lean and Agile Combined

LEAN VS AGILE 12
 SCRUM
How It Improved Agile

Scrum is part of the Agile movement, and was originally defined as "a flexible, holistic product
development strategy where a development team works as a collaborative unit to reach a
common goal. It is typically described as an Agile method to manage software development
with teams. The key focus of scrum is to be a flexible, iterative, incremental, and adaptive agile
software development framework as opposed to the traditional, sequential approach
(Waterfall).
A primary principle of scrum is its recognition that customers will change their minds about
what they want and need, and that those changes cannot be predicted. As such, scrum accepts
that the changes cannot be fully understood or defined, and focuses instead on maximizing the
team's ability to deliver quickly while adapting to evolving technologies and changes in market
conditions.
The main distinctive features of Scrum are agility and continuous progress provided by
continuous communication and close cooperation between the stakeholders at each step.
Scrum enables teams to self-organize by current product requirements, and fosters daily
face-to-face communication among all team members and disciplines in the project.
There are three core roles in the scrum framework that represent the scrum team.
Product Owner - the person that represents the stakeholders and is the voice of the
customer, who is accountable for ensuring that the team delivers value to the business.
Communication is a main function of the product owner. The ability to convey priorities and
empathize with team members and stakeholders is vital to steer the project in the right
direction. The following are some of the communication tasks of the product owner to the
stakeholders:
• negotiates priorities, scope, funding, and schedule;
• educates stakeholders in the development process;
• ensures that the product backlog is visible, transparent, and clear;
• organizes milestone reviews;
• defines and announces releases;
• communicates team status;
• demonstrates the product to key stakeholders who were not present at a sprint review;
A product owner’s ability to communicate effectively requires skills in techniques that
identify stakeholder needs, negotiate priorities between stakeholder interests, and
collaborate with developers to ensure effective management of requirements.
Development team
The development team is made up of individuals who do the actual coding work, and are
responsible for delivering incremental iterations of the product at the end of each
development sprint. Development teams are cross-functional, with all of the skills as a team
necessary to create a product increment. The team is made of specialists who analyse,
design, develop, test, document, and deploy to production each iteration of the product. In
scrum, the development team is self-organizing, with a minimal level of interface with upper
management.

LEAN VS AGILE 13
 Scrum Master
Scrum is facilitated by a scrum master, who is accountable for removing impediments to
progress. The scrum master is not a traditional team lead or project manager, but acts as a
buffer between the team and any distracting influences. The scrum master ensures that the
team follows the agreed upon scrum processes, facilitates daily scrum meetings, and
encourages the team to continually look for ways to improve.
The scrum master role differs from a traditional project manager in that the project
manager usually has people management responsibilities and the scrum master does not.
Scrum does not formally recognize the role of project manager, as traditional command
and control practices would cause difficulties in the team being able to self-organize. That
would likely negate the effectiveness of the scrum approach.
The core responsibilities of a scrum master include:
• Maintain the product backlog to insure that needed work is clearly understood.
• Help the team to define the “definition of done” for the product
• Coach the team on scrum principles, in order to deliver high-quality features
• Know cross-functional skills of team members
• Promote self-organization within the team
• Help the team to avoid or remove impediments to its progress
• Facilitate team events to ensure regular progress
• Educate key stakeholders in the product on scrum principles
The product owner provides or participates in identifying customer-centric requirements,
typically in the form of user stories. These are then ranked, prioritized, and added to the
product backlog. There can be only one product owner, and that role should not be combined
with that of the scrum master. The product owner should be on the business side of the project,
and should never interfere or interact with team members on the technical aspects of the
development task. This role is termed the “customer representative” role in some other agile
frameworks.
The Scrum Process
A sprint (or iteration) is the basic unit of development in scrum. The sprint is a timeboxed effort;
that is, it is restricted to a specific length of time. The duration is established in advance for each
sprint and is usually between one week and one month, with two weeks being the most
common.
Each sprint begins with a sprint planning event that attempts to define a list of requirements
that can be completed within a sprint. The sprints then can be prioritized and placed on a list in
order of completion, called a sprint backlog. Each sprint ends with a sprint review that examines
progress to show to stakeholders and identify lessons and improvements for the following
sprints.
Scrum emphasizes working product at the end
24h of each sprint that is really done. Definition of
done is crucial to a highly functioning Scrum
30
days
team. In the case of software, this likely
includes that the software has been integrated,
fully tested, end-user documented, and is
Product Sprint
Sprint
Working increment potentially shippable or ready for deployment
Backlog Backlog of the software
to production.

LEAN VS AGILE 14
Prioritized Story Map
A prioritized backlog of requirements helps the team understand what to do next, but
sometimes it's difficult to grasp what comes next. A prioritized user story map provides a high
level overview of the entire project, and is very helpful for large projects.

Functionality 01 Functionality 02 Functionality 03 Functionality 04 Functionality 05

User User User User User User

Story Story Story Story Story Story
Sprint 14
User User User
Story Story Story

User User User User User User User User

Story Story Story Story Story Story Story Story
Sprint 15
User User
Story Story

User User User User User User User

Story Story Story Story Story Story Story
Sprint 16
User User
Story Story

User User User User User User User User User User
Story Story Story Story Story Story Story Story Story Story
Backlog
User User User User User User User
Story Story Story Story Story Story Story

User User User

Story Story Story

User User
Story Story

Daily Scrum Meetings

Each day during a sprint, the team holds a daily scrum (or stand-up meeting) in a centralized
location or, for virtual teams, a collaborative video conferencing tool. Each stand up is
conducted with specific guidelines:
• The daily scrum happens at the same time and place every day
• starts precisely on time even if some development team members are missing
• is limited (timeboxed) to fifteen minutes
• Members of the development team come prepared
• Anyone is welcome, though normally only scrum team roles contribute
• During the daily scrum, each team-member answers three questions:
• What did I do yesterday that helped the development team meet the sprint goal?
• What will I do today to help the development team meet the sprint goal?
• Do I see any blockers that prevent me or the development team from meeting the
sprint goal?
Any impediment (stumbling block, blocker, risk or issue) identified in the daily scrum should be
captured by the scrum master and added to the team's scrum board, with an agreed person
designated to working toward a resolution, outside of the daily scrum. No detailed discussions
are allowed during the daily scrum.

LEAN VS AGILE 15
 Sample Burndown Chart
250 25

200 20

Remaining and completed tasks

Remaining effort (hours)

150 15
Completed tasks
Remaining effort
100 10 Ideal burndown
Remaining tasks

50 5

0 0
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21
Day
A sample burn down chart for a completed iteration, showing remaining effort

The sprint burndown chart lists the remaining work in the sprint backlog. Updated each day, it
gives each team member a current view of the sprint’s progress. During sprint planning the
ideal burndown chart is plotted. During the sprint, each member picks up tasks from the sprint
backlog and works on them. At the end of the day, the chart is updated and the remaining hours
for tasks to be completed are adjusted.

How To Implement Scrum in 5 Easy Steps

Step 1. Product Backlog Creation - a list of features (User Stories) ordered by priority.
Step 2. Sprint Planning and Sprint Backlog Creation - The product owner determines priorities,
while the scrum team defines the effort required.
Step 3. Working on the Sprint - The development process
Step 4. Testing and Product Demonstration - A review and demonstration of the results of the
sprint.
Step 5. Retrospective and Next Sprint Planning - How to improve the development process on
the next sprint.

Additional Information on Scrum:

Scrum - Wikipedia, the free encyclopedia
What Is Scrum? - The Scrum Alliance
The Scrum Guide - Scrum.org
Scrum Reference Card by Michael James
Scrum Methodology by Michael James

CabForward blog posts on Scrum Related Topics:

CabForward Project Management
Why Your App Needs A Digital Product Agency
7 Reasons Digital Apps Go Over Budget
Three Steps to Being Digitally Reborn

LEAN VS AGILE 16
 Scrum-But (Fractional Scrum)
Scrum-But (or Scrum but) is a term to describe the approach of a team who has modified the
scrum process to adapt to their unique needs. Generally, the reason Scrum experts object to
Scrum-buts is that they almost always hide an impediment which, if addressed and removed,
would improve things.
Scrum.org says, “ScrumButs are reasons why teams can’t take full advantage of Scrum to solve
their problems and realize the full benefits of product development using Scrum. Every Scrum
role, rule, and timebox is designed to provide the desired benefits and address predictable
recurring problems. ScrumButs mean that Scrum has exposed a dysfunction that is
contributing to the problem, but is too hard to fix. A ScrumBut retains the problem while
modifying Scrum to make it invisible so that the dysfunction is no longer a thorn in the side of
the team.”
A Scrum-But has a defined syntax: (Scrum-But)+(Reason)+(Workaround)
Examples:
"(We use Scrum, but) (having a Daily Scrum every day is too much overhead,) (so we only have
one per week.)"
"(We use Scrum, but) (Retrospectives are a waste of time,) (so we don't do them.)"
"(We use Scrum, but) (we can't build a piece of functionality in a month,) (so our Sprints are 6
weeks long.)"
Sometimes organizations make short term changes to Scrum to give them time to correct
deficiencies. For example, "done" may not initially include regression and performance testing
because it will take several months to develop automated testing. For these months,
transparency is compromised, but restored as quickly as possible.
Adaptations
Modification of the scrum methodology is very common, as scrum does not cover the whole
product development lifecycle. Therefore, organizations often find the need to adapt the
process to create a more encompassing implementation. Agencies commonly add processes
for requirements gathering and prioritization at the start of the project, along with high-level
design, and budget and schedule forecasting.
While the official Scrum Guide lists the essential elements of Scrum, many organizations deviate
significantly from it. There is usually little variance from the heart of Scrum: Sprints, Sprint
length, events, team size and requirements engineering, but great variation in the roles, effort
estimation and quality assurance.
According to Jeff Sutherland, inventor and co-creator of Scrum, “Scrum is fractal by nature and
scales to any size.” However, when Scrum moves to the enterprise level, the entire company is
affected, and many modifications to current business practices may be necessary. This often
leads to widely diverse applications of the scrum process, sometimes requiring organizations to
“plug it in” in the middle of existing processes. Hence the common term, Scrum, but...
Additional Resources: Other CabForward blog posts on Agile topics:
Scrum Methodology Agile Development
Agile Based Applications
The Power of Lean and Agile Combined

LEAN VS AGILE 117

 Kanban
Kanban originated as a just-in-time method of inventory control developed in Japanese
automobile factories. It has been adapted somewhat to become a process, or a framework, to
improve your current process by helping you visualize workflow, limiting work-in-progress and
managing the flow of work. It helps you start with what you have and gradually evolve by
making changes to your processes that improve your workflow, throughput, and the final
product quality.
Kanban can be defined as a project management process used to organize work for the sake of
efficiency. This is achieved by encouraging work to be broken down into manageable chunks,
limiting the amount of work allowed in any one condition, such as, “Unstarted,” “Design,” or
“Ongoing.” Only a certain number of tasks can be ongoing at any time and only so many can be
on the to-do list.
Kanban, literally “signboard,” or “billboard,” in Japanese, originally was an inventory-control
system for lean manufacturing and just-in-time manufacturing designed to better control the
supply chain.
In the late 1940s, Toyota started studying supermarkets, and applying shelf-stocking
techniques to the factory floor. In a supermarket, customers generally retrieve only what they
need at the required time; no more, no less. Consequently, the supermarket stocks only what it
expects to sell in a given time. Customers take only what they need, because future supply is
assured.
A kanban board is one of the tools used to visualize the kanban method for a project.
Kanban boards are perceived as a variation on traditional kanban cards in manufacturing.
Instead of the signal cards that represent demand or capacity, the board utilizes magnets,
plastic chips, colored washers or sticky notes to represent work items. Each of these objects
represents an item in a production process as it moves around the board. Its movement
corresponds with a manufacturing process.
At its simplest, the board is usually divided into three sections: "awaiting production", "work in
progress" and "completed work". Complex Kanban boards can be created that visualise the
flow of work across a value stream map. Employees move cards to the section on the board
that coincides with the status it represents.

A Simple Kanban Board

To Do Doing Done Adapted to software development, Kanban

became a method for managing knowledge work
USE LEARN GET SOME with an emphasis on just-in-time delivery. This
KANBAN STICKY
ABOUT approach presents all participants with a full view
KANBAN NOTES!
of the work process from task definition to
TRY GET A
KANBAN WHITE delivery. Team members pull work from a queue
TOOL -
BOAR
D that shows what to produce, when to produce it,
and how much to produce.

The Kanban Method is rooted in four basic principles:

• Start with the existing process - The Kanban method does not prescribe a specific set of
roles or process steps. The Kanban method starts with existing roles and processes and
stimulates continuous, incremental and evolutionary changes to the system. The Kanban
method is a change management method.
LEAN VS AGILE 118
 • Agree to pursue incremental, evolutionary change - The organization (or team) must agree
that continuous, incremental and evolutionary change is the way to make system
improvements and make them stick. Sweeping changes may seem more effective but have
a higher failure rate due to resistance and fear in the organization. The Kanban method
encourages continuous small incremental and evolutionary changes to the current system.
• Respect the current process, roles, responsibilities and titles - It is likely that the
organization currently has some elements that work acceptably and are worth preserving.
The Kanban method seeks to drive out fear in order to facilitate future change. It attempts
to eliminate initial fears by agreeing to respect current roles, responsibilities and job titles
with the goal of gaining broader support.
• Leadership at all levels - Acts of leadership at all levels in the organization, from individual
contributors to senior management, are encouraged.

Sample KANBAN Software Development Workflow Chart

Other Resources for Kanban:

Kanban – Successful Evolutionary Change for your Technology Business by David Anderson
Kanban Primer (Slide Presentation) by Julia Wester
Wikipedia, the free encyclopedia

LEAN VS AGILE 19
 Scrumban

Scrumban is a software production model based on Scrum plus Kanban. Scrumban is especially
suited for maintenance projects or whole-system projects with frequent and unexpected work
items or programming errors. The time-limited sprints of the scrum model don’t fit very well in
this setting, but scrum's daily events, burndown charts, and other practices may fit. Practices
for visualizing the work at hand and limitations for unfinished work (defects) come from the
Kanban model.
Savita Pahuja writes for Kanban Tool, “A combination of the two great Lean approaches may
lead to an ideal one. Scrumban combines Scrum and Kanban, and contains the best rules and
practices of both methods. On one hand, it uses the sanctioned nature of Scrum to be Agile, on
the other it encourages teams to constantly improve their processes” (to achieve continuous
improvement.)
Scrumban was originally designed as a way to transition from Scrum to Kanban. Today,
Scrumban is a management framework that emerges when teams use Scrum as their chosen
way of working and use the Kanban Method as a lens through which to view, understand and
continuously improve how they work.
The major differences between Scrum and Kanban are derived from the fact that, in scrum,
work is divided into sprints that last a certain amount of time, whereas in Kanban the workflow
is continuous as seen in work stage tables, which in scrum are emptied after each sprint. In
Kanban all tasks are marked on the same table. Scrum focuses on teams with cross functional
know-how, whereas Kanban utilizes specialized, functional teams.

Major Differences Between Scrum and Kanban

SCRUM KANBAN

• Work is divided into sprints
• Focuses on cross functional know-how
• Organizes work for fast delivery of product
• Uses a Scrum Board
• Limits amount of time allowed for tasks
• Heavy emphasis on schedule
• Iterative delivery process
• Roles: Product Owner, Scrummaster
and Team Members
• Work is divided into work stage tables
• Utilizes specialized, functional teams
• Organizes work for the sake of efficiency
• Uses a Kanban Board
• Limits the amount of work in each stage
• Limitations on amount of work in each stage
• No required time boxes or iterations
• Roles: Project manager or supervisor,
teams(s) of development specialists

LEAN VS AGILE 120

 Waterfall+Agile Hybrid Method

Agile, Kanban and Scrum, and all their derivations, are attempts to better shape the lean
manufacturing process to fit the software development world. Agile/Scrum and Waterfall
appear to be methods with really different fundamentals, as we have demonstrated, but they
are able to be complementary for complex web-application development. Waterfall works well
in an environment with lots of predictable routine processes like those routines performed on
servers, while the Agile approach provides software teams with the necessary flexibility and
transparency to adapt to changing requirements faster.

Agile Advantages Agile Disadvantage When to Use

• Allows changes after initial • With a less successful project • When rapid production is
planning manager, the project can more important than the
become a series of code quality of the product
sprints; late and over budget.

• Easy to add features that will • Final product can be grossly • When customers are able to
keep you up to date different than what was change the scope of the
initially intended project

• Allows customers to add their • When it isn’t clear what the

feedback at end of sprints final product should look like

• Bugs are caught in the • When you have skilled

development cycle developers who are adaptable
and able to think
independently

• More likely to reach its launch • When the product is for a

date market with rapidly changing
standards

Waterfall Advantages Waterfall Disadvantage When to Use

• Stresses meticulous record • Developers can’t go back to a • When there is a clear picture
keeping to help improve the previous stage and make of the final product
existing program in the future changes

• The customer knows what to • If requirements are faulty in • When definition is key to
expect; size, cost, and timeline any manner, the project is success, not speed
for the project. doomed to start all over

• The customer has a definite • The whole product is only bug • When customers won’t have the
idea of what their program will tested at the end ability to change the scope of
do when delivered the project once it has begun

• If requirements change, the

project will come in late and
over budget

LEAN VS AGILE 121

The combined Waterfall+Agile method, as shown in the chart below, is:
• Feasibility
• Detailed Planning (Requirement Identification)
• Detailed Design
• Development
• Test
• Push to Production
• Support

Waterfall + Agile Methods

Feasibility Plan Design Build Test Production Support

Both the Agile and Waterfall methodologies have strengths and weaknesses, as we have shown
above. The key to deciding which is right for you comes down to the requirements of the
project. Is it likely to be changing rapidly? If so, Agile may be your best bet. Do you know exactly
what you need? Good. Then maybe waterfall is the better option. Or better yet? Consider taking
aspects of both methodologies and combining them in order to make the best possible
software development process for your project.

Using Lean Principles for Design Thinking

All of these considerations of the various development methods help us learn to think in a more
agile way about our entire approach to creating better processes that produce better products.
A process called design thinking is finding its way into the heart and core of business practice,
joining lean thinking in the forefront of startup and enterprise operations.

LEAN VS AGILE 22
Examples of Design Thinking
Design thinking is a formal method for practical, creative resolution of problems and creation
of solutions, with the intent of an improved future result. It is a form of solution-focused
thinking that starts with a goal instead of solving a specific problem.
Approaches vary widely based on the potential business use, or type of industry, each of which
may have its own established disciplines. Design thinking and Lean Thinking have parallel
natures because there are many different paths through each of the phases and calls for
considering the given user case from various perspectives, empathizing with users, and
considering the various stakeholder objectives. And, each step is cyclical and ongoing, meaning
that it is very much a process of exploration, and, with each “Aha!” moment, that particular path,
process, or product, may be restarted or redirected.

EMPATHIZE IDEATE

DEFINE PROTOTYPE

TEST

An expanded version of the design thinking process has seven stages:

• Define the problem
• Research options
• Ideate approaches
• Create prototypes
• Choose the best
• Implement
• Learn
Design thinking for digital products is similar to this model, and includes; 1) gathering
information, 2) observing users, 3) defining the problem, 4) ideate, 5) create prototype, 6) test,
7) iterate.

GATHER OBSERVE IDENTIFY IDEATE PROTOTYPE TEST ITERATE

LEAN VS AGILE 23
Lean At the Heart of Design Thinking
Lean thinking is a business methodology that delivers more benefits and value while
eliminating waste by evaluating a given activity and weeding out inefficiency and
unproductivity. The objective of lean thinking is to create a lean process that delivers maximum
value.

SIDE BY SIDE COMPARISON

Design Thinking Lean Thinking

• Method for practical, creative resolution
of problems
• Solution focused thinking
• Starts with a goal instead of solving
a specific problem
• Creates an improved future result
• Method for identifying problems and
their elimination
• Solution focused thinking
• Starts with a goal of eliminating problems
• Sustains benefits at a lower cost,
financially and environmentally

Principles of Lean
Lean.org lists the five-step thought process for guiding the implementation of lean techniques
is easy to remember, but not always easy to achieve:
1. Specify value from the standpoint of the end customer by product family.
2. Identify all the steps in the value stream for each product family, eliminating whenever
possible those steps that do not create value.
3. Make the value-creating steps occur in tight sequence so the product will flow smoothly
toward the customer.
4. As flow is introduced, let customers pull value from the next upstream activity.
5. As value is specified, value streams are identified, wasted steps are removed, and flow and
pull are introduced, begin the process again and continue it until a state of perfection is
reached in which perfect value is created with no waste.

The difference
The best Innovation is between creative
designs are born from the people and
human-centered. clash of ideas. innovative people
is action.

EMPATHIZE IDEATE TEST

DEFINE PROTOTYPE

Framing the
Showing is
problem is the
better than
foundation to the
telling.
design.

LEAN VS AGILE 24
Principles of Design Thinking

1. Understand the needs of the end user

2. Defining the problem is key to effective design
3. Ideate a variety of potential solutions
4. Prototype the best ideas
5. Test the prototype to see if it is the solution

We might conclude from this brief study that Design Thinking is, by nature, Lean Thinking. The
purpose of Design Thinking is to find the most effective and efficient method of delivering the
intended impression to the recipient. That is similar to Lean: find the most effective and
efficient process to deliver the intended product to the customer. In both methods, the
objective is obtained by eliminating unnecessary steps (avoiding waste), making every required
action valuable, producing a good result every time, being always available, while producing
continuous flow to move through a process quickly and efficiently, without delays.

Conclusion
Design has always been about revising traditional practices to continue making things easier for
people to grasp. As new technologies and devices have rapidly evolved, designers have had to
to focus on specific capabilities and shortcomings of each, discover how to made them
cross-platform compatible, while often forcing us to lose sight of the end user’s needs. But, by
utilizing the Lean Thinking, Design Thinking, and evolving production methods, we have
discovered interesting and innovative fields like User Experience Design.
We are now able to employ new ways of thinking, implement new methods (and new
combinations of the same) to become leaner, more agile, improve customer experience while
building startup success rates. We haven’t yet arrived at the perfect answer. There are always
going to be “yeah, buts” when developing products in such a fast paced world. We can’t hope to
have the final solution nailed down when we start a project, when we know someone else is
already working on the next best thing that is going to affect our product in some way.
We are currently seeing the experimental merging of all the above methods and processes in
order to discover best practices. Perhaps in the not too distant future we will see waste and
redundancy eliminated from these processes, and a whole new, streamlined, business model
emerge that lets us do what we love and deliver happiness to our customer. The best we can
hope for is to share our experiences, what we have learned from failure, and what might be the
next steps to achieving a business method that alleviates the angst of trying to best serve our
customer while remaining a profitable business.

“We know unequivocally that the traditional

MBA curriculum for running large companies
does not work in startups. In fact, it’s toxic”
Steve Blank & Bob Dorf: The Startup Owner's Manual:
The Step-by-Step Guide for Building a Great Company

LEAN VS AGILE 25
Next Steps

So, how do you employ these new methods and ways of thinking to increase your chances of a
successful startup? Here is a comprehensive Startup Structuring To Do List from AngelBlog, a
site is devoted to the development of best practices for angel investors and entrepreneurs. Its
goal is to facilitate profitable, fair and enjoyable interactions between angels and
entrepreneurs.

1. Build a startup team (if it’s still just you, repeat step 1).
2. Agree on an idea (the idea is much less important than the team).
3. Agree that you want to start a company together (the next several dozen steps will test this).
4. Start with the end goal – the founders need to agree on the exit strategy now. (I know that’s
not intuitive, but it’s one of the most common flaws.)
5. Agree on intellectual property ownership. (This is essential to get right from day zero and
it’s not as easy as it looks.)
6. Agree on the time and money each of the founders will contribute.
7. Agree on how you will handle personal guarantees, credit cards and other personal
liabilities. (Creates a lot of problems if not done now.)
8. Agree on founder compensation and equity allocation.
9. Agree on vesting. (It’s actually reverse vesting, and if you don’t know the difference please
ask now.)
10. Agree on the capital structure at year three. In other words, project what the capital
structure and share register will look like after three or four financings. (Again not intuitive,
but the important thing is to not to agree on the startup structure, but what the structure
will look like three to five years later.)
11. Think hard about whether steps 6 through 10 are fair and equitable. Try to imagine whether
they will still seem fair and equitable in a year, or three years. If everyone in the founding
team is not absolutely in agreement, stop and try to work it out. If you are not successful, go
to step 12.
12. Ensure the startup team is still in alignment. (Get someone outside the team to do a Phase
1 alignment check. If the alignment is not perfect, consider having the first offsite strategic
planning retreat with a really great facilitator.)
13. Confirm the previous eight steps by signing employment agreements and Protection of
Corporate Interest Agreements.
14. Agree on company Articles. (Change the standard articles so a 51% vote is required to sell
the company. Also be sure you provide for electronic communications for statutory
shareholder requirements. I very nearly lost everything in my first company after ten years
of hard work because I was not paying attention when the Articles were finalized. It's not
fun, but you must read and understand your articles now. The next time you read them it
may be too late.)
15. Select a corporate jurisdiction.
16. Agree on the company officers and directors.
17. Check Phase 2 alignment among the founders.

LEAN VS AGILE 26
18. Find a least one very experienced advisor, mentor and/or coach who can review and
confirm the previous five steps.
19. If alignment is not perfect, it may now be time for the first offsite strategic planning retreat
with an excellent facilitator.
20. Celebrate the success of confirming Phase 2 alignment. (It looks like you really do have the
ingredients of a promising company.)
21. Select the year end to be December 31. (There is a dangerous conspiracy in the accounting
profession where they try and talk entrepreneurs into any other date except the right one.)
22. Incorporate the company - it really can't be finalized before the previous 20 steps.
23. Have the first shareholders meeting and the first Annual General Meeting to elect the
board.
24. Have the first board meeting to ‘hire’ the officers and give them the authority to conduct
business. (I’ve seen companies that got this wrong and ended up having to re-sign every
documents in the company’s history before they could close on a financing.)
25. Agree on the amount of equity for future employees and directors.
26. Set up the equity trusts for future employees and directors. (This has to be done at the
startup, before money goes in to avoid tax problems later.) Using Options is far, far less
desirable now.
27. Create a legal share register (strict legal requirement).
28. Have a board meeting to approve the capital structure and share register - another
essential legal procedure.
29. Create an electronic minute book. (For a number of reasons this really should be a folder
on a hard drive, not a physical binder. (There is a conspiracy in the legal profession to try
and talk you out of doing this electronically.)
30. Create a 12 month budget and three year financial projections. (It can be extremely simple
at this stage; it will be way off, but it’s another essential alignment check.)
31. Check that your projected capital structure still makes sense now that you have thought
more about the numbers - update if necessary - at this stage you still can.
32. Check again that you still have team alignment on the exit strategy.
33. Write a business plan. (Not to raise money, but to check founder alignment. May only need
one page of text, 12 month budget, three year projections and capital structure.)
34. Think carefully about whether there is anything else you need in a founding shareholders
agreement. (There usually isn’t, but now is the time to check, before your money goes into
the company. Get someone outside the founding team to do a check.)
35. Agree on signing authorities for treasury management, checks and other important
documents. (I once lost my entire investment because this wasn’t done right.)
36. Phase 3 alignment check. Get someone external to test the alignment with all of the team
members. In one of my startups we could not quite agree on whether there should be an ‘s’
in the company name (to make it plural). I forced a decision without perfect alignment. It
turned out to be an indication of a very, very serious alignment failure that festered for
years. Be very sensitive to any misalignment at the early stages. Get help if necessary to
reach perfect alignment now. (It will never again be as easy to do.)
37. Schedule an offsite strategic planning retreat to perfect alignment if necessary. (Choose an
excellent, experienced facilitator to maximize chances of success.)

LEAN VS AGILE 27
38. Celebrate Phase 3 alignment. (May not seem important, but it is for psychological reasons.)
39. Open a bank account at a bank with good online access and an interface to pay your taxes
online.
40. Get a simple subscription agreement for the founders' investment.
41. Now the founders can write the checks to contribute their startup capital.
42. Set up your accounting system if you haven't already. (Get someone with lots of gray hair
and tax experience to check your chart of accounts. This can be fixed later, but getting it
right now saves a lot of time at your year end.)
43. Learn about all of the taxes your company will have to pay. Do not rely on your accountant
to make the decisions; they cannot understand your business well enough to do this
entirely themselves. You must understand taxes well enough to ensure you are paying all of
the taxes the company owes and that you are not creating personal liability for your
directors. As your business changes in the early days, recheck your tax assumptions
regularly. In Canada, all startups need corporate tax, payroll tax and GST tax accounts on
Day One. Many will also need PST – this one is most often overlooked.
44. Make sure none of your employees think they can be contractors.
45. Understand the SRED program well enough to capture the information to make your first
claim. I often see startups losing lots of money by missing this. (This is an excellent R&D tax
rebate available in Canada.)
46. Get insurance (that you really need, not what the broker wants to sell you).
47. Get an alarm system before you move the computers into the office. (The stories I could tell
would break your heart.)
48. Start planning your friends and family financing round.
49. Be sure you are complying with all of the securities regulations for a friends and family
financing.
50. Agree on a fair valuation for friends and family. Get an external advisor to check and correct
the capital structure and share register if necessary. (It's still easy to fix this but that window
is closing fast).
51. Celebrate completing all of the absolutely necessary steps in building a successful startup.
52. Start working on the product, marketing, sales, recruiting, strategic relationships, (including
a technology partner) and exit strategy - the fun part.

For more information on any of these topics, call us at 512-693-4142, and visit our blog for
additional insights.

CabForward Blog Post Links

Lean Software:
http://cabforward.com/lean-software/

Unique Value Proposition:

http://cabforward.com/unique-value-proposition/

Agile Based Applications:

http://cabforward.com/unique-value-proposition/

LEAN VS AGILE 28
The Differences: Lean Startup vs Agile Methodology:
http://cabforward.com/the-differences-between-lean-startup-and-agile-methodology/

Seven Principles of Lean Software Development:

http://cabforward.com/lean-software-development/

Minimum Viable Product:

http://cabforward.com/minimum-viable-product/

The Power of Lean and Agile Combined:

http://cabforward.com/the-power-of-agile-and-lean-combined/
by Satish Kodukula

The Lean Process:

http://cabforward.com/lean-process/

Lean Software Development:

http://cabforward.com/lean-software-development_2/

Other CabForward blog posts on related topics:

Reflections on the Waterfall Method of Software Development
Cab Forward View At CabForward
Product Development Special Projects
Continuous Integration
8 Steps to a Lean Canvas Business Plan
Unique Value Proposition
Minimum Viable Product

Other Topics Related to Software Development:

Agile vs Waterfall: Comparing PM Methods, by Jim Bowes
Waterfall - The Process That Wasn’t Meant to Be - by Chris Kessell
History of the Waterfall Model-Wikipedia
List of software development philosophies
Agile software development
Big Design Up Front
Chaos model
DevOps
Entrepreneur's Guide to Customer Development
Iterative and incremental development
Object-oriented analysis and design
Platinum Process Continuum
Rapid application development
Software development process
Spiral model
Structured Systems Analysis and Design Method
System development methodology

LEAN VS AGILE 29
A Deeper Dive for Your Business
If you’re ready to see what lean and agile can do for you, together, contact us at 512-693-4142
to get a FREE consultation for your business development and design needs. No gimmicks. No
commitments. Just a free discussion about how you can achieve your app, site, and domain
goals.

Be A Part of the Discussion:

What are your thoughts, comments or questions? Do you prefer the Agile or Waterfall
methodology? Why? Have you successfully combined the two? Please join the discussion and
contribute to the dialogue as we explore why Lean is different than Agile.

LEAN VS AGILE 30
 LEADERSHIP TEAM

LANCE VAUGHN
Empathetic founder & CEO, Lance has a well-known ability to
use his intuition and intelligence to drive digital
transformation in businesses of all sizes. To know him is to
trust his guidance.

PATRICK MORGAN
Intimate knowledge of customer needs and developer
constraints, plus years as a senior developer, give Patrick
Morgan the perfect fusion of customer empathy and
technology expertise. He will assure your app is high quality
software.

SUSAN MUTHARIA
Working closely with all the functional groups in the agency
and our customers, Susan brings consistency and joy to the
collaboration process. No request will be left unaddressed
under her constant care.

JESSICA CHAPMAN
Bringing functionality and beauty to the product
development process, Jessica collaborates to relate the value
of your application to your users. Let her empathize with
your business, your user and your technology team.

LESLIE BLACK
Over 20 years of experience managing the finances of
businesses give Leslie immense wisdom. She relates to the
most complex financial situations, always striving for fiscal
harmony.