Agile frameworks promote constant physical interactions between individuals and teams. But when that is not an option, technology comes to the rescue.

Working remotely, Agile teams must not depend on the same collaborative and managerial practices performed by co-located teams. In remote scenarios, sharing screens on-site, post-its, and architecture diagrams on whiteboards are hard to implement and follow. They should be replaced by proper digital technologies that ensure the suitable collection, storage, and distribution of a team’s internal knowledge and supporting documents.

Agile frameworks promote constant and physical interaction between team members by ensuring regular delivery of features and a swift response to organizational changes. Daily stand-ups, group planning, review, and retrospectives sessions are examples of something more challenging to achieve and manage in a remote model. The risk of ignoring this challenge and not adapting the management practices can lead individuals and teams to start feeling isolated, not contextualized, and, consequently, causing inefficiencies in the execution of the development process.

Given the distance between teams and individuals and the fact that they rely on computers with an internet connection to perform the tasks, web-based collaborative platforms are essential to ensure people can talk, synchronize developments and knowledge as well as collaborate in the delivery of quality products

These collaboration tools can be grouped according to their functionality, namely:

1. communication and documentation support tools,
2. system development support tools
3. and Integrated product lifecycle management tools.

Now let’s deep dive into each of these three types and list some handy technologies and platforms you can use.

Communication assumes a central role given the agile collaborative and personal interaction nature. These tools ensure that teams can perform the different agile ceremonies remotely, message and exchange information whenever required, brainstorm ideas, or even share successes and failures. Generically, most of these tools include instant messaging technologies and videoconferencing systems. Still, more modern collaborative tools also bring resources for email management, meeting calendar, code sharing, document sharing, and even live screen sharing.

Although there are a variety of technologies on the market that can support teams with communication issues, choosing the best one is a challenge and will depend on topics such as security, purpose, or integration with existing systems.

Some examples of these tools can be found in the following. However, one should consider this a sample with the most used ones. There is in the market a more significant offer than those listed.

Development support tools assume a central role in enabling the creation of new products and systems. Development projects based on agile frameworks enhance the design of self-sustainable and self-organized teams, which requires greater collaboration and alignment among engineering teams in producing artifacts.

It is fundamental to have tools for coordinating the development activities of the systems aligned among all the parts of the distributed project.

These tools have very different use cases, namely:

• ensuring that all artifacts developed by the various teams are centralized and traceable in terms of different versions and contributions.
• help maintain a holistic view of the design of the solutions to be implemented.
• ensure that all code is developed towards minimizing implementation time and minimizing the probability of errors.

In a more structured way, it is suggested to group this type of tool into four main areas:

• Code repository for project artifacts and source code
• Management of requirements
• Solution design and brainstorming,
• Software development and testing
• and finally the information and knowledge center.

Now let’s deep dive into this kind of area.

2.1. Code repository for project artifacts and source code. An artifact repository or version control system is where the various programmers collaborate. It is crucial to ensure that all the source code generated by the multiple teams is integrated correctly into the same place. There are rules for conflict management if several members try to change the same section of the system. It allows not only collaboration on code creation but also on defining processes for submitting new code through the definition of different code branches or pull request mechanisms through which we can discuss changes made in a particular branch or request approval to integrate newly produced code into a certain code branch. Examples of these platforms include Github and Gitlab, where both allow us to collaborate on source code development, implement version control, manage different branches and implement pull request mechanisms.

2.2 Management of requirements. In terms of requirements management and project, agile frameworks enhance the sharing of requirements, using natural language to be understood by any party involved in the project, whether technical or business. After being specified and adequately written, these user stories must be inserted in a requirements management system or commonly called issue tracking systems in Agile. These systems are usually integrated with the project’s artifact repositories for better traceability between requirement and artifact produced and allow managing requirements and monitoring the work being executed in the current sprint and collecting performance analysis metrics of the teams and the work done over time. In this type of system, we can attach the drawings of the system to be implemented to help understand the requirements. Examples of these types of platforms encompass Jira or Trello. The Jira platform allows us to collaboratively perform several tasks such as creating user stories, sprint planning, distributing tasks across the team, prioritizing work, visualizing work in progress, and integrating with various tools such as code versioning for complete visibility from the requirement to developed code. Trello is a more simplistic but equally collaborative project management platform where we can manage needs by creating detailed tasks to be executed. These tools allow us to create new requirements and follow their status.

2.3 Solution design and brainstorming. Another equally important activity is the description, design, and architecture of the solutions to be developed. This type of platform supports the different members of the team in prototyping, brainstorming, creating mockups, or designing the architecture with the creation of diagrams that allow better visualization and discussion. These diagrams or informative documents help understand the system requirements in different situations. They are usually attached to the user stories that relate to them. Examples of this type of platform are Miro, Lucidcharts, or draw.io, which allow collaboratively and in real-time, creation and edit new diagrams. Google Docs or Microsoft Office Online helps create and edit documents, spreadsheets, and presentations collaboratively and in real-time which sometimes can be useful for product detail documents and brainstorming results.

