Agile Software Development
Dr.-Ing. Thomas Stober
Release Architect, WebSphere Portal IBM Deutschland Entwicklung GmbH
IBM Software Group
2
Agenda
Introduction WebSphere Portal
About the team, the product …
.. and the traditional development approach
Agile Software Development
A variety of approaches
Mix and Match
Agile development for Portal
Best practices
IBM Software Group
4
About WebSphere Portal: The Team
Global development
8 major locations
Multiple delivery streams
Major releases every 1 ½ years
Express
Fix packs
Other product dependencies
WebSphere Application Server
WebSphere Process Server
Quickr
And many more …
Boeblingen
Boeblingen
Haifa
Haifa
Westford
Westford
Raleigh
Raleigh
Beijing
Beijing
India
India
Sidney
Sidney
Yamato
Yamato
About Portal: Traditional Development Approach
Portal Development Process
Description, HOW to develop
Analysis
Requirements
Design and Development
Line Items
Design Documentation
“DCUT” Design-Code-Unit-Test
Test
Test scenarios
“IUT” Integrated Unit Test
“FVT” Function Verification Test
“SVT” System Verification Test
Final regression testing
Management System
Commitment, WHAT has to be developed
“IPD” Integrated Product
Development
“DCP” Decision Check Points
Concept
Plan
Availability
Release Content
IBM Software Group
6
About Portal: Traditional Development Approach
Coding complete
The Perfect Plan
Golden Master
Develop
Analysis
The Perfect Plan …
… Does NOT Exist !
If anything can go wrong, it will. Murphy‘s Law
Human life is just an instance,
IBM Software Group
8
Waterfall Approach: Getting Tougher Towards the End
Coding complete
The Perfect Plan
Golden Master
Develop
Analysis
Test
$
t
Fehlerkosten Kosten/Umfang Zeit QualitätWhen Everybody gets
really
nervous …
Coding completeDevelop
Test
20051102 20051109 20051116 20051123 20051130 20051207 20051214 20051221 20051228 20060104 20060111 20060118 20060125 20060201 20060208 20060215 20060222 20060301 20060308 20060315 20060322 20060329 20060405 20060412 20060419 20060426 20060503 20060510 20060517 20060524 20060531 0 2000 4000 6000 8000 10000 12000 14000 0 2000 4000 6000 8000 10000 12000 14000Total & Valid Defects
Projected Defects Projected Valid Actual Defects Actual Valid Total Backlog GM
Plan: Test complete
IBM Software Group
10
The Vasa Project, 1628
http://www.vasamuseet.se
… but has its limits
Accept uncertainty
There is no perfect plan
Customer does not know or describe his requirements clearly enough
Technical solution is not entirely understood
Errors in design and implementation can invalidate plans
Changes in team are possible at any time
Change of customer requirements and your priorities are possible at
any time
Risk Management
The most dangerous events are those which are not predictable
Plan for Change!
Planning is good …
It ain't what you don't know that gets you into trouble.
®
IBM Software Group
© 2007 IBM Corporation
Agile Software Development
What is Agility?
React to changing requirements and constraints
Balance
between Flexibility and Structure
Within your organization
During planning and execution
When using processes and tools
In your mentality
IBM Software Group
14
Agility: Keep the balance between predictable
Structure and total Flexibility (I)
Flexibility is good, but no for free!
Airline Tickets are cheaper when you commit to your destination and
travel dates early! Same is true for product features
Provide best possible guidance and planning!
Don’t use “Agility” as an excuse for lack of planning and design
Establish high-level goals and timelines
Keep risks in mind and have mitigation plans ready
Agility: Keep the balance between predictable
Structure and total Flexibility (II)
Understand two fundamental cultural patterns
according to Edward T. Hall, http://en.wikipedia.org/wiki/Edward_T._Hall
Monochronism demands a planned, deliberate control over time.
This is a task-oriented way of living. Individuals like to identify time periods when certain activities will be done. Their strengths may be utilized in
developing schedules whose exactness and precision allows workers to function in a cooperative manner.
It 's efficient for getting things done and it dominates most parts of the US and other industrialized countries.
Polychronism is the perception of time as merely a context in which we live.
Tasks are handled as they come. Such jobs require that the individuals constantly adjust to incoming new jobs and responsibilities. They enjoy change as part of their job (and) changing from one activity to another is the part of this pattern.
This is a relationship-oriented way of living. It's efficient for building
community, personal, and social relationships, and it dominates Asia, as well many rural areas.
IBM Software Group
16
IBM’s definition of Agile Development
“Uses continuous stakeholder feedback to deliver high-quality and
consumable code through use cases and a series of short, time-boxed
iterations.”
Key Features:
•
Stable
code at the end of each iteration
Æ be able to “ship” every few weeks
•
Meaningful
stakeholder
interaction
Æ get customer feedback – outside-in-design.
Æ Avoid anything that does not add value (waste).
•
Trust
the team
Æ delegate responsibility
Æ establish teams responsible for end-to-end functionality (reduce hand-offs and task switching)
Mix and Match:
IBM Software Group
18
Horizontal Teaming
Theme & Component Matrix
Components
Æ
Å
Themes
Infrastr. CMAPI Security Test
…
…
Owner Owner Owner Owner
Owner Owner Owner Owner Horizontal (=„Tiger“) -Teams major cross-cutting themes. component affinity. Organizational Focus Goal/Delivery Focus
Test
Translating Customer Requirements into
Vision/High Level Goals
Customer
I want a really cool user interface,
which is state of the art
I want to leverage the most recent
WAS as the common platform within my company
Leadership Team
- Create a new User Interface - Support WAS 6.1
Prioritization Strategy planning Release planning
Budget allocation /staffing High level use cases
ÆDeliver a release in 3Q07, and another in 1Q08 ÆInvest 5 people to create a new User Interface ÆInvest 4 people to support WAS 6.1
Decision
(staffing, rough timeframe and high-level goals)Vision
IBM Software Group
20
Stabilization Points ÆDeliver a release in 3Q07, and another in 1Q08
ÆInvest 5 people to create a new User Interface ÆInvest 4 people to support WAS 6.1
Decision
(staffing, rough timeframe and high-level goals)Translating Vision/High Level Goals into
actual Requirements/Line Items
Translating high-level goals into technical requirements and line items
Leadership Team
ÆInvest 5 people to create a new UI
ÆInvest 4 people to support WAS 6.1
High-level goal Discussion
Timeframe Discussion
ÆLeverage Ajax ÆMove from WMM to VMM ÆJava 5.0 complianceTiger Team Leads
ÆDeliver a 6.0.2 release in 3Q07 and a 6.1 release in 1Q08 GM Release 6.0.2 Inception Teamcharter Requirements HCDD, Test plan Efforts Staffing Priorities Teamcharter Requirements HCDD Test Plan Efforts Staffing Priorities
Content (requirements and plan outline)
INCEPTION --- STEP 2:
GM Release 6.1 StabilizationPoints (Iteration Exits) Decision Æ ContentCreate an Iteration Plan
Teamcharter Requirements HCDD Test Plan Efforts Staffing Priorities Teamcharter Requirements HCDD Test Plan Efforts Staffing PrioritiesLeadership Team
Line itemLine item Line item Line item Adjust … Vision, Decision (staffing/timeframe/goals) … when necessary Adjust … priorities, requirements line items… when necessary
Tiger Team
Create a Plan
... based on given timeframe ... based on given goals
... based on agreed teamcharter
Line item Line item Line item Line item Work for a future release Iteration Plan … - agile, adaptive
- strategic cross-release thinking - includes Dev and Test work items
Working …
- use case driven, - decentralized,
- within given high level goals - in horizontal teams
Content
(requirements and plan outline)GM Release 6.0.2 GM Release 6.1 StabilizationPoints (Iteration Exits) Test
Scen. Scen.Test
Test Scen. Test Scen. Test Scen. Test Scen. Line item Line item
IBM Software Group
22
StabilizationPoints (Iteration Exits)
Executing an Iteration Plan
Teamcharter Requirements Line Items HCDD Test Plan Efforts Staffing Priorities Teamcharter Requirements Line Items HCDD Test Plan Efforts Staffing Priorities Line itemLine item Line item Line item Line item Line item
ELABORATION, CONSTRUCTION --- STEP 1:
Tiger Team Leads
Line item Line item Line item Line item Work for a future release
Iteration Plan (Line Items for execution)
Actual Code in CMVC streams
Common CMVC Rel. 6.0.2
GMRelease 6.0.2 GMRelease 6.1 Release Closure Design Design Design Design Future Release Tracking Status PCR Adjustment (when necessary)
Release Management
Common CMVC Rel. 6.1
ReleaseClosure Design DesignMonitoring
Plan Æ Code Test Scen. Test Scen. Test Scen. Test Scen. TestScen. Scen.Test
Deliverable
Quality Assessment Common CMVC Rel. 6.0.2Release Closure
Line itemLine item Line itemTiger Teams
Iteration Exit Quality AssessmentRelease Management
StabilizationPoints Line item Line item Lineitem Lineitem
Line item Line item Line item Work for a future release
Acceptance
Release
Good Driver Iteration Exit Iteration Exit Iteration Exit Test Scen.Test Scen. Test Scen. Test Scen. Test Scen.Test Scen. Test Scen.Test Scen. Test Scen.Test Scen. Good Driver Extended FVT GVT TVT SVT Final Regr IUT IUT GMTest Teams
Quality AssessmentDeliverable
Perf. TestingIBM Software Group
24
Example: The Web 2.0 Tiger Team (I)
09/2006
Mission defined Initial Team staffed
03/2007
Mission updated
Plan aligned with Portal V6.0.2
Demo of Prototype on Greenhouse Demo at LotusSphere 09/2007 Mission updated
Plan aligned with Portal V6.1
Early Delivery as Portal V6.1 Beta GM Delivery as Portal V6.1 Beta 05/2008 (plan) Mission completed:
GM Delivery with Portal V6.1
REST Services
Basic Client Side Theme Demo Portlets
Drag&Drop Themes & Skins Back Button
Semantic Tagging
Client Side Programming Model
AJAX Proxy, Access Control Property Broker
Accessability and I18n
Leadership
Team
Web 2.0 Tiger Team
Go als Bu sine ss Sc en ari os Engine Business Portlets Business Portlets Portlet Container Admin UI Test Project Mgnt
Summary and
Best Practices
IBM Software Group
26
Agile Development
Outside In Design
Test driven based on use cases
Think horizontally across Organizations
Sustainable Pace
Continuous integration of code
Stabilization points
Prototyping and early customer feedback
Learn as we go
Allow teams to stay focused
It‘s a lot about philosophy
There is NO general rule
Mix and Match is common
Accept that
Change
is part of your plan
Critical for Success: Management Responsibility
Initiate
Tiger Teams
early
with staffing based on the budget decided
Provide sufficient
guidance
to the teams:
Provide a “feature grid” and a “timeline grid”
Æ Communicate a well defined overall Vision and high level Goals
Æ Communicate a rough timeline in which deliverables are expected
Æ Make clear and timely decisions
Æ Balance detailed goals versus flexibility
Delegate
responsibility
to the teams
Teams do detailed planning and prioritization of Line Items within the given High Level Goals
Æ they are the subject matter experts
Æ they have the authority to act within give guidance and goals
Allow teams to focus on making progress
IBM Software Group
28
Critical for Success: Planning Responsibility
Support
Agility
Do not overcommit a Tigerteam
Æ Only commit to really important “must-have” work items.
Æ Don’t be too aggressive. Be realistic.
Drive Content based on use cases and customer value
Plan for test coverage and execution (automation!!)
Anticipate changes throughout the project and be prepared to adapt to changes
Stick to schedule/iteration length, but rather move content around (“time boxing”)
Avoid
excessive use of
Agility
Change is good! But it doesn’t come for free
Allow the team to stay focused
Æ Keep overall vision, high level goals and rough timeline as stable as possible
Allow the team to execute
Æ Limit re-planning exercises, unless absolutely necessary
Æ Avoid team members being side-tracked
Allow the team to gain a common team spirit
Critical for success: Collaboration
Collaborate
across component and location boundaries
“We” = Tiger Team
– Avoid constantly changing team members – Ensure a reasonable staffing
Integrate test and development members
– Common goals
– Exchange of expertise
– More effective, quicker defect turnaround
Integrate team members across locations and organizations
– We are a globalized company
End-to-End thinking based on use cases
– Out of the box thinking
– Responsibility for customer value rather than component function
Ensure component consistency and quality
®
IBM Software Group
© 2007 IBM Corporation
Your Questions, please ...
