IT Support in Seattle

Enter Your Information Below To

Book a Complimentary Review.

















CyberStreams will never sell or rent your contact information. Your info is secure with us.

Agile Development

What is Agile Development Methodology?

Most of us are familiar with the traditional method of product development in technology (if not brief oversimplification below):

  • Develop concept
  • Develop an Alpha product
  • Conduct internal testing and a few focus groups
  • Develop a Beta product
  • Conduct an open beta where future customers volunteer as testers
  • Release the product
  • & rapidly patch a bunch of issues you missed in the beta

At some point 5 – 7 years out, announce the product is slated for EOL (end-of-life), thus forcing people to upgrade if they haven’t done so already.

(Repeat process again every 3 – 4 years in a “release cycle”)

As systems have become increasingly interdependent on each other, forecasting 3+ years out how software should work in an unknown future (and interdependent on other changing systems) has become a fool’s errand.

As such technology companies are moving to increasingly tighter release cycles. Agile Development facilitates this with a process that is constantly re-assessing goals after small landmarks.

In a very simple sense, the goal is: Anticipating product development as a series of “sprints” followed by “reassessment and testing”, then more “sprints”. (As opposed to running a marathon, then realizing the intended path was 12 miles north, not 26 miles west… whoops!)

Why does Agile Development matter to a small business?

You use these technology products and the same truths don’t necessarily hold anymore.

Not realizing that fact, could burn you.

Let’s take an example:

  1. You want a custom intranet for everyone in your company to interact on.
    (A few examples: Perhaps it centrally communicates info for training your various branch offices. Perhaps it contains a single repository for approving HR requests and complaints. Use your imagination here…)
  2. You decide that rather than program it from the ground up, you want to leverage a content management system to costs low.
    (Examples might be: Joomla, SharePoint, Drupal, etc.)
  3. You also decide that you want to leverage a cloud version, as it pencils out cheaper
    (Sometimes but not always true, let’s just assume in this example it does)
  4. With on premises versions of many of these products, it wasn’t uncommon to code within the application itself. That’s what you are advised to do, and you do exactly that.
    For on premise this makes sense, because you have full control of when patches occur. IF: Patch breaks things, THEN: roll back the patch.

      (In this vein, It isn’t uncommon to run into companies still using the 2001 version of a product because anything newer breaks some customizations they paid a lot for back in 2003)
  5. The site is developing nicely, you start encouraging users to use the site.
  6. Abruptly, the cloud provider pushes through the newest update. Your custom code completely conflicts with the patch.
      A few examples might be: They simplified a naming convention such that all your data calls now pull an error because the location they call to has a different convention for naming. [or] They enhanced security, such that one portion of your code can’t talk to another section of the site anymore.
  7.  Over the next month, you spend 22 hours on the phone with your cloud provider
  8. After a long battle, the final answer is you they give you good advice on how to change your coding so it works with the new structure of the product.
  9. You spend more money on the project, finally launch it again. You are over budget, but at least it is live. 
  10. Users are encouraged to use the site again, but because the first attempt was a train wreck, you really struggle to get people excited about it.
  11. You finally overcome that hurdle, and the following month, things are derailed abruptly when a small patch comes through.
  12. It was easy to fix, but didn’t get done for 3 days, and the outage in the meantime has further derailed employee confidence in the product. You now have people reverting to saving information in random spots they shouldn’t because they hate using the platform.…you then curse the sky. KHAN!!!!

The above issue is really quite simple:

  • For the setup you chose, you do not have control of the release cycle
  • As such, you must assume you cannot control the environment
  • You don’t build things that are expensive on unpredictable ground. (Although there are a lot of people who build houses in 5 year flood plains who evidently don’t agree… that is another stort)

Note that this issue is only getting worse over time, as release cycles keep getting tighter and more companies are embracing Agile Development and other similar methodologies for rapid releases.

How do I adapt?

Option 1: Control the ground

  • Perhaps the public cloud doesn’t make sense for your team now. Consider what is driving the decision. Is it cost? Redundancy? Other options include a dedicated hosting instance (private cloud). Or simply owning you own server environment entirely. There are drawbacks to every option, so make sure you map your decisions to your goals correctly.

Option 2: Leverage developer tools and best practices

  • Most applications being offered within large scale multi-tenant environments, have built ways for developers to work within constraints that won’t break (as often) on update. As an example. SharePoint allows you to develop “Solutions” for SharePoint Online. And yes, sometimes following ‘best practices’ for development can be more expensive. But it is also more expensive to buy land that isn’t in a 5 year flood plain… sometimes it seems like a ‘steal’ for a reason.

Option 3: Don’t customize the environment as much

  • If you really need the cheap public cloud options, as budget is scarce. And you can’t invest enough to do the project right, as budget is scarce. Then just don’t do the project. Firing away with a have cocked underfunded vision is usually a bad idea. Particularly when technology is involved…

Information Technology Glossary

Terms  
3G/4G/5GHardware RedundancyPersonal Cloud
Agile DevelopmentHybrid CloudPrivate Cloud
Big DataIaaSPublic Cloud
BYODInternet of Things (IoT)Redundancy
Cloud StorageISP RedundancySaaS
CybersecurityMobile AppsVirtualization
Geographic RedundancyPaaSWeb Apps

Office 365 Advisors Glossary

Below here we have an additional glossary from our partner site Office 365 Advisors.

Terms  
BlacklistsFederationOffice Pro Plus
BPOSFOPEProvisioning
Cloud ComputingForefrontSaaS
Dial-In ConferencingIntranetService Health
DNSLync OnlineSharePoint Online
Exchange OnlineMigrationSLA
ExtranetOffice 365 PortalWhitelists