2.4 Development platforms. Code development is the central element of the entire information systems development process. In this process, typically called build management, programmers produce that code before submitting it to a centralized code repository. The right platform for code creation depends on the programming language chosen, and the programmer’s choice. It is common for the programmer to choose the development environment following the programming language chosen for the project and the stipulated development practices. This environment should, however, consist of several components. Capacity to write new code, generate much of it automatically, and quickly identify errors and debug code by leveraging an IDE (Integrated development environment). Testing tools that will enable you to create tests that validate the proper execution of the code. Lastly, continuous integration tools allow us to build pipelines that check if the code passes the criteria necessary to be integrated into the central code repository and automatically integrate and migrate the code between development environments. Examples of integrated development environments are PyCharm for the Python programming language, Eclipse for the JAVA language, or Visual Studio for the C language. The testing component, specifically for unit code testing, depends on the chosen development language. Some examples are JUnit for the JAVA programming language and Nose2 for Python. There is, however, a new trend in testing, collaborative platforms for visualizing the quality of the produced code both in terms of unit tests and test coverage. An example of such a platform is SonarCube. Finally, and focusing on the continuous integration part, examples of this tool are Jenkins or CircleCI.

2.5 Information and knowledge center. Proper information management, documentation, and knowledge in distributed and agile information system projects are crucial to ensure continuous alignment between all project parts. Teams use wikis for ease of creation and knowledge sharing. These are often integrated with version control tools to allow navigation from the source code to its working documentation or even to the programming standards that were used in the development process. Another vital source of knowledge about projects is the so-called readme.MD files, are usually included in source code repositories and include information about the structure of the repository as well as instructions for installing and configuring the product. Looking further at the size of the source code, the correct use of comments during the development phase is also crucial. It makes it easier to read and understand the purpose of each code block and thus facilitates the work of the most diverse remote teams in maintaining the code generated by the various parties. Besides this fact, some services allow, through comments in the code, to automatically generate technical documentation about the product or service. Examples of such platforms are Atlation Confluence for managing private wikis and Doxygen for the automatic generation of documentation through comments created in the source code.

Given the increasing complexity and quantity of information systems that organizations have been developing, in certain situations, it is necessary to manage the development process in a more integrated and controlled way.

One of the strategies to follow a more controlled but still collaborative process of managing a product is implementing a product life-cycle management (PLM) platform. This integrated strategy allows us to control the entire life-cycle from planning to operation. This strategy will enable products and their features to be managed in a distributed way and encapsulate many of the features previously identified in communication tools and information systems development. Despite some apparent benefits, dependency on a single technology vendor can create disadvantages in agility and incorporation of market best practices. Organizations that follow this option become dependent on the speed of the PLM platform vendor.

An example of this platform is IBM Engineering Lifecycle Management Base, which allows collaborative systems development. It enables requirements, quality, change direction, and project management and monitoring.

Once again stay tuned for more articles!

Rui Machado

Agile frameworks have revolutionized how technical teams develop and deliver digital products worldwide. Its collaborative nature and adaptability to business changes and the speed of delivery with incremental iterations on products have led companies to follow these agile frameworks to manage their internal projects. However, the recent COVID-19 pandemic has introduced new challenges in maintaining the collaborative aspects of agile frameworks.

The multiple lock-downs worldwide have forced knowledge workers to work remotely from their homes, reducing and sometimes removing any physical interactions between agile teams and their members.

This new reality has introduced a new type of agile reality, even after lock-downs terminated as workers demand options to continue working from home, where ceremonies and interactions happen entirely on digital platforms. This new post-pandemic agile world requires companies to adapt multiple agile management processes to deliver value efficiently. However, managing remote teams using an Agile framework is not a new problem. Globalization and the advent of digital communication platforms led companies to introduce the remote and distributed dimension to their processes.

Still, this pandemic accelerated the processes and became an agent of digital transformation.

All in all, it makes us believe the lessons learned from past research can and should be applied to this new post-pandemic world. With this in mind, this article reviews the primary literature references for managing distributed and remote agile teams in the context of information systems and software engineering, with all its challenges. It provides suggestions on fixing them or at least minimizing their impact.

Challenges of managing agile remote teams

It is relatively easy to split independent components and software modules across different individual contributors in multiple locations thanks to the existence of several web-based collaboration tools, integrated development environments, conversation platforms, document sharing tools, or cloud-based services.

However, tasks that involve greater collaboration, dependency, and interaction between individuals bring another type of discussion. Requirements analysis and specification, information systems design or quality testing are more complex to distribute since they involve a constant conversation between individuals who are often located in different countries, time zones, cultures, and companies.

Thus, despite the benefits that these work distribution paradigms provide, there are some management challenges that, if not properly taken care of, can jeopardize the project’s success. Such challenges mostly involve:

1. Managing communication between different resources with all its challenges, namely, cultural differences, very different time zones, and the lack of tools for formal communication of system documentation.
2. Manage requirements efficiently to ensure the final quality of your deliverables is perfectly aligned with the real needs of the system’s end customers.
3. Align project management practices among the various teams to avoid inefficiencies between them. Such practices help distribute work efficiently and structure the system requirements correctly.
4. Manage all the knowledge generated with the preparation, execution, and closing of the project to avoid problems such as duplication of work or misalignment in the development of system components. Distributed development environments should facilitate this process by providing tools and processes to centralize the storage of this knowledge.
5. Manage the risk of misalignment between teams to design mitigation strategies to avoid and contingency strategies to resolve threats to proper project execution.

Now let’s see how one can improve in each of the previous challenge groups with practices and standards.

Tips and tricks for creating leverage in a remote agile management scenario

1. Improving communication and collaboration management

Collaboration and communication are crucial aspects of agile frameworks. One of the twelve principles of the agile manifesto is that business people and developers must work together daily throughout the project. This is a means to ensure the team is delivering value instead of misaligned or unasked features. Another principle suggests building projects around motivated individuals, giving them the environment and support they need, and trusting them to get the job done. Lastly, I highlight a principle around physical meetings, namely that the most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

