Agile is becoming mainstream in the enterprise
”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
Parsing rationale for enterprise Agile adoption
• “IT shop”
• “Effectiveness as well as efficiency”
• “Regular, predictable intervals”
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
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.
• 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?
• Enterprise IT goal posts
• Managing completion
• Feeding the beast
• Should definition be Agile?
• Big UCs, Hybrids and Agile Definition
• Working in the Enterprise eco-system
Enterprise IT goal posts
“So basically, you are wasting my money in the name of Agile?”
In the name of Agile …
• Managing Completion
• Wasting Money – how much re-work is acceptable?
• Distinguishing between Business and SMEs
• Continuous improvement
• Impact of rework to product completion
• 20% productivity penalty due to overheads and integration when re-
• More than 50% of the rework was imposed from outside the Agile
• Are Agile teams self-managing at this scale?
Traditional v/s Agile view of funding
Phase 1 complete
CRs on Phase 1
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 ..
• 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
• 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
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
• 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
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?
Continuous Improvement Targets
• Procurement in IT is used to
continuous improvement and
• Improvements expected as
familiarity increases with the
process and project domain and
• Lets look at a case where a 6%
improvement was expected in
Productivity Quotient (hours/unit
1 2 3 4 5 6
Decreasing PQ Targets
Note on data presented:
• Normalized for output variations in teams, cumulative
• 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
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
Plotting Productivity against Rework
• Plotting PQ against Rework started providing clues to the cause of the
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
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
• More than half of the impact was from outside the ‘Agile Project’
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
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
Feeding the Beast
“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?”
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
• The Use Cases were approved and added to the product backlog for
• The Use Cases were large (often multiple iterations by multiple teams)
Many enterprises switching over to Agile already have some of
requirements (which are unlikely to be User Stories) and would like
• Given the size of each Use Case, review and approval took weeks and
sometimes months due to approvals from Corporate, Architecture or non-
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?
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?
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.
• 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
• Since requirements were gathered for each domain simultaneously, inter-
dependency of functionalities was taken into account during requirement
• This had the benefits of being efficient and effective for requirements, but
the overhead of splitting work among multiple scrum teams remained.
Working in the Enterprise eco-system
The chaos of the Enterprise Bazaar
Success in Enterprise Agile
Working with non Agile dependencies:
Scheduling approvals, requirements, deliveries &
Showcase: Budgeting and cost
control, demonstrating progress
“An Agile Project”
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!
What were the results from our program?
• Delivered a real product that could be demo-ed, deployed and used (with
• Agile seen as critical to success – with waterfall, the program would likely
have been deemed a failure
• Additional funding provided to extend program
India | USA | UK | Germany | Sweden | Belgium | France | Switzerland | UAE | Singapore | Australia | Japan | China 33