Challenges in Traditional Organizations • Impact on Agile Process • Tweaking Agile For Your Situation Development in short iterative cycles builds better trust relationship and a stronger engagement between the product owner/ customer and the development team. Stay tuned for our upcoming webinars at https://www.synerzip.com/webinars/ that might be of your interest.

1. www.synerzip.com
Using Agile in Non-Ideal
Situations
April 15, 2010

2. 2
Introduction
In this webinar we will share our observations, as a
“vendor/partner”, in effectively applying the spirit of Agile
software development in real business/org situations.
Each client organization has differing degree of Agile
expertise and business/organizational constraints that
come in the way of applying text-book style Agile.
In almost all cases, as a “vendor/partner” we have to
tailor the text-book style Agile process to suit the specific
client situation.
With our recommended modifications, you can still get
most of the benefits of the Agile approach.

3. Terminology For Today
Business,
Customer,
End-user
Product Mgr,
Product Owner,
Business Analyst
IT,
Dev Team
Dev + QA
IT Vendor,
Dev Partner

4. 4
Discussion Topics
• Challenges in Traditional Organizations
• Impact on Agile Process
• Tweaking Agile For Your Situation
• Conclusion

5. 5
Challenge #1: Budget vs Scope
Manifesto for Agile Software Development
We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on
the right, we value the items on the left more.
RESOURCE
TIMESCOPE
Software
Development
Triad
• Organizations need $$ budget approval
• Budget depends on scope
• Agile embraces change = scope increase
• But, organizations don’t like budget increase

6. 6
Challenge #2: Org Boundaries
“Business”
“Internal IT” “IT Vendor”
1. Inter-organizational hand-offs and trust issues
2. Inherent contractual mindset
3. Teams often distributed across geographies and time-zones
– end-user, product owner, developer, QA

7. 7
Discussion Topics
• Challenges in Traditional Organizations
• Impact on Agile Process
• Tweaking Agile For Your Situation
• Conclusion

8. 8
Typical Agile Cycle
Prioritizing
Requirements
CI
End
Time
Steps Impacted

9. 9
Requirements Analyses
One time up frontContinuous Iterative
Does the product owner/ customer
agree that the requirements likely
to change?
It’s a porting/rewrite
project. Customer/
Product Owner feels that
requirements won’t
change at all
It’s a start up/new project.
Everyone knows that
requirements will change.
Remote team need requirements
to be frozen and captured in a written
document. Is this a local team?
Development is
outsourced to a remote
team.
Development is handled by
a local in-house team.
Is it a long or an on going project?
It’s a 4 week project.
There is no time to have
requirements analysis
dialogue
It’s a long 6 months project.
There is enough time to
discuss and develop
requirements.
The budget x scope for the project are
Flexible?
Requirements need to be
signed off.
The requirements can be
flexible.
Is QA co located with the development
team?
QA can’t start testing till
development has finished –
making it a serial process.
Development and QA team
are co-located. Testers can
engage in over the shoulder
review and test what is
ready in parallel.
Non IdealIdeal

10. 10
Prioritization and Estimation
One time up frontContinuous Iterative
The customer/ product owner doesn’t
want a fixed budget contract in
advance?
This is a new customer.
Trust relationship is not
yet developed.
This is an old customer.
Trust relationship
is developed.
Is the customer /product owner
willing to prioritize features?
The customer allows no
Requirements to be left
Out. All are ‘must have’s”.
The customer allows
flexibility and you are
allowed or prioritize and
leave out or postpone
certain requirements.
Are the requirements in a state where
estimates can happen?
There needs to be an
iteration zero or POC
phase to define the
requirements.
The requirements are in
a state where
estimation is possible.
Do we have enough product/ domain
knowledge to take care of the situations
when the customer/product owner too
busy to answer developer’s questions?
Developers can’t make
any progress unless all
their questions are
answered.
The developers know
enough about the product
/domain to make suitable
assumptions.
Is the project long enough to have any
meaningful iterations to evolve the
requirements and refine the estimates?
Its too short a project to allow
any evolution of requirements
or re-estimation and re
planning. Estimates and plan
need to be frozen up front
Its possible to work with an
initial – rough estimate and
then work on clarifying the
requirements and re-
estimate for better accuracy
Non IdealIdeal

