Digital Transformation Tech Talk: Data Governance and Management

With AI technologies taking the digital revolution to the next level so quickly, it can be easy to bypass common sense best practices regarding sensitive data. Agile companies are in a race to take advantage of the AI part of the digital movement, which is why core principles such as data governance and data management might take a back seat. There’s nothing sexy about:

1. putting together a data governance framework

2. hosting a few sessions to hammer out a set of data management practices and operations based on that strategic framework, then

3. socializing it to the various IT cloud teams that handle data

Even though data governance and management may not seem exciting, it’s crucial to have policies and agreed-upon practices in place to handle complicated situations involving data integrity. One such scenario arises when there are conflicting versions of entity data after recovering it from a damaged backup database. When data is considered the master, it is assigned a special identifier called a gold ID. If this master record is replicated to other databases, it’s imperative to ensure that all copies remain consistent, even in backup databases. In the event that one of these replicated databases becomes corrupted, it becomes necessary to have a defined process for accurately and safely restoring that database.

So what does data governance look like? There are some templates online to get started. I put together this governance guiding document based on previous consulting work I did as part of a strike force of architects with financial and healthcare corporate clients. I also found an outline on the AHIMA website a good point of reference for structuring a governance document, which I used as an outline below. In subsequent articles, I’ll dive into more details and provide the basics for cloud data management principles and operations, especially when it comes to data I/O ingestion in a multitenant architecture.

Here’s a healthcare industry example of a core data governance document to lay the foundation for a framework in any industry:

The characteristics of data quality can be summarized as follows:

· Accuracy: Data should be error-free and correct.

· Accessibility: Measures should be in place to ensure data availability when needed.

· Comprehensiveness: Data should contain all the necessary elements.

· Consistency: Data should be reliable and consistent throughout the entire patient encounter.

· Currency: Data should be up to date and current.

· Definition: All data elements should have clear definitions.

· Granularity: Data should be at an appropriate level of detail.

· Precision: Data should be collected in its exact form with precision.

· Relevancy: Data should be relevant to its intended purpose of collection.

· Timeliness: Documentation should be entered promptly, updated regularly, and available within specified time frames.

Many healthcare organizations understand the need for data governance, but may not understand where to begin or how to establish a robust data governance program. One potential obstacle to implementing healthcare data governance at an organizational level is a lack of understanding among key stakeholders regarding data as an asset. This can lead to data silos and delays in developing a comprehensive program.

Healthcare data governance should encompass the entire organization, involving interdisciplinary teams comprising subject matter experts. The primary aim of healthcare data governance is to foster an organizational culture that prioritizes data security, reliability, and accessibility for authorized individuals. When the entire organization is engaged, a data governance culture is established, resulting in a strong program. To cultivate a healthcare data governance culture, it’s good to start with baby steps that demonstrate the value and benefits of data governance.

In order to implement a healthcare data governance plan or program, the first step is to define the concept of data governance and determining its scope. This entails establishing a foundational framework for collecting, retaining, utilizing, accessing, and sharing healthcare data. This framework encompasses various aspects such as policies, procedures, standards, ownership, decision rights, roles and responsibilities, and accountability associated with the data.

To effectively establish healthcare data governance plans or programs, organizations should form a dedicated team called the Data Governance Management Team (or a similar name). This team should include key individuals such as the Chief Data Officer (or an equivalent position) working in collaboration with the Chief Medical Information Officer. Together, they will spearhead the efforts to develop and implement robust healthcare data governance initiatives.

If interested in more healthcare data governance, check out the PDF file on the AHIMA website here.

DATA RETENTION POLICY

A compliant data retention policy defines the duration for which data must be retained to meet regulatory and/or organizational requirements. On top of that, it specifies the actions to be taken once the retention period has expired. Organizations may choose to delete (or destroy) or archive data based on their retention guidelines.

These policies and procedures, or standard operating procedures (SOPs), provide a structured framework for efficient Data Governance, guaranteeing data integrity, appropriate access, privacy compliance, secure data sharing, and quality data retention.

Conclusion

To restate, in the fast-paced digital landscape IT finds itself today, driven by AI technologies like ChatGPT, it is crucial for technical organizations to not overlook fundamental best practices concerning sensitive data. While agile companies strive to harness the power of AI within the digital revolution, core principles such as data governance and data management can sometimes be neglected. Establishing a robust data governance framework and defining data management practices and operations based on a strategic framework may not seem glamorous. However, it is a necessary step for organizations to take. This involves conducting sessions to develop a comprehensive data governance framework and subsequently sharing and integrating it with the various IT cloud teams responsible for data handling.

How to Pick the Right Number of IT Cloud Team Members

On Medium and Substack

Coming up with a healthy, balanced ratio of the number of team members to number of clients is still a relatively subjective exercise. Not quite scientific yet. There are rules of thumb out there to start with, but it ultimately comes down to your requirements and the size of your B2B clients and B2C customer base. Also, the amount of request for new features or bug fixes spawns customer telemetry data that will factor into the ratio.

The following provides a rule of thumb starting point for your fine tuning needs based on personal observation in a consulting professional capacity over many years:

· Solution Architects: 1 for every set of 4 or 5 typical quarterly release projects or B2C clients

· Database Team: 1 to 5

· Networking Team: 1 to 5

· OS Sys Admin Team: 1 to 7

· Monitoring Team: 1 to 3

· Security: 1 to 5

· R&D: 1 to 10

Continuously capturing and tracking team role and skill inventory will help in determining these ratios, calibrating them over time.

Example Cloud Team Structure: Monitoring and Alerting

How many cloud monitoring team members do you need to support B2B corporate clients?

The number of cloud monitoring team members required to support B2B corporate clients can vary widely depending on the size and complexity of the clients, the scope of the services being offered, and the level of support required by the clients. However, some factors that can help determine the appropriate staffing levels for a cloud monitoring team might include:

1. Number and size of clients: The more clients you have and the larger their businesses are, the more team members you will likely need to support them effectively.

2. Service scope: The more services you offer and the more complex they are, the more team members you may need to monitor and maintain them.

3. Client service level agreements (SLAs): If your clients have SLAs that require a high level of service availability and response times, you may need more team members to meet these requirements.

4. Automated vs. manual monitoring: The more automated your monitoring is, the fewer team members you may need to support your clients.

With these factors in mind, a typical cloud monitoring team for a B2B corporate client might include anywhere from 5 to 15 team members, depending on the size and complexity of the clients being served. This team might include roles such as:

1. Cloud monitoring manager or team lead

2. Cloud monitoring engineers or technicians

3. Customer support specialists

4. Product Managers/Owners, Project managers or coordinators

Hope this helps give your sprint planning a starting point. Determining the optimal staffing levels for a cloud monitoring team relies on various factors that are unique to your organization and clients. I recommend you thoroughly evaluate your clients’ needs, including number of users and groups, and the level of assistance necessary to guarantee that you have the right staffing levels to deliver dependable and excellent services.

Industrial Era Leadership Styles Don’t Work in the Digital Era

On Medium and Substack

Recall the bygone era of robber baron executives who drove the Industrial Revolution. If you’re not coughing from the endless plumbs of smoke from the chimneys of gloom that harmed many lungs, you might recall that the leaders of those 19^th century corporations drove insane revenue goals at all costs. With some regulations and shifts in economic mindsets, things have improved, though the DNA of those industrial leadership styles still exist.

And then came the digital revolution.

The adoption of digital technologies and processes in manually intensive businesses has been ongoing for a while, and the COVID-19 pandemic expedited this movement as more employees had to work remotely. To enhance customer service and overall experience, businesses have been redesigning their processes using agile methods. Additionally, IT departments have been utilizing continuous Agile DevSecOps pipelines to provide cloud solutions. However, despite all of these efforts, one crucial aspect that needs to be addressed is the transformation of management practices.

Transforming management is the final frontier in achieving complete digital transformation. Although some organizations have realized this, many still have not, despite over two decades of agile thinking evolution. Failure to modernize management practices can lead to outdated practices and threaten digital transformation efforts. It’s like taking two steps forward and then taking three steps back if modernization of management practices is not adopted.

What Went Wrong with the Industrial Era Leadership Style?

The Industrial Era leadership styles were developed during a time when organizations were structured differently, and the work being done was largely manual and repetitive. The focus was on efficiency, productivity, and achieving economies of scale. The typical leadership style during this era was command and control, where managers were expected to be authoritarian and make decisions for their subordinates.

However, in the digital era, the nature of work has changed significantly. The rise of technology and automation has meant that much of the manual labor has been replaced by machines, and employees are increasingly required to think critically, collaborate, and innovate. As a result, traditional Industrial Era leadership styles don’t work in the digital era for several reasons:

Flexibility
Empowerment
Collaboration
Innovation
Emotional Intelligence

Flexibility

Digital era businesses need to be flexible and adaptable to rapidly changing market conditions. Leaders need to be able to pivot quickly and adjust strategies as needed. This requires a leadership style that is open to experimentation and willing to take risks.

Empowerment

The digital era workforce expects to be empowered and given the autonomy to make decisions. Leaders need to create an environment where employees feel empowered to take risks, make mistakes, and learn from them.

Collaboration

Digital era work often requires collaboration across teams and departments. Leaders need to be able to facilitate this collaboration by creating an environment that encourages communication and teamwork.

Innovation

In the digital era, innovation is key to staying competitive. Leaders need to foster a culture of innovation by encouraging experimentation and rewarding creativity.

Emotional Intelligence (aka “Technical Empathy”)

In the digital era, leaders need to have strong emotional intelligence to effectively manage and motivate a diverse workforce. This means being empathetic, listening to feedback, and understanding the needs and motivations of their employees. In agile practices, specifically regarding sprints, the retrospective at the end of the sprint is one of the best way to help hands on investors, executives and upper management be more empathetic with sprint team workers. I am planning an entire article on the importance of technical empathy in the chain of trust from investors, to executives, all the way down to sprint team members, and vice versa.

Examples of some of the shortcomings of industrial era “robber baron” leadership styles

Industrial era “robber baron” leadership styles were characterized by a focus on maximizing profits at any cost, often at the expense of workers, consumers, and the environment. Some of the shortcomings of these leadership styles include, but not limited to:

Exploitation of Workers	Robber baron leaders often paid workers very low wages, subjected them to dangerous working conditions, and denied them basic benefits like sick leave and health insurance
Monopolistic Practices	Robber baron leaders used their wealth and power to buy out competitors, creating monopolies that stifled competition and innovation. This led to higher prices for consumers and limited choices in the marketplace
Environmental Damage	Robber baron leaders often showed little regard for the environment, engaging in practices that caused significant damage to natural resources and ecosystems
Corruption	Robber baron leaders often used their wealth and power to influence government policies and regulations in their favor, engaging in corrupt practices that favored their own interests over the public good
Lack of Accountability	Robber baron leaders were often able to operate with little oversight or accountability, as they wielded significant power and influence over government officials, regulatory agencies, and the media

Personifications of industrial era robber baron leaders include Andrew Carnegie, John D. Rockefeller, and J.P. Morgan. Their leadership styles were characterized by a focus on maximizing profits and accumulating wealth, often at the expense of worker safety, consumers, and even the environment. While these leaders were successful in their time, their legacy has been tarnished by the negative impact they had on society and the economy. Though many of these bad CEO shenanigans have been checked by regulation, it is undeniable that many organizations profess to do the right thing by their employees and consumers, but in practice, do the opposite. I won’t name specific companies, but you can Google recent lawsuits regarding employee wage theft, cancer causing products, etc.

How Different is Today’s Industrial Era Leadership Mindset Compared to Robber Barons?

While there may be some similarities between today’s hands-on investors and C-level executives and the industrial era “robber baron” leaders and investors, it’s important to recognize that there are also notable differences in leadership styles and business practices.

Similarities

One similarity is a focus on maximizing profits and achieving rapid growth, often at the expense of other stakeholders such as workers and the environment. Some investors and executives may prioritize short-term gains over long-term sustainability, which can lead to unethical or unsustainable practices.

Another similarity is a willingness to take risks and pursue aggressive business strategies. On the one hand, this can lead to disruption and innovation in the marketplace. But on the other hand, it can also create significant social and environmental challenges. In the 19^th century, it was not uncommon for workers to work up to 18 hours a day, no breaks, 6 days a week, for under $2 a day. Even in those days, that was still not enough to take care of a family.

Differences

Thankfully, there are also several key differences between today’s hands-on investors and C-level executives and the industrial era “robber barons.” For example:

Without regulatory oversight, social responsibility, and stakeholder engagement, it’s likely that some of today’s hands-on investors and C-level executives would have leadership styles similar to their counterparts in the industrial “robber baron” era. In the absence of these constraints, there would be few incentives for these leaders to prioritize the interests of workers, consumers, and the environment over their own financial gain.

Without regulatory oversight, some investors and executives would be free to engage in monopolistic practices, engage in corrupt activities, and exploit workers to maximize profits. Without social responsibility, there would be little incentive to consider the long-term impacts of their business decisions on the environment and society. Without stakeholder engagement, investors and executives would be less likely to consider the interests of workers, customers, and the broader community. All of these can in effect increase the risk of failures in digital transformation as knowledge workers would be less motivated to innovate and more incentivized to hide or even “quiet quit.”

However, keep in mind that regulatory oversight, social responsibility, and stakeholder engagement are not the only factors that influence leadership styles. There are many other factors that can shape the way leaders execute the corporate vision, including their personal values, organizational culture, and the broader social and economic context. Therefore, while these factors can help to prevent some of the worst excesses of unregulated capitalism, they are not a guarantee of ethical and responsible leadership.

Conclusion

To succeed in the digital era, leadership styles need to evolve beyond those of the Industrial Era. Flexibility, empowerment, collaboration, innovation, and emotional intelligence are crucial for effectively managing a rapidly changing workforce and staying competitive in the global marketplace. While there may be some similarities between today’s hands-on investors and C-level executives and the industrial-era “robber barons,” modern leaders must take into account the regulatory oversight, social responsibility, and stakeholder engagement required in today’s business landscape. Leaders must recognize the challenges of the past and work towards creating a sustainable and responsible business model for the future. Exhibiting “technical empathy” via retrospectives and analyzing product and sprint backlogs can help leaders transition from the industrial era mindset to the digital era.

Introduction to Optimizing Cloud Team Structures for Continuous Product Improvement

Editor’s Note: Also featured on Medium, LinkedIn and Substack

Since 2020, many organizations launched digital transformation initiatives to automate their processes and adopt or migrate their technology operations to the cloud. Surveys by large analytics organizations such as McKinsey and Gartner have suggested that most have failed for a variety of reasons.

It is difficult to provide a precise number of failed initiatives as there are no publicly available statistics on the number of digital transformations that have fallen short in corporations since 2020. However, it is generally accepted that the success rate of digital transformation initiatives is not particularly high, with various surveys and reports suggesting failure rates ranging from 60% to 84%.

There are several reasons why digital transformation initiatives can fail, including a lack of clear executive strategy and leadership, inadequate investment in technology and talent (including cloud team structures and staffing mix), resistance to change from employees and customers, and a failure to align digital transformation efforts with business goals and complex customer needs.

It is worth noting that the COVID-19 pandemic has both accelerated the need for digital transformation in many organizations and created new challenges for digital transformation initiatives. Many organizations have had to adapt quickly to new ways of working and engaging with customers, which has put additional pressure on digital transformation initiatives. This has led to an underestimating of complexity of cloud team structures which are needed for a continuous product improvement process that leads to high Quality of Service (QoS) for customers.

In any case, it is clear that digital transformation is a complex and challenging process that requires careful planning, execution, and ongoing adaptation to changing circumstances. While some digital transformation initiatives may fail, it is important for organizations to learn from these experiences and continue to pursue digital transformation in order to remain competitive in today’s fast-paced, digital-first business environment.

The implication is that optimizing the structure and staffing of an IT cloud team can be a challenging, often complex process. There are a few key considerations that executive leadership and upper management can take into account to make the most of their staffing resources:

· Define clear cloud teams, roles and responsibilities

· Determine the necessary skill sets

· Consider the size and complexity of the cloud environment

· Balance in-house and outsourced resources

· Foster a culture of continuous learning, research and development

Define clear cloud teams, roles and responsibilities

The establishment of precise roles and responsibilities within a cloud team is an integral component of accomplishing organizational objectives. This facilitates the comprehension of individual responsibilities, enabling team members to better grasp the impact of their contributions towards the overarching organizational vision. In other words, they see the direct value of their sprint team contributions to solving customer problems. This methodology also serves to remove redundancies and channel the team’s efforts towards areas of high importance. Further, it is imperative to ensure sufficient staffing levels in each role to guarantee optimal customer service delivery.

The monitoring team, for instance, can be staffed adequately to proactively identify and troubleshoot customer problems before the customer discovers them. In the case of large organizations, the establishment of a personnel-to-client, product, or project ratio is a judicious decision to ensure the effective allocation of resources. Aligning team member counts to project ratios helps to provide good coverage to the number of clients and customers your organization has. This is especially important for B2B client scenarios, where having one or two developers may not be enough for 20 large B2B clients, each with millions of users.

Determine the necessary skill sets

For any given cloud or digital transformation project, there are certain skills need that must align with user requirements with emphasis on scaling the number of skilled workers with the size of the customer (B2B) or customer base (B2C). It is essential to identify the highly specialized skill sets required to support cloud infrastructure, including proficiencies in:

· distinct cloud platforms (SaaS, PaaS, IaaS)

· programming languages, and

· security protocols

This strategy aids in directing recruitment and training endeavors and guarantees that the team possesses the appropriate blend of expertise.

Consider the size and complexity of the cloud environment

The magnitude and intricacy of the cloud environment can significantly affect the personnel requirements of the team. A diminutive and less intricate environment may demand a modest team, while a vast and multifaceted environment may necessitate multiple and more specialized teams.

Let’s unpack this a bit. Assume that a company is using a public cloud service provider (CSP) for their operations. They have established a dedicated cloud monitoring team to oversee and manage their cloud infrastructure. In this scenario, the size and complexity of the company’s cloud environment would be the primary determinants of the necessary staffing levels for the monitoring team. Some organizations ignore this critical factor to their detriment, which is often where cloud migrations and digital transformations fail.

For a smaller cloud environment with limited cloud resources and services, the monitoring team may comprise a few personnel with a general understanding of cloud infrastructure and basic monitoring tools. The small mom and pop IT shops won’t be dealing with several major B2B clients or millions of users in their customer base. On the other hand, a larger and more complex cloud environment, with multiple cloud services and resources, may require a more extensive monitoring team with highly specialized roles, such as cloud security specialists, network monitoring experts, cloud architecture professionals, and data analysts.

In this way, the staffing requirements of the cloud monitoring team would depend on the size and complexity of the cloud environment, and the necessary skill sets for the team members would be based on the specific cloud services and resources being utilized.

Balance in-house and outsourced resources

It is crucial to identify the most advantageous equilibrium between in-house/onshore and outsourced/offshore resources. This could involve utilizing third-party vendors for particular functions, such as cloud security, while maintaining essential development and maintenance tasks in-house. For instance, cloud monitoring and alerting might require 24/7 operation with coverage in various regional time zones, necessitating multiregional team coverage.

Determining the optimal balance between in-house/onshore and outsourced/offshore resources can have several cost advantages and disadvantages for an organization. One of the primary cost advantages of outsourcing is the potential for reduced labor costs. Outsourcing to offshore locations may allow companies to benefit from lower labor costs in countries with lower wage rates, thus reducing overall operational expenses. Additionally, outsourcing specific functions, such as cloud security or data entry, may be more cost-effective than hiring in-house staff with the same expertise.

On the other hand, outsourcing may have a few drawbacks. For instance, communication issues may arise due to language/cultural barriers or time zone differences, which may impact project timelines and increase costs. Time zone difference can be a big factor in managing quality of service (QoS) for customer service level agreements. Monitoring and alerting, for instance, can be rendered useless if a major B2B client in the Central Time zone has to wait for Level 1 or Level 2 support in an Asian time zone. There may also be additional costs associated with managing the outsourced team, such as oversight and coordination expenses. Additionally, outsourcing may reduce the level of control and oversight that an organization has over its operations and data, potentially leading to security risks.