• Do not underestimate cultural change. To ensure the success of Agile in an organization, the organization must change its management culture, giving autonomy and decision-making power to those who implement the systems. In a distributed model, the parties involved may have different cultures, and working on this alignment at the beginning of the project is a factor for success.
• Plan frequent travel. Given the efficiency of personal interaction compared to virtual meetings, it is advisable to budget for team travel. This practice is of greater importance at the outset of projects to ensure more direct and personal socialization and thus minimize interactions in virtual communications.
• Ensure that all parties appoint and send ambassadors to the various locations. Since Agile assumes much personal iteration between stakeholders, in cases with significant time zone differences, ensuring the presence of an ambassador from each party involved in each project location can help with communication. This practice also powers face-to-face interactions more in line with Agile.
• Consider a common Agile Coach that ensures alignment between the practices and speed of the various teams in the Agile context can be facilitated by a common coach for both teams, who are willing to travel and can constantly remind them about the principles and values of the methodology they have chosen to work with.
• Consider custom shifts. Although potentially leading to some fatigue and attrition, in cases of large time zones differences between teams, consider maximizing contact windows by having a team start earlier or later than normal.
• Facilitate remote communication technologies in environments close to physical and personal interaction. Minimizing the impact of distance by facilitating and enhancing communications is crucial to ensure a solid and aligned response among all teams. Before starting the project, it should be assessed that teams have access to video conferencing tools such as a digital whiteboard (Miro is a great option). A dedicated channel on instant messaging platforms and email lists with all project stakeholders can also help facilitate communication.

2. Improve requirements management

Agile frameworks assume that requirements emerge during system development rather than all at once. They keep iterating over them, refining and adjusting, them along the product cycle, through collaboration between the Product Owner, Development Team, and end customers.

In this way, the final quality of the system depends mainly on the requirements elicitation and management process to identify the real needs of the system’s end customers.

However, increased by the logistical costs of organizing face-to-face meetings, lack of experience in distributed projects, cultural misalignment, and distinct agile practices, requirement management needs new practices and adjustments to achieve the success it would have in an agile project with co-located teams.

Some main threats identified for poor requirements management in distributed agile information system projects are:

• Lack of version control,
• Lack of common language between teams,
• Differences in terminology,
• Lack of enthusiasm,
• Lack of team spirit.

All these threats jeopardize correct requirements management and create barriers to the success of a project implementing an information system in a distributed agile setting.

The following are examples of practices that one can use to mitigate these issues.

• Use test scripts for requirements validation Given the distance between teams, it is important to relevance correct requirements management. The use of test scripts, also called acceptance tests, can be attached to a user story to help the programmer understand if a requirement is already solved or not. This way, even if the development and testing teams are split, alignment is created via this artifact.
• Create a hybrid requirements analysis team The dispersion of teams across distributed projects can lead to requirements not flowing efficiently between the requirements analysis team and the various development teams. It is therefore recommended to involve members of all teams, internal and external, in the requirements management process.
• Create and implement requirements analysis templates The different parties involved in a project of this nature will have different expectations regarding the requirements documentation to be produced. It is therefore essential to align on requirements sharing and discussion model so that both parties are aligned.
• Develop a glossary of project terms Cultural and linguistic differences often create difficulties in understanding technical and business terms. Thus the creation of a project glossary can mitigate misunderstandings in project discussions.
• Implement a requirements version control tool There should be an easily accessible platform, online and offline so that all parties can consult and manage the different requirements that are being created and changed throughout the project.
• Implement a requirements management responsibility matrix It is important to define from the start, which communication channels should be used, by whom, and how so that no requirements-related information is lost in the process.
• Maintain constant and proactive communication There should be constant alignment on the requirements to be implemented. Videoconferencing tools can assist in keeping all parties involved in discussions.
• Identify and engage enthusiastic employees Some internal employees may not be comfortable with distributed environments with high knowledge sharing. By creating enthusiasm, we leverage internal support for requirements implementation by external and re- mote teams.

3. Improve project management standards

The agile and remote development of information systems introduces several challenges from the point of view of project management such as:

• The estimation and planning of work,
• Handling dependencies between teams,
• Division of labor by several remote teams,
• Documentation management,
• Or even the management of conflicts at a distance is just some of the problems associated with this issue.

The sooner we know about a bottleneck, the faster our corrective action will be to correct eventual management problems of whatever nature they may be. Part of the solution to this problem is facilitating communication and access to information. Thus, faster delivery cycles accelerate the process of feedback on the implemented or to be implemented functionalities.

The following are examples of practices that one can use to mitigate these issues.

• Create feature teams and not activity ones To keep the dependency and waiting be- tween relocated teams to a minimum, we should structure the work into independent user stories requested from any team for implementation. We should also avoid dividing stories into tasks and distributing them among teams, which would lead to specialization by activity. Instead, the teams should receive the complete user story and distribute it among themselves, respecting an organization of cross-functional and autonomous teams.
• Hold short, regular meetings for status updates, adapted to remote teams Agile frameworks recommend daily meetings to evaluate the current point of evolution against the Sprint objectives. Given several obstacles with remote teams, even more so in the case of significant time differences, bi-weekly status meetings may be enough to keep the teams aligned and avoid wasting time with daily preparations. Meetings on other days can be held locally, using team representatives.
• Define short sprint iterations tailored to remote teams Agile frameworks typically follow sprint iterations ranging from 1–4 weeks. However, in the case of distributed development, we should aim for shorter iterations, between 1–2 weeks.
• Consider iterative Sprint planning sessions adapted to remote teams. In agile frameworks, there is usually a planning session at the beginning of each sprint, wherein in just one session, the planning is done. However, these sessions can take several hours, a problem with teams in different time zones. Therefore it may be advisable to do some of the structurings such as task creation, prioritization, and test scripts creation before the planning session, over the ongoing sprint. Later, in the planning session, only some final adjustments are made.

