Presentation to IIBA South Florida Chapter Members, Courtesy of Borland's Mark Kulak and Bryan Fangman.

1. When Agile & Waterfall Collide – Managing
the Balance!
Mark Kulak
Bryan Fangman

2. MARK KULAK
Borland Caliber – Requirements Definition & Management
Director of Product Development

3. • The current state of software project success and
industry trends
• What’s wrong with traditional requirements
management methods
• Latest innovation and concepts in Requirements
Definition & Management with Agile delivery
3
Overview
© 2013 Borland

4. The Standish Group International, Inc. CHAOS Manifesto
4
Trends - Software project success
© 2013 Borland

5. 5© 2013 Borland

6. 6
What does Agile really mean for requirements?
© 2013 Borland

7. 7
Waterfall lifecycle
7
Requirements Definition & Management
© 2013 Borland

8. 8
Requirements Definition & Management
DefinitionElicitation Management Approval
Requirement
s
Requirements
© 2013 Borland

9. Waterfall Project Management
Strengths
1. Clear understanding of expected scope
2. Produces complete design and
documentation
3. Clearly visible project history and
evolution
4. Progress through stages is clearly
visible
5. Definition up front allows understanding
of what is fully expected
6. Enforces discipline by requiring
completion of one stage before moving
to the next
7. Staged approach is relatively easy to
implement and understand
Weaknesses
1. Mistakes in requirements lead to
significant wasted effort
2. Business needs change as defined
requirements wait for implementation
3. Great difficulty in adapting to change
across phases
4. Defining full features up front is difficult
5. Estimating up front is often inaccurate
6. Visibility of detail across stages is limited
(isolated by project roles)
7. Work occurs in cycles creating peaks and
valleys of activity
8. Monumental review process
9© 2013 Borland

10. 10
Agile Software Development
© 2013 Borland

11. Our highest priority is to satisfy the
customer through early and continuous
delivery of valuable software.
Welcome changing requirements, even
late in development. Agile processes
harness change for the customer's
competitive advantage.
Deliver working software frequently, from
a couple of weeks to a couple of months,
with a preference to the shorter
timescale.
Business people and developers must
work together daily throughout the
project.
Build projects around motivated
individuals. Give them the environment
and support they need, and trust them to
get the job done.
The most efficient and effective method of
conveying information to and within a
development team is face-to-face
conversation.
Working software is the primary measure
of progress.
Agile processes promote sustainable
development. The sponsors, developers,
and users should be able to maintain a
constant pace indefinitely.
Continuous attention to technical
excellence and good design enhances
agility.
Simplicity--the art of maximizing the
amount of work not done--is essential.
The best architectures, requirements, and
designs emerge from self-organizing
teams.
At regular intervals, the team reflects on
how to become more effective, then tunes
and adjusts its behavior accordingly.
Agile Manifesto
• Individuals and interactions… over process and tools
• Working software… over comprehensive documentation
• Customer collaboration… over contract negotiation
• Respond to change… over following a plan
11© 2013 Borland

12. 12
Agile / Iterative / Scrum…
© 2013 Borland
Developed
Tested
Documented

13. Weaknesses
1. "Agile" often implemented as un-
governed methodology
2. Limited requirements change
management / visibility
3. Non-functional requirements are difficult
to capture as user stories
4. Project scope not clearly understood
5. "Fail fast" approach knowingly introduces
regular rework
6. Lack of structure and necessary
documentation
7. Delivery focused
Agile Project Management – Requirements
Strengths
1. Adapts to changing business needs
in short cycles
2. Allows progress with limited
information
3. Mistakes in requirements lead to
limited wasted effort
4. Inclusive of all stakeholders across
project
5. Provides clear status in the form of
working software
6. Work occurs in a sustainable manner
13© 2013 Borland

14. • Agile was a pullback from very tightly managed and highly
governed waterfall lifecycle
• Manifesto was required
– A radical change required a radical action
– Agilista
• Agile needs to fit for the enterprise…
– Visibility
– History
– Traceability
– Governance
• Time to adapt… “be agile”, don’t “do agile”
14
Agile is now widely recognized as a software
lifecycle
© 2013 Borland

