© Mindtree limited 2012

Industrial Agile Case Study:

Structure, Management and Challenges

Scrum Gathering® India Regional 2013 - Pune

Avinash Rao

Mindtree

Agile is becoming mainstream in the enterprise

2

”We’ve run a proof of concept and we are

impressed with the benefits of Agile! We

want to roll it out across our IT shop.”

“We have an efficient IT organisation; we

are looking for ways to increase

effectiveness. Agile is a step in that

direction.” “We run large, complex, multi-year IT

programs that will benefit from delivery of

business value at regular, predictable

intervals”

Parsing rationale for enterprise Agile adoption

• “IT shop”

• “Effectiveness as well as efficiency”

• “Regular, predictable intervals”

3

Large enterprise CTOs have long managed IT for efficiency; Agile seems to offer

an opportunity to increase effectiveness

However the pressures that Agile faces in large enterprise programs are different

from the incentives and measurements of smaller development projects

So what is this ‘Industrial’ Agile?

• Multi-year New Product Development

• Product Size > 10,000 FPs (Mk II)

• Team > 200 people in more than a dozen scrum teams offshore all

delivering a single product

4

This session shares the key experiences and learning from an Industrial Agile

program. The focus is on scaling Agile for large programs in the enterprise.

Session Takeaways

• Enterprise Agile looks different from traditional Agile in several ways

• The pressures of size in Enterprise Agile, and the centralized planning and

trade-offs needed for coordination across the enterprise

• Do some cherished Agile ideals break down with size?

• Also, given the pressures in many organizations around cost and

schedule, is Agile the right choice for Enterprise IT?

5

Agenda

• Enterprise IT goal posts

• Managing completion

• Contracting

• Rework

• Feeding the beast

• Should definition be Agile?

• Big UCs, Hybrids and Agile Definition

• Working in the Enterprise eco-system

6

Enterprise IT goal posts

7

“So basically, you are wasting my money in the name of Agile?”

Senior Management

In the name of Agile …

• Managing Completion

• Wasting Money – how much re-work is acceptable?

• Distinguishing between Business and SMEs

• Contracting

• Continuous improvement

• Impact of rework to product completion

• 20% productivity penalty due to overheads and integration when re-

working

• More than 50% of the rework was imposed from outside the Agile

project

• Are Agile teams self-managing at this scale?

8

Traditional v/s Agile view of funding

9

Phase 1 complete

CRs on Phase 1

Acceptance

Project completion Benefit realization

Project size: 100 FPs

Measured by size (often the basis for funding), Agile projects show a

slower rate of progress because of rework – this rework would have

been funded by CRs on traditional projects

If only the requirements were perfect the first time ..

10

• The value of Agile isn’t that it is cheaper – it is that value is delivered early

• However, re-work is incurred in Agile to course-correct (feedback from

demos, acceptance); this is seen as a negative from a delivered size

perspective

• This problem is acute with Function Points – a case can quickly be made

that if only the requirements were perfect the first time around, we

wouldn’t be having so much rework …

Business v/s SMEs

• But its Agile! I’m supposed to be able to make changes!

• A legitimate concern is that SMEs deputed as customers to large Agile

projects often focus on polishing functionality where good enough is often

good enough for the business

11

Non-Agile dependencies and interfaces

• Given the multitude of dependencies in enterprise IT, delivering value

requires that the Agile project work with several non-Agile interfaces and

approvers

• Who manages the integration? Who owns an overall product view to take

the project to completion?

• These can quickly impose a planning overhead to the Agile project

12

Now bring in contracting considerations

• Much IT is outsourced, and procurement likes pay for performance

• Payments linked to size delivered are complicated by Agile – what is

acceptable rework? Is there a vendor obligation to reduce re-work?

13

Continuous Improvement Targets

• Procurement in IT is used to

continuous improvement and

vendor learning!

• Improvements expected as

familiarity increases with the

process and project domain and

technology variants

• Lets look at a case where a 6%

improvement was expected in

Productivity Quotient (hours/unit

work)

14

80

90

100

1 2 3 4 5 6

PQ

Decreasing PQ Targets

Note on data presented:

• Normalized for output variations in teams, cumulative

output

• Variations presented as a % change

• Absolute numbers are masked

• Rework is client- commissioned re-work, not including

defect fixes or other development overhead

Making sense of rework

• We saw a wide variability in output from individual iterations, plotted

against target PQ

15

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

Investigating the variations

• Factors investigated to explain the variation included:

• Complexity of work across iterations

• Staff movement

• Vacations and holiday patterns

• Defects raised on output

