Fixed Distributed AgileThe way to do it right!Shlomi OtmazginHead of Java & Internet, Matrix Global
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.
Bilateral projectBilateral 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
Building the teamThe team structure: • 1 Project Manager » Development Team 1 Senior Java Developer 4 junior Java developers » QA team 1 QA team leader 2 QA testers
Choosing the FrameworksSupports 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.
Screen shotsDesktop 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.
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.
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
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
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
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.
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.
The Agile AspectThe 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.
The Agile AspectProduct & 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
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!
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 :-)
Finally, we must remember that ourmail goal was & always will be Adjusting to our client expectations