A real life success story: Commercial software and website developed in nine months
CTO, ZOOMtoLearn, Toronto, Canada
- This paper shares a real life story of launching a commercial software and website in nine months: Agile techniques were used to deliver fast, and an offshore team was used to reduce cost. The project took only nine months and 1,500 person hours, using seven secrets of fast delivery:An onsite customer to explain and prioritize requirements
- A highly-skilled team leader
- A dedicated team
- A war room setting
- Allowing the development team to own the requirements
- An onsite customer to validate the requirements fulfilled
In early 2012, a start-up called ZOOMtoLearn was established, delivering working software and a website at the least possible cost. .
Agile techniques were used for delivering fast results and an offshore team was set up to reduce costs.
It took approximately nine months to collect requirements, develop technical specs, coordinate development, test, launch, and stabilize the software product and website. The offshore team (www.softwareord-it.com/en) was located in Istanbul and it took around 1,500 person hours to complete and stabilize the software product and the website, making it one of the fastest deliveries the company ever completed. Problem statement:
As a start-up, we had to move fast and deliver a working software and a website as soon as possible with the least possible cost.
We applied agile techniques for delivering fast and used an offshore team reducing the cost.
April 2013: A prototype was developed in two weeks (200 person hours).
May – July 2013: We conducted four focus group meetings in Toronto in which a prototype for finalizing user and business requirements was presented to a total of 40 participants.
August 2013: We identified 40 product requirements, 19 website requirements, 21 content requirements. Furthermore, 50 user values, 1 customer persona, and 3 usage scenarios were identified to prioritize requirements accordingly.
October 2013: Requirements were then translated into “technical use cases” by the software development lead in Istanbul. Then the offshore development team completed the software and the website in six weeks, expending around 600 person hours.
early November 2013: The software product and the website launched.
November, December 2013: Around 700 person hours were spent fixing the defects found in the live system. By the end of December 2013, the product and the website were highly stable.
The agile principles for fast and high quality software development
Onsite customer to explain and prioritize the requirements
During software development, the customer was represented by the product owner, Orhan Kalayci. The product owner should be confident in knowing what the customer wants.
The product owner should be able to judge which features are crucial for a minimum viable product (MVP) so that customers will be happy with the available features.
We followed a formal methodology to establish and conduct four focus group meetings with the help of an external facilitator, Zeynep Aydin, a marketing consultant, based in Toronto, Canada. We had high confidence in our understanding of customer requirements since we presented our prototype to 40 potential customers. We also developed a customer persona, 50 user values, and 3 usage scenarios.
As shown in the Figure 1, our customer persona tells us a lot about our customer.
Figure 1: Customer persona
Our customer's name is Georgína. She and her husband are both university graduates and work full time. They have two kids, one dog, two cars, and a house. They conduct several of their day-to-day activities with the help of smartphones, tablets, and laptops. They have difficult customers, sponsors, team members, and peers. They are time poor. Unfortunately, they lack job security.Their projects have clear end dates; however, once a project is over, there is no certainty that they will be assigned to another project. Communication is their number one priority. They have to read and write many reports, emails, etc. They are experts in dealing with uncertainty; they used to deal with office politics, gossip, and rumors. They attend their local chapters, conferences, and networking events.
Our product owner was collocated with the software development team during the actual development to explain the requirements to software development team and answer their questions. Furthermore, he was willing to take risks by changing, combining, canceling, and postponing the requirements according to the customers’ priorities for staying in preset timeboxes. He also encouraged the team to own the requirements.
Highly skilled team leader
A highly skilled team leader is crucial for the success of an agile development team. Luckily we had such a leader onour team; his name is Cemal Can Efe. He possesses outstanding technical skills and soft people skills, making him an ideal leader on the software development team. We had to use mapping techniques for developing our product. By chance, our team lead had just completed a project for a large real estate agency in the U.S., allowing for their users to see available houses for sale in a given state or a region on a map.
Figure 2 shows our team lead summarizing the main modules of our product for the team members.
Figure 2: Our team lead, Cemal Can Efe, is summarizing the main modules of our product for the team members.
During the development of the pilot in April 2013, there were three software developers: Team lead, GUI developer, and database designer. In October 2013, for product development, we have worked with the same three developers plus GUI expert and .NET specialist for six weeks.
Figure 3 shows our software development team.
Figure 3: Our dedicated software development team in action.
War room setting
The software development team was based in an office equipped with a large white board, equipping the team with another communication tool to assist in formulating and expressing their ideas. Wall space also served to make the main features, requirements, and the progress visible as the team drew them up. The tasks for the current day and the next could always be visible on the walls or on the white board.
Figure 4: Customer requirements, features, and their progress visible on the walls.
Allowing development team to own the requirements
Understanding requirements is a prerequisite of ownership of the requirements. So the very first thing we had to do was to ensure that requirements were written and grouped in a simple fashion.
Accordingly, we always kept the number of main features less than 10. Requirements were grouped into approximately seven groups with approximately seven requirements in each group.
The software development team was encouraged to change the requirements as needed, as long as business results were not affected. For example, sometimes they preferred a different naming or term to refer to a feature. As long as it was not misleading or wrong, they were encouraged to use their own naming conventions.
Figure 5 shows requirements in a mind map format so that the team could get a better understanding of the requirements. The mind map version also allowed the team to monitor and track the progress in terms of completed requirements. Color coding was used to highlight high-priority requirements (Red for high priority, yellow for medium, and blue for low priority). Given the correct context, red also means a requirement is not started for implementation; yellow means it is in progress; and green means it is completed.
Figure 5: Requirements in a mind map format, whichfacilitates understanding the requirements, as well as monitoring and controlling.
Figure 6 shows that requirements are grouped into seven main requirements to ease communication and tracking.
Figure 6: Requirements are grouped into seven main requirements.
The development team lead transformed requirements into technical use cases. During the transformation, he suggested some changes; most of his suggestions were accepted and he was encouraged to change or improve the requirements.
One customer requirement may be transformed up to ten technical use cases. Each use case may take from 10 minutes to several hours of work.
At the end of the day, it is important for a software development team to feel they understand and contribute to meaning of the work they are performing for days and weeks.
Figure 7 shows list of technical use cases and tracking information on use cases.
Figure 7: Technical use cases with tracking information
For prototype and product development, duration and the budget were both fixed so the only variable left to change was requirements.
This way everybody feels like they accomplished something. By the end of the budget and time, we received a working software, and the customer was happy since there was a product which was up and running. The success of timeboxing highly depends on having an onsite product owner who knows the customer and customer requirements, so that he can make decisions on what to postpone for the next release and what not to.
Figure 8: Duration and budget was fixed; scope was flexible.
Onsite customer to validate the requirements fulfilled
The product owner plays an important role for validating the product for accepting purposes. Validation of requirements by product owner (customer) allows the product owner to think about requirements once more. Although it is not usually the case, sometimes minor changes were made on requirements during the validation.
Transparency is a great motivator: if, as a customer and product owner, you can share your screen with the rest of the team, it would be great to allow the rest of the team to learn how you validate the product and hence they will keep an eye on your screen. We accomplished this by putting a projector in the room for the customer to share his screen with the rest of the team.
Figure 9 shows how the product owner's screen is projected onto the wall while he was performing a validation.
Figure 9: Product owner's screen is projected on wall during a validation.
This paper shares a real life experience in developing a commercial software and a fully-working website in a very short period of time.
In April 2013, a prototype had been developed in two weeks (200 person hours). Four focus group meetings were organized based on one customer persona and three usage scenarios. A total of 40 people saw the prototype and helped finalize user and business requirements. Forty product requirements, 19 website requirements, 21 content requirements, and 50 user values were identified. Then the project team prioritized and translated them into “use cases,” which were developed offshore in six weeks (600 person hours) using an agile approach.
In late November 2013, the product was launched. In December, the offshore team had spent 900 person hours fixing the defects found in the live system. By the end of December 2013, the product and the website were highly stable.
The secret to this speed and quality was:
- Onsite customer to explain and prioritize the requirements
- Highly skilled team leader
- Dedicated team
- War room setting
- Allowing development team to own the requirements
- Onsite customer to validate the requirements fulfilled
ZOOMtoLearn™ Inc. and our first product ZOOMtoProjectManagement would not have been possible without the kind support and help of many individuals and organizations. We would like to extend our sincere thanks to all of them.
Joseph Wilson, Nathan Monk at MaRS , Toronto, ON, Canada
Venture Start, Mississauga, ON, Canada
Softwareord-IT, Istanbul, Turkey
Bryan Kanarens at Spark Centre, Oshawa, ON, Canada
Zeynep Aydin, Marketing Consultant, Toronto, ON, Canada
Keith Hampson, PhD, Domain Expert – eLearning, Toronto, ON, Canada & Pittsburgh, PA, USA
JoDee Grimmett, Graphic Designer, Chicago, IL, USA
Ismail Berkan, Lean Startup/Management Consultant, Istanbul, Turkey
© 2014, Orhan Kalayci