11. 11
Iteration/Release Planning
One time up frontContinuous iterative
Is the development team required to
accommodate last minute inclusions
or changes?
No flexibility or
postponement of
deliverables allowed
You can postpone some
features to the next cycle
Are all stake holders available to
review the deliverables and to provide
feedback at the end of each iteration?
Development team may
remain idle if scope is not
defined in advance.
Iteration evolution of
scope is possible.
Are the customer /product owner and
development team co-located?
Re-planning or
re-estimation is not possible
as communication is bottle
necked on account of time
-zone, language, distance
issues.
Re-estimation and
re-planning is possible with
lot of back and forth
communication.
Is the project duration long enough
to take advantage of reduction of
uncertainty as time passes?
Planning is a one time
exercise.
Its possible to plan more
accurately and reduce
padding as progress.
Non IdealIdeal

12. 12
Key Underlying Factors
1. How tight is time duration of the project
• Small – less than 2 months
• Medium – 2 to 6 months
• Ongoing – more than 6 months
2. How well elaborated are the requirements?
• No documents. Only whiteboard discussions. Typical of a
start up doing new development from scratch.
• Numbered list of functional requirements. Could be a list
of issues in a bug tracking system combined together to
develop a new version of an existing product.
• Documented use cases with wireframe diagrams. In the
case of a porting project the old version itself may serve as
the requirements definition.

13. 13
Key Underlying Factors (Cont’d)
3. Access/availability of customer
• No bandwidth for requirement discussions or intermediate reviews.
Transactional relation based on a contract document
• Limited bandwidth available only at the beginning of an iteration for
explaining requirements and at the end of an iteration to review the
work done.
• A full time champion resource to answer queries and review work
done.
4. Flexibility in scope, time or resources
• No flexibility. Fixed budget, features and time.
• Limited flexibility- Some buffer available in resources but features
and time are fixed
• Highly flexible-Features can be moved to future iterations.

14. 14
Key Underlying Factors (Cont’d)
5. Is the product owner co-located with the dev
team?
• Co-located with customer. Product owner is mostly busy
interfacing with the customers and end users.
• Shares time with dev and customer. The product owner
shares his time equally with customers and the dev team.
• Co-located with dev team. Product owner is co located with
the dev team.
6. Are QA resources co-located with the dev team?
• No. There are no QA resources with the development team.
Customer has decided to do the testing at their end.
• QA teams on both sides- While some testing is done by the
development team the customer has insisted on having their
own QA resources too.
• Yes-All the testers are closely collaborating with the
developers as they are co-located.

15. 15
Discussion Topics
• Challenges in Traditional Organizations
• Impact on Agile Process
• Tweaking Agile For Your Situation
• Conclusion

16. 16
Selecting the Right Approach
1. How tight is time duration?
2. How well elaborated are
the business reqmts?
3. Access/availability of
customer?
4. Scope X Resource
flexibility?
5. Is the product owner co-
located with the
development team?
6. Is QA located with
development team or with
the customer?
White-board,
no real docs
Use Cases w/
Wireframes
Not
available,
use doc only
Fully
available,
any time
No flex – fixed
resource,
scope
Highly
flexible
Numbered
list of
reqmts
Available at
start and end
of iteration
Limited flex
Co-located
with customer
Co located
with dev
Shares time
with dev and
customer
QA entirely
with
customer
All QA with
development
team
QA on both
sides
Small:
< 2 months
Ongoing,
> 6 months
Medium: 2 to
6 months
Non Ideal Ideal

17. 17
Case #1: Short, Fixed-Budget Project(s)
1. How tight is time duration?
2. How well elaborated are
the business reqmts?
3. Access/availability of
customer?
4. Scope X Resource
flexibility?
5. Is the product owner co-
located with the
development team?
6. Are QA resources located
with development team or
with the customer ?
White-board,
no real docs
Use Cases w/
Wireframes
Not
available,
use doc only
Fully
available,
any time
No flex – fixed
resource,
scope
Highly
flexible
Numbered
list of
reqmts
Available at
start and end
of iteration
Limited flex
QA entirely
with
customer
All QA with
development
team
QA on both
sides
Small:
< 2 months
Ongoing,
> 6 months
Medium: 2 to
6 months
Non Ideal Ideal
Co-located
with customer
Co located
with dev
Shares time
with dev and
customer

18. 18
•Series of fixed budget projects
•Requirements, estimation and
planning done only in iteration zero
•Short iterations with TDD, CI
•ROI improves with every project
Case #1: Short, Fixed-Budget Project(s)

