Last week we wrote Part 1 of our 2-part series on the role change plays in Modern Software Development. If you haven't read it yet, you can do so here:  Modern Day Software Development: "Making Change Difficult".  

We realize that the only constant in software development is change. Because we have a full and deep understanding the role change plays in the software development process, we have fully embraced another common approach to managing software development: AGILE.

Defining Waste

Dictionary.com defines waste as "a useless consumption or expenditure" or even better "a use without adequate return". There is no better example of that than large upfront requirements gathering efforts with the myth of locking down all requirements early on.  

Companies claiming to be agile espousing this type of methodology are simply being dishonest with themselves and their customers about who and what they are. The simple and honest reality is that all requirements for a software development effort of any substantive size simply cannot be known upfront.  

In an agile world, decisions are made later rather than sooner. The idea behind putting off decision-making until later is that you will have more clarity into what you are building than you do early on. In Lean Software Development, An Agile Toolkit, Mary and Tom Poppendieck describe a concept of waiting until “the last responsible moment” to make decisions. It is at that time that the most data is available to make an informed and educated decision instead of a "guesstimate".  

With that in mind, SilverFern embraces a methodology that breaks a single piece of software into several small functional pieces of software (features) that together make up the end product. We then work toward building each software feature and delivering it to the client "piece by piece", and allowing them to see working software early and often vs. late and all-at-once.

This approach keeps us from breaking out detailed requirements that may never even be built in the long run. Most software developers have seen projects with heavy, upfront requirements phases where as much as 50% of those requirements specified in the beginning never even see the light of day. If that's not waste, we don't know what is!

Change Management

Another common practice for companies not practicing agile is to have large, formal, documentation-heavy change control processes. Software vendors put these processes in place to limit the amount of change clients are allowed once the build effort has begun thereby limiting their risk (and protecting their margins).  

We embrace a process that allows change but makes it visible to the client. What that means in laymen's terms is that we believe in putting our customers in charge of what we build and how much it costs by the decisions we make together.

Close collaboration with our customers is at the core of a successful agile project. Gone are the days when software developers sequester themselves away from the "distraction of customer interaction" so they can get some "real work" done. In the agile model, the customer and the software developer form a new entity….a TEAM dedicated to buildling software. This model is extremely heavy on trust and visibility with the goal of succeeding together.

While change is much easier in an agile world, that doesn't mean it is not visible or that we are not responsible as a team for the decisions we make. When requirements are changing/growing in an agile project, a good software developer will make that visible to their customer. This allows customers to make whatever course corrections are necessary based on their specific constraints (i.e. time, money, specifications).

Conclusion

Every day, more and more companies are realizing that building software is not like other industries. While nailing down requirements like blueprints for a construction project is possible, it's not the best way to build software in today's world.

According to the Standish Report surveys (1994-2009), 68% of software projects are NOT successful (over time, over budget and/or lacking critical features). The software development status quo is not working and does not deserve to be replicated.  

We are here to help you learn why agile makes sense for your next software development project and why developing a long term relationship with us will help meet your custom software needs.

If you have questions about agile, leave a comment on this blog or call us today!