4. Facilitate knowledge management across your teams and people.

Knowledge management can be classified as an area that provides answers for collecting, storing, and sharing knowledge, thus allowing the creation of alignment between the different parties involved in a project, facilitating collaboration and coordination.

In the scope of an information systems engineering project, knowledge must be managed in all phases, namely in the elicitation and management of requirements, the development of the systems and respective tests, and the installation and configuration of the final product.

Knowledge about best practices and experiences must also be managed constantly throughout the project to reduce duplicate work in the future. In most projects, this knowledge can be found explicitly, but it’s usually scattered, in code repositories, email conversations, instant messaging conversations, meeting room whiteboards, or even personal notebooks.

Without an efficient knowledge management process, organizations face several obstacles to exploiting the benefits of Distributed Engineering, such as:

• Not being able to timely communicate changes to requirements across the various project teams
• Getting the best support in solving an already known problem.

It is therefore essential to create rules and implement knowledge management processes. The following are examples of practices that one can use to mitigate these issues.

• Consider increasing the volume of documentation produced Agile frameworks assume a greater focus on system development than on documentation production. However, given the less personal interaction in a distributed environment, we should consider creating a minimum set of documents in the project. In addition to system designs or server topologies, we should also make more significant support for documenting requirements, documenting code repositories, and documenting functionality.
• Identify and implement a list of base documents to be generated. This practice allows you to communicate to the entire team which documents are expected and who should create and maintain them at each stage of the information system development process.
• Use tags to classify conversations, videos, or shared images. Any instant message, image, or video should be classified or named according to a set of existing and previously agreed upon tags. The main reason for using these tags is, on one hand, to cluster by topic and, on the other hand, to allow a faster search for related artifacts.
• Use alarm systems to identify missing documents When the responsibility for creating and maintaining documents is dispersed among several teams, it is essential to have alert mechanisms in case of missing critical documentation.
• Use alarm systems to identify changes in documents Given the number of parties involved, everyone must be aware of the latest changes to avoid misalignment. This practice allows that whenever a document is updated, an update message is sent to all project members.

5. Minimize the risk of misalignment

Mitigating bugs is a core responsibility of agile teams. Agility can only happen if the team’s focus is on the risk tasks and the deliveries come with the quality the stakeholders are expecting. This way, teams will not entirely consume their bandwidth with bug fixing or adopting previous developments.

This problem is even more critical in remote and distributed scenarios, given that teams will be split.

When working from home, the number of distractions that can lead to mistakes is higher, the fatigue caused by not interacting with people in person will be equally higher, and thus, measures need to be put in place to mitigate risks and control the overall quality of the products.

The following are examples of practices that one can use to mitigate these issues.

• Start with bug fixes rather than new features When several teams contribute to the same code repository, it is possible that in some cases, the code has been started in one location and then expanded to a remote partner. In this situation, and to mitigate errors due to a lack of understanding of code structure and logic, the new team should start by fixing already identified bugs rather than contributing to new features.
• Perform constant builds to get feedback on new features This mechanism allows a quick response by end-users regarding the alignment of the final result with the initial requirements. Thus, with the existence of constant development cycles, any changes or corrections that need to be made are identified in advance, and the requirements adjusted.
• Leverage continuous integration techniques. Integrating code developed by teams in multiple locations can be challenging. So it is a good practice that all teams contribute to a single code repository. They all use the identical continuous integration process to update or patch features in any environment, whether development, quality, or production. This way, the code is always up-to-date and testable for any party involved.
• Use peer review techniques. This technique suggests that a peer programmer should review the work done by another. Leveraging web-based code versioning platforms such as github or gitlab, programmers can quickly review and approve changes to the code base.
• Use automation whenever possible, replace manual, repetitive tasks with code or bots that automatically perform such operations. By automating tasks, we minimize the risk of failure and thus improve the overall quality of systems.
• Leverage test-driven development. In test-driven scenarios, programmers start by de- signing a test case, which leads to the implementation phase after being approved by its team. This leads the development team to think about code outcomes and then implement a code block that yields such results. It is a good tool for splitting work across the team in a remote agile scenario. After a collaborative agreement of the test cases, the work can easily be split, and each member has a test that helps assess the completeness of their implementations.
• Invest in a proper digital onboarding program As new team members will be onboarded remotely, they must receive the same training and information that will help them start delivering value in alignment with the company culture and practices. Such will prevent bugs and misalignment due to not fully understanding the context, domain, tools, and practices.
• Invest in digital team buildings Team buildings can help boost a given team’s energy. While before teams could have lunch or do activities together, being in a remote scenario makes it harder to do so. So investing in digital team buildings can mean playing a game together or even watching a TV series. This is important to keep building the team culture spirit and boost energy.
• Consider no meeting days Remote environments will naturally increase the number of digital meetings, leading to eye fatigue. Creating a weekly no-meeting day can help teams adapt their calendars to have focus periods without interruptions and thus put more attention to their tasks.
• Consider regular digital 1:1s with direct reports Feeling lonely can eventually lead to depression which will naturally introduce risks to the project. Regular meetings conducted on digital communication platforms, either weekly or biweekly, with direct reports, can help understand their feelings and design support plans.