19. 19
Case #2: Emerging Reqmts, Distributed Team
1. How tight is time duration?
2. How well elaborated are
the business reqmts?
3. Access/availability of
customer?
4. Scope X Resource
flexibility?
5. Is the product owner co-
located with the
development team?
6. Are QA resources located
with development team or
with the customer?
White-board,
no real docs
Use Cases w/
Wireframes
Not
available,
use doc only
Fully
available,
any time
No flex – fixed
resource,
scope
Highly
flexible
Numbered
list of
reqmts
Available at
start and end
of iteration
Limited flex
QA entirely
with
customer
All QA with
development
team
QA on both
sides
Small:
< 2 months
Ongoing,
> 6 months
Medium: 2 to
6 months
Non Ideal Ideal
Co-located
with customer
Co located
with dev
Shares time
with dev and
customer

20. 20
Start
Prioritizing
Requirements
CI
New
Requirements/
Change request
End
Time
• Long –ongoing engagement
• Requirements are met as they
change or newly arise.
• Backlog is re-prioritized and re-
estimated to begin every iteration
Case #2: Emerging Reqmts, Distributed Team

21. 21
Case #3: Well Defined, Long Project
1. How tight is time duration?
2. How well elaborated are
the business reqmts?
3. Access/availability of
customer?
4. Scope X Resource
flexibility?
5. Is the product owner co-
located with the
development team?
6. Are QA resources located
with development team or
with the customer?
White-board,
no real docs
Use Cases w/
Wireframes
Not
available,
use doc only
Fully
available,
any time
No flex – fixed
resource,
scope
Highly
flexible
Numbered
list of
reqmts
Available at
start and end
of iteration
Limited flex
QA entirely
with
customer
All QA with
development
team
QA on both
sides
Small:
< 2 months
Ongoing,
> 6 months
Medium: 2 to
6 months
Non Ideal Ideal
Co-located
with customer
Co located
with dev
Shares time
with dev and
customer

22. 22
Start
Prioritizing
Requirements
CI
End
Time
• Requirements are fixed as this is
a porting/rewrite project.
• However we continue to re-plan
and re-estimate as changing
priorities result in requirements
being shifted between iterations.
Case #3: Well Defined, Long Project

23. 23
Discussion Topics
• Challenges in Traditional Organizations
• Impact on Agile Process
• Tweaking Agile For Your Situation
• Conclusion

24. Agile in Non-ideal Situations
• Certain processes which should be ideally running in parallel with other
processes in an agile iteration but because of certain non ideal
conditions they can only run in series before or after the agile iteration.
• It is possible to derive many benefits of agile by continuing to run the
other processes in parallel in an incremental iterative manner
Confidential 24
Ideal (Agile) Non-Ideal (Waterfall)
QA / Integration
Development
Requirements
Plan/Estimate
Acceptable (Hybrid)
QA / Integration
DevelopmentRequirements
Plan/Estimate
QA / Integration
Development
Requirements
Plan/Estimate

25. Still Gaining Benefits of Agile
• Development in short iterative cycles builds better trust
relationship and a stronger engagement between the
product owner/ customer and the development team.
• We can practice and derive all the benefits of agile
practices of continuous integration, TDD for unit testing,
scrum and iteration retrospective in the recommended
hybrid model.
• By following the hybrid approach you can expect the non
ideal conditions to change for better and if they do, you
have the option to move one step closer to the classical
agile approach by including the concerned process in the
iteration.
Confidential 25

26. 26
Questions?
www.synerzip.com
Hemant Elhence, hemant@synerzip.com
469.322.0349
Agile Software Product Development Partner

27. Confidential
Synerzip in a Nut-shell
1. Software product development partner for small/mid-
sized technology companies
• Exclusive focus on small/mid-sized technology companies
• By definition, all Synerzip work is the IP of its respective clients
• Deep experience in full SDLC – design, dev, QA/testing, deployment
• Technology and industry domain agnostic
2. Dedicated team of high caliber software professionals
• Seamlessly extends client’s local team, offering full transparency
• NOT just “staff augmentation”, but provide full mgmt support
3. Actually reduces risk of development/delivery
• Experienced team - uses appropriate level of engineering discipline
• Practices Agile development – responsive, yet disciplined
4. Reduces cost – dual-shore team, 50% cost advantage
5. Offers long term flexibility – allows (facilitates) taking
offshore team captive – aka “BOT” option

28. Confidential
Our Clients

29. 29
Thank You!
Call Us for a Free Consultation!
www.synerzip.com
Hemant Elhence, hemant@synerzip.com
469.322.0349
Agile Software Product Development Partner