Kanban is a lean methodology for managing workflow. It uses a visual board to display the actual workflow process and limits work-in-progress to improve flow. Workflow is tracked over time using cumulative flow diagrams to identify opportunities to optimize processes by tweaking work-in-progress limits and seek to minimize lead times. While some view Kanban and Scrum as competing methodologies, others see them as complementary approaches that can be combined for effective results.
KANBAN DEVELOPMENT
or get the agilest from agile
Oleh Dovhai, Java developer, ex QA engineer - about Kanban development process and how to use it in your project .
We will learn:
· What Kanban is: origin, principles, practice
· Kanban vs Scrum: compare tools for understanding, not judgment
· There is no ideal tool: experiment, combined and again experiment
WebCamp: Project Management Day: World of Agile: Kanban - Евгений АндрушкоGeeksLab Odessa
World of Agile: Kanban
Евгений Андрушко
Project Manager at Softserve
- Что общего между садом сакуры и тойота?
- Какую методологию выбрать на Вашем проекте?
- Реальная практика примения Kanban SDLC.
- Kanban kick-start.
- Kanban vs Iterative agile.
- Софт для Agile: Lean Kanban vs Jira vs Trello.
KANBAN DEVELOPMENT
or get the agilest from agile
Oleh Dovhai, Java developer, ex QA engineer - about Kanban development process and how to use it in your project .
We will learn:
· What Kanban is: origin, principles, practice
· Kanban vs Scrum: compare tools for understanding, not judgment
· There is no ideal tool: experiment, combined and again experiment
WebCamp: Project Management Day: World of Agile: Kanban - Евгений АндрушкоGeeksLab Odessa
World of Agile: Kanban
Евгений Андрушко
Project Manager at Softserve
- Что общего между садом сакуры и тойота?
- Какую методологию выбрать на Вашем проекте?
- Реальная практика примения Kanban SDLC.
- Kanban kick-start.
- Kanban vs Iterative agile.
- Софт для Agile: Lean Kanban vs Jira vs Trello.
Om met vakgenoten ervaringen uit te wisselen op het vlak van ALM en Scrum organiseert Delta-N vier keer per jaar een Scrum Round Table. Dit zijn interactieve sessies die gericht zijn op het delen van praktijkervaringen. Iedere round table heeft een specifiek thema waarover in een interactieve setting gediscussieerd wordt. De sessies worden begeleid door ervaren ALM Consultants / Scrum Masters. De derde Round Table van 2015 had als thema Scrumban.
Scrumban
Scrum en Kanban zijn beide vormen van agile. Waar Scrum het meest geschikt is voor producten en ontwikkelprojecten, is Kanban is het beste voor de productie ondersteuning. Scrumban combineert de sterke punten van beide methoden. In welke situaties of bij welke projecten is Scrumban geschikt en hoe pas je het succesvol toe in de praktijk.
Introduction Professional Scrum Developer for JavaJoris De Winne
Introduction to the official PSD for Java training from scrum.org. It doesn't cover all topics from the official curriculum, and serves as a intro and teaser to actually follow the official training.
A modern Kanban Board for Software Teams — Part 1 of "How to build the best S...Blossom IO Inc.
Part 1 of the "How to build the best Software Products" Series, brought to you by Blossom.co
A modern Kanban Board: 5 Key Steps for your effective Project Workflow
1. Establish a Workflow
2. Define Stage Policies
3. Visualize Work
4. Define Work-in-Progress (WIP) Limits
5. Continuously Improve
Lean Kanban India 2018 | Leveraging Lean and Kanban to implement Continuous ...LeanKanbanIndia
Session Overview :
How can continuous improvement culture and mindset be "transformed" with Lean and Kanban? What can corporate culture derive from and expand on cultures that still exist in Lean Manufacturing movement that began with TPS (Toyota Product System)? How can we leverage our knowledge of Lean and Kanban to transform organization's fitness for purpose? This is a workshop about a pictorial case study that shows how to apply Lean Manufacturing values, principles & best practices for continuous improvement in today's fast-paced IT landscape.
How to do SCRUM and how are we doing it in practice at Klarna TLV.
Covering the next topics: sprints, retro + demo, standup, pair programming, code quality, MVP, continuous integration, continuous deployment, and more...
Kanban/Scrumban - taking scrum outside its comfort zoneYuval Yeret
Kanban is a way to implement a Lean process, focused on flow, time to
market, and waste removal. Understand the Lean principles behind Kanban, its
relation to Agile/Scrum, and how the two can complement each other into
Scrumban. Understand where Kanban should be considered.
Finding a way to do things more efficiently is important - no matter what business you are in or what kind of projects you do.
I decided to help all the freshmen and share the basic Kanban principles with them.
Good luck!
Scrumban - applying agile and lean practices for daily uncertainty by Vidas V...Vidas Vasiliauskas
In this presentation I have talked about scrumban - a mix of routines and techniques for daily use in dynamic environment. Like in startups, product manufacture, support or similar cases.
#Scrum is very popular these days but #kanban is suitable for better organizational level continuous improvement. We use #scrumban to get the benefits of both the worlds. Its a combination of good practices of scrum with kanban.
If you are interested in Agile software development, Scrum might be the first Agile methodology you have learnt. The problem is it might not fit your work environment. Let’s explore another methodology that stands the test of time. There are many people out there discovered that Lean/Kanban is more suitable for their environment than other methodologies. See, you might be one of those.
Om met vakgenoten ervaringen uit te wisselen op het vlak van ALM en Scrum organiseert Delta-N vier keer per jaar een Scrum Round Table. Dit zijn interactieve sessies die gericht zijn op het delen van praktijkervaringen. Iedere round table heeft een specifiek thema waarover in een interactieve setting gediscussieerd wordt. De sessies worden begeleid door ervaren ALM Consultants / Scrum Masters. De derde Round Table van 2015 had als thema Scrumban.
Scrumban
Scrum en Kanban zijn beide vormen van agile. Waar Scrum het meest geschikt is voor producten en ontwikkelprojecten, is Kanban is het beste voor de productie ondersteuning. Scrumban combineert de sterke punten van beide methoden. In welke situaties of bij welke projecten is Scrumban geschikt en hoe pas je het succesvol toe in de praktijk.
Introduction Professional Scrum Developer for JavaJoris De Winne
Introduction to the official PSD for Java training from scrum.org. It doesn't cover all topics from the official curriculum, and serves as a intro and teaser to actually follow the official training.
A modern Kanban Board for Software Teams — Part 1 of "How to build the best S...Blossom IO Inc.
Part 1 of the "How to build the best Software Products" Series, brought to you by Blossom.co
A modern Kanban Board: 5 Key Steps for your effective Project Workflow
1. Establish a Workflow
2. Define Stage Policies
3. Visualize Work
4. Define Work-in-Progress (WIP) Limits
5. Continuously Improve
Lean Kanban India 2018 | Leveraging Lean and Kanban to implement Continuous ...LeanKanbanIndia
Session Overview :
How can continuous improvement culture and mindset be "transformed" with Lean and Kanban? What can corporate culture derive from and expand on cultures that still exist in Lean Manufacturing movement that began with TPS (Toyota Product System)? How can we leverage our knowledge of Lean and Kanban to transform organization's fitness for purpose? This is a workshop about a pictorial case study that shows how to apply Lean Manufacturing values, principles & best practices for continuous improvement in today's fast-paced IT landscape.
How to do SCRUM and how are we doing it in practice at Klarna TLV.
Covering the next topics: sprints, retro + demo, standup, pair programming, code quality, MVP, continuous integration, continuous deployment, and more...
Kanban/Scrumban - taking scrum outside its comfort zoneYuval Yeret
Kanban is a way to implement a Lean process, focused on flow, time to
market, and waste removal. Understand the Lean principles behind Kanban, its
relation to Agile/Scrum, and how the two can complement each other into
Scrumban. Understand where Kanban should be considered.
Finding a way to do things more efficiently is important - no matter what business you are in or what kind of projects you do.
I decided to help all the freshmen and share the basic Kanban principles with them.
Good luck!
Scrumban - applying agile and lean practices for daily uncertainty by Vidas V...Vidas Vasiliauskas
In this presentation I have talked about scrumban - a mix of routines and techniques for daily use in dynamic environment. Like in startups, product manufacture, support or similar cases.
#Scrum is very popular these days but #kanban is suitable for better organizational level continuous improvement. We use #scrumban to get the benefits of both the worlds. Its a combination of good practices of scrum with kanban.
If you are interested in Agile software development, Scrum might be the first Agile methodology you have learnt. The problem is it might not fit your work environment. Let’s explore another methodology that stands the test of time. There are many people out there discovered that Lean/Kanban is more suitable for their environment than other methodologies. See, you might be one of those.
Scrum and Kanban - Getting the Most from EachMichael Sahota
Scrum is the most popular Agile methodology with Kanban a growing second choice. Learn about the core parts of each one as well as how they differ so that you can find the best fit for your team or organizational context. For example, Scrum is great when you want to shake up the status quo and transform the way you work. Kanban is great when small changes are a better fit for the environment. Learn how they work and how you can use them in your environment.
Session Abstract:
Agile framework is based on iterative development, where requirements and solutions evolve through collaboration between self-organizing cross-functional teams. It’s a set of values and principles that help teams respond to unpredictability through incremental, iterative work cadences and continuous feedback.
Scrum is the most popular methodology under the Agile umbrella. Scrum emphasizes empirical feedback, team self-management, and striving to build shippable product increments within short iterations.
Kanban is another popular flavor of Agile that focuses on visualizing and managing the flow of work, in order to balance demand with available capacity and remove bottlenecks.
Learning Objectives:
> Gain a broad understanding of the Agile framework
> Discover Scrum and Kanban, the two most widely used Agile methodologies, and see how they can be used in construction industry
> Find out how Scrum and Kanban can be combined to have the best of both worlds (Scrumban)
The Agile Drupalist - Methodologies & Techniques for Running Effective Drupal...Adrian Jones
More and more clients are asking for Agile development for their projects, in particular the Scrum methodology, but do they really know what they are getting into? Both Waterfall and Scrum are viable methodologies, but each is best suited to particular situations, clients, and projects - neither can be considered the better methodology in all circumstances.
This presentation discusses the potential advantages of using Agile development for building sites in Drupal, but also the potential road-bumps and pitfalls.
This is a demo presentation prepared for the recruitment of Lecturer in CSE at Green University. In this presentation, an introduction to Software Development Life Cycle is demonstrated in an intuitive way.
4. Agenda:
• History: Agile pragmatism/fundamentalism seesaw
• Misconceptions: What Kanban is – and is NOT!
• Mechanics: How & why it works
• Questions, discussion, sample Kanban boards…
6. Agile Fundamentalism:
"Critics of the first edition have complained that it tries
to force them to program in a certain way... I'm
embarrassed to say that was my intention... in this
edition, I have tried to rephrase my message in a
positive, inclusive way“
-- Kent Beck,
“Extreme Programming Explained” 2nd ed.
7. “Agile” defined by Principles
• Our highest priority is to satisfy the customer through early and continuous delivery
of valuable software.
• Welcome changing requirements, even late in development. Agile processes
harness change for the customer's competitive advantage.
• Deliver working software frequently, from a couple of weeks to a couple of months,
with a preference to the shorter timescale.
• Business people and developers must work together daily throughout the project.
• Build projects around motivated individuals. Give them the environment and
support they need, and trust them to get the job done.
• The most efficient and effective method of conveying information to and within a
development team is face-to-face conversation.
• Working software is the primary measure of progress. Agile processes promote
sustainable development.
• The sponsors, developers, and users should be able to maintain a constant pace
indefinitely.
• Continuous attention to technical excellence and good design enhances agility.
• Simplicity--the art of maximizing the amount of work not done--is essential.
• The best architectures, requirements, and designs emerge from self-organizing
teams.
• At regular intervals, the team reflects on how to become more effective,
then tunes and adjusts its behavior accordingly.
(not specific practices)
10. “Kanban is not a software development cycle
methodology or an approach to project
management. It requires that some process is already
in place so that Kanban can be applied to
incrementally change the underlying process“
-- David Anderson
(originator of Kanban)
Kanban
11. Kanban is Simple!
1. Visual representation of your ACTUAL process
(3 Requirements)
22. Cumulative Flow Diagram:
# Days
# Features
in Each
Column
Development
On Deck
Test
Done!
WIP on day #4 = 9
Lead Time = 6 days
By
tweaking
WIP !
( seek to MINIMIZE )
24. So, why all the hate?
“The surprising thing for me is that many smart Agile
people - people I know to be intelligent insightful
people - seem bugged by Kanban... I'm seeing Agile
people behave as strangely about Kanban as
traditional process folks behaved about Agile. They
seem threatened."
-- Jeff Patton,
(Agile speaker and author)
26. Kanban and Scrum: Making the Most of Both
Definitive Resources:
by Henrik Kniberg & Mathias Skarin
(http://www.infoq.com/minibooks/kanban-scrum-minibook)
Kanban: Successful Evolutionary Change for Your
Technology Business
by David J. Anderson
Kniberg also authored Scrum and XP From The Trenches
*
27. a Confession…
"In theory, there is no difference between theory and
practice. In practice, there is“
-- Yogi Berra
If you remember one thing…
Borrowed analogy -- we’ll come back to what it means later
NOT consultant/selling services
20yr dev. interest in improving process -- Here’s why (sample) !
Lots co. & proj. size/types = IMPORTANT! – diff environs req diff process
(highly-motivated talent at web start up vs. complacent 20/1000 HW ISO)
C, C++/MFC x10, C#/.Net x8, Rails/Linx/Vim
2 startups, several med-large corps
Shrink-wrap SF/TM, Congo, 15yr-old 2.6MLOC ODBC/RPC/MFC + 3K gotos
MCP/CSM – hope no one’s impressed!
Assuming Agile familiarity -- want to get some idea of level…
XP? Scrum? Kanban? -- Frisbee?
Anderson/Kniberg?
CSM?
Actively using form of Agile (team, not solo)?
Found mgmnt/devs eager to adopt, clean/maint/ext code, short stress-free cycles?
Web apps? Mobile? Enterprise Apps? Shrink Wrap?
Cover history of Agile & how Kanban fits in, from diff perspective – prag vs. fund swings
(“How dare you corrupt our methodology!” while entire BASIS of Agile is pragmatism)
LOT’S of misconceptions!
Mike @ S.F. Agile Meetup: 2yr. wait, Kanban unrecognizable – acc. to ORIGINATORS
Misconceptions UNDERSTANDABLE due to the way Kanban works
Describe mechanics and trace through simple demo to see how Kb handles typical events
FireStarter vs. 3hrs = plenty of time for Q’s/discussion/alt. views – however misguided
Important to keep in mind! + difficult for consciencious devs to accept
ex: Jp co. = no code rev/stds, no SCM, step-thru, train to Osaka… but shipped!
Possible, even COMMON to ship software wi. horrible process
+ great team can make ANY process work, while NO process can make up for poor team
Agilist attitude often all-or-nothing, but…
Should be seeking INCREMENTAL improvement – want to HELP dysfunctional co.s BECOME Agile!
( but WHICH process elements to target first for biggest effect? )
(read quote)
We see this again & again: “MUST do X” vs. Popendieck, Shalloway etc. “adapt to YOUR unique situation”
(Flame wars also confusing/disturbing to non-dev. mgr considering Agile adoption)
Kent Beck triggered first widespread AWARENESS of “lightweight” process via XP in 1999
(technically, Scrum predates XP from early 90’s, but no one heard of it)
XP = 13 engineering practices, based on observing practices of effective devs & teams
Small change + test => TDD
Obsession with code quality => refactoring
Value in 2nd pair of eyes/asking Q’s => pair programming
etc.
Strictly ENGINEERING focus
Initial attitude = MUST DO ALL 13 Practices!
Backlash (didn’t fit dev. reality)
Reject pairing (dev. & mgr), assumed skill level (poor coders != good tests), role of PM…
Book: “Extreme Programming Refactored: The Case Against XP” – incl. failure @ Chrysler
Beck’s apology = admission of need to adapt to YOUR situation
In 2001, 17 proponents of “lightweight” methods authored Manifesto + PRINCIPLES
In terms of pragmatist vs. fundamentalist arguments, remember…
ANY process generally consistent with these principles IS AGILE!
(common?) example of co. adopting practices while ignoring PRINCIPLES:
2.6MLOC ODBC/RPC/MFC = client-server HW/DB…
3yr. rewrite wi. corporate devs + new tech.
Suggested “Walking Skeleton”: exercise architecture, 2 leads, good tests, review code…
Mgmnt: estimate “tasks” (unfamiliar tech!), plot in proj plan, sign in blood, randomly assign…
6 mos. Later = indep. “features”, no review, panic meetings on “cuts” + cancel vacations
Unit testing and CI server, but SO WHAT?!
Note principle #12: Should apply to PROCESS itself (not just activities UNDER specific process)
Growing adoption of Scrum with 2001 book on subject (Scrum actually dates from early ‘90s)
Moves agile beyond engineering, to coord. with product management
Usually adopts XP practices – “Should we use XP, or Scrum?” makes no sense!
Simplified Scrum activities (ignoring roles, philosophy etc) to compare wi. Kanban:
(note demands made on marketing “owner” etc.)
Backlog of features in form of User Stories, prioritized by “owner”, and sized (T-shirt or story pts)
Meet wi. owner: desired features in 2 weeks “sprint” vs. portion devs feel can complete
Devs meet separately, to break down stories and take on tasks (self-org.)
Devs meet in daily 15min. “stand up” with 3 questions (owner may observe)
After 2 weeks, meet wi. owner (and anyone else), to demo
Devs meet separately, to review process and make adjustments
Work planned vs. completed = better estimates next round
Rinse & repeat…
CSM instructor frustration (co. “won’t accept”) + separate QA question
Like XP, issues encountered by MANY Scrum teams in practice
AUTHORITY to change process differs in startup vs. corp.
Devs don’t get to DICTATE to external groups!
(ability to request SOME changes is assumed)
Attempts to work around = “Scrum-but” criticism – trying to solve REAL problems!
(ironic, since Scrum today != “original” Scrum)
2wk. sprint and many planning/review elements added later
Specific example: $1B pub co., 20devs/1000, ISO/customer audits, shared QA, FDA/EEC…
Go to marketing dept. (“owners”) and insist…
Submit requests in form of user stories (or acceptance tests)
Meet half day every 2 weeks – you request, we say “no”
Evaluate 2week (partial) features
Go to proj. manager and say “we’ll make decisions” (vs. THEIR manager’s expectations)
QA manager discovers you’ve been suggesting integration of QA
Ask UIX designer to work incrementally, without knowing full set of features to be integrated
Owner response: BUSY meeting wi. Customers, visiting Jp office wi. CEO… avail. via mail etc.
Also developer resistance: “Do I really have to read all of this?”
Also problems wi. defined process itself – failed sprints
Agile consultant’s message = Steve Martin’s “I can make YOU a MILLIONAIRE!”
(read quote)
This is from ORIGINATOR! – Many criticisms/promotions of Kb not even Kanban!
Just like “Scrum vs. XP”, “Kanban versus Scrum” makes no sense!
Kanban is something you ADD to EXISTING process!
(Obviously, if you able to start fresh, will borrow from XP/Scrum)
Kanban first presented publically in 2007
INSPIRED by lean manufacturing -- but very different!
Doors and palace grounds examples = signalling system
Anyone can “stop the line”, focusing everyone’s attn. on resolving issue
Immed. reports of dramatic results – incl. from many experienced Scrum practitioners!
Easier “buy in” (requires few changes, makes few demands)
Leads to gradual adoption of more Agile practices as SIDE EFFECT of tracking “flow”
Kanban is simple/trivial
3 practices you can apply to ANY existing process, incl. textbook Scrum or Waterfall
If you are doing textbook Scrum, ALREADY doing one of practices!
because… (click)
…Scrum board IS a visual representation of your dev. process!
Note we specified “ACTUAL” process
(tendency to show MANDATED process vs. process actually being followed – 5” ISO binder)
Difference between Scrum board vs. Kanban board – watch carefully!
We’ve defined an “arbitrary” limit on work in progress
and that is…
…the SECOND Kanban requirement!
How to decide number to use? Doesn’t matter!
Usually some number LESS than number of devs
Self-correcting, as we will see
Note just one example of change in mindset: silos/pair resistance
Columns do NOT represent “waterfall” – QA may plan tests for item in dev. etc.
( Think of it as things that need to be “checked off” for item to be “done” )
Design?
User Documentation?
Localization?
Security review?
Code review?
Do not have to get columns “correct” right away – adjust as you go
No formal “owner” etc. roles required – remember, just 3 requirements!
(Tech lead could select from backlog during architecture phase etc.)
Add colors, “swim lanes” etc., but beware “creeping complexity” – shouldn’t need user manual!
(8 color codes, misc. attachments, 6 horiz. lanes, 8 cols subdivided, multiple projects… = defeat purpose!)
Loses at-a-glance transparency on “flow” of work items + FAIL TO SPOT PROBLEMS !
Can no longer tell mgr. “Don’t need status reports, just glance at board”
Board lets us instantly (and AUTOMATICALLY) identify inefficiencies
ie: “items moving quickly through dev. but spending long time in Test…”
which brings us to the final (and MOST IMPORTANT) item…
NOT passively “watching” items move across board! Kanban has directed PURPOSE/goal
Seeking to minimize avg. time between item start (“On Deck”) and marking it “Done”
Everyone’s attention should CONTINUALLY be focused ON THIS ONE THING!
(fundamental Agile principle of ensuring sustainable, comfortable pace… still applies.)
Do not ignore this! Teams that fail to adjust high WIP numbers risk long lead times etc.
(focus on eliminating impediments to smooth work item flow turns out to maximize throughput)
Some more specific benefits of focusing on “flow”:
Provides guidance to “owner”: “Currently processing item ea. 6wks. What 2 items do you want in 6wks?”
Provide EVIDENCE to management: “Items getting stuck in Test. Hire more testers?”
This is just SIMPLIFIED example to illustrate “flow”…
Note we don’t show breakdown into tasks
(approaching limits of what you want to be doing wi. PowerPoint animation!)
When system “clogged” everyone’s attention is focused on issue = incentive for permanent fix
(same as “Stop The Line” in lean manufacturing)
Not just tracking “clogs”, but TIME spent in queue!
(With explicit columns, never have to “guess” why things are taking too long)
WIP too low = “clog”, too high = long time spent in queue
(example: 4 devs, WIP of 1, 3 devs not working… items spend long time in “On Deck” queue!)
Not just “waiting” for problems – expected to actively TWEAK process elements and see effect on lead time
so, we need a simple metric…
Commonly track via “Cummulative Flow Diagram”
(may use many additional metrics, incl. Scrum “burn down” charts etc.)
(run demo)
“Narrow” bands = short lead time!
Some teams track Minimum Marketable Features (MMF)
What owner cares about and can “evaluate”
(MMFs of different size/duration, so others prefer story points etc.)
Scrum = how many items can we do in 2 weeks? (“velocity”)
Kanban = how long, on average, does it take to complete an item? (“lead time” or “cycle time”)
There ARE NO RULES on how to play Frisbee with your dog !
Don’t even have to throw Frisbee
(assume Frisbee + dog, adjusting activity consistent with goal of “fun”)
Similarly, Kanban does not prohibit ANYTHING, or mandate anything beyond 3 items!
Expected to continually analyze and ADAPT to your unique project/org. requirements
(visitor to Anderson shocked that ea. team’s board was completely different!)
Many experienced Scrum practitioners HAVE TRIED and love Kanban
Found it resolves common problems with Agile adoption in real world
Many others criticize purely on PHILOSOHICAL grounds!
“It’s waterfall”, “it’s Scrum-but”…
Most upsetting to Scrum “purists” = teams DROPPING estimation & fixed iterations
Scrum teams reported they GRADUALLY determined these practices no longer added value
Teams creating a process from scratch found no need to adopt these practices
(source of misconception that Kanban PROHIBITS estimation/iterations)
If you remove estimation and fixed iterations, aren’t you missing out on proven benefits of Scrum?
Management seems to quickly become happy with accuracy of “lead time” estimates
No “unreasonable” time/effort requirements imposed on external groups
Less ceremony for developers (daily stand up becomes quick focus on impediments)
Development can be continuous, with SEPARATE schedules for release and retrospectives
Releases can occur only when Minimal Marketable Feature is ready
Retrospectives can occur at whatever frequency makes the most sense
etc.
There is debate on value of digital versus physical boards…
Many (Scrum and Kanban) orgs use digital for remote sharing, but still meet around physical
(also contributes to “information radiator” effect)
Recommend reading Kniberg (forward by Anderson)
(Quick read, free, Kanban essence, recognized Scrum authority)
Anderson includes complex OPTIONAL metrics + details = distract from understanding
Debated whether this should have been 1st slide…
My interest in Kanban from recognizing how it could have helped transition to Agile at previous co.
(Push for full-blown Agile rejected, but project shipped “successfully” 3yrs, half features, bad code)
Have not actually been on team working under Kanban!