Changes in Quality

After seventeen plus years in the tech business I've learned that if you're not adapting to change you're going to be left behind. I can recall no other time in my time recruiting career where this is true then the shift from manual to automated testing.

The speed at which development leaders have moved quality control strategy was staggering. Demand for manual QA dropped to nearly zero while countless "Software Engineer Development in Test" (SDET) jobs are going unfilled.

The catalyst for this change is clear - manual testing was slowing the process down. As engineers are prone to do, someone in a development shop somewhere wrote a program to perform QA functions. Then someone else made that program better. Before you know it Selenium, Cucumber, JMeter, and a slew of other Quality / DevOps tools were born.

If you like be involved in the entire lifecycle, working with business and technical teams to automate processes that facilitate speed in software delivery there is plenty of opportunity in the marketplace.

If your career has largely revolved around manually testing software, take heart. The skills & passion you have translate to other roles within the development lifecycle such as Business Analysis, Project Management, Product Ownership, and Customer Support & Training.

Technology moves pretty fast, if you don't stop and look around once in a while you're going to miss it. -Ferris Bueller

Scrummerfall....

...is now one of my favorite made up words. This interesting mash-up of Scrum and Waterfall was used in a conversation yesterday and it made me smile. It also got me thinking about how many conversations I've had with people about Agile, Scrum and the stories I hear about how these SDLC strategies are being used (and mis-used.)

If an organization is going to 'buy in' to SCRUM there are two fairly critical Agile principles they need to follow:

• "Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done"
• "Business people and developers must work together daily throughout the project."

Sounds good, right? Give business a daily voice in development and give the technical team the resources they need to do the job.

So why can we relate to Scrummerfall?

Let's start with Agile. Like it's predecessor Waterfall, Agile is a general label. It's a foundation that has generated different ideas and styles along with new tools and technologies for delivering software.

Scrum, TDD / BDD / FDD, paired programming and other development strategies fall under the Agile "brand."  Tools such as JIRA & TFS, Selenium & Cucumber, Docker, & CruiseControl are just a handful of the hundreds of platforms available to deliver in an iterative and continuous fashion.

By definition, if they serve the underlying purpose of delivering software efficiently, you can mix and match these strategies. When you boil it all down Agile is simply finding a way for business and technology to work together to find a better way to put usable software to production. 

Scrum & Kanban have been mashed up into Scrumban so why not mash up Scrum and Waterfall? Some would argue DSDM could be branded Scrummerfall.

After all, Agile is not without it's foibles. Fifteen years after the manifesto was written organizations still struggle to implement an Agile strategy that works for everyone. This is especially true in large, established organizations where there are many impediments to large scale Agile adaptation.

Who knows, maybe in the next few years we'll see Scrummerfall (or a variant) pop up on the drop down in TFS. And that's the beauty of Agile.