Achieving Digital Assurance through Agile Teams: The Tuckman Approach

In recent years, organizations have increasingly embraced digital transformation, aligning themselves with end-to-end digitization to improve customer services and deliver high-quality products and services on time. The traditional quality assurance approach has become more oriented toward providing high-quality customer experiences through flexibility and versatility rather than accommodating rigid business specifications.

With the emphasis being on a wide range of customer engagements, such as ease of use, look and feel, user feedback, performance, seamless transitions, and reduced complexity of objects, quality assurance has transitioned from testing functionality to testing user experience. 

Want to have your software and application work well? Get in touch with our digital assurance experts

Get in touch

Transforming business methods and strategies into digital models has also changed how software development and quality assurance are performed; lightweight proactive frameworks such as Agile specialize in incremental and iterative delivery of software. Teams are increasingly becoming cross-functional, with quality assurance integrated into the development process. The dev-ops process is leveraged to help automate packaging, deployment, test & delivery in digital assurance services, development, and the production environment. 

While organizations and programs are undergoing digital transformation and adopting these lightweight software development frameworks, teams face many challenges in planning, executing, and collaborating with the project and business stakeholders. They struggle to offer value to the business in terms of scope, budget, and ROI maximization and frequently fall into antipatterns.

Let us outline the common resistance and antipatterns by the team.

1. Conflict firefighting: While development and QA now work together and are cross-functional, members are hesitant to express their thoughts openly even if they are challenged with conflicting ideas and approaches and adapting to the new time boxes and practices.

2. Lack of commitment: Lack of collaboration, such as no daily stand-ups, pair testing, and pair programming, compels leadership to make decisions without the knowledge and buy-in of the rest of the team. Without a proper understanding of the available capacity, they may overcommit or under-commit, which can impact the quality of the delivered product.

3. Need for upskilling: Adopting a new process such as DevOps and the latest technology stack can affect delivery timelines if coaching and mentoring are not provided at the outset. Only by upskilling can employees self-organize and take responsibility for the promised deliverables.

4. Inattention to the outcome: When teams fail to delivermeasurable results and deviate from objectives, team members may focus on individual success over their team’s success, which can affect the final outcome.

5. Communication gap: Team members lack a clear understanding on how to work together, resolve impediments with the appropriate stakeholders, and inspect and adapt progress to the sprint goal, resulting in spill over to the next iteration or sprint.

Due to the above challenges and barriers, teams lack self-organization. They become incapable of delivering the working software on time, which in turn, can affect the business’s digital transformation goals. 

You might be interested in: Automated QA Transformation with highest level of Business Assurance

How are high-performing teams built?

Proposed by Bruce Tuckman

In the mid-1960s, Bruce W. Tuckman devised the most prevalent framework for teams to achieve high performance. This concept acknowledges that organizations do not begin by being completely functional. Instead, teams progress through well-defined stages, from forming groups of individuals to establishing cohesive, task-oriented teams. As the team grows in skill and maturity, its relationships become more intertwined, and its leadership style becomes more collaborative.

Tuckman’s stages of team development

Tuckman’s stages of team development are commonly known as Forming, Storming, Norming, Performing, and Adjourning.


The initial stage is the orientation and arrangement of the team structure. When implementing new technology, the organization must provide technical training. In this formative stage, teams are likely to be unsure of their objectives and how they will collaborate. They avoid conflict due to their need to be accepted into the group.

Team Members’ Mindset

  • They may be curious, full of anticipation, and optimistic
  • Team members are looking for a facilitator to guide them in the right direction.

In this stage, team members interact with their colleagues, build trust between themselves, and set roles and responsibilities for each team member.

For instance, the teams may establish an operating agreement at the start of the sprint execution, collaborate through daily stand-ups, and offer training on new tools and technologies. To learn and upskill, team members look for direction from an agile facilitator and technical lead.


