A Look at the Modern Agile Movement

With over 15 years of usage in the software development industry, the Agile methodology continues to mature as its adoption rate grows. We’ve talked about fairly recent innovations, like DevOps, Scaled Retrospectives, and Tribes, as companies transform Agile techniques to make their technology operations run more efficiently.

This time out, our eyes turn towards Modern Agile, an evolution of the original Manifesto, focusing on a simpler process with the hope development teams are able to accomplish more in less time. Maybe implementing some of its principles makes sense at your shop? Let’s check it out.

What is “Modern Agile?”

Modern Agile positions itself as a simpler alternative to the classic Agile methodology. The creators of this movement feel traditional Agile is “drowning in a bloated tangle of enterprise tools, scaling frameworks and questionable certificates that yield more bureaucracy than results.” As such, Modern Agile doesn’t define roles, practices, or related responsibilities, with the hope that simplification returns Agile to the roots that made it popular in the first place.

The Four Guiding Principles of the Modern Agile Movement

Modern Agile’s only true definition comes from its four guiding principles. They are Make People Awesome; Make Safety a Prerequisite; Experiment & Learn Rapidly, and Deliver Value Continuously. Let’s take a closer look at each of these principles.

“Make People Awesome” relates to designing and building software applications with the express purpose of empowering the users of those applications. The development company is also expected to transform its operations based on this principle. Amazon followed a similar concept with their “Customer Obsession” mission when they first started in 1997.

“Make Safety a Prerequisite” raises the issues of quality and safety to a “foundational ingredient for success,” according to the Modern Agile creators. Fear of failure tends to stifle the efficiency of software development teams. Under this principle, attaching blame is never a focus; everyone works together to solve problems. This “safe” environment leads to an overall higher quality level in software delivery.

“Experiment and Learn Rapidly” turns the removal of the fear of failure into a system where experimentation and learning are championed. This is especially vital considering the rapid rate of change in the software industry, with new innovations happening on a monthly basis. Speed is of the essence with experimentation. If an experiment doesn’t work, the developer simply moves on to another idea.

“Deliver Value Continuously” is a key principle for Modern Agile, and is highly relevant for companies with a Continuous Delivery program. The focus is getting value into the client’s hands as quickly as possible. All three other principles of Modern Agile combine to make this final principle possible.

Modern Agile is a relatively new concept and opinions on it are mixed. Some feel it is simply a vague “vapor methodology.” Others feel the concepts are a breath of fresh air, giving a necessary reset to the increasingly bloated Agile movement. Implementing some of the principles as part of a traditional Agile or DevOps program makes perfect sense, especially for companies already doing Continuous Delivery.

Stay tuned to the Betica Blog for additional news and insights from the software development world. As always, thanks for reading!

Monitor API Usage with Runscope

Any company involved in the development of APIs, or even those simply building web or mobile applications dependent on them, benefits from being able to analyze API performance before deployment to production. A tool combining this performance testing functionality with testing and monitoring capabilities offers a full range of features wanted by most software teams. Runscope is just this kind of application.

What follows is an overview of Runscope to help you determine whether it makes sense to add it to your organization’s API testing toolbox. It may just ensure your applications and APIs perform as expected in production.

A Closer Look at Runscope

Runscope is a relatively new product and company. Formed by two software engineers, John Sheehan and Frank Stratton, the initial version of the application became available in the first half of 2013. The primary goal of their API analysis tool involves trusting an API running on a remote server just like it was running on a developer’s local machine.

Runscope Monitoring Features and Functionality

Uptime monitoring of an API – in real-time – is a major selling-point for Runscope. The product promises the engineers responsible for tracking an application in a production environment will know if an API breaks before the client or customer. It integrates with a wide variety of popular notification and messaging apps, including Slack, PagerDuty, email, as well as offering support for webhooks.

An on-premises agent (supporting Linux, OS X, and Windows) allows for the seamless monitoring of private APIs. This is in addition to Runscope’s standard Cloud-based SaaS (located in 12 global data centers) used for public API analysis. The tool includes threshold-based notifications to lower the instance of false positives. 

