@GoAgileCamp

#AgileCamp2017

2017

Basic Kanban

Sachin Grover

Introductory

Agile Coach, Teradata

@Teradata

2

Challenges

• Teradata Agile Approach

• The Journey

• Kanban

Basic Kanban

Agenda

© 2014 Teradata 2

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

6

Teradata Agile for Analytics Framework

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

11 © 2014 Teradata

1st Client engagement (2013) – Largest retailer in UK The initial design

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

14

Simplified Design

2014—3rd largest 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

20

2016 Q1—Bank in Peru

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

25

The Kanban Method

Practices

Visualize Workflow, Work and Current Process (看板)

Limit Work-in-Progress - WIP (かんばん)

Manage Flow

Make Policies Explicit

Implement Feedback Loops

Improve Collaboratively, Evolve Experimentally (using models and the scientific method)