eBay's 5 Minute Deals with Agile Development, Corporate Start-Up, and Devops

This article is a summary of the key points taken from a keynote speech at Scrum Australia: Corporate Start-Up, Scrum, DevOps and eBay's 5 Minute Deals
The full presentation was given by Dimitri Spyridopoulos & Justin McRae at Scrum Australia 2014 and the slides can be found in the image below (links to Slideshare).

The Challenge:
Create a robust syndicated e-Commerce micro-site, that is responsive, has engaging user experience and can handle large quantities of transactions (say 30,000 per hour) within  the shortest buying time frame ever seen  (5 minutes). Oh, and do it in 2 months with a small scrum team using the client’s systems platform without disrupting other business.

Background: The business comes up with an idea

This was a program that was set in place by eBay as a means to explore promoting sales on weekends with deals that were way lower than were normally made available to the public. These deals would be sourced from various local scale product sellers and manufacturers and negotiated specifically as part of the big Sundays promotion. Once the promotion was in place, eBay decided to promote the campaign directly through TV, email blasts, banner ads and other means. eBay wanted to engage people to keep them coming back by combining the auction concept together with timing and stock. And so the 5 minute deals concept was born: a one hour window on Sundays that posted deals every 5 minutes.

The Think Tank: Prepping business to articulate the vision

If you have short time frames to deliver your project, collating and testing information in the discovery stage prior to development is critical. So what does this look like and who should be involved?
In the early stages of the 5 minutes deals project, the following steps were vital:

• Forming a vision or view of what the system might look like
• Testing the vision
• Ensuring that people would like it

All of this starts by forming a small Think Tank to get the structure together. This team should be comprised of business stakeholders and just a few key technical staff who could vouch for the technical viability of the vision.
Guiding this process was a single document called a product Backbrief, which gave people a sense of what the vision was. This document contained:

• The delivery approach and how it could be built
• The project background, the vision and business goals.
• The personas involved and potential challenges
• Wireframe of what the application might look like in combination with the associated navigation
• Menu structures, site entry points, key attention areas, any assumed responsive actions and an insight into any dynamic or animated areas
• The tangible images that helped readers get a grasp of what is being delivered

And also contained Key business flows, target delivery platforms, and the implementation approach for the project. Our project approach was to follow the S.M.A.R.T principle: Specific, Measurable, Aggressive, Realistic and Time bound.

The war room: Scrum in the Corporate ‘Start-up’
 

 

To deliver a new project in a complex environment involving existing teams, systems, and processes, we formed a ‘mission team’; in our case, we expanded the Think Tank group to a scrum team, which was made up of different specialised experts with a diversity of backgrounds. Large corporations are great places to mine the members of your mission team. Aside from diversity we lay down some rules in our selection and induction to the team:

 

• Coverage: Our aim was to have 99% coverage in the skill set required to deliver the project in the room with broader skills brought in when required
• Size: the team was made up of 6 core people and then there were about 4-6 others who were involved to support the delivery, remove blockers or advise on the architecture.
• Forming to storming quickly: Workshops where everyone had input were conducted. At the end of which the team was mobilised to reach the goals, time frames and objectives
• Units of work: would be decided as a team

 

Once the team was ready, they were allocated a ‘war room’ space which was separate from the rest of eBay’s corporate and IT staff. The space  was compact , short term and ensured that distractions were minimised. The walls were decorated with high fidelity designs, buying personas, project artifacts, PBI, what done looks like and inspirational messaging.
An empowered stakeholder was also sitting with the team so there were no useless untimely meetings and decisions could be made quickly. It was invaluable to have the stakeholder in the room as we were able to test and realign the MVP (minimal viable product) along the way.  Our short delivery time frame required a compressed environment and a tighter sprint rhythm. So we performed 1 week sprints.
 With such an intense driven environment, making time to celebrate little wins was important and was part of our team strategy. Each week we celebrated the end of the sprint, any other key milestones and team wins.

Building on a Building: Using the materials available 

 

In a large corporation, there are useful technology foundations that are extremely relevant in accelerating the development of a new project.  In our case, if these did not exist, then we could not have implemented the 5 minute deals project in 2 months. Using the positives of the large corporation helped us answer questions quickly from the beginning. Need information about the client persona? Marketing has it. Need metrics about the power consumption of your app? There is a team that just looks at that. Security? done.  Using the multiple business units to provide the information you require, that would otherwise be a spike in your development, reduces time to market.
 In order to deliver at this pace, we needed an underlying evolving architecture that takes the complexity out of our decisions and expedites the software delivery process and we needed people within our team who understood how to deploy quickly and effectively to this environment. eBay builds much of its technical stack upon open source foundations, which gives them a head start and the confidence that both they and the community will be focused and engaged in the life cycle of key components.
 
What are the key components to look for in a large corporate infrastructure that help your scrum team?

It is a collection of technology that:

 

• Is integrated and works well together
• Takes care of important decisions like Localization, Resource Management, Configuration Management, Content Management, and Tracking.

 

Raptor JS provided this for us. RaptorJS underpins eBay’s software stack and it was even contributed back to the open source community.  It  is the underlying architecture platform used by eBay to build small applications as well as large and complex applications. It meant that we had a starting point where a lot of the big systems decisions were decided upfront and therefore were not hindrances to our development.




When the software stack choices are already made, as they were at eBay, then plugging into infrastructure as a service and platform as a service technology stacks available help deliver projects of this scale with the agility required. They help take the complexity out of crucial DevOps decisions like redundancy, monitoring, deployment, and of course, scaling. There are less blockers and more functionality such as horizontal scaling which is fundamentally part of the underlying platform as a service. 

 

Do it right: Agile engineering practices and the right tools
Tracking your project and making the progress transparent is very important. We used  JIRA to show us the storyboard at a glance, giving us information on the project’s current sprint and where are we at with our story of continuous meaningful delivery.
JIRA storyboard can also tell us:

 

• How are we tracking
• What the project looks like as a whole
• What percentage of stories are completed, what’s new, and what’s the rate of new story creation vs. resolution
• The estimation accuracy

 

 

Confluence can be a great tool for recording sprint-to-sprint knowledge and sharing project artifacts, such as wireframes, images, links, and sketches.Using Scrum development principles meant the the development in itself is supported by defined processes. We made sure we had preliminary quality checking in the IDE, a shared place to put everything – such as GIT, a continuous automated build of that shared place such as Bamboo, and software quality checks that span the entire project such as Sonar, Findbugs, Checkstyle. Peer code review was  a crucial piece of the quality concept, and increased the visibility and knowledge share within the team.
 Information about repository trends can be extremely valuable when building on top of existing architecture. Metrics we used during the project included:

 

• Release & Build Naming
• Version Trees – Tagging, Branching, Baseline
• Velocity of project code
• Lines of Code metrics
• Commitment metrics
• Project volume & activity
• Code commitment overview
• Historical commitment

 

These helped us visualize over time how big the project was, how much of it had test coverage, how often work was being done.

The Launch = Success. 
 

 

Once the system was built for the 5 minute deals launch, many people eagerly awaited the launch results. On Sunday night, the responsive site counted down and the application launched.There were over 40,000 unique visitors who visited over the hour with roughly 1,000,000 page hits. As a result, over $1,000,000 in products were sold!