Meshfrog is founded on the belief that Agile Methodologies are generally proven to produce better outcomes than more traditional and rigid methodologies, especially in projects that involve producing or implementing technology at their core.

So what is an Agile Methodology, how is it different, and why is it so important?

What Is It?

An Agile Methodology is a way of approaching, managing, evaluating, and delivering a project (typically a software or technology project) that is predicated on the prioritization of speed, collaboration, flexibility, and delivering in small phases.  This contrasts with the more traditional engineering process that focuses on creating a rigid and perfect plan and then executing to it in spite of the changes and challenges that inevitably arise.

There are many different types or “brands” of Agile Methodologies – with names like SCRUM, XP, DSDM, Crystal, etc. – but at Meshfrog we believe that the specific process brand used is not as important as the distinction between a process and approach that is Agile in nature, versus one that is not.

How Is It Really Different?

In the more traditional model, a software project would begin with a process designed to produce detailed written specifications.  These specs were intended to tell the engineers everything they needed to know about the software they were going to write, and if the software was complex in functionality (and most is) then the specs could take months or even years to complete.  Once the specs were written they would be passed to the engineers who would start writing code to do what the specs said.  Writing the code almost always takes longer than writing the specs, so more months or years would pass. Finally at the end the software would be delivered – months or years after the specs were completed and many more months or years after the project was initially conceived.  Not surprisingly, all research of the last 20 years shows that this model almost never works to the satisfaction of any participant, and in fact 60% to 70% of technology projects were failing according to research from 2002-2006. The key issues cited are almost always the same:

• The software takes so long to conceive and develop that the business has changed significantly in the interim and even if the software matches the spec exactly, the business no longer does.
• Neither the business leaders nor the engineers are satisfied that the spec ever tells the whole story.  But because the specification is to be the final word on the software design and functionality, engineers often make assumptions when faced with decisions during the coding process, and these assumptions vary in accuracy.
• The process makes changes very difficult and expensive to incorporate, and all parties are therefore incentivized to spend huge amounts of time in the specification process (to hopefully make the spec so thorough that later changes are avoided) and to accept the software with shortcomings, or to abandon the project entirely if the inevitable flaws outweigh the benefits, and correcting the issues is deemed too expensive.

An Agile Approach, by contrast, is an explicit attempt to avoid the pitfalls of the more traditional process by establishing different priorities in some very specific ways:

• Complex, thorough, and “perfect” specifications are not an objective in Agile projects.  The process instead strives to create a constant feedback mechanism between the business (leaders and users) and the technology (developers, architects, and IT) so that collaboration can create an ever-evolving specification.
• Rather than seeing change as the enemy of a successful outcome, the Agile process expects change to occur throughout the project, and creates methods of surfacing and reacting to the changes that must occur over time.
• Detailed and rigid project plans, with predetermined phases, milestones priorities are not established up front in an Agile process.  Instead, the first few smaller phases are identified and understood in the context of the business priorities, and the process moves forward with the understanding that priorities and phases will be reevaluated and set as each smaller phase is delivered. A critical result of this is that the most important priority should ALWAYS be the one currently in progress, since each completed phase allows for a priority evaluation before the next is started.
• Beta testing with rapid and frequent user input is encouraged as the best way to keep the project on track, allowing changes, omissions, and insights to surface as quickly and organically as possible.

Why Is This So Important?

At Meshfrog, we apply Agile process and method concepts to everything we do.  We do not rigidly adhere to one specific brand of Agile Process, but we are committed to an approach in all of our consulting and coding activities that incorporates the best Agile practices.  For our clients and prospective clients this means that you can expect:

• Engagements designed to be highly collaborative and iterative.
• Projects that are built on a desire to identify, understand, and incorporate changes as necessary.
• Tremendous flexibility in project scope, length, and terms.