We are doing it for Endeavor Access. Because it is just a child. Maybe a baby. But when he grow, he will care us like we cared him.

… make light work.

Among the stories to tell about Endeavor Access over the last month, the most exciting, and in my opinion, the most promising is the birth of a budding community to support the project. Just over three weeks ago, Alvarenga put our codebase on github so we could work with a volunteer, David an experienced programmer from Seattle. David has since restructured and added to our code, improving our navbar while separating files to support access for additional volunteers. Beyond grateful, I was inspired by him to see if we can turn this project from a platform built by Endeavor staff to one built and supported by the larger Endeavor community. It will no doubt take both time and commitment, but it appears we have, at the very least, proof of concept. Over the last two weeks, we’ve started to add volunteers to our community, and will hope to feature their work here in the coming weeks.

In sum, thank you David, I hope you are a harbinger of what is to come as Endeavor Access grows. If you, reader, would like to get involved, please email me: peter (dot) olivier (at) endeavor.org, I look forward to hearing from you. We’re looking for help on all ends (front - angular.js - and back - PHP) so don’t hesitate.

_________________________________

… launch coming soon

We’re closing in our beta launch, which means a couple things worthy of note are nearing completion:

Privacy:

• We want people to feel comfortable. Entrepreneurs and mentors will be able to edit what information other network members can see about them.

• We respect the privacy of the business that work with us. Metrics information will be default private, to prevent the undue sharing of important information.

Visibility:

• Appropriate access is key. Finding out the right information about a company or individual before you meet them can save time and enrich conversation. We’re establishing a system so information can be shared with the people closest with you at the user’s discretion.

Sync:

• We want network members to add information to their profiles: their areas of expertise, industry and geographic knowledge, etc. In order to manage this information, we are currently coding a syncing system that will allow staff to intermediate and approve incoming data. Should be done in the coming weeks.

Launch:

• Once we have privacy, visibility, and sync systems operational we’ll be ready to launch our beta. It should be soon, but we’ll say “May” to be safe. Thanks to the beta testers who have signed up, we’re looking forward to hearing from you.

“It sometimes is hard, but possible and rewarding when done.”

- Milton Alvarenga

When we last left you, we were set to kick off our attempts to write directly to salesforce from Endeavor Access. After extraordinary feats of programming by Alvarenga, I’m delighted to say that we can now write directly to Salesforce using their API and a little magic. So where are we in the process now?

Step 1: Read from Salesforce and write to our front end

Check.

This turned out to be harder than we had anticipated, but it works well now. Exciting stuff, but just the tip of the iceberg.

Step 2: Write from our front end to Salesforce

Check.

While we’ve been able to make this work for a little while now, only over the last few days have we been able to make it write in practice - directly from our user interface, not via code. Knowing we can write directly to Salesforce is represents a huge step for Endeavor Access. It enables nearly everything that we want to do; from relevant metrics from candidates and mentors to collecting applications from potential Endeavor Entrepreneurs. 

However, allowing the user to edit our database directly is dangerous - what if they were do delete valuable information by mistake? Without a copy of our information, it would be complicated to track and repair deleted information. As platform moderators, we should be able to intermediate - decide which information gets written to Salesforce, and which doesn’t. 

In sum, we have to build a database. Additionally, we have to have a way for staff to filter changes made by users. Have a look at a mock up of the control panel below. It’s not built yet, but we’ll be started on it soon.

Steps 3 and 4: Write to and read from our server 

Check.

In order to write to our database, we have to first write to our server. We’ve been able to do that for the last couple weeks. So - we can save information to your cache, information will save as long as you don’t sign out. When you sign off, we lose all that data. 

Steps 5 and 6: Write from our server to our database and read from our database

Three-Quarters Check.

In order to sign into our system using LinkedIn, or give access to someone, Alvarenga wrote up a database to save this information. So, in one sense yes - we can write from our front end, through are server, and to our database. However, we haven’t yet closed the loop to write from our database to Salesforce, so we’re still writing direct from the front-end to Salesforce for the time being. 

In sum, we know how to do this, but we would need to code out a bit more before we can use it confidently.

Steps 7 and 8: Write from our database to Salesforce and from Salesforce to our database.

No Check.

We’re not here yet. We’re working on visibility settings, and then this - so it should be coming soon!

Exciting times ahead - when we close the loop and begin to write through our database, we’ll launch beta. We’ll reach out when that happens!

Two quick shout outs:

Thanks to Alvarenga who is battling on his own, and making admirable progress.

Still looking for design interns - more information here. 

More to come soon!

We started our second sprint on January 2nd.

In roughly two weeks - until the 18th - we planned to create a login system, LinkedIn OAuth sign on, emailing systems (to recover passwords and set up key-based logins), database to hold login information, and a test write to Salesforce.

Coming up on the deadline, it looks like we’ll be batting around 70% - which is about right. In review (with clipped shots from the site, misspellings and all):

Login and Emailing system: They’re not pretty - but they work!

OAuth and Database: It’s up! We’re now able to pull from LinkedIn and write to a database. We’ll be using this same database to write to Salesforce as soon as we’re able.

Development Environment and Test Environment:

We’re looking for more help! In hopes of bringing on a few volunteers to help out with the site, we’ve created a development environment so we can share and test code without disrupting the production environment. If you’d like to volunteer, click here for the description.

Over the next two days, we’ll be finished up the above work, pushing the updates to production, and hoping to establish a way to connect user profiles in salesforce, with users in our database.

Next sprint: Write to Salesforce, and proper visibility settings.

“If you wanna a better day, make it!”

- Milton Alvarenga

Before going on Holiday vacation, Alvarenga finished our first sprint. Exciting stuff which I’ll describe in a bit more in detail shortly. But first, the methodology we’re using. 

______________

Agile is what we’re shooting for. Specifically, we’re implementing Agile Scrum. In addition, we’re using trello.com to manage the backlog, which is free, but doesn’t have as many features for progress tracking (burndown charts, etc.) We’re using two week sprints and daily scrums, and, as of right now I think it’s working well (you’d have to confirm with Alvarenga) but I’m sure we’ll change up as things move along.

Useful resources I’ve been exposed to: General Assembly’s Product Management Class, Google’s Design Staff. 

All in all, we’re trying to do this the right way - recommendations more than welcome.

_____________

In our first sprint (December 7th - December 22nd) we focused on:

• Syncing the “Entrepreneur” and “Business” profiles with test qualitative data (i.e. pull information from 20+ locations within our Salesforce instance (fields, objects, related lists, etc.)
• Showing quantitative data stored in Salesforce using Google Charts (as described in the last blog entry.)
• Creating a structure to allow click-throughs to related entrepreneurs and businesses, and a directory function for searching for them based on experience, language, expertise, geography etc.

Thanks to Alvarenga’s hard work - we pulled it off! Look for our post on our second sprint soon.

During a trip to Brazil last week, Alvarenga and I set goals for our first sprint. I’m happy to announce a huge step forward today care of Alvarenga: we’re now pulling dummy data from Salesforce and displaying it through Google Charts.

Why is that exciting? If we can do this, we can display any metric in our database. Data hungry entrepreneurs can see their revenue, jobs and EBIT lines change over time. In the future, this same functionality will allow them to compare key performance indicators with industry standards, aggregated data from Endeavor companies, and even to their own predictions. Moreover, with Google’s dizzying array of charts and dashboards at our disposal, we’ll be able to serve up this data dynamically, with minimal programming time for our tiny team. All that is great news. Better yet, we’re getting closer to a true beta. It should be available in early February, and we can’t wait for your feedback.

What data are you most interested in seeing?

Example here: