The award recognizes Made in Tandem’s work to modernize San Diego Gas & Electric (SDG&E)’s legacy Emergency Notification System (ENS). Used to notify customers when power lines will be shut off due to wildfire-prone conditions, the ENS had been in place for 10+ years and needed an overhaul. Made in Tandem’s software consultants reimagined the system to create a modern, streamlined solution that empowers the SDG&E team to help their customers when minutes matter.

The American Business Awards are the U.S.A.’s premier business awards program. More than 3,700 nominations were submitted this year for consideration, so Made in Tandem is honored to be recognized alongside other companies transforming applications improving customers’ lives.

More than 300 professionals worldwide participated in the judging process to select this year’s Stevie Award winners. Speaking to Made in Tandem’s nomination, one judge remarked, “Tandem’s efforts in enhancing SDG&E’s emergency notification platform showcase their ability to address complex technical challenges, improve operational efficiency, and contribute to public safety. The solution’s impact on regulatory compliance and risk reduction underscores its significance in emergency response efforts.”

Another judge commented,

The modernization of SDG&E’s emergency notification platform by Tandem represents a significant improvement in the utility’s ability to communicate quickly and effectively with its customers during emergencies. By reducing the notification and reporting process from 37 steps to just ten and integrating seamlessly with existing systems, SDG&E has not only enhanced operational efficiency but also compliance with new regulatory standards.

The dramatic reduction in fines compared to their closest competitor, by a factor of 417, clearly demonstrates the tangible benefits of these upgrades. This project showcases a successful application of technology to meet critical regulatory and community safety needs, making it a valuable initiative where the numbers indeed speak for themselves.

Stevie Awards are conferred in eight programs, collectively receiving more than 12,000 entries each year from organizations in 70+ nations. To learn more about the American Business Awards and see the list of 2024 Stevie winners, visit the Stevie Awards website.

To see the winning video demonstration of how Tandem modernized SDG&E’s ENS software, you can view it on YouTube:

It’s not a surprise then that the discussions in many IT departments center around future-fit software and contemporary application development frameworks. Moreover, there is a special emphasis on the need to understand transformation and modernization within the software development lifecycle and the adoption of modern practices.

Defining Future-Fit Software

Future-fit software brings a customer-centric approach to the foreground, empowering organizations to rapidly modify business structures and capabilities to meet future customer and employee needs with adaptivity, creativity, and resilience.

Swift reconfiguration necessitates a shift in mindset and culture. The outdated belief that significant change is based on a one-time investment of capital, time, and effort needs to be abandoned. For a business to progress towards future readiness and modern application development, it must dispense with this belief and restructure around processes that promote agility and recognize the reality that investment in software will be a continual process.

Future-fit software — whether off-the-shelf or domain-specific and custom built to solve a particular business problem or enable a new workflow — must be considered transformative through evolution rather than with a “big bag” mentality. Software and technology are never “done,” but should be deployed in a way that allows them to grow and flex just as the business does.

The Significance of Application Development for the Business Future

In a nutshell, it is paramount. Today, software embodies the business, and in turn, the business describes the software that supports it. This symbiotic relationship means that altering operational software will modify the business model. And as the business responds to the market, the software will need to follow suit.

As mentioned above, there are also significant and fundamental transformations in the software climate on the horizon, especially in the areas of AI, ML, IoT, User Interface and Experience design, and Web3. This next wave of fundamental shifts will be a forcing factor for many businesses in how they stay relevant with their products, services, and operations.

While numerous companies are still grappling with the aftermath of past technology disruptions, it’s crucial for leadership to transition to modern application development and technology integration sooner rather than later. Competitors will certainly use these emerging technologies and software approaches to their advantage, and so should your business. But first, solid foundations must be laid.

The Harmonious Relationship Between Agile and DevOps

Adopting Agile and DevOps has often posed a challenge. It’s a common misconception that Agile is exclusively for the software group, while DevOps is the responsibility of infrastructure and operations. In reality, Agile and DevOps are two facets of the same principle.

DevOps demands the same mindset, practices, and culture as Agile. An end-to-end transformation with both can dissolve the barrier between business-focused software development and the operations and infrastructure teams that underpin that software. Embracing these twin process domains is a foundational prerequisite to achieving any success in creating future-fit platforms.

Agile imparts the exhilarating experience of steering a high-quality, speedy vehicle. DevOps, on the other hand, provides the necessary infrastructure in a scalable and automated way to ensure fast, secure, and resilient operations and keep customers from encountering poor performance or unreliability.

A critical component of the interplay between agile software development teams and DevOps, including security teams and compliance, is managing the release cycles between all groups. This goes beyond traditional PMO functions, and in complex scenarios requires a dedicated individual or team to manage the intricacies of deploying new functionality to production and accounting for all of the downstream effects on customers, operations, data, reporting, etc.

The Path Towards Modern Application Development

There is no one-size-fits-all path forward, as it will depend on a company’s current status regarding its people, processes, and technology. However, certain principles apply universally:

• Enhancing the connection between IT, business, infrastructure, and operations is vital to fully leverage new technologies.
• Initiate with small-scale projects and minimal investment, then scale as you grow. Avoid integration of a buzzword technology (AI, ML, big data, IoT, microservices, etc) unless you fully understand the implications and the business case you’re solving for. At Tandem we prefer to focus on simpler and proven technologies first and then move toward next-gen technologies as they mature.
• While grassroots-level initiatives can kick-start the process, sweeping success can only be achieved with executive-level support. This is an often overlooked but critical element to success in adopting new technologies and software approaches.
• Recognize that change can often be met with resistance, especially from managers tasked with implementing new procedures. Even with executive support, this can create bottlenecks.
• Clearing these bottlenecks requires effective communication. Understanding that each stakeholder group has unique objectives and concerns is crucial, and communication strategies should be tailored accordingly.
• Celebrate successes and maintain frequent communication.
• Plan for the long term by thinking in layers: weeks/sprints, quarters, years. But be willing to adjust when too much emphasis is placed on short vs. long-term planning and objectives — maintain balance across the field of view.

Additionally, organizations that collaborate with an external partner for new technology implementation tend to stay ahead of the curve compared to those that don’t. Choose your partners wisely and engage them at the ideal time in any new effort. This is usually just beyond the concept phase but before significant effort has gone into detailed planning.

A Case Study in Building Future-Fit Software

San Diego Gas and Electric (SDG&E), a subsidiary of Sempra Energy, is a regulated public utility provider that serves 3.7 million homes and businesses in San Diego and southern Orange county. After the 2018 fire season, the California Public Utility Commission and Office of Emergency Services imposed new regulations to reduce future fire risk, including more robust guidelines around customer notification and post-event reporting.

Ultimately, SDG&E’s manual reporting systems were no longer going to be feasible to meet their community’s needs. They engaged Tandem to extend their existing mass-notification system by better integrating it with other legacy systems and creating a long-term roadmap for process improvements that enabled the product to flex with future changes in their internal infrastructure, grid equipment, and regulatory changes – making the back-end systems future-fit for years to come.

Tandem used a purpose built design system to create an intuitive user experience and information radiator for their emergency operations center, another future-fit component that allows rapid changes to the UI/UX. This upgrade minimized confusion and complexity. Employees can now see critical facilities and communities affected by outages at a glance and onboard new employees faster. We also simplified the notification and reporting process from 37 steps to 10, enabling the SDG&E team to inform their most at-risk customers when minutes matter.

Our team created a custom deployment process for SDG&E that was fully tailored to their system and configurations, and integrated to work with eight existing critical applications within their organization. These integrations use an architecture that allows SDG&E to continue to expand their software, making it flexible enough to fit all of their needs and enable them to stay agile.

Most importantly, the refreshed application means SDG&E has been able to adapt quickly to the latest reporting regulations, leading to them facing far fewer fines — in 2022, their closest competitor was charged 417 times the fine amounts.

In conclusion, modern application development and future-fit technology are driving forces behind successful, resilient businesses. By embracing these advancements, companies can ensure they are well-equipped to meet and exceed the evolving needs of their customers, employees, and industry standards.

Is your software future-fit? Let’s chat about how Made in Tandem can make your product more resilient than ever.  

The Cloud Awards has recognized and honored innovation in cloud computing since 2011, spanning diverse industry sectors and welcoming submissions from organizations across the globe.

Tandem’s nomination specifically showcased the work done to modernize MIRS, the MEPCOM (Military Entrance Processing Command) Integrated Resource System, a software system used to track U.S. military applicants during their enlistment process. Hundreds of organizations entered the 2023-2024 Cloud Awards program, so Tandem is honored to be recognized as a winner alongside other innovators in the cloud computing space.

Speaking to Tandem’s application, lead judge for the Best Cloud Migration or Systems Integration Solution category Manju Sughaturu Krishnappa said:

This AWS GovCloud migration project is executed with a high degree of competence, addressing the unique challenges and requirements of government environments. The enhanced security measures and regulatory compliance achieved during the migration underscore the commitment to data protection and integrity. Congratulations from everyone at The Cloud Awards.

To learn more about the awards program and view the full list of winners, visit the Cloud Awards website. Check out this video demonstration to see how Tandem modernized the MIRS application:

The Advantages of Microservices

Microservice architecture is a method of building applications as a suite of small, independently deployable services. These services are structured around business functions and interact with each other through APIs and message queues. This architectural style offers several key benefits:

Independent Scalability

Microservices are designed to be deployed and scaled independently. This means that organizations can easily scale up or down individual services as required to manage changes in traffic or workload. This contrasts with a monolithic architecture, where scaling often involves scaling the entire application, which can be expensive and often has an upper speed limit that can be difficult to break through.

Adaptability

Microservices allow teams to work on individual services independently, making it easier to implement new features and make modifications without impacting the entire application. This adaptability also enables teams to adopt a more agile approach to software development, allowing them to quickly respond to customer needs.

High Dependability and Fault Isolation

Microservices are designed to operate independently, meaning a failure in one service won’t necessarily cause the entire application to fail (though some care must be taken on the consumer side of a service to implement this kind of tolerance). This results in more robust applications that can withstand failures in individual services.
Microservices are made up of modular services, making it easier to understand how each service contributes to the overall application. This modularity can improve the maintainability of the application, as developers can easily identify and fix issues without disrupting the overall application.

Reusability

In a microservice architecture, organizations can easily reuse individual services across multiple applications and use cases. This can save time and resources, resulting in faster time-to-market and ensuring consistency and standardization across different applications and use cases.

The Disadvantages of Microservices

While a microservices architecture has many benefits, it’s important to acknowledge the drawbacks:

Complexity

Microservices architecture can be more complex to design, build, and operate than monolithic architectures. Managing multiple services, APIs, and data stores can require additional tooling and operational overhead, increasing the overall effort of running a system. This complexity also comes into play when handling the change management overhead of introducing breaking changes or updates to individual services.

Latency

In a microservices architecture, each service is typically deployed independently and communicates with other services over the network. This can introduce additional latency, as data needs to be transmitted over the network and processed by each service. As a result, slower response times and reduced performance can occur. Careful attention should be paid to caching strategies and performance monitoring to overcome latency issues.

Integration Challenges

Integrating multiple services can be more challenging in microservices architecture, especially when dealing with legacy systems or services that don’t support modern APIs and protocols. This can require additional integration infrastructure and tooling, which can increase complexity and effort. As microservices are deployed, careful attention to program management should be taken to address such challenges.

The Future of Microservices

The future of microservices is likely to be shaped by several emerging technologies and trends, particularly serverless computing. Serverless computing is a cloud computing model in which the cloud provider manages the infrastructure and automatically allocates resources as needed. It’s an event-driven architecture whereby developers write code in the form of functions, which are triggered by events and executed in a stateless environment.

