Context is king when it comes to coaching a team.
All teams are at a different place in their Agile journey. Each team naturally will evolve team behaviors that are tailored to its specific context. An Agile coach needs to recognize where teams are in their journey and provide coaching that is customized to each unique situation. Standard templates or approaches applied to every team will not suffice. This blog series will focus on techniques to adjust coaching for a team’s distinct context.
The first post unpacks the word, “context,” by defining the 3 dimensions of growth for a team. Then, subsequent posts dive into each of the three growth dimensions one by one. For each growth dimension, the future posts will provide a real team scenario, the coaching approach that was used, and descriptions of different coaching strategies for different contexts within the dimension.
The Journey of a Team
There are three dimensions of growth an Agile team traverses—Social, Product, and Technology—as shown in Figure A. Based on a team’s place in their journey across the different dimensions of growth, they will have different needs and require customized coaching to their context.
Social Growth
The Social growth dimension is unique to each team. All teams mature along the social spectrum over their life. Tuckman’s model of Forming, Storming, Norming, and Performing1 is a good framework for discussing a team’s social journey.
Contrary to popular belief, long-lived teams do not plateau; rather, they continue to evolve and continuously improve their social growth dimension2.
The different aspects of team social development are outlined below.
Ways of Working
A team will evolve its processes, tools, and behaviors over time as its context evolves and new challenges are experienced. Some teams will mix Kanban and Scrum while other teams will strive for pure Scrum or Kanban. Some teams might have a customized Agile-based framework.
In some cases, teams will relative size their features while others will opt for small, uniformly sized features that do not require a size. In Scrum, some teams may opt for Sprint planning solely based on the prior Sprint’s velocity while other teams create detailed tasks to derive their sprint backlog and forecast. The tools and techniques will differ, and this is normal.
An Agile team will routinely reflect and improve its way of working over time through frequent retrospectives and improvement experiments. This retrospective inspect and adapt cycle will naturally develop a way of working that is unique to each team’s context. It is expected that because of these divergent customizations, each team will have different ways of working rather than standardized ways of working.
Team Member Capabilities
Each team member brings his or her own unique set of capabilities and experiences to the team. This naturally creates a way of working that is unique to each team with team members relying on each other to bring their capabilities to bear to complete the work.
The longer a team works together and pairs, swarms, or mobs on the work, cross pollination of skills and capabilities will naturally emerge. As the team members learn from each other, their way of working will continue to evolve. This results in T-Shaped team members with deep specialties and broad capabilities. Each team will develop its own unique skill mix that works for its context.
Interpersonal Relationships
Intra-team relationships form and mature the longer the team stays together. The team learns how to optimize within its unique composition of personalities and unique team member attributes. Relationships between team members evolve over time and shift as the team takes on different challenges and the individual circumstances of team members evolve.
Community Circle
Each team’s community circle (Figure B) is unique. A team’s stakeholders, users, and peer teams are unique.
The relationships in the community within which a team works will evolve over time. The longer it stays together, a team will evolve its interpersonal relationships with its stakeholders, users, and peer teams. The team may even outlive its product and gain new stakeholders, users, and peer teams.
Team Norms
Team norms are influenced by team member backgrounds and company culture. However, each team utimatly develops team norms that are unique to its team composition.
Some teams will be remote and some will be co-located. A team may like collaborating in the afternoon while other teams collaborate best in the morning. One team may choose to have strict rules for meetings while another desires informal meeting guidelines.
These norms rarely remain static and instead grow as the team evolves.
Product Growth
No two products are the same. As such, teams require customized approaches for these differences in their product.
Some attributes that make each product unique are described below.
Different Business Domains
Each team has a different business domain for their product. Each business domain is unique. To deal with the uniqueness of each domain, teams will develop approaches, norms, and knowledge that is unique to each domain context.
For instance, some domains are especially sensitive to forecasted delivery dates while other domains are less concerned with the date and focus on differentiation in the market. Teams may need to focus on continuous, transparent forecasting in the former and rapid build, measure, and learn loops in the latter.
Each domain also comes with its own domain specific knowledge and rules, which the team will gain over time as they gain a fundamental understanding of user and business needs and associated worflows.
Different Users
Every team has a unique set of users and user types for its product. Each user has different needs. Solutions for one user type will often not work for another user type. Similar user types in different domains will have different needs and will require context sensitive solutions.
In essence, each team will need to have empathy for its own set of users and will operate and deliver solutions unique to its user base. This will require a team to operate differently in every case.
Different Stakeholders with Unique Drivers
Any given set of stakeholders for a product will have unique needs and business drivers. Some stakeholders want heavy involvement in setting project direction while others rely heavily on the team to innovate. In the former scenario, teams will opt to engage closely throughout delivery with stakeholders, but in the latter scenario, stakeholders may have less frequent engagement touch points with the team.
Teams require custom approaches to effectively engage with their unique set of stakeholders. Expecting teams to treating all stakeholders in the same manner will not work.
Effort/Cost and Duration
The effort/cost and duration to build a a given feature, even if similar, will differ across product domains. This is due to the unique users, stakeholders, team members, scope, solution technologies for every product.
As such, expecting a similar feature to be delivered for the same effort and in the same timeframe for different products should be avoided. Each team will learn over time how to estimate effort and duration based on its own unique context and abilities.
Acceptable Quality Levels
Some products require high levels of quality while others just need to have basic quality. For instance, one product may require high levels of tolerance in calculations for safety reasons while another just needs to be close enough to provide guidance.
Further, one team may need to compete with a high-quality product favored in the market. Other teams might be working on a product non-existent today, and even a rudimentary version will suffice.
Teams adjust their definition of done and learning velocity appropriately based on quality expectations in the product domain.
Different Product Lifecycle States
Products can be in different lifecycle stages. Each lifecycle state requires a customized approach. Kent Beck’s recent work on 3X—Explore, Expand, and Extract—explains these stages nicely.
When a product is early in its life (Explore), rapid experimentation is key to find the right features that resonate with users.
Once the right path emerges (Expand), user demand takes off and the team has to remove constraints rapidly to keep up with the demand.
When the product user base is established and has stabilized (Extract), a more thoughtful approach is required to introduce new features so as not to disrupt the success of the stable user base and to continue extracting value.
Each team will operate differently depending on the lifecycle stage of its product.
Technology Growth
Technology is changing and evolving all the time. As such, each team will have a unique collection of skill sets that will evolve indefinitely. This learning path alone ensures that every team has its own unique technology learning challenges, which will require a custom path.
Some of the technology variables on a team are described below.
New Tools & Frameworks
New tools and frameworks for developing software are constantly emerging, including but not limited to the following:
- Integrated development environments
- Real time compilers
- Automated testing toolkits
- Code and component libraries
- Open source frameworks
- Version control tools
- Cloud development languages and frameworks
- Continuous integration and continuous deployment tools
- Collaboration tools, such as those for knowledge sharing (wikis), instant messaging, document storage, and real-time remote meetings and video conferencing
- Product backlog management tools such as Jira and Rally
Once a team learns and masters one tools, the next new tool becomes available. Team learning is continuous along this spectrum.
New Languages
New coding languages emerge as time progresses. Procedural languages emerged with BASIC, FORTRAN, COBOL, and C. Then, object oriented languages emerged, such as Smalltalk, C++, and Java. Today, modern languages are evolving, such as Ruby, Python, and Swift.
While all languages follow baseline programming constructs, each comes with its own syntax and rules that teams must learn.
Teams will learn and master one language, but they will soon need to learn and master another.
New Infrastructure
The days of on premises data centers are nearing an end. The movement to the cloud is inevitable. If a team’s company has not yet moved to cloud computing off premises, it will likely do so eventually.
With movement to the cloud comes new technologies to learn and a new set of skills for teams. Furthermore, this will not be the last time teams will need to learn new infrastructure skills.
New Patterns
New patterns are constantly being developed for modern Agile software development. For example, Martin Fowler just published his second edition of an evolving set of Refactoring patterns, giving teams an updated, modern view on his popular first edition in 2000.
As an example of emerging patterns, with the movement to the cloud, new patterns have emerged to move from monolithic centralized services to cloud-based micro-services.
When it comes to software development patterns, a new one is right around the corner. A software team is constantly faced with learning and integrating these new patterns.
Conclusion
Every Agile team is in a different place in their developmental journey. Each team’s maturation along the dimensions of Social, Product, Technical growth is unique. As such, all teams require a customized Agile coaching approach, tailored to their place in their journey.
Stay tuned for the next post on coaching patterns for teams in different stages of their Social journey.
Other Posts in the Series
- Customizing Agile Coaching to a Team’s Social Context – New Teams
- Customizing Agile Coaching to a Team’s Product Context – New Products
- Customizing Agile Coaching to a Team’s Technology Context – New Technology
Related Posts
References
- Developmental Sequence in Small Groups, Psychological Bulletin 63, B W Tuckman (1965)
- The Six Common Misperceptions About Teamwork, Robert J. Hackman, June 7, 2011
Todd Lankford unlocks Lean Leverage in organizations to cultivate powerful, engaged product teams who maximize outcomes and impact.
His articles share his experiences and learnings along the way. Join the mailing list to get them in your inbox.