Real-time performance data helps analyze an API’s response times as well as the ratio of successful calls to failures. Engineers are able to quickly detect any issues requiring closer analysis and debugging. Runscope’s data can be imported into third-party analytical tools, like Keen IO, Datadog, and New Relic Insights.

Additional API Testing Capabilities

Runscope sports other functionality aimed at the testing of APIs. You are able to verify data in the JSON and XML formats, as well as validate HTTP headers and response status codes. Advanced validations are also possible in code using JavaScript and the Chai Assertion Library.

Users are able to create dynamic test scripts for vetting API workflows, without any coding effort. Test plan creation in the Swagger format, among others, offers a more structured level of API QA. Runscope also integrates with Jenkins and other similar tools for organizations leveraging a Continuous Integration release cycle.

Interested customers can test drive Runscope on a free trial basis. Their premium service is structured across three tiers based on the number of API requests and users, with monthly prices ranging from $79 to $599; the higher two levels also include priority support and live chat. There is also a Premier level with additional custom features and extra traffic handling.

In short, Runscope’s full range of API monitoring and testing features, along with its compatibility with industry standard messaging and analytical tools, makes the tool worth checking out at any shop specializing in API development.

Stay tuned to the Betica Blog for additional dispatches and analysis from the software development and QA world. Thanks for reading, as always.

Making Agile work Better with Scaled Retrospectives

The Agile movement continues to mature as companies gain more experience with the software development methodology. We previously talked about the Agile Tribes organizational innovations implemented by the music streaming company, Spotify. In short, it allowed the company to improve their overall efficiency to better meet the goals of the business.

Scaled Retrospectives (or “Scaled Retros”) is another recent Agile innovation aimed at handling the various problems that crop up outside of the normal scope of a development team. Let’s take a closer look at this concept to see if it makes sense implementing it in your shop.

Scaled Retrospectives – What are They?

During any software project – Agile or not – a variety of issues come up impacting a team’s ability to complete a task on time. In an older methodology like the Waterfall, the entire project might be delayed, while in Agile, a Sprint completion date might be missed. Some problems, like a slow developer, are within the team’s area of influence. Scaled Retrospectives, on the other hand, identify any adverse issues happening beyond the team’s control.

The blog, Agile Uprising, identifies Scaled Retros as items meeting three different criteria. First off, the issue is outside the team’s sphere of control. Secondly, it is impeding their ability to complete work in a timely fashion. Finally, the underlying problem is one that needs to be fixed.

Software development shops that implement a process to identify Scaled Retrospectives are seeing a noticeable increase in efficiency provided an effort is also made to deal with the noted problems. Properly cataloging the items and analyzing any patterns affecting an entire enterprise is a key factor in the success of a Scaled Retros program.

The Benefits of a Scaled Retrospectives Program

While a formal Scaled Retros program benefits big development shops with multiple teams, even smaller groups gain an advantage from identifying any large-scale problems impacting the software engineering process. The author of the Agile Uprising blog post noted above describes a scenario where he cataloged retro items from 100 different teams. This quickly became a process that would require a few full-time employees.

Instead of trying to do everything himself, he engaged the different development teams to communicate with each other. Any serious problems affecting everyone in the shop quickly bubbled to the surface. A cataloging effort was still required, but the amount of repetitive data entry and analysis became smaller. This final process allowed a small list of major problems to be delivered to the senior executives able to fix the issue.

The most notable output of their first Scaled Retro process highlighted the need for an automated build server. This issue was identified by 70 percent of the enterprise’s development teams. The voice of a singular programmer carries more weight when combined with many others.

As noted earlier, even smaller shops would benefit from an informal Scaled Retrospectives program. It is especially vital at large businesses where company-wide issues may not be identified without the effort. The most significant point is to realize the importance of finding any large-scale issues impacting the efficiency of your software development teams.

Put Scaled Retrospectives to work for you!

Stay tuned to the Betica Blog for future insights from the worlds of software development and QA. Thanks for reading!