The document discusses challenges with implementing Agile practices at scale within large enterprises. Some key points: - Rework is higher in Agile projects which impacts perceived progress when measured by delivered size. However, Agile allows for earlier delivery of value. - Large enterprises have additional pressures like non-Agile dependencies, approvals from various stakeholders, and contractual obligations that can reduce Agile team autonomy. - Defining and splitting up requirements into user stories or features that multiple teams can work on simultaneously is challenging at scale. Approaches like hybrid WaterScrumFall may be needed. - Showcasing progress, value delivered, and managing expectations is important when non-traditional measures don't align

1. © Mindtree limited 2012
Industrial Agile Case Study:
Structure, Management and Challenges
Scrum Gathering® India Regional 2013 - Pune
Avinash Rao
Mindtree

2. 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”

3. 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

4. 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.

5. 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

6. 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

7. Enterprise IT goal posts
7
“So basically, you are wasting my money in the name of Agile?”
Senior Management

8. 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

9. 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

10. 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 …

11. 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

12. 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

13. 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

14. 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

15. 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

16. 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

17. 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

18. 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

19. 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

20. 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

21. 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

22. 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

23. • 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!

24. A hybrid traditional / Agile approach
• What if the requirement teams released every two weeks?
24

25. 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

26. 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

27. 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

28. Working in the Enterprise eco-system
28
The chaos of the Enterprise Bazaar

29. 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

30. 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

31. And in conclusion …
31

32. 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

33. India | USA | UK | Germany | Sweden | Belgium | France | Switzerland | UAE | Singapore | Australia | Japan | China 33
Questions?
Thank you!