Maintaining in-house staff can be advantageous in terms of control and flexibility. An in-house team is typically easier to manage and can respond more quickly to changing business needs. Additionally, it can be easier to ensure the quality of work when it is done in-house. However, in-house staffing may also be more expensive than outsourcing, as it requires investing in hiring, training, and retaining staff with specialized skills and knowledge.

Ultimately, the most cost-effective approach will depend on various factors, including the size and complexity of the organization’s operations, the expertise required for specific functions, and the cost of labor in different regions. Therefore, it is essential to carefully weigh the advantages and disadvantages of each approach and determine the most effective strategy for the organization.

Foster a culture of continuous learning, research and development

Cloud technology is constantly evolving, so it’s important for the team to stay up-to-date with the latest developments and trends. Management can foster a culture of continuous learning by providing access to training and development opportunities and encouraging team members to stay current with industry developments. Having an R&D team, in association with a corporate training team, can ensure that the organization is discovering new technologies that can improve team productivity. The training team can continuously plan and coordinate training for new technologies.

Conclusion

In conclusion, there are certain strategies management can plan and implement to optimize the structure and staffing of their IT cloud team, ensuring that it is well-positioned to support the organization’s strategic objectives. The process of digital transformation is a challenging and intricate journey that necessitates meticulous planning, implementation, and continuous adaptation to dynamic conditions.

While a number of organizations may experience setbacks during their digital transformation (DT) initiatives, it is crucial to derive lessons from these experiences and pursue DT to remain competitive in the rapidly evolving, digital first business world. Industrial era management strategies are obsolete. Optimizing the structure and staffing of an IT cloud team while transitioning from the industrial mindset can also be a complex process.

As such, there are key considerations that executive leadership and upper management can take into account to maximize their technical staffing resources. By adopting a strategic and comprehensive approach to staffing, organizations can leverage the benefits of cloud technologies and improve their business outcomes.

Digital Agile Strategies: When the Sales, Product and Sprint Teams Work in Tandem

The way a company makes money is by selling products and services to the public. Without sales, no revenue comes in. Revenue, and especially profits, are the lifeblood of an organization. Cut that off, and the company dies. Therefore, the sales staff must constantly sell, sell, sell at all costs to keep the company alive. It’s really that cut and dry.

Or is it?

Side note: This article also appears on Medium.com

True, the sales team is like the priesthood of capitalism that keeps the company’s future alive by sacrificing itself regularly. They should be applauded for this effort. But there is a limit on how much capacity the product team has to support a highly aggressive sales team. If you’ve been in technology long enough, even beyond IT, you know the delicate balancing act between aggressive sales on one hand, vs aggressive timelines to push out quality products based on features in the product backlog and tasks in the sprint backlog.

Product teams are caught in the pinch between the successful sales team, and the quality driven sprint team. If the sales team is too aggressive, product quality may suffer. If, on the other hand, sprint teams are behind schedule, the product team risks losing a sale that cuts the sales team commissions. Both of these scenarios can result in reputational damage as potential customers can get frustrated, terminate any sales agreements, and buy from a competitor.

Balancing the motives and goals of the sales, product and sprint teams is never an easy exercise as business forces can change dynamics rapidly. However, despite the temptation to revert back to ego driven knee jerk reactions to business events, it is crucial for

The sales team to be in alignment with the agile product team to ensure that the product quality meets customer expectations
The product team to be in alignment with the agile sprint team for the same reason

Aligning Sales and Product Teams

The following graphic highlights some strategies the sales and product teams can implement to ensure that product quality meets customer expectations:

Collaborate on product requirements

Working closely together at the sales and product team level improves the chances that customer requirements are well understood and documented. The sales team can provide valuable insights into the customers’ pain points, preferences, and expectations, which in turn can be used to prioritize quarterly product features and enhancements.

Attend sprint demos

The sales team should attend sprint demos to witness firsthand the progress made by the product team. They can also provide real-world feedback on how well the product is aligning with customer needs. This will allow the sales team to have some visibility into the product development process, as well as help identify any gaps or areas that need improvement.

Provide customer feedback

The sales team should be the primary source of customer feedback and possibly user story input for the product team. They should provide surveys or plain text feedback on customer satisfaction, feature requests (hopefully in the form of user stories), and pain points to help the product team adjust priorities and make product improvements.

Attend retrospectives

Some product teams may hesitate to invite the sales team to retrospectives, but there is some value at times in doing so. The sales team, once it understands the nature and importance of this exercise, should attend retrospectives to provide feedback on the product development process and collaborate with the product team to identify areas for improvement. This will help the product team to continuously improve the quality of the product and ensure it meets customer expectations.

Develop a shared understanding of quality

The sales team and product team should develop a common understanding of what constitutes high-quality products. This shared understanding should include customer expectations, usability, and performance metrics, among others.

In summary, by collaborating on product requirements, attending sprint demos and retrospectives, providing customer feedback, and developing a shared understanding of quality, the sales team can align with the agile product team to ensure that product quality meets customer expectations.

Aligning Product and Sprint Teams

Continuing, the chain of collaboration between the sales and product teams extend to the collaboration between the product and sprint teams. To maintain product quality, the product team must be in alignment with the agile sprint team continuously. A few ways the product team can align with the agile sprint team to achieve continuity include:

Collaborate on sprint goals

The product team should work closely with the sprint team to define sprint goals that are aligned with the product roadmap and customer needs. By setting clear goals, both teams can ensure that the work being done during the sprint is focused and contributes to maintaining product quality.

Define acceptance criteria

The product team should define acceptance criteria for each user story or feature being developed during the sprint. The acceptance criteria should outline the conditions that must be met before a user story or feature is considered complete and of acceptable quality. This ensures that everyone on the sprint team understands what is required to deliver a quality product.

Conduct high level code reviews

The product team should participate in code reviews, with the guidance of the solution architect assigned to the product backlog or at least the most senior technical leader of the sprint team. This approach is a best practice, helping to make sure the code being developed during the sprint meets the product team’s quality standards. This can include reviewing code for readability, maintainability, and adherence to coding standards.

Provide effective feedback and business guidance

The product team should provide feedback and guidance to the sprint team throughout the sprint. This can include reviewing and providing feedback on user stories, features, and design decisions, as well as providing guidance on how to address any quality issues that arise during development.

Collaborate in sprint reviews and retrospectives

The product team should participate in sprint reviews and retrospectives to provide feedback on the quality of the product and the development process. This will help identify areas for improvement and enable the team to continuously improve the quality of the product.

By collaborating on sprint goals, defining acceptance criteria, conducting code reviews, providing feedback and guidance, and participating in sprint reviews and retrospectives, the product team can align with the agile sprint team to maintain product quality. As a result, the emphasis on optimal quality will ensure that the product meets customer needs and expectations while adhering to high quality standards.

How agile sprint planning and sprint retrospectives can improve crucial conversations

Agile sprint planning and sprint retrospectives can improve crucial conversations between C-level executives, product managers, and sprint teams in several ways:

Encourages collaboration
Creates transparency
Facilitates alignment
Encourages continuous improvement

Collaboration

Agile sprint planning and sprint retrospectives are collaborative processes that involve input from all stakeholders, including C-level executives, product managers, and sprint teams. This might be surprising for some agile practitioners, but sprint planning and retrospectives are actually important business process in the digital era. In working together, they can gain a deeper understanding of each other’s perspectives, identify potential roadblocks, and find solutions to address them.

Transparency

Agile sprint planning and sprint retrospectives together promote transparency by providing regular updates on the progress of the project. Providing continuous updates can help C-level executives and product managers gain insight into the sprint development process, and identify areas where they can provide support or resources. The basis for C-level support of the team is what can be the basis of what’s called “technical empathy.”

Alignment

Agile sprint planning and sprint retrospectives help align the goals and priorities of all stakeholders involved in the project. By having a shared understanding of the project’s objectives and progress, C-level executives, product managers, and sprint teams can work together more effectively towards a common goal.

Continuous Improvement

Agile sprint planning and sprint retrospectives provide opportunities for continuous improvement. During the sprint retrospective, the sprint team reflects on what worked well, followed by what didn’t. The team then identifies areas for improvement. This crucial feedback can help C-level executives and product managers understand the team’s needs, as well as identify ways to support the team in achieving their goals.

Conclusion

The product team finds themselves caught between the competing interests of the successful sales team and the quality-driven sprint team. If the sales team is too aggressive, it could lead to a decrease in product quality. Conversely, if the sprint teams fall behind schedule, the product team risks losing a sale, which in turn could reduce the commissions of the sales team. In both scenarios, the company’s reputation may suffer as frustrated customers could terminate sales agreements and turn to competitors.

Maintaining a balance between the objectives and goals of the sales, product, and sprint teams can be a challenging task as market forces can change rapidly. Despite the temptation to react impulsively to business events, it is crucial for:

The sales team to work in concert with the agile product team to ensure that the product quality meets customer expectations
The product team to collaborate with the agile sprint team to achieve the same goal.

Generally speaking, both agile sprint planning and sprint retrospectives create a collaborative and transparent environment that fosters (1) open communication and (2) continuous improvement. Avoiding breaks in collaboration keeps the sprint team alert and ready to respond to business events. By encouraging crucial conversations between C-level executives, product managers, and sprint teams, an organization can help ensure that each member of each team is working towards the same goals and priorities, which is not exactly an easy proposition in an ever changing digital world. At the end of the day, the project is has to be successful in meeting customer needs and business objectives for the given product.

How Executives Can Improve Their Leadership via Agile Portfolio Management

Note: This article also appears on Medium and LinkedIn

The agile revolution in IT, and beyond, has been transforming organizations of all sizes since 2001, when the Agile Manifesto first got unleashed on the public. Even before then, I was actively involved in the Rational Unified Process community where some of the minds behind the manifesto were also active. Back then (circa late 1990s), IT was going through the distributed client-server revolution as IT started to move beyond mainframes (which are still active in older organizations, mind you). Executives and upper management in those days demanded lots of technical documentation that would usually not be useful to the technical SMEs, but sat as trophies in the offices of corporate leaders.

But agile thinking came along to shatter the notion of “too much documentation.” Not that it was not important, but that teams should only produce just enough to satisfy leaders while being practical enough for sprint teams to find useful. In my opinion, this silent disconnect between the technical sprint teams and leadership was, and is, a symptom of a deeper rift in organizational transformation strategies vs tactics. Cloud computing, especially after the pandemic years of 2020-2022 with an accelerated digital transformation push, exposed even deeper rifts, resulting in most digital transformation initiatives failing. I’m relying on reports by McKinsey and Gartner on the stats for such failures.

This divergence between self-organizing sprint teams and executive leadership got me to thinking of my own observation as a consultant and executive level cloud solution architect over the years. I have seen companies that adopted and pivoted their strategies around agile management thrive very well, while others that resisted it or did not fully embrace it struggled. How can we turn this around for the latter? I my experience, enabling self-organizing teams and getting better acquainted with product and sprint backlogs should be one of the top work items for executives and even hands on investors who sometimes distrust their board’s pick of said executives.

Recently, I decided to do a little AI prompt engineering with ChatGPT to have a “discussion” on how large hands on investors, executives and upper management of larger corporations miss out on the hidden added value of agile management principles. I’ll simplify my AI prompts so that they seem more like casual questions rather than geek speak.

Me: How can c-level executives and hands on investors improve their leadership approach using reports and metrics from Agile portfolio management

C-level executives and investors can improve their leadership using reports and metrics from Agile portfolio management by gaining visibility into how the organization’s portfolio is performing and using that information to make data-driven decisions.

Here are some ways that reports and metrics from Agile portfolio management can help C-level executives and investors improve their leadership:

Strategic alignment: Agile portfolio management provides a framework for aligning the portfolio with the organization’s strategic objectives. Reports and metrics can help C-level executives and investors understand how the portfolio is contributing to those objectives, and identify areas where adjustments may be needed.
Resource optimization: Agile portfolio management can help optimize the use of resources across the organization. Reports and metrics can provide insights into resource utilization and identify areas where resources may be underutilized or overutilized.
Risk management: Agile portfolio management can help manage risk by providing visibility into potential risks across the portfolio. Reports and metrics can help identify areas of the portfolio that may be at risk, and help the organization take proactive measures to mitigate those risks.
Performance measurement: Agile portfolio management provides a framework for measuring the performance of the portfolio. Reports and metrics can help C-level executives and investors understand how the portfolio is performing against key performance indicators, and identify areas for improvement.
Transparency: Agile portfolio management provides transparency into the organization’s portfolio and how it is being managed. Reports and metrics can help C-level executives and investors understand how the portfolio is being managed, and provide insights into the decision-making process.

By using reports and metrics from Agile portfolio management, C-level executives and investors can gain a deeper understanding of the organization’s portfolio and make data-driven decisions to improve its performance. This can help the organization achieve its strategic objectives, optimize its resources, manage risk, measure performance, and increase transparency.

Me: How does agile portfolio management align with product management?

Agile portfolio management and product management are closely related and have many overlapping elements. Both focus on delivering value to customers by developing and managing a portfolio of products or initiatives. However, there are some key differences in the focus and scope of each discipline.

Agile portfolio management focuses on managing a portfolio of initiatives or products across an organization, with the goal of maximizing value delivery and achieving strategic objectives. It involves managing resources, prioritizing initiatives, and measuring performance to ensure that the portfolio is delivering the desired outcomes.

Product management, on the other hand, focuses on developing and managing individual products or services within the portfolio. It involves understanding customer needs, defining product requirements, and overseeing the development and launch of the product.

Despite these differences, agile portfolio management and product management are closely aligned and can work together to achieve common goals. Agile portfolio management provides a framework for managing the overall portfolio, while product management provides a framework for developing and managing individual products within the portfolio.

For example, agile portfolio management can help product managers prioritize their product roadmap by identifying the initiatives or products that will deliver the greatest value to the organization. At the same time, product management can provide feedback to the portfolio management team on the success of individual products and initiatives, which can inform future portfolio management decisions.

Overall, agile portfolio management and product management are complementary disciplines that work together to deliver value to customers and achieve strategic objectives. By aligning these two disciplines, organizations can ensure that they are delivering the right products and initiatives to meet the needs of their customers and stakeholders.

Me: For those corporate leaders who may still be adopting agile principles, explain agile portfolio management?

Agile portfolio management is an approach to managing an organization’s portfolio of projects and programs in an agile manner. It involves applying agile principles and practices to the management of the portfolio to improve the organization’s ability to deliver value to its customers and stakeholders.

In traditional portfolio management, projects are selected based on a thorough analysis of their potential returns, risks, and costs. The portfolio is managed through a series of gates, with projects advancing to the next gate only if they meet certain criteria. However, this approach can be slow and inflexible, and may not adapt well to changing business needs.

Agile portfolio management, on the other hand, focuses on creating a flexible and adaptive portfolio that can respond quickly to changes in the business environment. It involves continuous evaluation and prioritization of projects based on their potential value, alignment with the organization’s goals, and ability to deliver results quickly.

The following are some key principles of agile portfolio management:

Prioritization based on value: Projects are prioritized based on their potential value to the organization, with a focus on delivering value quickly and iteratively.
Continuous planning and evaluation: The portfolio is regularly reviewed and updated to ensure that it remains aligned with the organization’s goals and can respond quickly to changing business needs.
Flexible funding and resource allocation: Funding and resources are allocated based on the current priorities and needs of the portfolio, with the ability to adjust as needed.
Collaboration and transparency: Stakeholders are involved in the portfolio management process and are provided with regular updates on progress and results.
Continuous improvement: The portfolio management process is continually evaluated and improved based on feedback and results.

Overall, agile portfolio management enables organizations to manage their portfolio of projects and programs in a more flexible, adaptive, and value-driven manner. It allows them to respond quickly to changes in the business environment and deliver value to their customers and stakeholders more efficiently.

Me: You said a mouthful there lol. What steps are needed to setup agile portfolio management for organizations that have little or no experience?

Setting up an agile portfolio management process can be a complex task, but the following steps can provide a general framework to guide the process:

Define the portfolio vision and goals: The first step is to clearly define the portfolio vision and goals. This involves understanding the organization’s mission, strategic objectives, and business goals, and identifying the portfolio’s role in achieving them.
Establish governance and decision-making processes: Agile portfolio management requires a different governance structure and decision-making process than traditional portfolio management. The governance structure should include roles and responsibilities, decision-making processes, and guidelines for prioritizing and selecting projects.
Define the portfolio backlog: The portfolio backlog is a prioritized list of all the projects and initiatives in the portfolio. It should be based on the organization’s strategic goals and objectives, and should be regularly reviewed and updated based on changes in the business environment.
Identify the agile portfolio management team: The agile portfolio management team is responsible for overseeing the portfolio and ensuring that it is aligned with the organization’s strategic goals. The team should include representatives from different areas of the organization, including business, IT, and finance.
Establish metrics and KPIs: Metrics and KPIs are essential for measuring the success of the portfolio and identifying areas for improvement. The metrics should be aligned with the organization’s strategic goals and should be regularly reviewed and updated.
Implement agile portfolio management tools: Agile portfolio management tools can help automate and streamline the portfolio management process. These tools can include agile project management software, portfolio management dashboards, and collaboration tools.
Conduct regular portfolio reviews: Regular portfolio reviews are essential for ensuring that the portfolio remains aligned with the organization’s strategic goals and is delivering value to its customers and stakeholders. The reviews should be conducted on a regular basis, and should include feedback from stakeholders and updates to the portfolio backlog.

By following these steps, organizations can establish an agile portfolio management process that is aligned with their strategic goals and enables them to respond quickly to changes in the business environment. It is important to note that the process should be continually evaluated and improved based on feedback and results.

Me: Great, thanks. Lets unpack metrics for a bit, what are the most common metrics and KPIs for agile portfolio management?

There are several metrics and key performance indicators (KPIs) that can be used to measure the success of an agile portfolio management process. The following are some of the most common metrics and KPIs used in agile portfolio management:

Value delivered: This measures the value that the portfolio delivers to the organization and its stakeholders. This metric can be measured by looking at the return on investment (ROI) or other financial metrics.
Time-to-market: This measures the time it takes to deliver a project or product to the market. This can be a critical metric in industries where speed-to-market is a key competitive advantage.
Customer satisfaction: This measures how satisfied customers are with the products or services delivered by the portfolio. This can be measured through surveys, feedback forms, or other methods.
Portfolio throughput: This measures the rate at which projects are completed and delivered by the portfolio. This metric can be used to identify bottlenecks and areas for improvement in the portfolio management process.
Team productivity: This measures the productivity of the teams working on the projects in the portfolio. This can be measured by looking at metrics such as cycle time, velocity, and capacity utilization.
Agile maturity: This measures the organization’s level of maturity in adopting agile practices and processes. This can be measured by conducting regular assessments or surveys.
Portfolio predictability: This measures the portfolio’s ability to deliver projects on time and within budget. This can be measured by looking at metrics such as schedule variance and cost variance.

Overall, the metrics and KPIs used in agile portfolio management should be aligned with the organization’s strategic goals and should be regularly reviewed and updated based on feedback and results. It is important to focus on a few key metrics that provide meaningful insights into the portfolio’s performance, rather than trying to measure everything.

Me: Along those lines, what are the best tools that measure metrics and KPIs for the agile portfolio management process?

There are many tools available that can help measure metrics and key performance indicators (KPIs) for the agile portfolio management process. The following are some of the most commonly used tools:

Agile project management software: Agile project management software such as Jira, Trello, or Asana can help track progress, measure team productivity, and manage the portfolio backlog.
Portfolio management dashboards: Dashboards such as Tableau, Power BI, or Klipfolio can provide real-time visualizations of portfolio performance metrics and KPIs.
Collaboration tools: Collaboration tools such as Slack or Microsoft Teams can help facilitate communication and collaboration between portfolio team members.
Business intelligence tools: Business intelligence tools such as SAP or Oracle can help collect and analyze data from multiple sources to provide insights into portfolio performance.
Agile assessment tools: Agile assessment tools such as Agile Health Radars or Agile Maturity Assessments can help assess the organization’s level of agile maturity and identify areas for improvement.
Customer feedback tools: Customer feedback tools such as SurveyMonkey or Qualtrics can help collect feedback from customers and stakeholders, which can be used to measure customer satisfaction.
Financial management tools: Financial management tools such as QuickBooks or Xero can help track financial metrics such as return on investment (ROI) and cost variance.

