The game has changed!

@sudiptal

@sudiptal

The Game has changed!

3

@sudiptal

Sudipta Lahiri (Sudi)slahiri@digite.com, lahiri.sudipta@gmail.com

• Senior Vice President, Digité• Agile/Lean practitioner (75%)

• Lean Transformation of our own team• Developed SwiftKanban (www.swiftkanban.com), SwiftALM (

www.digite.com)• Licensed user base of over 500,000

• Agile Coach (25%)• Train and coach teams/organizations in Lean/Agile

• Run the LimitedWIP Societies in India

My Background

@sudiptal

Why this talk?Lean/Agile Adoption has been weak! Mostly, at Team level A few at Program level Almost none at Organization level

@sudiptal

@sudiptal

Just reflect on what we preach today...

“Projects” is a bad term!No(almost) EstimationNo(almost) Planning

No Schedules with associated BudgetsNo Managers but “servant-leaders”

Don’t allocate work... let people pull their work!Multi-tasking is a bad thing!

100% utilization is a bad thing!Testers and Developers will collaborateWe will deliver more, faster with lesser

planning, estimation...!

That’s exactly opposite to what we did all this time!

@sudiptal maguzz.henislie.com

@sudiptal

... in every aspect...

... and its our job to educate why and how!

The game has changed...

@sudiptal

1. The nature of applications

@sudiptal

Then!

@sudiptal

Now!

@sudiptal

Recognize that the fundamental nature of applications have changed

UI and application interaction has become paramount! That’s a discovery process

@sudiptal

2. Planning: The way we plan and track has changed!

@sudiptal

Estimation: Then...

Extremely time consuming (months)

Needed a fair amount of detail

Filled with assumptions...

http://chronologist.com/images/function-points-are-fantasy-points/function-point-estimation-worksheet.png

@sudiptal

Estimation: Now...

(Ultra) Fast

Relative

Gut feel first estimate is generally right!https://styleshare.github.io/images/2015-11-05-estimator/planningpoker.jpg

@sudiptal

Scheduling/Forecasting: Then...

http://www.techrepublic.com/blog/tech-decision-maker/managing-deadlines-in-microsoft-project-2007/

Assumptions at all levels• Team Member Productivity• Work Item Estimates• Resource Skillsets• Dependencies• Project/Resource Calendar

Yet, we give a deterministic end date!

@sudiptal

Scheduling/Forecasting: Then… Critical path planning

Fast tracking or Crashing

Take a day for medium size projects; several days for large size projects Specifically, if your resources are

not always under your direct control

@sudiptal

Product VisionRelease Vision

Short reminder

What do we want to accomplish in this release and

how much is left ?Why is this

important and to whom ?

Scheduling: Now...

@sudiptal

Scheduling/Forecasting: Now… A Kanban system

Henrik Kniberg

Delivered features

Date

When will all of this be

done?

Around week 27-30

@sudiptal

Scheduling/Forecasting: Now… A Scrum system

Worst (28SP*6=168)

Average (33SP*6=198)

Release Backlog

for 6 Sprints

Last Release

FP Velocity

Reference: AgileSparks

@sudiptal

In short, the entire planning and monitoring approach has changed

Estimation, Scheduling, Forecasting

How do you communicate Lean/Agile without bridging this gap?

@sudiptal

2. Requirements – The game has changed!

@sudiptal

These BRDs used to work (mostly)... then!

Our BRDs... then!

@sudiptal

But... written specs are often misunderstood...

@sudiptal

@sudiptal

@sudiptal

We accept that requirements are effective only when given by a conversation...

... between the Developer and the Consumer...

... supported by a common understanding of what is “acceptable”

@sudiptal

Written requirements have failed as the artefact for Requirement definition

Use written requirements as a starting point and define acceptance criteria

The importance of collaboration (not hand-off) between the 2 parties is established!

CR/Scope Change isn’t paramount anymore

@sudiptal

2. Completeness of BRDs

@sudiptal

Then: Acceptance/payment linked to it

We had to complete every line of the signed off the BRD!

@sudiptalHenrik Kniberg

Now: We know that we build the wrong thing, often

Sources:Standish group study reported at XP2002 by Jim Johnson, Chairman

Always7%

Often13%

Some-

times16%Rarely

19%

Never

45%

Features and functions used in a typical system

Half of the stuff we build is

never used!

Comple

xity

Cost

# of features

This graph courtesy of Mary Poppendieck

@sudiptal

Therefore... Backlog Grooming!

@sudiptal

Recognizing “premise” of conversation...

We demo early We break Requirements as per INVEST We Automate We Deliver Continuously to get Early

Feedback

Feedback for change is welcome… It means you are paying attention to what I

am building… and I am building something closer to your need!

@sudiptal

A very different thought process...

We don’t commit to scope... we commit to effort and timeline and keep delivering what makes most sense, demoing and taking feedback, regularly!

@sudiptal

True agility isn’t without: Small, independent

requirements Automation CI and CD

Caution: You will not get “agility” by doing requirement decomposition the traditional way, with dependencies

@sudiptal

2. CUT: the game has changed!

@sudiptal

How can a Developer be trusted to test his own code?Metrics like Defect Density were used as for appraisal

It encouraged Testers to file more defects, often bogusIt encouraged Developers to test less (and file less defects)!

@sudiptal

Then...

Test Coverage was an enigma!Automation was considered expensive…

… because we viewed as a Project

@sudiptal

Now...

If done right, (near) 100% Test Coverage is accomplishedAutomation, done with development, isn’t another “overhead” cost; saves cost significantlyThe tooling supports this!

@sudiptal

The scope, role and responsibility of “Dev” has changed

TDD is the “new” norm

Sell the “guarantee” of test coverage

@sudiptal

3. Testing: A completely different paradigm

@sudiptal

Then…

Testing is Testing team’s responsibility

@sudiptal

Now…

Testing is everyone’s responsibility

@sudiptal

Then…

Dev

TestCode Drop

The long gap increased risk and wastage

45

@sudiptal

Then...

@sudiptal

Now… Buggy software is harder to test,

harder to modify and slows overall productivity

Keep the code clean; fix bugs fast Can’t go home if the build is broke!

47

@sudiptal

Then...

@sudiptal

Now… Tested is part of “DONE” .... It

cannot be “Done” if it isn’t Implemented and Tested

Without Testing, you don’t know if the expectations are met

Classic implementation in Agile EVM

@sudiptal

Testing “psyche” has changed completely! The role is not to test; the role is to deliver a quality service

The “testing” role is more driven by the Dev team (refer the Testing Pyramid)

Therefore, the traditional metrics also do not work

@sudiptal

@sudiptal

The game has “indeed” changed!

From the nature of applications…… to the way projects are planned,

tracked and monitored…… to the way SDLC is executed…… to the way tools have evolved to

deliver CI and CD…… to the way teams have to be

structured and appraised (which we did not cover today)!

@sudiptal

Communicate the “full” picture

Just doing the Ceremonies or putting a Kanban Board is neither Agile nor Lean

The game has “indeed” changed!

@sudiptal

Thank you for your time today... For any questions or

clarifications, reach me at: @sudiptal slahiri@digite.com lahiri.sudipta@gmail.com http://sudi-

thoughts.blogspot.in/

Join Limited WIP Societies @ NCR, Bangalore, Pune, Chennai, Hyderabad

Join us at Lean Kanban India 2016!Bangalore, Sep 9-10