However, it’s important to note that the two architectures aren’t mutually exclusive, and organizations may choose to use one or even both approaches depending on their needs. When combined, microservices are used to break down applications into smaller manageable components, while serverless technology can be used to manage the execution and scaling of these components.

Wrapping Up

Despite all the social media hype that “microservices are dead,” the approach is far from obsolete and continues to be a practical approach for many enterprises. However, it’s crucial to weigh the architecture’s potential drawbacks and the nature of your projects before making your decision.

Technologies such as serverless computing and Kubernetes may influence the future of microservices, and organizations should stay abreast of these developments to make informed decisions about their system architecture strategy.

While microservices can offer many benefits, they may not be the best approach for all applications. For smaller applications, using the microservice architecture might be excessive. A simple monolithic architecture will suffice, as it doesn’t require the additional complexity and maintenance overhead that microservices can introduce.

It’s also important to remember that replacing a large, unstructured system with distributed smaller, unstructured systems will only exacerbate the problem. You will soon face a project to revert back to the monolithic system. Unfortunately, organizations that pursue smaller, unstructured systems often blame microservices rather than their poor architectural decisions.

To quote the original Amazon blog, “Microservices and serverless components are tools that do work at high scale, but whether to use them over monolith has to be made on a case-by-case basis.” And, the menu of approaches: microservices, monoliths, serverless/stateless, messaging, etc can all play a role in a robust systems architecture when employed wisely.

In the end, architecture is about delivering business outcomes. Start with the desired outcomes before discussing technical design. Don’t just blindly follow trends without understanding them. Understand how an architecture adds value and its trade-offs. Know your desired business outcomes and how an architecture aligns (or doesn’t) to those outcomes. Be clear about how your IT organizational structure is aligned (or misaligned) with your business design. Most important of all, never forget: Employing microservices for microservices’ sake won’t make up for poor coupling and cohesion decisions.

Three Signs that Your Organization’s Data is Locked in Silos

1. Relying on low-maturity, self-created tools and spreadsheets

If your organization is still depending on self-created tools and spreadsheets, it’s time to adopt a product mindset for data. This means making data ownable, discoverable, traceable, and trusted, moving away from restrictive self-created solutions and towards extracting business value from your data in a holistic, organization-wide manner.

2. Slow access to data, hindering market value realization

Data silos render data inaccessible, leading to missed opportunities and operational inefficiencies. Data-as-a-product thinking addresses this issue by building semantic layers into your data and transforming how it is accessed. This enables speed and flexibility across all business domains, allowing everyone to access the data they need when they need it.

3. Disconnect between business and IT, resulting in a lack of data culture

Silos often form when people are left to find their own solutions, creating a lack of collaboration and introducing productivity barriers that hinder growth. By adopting an agile, bottom-up-and-top-down approach to data strategy, your organization can instill a data-driven culture that connects departments and domains, breaking down silos and unlocking the true value stored in organizational data.

Some Steps to Release the Hidden Potential in Your Company’s Data

Cultivate a data-driven culture

Instill a data-driven culture by encouraging data literacy and promoting data usage across all levels of your organization. This includes providing training and resources to help employees understand the importance of data, the principles of data analysis, and the tools and techniques used to extract insights from data. By empowering your workforce with data skills, they can make more informed decisions, identify opportunities for improvement, and contribute to the overall success of your organization.

An essential part of developing a data-driven culture is promoting collaboration between business and IT and developing a shared vision for data-driven success. Hold workshops and brainstorming sessions to facilitate open discussions between business and IT stakeholders, encouraging them to share their unique perspectives, challenges, and goals. These sessions can help to align priorities and foster a shared understanding of the organization’s data objectives.

Another effective way to promote collaboration is by implementing cross-functional teams, where business and IT professionals work together on data-related projects. This approach encourages knowledge sharing and ensures that both technical and business perspectives are considered throughout the project lifecycle. As a result, data solutions are more likely to meet the needs of end-users and drive tangible business outcomes.

Take a Data-as-a-Product (DaaP) approach

A DaaP approach emphasizes making data accessible, accurate, and actionable for everyone in your organization. By building domain-specific semantic layers and creating an accessible data marketplace, you can enable speed and flexibility across all business domains.

The semantic layers sit between the raw, structured data stored in databases and other data stores and the end-users interacting with that data. These layers translate the technical, database languages into a more user-friendly, business-oriented language and serves several critical functions such as:

1. Simplifying data complexity: It presents complex data in an easy-to-understand format, making it accessible for non-technical users. This means that users don’t need to know SQL or other database languages to extract insights from the data.
2. Ensuring data consistency: It provides a unified and consistent view of data across the organization, which is essential for accurate reporting and analysis.
3. Promoting self-service analytics: By making data more understandable and accessible, the semantic layer empowers end-users to conduct their analyses and generate reports, fostering a data-driven culture within the organization.
4. Enhancing data security: The semantic layer can also control data access, ensuring that users only see data that they are authorized to view.

Invest in the right tools and technologies

While technology alone is not the solution, the right tools and technologies can play a crucial role in breaking down data silos. When investing in tools and technologies for data management and analytics, you should consider a range of solutions that cover data integration, data storage, data analysis, and data visualization. Here are some categories of tools and technologies you might consider:

1. Data Integration Tools: These tools help to bring together data from various sources, ensuring that it’s consistent and accessible. Examples include ETL (Extract, Transform, Load) tools like Informatica, Talend, and Microsoft SQL Server Integration Services (SSIS). These tools add value by creating a unified view of your data, making it easier to analyze and gain insights.
2. Data Storage and Management Systems: These systems are used for storing, retrieving, and managing data. They include traditional relational database management systems (RDBMS) like PostgreSQL, MySQL, and Microsoft SQL Server, as well as NoSQL databases like MongoDB and Cassandra, and data warehousing solutions like Amazon Redshift and Google BigQuery. These tools are critical for ensuring data is stored securely and can be accessed and managed efficiently.
3. Data Analysis Tools: Data analysis tools allow you to manipulate and analyze your data to extract insights. This category includes statistical analysis systems (SAS), like R and Python, and business intelligence (BI) tools like Tableau, Microsoft Power BI, and Looker. These tools help businesses make informed decisions by providing insights into trends, patterns, and correlations in their data.
4. Data Visualization Tools: These tools help to present data in a visually engaging and easily digestible format. They are often part of BI platforms (like Tableau and Power BI) but also standalone tools like D3.js exist. Visualization tools are crucial for communicating data insights effectively, as they allow users to see patterns and trends that might not be apparent in raw data.
5. Data Governance Tools: Data governance tools help organizations manage their data assets, ensuring they remain high-quality, consistent, and secure. They can help with cataloging data, maintaining metadata, ensuring data privacy compliance, and more. Examples include Collibra and Alation. These tools add value by improving trust in data and ensuring compliance with data regulations.
6. Machine Learning / AI Tools: These tools, like TensorFlow, H2O.ai, and RapidMiner (along with a rapidly expanding set of tools), allow businesses to apply machine learning algorithms to their data to make predictions, automate decision-making, and more. These tools can provide a significant competitive advantage by enabling predictive analytics and other advanced data analysis techniques.

Each of these tools can play a critical role in a comprehensive data strategy, helping to ensure that your data is accessible, reliable, and actionable. The right mix of tools will depend on your specific needs and goals, but in general, a robust data infrastructure will include solutions from each of these categories.

Breaking down data silos and unlocking the hidden potential in your organization’s data requires a shift in culture, strategy, and technology. Don’t let data silos hold your organization back.

If you’re looking for help unleashing the full potential of your data, please reach out and we’ll have one of our data specialists get back to you for a brainstorming session on how we can help.

As industries across the board embrace digital transformation, the demand for software engineering talent is growing in every sector, including finance, healthcare, e-commerce, and government. Companies are looking for professionals who possess a deep understanding of programming languages, system architecture, and agile methodologies. Not only does this surge in demand signify the critical role software engineering plays in modern business, but it also presents abundant opportunities for successful partnerships in this dynamic and ever-evolving field.

Choosing the right software professionals for your needs is important: Their expertise will have a significant impact on the success of your projects. The right professional has both the necessary technical skills and a deep understanding of your specific industry and business goals. They can analyze your requirements, offer tailored solutions, and deliver results that align with your objectives. Making the wrong choice can lead to costly setbacks, inefficient workflows, and missed opportunities. By investing time and effort into selecting the right software professionals, you ensure that your projects are executed well — enabling your business to thrive in the digital landscape.

In the world of software engineering, the decision between hiring a contractor or a consultant can be a pivotal one for businesses and organizations. What’s the difference between the two? In this blog post, we will delve into the key characteristics and considerations when choosing between these two types of software professionals, including factors such as project duration, cost, expertise, and project management requirements.

Contractors

A software engineering contractor is usually hired to just get the job done. They are hired on a temporary or short-term basis to provide specialized skills and expertise. These contractors can be self-employed or work as part of a contracting firm, and they are engaged by organizations to fulfill specific technical requirements. The role of a software engineering contractor involves working with clients to understand their project needs, developing software solutions, and delivering high-quality code within the agreed-upon timeline.

Contractors often bring experience in various programming languages, frameworks, and development methodologies. They can be responsible for tasks such as software design, programming, testing, and debugging. The primary advantage of hiring software engineering contractors is the flexibility they offer in scaling resources and expertise according to project demands — making them a cost-effective option for short-term or specialized projects.

“Tandem recognizes the importance of staying ahead in a rapidly evolving landscape. We use contractors in specific cases when we need a niche skillset that’s very targeted (think some obscure plugin for an ERP or an outdated technology). From a business standpoint, it doesn’t make sense financially for us to learn some technologies. We also tend to use contractors when we have a well defined and decomposed system and just need folks to execute but not provide advice on architecture, process, technology selection, product decisions — those are what true consultants are good at.” –JC Grubbs, CEO of Tandem

When hiring a software engineering contractor, here are a few important considerations to keep in mind:

1. Clearly define project requirements: Before engaging a contractor, ensure that you have a clear understanding of your project’s scope, objectives, and deliverables. Clearly communicate these requirements to the contractor to confirm alignment from the start.
2. Evaluate technical expertise: Assess the contractor’s technical skills and knowledge of programming languages, frameworks, and tools relevant to your project. Review their past projects and references to gauge their proficiency and suitability for your specific needs.
3. Assess communication and collaboration abilities: Effective communication is crucial for successful collaboration. Evaluate the contractor’s communication skills, responsiveness, and ability to work as part of a team. Clear and frequent communication channels are essential to ensure project progress and timely updates.
4. Consider cultural fit: Assess how well the contractor’s working style aligns with your organization’s culture and values. A good cultural fit can enhance collaboration and productivity, leading to a smoother working relationship.
5. Manage and oversee the work: While contractors work independently, it’s essential to have a client partner or point of contact within your organization who can provide guidance, clarify requirements, and oversee the progress and work delivered by the contractor.

By considering these factors, you can increase the likelihood of hiring a software engineering contractor who is well-suited to your project’s needs and who can contribute effectively to its successful completion.

Consultants

The primary focus of a software engineer consultant is to help organizations make informed decisions related to their software engineering practices and projects. They act as a trusted advisor, driving innovation by assisting with tasks like:

• software project planning
• technology selection
• software architecture design process optimization, and
• implementation strategies

