* Based on availability and project scope.
Since this is a newer term in the industry, here’s what it means to us:
We believe that clients should be motivated financially to manage scope and budget. And that we as the software development company should be motivated financially to manage the efficiency of our software-writing process. Traditional models are backwards, with the software company acting as the scope manager or the client trying to keep engineers working in the most efficient way possible.
How do we turn those traditional models upside down? At EduSource, clients pay weekly for a team to complete User Stories on their project. Each week, the client gets a set number of EduPoints to “purchase” User Stories that the engineers work on.
The client is able to make informed decisions about changing scope, because they know that it may add to the project’s timeframe (and thus, affect the budget). And we are motivated to keep our teams operating as efficiently as possible, because we are committing to moving a certain amount of work through our process. If we get behind, our client doesn’t pay for catch-up time.
Both parties are motivated appropriately in this model. It’s a win-win. We call it Agile Contracting.
An EduPoint is a measurement we made up. It is similar to a Story Point, if you are familiar with that term. If you aren’t familiar with it, think of an EduPoint like a token. You get an allotted number of EduPoints, which you use to “purchase” (or start) User Stories for development. The number of EduPoints you get depends on which Project Mode you’re developing in.
In your Discovery Phase, our team will work with you to break your project into specific features. Think of it like this: I need a new car. I want the car to have air conditioning. That’s a feature. I want the car to have four-wheel drive. Again, another feature. In the software world, we call these features “User Stories.” Your software project will consist of a long list of User Stories.
Each week, you’ll meet with your Client Relationship Manager (CRM) to replenish your User Story queue. The meeting can be in person or by phone, whatever fits best in your schedule. You’ll meet with your CRM to decide what new User Stories should be next in line for development. There will be some restrictions (two larges is never a good idea), but your CRM will be able to help you with these choices.
Nope, that’s not how EduPoints work. Each User Story is made up of a set amount of EduPoints, depending on its complexity. Stories range in size from small (which takes only about a day to develop) to large (which takes more than a week). The breakdown is as follows: small (5 EduPoints); medium (8 EduPoints); and large (13 EduPoints).
Sometimes the math won’t work out perfectly. For instance, you might decide that next in line should be two smalls and a medium, but that’s short of your weekly EduPoint mode. Don’t worry—we’re looking for an average of points. Some weeks you’ll pick more than your allotted points and some weeks less. Your Client Relationship Manager (CRM) will help you walk through this process to ensure that your queue will work for the development team.
Once our developers have finished work on a User Story, and it has gone through Code Review, and it has been tested internally (and any needed fixes from any of those stages have been completed), we will transfer the User Story into your User Acceptance Testing (UAT) environment.
When you meet with your Client Relationship Manager (CRM) weekly, she will demo any new User Stories for you, and show you how to complete UAT on them.
During that week, as you have time, you’ll be testing the heck out of the new User Stories. Anything you find will be separated into two categories: bugs and new functionality. When you click on a “Add a New User” button, and nothing happens, that’s a bug. If you decide that you’d like to move the button from the top of the page to the bottom, that’s new functionality.
Bugs will be sent back for re-work under the original User Story. New functionality will be defined by a Business Analyst (BA) and separated into new User Stories (for something like this example, an extra small or 1 EduPoint).
When you sign off on the User Stories at the end of your week of UAT, we consider that work “done.” It’s an important designation, because our goal is always to keep moving forward with your software, and not continue to change things over and over again. That’s also why we need you to set aside time in your week to go through UAT. We don’t want User Stories to be clogging up our system, never getting finished. That’s why we ask that you always complete UAT within a week of getting access to the User Stories.
So does that mean that once something’s done you can’t touch it again? We’ll be encouraging you that way, since we want to keep moving forward. But if you find something that doesn’t work, or you get a much better idea about how to change something, we can always go back and rework. But keep in mind that it will affect your timelines, and thus, your budget.
That’s the million-dollar question of software development. If we could only invent a way to read our clients’ minds and pair that with magic understanding of any curve balls the technology is going to throw at us, we’d be set for the foreseeable future.
Unfortunately, no one can answer that without really diving in. In fact, if a software company gives you a hard estimate without going through a fairly elaborate estimation phase, our advice is to run. The company is either making really big assumptions about your project or is trying too hard to get your business. It’s not going to end well.
That’s why we believe in the necessity of a Discovery Phase. We don’t feel good about asking you to commit the budget necessary to complete a project without really knowing what your company needs. We always start there.
So how do you know if you have even the ballpark of budget necessary for a project? Fill out this form to request a consultation—it’s always free at EduSource. After digging in and getting a general idea of your software needs, we can place your project in a bucket, which will give you a ballpark idea of what size we expect the project to be. That should help you decide if your budget is large enough to make the Discovery Phase worth the cost.
At EduSource, we use Agile methodology. Agile is an umbrella term for several more specific software development methodologies. Books have been written about the topic, but here’s a really basic definition: Agile seeks to incorporate continuous improvement in the software process, compared to a traditional waterfall method, which is known for a sequential design process. In waterfall, there’s no room for change, so a project outcome and extensive plan must be set in the beginning, then followed carefully.
Within Agile, there are two main types of methods: Scrum and Kanban. EduSource uses Kanban, which has an emphasis on continual delivery and a system where work is pulled through the process and changes can be made at any time. Ever heard of Lean Manufacturing, which was first made famous by Toyota? That Just-In-Time method provided the basis for Kanban.
Internally, we also use a system called Daily Layered Accountability (DLA) to make sure our teams are on track for meeting deadlines. Each morning, teams meet to assess certain metrics, including Delivery, Efficiency, and Cost. We are really proud of this system, as it’s solved a problem that custom software companies have been dealing with for decades: completing projects on time. Our DLA metrics are predictive, so they let our teams know that something is in danger of being late before it even is.
So what does EduSource use, as far as software methodology? We use Agile Kanban, with Daily Layered Accountability. Agile and Kanban are known in the industry, but Daily Layered Accountability is something specific to us.
The best answer to that is “usually.” Of course, it depends on what resources are available in the office. To give us the best chance to work this out, try to plan as far ahead as possible. If you know you’ll have a larger weekly budget available in a month, let us know as soon as you know, so we can plan.
We would love to tell you that this won’t ever happen. But that simply isn’t true. We have great faith in our estimating ability, but technology is complex and sometimes still surprises us. More than 95% of the time, your selected User Stories will be completed and ready for you to test within three weeks. Some of them will be finished as early as the next week. EduSource uses sophisticated metrics to ensure that we are on track. (Curious to know more? Ask us!)
Our commitment to you is that if we get too far behind, we’ll let you take a week off your payment schedule, and we’ll use the time to get caught up.
Because we use apprentices for some of our work. We hire computer-science university students during their junior and senior years to work for us. They start working for us in the summer, when they are on-site. During that face-to-face time, they go through extensive training to be ready to serve right on our development teams, along with our full-time software engineers. Once they are back at school, our teams are in contact with these students daily, assigning them work that they complete around their class schedules.
Since our apprentices work at a lower rate than even entry-level software engineers, we are able to provide you with a less-expensive option than many other companies.
Yes! One thing we’ve learned from years of running custom software projects? Communication has to be a top priority.
When development is running super smoothly, it’s easy for software companies to keep heads down programming and go radio silent on the client. In the meantime, the client is thinking, “Did they stop working on my project? Are they just taking my money, but not actually doing anything? Is it going to end up costing WAY more than expected, and they are afraid to tell me? Did they break everything?”
That’s why we now have one person completely devoted to client communication. Not only do we guarantee that we’ll send you a weekly update about how we’re doing, but if you are on one of our project modes, we’ll also have a weekly replenishment meeting and demo. But in the meantime, what if you start feeling stressed and have questions? Just pick up the phone or send off an email to your Client Relationship Manager (CRM). It’ll be a real person you’ve met and know.
That’s the benefit of a small company.
Another note here: while we absolutely want you to meet your development team and even stop by to visit, we don’t encourage you to contact them directly about your software. This is for two reasons. First, we want our developers focused on creating great software for you. Believe it or not, client communication can take up a lot of time. Second, it can just plain get confusing when the CRM thinks the client wants one thing, but then the client contacts the developer and suggests a new idea. Pretty soon we aren’t sure who has the latest news and things get really dicey. But our CRM is always available to make sure you’re happy with what you’re getting.
Definitely! We hope you’ll come meet your team, and they’ll occasionally be on hand during demos.
But also, if you get a hankering to come visit us on a random Tuesday at 10 a.m., you are absolutely welcome. Just so you know, things can be pretty dull around here on Tuesdays at 10. But if you bring donuts, you’ll be instantly popular.