Basic Kanban - Schedschd.ws/hosted_files/agilecampnewyorkmetro2017/b5/Kanban Agile C… · Basic...
-
Upload
hoangthien -
Category
Documents
-
view
229 -
download
6
Transcript of Basic Kanban - Schedschd.ws/hosted_files/agilecampnewyorkmetro2017/b5/Kanban Agile C… · Basic...
@GoAgileCamp
#AgileCamp2017
2017
Basic Kanban
Sachin Grover
Introductory
Agile Coach, Teradata
@Teradata
3
The Fundamental Problem
The Big Requirements Up Front target
~12 to 18 months
The Fundamental Problem with the Traditional Method in Delivering the Highest Business Value
Possible
4
Concept: Deliver the Highest Business Value Possible
Agile development and
deployment ensures that
what is delivered to the
business:
• Is exactly what they need
• And deploys the value sooner and more frequently
5
• Challenges
Teradata Agile Approach
• The Journey
• Kanban
Teradata Agile
Agenda
© 2014 Teradata 5
7
• Challenges
• Teradata Agile Approach
The Journey
• Kanban
Teradata Agile
Agenda
© 2014 Teradata 7
8
Timeline
2013
Agile Start
Culture Bank in
Peru
2015 Q4
DevOps
2016 Q2
Reset on Build
2015
Healthcare
in USA
2014
2nd Retailer in UK
2014
Retailer in UK
2014
Engineering and Build
Concept
2014
Migration Project
In Columbia
2016 Q1
Financial Institution in
Canada
2015
Government Organization in
Australia
2016 Q3
9
We saw the huge need to implement projects that didn’t take long time (18 months or longer) to deliver. Even after 18 months, no business value was delivered. Success metrics were delivering “things” into Production, regardless of usage. If the plan was to deploy in 18 months, and the actual deployment was 24 months; project was deemed successful. In retrospect, the project plan took several months to create, only to find out it was inaccurate. Management created and dictated the plan for teams to follow. Requirements were “locked” after the Requirement phase. Teams had no sense of urgency in the beginning of the project while towards the end they worked long hours and weekends to deploy into Production. It was way too expensive to find out the product delivered at the end was not relevant due to inaccurate requirements gathering. This caused many unknowns and uncertainty in the analytics project and no simple way to remove it.
“Users are often unable to articulate exactly what they need, yet they often seem insistent about what they don’t want … once they see it”
– Lean Enterprise (book)
“definition of insanity”
See a need … fill a need
10
• Started shadowing PS projects
• Investigated Scrum
• Noticed that almost all agile projects used Scrum as the flavor of agile – Scrum was Agile and Agile was Scrum – Scrum for Waterfall – Mini-waterfall sprints
• Agile techniques were followed, but no one was following the key business-focused principles of agile
• Was not end-to-end
• Came up with Engineering-Build concept
• Set out to find a pilot
Late 2012-2013
Our Journey begins
12
“The Good”
• Success story with customer
• Reduced unknowns and uncertainties with Engineering Sprint
• Produced 3 dimensional models, 38 tables, 402 columns, loaded with data, with Microstrategy dashboards.
• Introduced Pattern-Driven Development
• Introduced definition of done and task lists – self-organizing
• Introduced data-driven design
• First release within 6 months, shortening the cycle by 12 months—1/3rd
• Higher Quality
• Close business interaction had raised levels of engagement not seen before
• High-quality results and incremental delivery led to healthy relationship between business and IT
• Developers realized benefits of agile
2013 – Large retailer in UK
© 2014 Teradata
13
“The Bad”
• Surrounding teams not agile like source system team
• Work stacked up for Build teams
• Many standards and best practices not followed in Build sprints
• Release Sprints were not Agile
• Sprint Planning sessions took several days (decomposition process)
• Product was built for Malaysian users, however UK users were defining the requirements
• Hard to implement cultural changes
2013 – Large retailer in UK
© 2014 Teradata
15
“The Good”
• Repeatable Process—we were able to replicate success
• Extended build sprints longer to accommodate
• Split decomposition into 2 pieces to cut down Sprint Planning session
• After initial success, subsequent projects were started
“The Bad”
• Were still seeing some of the same problems with first customer – began looking for ways to solve them.
2014—3rd largest retailer in UK
© 2014 Teradata
16
Description
• Presented our Engineering-Build approach using Scrum
• Loved the concept
• Client had spent 3 years with Accenture defining their SDLC with “15 process gates,” which they couldn’t eliminate.
• They also worked from multiple locations, including offshore.
• They said, “You solve this problem and we’ll be interested.”
• Began to recognize that Scrum supported simple SDLCs – ours were not simple.
Consulting Engagement
2014—Consumer Packaged Goods Company
© 2014 Teradata
17
• Researched Kanban
• Team training on Kanban
• Researched Lean principles
• Evaluated – Scrum focuses on product, Kanban focuses on flow, XP focuses on technical
practices
• Didn’t want to “blend” different flavors of agile (another consulting in USA confirmed this for us – “LeanScrumBan”) – Focused on methods – Didn’t understand the “Why”
• Scum.org VS. Scrum Alliance – Framework VS. Process
• First web-based trainings on TD University
2015 Reset – Fix Recurring Issues
© 2014 Teradata
18
A different approach for Build
• Drives incremental development
• No time-box
• Standardize on work
• No prescriptive roles / process
• Specialized teams – work centers
• Support for large teams
• Continuous improvement
• Offshore-friendly
• Make test part of “cycle”
• Make Build work independently of Engineering work so it doesn’t stack up
Why Kanban?
© 2014 Teradata
19
• Co-located so business knowledge stays in-house
• Co-located for collaboration
• Ownership of delivery
• Self-organizing teams – Empowered to make necessary
decisions
• Feedback loops – Scrum ceremonies are designed
for these such as Daily Stand-ups, Retrospective, Sprint Review etc.
• Product-focused development – Less rigor on Standards and Best-
practices
• Time-boxed iteration – Developers cut corners when they
are time-boxed. This is perfect for Discovery since the focus is on getting the data into the hands of business users as quickly as possible.
• Small teams to enable collaboration
• Cross-functional teams that can do analysis, data modeling, development, visualization, testing etc. – Usually need to create new team
that has all skills
Why Scrum?
Engineering Sprint
21
• Challenges
• Teradata Agile Approach
• The Journey
Kanban
Teradata Agile
Agenda
© 2014 Teradata 21
22
Delivery Services – The Kanban Method
… uses kanban boards to visualize invisible work,
workflow and business risks together with kanban
systems which limit work-in-progress
… faster, more predictable delivery and an adaptive
capability that enables you to respond effectively to
changes from customer demand or your business
environment
Kanban Method delivers…
23
• Visualize Workflow, Work,
and Current Process
• Limit Work-in-Progress
(WIP)
• Manage Flow
• Make Policies Explicit
• Implement Feedback
Loops
• Improve Collaboratively,
Evolve Experimentally
Delivery Services - The Kanban Method
Ready (6) Analyze (3)
Design (5) Implement (2)
Test (3) Delivered Doing Done Doing Done
24
The Kanban Method is not…
A project management method
or
A software development lifecycle
process