These 1–1s should be short and focus on the human being, the employee, and thus, not on the work itself.

Conclusions

COVID-19 had introduced a whole set of new challenges to companies, some of which had never tested remote work before or did not believe it could be implemented without affecting a team’s productivity.

On the other hand, Agile frameworks were widely adopted as the standard for managing software engineering projects. These two phenomena together became an agent for digital transformation. Companies had to rely on remote work to continue their operations and adapt their agile practices to support digital meetings instead of physical ones and provide the tools for constant interaction of team members and better knowledge and document management.

However, several of these challenges were already being researched for years, as the natural course of software and information systems engineering-led teams to be more remote and supported by digital technologies to manage their projects. COVID-19 accelerated this change, but the core challenges were not new. Solutions to overcome and mitigate their impact exists and can be applied to companies to manage their remote agile processes better.

Thank you and stay tuned. In the next article, I will be focusing on what technologies we can use to accelerate the adoption of the practices mentioned before.

Rui Machado

Originally published at https://medium.com on March 28, 2022.

• Understand the mood and motivation of employees
• Gather and share important information
• Set and evaluate continuous improvement behaviors and training for every one of them.

However, when it comes to the continuous improvement of your teams, I believe this only gives you the individual perspective of it, we are lacking the team perspective. We also need a tool to perform 1-Ns on top of the 1–1s.

I have been recently working on a framework to assess the basic maturity of a team and using that establish a proper continuous improvement discussion channel.

The main goal of it is to provide a communication channel between a development team (Regardless of its scope, data, software, mobile or DevOps) and the engineering manager.

This framework is inspired by the well-known black-box model and I call it:

• Continuous Discussion Model (CDM) — The model that sustains the discussion
• Continuous Discussion Workshops (CDW) — The sessions that follow-up and set the action items every month
• The main goal of this model is to guide the discussions about which areas of the whole development process we want to improve (As a team).

Explaining the continuous discussion model (CDM)

The model has a set of 6 areas of analysis and 5 levels of maturity. Let’s start by looking at the areas of analysis.

1. Requirements/Definition of Ready

Under what conditions do we accept new work?

How can we improve our understanding of requirements if needed?

Who are our points of contact

2. Issue/work logging, monitoring, and tracking

How can we properly track our work?

Are we updating our tickets when they move status?

Are we helping our stakeholders by commenting on what we did on a ticket?

3. Deliverable/Definition of Done

When do we consider something is done?

How do we make sure we are delivering what customers have asked?

Is our trust increasing or not?

4. Engineering excellence/practices

Is our development process efficient?

Are we using the best tools?

If a new person is onboarded how do we keep delivering without affecting quality?

5. Automation/ CI and CD

If I deliver something today how do I make sure I can deliver a similar artifact with the same quality tomorrow?

Are we wasting time with manual tasks that can be automated?

How do we decrease the risk of failed with automatic testing?

6. Ensure quality end-to-end?

Are we spotting issues as soon as possible?

Do we trust the quality of our deliverables?

Should we peer review our work?

Even though all these areas are important, focusing on all at the same time can be too ambitious and lead to a loss of focus. This way I propose a set of 5 maturity levels to bring the teams to a better quality of delivery.

To illustrate how this level complements each other I will take you through the process of making a pancake on-demand.

Level 1 — The basics

This level is all about the basics. In order to implement a development process, you need to make sure:

1. Requirements are flowing into the team frequently
2. Your development team has proper tools and hardware so that they can start delivering
3. Deliverables are produced often and feedback from end-users is being collected (Search for content on Agile, Lean, XP and Kanban to improve here)

Basically, there is something coming in, development is being done and something is coming out. It’s making sure the basics are there: requirements, people, equipment, communication, and feedback channels.

The pancake challenge: In this level of maturity I am able to get all the ingredients, the pan, and a stove.

• I can turn the stove on, put the pan in there and cook a pancake following a recipe.
• Because we only focus on the process its normal that we waste ingredients, the pancake is not tasty or that it takes us 2 hours to do one pancake and that the customer complains a lot about it.

Level 2 — Control it

This level is all about controlling the workflow and is probably the most complex one and, if properly implemented, a game-changer in terms of quality of delivery. As we grow in maturity we need to keep track of what we are working on, split the work across the team and make sure we can anticipate what is going to be developed. Tools like Trello (For simple environments) or JIRA (for more complex ones) play a major role in this step and you should consider having them in place at this level.

If you look at the previous figure you will notice there are some rectangles in the development phase. This is very important to make sure we can assess, at any given step of our scrum sprint or development phase, what is going on, how is it going and if we are going to deliver it with the expected quality at the expected time.

Another important thing at this level is making sure the requirements you are receiving are properly structured and are fully understandable and that whatever you produce is following a set of rules that ensure the minimum quality of delivery.

In terms of items to focus on at this level of maturity:

