News from the Worlds of Software Development and QA – November 2016

Welcome to this month’s look at a few interesting news stories from the worlds of Software Development and Quality Assurance. Last month, we covered Microsoft Teams – Redmond’s attempt to enter the enterprise social communication space dominated by Slack. November’s collection of news stories hopefully offers a few insights to apply to your daily work routine.

Without further adieu, here is the news!

Enterprises still struggling with Agile Software Development

An article in ZDNet from mid November takes a look at how enterprises are still finding it difficult to implement Agile as their software development methodology. The story is based off of a recent podcast between Santiago Comella-Dorda, Roberta Fusaro, and Gerard Speksnijder, all from the management consulting firm, McKinsey.

A main cause of problems is the large number of legacy systems in production at most enterprises. This makes it harder for their software project teams to be as nimble as required by Agile. Gerard Speksnijder commented on how this core issue isn’t present at startups or smaller firms.

“(Startups) don’t have the application-architecture legacy. There are no monolith applications. Everything typically is being defined in a pretty modular fashion, with lots of microservices, APIs, which allows you to make changes to the specific component of the application architecture. You can test it and release those features quite fast and without having lots of dependencies on other parts of your application landscape,” said Speksnijder.

The McKinsey analysts feel starting small, and using a product-based model, helps larger companies successfully implement Agile. They recently published a four-point program aimed at bringing Agile to the Enterprise. It is worth a perusal if your larger firm hopes to take advantage of this modern software development methodology.

DevOps is the Key for Success with Agile

Agile is definitely all over the IT news this month. CIO magazine published a piece describing the successful Agile implementation at Fannie Mae. A major factor in their success was an organizational structure based on DevOps.

A commitment to automation and a Continuous Deployment model for software delivery also played an important role. Using a racing metaphor, Fannie Mae CIO Frederic Veron described how DevOps helped his team achieve new benchmarks by doubling its software output over the last 18 months.

“If you do agile without DevOps, it’s like you’re trying to race with a tractor instead of a car. You can go and do the laps but it’s not going to go very fast, you’re probably going to consume a lot of fuel and it won’t be a lot of fun,” commented Veron. A software enhancement that used to take nine months is now fully implemented in 10 weeks using the Agile methodology, automated tools, and a DevOps organizational structure.

Needless to say, large and medium-sized companies need to consider switching to a DevOps structure at the same time they embrace Agile.

Well, this month’s post featured two valuable news stories from the trenches of the corporate software development world, as they try to leverage Agile for the purpose of faster software delivery. Starting with a small pilot program or completely restructuring your organization to a DevOps model raises your chances of success.

Stay tuned to upcoming editions of the Betica Blog for additional news and insights from the evolving world of software development. Thanks for reading.

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!