4 best practices to build more perfect software, faster

https://ift.tt/eA8V8J

It’s a truism that the only code that has no bugs is code that has never been written. Working to prevent something from failing even though it’s inevitably going to fail anyway doesn’t solve anything. That kind of brittle approach for perfection does not address the root problem; it just papers over the issue so it can be ignored for the moment.

That’s why many companies turn to an Agile, “fail fast, fail often” approach, which calls for mistakes to be caught and corrected as early as possible. However, what isn’t discussed as much is the organizational culture that needs to be fostered to create a positive environment that encourages a “fail fast” mindset. For any company to be successful in today’s competitive marketplace, it needs to make failure a critical part of their workplace culture and destigmatize this approach. Ultimately, it’s about encouraging teams to bring in new ideas to propel growth and deliver results. 

RELATED ARTICLES:
Reskilling developers for the new software landscape
Empathy drives software experience design

Let’s be clear, a software team isn’t an iteration engine. Teams can’t simply floor the accelerator and expect to endlessly churn out great software without the proper support and processes. The leap from “failing faster” to “going faster” does require the right culture to actually learn and change from the inevitable mistakes, not to mention the right data and insights to inform realistic goals and priorities, and the right technology and tools to get the job done. Time is the most precious resource in the world of modern software, but creating an environment where the need for speed trumps spending time on creativity is counterproductive.

Fortunately, there’s a better way: Don’t just deploy fast, learn how to build software better, faster. 

These four approaches can help your organization fail faster and better on your journey to build more perfect software.

1. Foster a culture of psychological safety
First things first, if you’re going to experiment at a workplace, you need to empower your teams to feel safe and comfortable failing regularly. Studies at Google and other companies show that psychological safety is one of the most important characteristics of fast-moving teams. Simply put, psychological safety happens when teams can take big risks without fear of embarrassment — something that is essential when you’re bringing a new product to market. Treat psychological safety as a key business metric, as important as revenue, cost of sales, or uptime. It will support your team’s effectiveness, productivity, and staff retention, along with other key business metrics.

Recommendation: Emphasize purpose and values, demonstrate humility as a leader, ask questions, work to destigmatize failure.

2. Create a shared reality
To enable an experimental and “fail fast” culture, everyone in the company needs to be deeply aligned with the overarching big-picture strategy. Otherwise, teams will experiment in silos, likely creating organizational friction, and deflect from delivering on priority tasks and overall strategy. A common symptom of a team that isn’t moving as quickly as it could is when product management, design, and engineering aren’t on the same page and don’t understand the other groups’ priorities and challenges.

3. Decentralize (and formalize) decision-making
It’s imperative for leaders to realize that in order to truly encourage experiments, their teams  don’t need to wait for weeks to secure approvals. Delayed decisions defeat the purpose of creating a “fail-often” culture. Every team should be empowered to take calculated risks and have the ability to launch new software quickly, while addressing the needs of their end-customer. 

Understanding how decisions are made helps teams approach the decision-making process with a clearer point of view. Leadership’s responsibility is to establish the rules for decision-making and then empower others to actually make the decisions.

Make no mistake, delivering value in the shortest sustainable lead time requires decentralized decision-making. Not surprisingly, teams get slowed down when they must wait for approval of their decisions. Even worse, handing down decisions from the top limits a team’s ability to improve. 

Recommendation: Adopt a DACI framework within your organization. The DACI decision-making framework is a model designed to improve a team’s effectiveness and velocity on projects, by assigning team members specific roles and responsibilities when it comes to group decisions. The names for these roles and responsibilities form the acronym DACI: Driver (the person who drives the decision), Approver (the person who makes the decision), Contributors (the people or teams whose work or knowledge aid in the project), and Informed (the people whose work might be affected by these decisions and who therefore need to be kept in the loop).

Assign an owner and timeline for decisions to enhance accountability. Also, as Amazon founder Jeff Bezos famously explained, it’s critical to understand the difference between one-way and two-way door decisions. Figuratively, there’s no going back with one-way decisions. While two-way door decisions might feel momentous, with a little time and effort (often a lot less than you think) they can be reversed.

4. Invest in a solid platform
To build a successful “fail fast, fail often” culture, it can’t take upwards of two weeks to build software and get it to production. To begin with, it’s critical that companies have a solid enterprise-grade platform in place that allows teams to conduct quick and frequent experiments. You need to ensure engineering teams are always working on differentiated value for the customer and not just re-implementing the same things over and over again (the same UI widgets, the same services, etc). To ensure teams focus on driving customer value, invest in building the “technical happy path” for your engineering team—which includes creating an artifact of common libraries, services, and deployment options to get code in front of customers as quickly as possible.  

Recommendation: Having a technical happy path helps your engineers build on the shoulders of giants instead of starting from scratch every time they have a new product idea. Access to historical information gives them the agility. 

Find success one failure at a time
The reality of today’s increasingly complex software environments is that system failures and software crashes are virtually inevitable, and not always the worst thing that can happen. In fact,  sometimes they’re not bad at all. There is something much worse that impacts the bottom line adversely: organizational silos, crashes long after the original bug, lack of timely troubleshooting and data inconsistency. 

At least you know where you stand and that you still have work to do. The overarching goal of a fail faster and better approach is to use those inevitable failures as a catalyst for achieving success—learning from each mistake as you consistently, sustainably improve your software, and your business.

Recommendation: The leadership team must understand the company’s long-term goals, department objectives, and key initiatives before passing the shared reality down to the team level. The unified leadership team should encourage trust, create empowerment, and break managers out of the “my department” mentality and into an “our organization” mentality. Breaking down silos requires team managers to buy in to the idea that a free flow of information will help the entire organization. Techniques to make that happen include establishing key objectives and key results framework (OKRs), holding all-hands meetings, emphasizing agile long-term planning, and building cross-functional teams.  

The post 4 best practices to build more perfect software, faster appeared first on SD Times.

Tech Developers