It’s important to note that the choice of tools will depend on the organization’s specific needs, budget, and existing technology infrastructure. The most effective tools are those that can be integrated with each other to provide a comprehensive view of portfolio performance.

Me: A popular agile product management tool some executives and upper managers find useful is Aha! Can Aha! track metrics and KPIs for the agile portfolio management process?

Yes, Aha! is a product management and roadmapping tool that can be used to track metrics and key performance indicators (KPIs) for the agile portfolio management process. Aha! provides a variety of features that can help measure portfolio performance, including:

Customizable dashboards: Aha! provides customizable dashboards that can be configured to display the most important metrics and KPIs for the portfolio. These dashboards can be shared with stakeholders to provide a real-time view of portfolio performance.
Goal setting and tracking: Aha! allows users to set goals for the portfolio and track progress towards those goals. This can be a powerful tool for measuring the impact of the portfolio on the organization’s strategic objectives.
Customizable reports: Aha! provides customizable reports that can be used to analyze portfolio performance and identify areas for improvement. These reports can be generated on a regular basis to provide a comprehensive view of portfolio performance.
Integration with other tools: Aha! can be integrated with other tools such as Jira or Trello to provide a comprehensive view of portfolio performance.
Customer feedback: Aha! provides tools for collecting and analyzing customer feedback, which can be used to measure customer satisfaction and identify areas for improvement.

Overall, Aha! is a powerful tool for tracking metrics and KPIs for the agile portfolio management process. Its customizable dashboards, goal setting and tracking features, and integration with other tools make it a popular choice among portfolio managers.

Me: Can aha! help with agile team capacity planning and utilization?

Yes, Aha! can help with agile team capacity planning and utilization. Aha! provides a variety of features that can help teams plan and manage their capacity, including:

Resource allocation: Aha! allows teams to allocate resources to specific initiatives or projects, which can help ensure that resources are being used effectively and efficiently.
Capacity planning: Aha! provides tools for capacity planning, which can help teams determine how much work they can take on based on their available resources and capacity.
Team workload: Aha! allows teams to view their workload across all initiatives and projects, which can help them identify potential bottlenecks or areas where they may need additional support.
Time tracking: Aha! provides tools for time tracking, which can help teams monitor how much time they are spending on specific tasks or projects. This can be useful for identifying areas where teams may be spending too much time, or where they may need additional training or support.
Capacity reporting: Aha! provides customizable reports that can be used to analyze team capacity and utilization over time. These reports can be used to identify trends or areas for improvement, and can help teams make data-driven decisions about how to allocate their resources.

Overall, Aha! provides a comprehensive set of tools for agile team capacity planning and utilization, which can help teams work more efficiently and effectively. Its resource allocation, capacity planning, team workload, time tracking, and capacity reporting features make it a popular choice among agile teams.

Me: Good deal. How does Azure DevOps compare with Aha! and Confluence Jira?

Azure DevOps, Aha!, and Confluence Jira are all software development tools that offer different functionalities and serve different purposes in the software development lifecycle. Here are some key differences between these tools:

Azure DevOps: Azure DevOps is a comprehensive software development platform that provides end-to-end functionality for planning, tracking, and deploying software products. It includes tools for agile project management, source code management, continuous integration and deployment, and testing. Azure DevOps is an all-in-one platform that provides a complete set of features and integrations, which makes it a popular choice for organizations that are looking for a single platform to manage their entire software development lifecycle.
Aha!: Aha! is a product management tool that helps organizations plan and manage their product roadmap, features, and releases. It provides features for idea management, product strategy, and product analytics. Aha! is focused on helping product teams align their roadmap with their business goals and customer needs.
Confluence Jira: Confluence Jira is a collaboration tool that allows teams to plan, track, and report on their work. It includes features for agile project management, issue tracking, and team collaboration. Confluence Jira is popular among agile teams as it provides features for creating and managing agile boards, sprints, and backlogs.

In summary, Azure DevOps is a comprehensive platform that provides end-to-end functionality for software development, while Aha! and Confluence Jira are more specialized tools that focus on product management and collaboration, respectively. Depending on the organization’s needs, each of these tools can be a good fit for different aspects of the software development process.

Me: How does agile portfolio management align with product management?

Me: How can executives and hands on investors improve their leadership using reports and metrics from Agile portfolio management?

Here are some ways that reports and metrics from Agile portfolio management can help C-level executives and investors improve their leadership:

Strategic alignment: Agile portfolio management provides a framework for aligning the portfolio with the organization’s strategic objectives. Reports and metrics can help C-level executives and investors understand how the portfolio is contributing to those objectives, and identify areas where adjustments may be needed.
Resource optimization: Agile portfolio management can help optimize the use of resources across the organization. Reports and metrics can provide insights into resource utilization and identify areas where resources may be underutilized or overutilized.
Risk management: Agile portfolio management can help manage risk by providing visibility into potential risks across the portfolio. Reports and metrics can help identify areas of the portfolio that may be at risk, and help the organization take proactive measures to mitigate those risks.
Performance measurement: Agile portfolio management provides a framework for measuring the performance of the portfolio. Reports and metrics can help C-level executives and investors understand how the portfolio is performing against key performance indicators, and identify areas for improvement.
Transparency: Agile portfolio management provides transparency into the organization’s portfolio and how it is being managed. Reports and metrics can help C-level executives and investors understand how the portfolio is being managed, and provide insights into the decision-making process.

Me: Very informative. I knew there was a reason I like you. Can Azure Agile DevOps track metrics and KPIs for the agile portfolio management process?

Yes, Azure DevOps can track metrics and KPIs for the agile portfolio management process. Azure DevOps provides a range of tools and features that can help organizations manage their agile portfolio and measure its performance.

Here are some ways that Azure DevOps can help track metrics and KPIs for agile portfolio management:

Backlogs: Azure DevOps provides tools for managing product backlogs, which can help organizations prioritize and track work across their portfolio. By tracking the status of backlog items, organizations can measure their progress and identify areas where improvements are needed.
Dashboards: Azure DevOps provides customizable dashboards that can be used to track key metrics and KPIs for agile portfolio management. These dashboards can be configured to display information such as backlog status, sprint progress, and team capacity utilization.
Reporting: Azure DevOps provides a range of built-in reports that can be used to measure the performance of the agile portfolio. These reports can be customized to display information such as velocity, burn-down charts, and team capacity.
Integration: Azure DevOps integrates with a range of other tools and services, which can help organizations track metrics and KPIs across their entire software development lifecycle. For example, Azure DevOps can integrate with Power BI to provide more advanced reporting and analytics capabilities.
Analytics: Azure DevOps also provides advanced analytics capabilities that can be used to measure and optimize the performance of the agile portfolio. These analytics tools can help organizations identify trends, uncover insights, and make data-driven decisions to improve their portfolio management processes.

Overall, Azure DevOps provides a range of tools and features that can help organizations track metrics and KPIs for agile portfolio management. By using these tools, organizations can gain insights into their portfolio performance, identify areas for improvement, and make data-driven decisions to optimize their portfolio management processes.

Me: Sweet. Finally, I know my sophisticated questions probably wore your AI brain out…Can Azure DevOps help with agile team capacity planning and utilization? Team capacity is one of the most powerful yet least used leadership tool that I think can help executives enable sprint and product teams to provide value and feel like their work makes a difference.

Yes, Azure DevOps can help with agile team capacity planning and utilization. Azure DevOps provides a range of features and tools that can help organizations plan and manage their team capacity in an agile environment.

Here are some ways that Azure DevOps can help with agile team capacity planning and utilization:

Capacity Planning: Azure DevOps provides capacity planning tools that enable teams to estimate their available capacity for upcoming sprints. This helps teams plan their work more effectively and ensure that they are not overcommitting.
Resource Allocation: Azure DevOps allows organizations to allocate resources to specific teams, projects, or initiatives. This helps organizations optimize their resource utilization and ensure that resources are being used effectively.
Time Tracking: Azure DevOps provides time tracking capabilities that enable teams to track the time spent on specific tasks or user stories. This helps teams better understand how their time is being spent and identify areas where they can improve their productivity.
Work Item Tracking: Azure DevOps provides work item tracking capabilities that allow teams to track the status of their work items and ensure that they are being completed on time. This helps teams identify potential bottlenecks and take corrective action to improve their efficiency.
Reporting: Azure DevOps provides a range of reporting capabilities that allow teams to measure and analyze their capacity and utilization. This helps teams identify areas for improvement and make data-driven decisions to optimize their capacity planning and utilization processes.

Overall, Azure DevOps provides a range of tools and features that can help organizations with agile team capacity planning and utilization. By using these tools, organizations can plan their work more effectively, optimize their resource utilization, and improve their team’s productivity and efficiency.

Barebones Agile DevOps (BAD) – A Simplified Hybrid Agile DevOps Approach for Delivering IT Cloud Solutions

By John Conley III

CEO, Samsona Digital

A division of Samsona Corporation

“Transforming your world one task at a time”

Tips for implementing a hybrid approach to solution delivery

You can have the best DevOps engineering pipeline in the world, but if you don’t control the flow of work before requirements reach the sprint backlog, chaos can wreak havoc on the dev team’s sprint velocity.

Having been a consultant at several companies during the digital cloud revolution (and before this era), I can safely say that most companies do not implement a pure agile approach. That’s fine. Life happens. Not all companies implement a pure Agile approach to solution delivery. Even those who use SAFe still mix in some familiar, waterfall or even unconventional methods. No matter how they slice it, almost all companies who pursue an Agile DevOps approach to IT delivery mix in unorthodox, home grown, semi-waterfall methods. If your company is one of these, then this content is for you.

Your company most likely sent teams to one of the many agile devops trainings available online and in person. Everyone is pumped up, ready to do some sprint planning. But the corporate technology culture is not sharing that enthusiasm. The “corporate culture tech debt” still wants the old ways of deploying technology.

Pure Agile and DevOps practitioners such as myself have to acknowledge that, despite the fact the Agile Manifesto was written almost 20 years ago, most organizations still fall back, by instinct, to waterfall approaches. Why? It’s mostly due to pressure from market forces, executive deadlines, and budget constraints. Human nature drives teams to quickly capture requirements and turn out code with little time for thought. Approaches such as Scaled Agile and DevOps have tried to balance this knee jerk reaction with some lightweight guiding principles, but most organizations still mix in pressure-driven waterfall regardless. Mixing waterfall with agile devops is what we notoriously call “WAgile.” We have to live with this grassroots behavior whether we want to or not.

Rule of Thumb: The more that IT shops veer away from an ideal Agile approach, the more chaotic their IT workflow becomes. Team members generally want to work their butts off to deliver quality solutions on time and within budget if organizations manage the chaos better.

Tip: When you hire new tech workers, be sure to document and train them on the aspects of your technology culture that are not part of industry standard methodologies or CI CD platforms. Just because a cloud developer knows Azure DevOps (the technology), for instance, doesn’t mean they understand all of the crazy complicated DevOps scripts you created (the technology culture). This also includes training senior technology leaders on the kinds of presentation templates that C-level executives want to see for status reports. These executive reports can vary widely per organization – I’ve literally had to have executive admins help me understand what style works best for certain C-suite execs. Separate the technology culture from the technology itself when onboarding team members. These are two different animals. Failure to adequately plan the training of technical team members such as architects and developers on unique homegrown practices is an antipattern I’ve observed in some organizations, including some mature agile organizations.

Figure 1. The Backlog Pipeline (High Level)

The Team Backlog

At a minimum, each team role needs its own backlog. Thus, not only should there be a developer sprint backlog and a product backlog, but there should also be an enterprise solution arch backlog, a security team backlog, a cloud platform engineer backlog, and QA backlog. If you use pure SAFe to manage the flow of work in and out of these backlogs, great. If not, at least when you manage your “wagile” pipeline—wagile being a waterfall-agile hybrid, just have these backlogs in place, at a minimum, so that the work can be organized and prioritized at the beginning of each sprint.

Neglecting any of these backlogs will increase the chaos of the solution delivery cycle, which will impact sprint velocity, and may lead to team member burnout and turnover. For instance, upper management will throw random work on the member and expect deliveries within 24 hours, despite the fact that the team already has backed up work that was due yesterday. This is where “office politics” usually increases because of the resulting personality clashes, escalations, tensions, etc. The more organized your delivery workflow, the more satisfied the team members will be, and the better the expected outcomes. And we all know that top level executives mainly care about results, so efficient backlog management is the best way towards achieving measurable results and value per enterprise capability.

Rule of thumb: It’s seldom the people who cause project failures, it’s actually a flawed workflow process.

Tip: Improve the process, improve the chances of success.

The Barebones Agile DevOps (BAD) Workflow

I’m proposing what I call a Barebones Agile DevOps (BAD) workflow as a way to help organizations who tend to do a hybrid between waterfall and agile methods such as SAFe. This approach is just a lightweight process for hybrid organizations to streamline the flow of work from the Product Owner to the Architects and finally to the Implementers (Business Analysts/User Story Writers, Developers, Testers, Cloud Engineers, DBAs/Data Architects, Technical Writers). By no means is this approach intended to replace any existing methodologies. It is simply a slimmed down method that is realistic about the ways organizations execute hybrid waterfall, Agile and DevOps. Therefore, this content will not be long, exhaustive, or overly detailed. I’m simply presenting just enough info so that your project teams can rapidly adopt it, in order to reduce and control the chaos in the current IT workflow.

So how does it all work? Every organization has a set of capabilities that support a value proposition to external customers and internal workers. The workers execute certain tasks, which are tied to those capabilities, to deliver a product or service to the customer. Capabilities are often aligned with Epics in Agile, but based on my consulting experience, some organizations struggle in this area.