15. Agile / Iterative / Scrum…
Requirements
Definition
Requirements…
Elicitation?
Definition?
Collaboration?
Review?
Versioning?
Change Management?
15© 2013 Borland

16. Requirements Definition & Management
Elicitation Management Approval
Requirement
s
Requirements
Definition
16© 2013 Borland

17. Iterative Development
Two Life Cycles… Working as One
Iterative Definition
Add structure and management to the backlog
User
Feedback
17© 2013 Borland

18. • Requirements backlog
– Managed / groomed to enable consensus, visibility and
governance
• Incremental definition
– Detail defined according to relative priority
– Definition work spent on low priority requirements is waste
– Definition work beyond that required for communication is waste
• Iteratively turn over "well formed" requirements / user stories
– Defined, reviewed and approved… Manage the backlog
• Success measured against “business need” not against
“development unit”
– When is a product releasable?... Minimally marketable features
18
Agile requirements definition
© 2013 Borland

19. 19
Aren’t requirements and user stories
the same thing?
© 2013 Borland

20. 20
Defining Business Need - Requirement
Idea
Increasing
Detail
Fully formed
Requirement
High level goals
Basic visualization
Use cases
Functional
requirements
Non-functional
requirements
Business Need Driven
© 2013 Borland

21. 21
Defining Development Unit – User story
Task
User story
Feature
Breakdown for work
User story
Development Need Driven
© 2013 Borland

22. 22
Agile Requirements Bell Curve
Defining
Development
Detail
Defining
. Business
Features
What is the status of what was asked for?
Idea Task
Does what was created, satisfy what was asked for?

23. 23
Do I still need to define it all up front?
© 2013 Borland

24. Practical Fidelity (Incremental Definition)
Definition beyond what is required for communication is waste
24© 2013 Borland

25. 25
Pragmatic definition
Defining
Development
Detail
Detail required for business clarity
WASTE
© 2013 Borland
Defining
. Business
Features

26. 26
Different for every organization, project,
requirement
Light weight requirementsDetailed requirements
Regardless of level of rigor in the organizational process,
requirements must be managed
© 2013 Borland

27. Upfront Requirements Definition… a Contrast
Traditional
Requirements
Requirement 1
Feature 1.1
Feature 1.2
Feature 1.3
Requirement 2
Feature 2.1
Feature 2.2
Feature 2.3
Requirement 3
Feature 3.1
Feature 3.2
Feature 2.4
Feature 2.5
Agile
Requirements
Requirement 1
Feature 1.3
Requirement 3
• Full upfront definition
including low priority
features
• Rigid expectations
• Commitment to detailed
scope
• “Must Have” payload and critical
features defined upfront
• High level definition only, detailed where
details are needed
• Incremental detail added JIT to match
delivery team need (iterations)
• Commitment to high level scope
© 2013 Borland

28. © 2013 Borland
Approved
Requirement 1
Feature 1.1
Feature 1.2
Feature 1.3
Requirement 2
Feature 2.1
Feature 2.2
Feature 2.3
Requirement 3
Feature 3.1
Feature 3.2
Feature 2.4
Feature 2.5
Delivery Using Traditional Requirements
Requirement 1
Feature 1.1
Feature 1.2
Feature 1.3
Requirement 2
Feature 2.1
Feature 2.2
Feature 2.3
Requirement 3
Feature 3.1
Feature 3.2
Feature 2.4
Feature 2.5
Delivered
• What is delivered seldom matches
what is initially requested
• Implementation uncovers limitations
and opportunities
• Usage and market needs shift over
time
Approved
Requirement 1
Feature 1.1
Feature 1.2
Feature 1.3
Requirement 2
Feature 2.1
Feature 2.2
Feature 2.3
Requirement 3
Feature 3.1
Feature 3.2
Feature 2.4
Feature 2.5
Approved
Requirement 1
Feature 1.1
Feature 1.2
Feature 1.3
Requirement 2
Feature 2.1
Feature 2.2
Feature 2.3
Requirement 3
Feature 3.1
Feature 3.2
Feature 2.4
Feature 2.5
Overly managed change control
process impedes responsiveness
Feature 3.3

29. Requirement 1
Feature 1.1
Requirement 3
Requirement 1
Feature 1.1
Feature 1.2
Feature 1.3
Requirement 2
Feature 2.1
Feature 2.2
Feature 2.3
Requirement 3
Feature 3.1
Feature 3.2
Feature 2.4
Feature 2.5
Delivery Using Agile Requirements
Initial
Approval Delivered
Requirement 1
Feature 1.1
Requirement 3
Feature 3.1
Requirement 1
Feature 1.1
Requirement 3
Feature 3.1
Requirement 2
Feature 2.1
Feature 2.2
Feature 1.2
Iteration 2 Iteration 4
Requirement 1
Feature 1.1
Requirement 3
Feature 3.1
Feature 1.2
Iteration 6
Requirement 2
Feature 2.1
Feature 2.2
Feature 2.3
Feature 2.4
Feature 2.5
• Usage and market needs shift over time
• Flexible requirements definition process encourages
responsiveness
• Priority requirements are
delivered early, removing risk
• Implementation / demos uncover
limitations and opportunities
Requirement 1
Feature 1.1
Requirement 3
Iterative delivery… what about the iterative REQUIREMENTS delivery?
© 2013 Borland

30. DeliveryRequirements
Requirement 1
Feature 1.1
Requirement 3
Requirement 1
Feature 1.1
Feature 1.2
Feature 1.3
Requirement 2
Feature 2.1
Feature 2.2
Feature 2.3
Requirement 3
Feature 3.1
Feature 3.2
Feature 2.4
Feature 2.5
Iterative Requirements Definition
Iteration 8
Requirement 1
Feature 1.1
Requirement 3
Feature 3.1
Requirement 1
Feature 1.1
Requirement 3
Feature 3.1
Requirement 2
Feature 2.1
Feature 2.2
Feature 1.2
Requirement 1
Feature 1.1
Requirement 3
Feature 3.1
Feature 1.2
Requirement 2
Feature 2.1
Feature 2.2
Feature 2.3
Feature 2.4
Feature 2.5
Requirement 1
Feature 1.1
Requirement 3
Feature 3.1
Requirement 2
Feature 1.2
Feature 2.1
Feature 2.2
Feature 2.3
Feature 2.4
Feature 2.5
Feature 1.3
Feature 3.2
Feature #.#
© 2013 Borland
Iteration 0&1 Iteration 2 Iteration 4 Iteration 6
• Incremental requirements detail and
adjustment
• Focus on defining & approving the
next most important / risky features
• Incorporates changes
driven by demo feedback
and implementation

31. 31
Agile Requirements Definition and Delivery
© 2013 Borland
Make agile two lifecycles working as one
Iterative requirements definition
Iterative requirements delivery
Less waste by assuring business and
delivery are in alignment. Fail fast…
and less frequently
Pragmatic definition - only define enough
detail to satisfy organizational needs and
delivery clarity… Anything beyond is waste

32. BRYAN FANGMAN
Borland Caliber – Requirements Definition & Management
Senior Product Manager

33. • Testing will cover requirements at the time of definition as well as the
incremental deliverables in each supporting story
• As Agile practices become more managed, Agile requirements/stories will
trace to an increasing number of related elements
• More stakeholders will become actively involved in the elicitation and
approval process as tools improve efficiency
• Visualizations will become increasingly important for requirements
elicitation and validation
• The majority of individuals participating in the requirements management
process will use web-based and mobile solutions
• Organizations will become more efficient in centralizing, standardizing and
reusing requirements
• The accuracy of the initial and ongoing time/cost estimations will improve
and occur earlier in the lifecycle
33
The Future of RDM and Agile Tools
© 2013 Borland

34. • Testing occurs at multiple levels
– Requirements – validates the business capability is delivered
– User stories – validates the completeness of the individual
incremental capabilities
• User stories should be tested every sprint
• Requirements are tested after a appreciable amount of
business capability has been delivered
• Visual scenarios become the foundation for test cases
34
Testing
© 2013 Borland

35. • Requirements must be linked to user stories to provide
visibility into what has been delivered against the business
needs
• By understanding how much activity has transpired in
delivering the requirement, impact analysis is more
complete
• Better decisions can be made in real-time to avoid costly
rework
• Decisions can be made to postpone changes to allow critical
functionality to be delivered sooner
35
Impact Analysis with Agile Stories
© 2013 Borland

36. 36
Impact Analysis with Traceability
© 2013 Borland
- Trace to Visualizations
- Scenarios
- Simulations
- Trace design elements
- Trace regulatory requirements
- Trace dependencies

37. • Tradition non-Agile roles will become more involved
• Increased visibility allows for real-time feedback
• Reaching greater number of stakeholders ensures the right
functionality is delivered the first time
• Tools and technology advancements such as web-based and
mobile technologies promote real-time participation
37
Increased Stakeholder Participation
© 2013 Borland

38. 38
Increased Stakeholder Participation
© 2013 Borland
- Web and mobile access
- View related artifacts and
attributes
- Centralized feedback
- Approvals

39. Scenarios
Validate the process flow and identify requirements/business rules:
– What is the sequence?
– Who is involved at each step?
– What are the alternate paths and decisions being made?
Simulations
Validate the flow, behavior and usability of the user interface by role:
– Wireframes and layout
– Interactive demonstration of key capabilities
– Ensure agreement on UI before development starts
39
Visualizations Promote Agile
© 2013 Borland

40. 40
Visualizations: Storyboards (Scenarios)
© 2013 Borland
Validate the process flow and
identify requirements /business
rules:
• What is the sequence?
• Who is involved at each step?
• What are the alternate paths
and decisions being made?

41. 41
Requirements Validation
© 2013 Borland
- Scenarios can be validated
and are foundation for UAT
- Requirements acceptance
criteria defined up front

42. 42
Visualizations: Simulations
© 2013 Borland
Validate the flow, behavior and
usability of the user interface by
role:
• Wireframes and layout
• Interactive demonstration of
key capabilities
• Ensure agreement on UI
before development starts

43. • Reusable repository of key requirements
– Non functional requirements
• Security requirements
• Performance requirements
• Usability requirements
• Requirements are aligned with supporting user stories
• Requirements are traced to shared compliance
requirements (dependency)
• Updates to compliance requirements triggers suspect trace
with requirements and subsequent user stories
43
Regulatory Compliance
© 2013 Borland

44. • Requirements define the business capability
• User stories in aggregate should satisfy the business need
• Real-time integration of requirements with user stories is
critical for sufficient impact analysis
• Integration ensures that what gets delivered aligns with the
business needs
• Can be done whether moving from structured to Agile or
vice-versa
44
Aligning Business Needs and Delivery
© 2013 Borland

45. 45
Requirements and Agile Stories
© 2013 Borland
Create a new story
or trace to existing
stories

46. 46
Creating a New Story
© 2013 Borland
Create a new story

47. 47
Alignment of Stories with Business Needs
© 2013 Borland
Visibility of
delivery status

48. • Adopt a process that conforms to your preferred methodology
– Ensure the framework does not constrict productivity
– Respect roles that are not traditionally Agile
• Find a tool that fits within your methodology
– Allow each role to work with the tools they want
– Avoid restrictive workflows and rules
• Centralize best practices from successful projects
• Expand visibility between Agile assets and related artifacts for
real-time impact analysis
• Start with Agile delivery; the rest will follow an Agile tempo in
time
• Ensure what is delivered aligns to business needs
48
Enabling a Managed Approach to Agile
© 2013 Borland

49. QUESTIONS?
49© 2013 Borland

50. For additional information regarding:
• Presentation content
• Scheduling a demonstration
• Integrating requirements and agile delivery
• Products and services
• Speaking engagements
Please contact:
50
Contact Information
© 2013 Borland
http://www.borland.com
Bryan Fangman
Senior Product Manager
bryan.fangman@microfocus.com
(301) 838-5170
Mark Kulak
Director of Development
mark.kulak@microfocus.com
(248) 824-1743

51. BORLAND SOLUTIONS
Waterfall, Agile, others… we can help!

52. Borland’s Approach
We are Open... to the way you want to work and to the
investments you have already made in your ALM tooling
We are Agile... in how we work with you, responding
quickly to your changing requirements, bringing the
benefits of Agile to existing processes
We are Enterprise... in our scale and understanding, satisfying
even the largest of organizations
52

53. The award recognizes Borland’s Agile Transformation as an IT project that
exemplifies intelligent, creative use of technology to meet business and
technical objectives. Like most organizations considering a large-scale Agile
shift, Borland faced a major process renovation while still needing to execute
on an aggressive product roadmap. As Borland began to scale its Agile efforts
across an organization with more than 350 developers in five geographic
locations, teams needed a better way to collaborate, share information and
manage their work. At the same time, management needed visibility in order
to establish a baseline for performance and be able to measure the progress
and benefits of the transition to Agile.
Our Own Award-winning Agile Transformation
Borland received an Info World Top 100 Innovation
Award for transitioning its own development
organization to agile
53

54. Validated by Partners - Microsoft
The ideas we have shared are being echoed throughout the industry.
http://blog.hinshelwood.com/requirement-management-in-the-modern-application-lifecycle/
54
* See full article in upcoming
inaugural issue of ALM magazine

55. Caliber
Requirements Elicitation
Storyboards
Prototyping
Performance Metrics
Automated Functional Testing
Regression Testing
StarTeam
SilkCentral
Test Management
Test Execution
Defect Tracking
Test Reporting
Borland Solutions
Execute Tests and
Collect Results
Create Test Case
Scenarios
Synchronize Requirements
and Create Test Cases
Synchronize and
Trace
Requirements
Synchronize
Issues
Continuous Build and Test
Development Metrics
Source Control
Issue and Task Management
Agile Project Management
Glossaries
Baselines
Approvals
Traceability
Test Case Generation
Automated Load Testing
SilkPerformer
SilkTest
SilkMobile
On Device test automation
iOS, Android, BlackBerry
Cloud Execution
55© 2013 Borland

56. 56
Requirements Management and Traceability
Caliber Author
• Reuse requirements across projects
• Integrate with code development and testing tools for verification and
validation
• Understand the impacts of change and alignment to business
objectives through traced relationships
© 2013 Borland

57. • Visual clarity reduces process ambiguity
• Identifies missing or wrong underlying assumptions
• Stakeholder feedback improves quality of requirements
• Establishes a common vision
and shared responsibility
Scenarios and Simulations
Caliber Visualize
Visualization brings activities, actors and requirements together within their context
57© 2013 Borland

58. • License free model assures
maximum participation of
stakeholders
- Online discussions tied to
requirements
- Same discussions available
from Author, Visualize and
Review
58
Collaborate, Review and Discuss
Caliber Review
© 2013 Borland
• Additional functionality
- Baselines
- Filters
- Search
• View requirements, attributes,
traces via web

59. • Silk Central provides a unified framework
for the integration of requirements, test
automation tools
– Unit
– Functional
– Performance
59
Test Integration and Management
Silk Central Test Management
• Dashboard Reporting
• Manual execution planning
• Highlight risk mitigation
and quality goals
• Configuration testing
• Video and image capture
• SAP Testing
© 2013 Borland

60. Powerful, easy, cost-effective
• Open - offering leading Web 2.0 and broad enterprise application
support
• Agile - easiest to use load testing solution with a short learning curve
for rapid releases
• Enterprise - gain confidence in the performance and stability of your
mission-critical applications
60
Application Performance Testing
Silk Performer
• Leading Web 2.0 support
• Mobile testing
• Cloud integration
• Rich reporting and analysis
• Server monitoring
• Enterprise application support
• Workflows & wizards
• Accurate real-life user simulations
© 2013 Borland

61. Mobile app testing – simple, visual, powerful
• Easiest mobile testing tool ensures your mobile apps get to
market in half the time
• Robust combination of native, image and text based
recognition technology increases the usability of your apps
• Complete solution handling functional and performance testing
makes your mobile apps perform better
61
Mobile Application Testing
Silk Mobile
© 2013 Borland
• The way your users use it – gestures
support
• Broad mobile OS platform support
• No hacking required
• Native object recognition
• Optical character recognition
• Easy to use because it’s visual
• Easy to read execution reports