1. Definition of Ready: To ensure that the requirements are coming in such a way that there are no doubts about what needs to be done, who to contact in terms of doubts, the DoR is the best tool for you. This is a commitment of the development team stating that: “If you guys follow these rules and give us these required inputs, we are able to start working on your request and deliver it with the expected quality at the expected time”.
2. Issue tracking: When our projects become more complex, tracking the work being done by the team can become a complex task. However, it’s crucial that we have a process that states: how to log new work; what work status should exist and how to move between them (and who can do it); how to make visible to the whole team the current delivery status compared to what was promised. Again, tools like Trello or JIRA play a major role here.
3. Monitoring and Tracking: Here I am not talking about systems monitoring, I am talking about work and this means it’s important to implement processes (some tools make this very simple), that allow us to understand where we stand and if something starts getting delayed we can immediately act on it.
4. Definition of Done: When your team says it’s done, what does it mean actually? This is what the DoD answer. The team should agree on the criteria that make them say development is done and can be delivered to your end customer. This is quality assurance as your stakeholders and end-users know that everything that is released at least followed those rules. This does not create bulletproof items but ensures minimum quality.

Hint: DoR and DoD for those using JIRA can easily be added as a new ticket attribute (Checklist) and be used to condition the workflow of a ticket. “It can only move to close if all DoD items were ticked”.

Basically, in this level, we implement a process that allows us to know: what work is in backlog, what’s being implemented now and what’s the status and what does it mean when the team says it’s done.

The pancake challenge: In this level of maturity I am able to access if the ingredients meet my quality standards, I can easily anticipate how long it will take me to finish my pancake and what does it mean to say my pancake is ready, in more detail:

• When someone asks me to do a pancake plate, it tells me nothing about how many does he want, if it should come with a topping or not and even if he wants it warm or cold.
• I get tired of complaints, so I start making a set of questions when people make an order so that I can meet their expectations at the end.
• I know exactly how long does it take to make a pancake so at any step of the cooking process I can tell my customer how much more is needed to finish the pancakes.
• I start following a picture of the expected outcome so that my customers know exactly what I am going to put in front of them at the end of the cooking process.

Level 3 — Excel on in

This level is all about excellence. For whatever you are doing, are your following best practices, validated in the community or following the proper rules to writing code?

This kind of initiative is important not just to embed quality in your development process but also to ensure a standard communication and understanding or your architectures and implementation across all team members, even new ones.

Some examples of what can be brainstormed with the team at this level are:

• Implementing a coding standards document stating the basic rules to writing code in your development cycles.
• Consider the usage of proper branching strategies to increase the control over your versioning process.
• Consider the usage of infrastructure as code frameworks to ease and give more maturity to the management of your infrastructure.

Although the previous examples focus on technology, also think about the organization of your team, considering things like:

• Do we have the proper hard skills to execute our work? (Consider creating a skillset matrix)
• Should we deliver training programs to our resources?
• Is our team properly setup? Are we missing a required role?
• Is our Agile method efficient?
• Consider reviewing your agile process and improve it with the team.

Hint: Again, it’s important to mention this is the moment you take a team that works and transform it into a team that shines and achieves high output levels.

The pancake challenge: Now that I have the ingredient, control the process and have a recipe, I keep facing the same problem, the pancake is not tasty enough and it looks different every time I do it. In order to fix it, I have decided to enroll in a cooking course so that I can learn the best practices on how to cook a pancake.

After taking the course I have learned that I was not mixing the ingredients in the right order and was using too much oil to cook it. Now my pancake is tasty and my customers are enjoying it.

Level 4 — Make the machine work for you

When we assemble a team, development or not, making mistakes is important as they allow us to quickly learn how not to do something. However, once you achieve a certain success you must make sure your quality of delivery is predictable and that whatever you produce will be delivered with a similarly “taste” to the previous one.

I like to think of this level as the one where you turn your team into a McDonalds one. Imagine what it would be to go three times to Mcdonalds and your big mac tasting differently every time. What will naturally happen is that you lose trust in the restaurant as you cannot anticipate how your burger will taste.

But the problem at this level is not just the quality of the product, it’s also the speed of delivery. Again, imagine your big mac takes 10 min to deliver today and 1h tomorrow. In order to have efficient teams that generate trust, both quality and time to market should be predictable.

One of the best ways to ensure repeatable quality is through automation because as you know computers are great at following orders and can make it in a very similar way every time.

In development processes this can be achieved in multiple ways:

Implementation of Continous integration and continuous deployment pipelines (Read about DevOps if you want to know more about it.)

• This will make your “idea to production” process repeatable, predictable and faster than compared to performing it by hand (You never know if your developer got a bad night, and will make a minor mistake that will cost you a big chunk of your system availability)

Automation, Automation, Automation, just look at all the manual processes your developers are doing and invest in scripting it.

• It can go from turning EC2 instances on and off automatically to extracting a certain dataset from JIRA to even smaller things like monitoring the success of your ELT flows.

Containerization.

• A container is a standard unit of software that packages up code and all its dependencies so the application runs quickly and reliably from one computing environment to another. (Got it from docker website)
• This is a great way to implement automation at the application migration between environments level and makes the setup of environments very straight forward and predictable.
• Consider the usage of containerization for easing the deployment process.

More ways might exist, it’s up to you and your team to assess which ones exist and when and how you want to implement it.

The main message in this level here is, if your team is doing something manually, frequently add it to the action items as an automation opportunity.

The pancake challenge: Remember my McDonalds example above? It’s exactly that. How can I make sure that whenever I do a pancake it will take a similar time than before and will taste the same way? (I am not an expert cook so I will leave this one to your imagination -should have stayed with IT/IS examples…)

Level 5 — End-to-end quality measures

