A Quick Look at GROWS Software Development Methodology

First, if you haven't ready Andy's latest blog post (The Failure of Agile) you should give it a read. Also, if you haven't read The Agile Manifesto or it's been awhile, you might really want to read that first.

I can certainly appreciate Andy's position; back in 2001 he and 12 others had this great idea that was going to revolutionize how software is developed, deployed, and delivered to customers. To be fair, it's still a good methodology; and that is really the core of his recent post. Agile principles are good but only when fully implemented. I share in his frustration how Agile became a buzzword and how software managers (and developers) only took the principles they wanted out of the manifesto and ignored the other practices that made Agile stand apart.

This is why I am excited about revisiting the core principles of Agile with Andy's new methodology GROWS, Growing Real-World Oriented Working Software.

The GROWS Methodology

As with other software development analogies, GROWS attempts to bring to the forefront the idea that software is an organic and flexible process that is highly adaptable to changing environmental variables and is a continuous process of betterment (you may contrast this analogy with Steve McConnell's analogy of software as a construction project). What is refreshing about this analogy, and what may be entirely my own extrapolation, is that software does indeed grow over time, it can grow bigger and better, sometimes bigger and not better, and ultimately will have and end of life that gives way to yet another organic growth from the foundations of what came before. The main point however remains that, like Agile, the process is adaptable to change and grows to suit the needs of the client what ever they are.

Later in his post Andy refers to how the individual developers shape the process and how important it is to not only give the more experienced developers room to innovate, but also to allow for time to spend with less experienced developers to develop their skill set. This is obviously a vital element to any development team, but sometimes the "iron-sharpening-iron" gets put aside in lieu of more features and decreasing the timeline. At Cosairus, we are fortunate enough to be able to make the time to bring developers up to speed on new projects and technologies so that we ultimately all benefit from the experience and thus improve the resultant product to our customers. Much the same way code grows, so too must developers.

Another great point that Andy brings out is the "Read-World Oriented" element to the GROWS methodology. There is nothing quite like cold, hard facts to back you up in any situation and software development is no exception. Custom software solutions are tailored like a well-fitting suit and each is unique even if they may appear similar to other applications. As a part of iterative development methodologies, the client feedback loop is essential to the development process, but there is no substitute for data and evidence-driven decisions during design and development. If you are rebuilding an existing application, have you take into consideration the feedback of just the Project Managers or do we have some sort of empirical data on user experience that we can use to design and develop the application? Do we know what features are most used and which are left unused? If we are designing a new application we might want to ask what elements and best practices make applications user-friendly and facilitate rapid development. These are the kinds of questions we need to ask when developing any software, especially if we want to develop a robust application with a long life expectancy. This is the sort of real-world orientation Andy was referring to; that we take a fresh look at what we are developing to ensure that the objects and processes we are attempting to emulate, closely match the objects and processes of their real-world counterparts.

Finally, Andy brings to the foreground principle number one from the Agile manifesto, working software. If "valuable software" wasn't explicit enough, "working software" should make the point crystal clear; we, as software developers, need to deliver working software as a continuous deliverable to our customers. As part of the customer feedback loop, our client and their future users need to be able to test and demo the developed code before receiving the final copy to ensure both that the customer receives the product they are expecting and that it operates how they expect it to. As software developers, we are only experts at writing software. In order to develop an accounting application, we must rely on accounting professionals to help us become "expert-enough" to be able to create a digital representation of their real-world tasks so that the software works as they expect it to. Part of this process is breaking down the components of the objects and the process into smaller partial objects and sub-processes so that the cumulative process can come to fruition once all of the sub components are completed (recursive software development methodology). These partial objects and sub-processes have the ability to be delivered to the customer as they are completed as working software components.

Conclusion

As GROWS continues to generate momentum and as Andy and Jared Richardson continue to release more on the GROWS method, I hope that software managers and developers can continue keep in focus the overarching goals of software development; that is to make working digital representations of real-world processes for our clients in both an efficient and cost-effective manner. Software development is an ever-changing and constantly evolving profession and it is thanks to people like Andy and Jared that we can continue to pursue the forefront of software design and methodology for our customers.

For more information on GROWS, please visit growsmethod.com.