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!

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!

Continuous Testing at the Speed of the Agile Modern Business

Relying on automation to execute whole test on large deployment, doesn’t mean the role of the QA engineer is going away. Learn why?

With more companies of all sizes embracing the Agile and DevOps methodologies, the speed of the software development lifecycle continues to increase. This reflects a competitive business world which operates all over the globe on a 24-7 basis. The days of the biannual release cycle appear to be obsolete.

Continuous deployment and other offshoots of Agile strive to make software enhancements a quick and painless process, so it stands to reason this “need for speed” would influence quality assurance. Enter continuous testing. We’ve mentioned this concept in a previous post, but this time out we’ll take a closer look at this emerging QA trend.

Preventing QA from becoming a Bottleneck

Companies embracing continuous delivery leverage automation to make various aspects of the SDLC faster. This includes automating builds, migrations, and other related tasks. While a need for manual software testing still exists, especially when it comes to validating usability and interfaces, companies are taking advantage of automated tests as part of a continuous testing model.

Continuous testing requires extra effort to be spent on developing these automated tests. This concept applies when it comes to determining whether or not to deploy the software into production after the test run is complete. Business stakeholders need to work closely with QA engineers to determine the criteria for a go/no go decision; factoring in performance, reliability, and security issues.

Additionally, many continuous testing programs involve QA personnel at the beginning of the lifecycle, with the hopes of validating design work before development takes place — the extra cost of handling bugs later in the SDLC still matters in this scenario. The scope of testing includes automated API tests, unit tests, as well as system and integration tests. Security and performance testing is also performed when relevant.

Managing the Continuous Testing Process

Relying on automation to execute a whole range of tests as part of a larger build and deployment process doesn’t mean the role of the QA engineer is going away. We mentioned earlier about the importance in properly developing automated tests able to determine whether or not to deploy a release. It is also vital to involve QA personnel in the management of the entire automated testing process, including performance monitoring and defect analysis.

Many QA tools and applications now include support for continuous testing that goes beyond simply automation. These typically provide a robust mechanism for authoring tests in addition to the real-time defect reporting and performance features needed to truly take advantage of CT.

Resources for Learning more about Continuous Testing

A wide range of eBooks and other material covering continuous testing are available if you are interested in learning more about this topic. SOASTA, known for their performance analytics software, offers an eBook on Continuous Testing in an Agile World. IT managers interested in the subject need to check out Parasoft’s book aimed at technology leaders.

In short, continuous testing needs to be considered by any organization hoping to truly take advantage of Agile or DevOps.

Keep tuned to the Betica Blog for further dispatches from the wide world of QA and software development.