This level is all about quality. And not just the quality of the deliverable but the quality of the whole implementation process and of the software that is being operated. We need to make sure as a team that we fully control what is happening in a timely way.

I am not a fan of implementing quality controls everywhere but of implementing the ones that will allow us to trust whatever we develop and deliver. And of course, this is highly related to the complexity of the system we develop as simple systems might require fewer quality gates than complex ones.

The reason I am an advocate of controlled quality is inspired by how typically a factory works. If a factory is producing thousands of products every day and decides to assess the quality of each one of them, it will take a lot more than if they do quality analysis over a sample of those. This will allow them to assess how much they trust the quality of the products developed in one day and of course if there are many defects they can still act on it. Its a tradeoff between speed of delivery and number of defects that go to waste.

And this example leads me to my point: trust. You should invest more or less in new quality controls based on the trust you have on the quality of your deliverables. If your team is delivering high-quality ones, totally aligned with your business stakeholders that are scaling well, follow a normal continuous improvement pace and keep adding new controls. However, if you are constantly failing and bugs are increasing like hell, spend more time with your team at this level and implement as many controls as necessary. But whatever happens, don’t freak out, working software is still your best quality measure.

In development processes there are many quality controls that you can implement but start by brainstorming the following with your team:

Unit testing this type of test allows you to test individual units/ components of a software.

• See that new transformation function your team is working on? It should have a corresponding unit test to make sure the basic behavior is working. This type of test makes sure that atomically all your system components work. However, they don’t test them in an integrated way.

Integrated Testing is when individual software modules are combined and tested as a group.

• Say you have a data engineering team and they are developing data pipelines. This is the time of the test that combines all transformation functions into the required pipeline and assesses that the outcome is expected.

Code coverage is a measure used to describe the degree to which the source code of a program is executed when a particular test suite runs.

• It basically tells you how much of your code is being tested. Say you score 80%, that means there is 20% of your code that was implemented and not tested using a unit test. Meaning it is at high risk of having a bug and potentially break your system

Logging allows you to keep track of all the events that have occurred in your system (Say all the records you have processed, the number of exceptions thrown in your try…catch block, etc ). You can save it to a file or use a proper logging platform such as Splunk.

• This will allow you to know exactly what happened and when it happened in your system. Imagine you receive a call in the middle of the night saying your ETL flow as failed, where are you gonna check what happened before relaunching the chain? In your logs. Without it, you should pray that your systems don’t fail because if it does you won’t know where to check that.

Systems monitoring allows you to know the health of the infrastructure where your applications are running but also the health of your application like the availability percentage, downtime, etc.

• This is critical to make sure your environment is healthy and that your application is performing in accordance with what is expected.

The pancake challenge: Imagine one of your ingredients say an egg, is rotten. This should be your first control check, making sure your base ingredient is not expired and that you can trust its usage. However, I also need to make sure that I am following the recipe properly so maybe I should write it down, follow it carefully every time, weigh the ingredients and test the consistency and looks of the pancake at every time.

Last but not least, should I try every single pancake before giving it to my customers? I don’t think so, maybe its enough to ask for feedback from them and to do a proof of concept once in a while. What if a customer complaints? In that case, I should be careful in the next pancakes and try a little one before serving to the customer. Once the trust is restored I can start cooking without fear again.

All this will ensure my pancake is of good quality, can be delivered in time and my customers trust my work.

Implement the BB model and the CDW sessions

You should take the previous model and thing of the best way to make it work in your teams. However, I would like to leave you with a suggestion of implementation, namely:

Step 1 (One time): Do an initial 1-hour session with the whole team introducing the CDM and the CDW sessions

• 20 minutes to talk about the model
• 40 to identify a set of action items at least for the area 1 of the model
• You should go sequentially over the areas of the model from 1–6 and stop when no more time is available (If you stop at 2, it’s ok)

This initial session should introduce the model to the team, set the governance rules like how frequently will it occur, what’s expected of it and also do an initial round of brainstorming.

It’s fine if you don’t go through all the areas of the model, the goal is to keep improving every month, so don’t rush to go through all the areas in every session, make it incremental and respect the team’s speed and maturity.

Step 2 (Recurrent — After every CDW): Keep your action items in a spreadsheet

Create a spreadsheet with the minimum columns:

• CIW Session Date | Area in the CDM Model | Action Item | Owner
• 20/03/2020 | Requirements | Implement end enforce a DoR | Rui Machado
• Share this spreadsheet with the whole team

Step 3 (Recurrent): Do a monthly follow-up

In every monthly session:

• Review progress of last month
• Revisit or continue brainstorming the black box areas (In sequence)
• Define new improvement targets for the following month.

30 days is a good timeline for setting a continuous improvement pace but you can do it less frequently is needed. Be careful not to make very frequent otherwise, you might fall under the sprint review and retrospective scope of action.

Hint: You can use the MBO (Manage by objectives) technique to improve your CDW action items. Set quarterly or yearly objectives for your team in terms of performance improvement and use the CDW sessions to evaluate your progress considering the action items as key results. This makes this tool bigger than a sprint retrospective as it manages continuous improvement from a control tower. In order to distinguish it:

The sprint retrospective is based on what the team has learned from working together in the last sprint(s) and what can be done to either make sure it will stay (Positive learning) or to mitigate it (Negative learning)

Continuous Discussion Model and Workshops are based on best practices and market trends and are not related to any team learning. This tool brings ways to challenge your processes and technologies and come up with innovations the team would like to test and implement, regardless of its experience as a team. Some of these items might overlap the agile principles and values and in this case, can use the sprint retrospective to implement them and others might not.

• Example 1: “There is no evidence from past sprints that containerization is required to keep delivering value but the team would like to achieve a new level of speed and quality in its continuous deployment process”
• Example 2: “The team would like to implement a new technology stack that the tech community has shown to prove it speeds up the data ingestion process, however, they need training for that.”

Step 4 (Recurrent): Keep the results visible for everyone

• It’s important to make your achievement visible and to track the percentage of action items that are accomplished every month.
• Another important note is that your model will become more robust if you set KPIs for your action items, which will allow you to track the adoption even after you consider it as implemented.
• Use JIRA or monthly reports for it

Example:

• Let’s take our previous action as an example: Implement end enforce a DoR
• You can create a KPI: #Number of tickets frozen by bad requirements or even #number of functional refinements required per sprint

— —

Final message: Even if you feel your teams are working well, there is always something to be improved. Test this approach and be surprised by how a team can improve if they feel heard.

— —

Let me know what you think of it! Drop me a message or email.

Thank you,

Rui Machado

Focusing purely on results, without considering this kind of approach, might lead to an amazing product that, in the end, will fail at first try. It creates the distrust feeling in users that makes an amazing technology deployment to be postponed for years.

Although we like to try everything, this is exactly what we want to avoid. On one hand, at HUUB, we are focused on supporting our people with amazing technologies that will extend their capabilities, instead of replacing them. On the other hand, we don´t fall into the disconnection issue of building something that uses state of the art technologies but fails to prove that it adds value for our co-workers.

An HUUBnormal pragmatism is the key for artificial intelligence with value

Just like your eyes get used to a bad eyesight so do companies to their performance when they rely on gut feeling and we all know what happens if you close your eyes while driving your car. We like to think artificial intelligence as the missing glasses in both strategic and tactical decision levels and once on, everything will start being much clearer. As we like to put money where our mouth is, take the following examples in consideration:

Email classification. Our Account Management team spends most of their day communicating with our brands for multiple reasons: going from returns handling to stock issues. As it is our goal to have a much more active role in giving insights to the brands managers, we had to do something. With this mindset, we created a text classification algorithm based on a set of historical email conversations. Our model then learns to classify future emails according to a set of topics. This allowed us to have full visibility over the most frequent problems that a given brand has and guide our operational and strategic focus to fix them. In the end, the goal is met, to relieve and leverage our account management team.

Order to box. We love to work with retail brands, but this comes with very specific issues that have to be fixed in order to become competitive in the Supply Chain Management industry. Take this as an example, a given brand attends a fair and sells its trendy apparel to multiple boutiques. It will start producing the items and three months later HUUB will be shipping them, splitting the items at the reception moment. So far so good, but how do we know how many boxes need to be prepared to accommodate the items bought by each boutique? Imagine the time and money lost preparing the wrong set of boxes and then moving all items to a new set. To solve this probelm, we created a volume estimation algorithm that, based on regular item features like category, fabric, supplier and size, calculates its volume and outputs the optimal pack set for a specific order. This allowed us to save around 20% of preparation times and 15% in shipping costs, depending on the service.

Operational planning. When you manage multiple Supply Chains from multiple customers with suppliers in all corners of the globe, different service level agreements and more than 65 destination markets, having business rules planning operations is not an option. With just a few brands, a team of analysts might be enough, but with more than 30 it becomes humanly impossible to understand all contexts and prioritize operations. Our approach was to look at all pieces of the Supply Chain Management processes and create an abstract mathematical model that fits all possible variables and constraints of the planning process. After building the abstraction, we were able to customize the model using the business rules of all our brands and output on a daily basis the most optimal plan for the following two weeks. This allowed us to save costs with not optimal activities and at the same time prepare the company for to scale.

We are focused on people and on the support of our business growth. We leverage the combination of math, statistics, machine learning and deep convolutional neural networks, as our weapons to tackle the obstacles that we face on our path.

Well, we also like to push the limits…

At HUUB, we take food very seriously. Being part of a startup, we are not lucky enough to count on a canteen. So you either bring your own food or you need to eat outside of our facilities.

The routine is the following, around mid-day, we start our active discussion on what to eat, where to eat and who wants to join the horde of nomad eaters of our company. Not having too many co-workers makes this as easy as standing up and shouting out loud who wants to go. But this is too easy for an artificial intelligence backed industry 4.0 company.

What if we could build an integrated system? One that, based on the daily menu of a restaurant, generates a slack-based poll and, at a given time, automatically calls the restaurant to reserve the required food and tables? Well, we did it. And guess what, every day we save 20 min of all our nomad eaters.

Based on our historical data, I think you should use the key…

Thinking analytics is nowadays a multiple dimension problem, companies must think descriptive to understand its figures and keep track of the company performance. Even so, with the recent innovations that democratized machine learning and artificial intelligence, companies should start thinking about prescriptive and optimization.

HUUB is bringing this mindset to the Supply Chain Management industry. It is increasingly demanding more and more agility to answer consumers expectations. So, in a nutshell, we offer solutions that generate insights and optimize processes that have been stuck in manual operations for too many years.

By the way, we are offering tickets to join us on this amazing trip, revolutionizing, with pragmatism, the data analytics world! Do you have what it takes? Check our jobs.

Thank you!

Between the future and the present, lies the pragmatism was originally published in HUUB on Medium, where people are continuing the conversation by highlighting and responding to this story.