There is recent talk about Daily deal sites like Groupon slowing down based on the growing sentiment that the people that buy deals are deal shoppers and not potential long-term business.  So are Groupon-like sites in for some rough waters.  It’s a great question.  There are 2 parties necessary to make the Groupon model work.  Consumers and businesses that offer the deals up via these daily deal sites.  IF its determined that the businesses are not getting the marketing value out of the daily deals, then the cost associated with offer the deeply discounted products or services gets crossed off the marketing plan.  Growth is great for all businesses big and small, but as Groupon recently had to disclose as part of its adjustment to its IPO filing, growing while spending more than you are making to acquire customers might not be a sustainable long term plan.  Its one thing when you are spending investors dollars, but tell that to the mom and pop store selling muffins or the one person acupuncture shop that works for free fulfilling Groupon order for the next month.  Think they will sign up again?  Doubtful.  Asking living social’s communication director if the businesses are happy is pretty comical.  Ask my mom who worked 180 hours and lost money at her spa.  If you mention the word Groupon she might reach for the wooden spoon she used to chase me around the house with as a kid.  How many more moms helped to inflate that valuation?  Millions?

No that shouldn’t be said that all daily deals are dead.  Look at Rue La La or Gilt Group.  Find waste and turn it into products.  And then put time limits on it and let the shoppers fiend for the shirt, dress, shoes, vacation they just couldn’t justify when it hit the stores at full price.  Here you have a never-ending supply of product, a never-ending supply of consumers looking to acquire for what they thought they could never justify buying.  Here the buyers and sellers BOTH win.  And in the end so will this model.

Communities offer huge opportunities for business.  In commerce models, it will be the ones that take into account the long-term value for all the community members that will be successful.  Fool me once, shame on you; fool me twice, shame on me!

Submit to:

I say that a lot. Probably not enough. I’m thinking of getting it tattooed on my forehead. Next time I have a few beers, please keep a leash on me and yank it if i get in the vicinity of a tattoo parlor. For real.

I’ll say it again. The success or failure of a project is wholly dependant on the expectations that you set at the beginning of the project. When you set solid and achievable expectations at the beginning, you’re putting yourself in a position to deliver quality results on time without utilizing more resources than you initially anticipated at the end. Not to mention, you’re in the right position to adapt to any requirement changes that come your way. Also, remember that setting expectations goes both ways. The client or stakeholder needs to be explicit and clear up front with what they want, and you have to make sure that when you agree on a scope, that you’re agreeing to the same thing.

Now before we get into the details, let me just quickly mention that I hate it when people say you can’t scope scrum projects or give real deliverable dates. For shame. It’s thinking like this that keeps people failing left and right using waterfall methods to do their planning. Smarten up.

Here’s the deal. I do this for a living, which means that I’ve had to learn all this nonsense the hard way. We’re 100% agile and our ADEPT™ development methodology is firmly rooted in scrum principles. Save yourself the frustration and heed my words. Every scope that we put together for our clients includes a prioritized component backlog and a sprint delivery schedule that details sprint by sprint, how we’ll get from the beginning of the project to the end. This is key. We are setting a baseline of expectation that says: “for this amount of money, in this amount of time, this is what can be accomplished.”

Why is this important? Because when the client or business stakeholder wants to try and squeeze in something big, you’re able to point to the sprint schedule and ask them to show you where it could fit, thus leaving them with one of three options:

• - Swap the new feature / component with one of comparable size on the schedule
• - Add resources
• - Extend the timeline

If you don’t set this mutually agreed-upon baseline of expectation up front, what you’ll get instead is the following:

“I’m paying you a lot of money, figure it out.”   Thanks.

We actually find that when we set the expectations properly up front, the client is usually the one that’s coming up to us with the solution.

For example:  “I really want to get this component in there, so lets replace it with this other low priority one”.

Or:  “We need to fit this in, so I’m open to adding another resource, and/or expanding the timeline to have it, because its critical for the launch”.

Glorious. This is what you want. If you put yourself in situations where the stakeholders are constantly trying to shove in functionality after the fact, and you have no recourse or baseline to ground them in reality, you’re probably going to miss your date, and end up delivering something that’s less than spectacular when you do. However, when you’ve got a sprint-by-sprint breakdown of exactly what you’re delivering and when, you have successfully flipped the script, and alleviated one of the great headaches of project execution.