The role of a consultant goes beyond hands-on coding and development — Tandem consultants work closely with clients to understand their business objectives, analyze existing systems and processes, identify areas for improvement, and provide recommendations for optimized software solutions. Consultants bring a fresh perspective, drawing from their broad industry experience and exposure to different software development methodologies and tools. By engaging a software engineering consultancy like Tandem, companies can leverage external expertise, optimize their software development processes, and achieve their project goals more efficiently.

Not only does hiring a software engineer consultant allow companies to tap into specialized skills and knowledge while focusing on their core business objectives, but this approach also brings several advantages to organizations:

1. Expertise and Industry Knowledge: Software engineer consultants possess extensive expertise and deep industry knowledge. They stay up-to-date with the latest software engineering trends, best practices, and emerging technologies. Their insights and experience can help organizations make informed decisions and stay ahead of the curve in a rapidly evolving technology landscape.
2. Strategic Guidance: Consultants provide strategic guidance tailored to the specific needs of the organization. They can assess existing software systems, identify areas for improvement, and offer recommendations for optimizing processes, enhancing efficiency, and achieving business goals. Their strategic input helps align software engineering efforts with the organization’s overall objectives, driving organizational growth.
3. Problem-Solving Capabilities: Consultants are skilled problem solvers. They excel at analyzing complex technical challenges and finding effective, long-term solutions. They bring fresh perspectives to address software engineering problems and can help overcome obstacles or bottlenecks that may hinder project progress.
4. Objective Perspective: Being external to the organization, software engineer consultants can provide an objective viewpoint. They are not influenced by internal politics or biases and can offer unbiased assessments and recommendations. This objectivity can lead to more accurate evaluations and better decision-making,
5. Mentoring and Skill Development: Consultants often play a mentoring role, sharing their knowledge and expertise with internal teams. They can:This knowledge transfer contributes to long-term skill development and increased team efficiency.
   • guide and mentor developers
   • conduct code reviews
   • offer training sessions
   • help them enhance their technical skills
   • advise on how to adopt best practices, and
   • improve the quality and efficiency of software development within the organization.
6. Cost and Time Efficiency: Hiring a software engineer consultant can be cost-effective compared to hiring a full-time employee with similar expertise. Organizations can engage consultants for specific projects or duration, avoiding long-term overhead costs. Additionally, consultants bring specialized skills and experience, allowing them to work efficiently and deliver results within shorter timeframes.

By utilizing the benefits of a software engineer consultant, organizations can tap into valuable expertise, receive strategic guidance, and speed up their software engineering efforts, leading to improved efficiency, innovation, and competitive advantage.

“Contractors are individuals hired for specific tasks, adhering strictly to predefined plans. While effective, their role is limited to execution. In contrast, consultants provide a broader range of services. They not only execute tasks according to a plan but also contribute to establishing team culture and implementing best practices. Consultants like Tandem offer valuable insights in refining project plans, going beyond execution to help shape and optimize strategies for success.” –Sergio Rabiela, SVP of Technology at Beyond Finance

While the ROI of hiring a software engineering contractor versus a consultant may not always be easily quantifiable, it is important to consider the specific objectives, timeline, and complexity of the project. Evaluating the potential benefits, cost savings, and long-term value of each option can help determine the best choice for a given project.

By understanding the nuances and unique value propositions of software contractors and consultants, stakeholders can make more informed decisions and select the most suitable option for their software engineering needs.

If you’re curious to learn more about Tandem’s implementation of these strategies, we encourage you to visit our Beyond Finance case study, where you can find extensive information and insights.

Succeed as a Team and Fail as a Team

In a resilient organization, teams and managers prioritize problem-solving and prevention over assigning blame when issues arise. Encouraging a culture where team members feel safe to expose vulnerabilities, weaknesses, and even individual mistakes is essential for building stronger, more resilient software and technology organizations. Celebrating those who identify these areas for improvement fosters a positive environment that prioritizes resilience.

A blame-free culture also encourages open communication and transparency, facilitating faster problem resolution and improving overall system stability. When team members are empowered to discuss issues and work together to find solutions, it creates a stronger sense of ownership and responsibility.

Listen to Your Metrics, They Don’t Lie

Resilient teams use metrics to measure their performance and identify areas for improvement. By closely monitoring incidents they created or those with recurring root causes, teams learn from their mistakes and work towards developing more resilient solutions.

Metrics can include system uptime, incident response time, mean time to recovery (MTTR), and mean time between failures (MTBF) – as well as any industry or domain-specific metrics that affect the business or operations. By analyzing these metrics, teams can identify trends, weaknesses, and areas for improvement. Regularly reviewing and adjusting metrics ensures that teams are always working towards greater resilience.

Tabletop Exercises Help to Play the Tape Forward

Preparing for potential problems is a critical aspect of building resilience. Teams should practice their response to complete system outages, severe scaling problems, or the impact of losing access to a dependency, starting with individual applications and moving up to entire services. This iterative process helps teams become more adept at handling crises when they occur.

Outage rehearsals can involve tabletop exercises, simulations, or even real-life drills. By practicing their response to various scenarios, teams can identify gaps in their plans and make adjustments to improve their resilience. Additionally, rehearsing the outage helps teams better understand their dependencies and interconnections, which can be critical in a crisis. Lastly, it creates a shared responsibility for reliability and incident response, building the team’s confidence in their capacity to address such challenges.

Ruthlessly Prioritize your Systems, Services, and Applications

It is crucial to recognize that not all business services and applications require the same level of resilience. Organizations should first identify their most critical services, which are essential for meeting obligations to customers, business partners, regulators, and operational users. By understanding the technology landscape and the dependencies and interconnections between applications and systems, organizations can assess their current resilience levels and prioritize improvements and the order of operations during a crisis accordingly.

Establishing a clear hierarchy of critical services helps organizations allocate resources more effectively and ensures that the most important systems receive the attention they need. This prioritization also informs decisions about backup and recovery strategies, redundancy, investment in infrastructure, and potential temporary alternatives during an outage event.

Measure Resilience Continually

Evaluating existing technology resilience is the next step. Organizations should assess their maturity on an S-curve, examining whether they possess resilient system architecture and software across the stages of a typical outage or service degradation event. Such an assessment may be different for the particulars of your organization but in general the following questions should be answerable on a continuous basis:

• Fault Detection: How quickly can infrastructure or operations teams identify that a fault or outage has occurred? Are the ideal tools in place for notification of such errors to be sent to the correct individuals or teams to handle the issue?
• Triage and Resistance: How long does it take to identify the root cause of issues? How available are mitigating measures to resist catastrophic outcomes such as lost revenue, lost data, etc?
• Response: Does your average response time meet expectations? When a response is necessary is it to pull the system back from the brink or is it an adjustment that allows a speedy recovery?
• Recovery: When a response has been implemented, how quickly does the overall system (or network of systems) take to fully recover? Does your infrastructure support rapid deployment of fixes?
• Restoration: Once restored, are there frequently after-event issues to be resolved, such as ensuring data integrity? Does the team refactor any quick fixes to be more stable over the long-term? What does your post-mortem review process look like and is it effective?

The most mature organizations incorporate technology resilience into application and system architecture by design. In deployment and operations, resilient operations should consider not only operational contingencies but also the root cause of incidents that arise during business as usual to improve procedures, training, and technology solutions. Monitoring and validation involve reactive or backward-looking metrics at lower maturity levels. At higher maturity levels, organizations shift to proactive measures to look for early indicators of resilience issues and test responses and contingency plans for the most likely eventualities.

Reviewing and Learning from Past Incidents

In addition to assessing the current level of resilience, organizations should analyze past technology-related incidents to uncover common factors that can be addressed to improve resilience. This process involves reviewing incident reports, logs, and other documentation, as well as interviewing those involved in the incident and response. By conducting a thorough review of past incidents, organizations can identify trends and patterns that may indicate areas of weakness or vulnerability.

When analyzing past crises, it is essential to consider both internal and external factors. Internal factors may include outdated systems, insufficient training, or a lack of standard operating procedures. External factors could involve supply chain disruptions, natural disasters, or cyberattacks.

Understanding the full context of past crises helps organizations develop more comprehensive resilience strategies. Moreover, learning from past incidents enables organizations to implement necessary changes, improve their overall resilience, and be better prepared for future challenges. This proactive approach to reviewing and learning from past crises is a vital component of building a resilient organization.

Cross-Functional Remediation

After identifying gaps in technology resilience, organizations must work to remediate them. This process often requires a cross-functional approach, with collaboration between different departments and teams to ensure that resilience is addressed holistically. Some specific steps include:

• Assigning clear ownership and accountability for technology resilience activities is essential. Distributed systems can have multiple owners, and developers aren’t always incentivized to architect and design for resilience. Applications and systems must have clear ownership, developers need accountability tied to the resilience of the applications they build, and third-party contracts must include resilience/SLA requirements.
• Enhancing governance toward resiliency levels, the C-suite needs to communicate its intention and prioritization of resilience down through all levels of the organization with continuous and consistent messaging.
• Establish dedicated teams composed of representatives from various departments, including IT, operations, and business functions. These teams can work together to address resilience gaps and ensure that all aspects of the organization are aligned in their efforts to improve resilience.

Need help assessing your team’s resilience? Let’s talk.

Darcy: Most of my experience has been with monolithic architecture. I have a bit of experience with microservices at previous jobs, but most of that was with hybrid situations with legacy apps that followed monolithic architecture and new microservices for newer apps.

Toby: That’s about the same for me. One of the student workers at my last job, who was very ambitious, was trying to sell my team on breaking up our services into microservices. Our team lead turned down the idea, saying it sounded like too many moving parts.

Varell: Pretty much all the apps I’ve worked on have been monoliths, even when working for an e-commerce company. With a client of ours, an application was set up as a microservice architecture but still deployed to one machine with many Docker containers. I’ve read a lot about the advantages and disadvantages of microservice and monolithic architectures over the years and am excited to work on a microservices structured application.

Ryan: I’ve worked mostly with monoliths. I’ve worked on a project that involved splitting up a giant monolith into microservices. I’ve also worked on a project going the other way, consolidating microservices into a more monolithic architecture. I’ve never worked on something that was designed as microservices from the beginning and stayed that way; I haven’t worked on problems that required that sort of architecture.

What are the biggest differences between the two? Benefits? Drawbacks?

Ryan: I think one reason you might want to have a microservices architecture is to have smaller units of deployment so that you can deploy services independently of each other. That doesn’t come for free, though — you have to design them not to be coupled together, but it gives you more freedom in deployment if done correctly. For example, if you have two different parts of an app, one changes a lot and one doesn’t change very much, in a monolithic architecture the number of deploys is driven by the part that’s changing more. This means you have a lot of turnover in the code that might be unnecessary compared to if they were split up.

Another nice thing about microservices is that you can scale services independently as well. If you have a particular part of your app that is CPU-heavy or uses a lot of memory, you can dedicate infrastructure resources to fit that need, and the rest of your application doesn’t need to be on a big machine. With a monolithic architecture, the resources are determined by the most resource-intensive part of the application. In general, that’s one of the benefits of microservices — you can scale parts of your application more precisely.

Varell: Ryan hinted at a lot of things I want to highlight, like horizontal versus vertical scaling.

Ryan: Yeah, that’s a better way to say it.

Varell: With vertical scaling in a monolithic application, you have to deploy the whole app to be able to respond to more requests. You can add more resources to the infrastructure that the monolith is deployed to. When scaling microservices and one service needs better performance, you can deploy more instances of a particular service, allowing you to target particular parts of the app.

One difference I want to bring up is their deployment strategy. Like a Hershey bar, you can either choose to have the pieces all together (monolith) or break them apart (microservices). Also, when first developing a project, you often don’t know what parts would be good to break into microservices. Creating a monolith first and then breaking it out into microservices could be a good approach to take. I’ll pass the mic to DJ Darcy Darce!

Darcy: Woohoo! I need the lights to change or something, haha. With microservices, ditto a lot of what’s been said. I am thinking about it more organizationally — typically with microservices, you have a team that’s responsible for a specific service and one of the pros is that you can have a team specializing in a specific tech stack, and then another team working on a service with a completely different tech stack — and that’s okay! As long as these teams communicate and make sure the services are compatible.

However, a drawback is knowledge siloing, that’s one of the challenges with microservices. It’s difficult because large organizations will hire people familiar with different tech stacks for different services, and that usually ends up with few people who understand the whole system. And testing for a monolith is a lot more straightforward. With microservices, you have to test each service and account for its dependencies which can be very complicated. I’ll pass it to DJ Toby Tobe!

Toby: Haha I do have lights that change in here, I should get them going sometime. I like what Varell said about building the app first and then breaking it out because in my experience, that’s a good way to do it. It’s the whole Red, Green, Refactor thing — find where the problems are, fix them, then break it out, etc.

My issue is — and I may be overthinking this — communication between parts of an application. A microservices architecture has more complexity because of the possibility of network failures. In a monolith, instead of making a method call, which yeah it could fail, you’ve got the entire network stack on top of it, plus any unreliability that might be there.

With microservices, now you’re not just making a method call, you’re basically making an HTTP request to something else. So if part of the code needs to query some users, you’d get an HTTP 500 error with the microservice. As a Rails developer, that would bug me if I had to do things in a transaction. If my team had to update a batch of users, then begin a transaction, post, and still have to implement that ourselves? I’d rather do that in a monolith because with Active Record, there’s a way to just do that using Ruby syntax. Anything beyond the basics, like once you need transaction support, means now you’ve got to start writing that code yourself. Now you have all these layers in between, so there’s more chances for failure.

That’s always been my big thing — is it worth the extra complication? If you’ve got the numbers behind it saying we can scale up as needed, then great. I’m with Varell, you should wait until you have a definite use case for microservices.

Ryan: Yeah, Toby you brought up a downside of microservices that I think should be emphasized: they involve a lot more network calls and networks are unreliable. In making a request to another service, a transient error could occur because the service was down for a second. This means you have to include retry logic, probably with some sort of exponential backoff so you don’t hammer that service and cause cascading failures. None of those issues are involved in a monolith when making a simple method call.

And yeah transactions are another thing that become more difficult. There are patterns for implementing distributed transactions, like Saga or Two-Phase Commit. But implementing the Saga pattern can get complicated and not every database system implements the Two-Phase Commit protocol.

In a monolith, you typically have one relational database and transactions are just part of the feature set of that.

Toby: I’ll just add on that yeah, saying “Let’s abstract out the users’ stuff” means now you’ve got to write this abstraction and add to it; it’s not easy.

If you want to do it cleanly, you’ve got to add a layer of abstraction because you also need to be able to test this. So instead of “here’s the code to manage users,” you now have to create an abstraction like an interface or protocol that lists out all of the methods you may need to call on users – create, delete, update, etc – and then you have to write your specific implementation for it that will work with your microservice. This isn’t a bad pattern! It’s one I’ve used in the past very successfully because it separates things. But, in the case of something like database access, where for example something like ActiveRecord handles it beautifully for you, now you’re reinventing the wheel.

The end result is the code doesn’t need to know about the details of the database connection — it only knows as much as it needs to know. The benefit to that is now you can test all of your code very easily — you don’t need a database connected.

With a monolith, we already know we’re using Active Record, so I can just have a piece of code somewhere like user.find and then boom, I have the user. It’s that easy! With a microservice, now the code has to know to call out to the microservice or you’ve got to do the abstraction we talked about. The code calls the abstraction and further up the chain we’ve figured out that it’s going to talk to the microservice, but the code doesn’t know that. It’s extra work. It can absolutely be worth it, especially where testing is concerned, but it’s a tradeoff.

Varell: One thing Toby mentioned was that with monoliths you can just call a function. This is also possible with microservices using gRPC. With gRPC, you are able to call a function that exists on another machine as if it is a part of your codebase.

I agree with what was said about transactions, especially in a case where you have to change multiple tables in multiple different databases across multiple services — how do you roll back if only one of the databases updates correctly?

Ryan: One could argue that okay, look at all the monoliths out there — a lot of them turn out to be a big ball of mud, becoming difficult to work in as more people work in them and they scale up. The main thing that goes wrong with them is that there’s no module boundaries and everything gets coupled together, so there’s no way to decompose it into different units. You might say, “Oh, well why don’t we set some hard boundaries? Maybe microservices are better because we can avoid that ball of mud.”

But I think you could do the same thing just as easily, coupling microservices together so they have to be deployed at the same time, creating implicit dependencies in data processing. Just because you do microservices doesn’t mean you have decoupled architecture, you have to enforce it through careful design, like with a monolith.

Varell: This lack of structure and/or boundaries in code is also referred to as spaghetti code and when applied to architecture it has been referred to as spaghetti architecture. Either way, what you choose takes discipline to implement well and reimplement as an application changes.

Darcy: Microservices come with a lot more complexity that is hard to manage because for each service you have to handle deployment, logging, possibly a unique tech stack, and an entire team. It requires more responsibility for the team that owns it and it decentralizes decision making, which comes with pros and cons — could be a whole other blog post!

How does communication in the organization shift based on microservice or monolithic architecture?

Ryan: I think Darcy hit the main point very well — microservices can facilitate decentralized control and management. Also, with microservices, the medium of communication changes when you have to coordinate different services because you’re communicating via contracts or versioned specifications. What’s the shape of the data that this service expects and returns? Your service is expected to adhere to that contract so other teams can rely on it — it’s more formalized. On the other hand, in a monolith, those boundaries are generally softer.

Toby: Yeah just thinking about team communications, even if you had multiple microservices using the same tech stack, the structure could be one big team or split into a couple of teams. For example, if you had the option of coding in Go, and the main Go developer is on vacation, then the update won’t get pushed.

Varell: It’s quicker to get up to speed on a microservices app because it’s smaller — you wouldn’t really be looking at code that’s for a different feature because everything you’re looking at is part of the service you are responsible for. In that way, microservices are more streamlined.

Ryan: With microservices, you would have different versions and deploy a new version of your API, but continue to support the old version so nothing downstream breaks. But there’s often cross-team communication needed like: “Is everyone off of version two? Can that go away so we don’t have to support that anymore?”

Toby: You can kind of bake that into the contract if you agree to do semantic versioning, but even then yeah, you run into “We’d like to move to new framework X but we can’t because these two old projects run on this old framework, and we have to support it to keep it alive.” It’s hard.

Varell: Versioning for endpoints may be unnecessary because developers will see in their local environment if something breaks before they push to production.

What’s overlooked about either microservices or monolithic architecture?

Darcy: I don’t have hard data for this, but I highly suspect that monetary costs are overlooked with both — but more so with microservices because you have to pay for all the different services and applications that support each service plus the engineers.

You need more specialized engineering if you have a system with lots of different types of technologies because it requires developers familiar with specific tech stacks, DevOps, and numerous tools for monitoring and logging. Costs add up, so microservices can be unrealistic for many small and medium-size companies.

Varell: I guess my biggest ‘ick’ is when people get caught up in following trends. Both microservices and monolithic architecture are proven to work, you need to decide what’s best for you. Thought leaders start writing blog posts about the same topics and business professionals feel like they need to migrate to one thing.

It’s not a bad thing to learn what others are doing, but implementing a structure because others are is an overlooked thing. Just because others are using one type of architecture doesn’t mean it’s good for your situation. It’s good to read, learn, and see benefits of each architecture type, but it’s even better to draw a conclusion about if it’s the best thing for you right now.

Ryan: You can design a monolith to gain some of the benefits of microservices that we’ve mentioned, like being able to adapt and change quickly, by having well-defined module boundaries.

As your monolith evolves and the domain objects become established, you could even go as far as to separate modules’ data in the database and have different schemas for them. That has independent benefits for making your code easier to understand — making your system easier to understand and change — but also can give you more flexibility with what infrastructure the application is ultimately running on.

For example, if you had different modules that were separated, communicating via a message bus or some in-process facsimile of one, splitting one of those modules out to one or more microservices is not hard and doesn’t require a lot of changes to the code. If you write your monolith in a way that expects async communication, you can be a lot more agile and get the benefits of microservices when you need them.

The awards recognize Tandem’s work to modernize the U.S. Department of Defense’s legacy application MIRS, or the MEPCOM (Military Entrance Processing Command) Integrated Resource System. Used to track military applicants during their enlistment process, MIRS had been in place for 25+ years. Over a three-year period, Tandem’s software consultants completely reimagined the system to create a modern, user-friendly platform that helps field advisors process applicants through to the military faster than ever before.

The American Business Awards are the U.S.A.’s premier business awards program, honoring organizations of all sizes and industries. 2023 saw ​​more than 3,700 nominations, so Tandem is honored to be recognized alongside other companies transforming applications to make customers’ lives easier.

More than 230 professionals worldwide participated in the judging process to select this year’s Stevie Award winners. Speaking to Tandem’s nomination, one judge remarked, “This is a comprehensive solution to solve the military enlistment problem […] the design and UX look clean, simple, and smooth. The data showed that it has already been creating a real impact — saving lots of time and money for the military.”

Stevie Awards are conferred in eight programs, collectively receiving more than 12,000 entries each year from organizations in 70+ nations. To learn more about the American Business Awards and see the list of 2023 Stevie winners, visit the Stevie Awards website.

To see the winning video demonstration of how Tandem modernized the MIRS application, you can view it on YouTube:

There are a number of different technical considerations when undertaking a migration that are project-specific. Moving data from one database type to another such as SQL to NoSQL will clearly have implications but even a relational database migration from a row to columnar database also has implications for the data. Project-specific details will impact conversion scripts and SQL objects. It is important to understand how these changes will impact the end users and data consumer applications and to plan accordingly. In this blog post, we will explore some key tips for data migration that are more focused on universal planning concerns, including how to identify and manage stakeholders and strategies for dealing with different types of data.

Understand Who is Using the Data

Identifying stakeholders is a crucial step in the data migration process. Stakeholders are individuals or groups who have an interest in the data migration project and may need to weigh in on decisions related to the data. Some common stakeholders in a data migration project include product owners, data managers, and customer service teams. It’s important to involve these stakeholders early in the process to ensure that everyone is aligned on the goals and objectives of the project. Typical stakeholders for a data migration project include not just technical stakeholders like DBA’s but business stakeholders who use the data daily. In addition to product owners, downstream stakeholders like customer service departments can be impacted by data quality issues.

It is also important to consider the needs of data consumer applications when planning a data migration. These are applications that rely on the data being migrated and may be impacted by changes to the data or the database. It is important to understand how these applications use the data and to identify any potential issues that may arise as a result of the migration such as data duplication and service outages.

Know Your Data

First, it is important to understand the different types of data that you may need to migrate. Structured data refers to data that is organized in a specific way, such as in a database or spreadsheet. This type of data is easy to work with and can be easily searched and analyzed. Unstructured data, on the other hand, is data that does not have a predetermined structure and can be more challenging to work with. Examples of unstructured data include emails, documents, and images.

When planning a data migration, it is also important to consider the type of database you are using. If you are using a relational database, such as MySQL or Oracle, you will need to consider the relationships between different pieces of data and how they are organized. If you are using a data blob, such as Amazon S3 or Azure Blob Storage, you will need to consider how the data is stored and accessed.

