Downloaded 88 times
Uploaded byAlberto Caeiro, CSPO, CSM, PMP
Agile product development and project management with Kanban
The document discusses agile product development, focusing on its principles, methodologies, and tools like kanban and lean practices. It highlights the importance of customer feedback, rapid iteration, and continuous improvement in effectively achieving product-market fit. Additionally, it covers best practices for implementing agile practices and the role of minimum viable products (MVPs) in validating business assumptions.
More Related Content
Similar to Agile product development and project management with Kanban
Agile product development and project management with Kanban
- 1. Kanban, Lean and AgileProduct 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)
- 3. “The only surething is uncertainty”
- 4. Why Agile? • Startup = 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 NOTAgile? • 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
- 8. “Agility is thenew rule”
- 9. What it reallymeans • 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)
- 10. “Excellence in Executionis paramount”
- 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)
- 12.
- 13. What is aMVP • 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
- 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 • 8Types 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
- 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 ImplementingKanban 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)
- 20. Product Development coversa lot of things:
- 21. Product Development • ProductDevelopment (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 • FeatureSet • 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
- 24. Product Development • UserInteractions • 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.
- 26.
- 27. Product Development • VisualDesign • 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 AgileProduct 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…
- 29.
- 30. A/B Testing • Atesting 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
- 31.
- 32. Kanban Board • Mapyou 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
- 33.
- 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 • Timeis 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
- 36. Daily (Stand Up)Meetings
- 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 • Mapyour 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)
- 39. Q & A •Feel free. It’s time now!
- 40. About Me • Whothe 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
- #10 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.
- #12 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
- #13 The first MVP of Dropbox!
- #14 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
- #16 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
- #17 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.
- #19 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.
- #20 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
- #35 New work is pulled, when there is capacity to handle it.
- #36 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
- #38 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