I won’t address those struggles here. But long story short, there are certain functional business requirements that need to be collected in a Product Backlog. They are usually realized as Epics and Features. Again, Epics are loosely aligned with organizational Capabilities. Conversely, epics sometimes evolve from large user stories, which is kind of a bottom-up approach. The alignment of bottom-up epics to capabilities is a challenge for organizations. The difficulty is in using non agile approaches to identify and map such capabilities to various lines of business functionalities, and finally to IT projects (NFRs, architecture runways, etc.

Figure 2. The 6 Backlog Verbs

The 6 Backlog Verbs

Nonetheless, the barebones approach is focused on 6 verbs to manage the backlogs and push items to the next backlog in the IT workflow pipeline. They are:

Identify

Rationalize

Prioritize

Assign

Deliver

Learn

To explain each, I’ll use the Product Backlog as an example. The other backlogs will follow a similar pattern.

Identify

As digital transformations of organizations sweep many industries these days, the activities of workers to provide value to customers is defined by requests from customers, executives and even workers to improve the various solutions in the enterprise. These requests are captured as functional requirements and queued up in the Product Backlog. Assuming you’ve created a Product Owner team in your DevOps tool of choice (I tend to use Azure DevOps), you can manage these incoming backlog items in a Kanban board, which is useful for rationalizing the items as a team.

Rationalize

At this step, the PO team leader, which would likely be a Product Manager, would organize a regular meeting to go over the new backlog items. Ideally, host this meeting every 1-2 weeks. The purpose is to determine if the new PBI is a new requirement, is similar to an existing PBI, or is not a true requirement but a request for product training or awareness. The goal is to filter out the backlog items so that you’re left with a viable set of functional requirements.

Prioritize

Once you’ve rationalized your PBIs, it’s time to prioritize them based on input from executives and the level of effort to document them. The PO can act on behalf of executives, with Product Managers sometimes weighing in on mission critical PBIs. The level of effort can be T shirt sized like this:

Small effort
Medium effort
Large effort
X Large effort

If an effort is deemed Large or X Large, there’s a possibility it may align to an enterprise Capability which can then become a basis for an Epic. The goal of this step is to have a better idea of which higher priority PBIs can be assigned to POs and/or Business Analysts. You’ll likely categorize the PBIs into Epics, Features, and User Stories.

Note: Sometimes, when a Solution or Enterprise Architect is involved in prioritizing PBIs, some NFRs (technical nonfunctional requirements) may come up which will be rationalized in the Architect Backlog later. Don’t rationalize and prioritize those in this step. Just label them so that they can be moved to the Architect Backlog.

Assign

Continuing from the last step, the team leader assigns each PBI to the team members based on their current workload capacity. A round robin approach is usually used here, based on my experience with several companies. An even distribution of PBIs is the goal. The level of effort should be factored in when assigning PBIs. An X large PBI might be the equivalent of 4 Small PBIs, for instance. Use a Kanban board to track progress in daily standups (or whatever meeting frequency you choose). For teams of Product Managers and Product Owners, the Product Manager would assign items to POs. Some IT shops also have Business Analysts who work with POs.

Tip: The preceding 4 steps can be done in one meeting or two if team member calendars are tight.

Note: In place of “Business Analysts,” some shops may have “user story writers” or other kinds of roles that work the PBIs into more detail.

Deliver

Finally, each team member works their PBI until it is ready to be delivered to the next backlog in the pipeline. In the case of the Product Backlog, the next one is the Architect Backlog. Since the focus is only on documenting functional requirements in each PBI, backlog items that are T shirt sized as Small shouldn’t take longer than a day, Medium probably 2 days, Large 3-5 days, and X Large up to 10 business days. If needed, break up X Large backlog items into smaller ones to do the work concurrently and deliver it faster.

Learn

At the conclusion of every backlog pipeline should be a meeting to discuss lessons learned. What went well? Where can the team improve? Do we have too many meetings or not enough meetings? Does each team member feel empowered and supported to perform their tasks? Do they feel they can be open and honest with leadership? Use this step as a way to calibrate the backlog workflow to improve the quality and the output of the backlog pipeline. A Scrum Master, Agile Coach or similar leader can facilitate the improvements needed to make this learning step effective.

And that’s it. The next backlog in the pipeline is the Architect Backlog. It follows the same 6 verbs, but from a technical and architecture governance standpoint.

Tip: Any methodology has to feel natural to a team. The waterfall approach, though not always favorable, feels natural to most teams because when the pressure is on, it feels like a natural response. Likewise, implementing an Agile DevSecOps approach should feel equally as natural and easy to learn in order for it to replace waterfall.

The Importance of the Architect Backlog

Interestingly, many organizations overlook the need for the critical Architect Backlog (AB) as they go straight from the Product Backlog (PB) to the Sprint Backlog (SB), incorporating architecture input as an afterthought, or just another task. Bridging the gap between these two backlogs is actually not trivial. Smaller organizations can get away with skipping the architect backlog and letting analysts and developers figure things out on their own (which is the nature of self-organizing teams).

For larger enterprises, this is not an option.

Developers are usually overworked and don’t have time to consider if a PBI is a repeat of something already done, whether it truly makes technical sense, whether regulatory or corporate policy requirements need to be applied, strategic backup and disaster recovery designs, etc. My experience shows that this backlog is just as important as the PB and Sprint backlog, making for a “Big Three” backlog strategy at a minimum.

Solution and Enterprise Architects have to rationalize each incoming PBI to make sure they are technically feasible. They make a best guesstimate as to the level of technical effort involved in doing the high level design. They leave the low level design guesstimates to the Sprint Planning process (basically, the beginning of the next backlog, the developer Sprint Backlog). The lead architect, usually an Enterprise Architect, will assign AB items to each Solution Architect on the team. What is delivered is usually a Solution Architecture Design (SAD) document. This document should not be more than 5 to 10 pages long and should come with a one page recommendations to guide developers as they take this input into the Sprint Backlog.

The Developer Sprint Backlog usually is setup pretty well, from my experience. No need to go into much detail here. With a smooth PB and Architect Backlog, the developers can focus on sizing the level of effort using a Story Points scoring system. Items they deem above average (usually higher than 5 on a scale of 1 to 10) would involve Solution Architects having to approve the code at a DevOps tollgate before it is pushed to the next step in the CI CD pipeline. Architects generally verify that best design practices are being used, and if not why not, also looking for regulatory compliance, corporate policy compliance, performance and other NFRs, etc.

The remaining roles of Testers, Cloud Engineers, Security, Data, have more streamlined Backlogs as they don’t need to be as involved once the technical rigor of the Architect and Developer backlogs have been performed. The main backlog verbs here (steps) are Rationalize, Assign, Deliver and Learn.

Conclusion

Hopefully this scaled down, barebones approach is easy enough to help hybrid environments make the most of their unique mix of waterfall and Agile DevOps. If you think your teams need an outside voice to help adopt this easy approach, feel free to reach out to me. Until the next video, stay agile.

How to Really Map a Namecheap URL to Your Static Azure Cloud Website

You finally buy that cute-sounding website address, and then some time later, you pick a cloud platform to host your website. These days, that’s starting to be a typical scenario. Cloud computing has brought the price of owning your own website down to very reasonable costs. Likewise, with the expansion of website domain addresses beyond the classic “.com” URL, the cost and ease of getting your own web address has improved. But when it comes time to use your shiny new website address you bought at a domain name registrar like Namecheap.com to deploy your website to your inexpensive Azure cloud account, that’s where things get a little tricky.

Both Namecheap.com and Microsoft offer online Help articles to walk you through the process, but not specifically for deploying a Namecheap.com registered domain to a static Azure cloud storage account. Namecheap.com provides generic instructions for routing your URL to ANY cloud provider, and Microsoft offers generic instructions for creating DNS zone settings for URLs registered at ANY domain registrar, but no two domain name registrars and cloud platforms are the same. In other words, once you try to customize the settings for a specific Registrar-Cloud pair, the instructions can be frustrating. This article provides help for making your Namecheap.com URL work with your static Azure cloud website.

You may ask, “why not just buy the URL domain and website hosting from the same company, either Namecheap or Microsoft?” You can certainly do that, though Microsoft, as of this writing, does not sell domain name registrations. If you’ve hosted sites with WordPress or Shopify, you should know how this works. But what if, say six months later, you decide to switch hosting providers or the company goes out of business?

It’s a best practice to have your domain registrar separate from the hosting provider to avoid having one company monopolize your online presence. You can probably apply this help to other pairings, but you will likely encounter some hiccups along the way. But if simplicity is your number one goal, then it might be more convenient for you to have one company take care of everything for you. No need to read the rest of this article. But for those who already have a URL domain registered with one company (in this case, Namecheap.com) and are looking to host a website on another company’s cloud platform (in this case, Microsoft Azure).

Namecheap.com is my registrar, but most domain registrars work in similar ways. Without further ado, I will skip the verbosity and get right to it. The process of configuring your URL to work with your cloud account is as follows:

1. Have your URL domain registration info from Namecheap.com handy

2. In your cloud account portal, setup storage accounts for static websites

3. Configure your Azure cloud account so that your DNS configuration is ready to go with your DNS nameserver

Both Namecheap.com and Microsoft have tutorials to help you (links are provided). I won’t repeat the steps here. I suggest reading that now before continuing. I will focus on the details that are not so obvious that can frustrate you.

Read the rest here!

Tips for Inheriting Legacy Software Code

At one point or other, a software developer will be tasked with inheriting another developer’s code. Less experienced developers will not have a clue what’s in store for them, and more experienced developers already know it’s like playing Russian roulette. Ideally, the prior developer did a reasonably good job with writing clean code (not perfect, but clean) and hopefully some inline comments clarifying the more complex, mission critical parts of the solution.

The level of tech debt the inheritors encounter will depend in large part on the age of the code base, which is a key factor in what’s called software rot. Software rot is the idea that, like any other tangible product, software decays over time. The rate of decay accelerates if the code is not continuously updated and deployed. This means there are two categories of inherited code:

Fresh Code

Stale Code

Fresh code will often have the latest libraries and frameworks in place. Hopefully, they follow the latest best practices for mobile and web development. Code written in the modern era of MVC and microservices will likely be reasonably clean enough to understand without much documentation. Stale code, on the other hand, runs the risk of being out of touch with the latest best practices. Code written, say, 15 years ago will have big monolithic services (early SOA era) and some fat UI clients. Infrequently updated code are not as bad as code that has not been updated in a decade or longer. Following DevOps processes ensures the code stays fresh and is easier to inherit.

Read the rest on Medium.com!

Understanding the Relationship Between the Product Owner, Solution Architect and Cloud Development-Deployment Teams

By John Conley

As organizations launch digital transformation projects using Agile and DevOps techniques, it’s easy for them to overlook the dynamic of the teams they assemble to make the transformation a reality. The transformation team needs a technical vision as well as a business vision. Without the clarity provided by the vision, the team can break down into a basket case of ineffective sprints and unproductive relationships. The Product Owner role helps drive that vision into a set of strategic initiatives that then are vetted and technically prioritized, with the help of the Solution Architect, into sprints. Of all the relationships on a given team, the most misunderstood perhaps is that of the Product Owner and the Solution Architect.
One of the reasons for this misunderstanding is that underestimate the complexity of a project. With smaller organizations, this may or may not be a big deal. But for larger corporations, especially those that are publicly traded, this is often inexcusable.
Within any organization, there are two figurative sandboxes that employees work in:
• The Business sandbox and
• The Technology sandbox
In the Business sandbox, employees carry out tasks that directly align with the organization’s marketing and business support operations. In the technology sandbox, employees are tasked with ensuring that the best and most updated technology is being used to support the Business sandbox. In a digital transformation, technology is no longer an afterthought, or “those IT nerds over there,” but an essential engine that drives the business forward. For every IT project, the leading voice of the business sandbox is the Product Owner (PO).
For the Technology sandbox, the Solution Architect (SA) is the main voice. The Product Owner, as the voice of the customer, internal employee, and executive stakeholder, has the responsibility to manage a Product Backlog of requests for new features to existing solution, brand new solutions, and bug/defect requests. Since the Product Owner is generally nontechnical (which is usually a good thing), the Enterprise Architecture team assigns a Solution Architect to that PO. The SA and PO meet regularly (usually weekly or biweekly) to go over the Product Backlog (PB) to vet each Product Backlog Item (PBI).
Depending on how large the PB is, the meeting can be either quick or tedious. The latter is especially true for larger organizations who are introducing the concept of a PB for the first time. Vetting a the PBIs in a backlog is a multistep process:

• PO Guesstimate
• SA Guesstimate
• PBI Priority Ranking
• Executive Budget Approval
• EA Backlog

PO Guesstimate
The PO t-shirt sizes (e.g., Small, Medium, Large) the business importance/impact of each PBI based on business strategies and capabilities being addressed. No technical input involved. Sometimes, the PO will recognize that a new PBI was already implemented in part or in full by another solution already in production, or is just a matter of training. In this case, the PBI can be marked “Resolved” or “Closed.” There will be times when the PO needs further clarification on the business rationale for a PBI from executive stakeholders. These can be marked as “Pending further business review” or something similar. These items should be time tracked so that they don’t age too long in the product backlog.
SA Guesstimate
After gaining business insight into the PBI, the SA t-shirt sizes the effort to analyze and implement technologically. No business input involved. The most popular t-shirt sizes used are Small, Medium and Large. Some teams use X Large for really big epics, but that’s up to you what works. Sometimes, the SA will recognize that a new PBI was already implemented in part or in full by another solution already in production, or is just a matter of training. In this case, the PBI can be marked “Resolved” or “Closed.” There are also times the SA may need a second pair of technical eyes to vet a PBI, so these should be marked “Needing further technical review.”

PBI Priority Ranking
If a PBI survives 1 and 2, then the business and technical rankings together should guide the PO and SA to prioritize the PBI relative to the others. Ranking PBIs is mostly subjective, but a good rule of thumb is to give weight to those items that are quick wins or have been heavily requested among users and executive stakeholders for some time.

Executive Budget Approval
Once the PBIs are prioritized, the PO gets budgetary approval of the top 10 (or whatever the threshold is) from executive stakeholders. Once a PBI is approved, the PO marks the PBI as “Ready for Implementation” or whatever status is agreed upon.

EA Backlog
There are different schools of thought regarding how to the technology team proceeds after a PBI has been approved. The Scaled Agile Framework offers some good ideas around value trains and solutions trains that have helped many organizations. Plain old Scrum, Agile and DevOps have good ideas here. Choose the approach that works for you. Here, I am focusing mostly on the pure process itself without getting bogged down in methodology wars. Once a PBI is approved, some technology leaders directly assign them to a sprint backlog. That might work for smaller organizations, but for larger ones, there is a need for a technology “brain trust” to determine the next step before it goes to any particular team’s sprint backlog. This is where Enterprise Architecture (EA) comes into play.
Often, SAs are under the direction of an EA Brain Trust who assigns them to one or more IT projects. So it would make since that there needs to be an EA Backlog the mediates between the PO’s Product Backlog and each team’s Sprint Backlog. This becomes especially true for organizations going through a digital transformation that involves implementing cloud computing. In the cloud, there are three layers that a PBI can intersect with:
• Software (SaaS)
• Platform (PaaS)
• Infrastructure (IaaS)
Each of these tiers would have a corresponding technology team of technical development and deployment specialists to implement the incoming PBI within the organizations IT environment. With the typical sprint backlog setup, the default assumption is that the incoming PBI is focused on developing software. But what if it only involves standing up a SQL database or a Linux or Windows Server VM? The determination about what kind of team to engage for the solution needs to be at the EA level. This technology brain trust, the EA Team, should have leaders from each area to help engage the right team. The PBI would then be routed to that respective team’s Sprint Backlog to work. The EA team would also do a more technical score of each incoming PBI to determine if an SA is needed to guide the sprint team. A good starting point for a scoring system is 1 to 50, where anything 26 or higher means the PBI is strategically important enough to warrant assigning an SA to the team. Less strategic PBIs can usually be handled by sprint teams with just a normal tech lead or dev lead. If an SA is needed, the SA would then work with the team to do normal sprint planning and backlog refinement activities. The SA creates necessary design docs that are within the guidelines of the master EA doc.

Considerations for Consulting Engagements
The same principles apply to a consulting practice engaging a prospective customer after making the initial sales pitch. After a consulting sales pitch, there has to be a customer assessment phase to determine the level of effort both parties can expect before a full engagement commitment is made. Both roles, PO and SA, are needed at a minimum to determine the effort. During the assessment, the PO and SA develop and manage a backlog of items the customer would need to address before committing to a digital transformation initiative. Depending on the size and complexity of the organization, this can take anywhere from a week or two, to several weeks or longer. The less mature the organization is technologically, the longer this assessment phase will take. It’s similar to when you hire house cleaning service. If it’s your first time, and your house is big, it will take longer than a similar house that already has regular house cleaning.

Wrapping Up
Hopefully this white paper helped in understanding the important relationship between a Product Owner and a Solution Architect. The former is business oriented and is the voice of the customer, employee user and executive stakeholder. The latter is technically oriented, and is the voice of the technology teams and the mediator between the functional requirements (usually user stories and other PBIs) and the nonfunctional requirements that the technology teams implement to satisfy the business. The EA team helps determine how to map incoming PBIs to the right technology teams, and will assign an SA if the PBI is architecturally and strategically significant.

About the Author
John Conley is a Dallas, TX, based Digital Solution Architect and Cloud Engineer Consultant. This is an excerpt from his forthcoming eBook “2020 Business Guide to Digital Transformation Governance.” Feel free to reach out to him if you have any questions or need consulting for your enterprise engagements.

By John Conley

Photo Credit: Mimi Thian from Unsplash.com

Note: This article is also available on Medium.com.

One of the reasons for this misunderstanding is the underestimating of the complexity of a project. With smaller organizations, this may or may not be a big deal. But for larger corporations, especially those that are publicly traded, this is often inexcusable.

Within any organization, there are two figurative sandboxes that employees work in:

The Business sandbox and
The Technology sandbox

In the Business sandbox, employees carry out tasks that directly align with the organization’s marketing and business support operations. In the technology sandbox, employees are tasked with ensuring that the best and most updated technology is being used to support the Business sandbox. In a digital transformation, technology is no longer an afterthought, or “those IT nerds over there,” but an essential engine that drives the business forward. For every IT project, the leading voice of the business sandbox is the Product Owner (PO).

nesa-by-makers-IgUR1iX0mqM-unsplash — Photo: Nesa by Makers at Unsplash.com

For the Technology sandbox, the Solution Architect (SA) is the main voice. The Product Owner, as the voice of the customer, internal employee, and executive stakeholder, has the responsibility to manage a Product Backlog of requests for new features to existing solution, brand new solutions, and bug/defect requests. Since the Product Owner is generally nontechnical (which is usually a good thing), the Enterprise Architecture team assigns a Solution Architect to that PO. The SA and PO meet regularly (usually weekly or biweekly) to go over the Product Backlog (PB) to vet each Product Backlog Item (PBI).

Depending on how large the PB is, the meeting can be either quick or tedious. The latter is especially true for larger organizations who are introducing the concept of a PB for the first time. Vetting a the PBIs in a backlog is a multistep process:

PO Guesstimate
SA Guesstimate
PBI Priority Ranking
Executive Budget Approval
EA Backlog

PO Guesstimate

The PO t-shirt sizes (e.g., Small, Medium, Large) the business importance/impact of each PBI based on business strategies and capabilities being addressed. No technical input involved. Sometimes, the PO will recognize that a new PBI was already implemented in part or in full by another solution already in production, or is just a matter of training. In this case, the PBI can be marked “Resolved” or “Closed.” There will be times when the PO needs further clarification on the business rationale for a PBI from executive stakeholders. These can be marked as “Pending further business review” or something similar. These items should be time tracked so that they don’t age too long in the product backlog.

SA Guesstimate

After gaining business insight into the PBI, the SA t-shirt sizes the effort to analyze and implement technologically. No business input involved. The most popular t-shirt sizes used are Small, Medium and Large. Some teams use X Large for really big epics, but that’s up to you what works. Sometimes, the SA will recognize that a new PBI was already implemented in part or in full by another solution already in production, or is just a matter of training. In this case, the PBI can be marked “Resolved” or “Closed.” There are also times the SA may need a second pair of technical eyes to vet a PBI, so these should be marked “Needing further technical review.”

PBI Priority Ranking

If a PBI survives 1 and 2, then the business and technical rankings together should guide the PO and SA to prioritize the PBI relative to the others. Ranking PBIs is mostly subjective, but a good rule of thumb is to give weight to those items that are quick wins or have been heavily requested among users and executive stakeholders for some time.

Executive Budget Approval

Once the PBIs are prioritized, the PO gets budgetary approval of the top 10 (or whatever the threshold is) from executive stakeholders. Once a PBI is approved, the PO marks the PBI as “Ready for Implementation” or whatever status is agreed upon.

icons8-team-yTwXpLO5HAA-unsplash — Photo: Icons8 Team from Unsplash.com

EA Backlog

There are different schools of thought regarding how to the technology team proceeds after a PBI has been approved. The Scaled Agile Framework offers some good ideas around value trains and solutions trains that have helped many organizations. Plain old Scrum, Agile and DevOps have good ideas here. Choose the approach that works for you. Here, I am focusing mostly on the pure process itself without getting bogged down in methodology wars. Once a PBI is approved, some technology leaders directly assign them to a sprint backlog. That might work for smaller organizations, but for larger ones, there is a need for a technology “brain trust” to determine the next step before it goes to any particular team’s sprint backlog. This is where Enterprise Architecture (EA) comes into play.

Often, SAs are under the direction of an EA Brain Trust who assigns them to one or more IT projects. So it would make since that there needs to be an EA Backlog the mediates between the PO’s Product Backlog and each team’s Sprint Backlog. This becomes especially true for organizations going through a digital transformation that involves implementing cloud computing. In the cloud, there are three layers that a PBI can intersect with:

Software (SaaS)
Platform (PaaS)
Infrastructure (IaaS)

Each of these tiers would have a corresponding technology team of technical development and deployment specialists to implement the incoming PBI within the organizations IT environment. With the typical sprint backlog setup, the default assumption is that the incoming PBI is focused on developing software. But what if it only involves standing up a SQL database or a Linux or Windows Server VM? The determination about what kind of team to engage for the solution needs to be at the EA level. This technology brain trust, the EA Team, should have leaders from each area to help engage the right team.

The PBI would then be routed to that respective team’s Sprint Backlog to work. The EA team would also do a more technical score of each incoming PBI to determine if an SA is needed to guide the sprint team. A good starting point for a scoring system is 1 to 50, where anything 26 or higher means the PBI is strategically important enough to warrant assigning an SA to the team. Less strategic PBIs can usually be handled by sprint teams with just a normal tech lead or dev lead. If an SA is needed, the SA would then work with the team to do normal sprint planning and backlog refinement activities. The SA creates necessary design docs that are within the guidelines of the master EA doc.

Considerations for Consulting Engagements

The process of initiating a consulting engagement for a prospective customer has its own set of steps not unlike a software development project. After a consulting sales pitch, there has to be a customer assessment phase to determine the level of effort both parties can expect before a full engagement commitment is made. Both roles, PO and SA, are needed at a minimum to determine the effort.

During the assessment, the PO and SA develop and manage a backlog of items the customer would need to address before committing to a digital transformation initiative. Depending on the size and complexity of the organization, this assessment can take anywhere from a week or two, to several weeks or longer. The less mature the organization is technologically, the longer this assessment phase will take. It’s similar to when you hire house cleaning service. If it’s your first time, and your house is big, it will take longer than a similar house that already has regular house cleaning.

The successful completion of the engagement setup has, at a minimum, the following micro sprints as key milestones:

Request for info, quote, proposal from the prospective client
Sales pitch by the consultant
High level needs assessment by both the client and consultant
Service Level Agreement (SLA)
Product backlog creation and evolution based on user stories and other feature requirements

This set of milestones is by no means exhaustive but is meant to provide a set of guardrails to manage the micro sprints for the engagement setup process.

Wrapping Up

Hopefully this white paper helped in understanding the important relationship between a Product Owner and a Solution Architect. The former is business oriented and is the voice of the customer, employee user and executive stakeholder. The latter is technically oriented, and is the voice of the technology teams and the mediator between the functional requirements (usually user stories and other PBIs) and the nonfunctional requirements that the technology teams implement to satisfy the business. The EA team helps determine how to map incoming PBIs to the right technology teams, and will assign an SA if the PBI is architecturally and strategically significant.

About the Author

John Conley is a Dallas, TX, based Digital Solution Architect and Cloud Engineer Consultant. This is an excerpt from his forthcoming eBook “2020 Business Guide to Digital Transformation Governance.” Feel free to reach out to him if you have any questions or need consulting for your enterprise engagements.

DATA RETENTION POLICY

Conclusion

Share this:

Like this:

Example Cloud Team Structure: Monitoring and Alerting

Share this:

Like this:

What Went Wrong with the Industrial Era Leadership Style?

Flexibility

Empowerment

Collaboration

Innovation

Emotional Intelligence (aka “Technical Empathy”)

Examples of some of the shortcomings of industrial era “robber baron” leadership styles

How Different is Today’s Industrial Era Leadership Mindset Compared to Robber Barons?

Similarities

Differences

Conclusion

Share this:

Like this:

Define clear cloud teams, roles and responsibilities

Determine the necessary skill sets

Balance in-house and outsourced resources

Foster a culture of continuous learning, research and development

Conclusion

Share this:

Like this:

Aligning Sales and Product Teams

Collaborate on product requirements

Attend sprint demos

Provide customer feedback

Attend retrospectives

Develop a shared understanding of quality

Aligning Product and Sprint Teams

Collaborate on sprint goals

Define acceptance criteria

Conduct high level code reviews

Provide effective feedback and business guidance

Collaborate in sprint reviews and retrospectives

How agile sprint planning and sprint retrospectives can improve crucial conversations

Collaboration

Transparency

Alignment

Continuous Improvement

Conclusion

Share this:

Like this:

Share this:

Like this:

Tips for implementing a hybrid approach to solution delivery

The Team Backlog

The Barebones Agile DevOps (BAD) Workflow

The 6 Backlog Verbs

Identify

Rationalize

Prioritize

Assign

Deliver

Learn

The Importance of the Architect Backlog

Conclusion

Share this:

Like this:

Share this:

Like this:

Share this:

Like this:

By John Conley

Photo Credit: Mimi Thian from Unsplash.com

PO Guesstimate

SA Guesstimate

PBI Priority Ranking

Executive Budget Approval

EA Backlog

Considerations for Consulting Engagements

Wrapping Up

About the Author

Share this:

Like this: