Presentation made at 21212 workshop, covering agile concepts like lean, kanban, mpv applied to product development and project management in an startup environment.
Agile product development and project management with Kanban
1. Kanban, Lean and
Agile Product
Development
Alberto A. Caeiro Jr, PMP
Partner and CTO
Crihen Internet Ventures & Teckler.Inc.
2. Agenda
• Why Agile
• What is Agile (and what is not)
• What it Means
• Agile in Product Development
• What is Kanban
• Best Practices
• Practice (Dojo Session)
4. Why Agile?
• Start up = Fast Growth, Change and Learning
• It’s very difficult to get market-product fit at first, so you
have to test (change) a lot of things and learn what
sticks
• (very) Rapid Growth is an expected outcome when you
find your Product-Market Fit
• Agile
• It’s a software development approach which helps the
team on focusing in what matters
• One pillar of Agile teams is to “embrace and welcome
change”
5. What is NOT Agile?
• It’s not a “No-Men” land, where everybody does what one wants
• It’s not a misaligned environment.
• It’s not caos or anarchy
6. What is Agile?
• Most of all: it’s a new way of thinking and
working
• Ideal for ever-changing environments like
the ones faced by (tech) start-ups
• Very fast iteration and feedback loops
• Per si, it’s not a methodology, but a new
way of thinking and behaving
• Deliver value to customer since the
beginning
7. The Agile Manifesto
• Welcome Change
• Deliver Working Software
• Business People and Tech
team must work together
• Build the team with the
right people and get them
space and freedom to
work
• Face to face interaction
over
documentation, emails, me
mos
• Maintain a constant pace
• Working software as a
measure of progress
• Simplicity
• Technical Excellence
9. What it really means
• Welcome in changing requirements (change is the only certainty
you can count on)
• Listen to you customer/audience
• Embrace diversity (No distinction among business and tech team)
• Build (and ship) instead of theorize (the real test is the market)
• Simple is much (much) better than complex
• Test a lot of things (always/most of the time, from the business
perspective)
• And keep learning…
• Measure progress against the right things (working software)
11. Agile in Product
Development?
• Listen your customer (Lean)
• Simplicity & Welcome
Change (MVP)
• Value Stream
Mapping/Analysis (Lean)
• Get rid of waste
(unnecessary
docs, unnecessary
meetings, unnecessary
features, etc) (Lean)
• Go to the heart of the matter
(Lean)
• Continuous Delivery and
Maintain a constant pace
(Kanban)
• Pull System (Lean / Kanban)
• Face to Face Meetings
(Kanban)
13. What is a MVP
• MVP = Minimal Viable Product
• Is used to test you business premises/assumptions
• To validate your business model
• To identify you real customer
• To understand what your customer really wants
• In practical terms is the minimum set of features
you should have to validate your assumptions
14.
15. What is Lean
• It comes from the legendary TPS (Toyota
Production System)
• Based on some pillars, the most useful for us:
• Value stream mapping
• Flow Creation
• Waste reduction/elimination
• Root-cause analysis
• Pull System
• Continuous Improvement
16. Lean Toolset
• 8 Types of Waste
• Defects
• Overproduction
• Waiting
• Non Utilized
Resources/talent
• Transportation
• (excess of) Inventory
• (unnecessary) Motion
• Over Processing
• Root-Cause Analysis
• 5 Whys, Ishikawa
Diagram
• “5S” Tools
• Sort, Straighten, Scrub,
Standardize, Sustain
• Heavily Based on
PDCA
• Value Stream Mapping
17.
18. What is Kanban
• It’s a visual signboard process used to
• Reduce/limit the Work in Progress
• Balance demand against throughput
• Create flow and constant pace of delivery
• Identify and remove bottlenecks and problems
• Keep the whole team synchronized and aligned
• Shorten lead times to improve predictability
• It’s a lean tool
• Kanban per si is an agnostic “tool”, can be used both in agile
and in waterfall approaches
19. Recipe for Implementing Kanban
1. Focus on Quality (no Technical Debt)
2. Limit Work-In-Progress (enough of multi-tasking)
3. Deliver Often
4. Balance Demand against Throughput
5. Prioritize
6. Attack Sources of Variability to Improve Predictability
* From David J. Anderson (Kanban: Successful Evolutionary Change For your Technology
Business)
21. Product Development
• Product Development (Technical)
• Feature Set (in the proper order)
• User Interactions and User Experience (UX)
• Wire-frames, Information Architecture
• Visual Design
• Product Development (Non Technical)
• Positioning, Marketing and Advertising
• Communication and PR
• Pricing
• Distribution and Logistics
• Vendors, Partnerships, etc.
22. Product Development
• Feature Set
• Which features should be built
• (most important) In which order
• MVP
• Which are the most fundamental assumptions I need
to test/validate/learn
• What are the most critical features in terms of value
proposition
• How will I measure this learning
23.
24. Product Development
• User Interactions
• How the user will interact with the product you are
designing.
• Which steps are needed to perform the
actions/tasks proposed that add value
• How all components fit together (from a business
perspective)
• Focus on the customer
• It should be done before or alongside the wire
frame.
25. Product Development
• Wire-frames
• It’s like a building’s blue-print
• In practical terms is the “realization” of the User
Experience & Information Architecture
• No concerns about the beauty of visual design
• No colors specs, no animation effects, nothing
blinks
• The main idea is to get a more tangible idea on
HOW the user interaction will take place.
27. Product Development
• Visual Design
• The real look and feel
• Colors, CSS, Images, etc.
• The beauty of the site
• Complements the UX reinforcing the product
positioning (marketing)
28. Best Practices for
Agile Product Development
• Define/Identify Key
Business/Learning Metrics
• Test your business
assumptions through the
MVP
• Use A/B test to gather a
better understanding of
your customer needs and
pains
• Implement some kind of
feedback loop.
• Implement a Visual Control
System
• Use a pull system (or a
Time-Boxed Approach)
• Daily Meetings
• Go back to step 1…
30. A/B Testing
• A testing methodology used to understand
how specific changes can affect user
behavior and thus your bottom-line KPIs
• One (or more) testing group(s) “receives” the
testing
• One (or more) group (control group) receive the
“normal” feature
• Comparing KPIs allow you to identify what
is more effective for each group
32. Kanban Board
• Map you production flow/process
• Identify the capacity of each component
• Limit work in progress for whole system by the
component with the less capacity
• Keep everything in sight (i.e.: visual control is a MUST)
• Dynamically (and ongoing) identify the bottlenecks
• Maintain the flow/pace
• Use a Pull-system approach to handle work
34. Pull System (Kanban
Way)
• No Inventory
• One feature is only schedule to be built upon “customer”
request
• Development is always driven by the market/customer, to
supply a specific demand
• In practical terms:
• Put on your do-to queue only when there is someone willing to pay for it
• Spec only when you are about to code/design
• Code only when you are about to ship
• Ship only when the need is clear
• No “predefined” sprints. The focus is to achieve flow and a constant pace
of delivery.
35. Time-Boxed Approach
• Time is the only fixed constraint
• 1 week, 2 weeks (rarely more than this)
• So you can change (reduce/increase)
• feature-set
• quality standards (not recommended)
• scope coverage
• But you are always delivering/shipping at the
same rate, in a constant pace.
• Increased visibility
37. Daily StandUp Meetings
• Address Problems and Bottlenecks in “Real Time”
• Keep track of progress
• Keep communication channels open
• Keep the team focus
• Clarify/Address concerns
• Allow prompt route adjustments
• Allow for queue replenishments
38. Practical Session
• Map your value stream/workflow
• MVP to prioritize your Backlog
• Kanban to daily execute/control/manage your
development activities
• System Capacity
• 2 iterations - Time-Boxed (2hs for the sessions)
40. About Me
• Who the hell is this guy?
• Responsible for Tech Operations, Architecture and
Project Management as well as tech staffing and
recruiting at Crihen Internet Ventures & Teckler.Inc.
• Former Head of Software Development at Match.com
and WW CTO of Automatos Inc - an Intel Capital
Company, where he led all tech group covering
operations in USA, India, Europe, Australia and South
America. Had worked as Global Project Manager at the
Internet Division of Bowne Global Solutions (bought by
Lionbridge).
Editor's Notes
Very common issues:The Software is not ready yetThere are a lot of bugsIt is still missing feature A, B or CMy competitor will copy/clone my idea.
It’s all about lean principlesListen your customer =>Listen and understand what your customer really wantsTest your assumptions about what the customer wantsTalk to customers to validate your assumptionsKeep an open channel of communication with you customer”Over-communicating” is not a problemSimplicity & Welcome Change =>The key to enable fast change is to keep things as simple as possible.The simple is easier to understand and much easier to changeIf you are feeling that it’s getting complex, believe it, it ALREADY complex. Start it over and get it simpleChange is the only certainty you have when you create a startupThe requirements of today may (most certainly) not be the requirements of tomorrowChanges that adds value to you product are always beneficialValue Stream Mapping/Analysis =>Understand your value stream, i.e. all the steps in your product development workflow, mapping the ones that really add value to the customer and the ones that don’t.Elicit your REAL workflow.Really understand your processes and policies, why they are in place, and how they affect your botton-line.Get rid of waste (unnecessary docs, unnecessary meetings, unnecessary features, etc) => If it doesn’t add value, try as hard as possible to get rid of it.Waste, as the name says, it’s waste. But sometimes (only sometimes) they are necessary Go to the heart of the matterIf you have an issue and you work only the surface of it, it will happen again.If you have the same issues over and over again, you are not fixing the root cause.Continuous Delivery and Maintain a constant pace => The longer you wait to deliver, the longer your product/feature becomes obsolete, and less value the customer gets from it.The longer you wait to deliver : you are loosing a great opportunity to interact to and learn from your customer needs, wishes and dreams.Constant pace of delivery builds up trust and confidencePull System =>Do only what is really necessary, when necessary.Features not used by you customer are a waste (you could have build other ones that they would use and pay of it)(Daily)Face to Face Meetings =>Used to keep on top of things, you need constant project/product communication and collaboration.High performance teams needs trust and good communication to flourishInteracting with one-another is MUCH, MUCH richer then reading a email (you can see emotions, unstated concerns, etc)Builds a sense of collective ownership
The first MVP of Dropbox!
Minimal is REALLY minimal“If you are not embarrassed by the first release of your product, you’ve launched too late” (from Reid Hoffman, founder of Linkedin)If you extend this to new products, projects: MVP is not a milestone you achieve, it is a process you use to get to your product-market fit (or a feature-market fit)Every time you pivot, it’s a new MVPPivoting is not about changing features, but your WHOLE BUSINESS MODELFor product development purposes, you can create different MVPs to test/validate different set of assumptions
Value Stream MappingIt’s all about mapping the added value activities you need in order to produce your product/serviceIt’s normally divided in 3:Value creation activitiesValue destroyer activities (waste)Non-added but necessary activitiesWasteIs everything that destroy valueOr everything that is done but not used (inventory)Code not shippedDesigned not codedSpecs not implementedTools not used (or under-utilized)Problems are common to any organization/processLean treats its problems on a much deeper level through it’s 5 – whysAsk why multiple times to get the heart of the problem (the root cause)It’s also a mindset to go deeper99% of the time, the problem is all about people and theirs derivativesPeople not being trained enoughPeople not using the best toolsPeople not using the best processPeople not fit for the role they need to playMost of the time is a “Management Problem”Pull SystemReduce inventory and limit work-in-progressOn feature is only put to be worked on, after your customer explicit asks for it (and ideally is willing to pay to have it)In some places are known as Just in Time System
WasteDefectOverproduction and Over processing : Producing and Processing more than necessaryWaiting : Time is money.Non Utilized ResourcesTransportationInventoryMotion5 Why’s (asking WHY 5 consecutive times usually help you to reach the REAL issue (the root cause)5SSort (remove what is not needed for the job)Straighten – Set in orderScrub – “cleaning”StandardizeSustain PDCAPlanDoCheckAct PDCA is the basis of the lean approach.
5 core properties to create an emergent set of Lean behaviors for a Kanban System:Visualize WorkflowLimit Work in ProgressMeasure and Manage FlowMake Process Policies ExplicitUse Models to recognize improvement opportunities.
Why Quality: Defects are the one of the worse type of waste in Software. And defects are like compound interest rates. The longer you take to fix them, the worse they became, the longer (in the development lifecycle, the longer you will take to fix it).How to address it: Unit Testing, TDD, Front-end testing, code inspections, code review, architecture meeting reviews, code clarity, code standards, collaborative analysis and design, design patterns, modular and loosely coupled architecturesCan be done both in Waterfall and Agile methodologiesLimit Work in Progress and don’t multithread.Experiences shows the 2-week interactions drives higher quality code than 4-week interactionReducing the working in progress create higher focus on the task at handFacilitate a more loosely-coupled approach both to code and to architecture as a wholeLead (counter-intuitively) to a faster lead-timeDeliver OftenMore frequent releases help on building trust with business people.It shows that the team can deliver and add value on a regular basisHigh quality deliver also build trust with other tech teams link ops, dev-ops, infra, security, etc.Balance demand against throughputThe rate in which you accept new requirements to code have to match the rate in which you can deliver quality code.As code is delivered, more requirements are pulled from the queueThis allows the business people to face the ever changing business challenges with a newer perspective, since they can often reprioritize the work to be doneOnce step 2 and 4 are in place, naturally some slacks will be create. Slack enables the continuous improvementBuild the right thing.Prioritization should not be controlled by Engineering. Business value delivered is the true measure of successVariabilityThe greater the variability the greater the needed slack
New work is pulled, when there is capacity to handle it.
Time-boxed ApproachIt’s a new mind-setIt’s a project planning and monitoring toolIf a task will “leak”, you canReduce the task scopeCrop it, and put it to the next BoxFocus on Working software/prototypeIt’s difficult to adhereYou have to fight against : “It’s only more half-day to finishQuality issues – Remember the mantra of GOOD quality code
Keep Track of progressNot like a “traditional” agile meeting where the 3 default questions are asked.The idea is to focus on flow, and in issues that could impact the pace of the deliveryClarify/Address ConcernsAttack the problems fiercely and heads-on. As soon as possible.Queue ReplenishmentsQueue Replenishments serves the purpose of prioritization. At Kanban, it is said to be deferred or postponed until the last reasonable moment.It’s purpose is to fill the kanban system’s input queue for a single value stream. The audience should be as senior as possibleSenior people can make more decisions and are often aware of a wider contextual information, which improves the quality of the decision