Changes to the source application data model can break the data contract between the data producer application and data consumer system and the migration will cause production issues during the switch.

The impact on the data model is another key consideration when planning a data migration. The data model is the structure and organization of the data. Source-to-target modeling is a technique that is often used in data migration projects to understand the relationships between the data in the source database and the target database. This can help identify any issues or inconsistencies that may arise during the migration process.

Setting Up Environments and Licensing

Before the migration starts, it’s also important to take into account the different types of environments that will be needed for the data migration. In addition to the eventual production environment, procuring a test environment for testing things like observing how converted SQL scripts impact the data will increase confidence in the success of the migration. The size and complexity of the project will impact the number of environments as well as the length of time the environments need to be provisioned. In certain cases, a test environment might be warranted in case of a rollback or data quality issues surface after the migration is complete. Provisioning a test environment and additional licenses, in addition to the new target environment, will have cost and support implications for the time that those environments will be needed.

In some cases, it may not be necessary to move all of the data to the new platform. Instead, you may want to consider archiving certain data that is no longer actively used or needed. There are a number of advantages to archiving data before migration, including cost, simplifying and optimizing the time it will take to actually completing the migration, even complying with the growing number of privacy regulations. In other words, less can be more when it comes to having data in a production environment. There are several factors to consider when deciding which data to archive, including PII regulations, business rules, and data integrity concerns. It is important to involve the appropriate stakeholders in this decision-making process to ensure that all relevant considerations are taken into account. Once the important decisions have been made, cloud providers like AWS have lower-cost storage products like AWS Glacier available.

Understand How and What to Test

There are multiple specific details to consider when planning and implementing a data migration that are specific to your migration such as whether or not this is a cloud-to-cloud migration versus on-prem to cloud, or a migration over time versus a “big bang” migration. Regardless of these differences, one thing you will need to consider is data testing. Any time data moves from one place to another there is a chance of corruption or data loss. Setting up a test plan that takes into account acceptance criteria, test environments and test data, triaging issues that will occur along the way, recruiting and managing test participants and exit criteria will be a critical step to ensuring a successful migration and getting sign-off from stakeholders.

Planning a platform migration or update? Contact us to let us know how we can help.

Similarly, human-centered design (HCD) has been widely recognized as a best-practice in developing solutions that solve real problems for real people. Rather than starting with a product or idea, let’s start with the person and problem and work toward the solution. Products driven by HCD foster a higher level of engagement with their users and result in a tighter market fit.

While both agile and HCD are often referred to as “methodologies” they really aren’t, they’re philosophies. There are numerous techniques and methods that fall under the HCD umbrella. And, there are several popular frameworks that can justify calling themselves agile.

This distinction between method and philosophy is an important one when exploring how HCD and agile can work together. Because these are philosophies, a set of mindsets and objectives, we don’t have to struggle to merge two disparate processes. Rather, we can conceive new processes that satisfy the values of both philosophies.

The Philosophies

The core difference between the parallel philosophies of agile and human-centered design revolves around how each system measures value. For many agile software teams, the measure of value is closely related to velocity (how quickly work is being done) and the progress in delivering features to production. In this way of thinking value starts at zero and incrementally (and uniformly) increases to some maximum as defined by the scope of the project.

HCD, on the other hand, measures value in terms of the quality of the user’s experience – how well and how completely does the product address the user’s pain points. This approach also adds value over time but it is much less linear and often doesn’t start from zero as problems are often already somewhat solved by alternatives. Additionally, practitioners of HCD consider that, at times, the product may actually decrease in value even though it has more features than before.

The working supposition of this article, and what we’ll discuss in subsequent sections, is that neither philosophy is wholly “correct”. The danger in taking an exclusively agile approach is that we may not build the ideal thing and therefore not solve a real problem. The peril in focusing only on an HCD approach is that we may not ever get off the ground, mired in a “design hole” and never ascending to execution. However, the philosophies are complementary, each covering the deficiencies of the other in powerful ways.

Why agile needs a little HCD

As stated previously, agile sprung from a well of discontent filled with stalled projects, drawn-out timelines, and endless planning. The intent of its founders was to address these problems in the context of software projects, a very “by developers, for developers” approach. Yes, agile does seek to involve the stakeholders more and later incarnations of agile practices such as Extreme Programming (XP) took this further. But, on balance, agile addresses the concerns of a well-executed project.

Some readers will doubtless argue against the previous point. And yes, I am generalizing. But in my many years of experience (most of it on agile projects), I have seen the agile methods used more as a defensive mechanism for teams than as a way to build a better product for the user.

So why then, does agile need HCD?

Savvy Users

As users become savvier with technology (the web, mobile apps, wearables, voice interfaces and AI, etc) they have a better intuition about how systems should behave. When a digital experience breaks their intuitive assumptions the product becomes much less effective at solving what they expected the product to solve. The immediate next step for a user is to search for an alternative, not a great outcome for our customers, or our businesses.

Higher Order Problems

As technology has advanced over the decades it has become capable of solving ever more critical human problems. These problems are often sweeping in their scope and require a systems approach. HCD’s concentration on deriving solutions from foundational user research leads to the discovery of a solution that is a system of systems.

For example, modern healthcare technology, transportation, farming, and public safety are large-scale problem domains. Solutions in these spaces are improved by this systems view rather than thinking of them as a set of isolated activities strung together.

A Benchmark for Validation

Both agile and HCD encourage the collection of feedback and refinement of ideas through validation. However, agile tends to benchmark from a different position, usually against the edicts of business stakeholders.

User-based research, on the other hand, provides a scale which can weigh design decisions against the value delivered to a real user. This evidence-based approach means much less guesswork which frequently becomes a matter of rather meaningless debate.

ABE, Always-be-Editing

The age of bloated, feature-centric software (more specifically interfaces) is over. There will always be a place for complex, technical, and utilitarian software, but the vast majority of products do not fall into this category. Pleasant, effective, and intuitive experiences are far more likely to drive success today than merely a long list of capabilities. HCD advocates for constant editing, always asking “do we still need this,” and “can we solve this in a simpler way.”

—

In our next post, we’ll explore where agile and HCD can falter and some of the principles to follow to bring them together successfully.

This is the first in a three-part series of posts that will explore how we do product development at Tandem – something we call “Human-Centered Agile.”

Technical debt in software projects is unavoidable. It’s the cost of doing business, and teams should not be made to feel guilty for choosing to accrue some debt. The key to maintaining a healthy codebase is proactive debt management.

In my experience, there are three main causes of tech debt:

• The team prioritizing shipping code over quality code
• Updated requirements making the past solution harder to work with
• Natural deprecation over time

Since tech debt is an inevitability, when is the best time to pay it down?

Cause: Prioritizing Shipping

Management Strategy: Pay It Down ASAP

Sometimes, choosing to ship a less elegant solution means getting a feature in the hands of your users faster. Decreased time to market is a huge competitive advantage that quickly provides you and your team valuable feedback. I always recommend user testing prior to feature deployment — but sometimes, user testing in a vacuum can only get you so far. The sooner you get your feature into real-life use, the sooner you can identify opportunities and fix any problems.

As long as the decision to ship less-polished code does not risk team burnout or cause unrealistic timelines, taking on this tech debt may be a wise decision. Prioritizing shipping reduces your time to realization and helps you understand your users’ needs better.

For this kind of tech debt, I recommend paying it down as soon as possible. In software development terms, this strategy follows the “make it work, then make it good” mentality. After your team ships a feature, clean up the solution and pay down tech debt. This capitalizes on their knowledge while the context is still fresh and will make the code easier to extend and build upon as you get feedback from your users.

Cause: Updated Requirements

Management Strategy: Highest Interest First

Tech debt can also accrue as you learn more about your needs and user requirements. The solution you started with may no longer be the best solution to meet those needs. Code reflects the team’s understanding of the problem at a point in time: as that understanding evolves, so should the code.

For this type of debt, it’s best to pay it off in a “highest interest first” approach. That means the most painful and most resistant-to-change parts of the code should be refactored first. Be on the lookout for the moment when changes in the codebase that used to be simple and easy become time-consuming or cause some grumbles from the team. When a simple requirement change or feature request means a week or more of work, that’s a good sign that the previous solution or abstraction in the code is no longer suited to your needs.

When this happens, prioritize time to refactor this code, focusing on high-churn areas first. High-churn code is code that is updated frequently. Parts of your codebase that are only touched once per year are less likely to require refactoring. If it works and you don’t change it much, it’s ok to leave it alone.

If you know that you have a new feature coming up, talk with your team about any refactors that should be made before tackling the new work. Building new features on a sturdy foundation is almost always quicker, easier, and more enjoyable than trying to put band-aids on a shaky base. Refactoring the code you’ll be extending before you add your feature helps you fortify it for upcoming iterations as well.

By prioritizing painful parts of the codebase for debt management, you ensure that your team never spends more time (and budget) than necessary maintaining them.

Cause: Time

Management Strategy: Pay As You Go

Finally, some tech debt happens naturally as a codebase ages. Languages and frameworks are updated, packages are deprecated, security patches are released, etc. This type of tech debt should be paid down early and often to prevent it from piling up–the more debt there is, the more interest you’ll have to pay on it.

Every team should set aside time in their workweek for managing this kind of tech debt. Budget time for upgrading languages and frameworks when new releases come out. Run security audits every sprint or two and give your team time to remediate any findings. Keep an eye on third-party packages and upgrade them as needed or replace them with alternatives if any become deprecated (hopefully a rare occurrence!)

By paying down this natural debt as you go, you prevent it from ever becoming unmanageable or interfering with the feature work of your team–the work that brings in revenue. 🥳

Reducing Technical Debt in the Future

There’s no way to prevent technical debt in a software product. However, there are some ways to reduce how much debt is accrued. First, as we’ve talked about, is to proactively manage your debt and pay it down regularly.

You should also embrace and celebrate quality code. A little upfront investment in your software can go a long way to making tech debt easier to address when it does come up. And encouraging engineers to “leave the codebase better than when you found it” creates a reinforcing feedback loop of cleaner and stronger code that becomes easier to work with and maintain.

Finally, share long-term goals and product plans with your engineers so that they can provide strategic ideas on where to pay down tech debt and when. Most engineers I know do not enjoy working in brittle codebases: your team is your biggest ally in identifying and mitigating tech debt long-term.

Do you need support in identifying and paying down your tech debt? Let’s talk.

To start, let me demonstrate what I mean when I say ‘complex system.’ For several years, we’ve worked with the U.S. Department of Defense to create an enlistment application called MIRS. Each individual arm of the DOD has its own unique recruitment system, which has to send and receive data from our application.

Once information has been received from the original systems, MIRS is used to move each applicant through the vetting process. That process requires us to integrate with additional external pieces of software and hardware:

Adding to the complexity of this system is its diverse user base: our application will be used by physicians, military service members, and civilian users, all with different levels of comfort with technology.

With just one application, we’re accounting for many different system integrations, a massive amount of data coming in and going out, physical machinery, and a diverse user group. Designing for so many dependencies can be a challenge. But, understanding how each system works with your application is critical to designing for success.

The Role of Design in Complex Systems

In a system like MIRS, our team’s software engineers deal with integrations on the most intimate level, since they are responsible for actually writing the code that connects components together. But designers also need to understand how these systems talk to each other: Does a user manually enter data? Or does the system integrate to display data onto the screen? As a UX designer, it’s important to know how we are getting the data. For example, if it’s manual input, there is potential for user error, so I can make design choices to minimize that risk.

Designers also have the most influence on how to account for the human element of a system. In another complex system I’ve worked on, a healthcare app, the system was smart enough to know when a user was going off track from their weight loss goals. But as humans, we know that alerting the user to this information takes some delicacy: how do we use language to avoid causing shame or alarm? The app also had a mood-tracking function: how do we make sure the app’s messaging strikes the appropriate tone when the user is feeling depressed? A system can be super smart, but you need a human to understand that when the user is having a bad day, the language should be encouraging — and when a user is having a great day, the language should be celebratory!

User Research for Complex Systems

To fully understand a system’s complexity, you need to gather multiple perspectives on the product: from the product’s end users, the product’s stakeholders, and your engineering teammates.

Users

For all products, I’m a huge proponent of co-creating with the actual users — and the more complex the system, the more I advocate for this approach. Ask them: if you could redesign your application, what would you do? When we talked to MIRS users, we learned that the legacy application displayed each applicant’s birth date on the screen, leaving the user responsible for doing the mental math to determine whether or not the applicant was 18 years old. It made their lives a lot easier when we redesigned the system to also display the applicant’s age! Tapping into your users’ perspective will always give you practical ideas.

Asking questions will get you a lot of information about your users’ frustrations. What’s even more valuable, though, is just watching them work. This can be awkward at first — a lot of the time, users feel like they have to entertain us or talk us through what they are doing — but once you get them comfortable with letting you just watch as they work, you can discover the hacks they don’t even realize they use to accommodate their legacy systems. Watching a nurse struggle with a label printer is more valuable than just hearing her say “I print labels every day.” A lot of users become accepting of the work-arounds they’ve developed, but when you observe them, you see so much opportunity to make tasks easier!

Stakeholders

On many projects, your stakeholders or clients are different people from the end users: sometimes your stakeholders are managing your users, or are creating a product to sell to your users. While the end users will give you the best perspective on how to actually make the product work for them, your stakeholders can provide the macro-level perspective on what business goals the product is expected to achieve.

Software Engineers

Finally, when you’re having user and stakeholder conversations, bring some of your engineer teammates with you. They ask a lot of good questions, because they think about how to implement UX improvements. The engineering perspective is different from the design perspective, so when you’re able to really combine your thoughts from the beginning, you come up with the best and most workable solutions.

Engineers can also help you understand what kind of data visualization is possible. For one project, we wanted to display a lot of details on a map, so we worked with our engineer teammates to explore the libraries and frameworks that already exist to perform mapping functions. Ultimately, we as designers made the recommendation on how to proceed, but by working collaboratively with the dev team we were able to make a good, implementable choice.

Synthesis

Once you’ve gathered information from your users, stakeholders, and engineer teammates, it’s time to synthesize your learnings. Write your teams’ insights on post-it notes, write down even the smallest observations. Once we have all of our thoughts on the wall, we start to group post-it notes by themes. Finding these themes can be challenging. At this point, you’ll start narrowing down your findings to create a synthesized insights report that demonstrates the key findings from your research.

Designing for Complex Systems is More Than UI

Our technology world has widened so much; innovative technologies like virtual reality, automation, and machine learning create so much possibility to improve peoples’ lives. But as a designer, it’s important to never forget the role human beings can play in achieving those same goals.

To illustrate my point: In the healthcare app I mentioned earlier, the original app auto-sent a message to a health coach every time a user logged a meal. This became overwhelming fast: the coach would get a separate email every time somebody ate a banana or had a glass of water! Eventually the coaches would just ignore the notification emails because there were just too many to keep up with. Implementing machine learning helped the app recognize which foods the coach needed to be alerted by, versus the foods that were fine and didn’t require any notification. This made the product better and improved the coaches’ ability to help their clients.

On the other hand, there are some situations where machine learning, or whatever technology we invent in the future, is not the solution. If an app user eats pizza and ice cream for breakfast the machine can identify that the user needs to be coached, but a person has to actually do that coaching and have a human conversation. Could a chatbot send a check-in text? Sure. But the more effective thing to actually achieve a user’s health goals is to enable that personal, encouraging connection with a coach who cares about you. A chatbot won’t likely motivate you to choose a salad next time. As a designer, it’s so important to recognize the way technology and humans each have their strengths and their flaws.

In the end, if you’ve done a good job, your complex system won’t seem complex at all to its end users. Hiding that complexity is the most important — and satisfying — part of what we do as designers.

Designing for complex systems requires a good understanding of each component of the system, combined with an intense familiarity with the people who use the system. Your challenge as a designer is to approach these projects with an open, curious mind so you can learn as much as possible during the discovery phase, and then use your UX expertise to bring simplicity to the complex.

Rental car agency Hertz filed a $32 million lawsuit in April against consulting giant Accenture because it “failed to deliver the website and apps for which it was so generously paid.” Hertz pulled out of the contract in May 2018 after repeated delays prevented a launch originally scheduled for December 2017.

Hertz also claims Accenture failed to implement responsive web design, cited security risks due to poor coding, and alleged the design was too specific to the North American Hertz brand to be used for Dollar and Thrifty (brands Hertz owns and operates) as agreed upon.

Back in the day, people would say, “Nobody ever got fired for buying IBM.” That mindset probably applied here, too—Hertz figured Accenture was too big, too respected to possibly be a poor choice for a major project like this. Many people seem surprised that a leading consultancy with a great track record like Accenture dropped the ball here.

But I’m not.

But my guess is that Hertz and Accenture should share the blame. 

That is most likely the case given what a monumental failure the project turned out to be—it can’t be any one party’s fault alone. Of course, this is almost purely speculation; I have no inside knowledge about the details of the project. But as the CEO of Tandem, a design and technology innovation firm that has taken on similar projects, I’d like to offer an educated guess of what I expect went wrong.

Hertz and Accenture didn’t nail down the requirements and communicate them across teams right from the beginning.

It’s fairly obvious Hertz didn’t have proper oversight on this project. That’s primarily its own fault, but also Accenture’s fault because every good consulting company makes sure its client has them under a microscope.

For example, when a project is meant to serve multiple tenants (brands, in this case—Hertz, Thrifty, and Dollar), that’s something you plan for from the outset of a project. It’s decided upon before you create any data models or begin on product architecture.

I’m not sure where the communication between Hertz and Accenture broke down here, as basic requirements gathering would have let Accenture know cross-brand functionality was a core component of the project. The same is true for the data protocols and responsive displays Hertz requested.

Accenture likely sent a business analysis team and a project manager to draft requirements, then relayed them to the development team. So much fidelity is lost during this handoff, leaving the delivery team with only a partial understanding of the client’s vision and expectations.

Additionally, although many of Hertz’s unmet demands were included in the contract, companies shouldn’t be baking their requirements and deliverables into contracts in the first place. Contracts live in a different world than the delivery teams. Even at Tandem, our teams aren’t going back to the contract. They learn about requirements from direct interaction and conversation with the client.

Accenture’s team was too big and (probably) siloed. And it’s obvious all the separate parts of this project simply didn’t come together in the right way. 

Again, this is just conjecture, but I’d guess that the team working on this project was easily 60-plus people.

With a project and team of that size, you need incredibly comprehensive design and planning, the perfect project manager, and lots of product ownership protocols. Otherwise, communication between your payment processing team, your scheduling team, your logistics team, your front-end user experience team, etc. will break down and silo.

And I’d imagine Accenture outsourced some parts of the project to offshore companies, which only makes communication more difficult.

Once it came time to integrate all the separate parts of this project, Accenture likely struggled both with having all the necessary parts ready and effectively piecing them together.

Hertz probably rushed the timeline and requested a low budget—and Accenture played along.

For the project to have gotten so far overdue, and so far in the hole from a cost standpoint—it’s hard to fathom. This project had to have been doomed from the start by an unrealistic timeline and low-ball budget.

I’d imagine Accenture, a public company, was worried how investors would react if they told Hertz their requested timeline wasn’t doable and they lost the massive project to Deloitte or another competitor. It’s likely that someone at Accenture pushed back, but Hertz insisted. (As a side note, I often question whether professional services organizations should even be publicly traded for exactly this reason.)

With every massive project like this, things will go wrong and launch dates will be pushed back. But when you reach the point where you need an extra $10 million, that’s beyond the realm of what’s reasonable.

Here’s how we would have handled this project differently at Tandem: 

We’d work with small teams.

Every software project has a “speed limit” that, if surpassed, will result in different work streams bumping into each other.

When explaining this concept, I like to use the analogy of painting a closet. You can paint a closet with two or three people, but not eight—at that point, everyone’s just crashing into each other and you get nothing done.

Some parts of projects are like painting a closet—include too many people on what should be a small team and nothing gets done due to friction.

We’d include our entire team, from designers to developers, in the initial drafting and design process.

When all teams are present for drafting, everyone can ask questions and gain a clear picture of what the end product should look like. This immersion process also entails job shadowing, interviews with stakeholders and customers, defining major themes and goals, and more.

We’d clearly lay out requirements outside of the contract. 

My belief is that project requirements should not exist solely in a contract—not enough people see contracts at all, and not enough teams revisit contracts throughout the course of a project. For this reason, requirements should always exist somewhere else.

We’d have requested a longer timeline.

When you force a short timeline, as Hertz and Accenture did, disaster happens. There are only so many aspects to a project like this that you can develop in parallel.

We’ve worked on projects of a similar size at Tandem, and for the Hertz redesign, I would have proposed a two-and-a-half or three-year timeline (Hertz and Accenture landed on a year and a half).

Anyone who has worked in this industry long enough knows that when you rush a project, it only ends up taking longer due to miscommunication and problems with integration.

We’d have caught problems early on and accounted for them.

With software development projects, mistakes are inevitable. Changes will always need to be made. But you need to make sure to catch them early on and communicate them to the client, then push forward alongside them.

1. The transformation is pervasive throughout the organization
2. It substantially impacts the operating model, and
3. The impact extends to the way customers receive value

If you’re like most business leaders, these three criteria are daunting, perhaps even a little frightening. An effort of this scale, that will drastically reshape your business, should be approached with extreme care. The process starts with an honest evaluation of the company and investing in some changes to the underlying structure, values, success metrics, culture, and people.

A Readiness Questionnaire

Through our work, we see many companies that are in the middle of sweeping transformations. Some of them go smoothly, but more often they are chaotic, reactionary, and in some cases resisted by employees. The most well executed digital transformation initiatives are those that occur within organizations that have prepared. Let’s look at a few of the signals that indicate a company is ready for transformation.

Is your organization customer obsessed?

Being obsessed with customers is probably the first and most critical success factor in any digital transformation. Here are a couple markers of truly customer focused companies:

• All levels of the organization have essential and regular touch points with customers, from the executive level down
• The organization has a mature user research or customer insights team whose mission is to find customer needs more than just validate the product team’s ideas
• Customers regularly participate in the co-creation of new products and services through user experience testing and accessible feedback mechanisms

Are your product teams high-functioning?

There can be many reasons why a delivery organization is not performing at optimal throughput. But one of the most common issues we see is upstream chaos. Specifically, the pipeline of steps that lead to clear, actionable, product definition is dysfunctional.

Because our definition of digital transformation requires pervasive and impactful change, these dysfunctions will literally kill a transformation effort on the vine. The easiest way to detect that your product organization may not be fully effective is to look at the amount of churn that happens in requirements based on feedback from the delivery (design, engineering, manufacturing) teams. If there’s a lot of churn it means that the product likely didn’t satisfactorily answer: who, what, why, and when.

Is experimentation safe for employees and managers?

The value of experimentation, and occasional failure cannot be overstated. This is especially true in a digitally enabled business. The benefits derived from becoming an organization that supports experimentation come at two levels:

