1. The project manager recruited a team of developers and testers to build a bilateral system for iBasis using an agile methodology. 2. The project manager traveled to the customer site for two weeks to understand the current system and write requirements documents. 3. Upon returning, the developers were trained on the relevant technologies while the project manager began planning sprints and estimating tasks.

1. Fixed Distributed Agile
The way to do it right!
Shlomi Otmazgin
Head of Java & Internet, Matrix Global

2. About iBasis
• iBasis is a private corporation based in Burlington,
Massachusetts.
• It is a wholesale carrier of international long distance
telephone calls, with enhanced services for mobile
operators, and a provider of retail prepaid calling services.
• In Fiscal Year 2010, iBasis had total revenues of
$1.8 billion, carried approximately 32 billion minutes of
international voice traffic, and employed approximately
420 people.

3. Bilateral project
Bilateral system connects between iBasis clients &
vendors that don’t share any commercial
relationship, or are able to find better rates with
iBasis, for example:
Bilateral

4. Building the team
The team structure:
• 1 Project Manager
» Development Team
1 Senior Java Developer
4 junior Java developers
» QA team
1 QA team leader
2 QA testers

5. Choosing the Frameworks
Supports MVC Model.
Written in Java 6 upon eclipse.
All HTTP calls are pure Ajax.
Uses ExtJS to draw RIA.
Uses DWR engine to allow simple asynchronous server-client data transfer.
ORM by Hibernate annotations to Oracle 10 DB.
Object initialization by Spring IoC & Spring Injection.
Automated testing by JUnit 4.
Logging support by Log4j.
Reports support using JXL for Excel & iText for PDF.
Build by Maven 2 & deployed on Tomcat 6 using Hudson.
Cross browser application.

6. Screen shots
Desktop environment
A drag & drop resizable windows environment.
Clean, rich, fast, flexible & very intuitive.
Smart search screens
Auto complete paginated combo boxes.
All actions are very fast using Ajax.

7. Go!
1. Project manager was recruited.
2. Senior developer and junior developers recruited (by project manager).
3. Project manager traveled to customer (2 weeks):
• Learned the current system.
• Wrote HLD & SDD.
• Review and authorization of above.
4. In parallel – developers trained in relevant technologies.
5. Development begins within one month.
• First release on schedule - after 4 months.
• Second release (iterative) - after 3 months.
• Third release - no travel - after 3 months.

8. Fixed Distributed Agile
Step 1 – HLD & SDD With no estimations!
• Write the HLD & SDD to the whole project.
• Build the product backlog.
• Was done at the client’s site.
Duration: 1-2 weeks

9. Fixed Distributed Agile
Step 2 - Artifacts
• Meet the team and held ALL the sprint planning meetings
one after the other.
• Get the precise estimations for each task
using scrum poker cards.
• Build the sprint backlogs for the entire project.
• Add 15%-20% time as a fix project safety net – WHY?
• The team members pick the tasks & the team leader build
the project gantt. Duration: 1 week

10. Fixed Distributed Agile
Step 3 – SOW
• With accurate estimation for the whole project
write the SOW.
• Negotiate the estimations with the client & get
the final approval.
Duration: 1 day

11. Fixed Distributed Agile
Step 4 – Work begins!
• Work begins with a daily stand up meeting.
• Weekly meeting with the client to review the progress &
solve open questions.
• After each sprint (3-4 weeks) – sprint review meeting with
the client.
• Retrospective team meetings from current sprint for the
next ones.
• 1 week max for client’s sprint review.

12. Fixed Distributed Agile
Step 5 – The Finish Line
• Release the final version after 4 months & 5 sprints.
• Because of 15%-20% extra time the CR’s along the
way languish into the initial specifications.
1 week max for client’s sprint review.

13. The Agile Aspect
The client is aware of the team status on a daily basis.
He MUST review the project status on each of every sprint.
The client can notice misunderstandings or can just modify
the design while developing to suit his will, up to a certain
level – huh?!?.
Development is very flexible because changes are made in
an early stage thus rewriting is an easy effort.

14. The Agile Aspect
Product & design change along with development to create
a product that is suitable to client’s expectations.
If CR is too big we usually postpone it to the next phase.
Use of scrum concepts as: stand up/weekly/sprint meetings,
product backlog scrum poker cards, XP.
There are 0 “bad surprises” on delivery – UAT

15. Scary? Don’t call it Agile!
Typical Agile reactions
• Low ceiling for new ideas - the angry monkey
experiment.
• Our product/structure/management is too complex for
Agile.
• We started and than backed off.
o Was your client/management/colleague devoted?
• I do want but I can’t get my manager’s approval.
• I don’t know where to start!

16. Scary? Don’t call it Agile!
1. Start using agile without shouting it.
2. Use what fits you.
3. Go for quick wins.
4. When showing your managers it helps you, talk about
ROI (it makes them feel cozy…)
5. Add more & more Agile routines to the team.
6. One day you’ll wake up with an Agile sleeping next to
you :-)

17. Finally,
we must remember that our
mail goal was & always will be
Adjusting to our client
expectations

18. Even if they seem odd…

19. Q&A

20. Thanks