• However, there appeared to be no difference in complexity of work

handled, or in the teams that developed the functionality

• The scrum masters, however, complained that they had more trouble with

iterations that touched code already written

16

Plotting Productivity against Rework

17

• Plotting PQ against Rework started providing clues to the cause of the

variation

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

PQ

Rework

What was this re-work?

• Some items we would see in all Agile projects:

• Change in design

• Others that come in play in large enterprise projects:

• Defect fixes and changes in dependencies

• Other partner changes or defects

• Audits and checks on work performed in the past and submitted for

approval

• More than half of the impact was from outside the ‘Agile Project’

18

The Rework – Productivity link

The nature of Rework induced was a collection of small changes into

functionality developed already

The overheads in an iteration – planning day, testing (unit, regression,

automation), code compliance and deployment is common irrespective of

the amount of functionality developed

Further, at a team level, rework resulted in fragmented idle time that could

not be used; rework teams also waited more for other teams to complete

We found a rework penalty of 20% for teams dealing with externally

induced rework

19

Why the stress on contractual and measurement aspects?

• Traditional methods of reporting progress may weigh against Agile

• We believe that an Agile approach compounds the problem of cross

application integration, if progress is measured in size

• An additional wrinkle is added by defects found mid-iteration on other non-

Agile code leading to spiraling effort without moving the product forward

• Agile projects need to clearly showcase their progress and value delivered

20

Feeding the Beast

21

“Of all the questions that kept me awake at night, the biggest one that gnawed at

me was – how will I keep the teams fed in the next iteration?”

Manager, Requirements

Finding the right approach to definition

• We began with a team of business analysts documenting requirements

using traditional Use Cases

• Given that there were already existing requirements available in areas of

the product (developed pre-Agile), it seemed logical to continue with Use

Cases

• The Use Cases were approved and added to the product backlog for

development

• The Use Cases were large (often multiple iterations by multiple teams)

22

Many enterprises switching over to Agile already have some of

requirements (which are unlikely to be User Stories) and would like

them re-used

• Given the size of each Use Case, review and approval took weeks and

sometimes months due to approvals from Corporate, Architecture or non-

Agile dependencies

23

In smaller projects, it is easier to get stakeholders together and

accelerate decision making.

Large enterprises are unlikely to move all IT functions to Agile at once!

A hybrid traditional / Agile approach

• What if the requirement teams released every two weeks?

24

Finally! Agile Requirements

• We finally moved to a fully Agile mode of working where the business

analysts released functionality every two weeks that was of a size that

could be consumed by a single scrum team.

• This is what we should have done in the first place, right?

25

WaterScrumFall?

Agile definition turned into a nightmare for analysts

• Complex functionality could not be part-delivered easily and, with

dependencies, keeping track of outstanding items to be defined and

tracking their dependencies soon became a full time task that reduced the

productivity of the requirement teams.

• It was extremely difficult to visualize a piece of working product and then

specify it incrementally. On every iteration care had to be taken to ensure

that the piece fitted the bigger picture and that every missing detail was

captured in future definition iterations.

26

End state

• It became imperative to modify the requirement documentation process to

overcome these bottlenecks and the new approach was rolled back.

• Finally, the functionality was divided into various domains and use cases

were authored covering functionalities in a domain across various

iterations.

• Since requirements were gathered for each domain simultaneously, inter-

dependency of functionalities was taken into account during requirement

documentation.

• This had the benefits of being efficient and effective for requirements, but

the overhead of splitting work among multiple scrum teams remained.

27

Working in the Enterprise eco-system

28

The chaos of the Enterprise Bazaar

Success in Enterprise Agile

Meta-Planning

Working with non Agile dependencies:

Scheduling approvals, requirements, deliveries & defect fixes

Showcase: Budgeting and cost control, demonstrating progress

and value

“An Agile Project”

29

Architecture Security & Compliance Non-Agile IT Data centre Partners

An Agile project is just one part of the ecosystem

A few things to keep in mind …

• Company Architecture standards to be followed, approvals needed

• Security and compliance audits, signoff

• External partner dependencies and delays

• How non-Agile dependencies provide releases and patches

• Data centres are not agile!

• Constantly showcase value delivered!

30

And in conclusion …

31

What were the results from our program?

• Delivered a real product that could be demo-ed, deployed and used (with

functional gaps)

• Agile seen as critical to success – with waterfall, the program would likely

have been deemed a failure

• Additional funding provided to extend program

32

India | USA | UK | Germany | Sweden | Belgium | France | Switzerland | UAE | Singapore | Australia | Japan | China 33

Questions?

Thank you!