Now hopefully at this point, you’re on the bandwagon, and you’re in the right mindset to scope your next project. That’s good, because I’m going to bring it all together for you in the next and final installment of this mini-drama, where I show you how to make a prioritized component backlog and sprint schedule.

Submit to:

Clearly, measuring the coastal wind speed has nothing to do with determining how many resources its going to take to implement a fixed set of features within a fixed time frame.  However, committing yourself to a fixed amount of time and money based upon a supposedly fixed set of requirements that are guaranteed to change isn’t much better.  When dealing with projects that are heavy on the creative, the problem is exaggerated even more.

The problem with Fixed Bid projects is the assumption that cost, time to deliver, and features/deliverables are constant.  For a variety of reasons, requirements are going to change throughout the lifetime of any project.  New requirements, change requests, and overlooked details will add new complexities and complications to every project.  Everyone “knows” this, yet it routinely gets overlooked when the project is being scoped.  This is usually because people aren’t sure how to account for it, and figure they can deal with it later.  In actuality, “dealing with it later” means running your teams ragged trying to meet a date that shouldn’t be feasible, all for a smaller profit margin because you’re using more resources.  Good times.

This is a very solvable problem.  Fixing it turns stressful and tiresome projects into ones that you actually enjoy working on.  If you embrace your variable by planning for changing requirements, you can still provide a fixed cost, with a fixed date.  For real.

Ready for more? Then continue on to Scoping Scrum Projects (Part 2) – Great Expectations.

Submit to:

Smart man, that Aristotle.  What does this have to do with Progressive Development? A lot - because no two development firms are the same, and the good ones are few and far between.  We’ve put an inordinate amount of effort into assembling and choosing our remote teams, because the truth is, the success of any project (technology or otherwise), is directly related to the team’s ability to execute.  Put in simpler terms; bad teams have crap results.

Choosing an outside team for a development project without vetting them first is a lot like buying a used car from a guy in a parking lot.  It might run well for the first couple of months, but sooner or later, its going to break down.  You’ll end up stuck in the middle of nowhere, with no option but to buy another one from some other guy.  At this point it will have cost you twice as much, and have taken you twice as long to get where you’re going (assuming you ever get there).

Since you’re reading this post, you most likely have more than a passing interest in using a progressive hybrid or pure offshore development team.  If you’re ever going to find yourself in a position of picking one (be it us or someone else), I encourage you to take advantage of our experience and read on.  We’ve kissed some toads in the past and learned a few things in the process.

Firms are better than teams of individuals. Believe me.  Communication, trust, and familiarity among team members are essential elements to a development project.  This is pretty hard when they’re scattered around the world, and they all speak different native languages.  Are there situations where this can work?  Sure.  But I wouldn’t bet my job on it.

You get what you pay for. Using a pure off-shore or (even better) a progressive hybrid solution is already going to save you a lot of money over traditional on-shore firms or in house talent.  Don’t poke the bear.  A good firm is going to invest money in training their employees (technology and language), take better care of them through benefits, and provide ample vacation time, good workspaces, and solid infrastructure.  As a result, a good firm is never going to be priced as absurdly low as a guy with a laptop in an internet cafe and a PHP for Dummies book in his backpack.  But, what good is a cheap solution that’s going to take twice as long and deliver something half as good?  You’ll pay for the difference and more, in one way or the other.  Don’t be penny-wise and pound foolish.

Everyone says they’re agile. Few actually practice it.  Even fewer are good at it.  Its not uncommon for a firm to tell you that they employ agile methods, then live and die by the waterfall methodology, which is a recipe for disaster.  Being good at agile doesn’t happen by accident.  Every team leader on our remote teams is a certified scrum master, and every project that we do is fully agile.  We’re constantly learning and refining our process, sprint by sprint.  If a firm says “we can use agile development if you’d like us to”, then they’re just trying to make you happy.  You’re either agile or you’re not.  It’s that simple.

Watch out for one night stands. You want firms that are looking to forge a long term working relationship.  There are plenty of firms out there that will do anything they can to win your business (whether they’re qualified to take on the project or not), squeeze you as much as they can, and then leave you with a mess on your hands.  A good firm will spend enough time up front making sure that the relationship is a good fit.  They’ll ensure that they have the skillsets that you need in house, and that they’re well-equipped to meet your needs in the event that you’ll need to scale up and add more resources.

Evaluate the business. Where there’s good leadership, management, and success, there will be productive and happy teams.   Just because a team has all of the skillsets you’re looking for, doesn’t mean that the team members are going to stick around.  Attrition of your team members can be a big problem – firms going belly up can be an even bigger one.  A well managed business that values their team members and takes care of them is more likely to deliver, and unlikely to implode and disappear.  A good young firm should have at least 100 people, and a consistent (but not outrageous) growth rate.  I personally wouldn’t bet on any that are smaller than that.

Talk to me. Its crucial that you be in constant real-time communication with your team members, over multiple channels, especially when you’re agile.  Using e-mail only is not acceptable.  Phone/Skype is great for scheduled meetings, and instant messaging is crucial for general communications over the course of the day.

This also brings up the issue of time zone.  You may like staying up all night talking to someone that’s coming in when all your friends and family are going to sleep, but you won’t like it for long.  Find a team in a time zone that overlaps your own schedule by at least half of your workday.  Most importantly, they need to know your language (both spoken and written).  You should be able to directly interact over phone or text with anyone on your team and not feel like they’re getting every 10th word.

And last but not least (put on your earmuffs kids)…

Respect your Bullsh*t Meter. Some people will say just about anything to get your money.  You can ask all the right questions, and still get fleeced if you don’t listen carefully to the answers.  Look for any elements of inconsistency.  If someone tells you that they adhere to agile development practices, ask them later on in the conversation how long they usually spend putting together their technical specification document before they start coding.  This is a lot like being at a party and having someone tell you how much they love the movie that you were just talking about, and then later dropping an obvious reference and watching it sail over their head.  Steer clear of these people, and steer clear of these firms.  They’ll say anything to get you to like them.  Don’t be afraid to tune your meter if you’re having trouble identifying them.

All in all, there are a lot of horror stories when it comes to using remote development, and many of them were doomed from the start because the team wasn’t equipped to execute on what they promised.  In the interest of shameless self-promotion, a progressive hybrid model like the one offered by Janeiro is designed to solve this problem, because the resources are known and trusted.

Whatever path you choose, make sure its an informed one.  All development firms are not created equal.

Submit to:

So why hasn’t everyone moved all of their development offshore?

Some have, and some have had success with it.  But, there’s been enough mixed results, and enough horror stories to make you think twice about the risk you’re assuming when handing off your mission critical development to a place far far away.  It’s a shame really, because offshore development does have its place and can work like a charm with the right team, following the right process, managed by the right people.  Sounds simple, but its not so easy to make all those stars align.  Enter Progressive Development.

The whole idea behind Progressive Development is to maximize the benefits of offshore development and squash the risks.  You keep the cost savings and all of innate advantages, like the ability to automatically scale up and down, the access to any skill-set you need for as long or short as you need it – but with the assurance that you’re going to deliver the right solution, on-time.

Now if you’re reading this and shaking your head, then you’re probably one of the unfortunates who’s been burned in the past on an offshore project.  It’s cool – I’m one of them too.  We can have beers.  In fact, were it not for the soul-wrenching experience that was our first offshore development project, we never would’ve pioneered this progressive hybrid model, which has filled my life with joy (and a lot more free time).

Here’s how we do it.  We combine a local on-shore presence, that works face to face with the client and handles all of the technology strategy, architecture, and project management, with trusted remote resources that turn the plan into reality.  Each project starts with a minimum of a CTO (like me), a project manager, and a full-time remote engineer.  As a CTO on a given project, I typically spend a bunch of time up front with the client understanding and (sometimes… usually) challenging the requirements, then helping with everything from architectural decisions to execution planning, etc.  Once we’re ready to rock and roll, we start adding resources.  We handle all of the day-to-day management, and I constantly ensure that the team is delivering something that’s squarely in line with the goals of the customer (especially as requirements adjust).  We use a highly agile, scrum based development model that we’ve tailored to work with offshore resources, and combine it with a pretty awesome local team and an equally awesome and trusted group of remote talent.  So far, the results have spoken for themselves. We’re habitually delivering high-quality results, - ON TIME. Seriously.    :-|

In the next couple of installments, I’ll break down the different parts of the process.  I’ll also talk about some higher level things like scheduling and setting expectations, and anything else I can think of to educate you on our progressive process, while at the same time convincing you that I’m not just blowing smoke up your chimney  ;D

Submit to:

Date: Wednesday, July 7, 2010
Time: 1:00 PM – 2:00 PM EDT

Click here to register!

Space is limited. The first 20 persons registered in the event will receive the book “Software without Borders” by Steve Mezak via mail, all participants will receive an abbreviated e-book version with a discount to purchase it.

If you are interested in learning best outsourcing practices from the leaders of this field, we invite you to attend our webinar: Agile Development from Argentina: Lessons Learned in Nearshore Outsourcing. We will be covering the advantages of using Agile Methodologies in the context of nearshore outsourcing as well as sharing the experience of experts in how to improve your chances of success.

Major Topics:

• How to apply agile methodologies in outsourcing.
• Typical challenges of outsourcing and how to overcome them.
• Pros and cons of Latin America in general and Argentina in particular for software outsourcing.
• How to assess the maturity of potential and current vendors.
• Janeiro Digital’s personal account comparing outsourcing in Bangladesh, China and Argentina.

Speakers:

Steve Mezak is author of Software without Borders and CEO of Accelerance, Inc., a global software development firm with over 20 software development partners in a dozen countries. As a technical entrepreneur and veteran of six Silicon Valley startups, Steve mastered global software development in a variety of management and technical roles, including CTO and CEO with more than 25 years of software development experience. Steve attended UC Berkeley, the City University in London, and holds a BS Degree in Computer Science from Worcester Polytechnic Institute. He continues to serve as an adviser to WPI’s Electrical and Computer Engineering Department. Steve is co-chair of the SDForum Software Architecture and Modeling SIG and member of the IEEE Professional Activities Board IT Committee.

Jonathan Bingham is CEO of Janeiro Digital, a software development firm headquartered in Boston that works with emerging innovation-driven companies and digital marketing services agencies throughout the U.S. Whether creating a new software-based product, a social networking application or a back-end business system, Janeiro Digital provides its clients CTO-level strategic advice, software architecture and design counsel, and project management, and then partners with Belatrix to do the actual software engineering. Jonathan is a serial entrepreneur, having co-founded Intrusic (an enterprise security vendor) and Surrge (an online music service) prior to Janeiro Digital. Previously he was a security technology industry analyst at Forrester Research.

Alex Robbio (Moderator) is the Vice President of Business Development at Belatrix Software Factory. Alex is a Certified Scrum Master and has extensive experience in the software industry including roles as Developer, Architect and Project Manager for important software companies.

After registering you will receive a confirmation email containing information about joining the Webinar.

System Requirements:

PC-based attendees: Windows® 7, Vista, XP, 2003 Server or 2000
Macintosh®-based attendees: Mac OS® X 10.4.11 (Tiger®) or newer

Submit to:

Read the full article: Tips for Picking a Software Development Partner From a Time Zone Focused CEO

Here’s a quick snippet:

Surely you’ve heard someone say that communication is the key to a successful outsourcing relationship. You’ve probably heard it so many times that your cliche alert pops up anytime someone utters the phrase.

But we’re hearing from more and more software-building companies that the best projects are those where there isn’t just good communication but where everyone is working in synch: not just on the same clock but on the same wavelength.

Check it!

Submit to:

The net result was an interesting article that provides great insight into Janeiro Digital’s business model and innate value. Here’s a link to the full article, along with a snippet to give you a taste of what you’re getting yourself into:

Read the Full Article: Janeiro Digital Speedramps Software Development for SMBs

For companies too small or new to have a software development team in place, Janeiro Digital supercharges the process and shortens the cycle with project management and teams already used to working together. Managed services, SaaS, clouds and other third-party offerings offer SMBs a growing range of ways to outsource apps, back-room IT, et cetera. But what if what your company wants to do is create new software, e.g., to run the business better, or as a new business? There’s no shortage of excellent, experienced highly-qualified developers out there eager for full-time, contract or temporary project work. (I’ve got too many friends in this situation, and you probably do, too.)

Holler!

HJDGFM2S38MG

Submit to:

Having been in this world for the last 10 or so years we’ve seen a lot and met some fantastic business people.  Boston is rich with smart people and innovative ideas.  We’ve been fortunate enough to become a sounding board for some of these amazing people as they forge ahead chasing their dreams with nothing but determination, grit, persistence and faith that their idea will revolutionize the way we use the internet in our daily lives.

In the last 4 years, software development has taken a major shift in both process and resource utilization.  The days of 1-year development cycles are over and agile processes are the wave of the future. As for team make up, things have changed.  Stay tuned for some new ways to build and maintain software projects that take advantage of both local expertise and near shore resources to scale project development quickly and get  things out the door!

Submit to: