I’m interested in building great software. Working on beautiful, easy to use products and growing a dedicated fanbase is something that gets me excited. I love digging into the ‘why’ people’s passions and making things better on the fly, as opposed to edifying a master plan of attack from the beginning.

After all, it’s so rare a team really understands what they’re getting into until they actually start building. Having a strong vision is crucial from the beginning, but having a detailed plan often isn’t.

Agile Development: The Theory

In the late ‘90s a group of engineers and software development enthusiasts got together and coined the agile manifesto in the spirit of working toward building great software. A spirit of adventure, learning as you go, and a passion for working together akin to that of a sports team. Since then, a variety of specific development methodologies have branched off of the base agile tenets, but that isn’t in the scope of this post.

The basics are simple. Here are the tenets they penned:

Individuals and interactions over processes and tools,
Working software over comprehensive documentation,
Customer collaboration over contract negotiation,
Responding to change over following a plan,
That is, while there is value in the items on
the right, we value the items on the left more.

Planning for Change

The general sentiment among experts is that teams hardly ever know the entirety of what they want up front, and in the case that they do, there is a near-zero chance that they don’t change their mind over the course of the project.

When projects are scoped out in detail and the development plan is stuck to strictly throughout the project, these projects often fail (remember Windows ME?*). My best guess is that these big-design-up-front style waterfall projects often fail because they resist changing the plan as new information comes to light. They also often don’t budget scope for ideas from customers, engineers building the product, or anyone else on the product team to be implemented.

Through the course of an app’s development, your development team will become intimately in touch with your product. Not having the leeway to implement new features they see to be in line with the product vision seriously limits the upside of working with a team of experts.

The Stadish Group published a comprehensive report on software development operations and found that agile development results in successful software 3x more often than traditional “big design and planning up front” style of development.

Agile Is a Software Development Philosophy.

It’s a general set of values that recognizes the uncertainty and unknowns involved in software development and leverages responsiveness and teamwork to persist in the right direction when things change unexpectedly.

Agile Development: The Practice

An idea that comes closely coupled with agile development is the idea of a lean production process. Specifically – maximizing customer value while minimizing waste. When leading lean teams, my primary focus is to tie everything we do back to the value it creates for the business and how visible it will be to our customers. By helping clients weigh the tradeoff (development effort vs. impact on the customer base), we can move forward as a team in a way that maximizes return on investment.

This isn’t to say agile is an end-all solution.

Starting agile is hard, especially when the team doesn’t have experience with it. One problem we run into from time to time with clients who are more well versed in the traditional, waterfall style development is that we don’t like to write a detailed plan and scope the project to the T ahead of time.

We prefer to set a goal of where we want to be on a certain date based on a general complexity assessment, and hit the ground running with development without wasting time detailing a plan that is undoubtedly going to change.

Agile helps us be truly collaborative in our development process; and unite our team and the client’s team to achieve a common goal.

Agile development is about learning as you go and changing how you work based on new information. If you’d like to discuss agile development some more, reach out to us on Twitter (@teamjackrabbit) or leave a comment below.

Disclosure – I don’t actually know if Microsoft used agile to build that version of Windows or not.