DevOps and Agile Lessons from the Story of Stone Soup

Saturday, October 17, 2015

I love the old stone soup story. A nifty tale of how hungry travelers with nothing more than a cooking pot, water and a large stone, managed to get curious townsfolk to contribute ingredients to the ‘stone soup’ they were cooking. A wonderful soup, that never quite reached its full potential because it lacked a few essentials. Finally, after the villagers had contributed a missing ingredient, everyone shared a great meal.

Apart from being perfect example of crowd sourcing, stone soup also provides some valuable lessons for agile development and DevOps aspirants.

So if you’re sitting comfortably, let me tell my IT version of the story.

Once upon a time there was a CIO. Our hero was under pressure to feed the business with innovative new applications and services. Undaunted, she decided to shake things up by introducing agile development into the organization. No more long cycle times and infrequent change thinks our CIO, oh no, it’ll be a continuous flow of value to our business from my organization.

And so after spicing things up with a neat sounding workforce transformation initiative, a whole band of agile coaches, and heaps of scrum training, our CIO has all her development teams itching to get cooking. Better still, folks are talking-the-talk with lively discussions around digital disruption, minimum viable products and failing fast. Even her downtrodden development team suddenly feels empowered because they have lots of new cooking utensils for coding, building, configuring, provisioning, testing and releasing.

Life is good thinks our hero, but alas no. Pretty soon business again starts complaining that software systems aren’t being built fast enough. She receives a call from compliance about a release being held up because of serious control breaches, and over in the call center the manager reports that operators are being flooded with complaints about the reliability of a new mobile app.

Now the agile soup isn’t so flavorsome. So where is the problem, asks our glorious leader. “No issues on our watch,” claims the IT Operations manager – “we’re just tired of picking up the pieces after shonky releases, especially when folks on my team are constantly being called in after hours to figure out application outages”.

Over in security the manager’s response is similar – “we’re just doing our job – the last release had to be stopped because the exposures in the new code base were off the charts,” -- adding with a shake of the head – “if only they had called us earlier.”

Suddenly the light goes on for one of the development teams. “What if we involve folks earlier in our ‘agile soup’ making development cycle? What if we accept that while being brilliant chefs and super at cooking apps, we’re lousy at providing complete, secure and reliable services?”

And so the teams start to invite other groups to their soup making IT sessions.

The development teams tells operations that they’re cooking up a new program of work based on microservice style architecture. This includes adopting new programming languages and data stores, plus asynchronous messaging with Restful API’s, but they’re concerned about resilience and performance.

Happy to participate, the Ops team gets involved; collaboratively co-designing a design-for-failure model using automated cloud services. They also provide advice on network latency related issues for distributed architectures and proactively setup management for elements that’s consistent with current unified monitoring best practices.

Over in security, analysts are asked for advice. “We suck at security” admit the development teams. “Can you provide some guidance on the secureability of these new applications and the open source components we’ve been using?”

Again working closely, these teams get down to business. This could involve tracing SQL calls or Java script to detect potential vulnerabilities, mitigating potential new threats with API management software, or perhaps correctly applying some privileged user access policies.

Pretty soon word about the tasty ‘application soup’ starts spreading and more groups want to get involved. The API development team gets valuable insight from the web-app team on how they to use service virtualization and test data management tools to simulate constrained systems and information.

Back in operations the application support group are invited to discuss strategies on establishing monitoring in pre-production to give developer’s early warning into code related defects. Then collaborating further, both teams agree that supportability should be major design consideration; incorporating advanced monitoring and analytics as code is developed and infrastructure provisioned.

Over time many other groups get to add key ingredients to the soup. In heavily regulated industries that could be the compliance team, or in an Internet of Things type project, industrial and plant engineers. Even finance, the call center, IT service team and HR could get involved to improve the business potential, quality, reliability and supportability of new applications.

So with some DevOps style cross-functional collaboration the CIOs agile transformation project starts to deliver what is should – speed and quality at scale.

And the moral of the story – with collective involvement and the power of broader teamwork and contributions, great things can be developed that everyone will value. But just remember that whatever business we cook up from our digital menu, DevOps programs must strive for improvement whenever the gets taste gets bland.

This content is made possible by a guest author, or sponsor; it is not written by and does not necessarily reflect the views of App Developer Magazine's editorial staff.