Next, the storming stage is the most crucial and critical time for all team members. In this phase, the team may experience conflict between themselves by thinking that their way of doing a task is the right one. The team may thus focus on individual goals, and most of their efforts could lead to unproductive activities. 

Team Members’ Mindset

  • Unhealthy competition between team 
  • Loss of interest
  • Lack of understanding of the sprint goal 

In this stage, team members should receive feedback from their facilitator and try to clarify and understand the team goal. To proceed to the next step, team members must improve upon  listening to their teammates.

For instance, a conflict could occur during a code merge in the DevOps pipeline. Individuals are often offended when a code review is done, and corrections are requested to refactor the code and apply better practices. With a lack of synchronization, the team faces challenges in pull requests, and code stability is also compromised. The team will continuously fix the failures in the pipeline and create a lot of rework and technical debts.


When teams reach norming stage, they handle and resolve conflicts independently, establish guidelines, and leverage processes. The group begins appreciating their team members’ strengths and recognizing talents. As they develop team routines and focus on achieving task goals, members will acquire product knowledge, understand customer expectations, and develop negotiation skills with the business.

Team Members’ Mindset

  • Members build team confidence and trust each other 
  • Members start taking ownership and accountability
  • Members learn to collaborate effectively

This stage is where members are involved in creativity and leverage process betterment. Collaboration emerges during this stage among the team when work ethic and team goals are understood.

For instance, theteam will start following processes and establish guidelines to minimize conflicts. They will also perform innovative retrospectives, collaborate, and communicate with colleagues effectively.


The team is now well-established, mature, organized, and well-functioning in the performing stage. Each team member understands others’ strengths and weaknesses, and tight bonds emerge. Even if the team faces disagreements, they can now resolve them effectively and make necessary changes to processes and structure. 

Team Members’ Mindset

  • Members become self-organized
  • Improvement in creativity and personal development
  • Tight bonds emerge
  • High commitment and understanding of customer expectations

When members work in a cohesive and supportive environment, personal development and creativity are sparked, and team members have high morale.

For instance, team members are well-experienced, and the team becomes cross-functional. Each individual can perform tasks independently, without conflict, and they try to help other teammates. Team members are mature and begin predicting the task from the business, ask for and provide creative approaches, brainstorm ideas, and work closely with business stakeholders with continuous feedback loops.


This stage brings a sense of closure to a team whose objectives have been accomplished. The priority is completing final tasks, documenting the effort, and delivering high-quality increments ready for market use.

Team Members’ Mindset

  • Recognize and reward team efforts
  • Sadness occurs within the team as the end approaches

As the workload is in the final stage, there may be regret as the team ends, so recognize and reward team efforts. Individual members may be reassigned to other groups.

My Experience with Tuckman’s Approach

I am a person who is curious to learn new technologies and try to implement them in my working environment. I approached my manager about an automation opportunity at the same time as my client requested a new automation team, and I was fortunate to receive this opportunity.

We were excited to interact with each other and work collaboratively. We also had an orientation process where we became acquainted with the technical stack. Within a week, the team started working on the project. 

We started encountering problems where each member was working on the individual task assigned and failed to collaborate and discuss common issues and technical challenges. Conflicts arose between team members as each member was at a remote location, and merging code in the pipeline was a challenge. We all deviated from the iteration goals and were unable to deliver the working code on time. The core team facilitator played a significant role at this stage, giving us full support and establishing a collaborative environment where the team discussed impediments and brainstormed ideas. 

We started to inspect and adapt to the working process. We had innovation and planning sessions where we continuously pursued improvements. Members began giving their solutions to overcome the problems, leading to healthy interaction and collaboration. We began trusting each other, sharing ideas, and supporting each other. As a team, we all set an example for others and garnered client appreciation. Today, we are more than ten members, and we can find ourselves in the “Norming” stage. 

Modernizing QA with life-cycle automation and AI practices to address scale, speed, security and innovation in the cloud is a prerequisite for Digital Transformation.