1. Products and services that undergo experimentation and iteration before and after release tend to be much more hardened against competition and much more integrated into an end-to-end offering
2. The sheer effort of becoming good at experimentations forces the organization to become more agile and resilient which has incredible knock-on positive effects

For organizations to really support experimentation there are a few foundational things that need to be in place:

• Employee incentives must be properly calibrated to strike a balance between incentivizing success (typically aligned with the old way of doing business) and disincentivizing failure
• Experiments should have clear boundaries in terms of timeline, milestones, and success criteria that are known by all involved – this provides some psychological safety that failure does not fall on any individual or team
• The core business must be allowed to be challenged. In other words, it must be acceptable for experiments to produce direct competition to the old guard.
• Experimentation must not be shortchanged in terms of budget allocation so that they can fully realize their potential for value creation up to a particular milestone.

Are your technologists ready and forward-looking?

Digital transformations are, well, digital. This means that your organization needs deep technology delivery capabilities at its disposal. This could mean building an in-house team, partnering with external groups that are already well-oiled digital delivery machines, or a mix of the two. Regardless of how you build this capability, it is critical that the organization has the agility and skill to execute as strategic moves are put on the roadmap.

Do you have strong executive buy-in and leadership?

Earlier I mentioned that customer obsession was probably the single most critical component to successful digital transformation. I apologize, but I lied, customer obsession comes in second only to the need for executive leadership. Sweeping change in large organizations almost never happens without buy-in at the C-suite level.

When it comes to big digital initiatives that impact everything including product, marketing, sales, logistics, and operations, executive leadership must be at the forefront. It’s well known that the frozen-middle will organically resist these kinds of broad innovative changes. It’s not because they don’t see benefits in innovation, but because they are stuck in the old ways of producing value. The only contingent within a company that can unfreeze this layer is the executive team.

—

If you found these questions challenging, don’t worry, you’re not alone. Most companies require several quarters or even years to be able to answer these questions positively. And, you don’t have to be perfect before you start down the digital transformation path. In our work with companies undergoing such change, we’ve seen examples at all stages of the maturity curve. Ultimately, success comes down to a company’s willingness to let go of the past, face the future, and change.

Technical debt can similarly be considered a given. Those custom applications that your enterprise maintains will accrete the cumulative effects of short-term trade-offs made in the interest of efficiency and time-to-market. The decisions that resulted in technical debt were likely not wrong at the time: they were made to enable the business. But, if not properly paid down, the debt continues to grow at an alarming compound rate.

Neither legacy systems nor technical debt are bad in the narrow view, but taking the long-term view they will eventually impact your business in several key ways:

• Lagging Behind the Competition – Operational efficiency and new ways of doing business are under continual evolution. If your systems and technology are preventing you from keeping up, your competition will leap ahead.
• Increasing Fixed Costs – The cost of maintaining legacy systems is constantly increasing with platform licensing fees, maintenance costs, and the resource availability of aging skill sets; this all amounts to long-tail increase in cost of ownership.
• Diversion of Key Resources – Your most valuable asset is almost certainly your people and as systems age they require more and more time and input rather than less. This diversion of resources away from innovation and toward “keeping the lights on” can cripple a company’s ability to evolve.
• Inability To Integrate the New – Most likely you will make investments in new systems which will inevitably rely on legacy data or capabilities. Your cost to integrate the new and the legacy may be high and will only add to the layers of architectural complexity.

What to do about this issue can feel confounding. According to an Accenture survey, 72% of C-suite executives state that their legacy systems hamper their ability to migrate to new technologies and make their IT functions less responsive to market change. And, according to a study by the MIT Sloan School of Management, 67% of executives would like to replace all of their core legacy systems, 70% indicated that they would like to get as much long-term value out of these systems as possible, and 50% reported that they wish they could have the best of both worlds. The overlap in statistics here indicates a high degree of indecision among leaders – you are likely not alone.

Assessing Your Legacy and Technical Debt Position

Performing a thorough analysis of your overall technology landscape can be a very detailed and lengthy effort – well beyond the scope of this article. But, here are a few general questions you can use to get a sense of whether or not your legacy systems and technical debt are holding your organization back.

• Are your costs to maintain systems going up rather than down over time?
• Do you find it increasingly difficult to hire people to work on your systems?
• Have your platform vendors begun to increase licensing fees for core technologies?
• Does it take longer now to add new capabilities/features than it did a year ago?
• Is your technology team pushing back more on enhancements than before?
• Are your customers complaining more frequently about your digital touch points?
• Have your teams separated into “new platform” and “old platform” teams?

Answering ‘yes’ to any of these, and especially more than 3 of these, will indicate that your legacy systems and technical debt are beginning to hamper enterprise agility.

Strategies for Coping With Technical Debt and Legacy Systems

There is no shortage of articles and books written about dealing with legacy systems. But for CEOs and CIOs there are a few key investments you can make to reduce debt and push your IT forward.

Decoupling Your Systems and Your Data

Decoupling is perhaps the first step to modernization from an architectural perspective. This involves decomposing systems into smaller units, including legacy data sources, business processes, and core functions.

For example, let’s imagine you run a logistics firm that heavily invested in a centralized system during the 80’s. The software runs on a legacy operating system and handles almost every operational function of your business. You would like to rebuild the carrier pricing components, but they are tightly integrated with the invoicing and scheduling components. Using these as natural “seams” in the software, you can duplicate running instances and isolate the messages between them. Then, temporary bridges can be written to make sure dependent components continue to function while the carrier pricing module is rebuilt as a modern, scalable web service.

This approach requires a high degree of planning and discipline — but it can be a powerful strategy for evolving your platforms while keeping your core operations online. This is also a key opportunity to consider moving to a cloud infrastructure. The flexibility of a public or private cloud will allow re-architecture with much less expense as compared to a traditional data center.

Invest In Becoming an Agile Organization

The concept of agility is often confused with the software methodologies that are commonly used to “implement” agile. But being an agile organization is much more than just doing iterative development or using Scrum. Enterprise agility requires a whole set of cultural and philosophical changes that will inherently allow your organization to more easily cope with its legacy debt.

Becoming a more agile organization has far-reaching implications. Just a few areas to consider:

• Agility requires constant prioritization at all levels of the business: what to invest in, where to allocate resources, what is important for customers
• Being an agile enterprise means committing to strategy only as long as it’s working, and requires tough milestone targets and metrics to evaluate outcomes
• Truly agile companies create a stable core for employees while the particular initiatives they are pursuing may be in constant flux

Agile organizations tend to more actively combat legacy systems and technical debt because they realize that to be responsive to the market, they must also keep free of such encumbrances. Agility will naturally lead companies to become more resilient to change and increase their ability to challenge established technologies and processes.

Constantly Invest In Your Biggest Asset: Your People

Often we forget that companies are made of people: layers, hierarchies, and matrices of people. And as executives, our people determine the execution speed of our decisions. While most large firms have professional development strategies, many are substantially lacking when it comes to IT and software development.

Helping your software engineers, IT operations (DevOps), and technical product management teams modernize their skills may seem like a never-ending treadmill. But, every dollar invested here will pay bigger dividends when it comes to modernizing your business systems.

Creating training and growth opportunities for your teams will mean that you have ready-and-willing advocates for modernization when the time comes. Rather than complaining about the next generation of technology, these teams will be leading the charge — not just with skills but with ideas. Investing in helping people keep their skills sharp and current is perhaps the single best investment any organization can make to help improve their chances at successful digital transformation.

Partnering With Experienced Consultants

Tandem’s team of consultants are experienced in assessing and modernizing an organization’s technology architecture, systems, processes, and products. We take a collaborative, down-to-earth approach to solving the technology problems that are standing in the way of your business goals. Are you ready to take the next step in pushing your business forward? Reach out and let’s have a conversation.

A Process for HCD+Agile

Any article that expounds on the conjoining of the philosophies of agile and human-centered design would feel somewhat perfunctory if it didn’t also attempt to propose a process. There are innumerable ways to implement process around agile and HCD – what follows is by no means comprehensive, or even ideal in every scenario. One of the values of agile wins here: “respond to change over following a plan”, the reader will need to determine the best practice for their needs.

The process above can be broken down into roughly 3 phases: research, experience design, and construction. While this appears to be a linear flow in the graphic above this is merely a limitation of visualization, in practice the process loops and repeats when needed and often doubles back when necessary.

Discovery

During the research phase, the primary objective is to take raw research and turn it into product concepts. At Tandem, we do this through the following steps:

1. Research through interview, observation, ethnographic & psychographic study, and survey
2. Download (often parallel) research streams into a single set of themes and key learnings
3. Synthesize these themes and key learnings into insights, statements that either surprise us or affirm our assumptions
4. Identify the opportunities that these insights produce through “how might we” statements
5. Benchmark how similar and orthogonal problems are being solved by other products in the market or homegrown solutions

Sidebar: When we describe our process we often get the question: “where do personas fit in?” The answer is that we don’t really find them to be effective. They are a handy reference but usually fail to capture the full picture and only highlight the attributes that the designer or team care about or they capture superfluous attributes that are just noise. We often see personas used as a crutch to justify not doing enough primary research. Instead, we like to use “archetype users”, real research subjects who we have interviewed or observed that represent a cohort of users. This results in a much richer model against which to check our assumptions.

Definition

Now that we have some product concepts we need to further define the product. It’s important at this stage to do just enough planning. Too much planning will kick us into waterfall, not enough and we run the risk of missing large objectives that will inevitably change the project direction and cause waste. Our general progression is the following:

1. Brainstorm product concepts that fulfill these opportunities and position well against alternatives, frequently involving lo-fidelity sketching
2. Test our product concepts with users to validate or refine our approach, this ideally involves the original research subjects
3. Frame the product with a project charter, a set of high-level capabilities and features, often the core user journeys will be drawn out here
4. Plan for construction: estimation, staffing, constraints, etc.

Depending on the project, this is where we may also develop the business model or business case – particularly true if this product is opening a new market. This may involve defining the overall product strategy, value propositions, pricing model, and forecasting return-on-investment.

Construction

Building something is where agile begins to come to the fore. At Tandem we typically use a combination of Scrum and Kanban methodologies but adhere dogmatically to neither. For example, we do fixed duration sprints, sprint planning, and regular retrospectives but we also pull from a continuous backlog and stress the limitation of work-in-progress (WIP).

The visualization above zooms in on the agile process but in particular highlights how design fits in. The key takeaway here though is that design of the user-interface should be done in close proximity to the writing of code. Meaning, that design (UX and UI) occurs roughly in tandem with the implementation, or perhaps slightly ahead.

Sidebar: Here there is a warning for the designers on the team. Because your progression through the user journeys is often faster than the developers you will feel a pull to run ahead of implementation. By doing this you run the risk of two major failure modes: 1) creating designs that are difficult to implement or overly complex, and 2) designing things that will ultimately not be introduced into the product. This second failure can be demoralizing for the designer and simultaneously cloud the judgement of the product owner.

Connecting the Dots

The construction phase is where we get our hands dirty in the details. The danger here is that we can lose sight of our original research and insights. If HCD and agile are truly going to work together we must connect our strategic insights to our tactical decisions. There are numerous ways to accomplish this but the way we do it is to keep the research insights up on the wall in the physical project space.

As we hold our product planning and user story writing meetings we can continually ask ourselves: “which insight and opportunity does this feature serve?” If we can’t answer that question then it implies we either don’t need it or we are working from assumption and incomplete information.

User Testing

Despite all of our efforts to align our product decisions with user value, there will be things that are missed. Performing user testing at regular intervals is the best way to ensure we stay on track and deliver the value our users expect. There are a few best-practices that will improve the outcomes of your user testing efforts:

• Use a Mixed Panel – subjects should be a mix of individuals that were part of the original research and fresh subjects who did not have a hand in co-creation – the reactions from both will be valuable.
• Plan Ahead – create scripted test scenarios ahead of time that is as “real world” as possible so that each test run can be compared apples-to-apples.
• Observe Don’t Direct – it’s important to set up test scenarios for your subjects and let them discover the good and the bad of your design on their own, only intervene when they become seriously stuck.
• Record if Possible – if it’s ok with users it can be helpful to screen capture (or video record in the case of non-digital products) each test session, often things are missed in the live session that is later caught while reviewing recorded material.
• Create an Analysis Rubric – results of a usability test can often be qualitative (which is good) but it’s also helpful to set up a quantitative rubric that can be used to measure your test scenarios as a benchmark for future product iterations.

Milestones

Another important facet of this process is that it requires any sufficiently complex project to be broken down into smaller milestones. This is particularly true of projects that will likely require many months or even years to tackle in full. There are numerous reasons for this:

• It creates opportunities to put parts of the solution into the market for testing, feedback, and course correction at regular intervals.
• Discovery and definition do not need to be done up front for the entire system which avoids falling into waterfall or “analysis paralysis”. Each milestone can loop back to the beginning of the process and take a fresh look at research.
• The team builds a sense of momentum and accomplishment that staves off the “death march” of extremely long projects.

Exactly how milestones are broken down varies wildly based on the project. And, the definition of milestones can change over the course of a large initiative.

—

I hope these articles, lengthy though they were, will inspire you to take a fresh look at your processes. Not just from the perspective of what you do to build software, but why. Time and time again I am encouraged that we have pushed the boundaries of product development through the combination of human-centered design and agile philosophies. Take the leap, I think you will too.

While the two philosophies are after the same goal it is undeniable that there has been a historic rift between the proponents of each camp. Agile’s origin story was written by developers, it’s roots are firmly in the hands of “engineers.”

The mythology of HCD or “Human-Centered Design” is a bit murkier but many of the concepts and terminology can be traced back to, Don Norman, director of The Design Lab at University of California, San Diego. It became a way for designers to describe their process and the outcomes they wished to achieve. To many designers (mostly those classically trained), agile methodologies are at best “those meetings the devs have” and at worst a cold, detached and mechanical way of creating software (not a product).

If my oversimplification here has offended anyone, my apologies. There are of course both developers and designers who happily coexist and even thrive in a close working relationship. We operate with this approach at Tandem and I know other organizations do as well. But there is a vast wasteland out there in which these two philosophies are anathema to one another.

Where HCD and Agile Can Falter

I don’t wish to leave the reader with the assumption that upon successfully combining agile and HCD their life will be rosy and all will be well. There is no road to product development Nirvana. So to wrap up, let’s look at some ways that this combination can fall short.

The Unviable MVP

If I had my way we’d strike the term Minimum Viable Product from our vernacular. It is a washed out phrase that more often than not becomes an excuse for building something that half-solves a problem and that certainly doesn’t delight users. We focus only on the M and forget the V altogether.This is where HCD has a leg up on the way agile is practiced in most environs. Agile is concerned with doing the smallest thing that can result in working software. HCD is concerned with doing the smallest thing that can provide a valuable solution to a problem, or some part thereof. Both run the risk of defining the scope of “working” or “complete” as being smaller or larger than necessary. But at least HCD is focused on a tangible outcome for a person rather than checking off a requirement.

Constraint-free Design

Any designer will tell you horror stories of being stuck in a swirling vortex of indecision in which the search for perfect leads straight to nowhere. Constraints such as feasibility, budget, cost of change, and accessibility are a way to extricate a design team from such a vortex.

Infeasible designs, those which either can’t be built for technical reasons, can’t be effectively manufactured, or do not have a clear path to market have two downstream effects. First, the business stakeholders are left feeling that the development team has wasted time and let them down. Second, the design team feels that the only way to build anything is to “water it down”, that the cleverness of their designs are reduced to commodity.

The solution here is to define clear and measurable constraints at the outset. And, to ensure that these constraints are understood by all members of the team.

The Revenge of Waterfall

Sharp handoffs between teams creates a boundary over which understanding can degrade. This is especially true of teams that approach their work with different skill-sets, such as design and development teams. This loss in fidelity in understanding the theory or mental model behind a decision, design, or complete solution can wreak havoc on outcomes. These types of handoffs allow our teams to slide quietly back into waterfall.We see this mistake time and time again in our work. And each time I consider it an oddity given that both HCD and agile place a disproportionate value on face-to-face communication over documentation or specification. Being a truly cross-functional team is hard work but it’s the only way to avoid the pitfall of handoffs.

Iteration and Refactoring

In agile contexts, we often use the word iteration to mean a series of time boxes each of which contains a given amount of work. But real iteration is not about the continuum of time, ticking off tasks, but about iteratively evolving the subject matter.

This misuse of the word is yet again one more signal of a propensity to fall back on waterfall, a failure of a “worse but easier” mindset. We do not build digital experiences like we build houses: first the foundation (100% complete) then the framing (100% complete) then the plumbing and electrical (100% complete), drywall, doors, and on until it’s all done. Rather, you should build a feature in a way that solves a problem and then iterate on it over time to solve the problem in better and more complete ways at each stage. The following visualization will help:

We see this danger not just on the development side of projects but also in design where perfect becomes the enemy of good all too often. UI designers need to resist the urge to wait to present work until it is in a “final” state because the truth is that it won’t ever be finished. Refactoring should happen both in code and in design.

Principles That Make HCD+Agile Work

If it is true that these two philosophies are indeed better together than apart what are the underlying principles that make such a marriage work?

Unrelenting iteration that places little to no value on previous coding. Iteration that isn’t just moving on to the next thing when we cross a time box boundary but that truely “iterates” a feature. This prevents earlier work from diverting the project away from user needs by way of the “sunk cost” myth. Developers (and designers too) must be willing to unceremoniously throw away previous work when a better outcome for the user is discovered.

User research is always needed and usually needs to be refined throughout a project. This is especially true for highly innovative projects that are forging new paths. The more innovative and groundbreaking, the more research is needed. Research also needs to be done intentionally with best practice techniques – we’ll explore these methods in greater depth in another article.

Ideal teams have balanced skills. In our experience, this is somewhere around 1.5-2 developers to every 1 designer/researcher. Depending on the size of the team and the project in question they also need the proper supporting cast of product owner, operations expertise, business strategy analysts, and quality control.

Agile methods and HCD will only support and complement each other so long as there is mutual respect and common understanding between designers, developers, and the whole project cast. In our experience we often see engineering teams view designers as support roles rather than integral to delivering value, this must be resisted.

Teams must be prepared for the natural ebb and flow on a project that is being informed by an evolving understanding of the user’s needs. This means changes in scope, timeline, release cycles, staffing, and refactoring. Flexibility, tenacity, and resilience are essential for high functioning teams.

Productivity should be measured by value delivered to a user, not by quantity of work. This implies that user testing is ongoing throughout a project to measure this value. Velocity and story points are fine for determining what might be accomplished in an iteration, but they should never be a measure of completeness or productivity.

—

In our next post we’ll get tactical and share a process framework for bringing HCD and agile together.

You don’t put a horse with a broken leg in a race and then kick it when it doesn’t win.

Now, there are many interpretations to this turn of phrase but I always took it to mean that people are who they are right now. People react and behave in a manner consistent with their experiences and values at this very moment. And, it’s hard for them to break out of this mold, even if desired. It’s not an excuse for acting a certain way, but it is an explanation, and an empathic one.

Organizations and companies are like this too. Groups of people develop a culture, a collective personality in which some edges are smooth, some jagged, some soft, and others hard as nails.

Good consultants will know this going in to any new engagement, sales call, or mentoring session. Good consultants meet people and teams where they are. Always with the goal of affecting improvement and growth of course, but not with the presupposition that growth can be bestowed, but that it can only be fostered.

At Tandem(software development company), I’d like to think that we meet customers where they are. They often come to us with baggage, broken processes, or poorly performing teams. This is not their fault, it is merely the state they’re in and it’s our job to help, in whatever small or large way possible. This is incredibly challenging, and something we ourselves are learning and maturing around. I’d like to share a few ways that we try to meet people where they are.

Listening and Mirroring

As with any good relationship, it all starts with listening. In this case though, you have to listen between the words. In the setting of a new relationship people will rarely tell you the whole story, and what you can really, truly, help them with may be hiding behind the specifics of their inquiry. So we do what we can to hold our tongues and take in as much information as we can.

I’ll let you in on a little secret, we talk about customers behind their backs a ton. Not in the way you’re thinking though, we spend a lot of time synthesizing how we read between the lines in the last meeting, what the person was really saying in that email, and how our responses will be interpreted.

This all allows us to mirror the customer in certain ways. Focusing on the things they think are important to them even when we may have the intuition that the real work lies elsewhere. Mirroring a customer’s own feelings about things helps to accumulate that intangible trust capital that can be later spent to move in the direction where we can be most helpful.

Countering and Balancing

I mentioned earlier that clients sometimes come with baggage, and oh boy do they. Over the past year we’ve taken on a number of rescue projects, initiatives that have failed or are failing for one reason or another. These all come with baggage: financial, personnel related, technical, emotional, you name it.

In these cases there’s almost always one overriding factor in the failed project that’s out of balance. It could be that the client’s internal team has a few bad apples spoiling the lot. It could be that they’re financially strapped and the last consulting firm dropped them rather than working with them. It could be they chose a bad vendor that couldn’t deliver and they had no visibility until it was too late. Regardless what the issue is, we try to find that and counter it, bringing the system back into balance.

As an example, at the beginning of a recent project we noticed the client being particularly agitated around when the next meeting was going to be after each previous meeting. It was very curious, but we later learned that their previous interactions with developers had been very haphazard and unpredictable. Quickly countering this by setting up two or three meetings in advance and sending calendar invites with an agenda gave us instant credibility.

Before I move on, I want to address technical debt and “legacy code”. This is another common area of baggage which our team deals with when spinning up on new clients. Developers like new and shiny, no doubt about it, but sometimes what a client really needs is help with old and dirty. This is something our team is good at and getting better every day. It takes a special set of skills and patience to methodically plod through a messy code base, see the path to refactoring, and then on to new features – all while staying upbeat, curious, and engaged.

Giving and Mentoring

One of the best ways to meet customers where they are and still move them towards a better state is to give things away for free. People will rarely pay you for things they don’t perceive to have value, but they’ll often take you up on an offer of free assistance in those areas.

Knowing that a customer has a serious issue with having too many junior members of their team which they themselves can’t see might lead you to offer some free mentoring. “Would it be alright if we pulled Sarah and Mark onto our team for a week so they can work with some of our folks? We’ve got a week of downtime for two people and we’d be happy to offer that free of charge. It might help them gain some experience with X.”

That kind of thing almost never gets turned down. The side effect in most cases is that the client now attaches value to that activity. Why were Sarah and Mark so much more productive last week? Well, it’s because some senior folks from Tandem spent a week pair programming with them. When it makes financial sense this kind of thing almost always pays back dividends.

~~

I want to conclude by saying that this is a journey. Just like we need to meet customers where they are, we are somewhere too! A healthy dose of introspection and self-awareness makes an enormous difference in your ability to empathize with another party’s situation. I’m proud that this is something we work on at Tandem.