6 Considerations to Ensure Agile Team Value
Unique challenges exist when integrating external resources in agile implementations.
Rather than confront how to fix challenges in future projects during an after action review, the key question is, “How do we overcome the potential problems from the onset?”
Effectiveness
Productivity and effectiveness are key to project success. In thinking about how to proactively remove blockers for the team, consider the technical environment, team expertise and escalation pathways.
Environment
Three key questions related to environment are:
Is your build environment working correctly?
Is the integrated team able to work effectively?
Are there environment parameters that can be approved?
A simple example of a common environment challenge involves integration testing. When validating the output of integrated team members’ specific code, work station integration and code migration between environments directly impacts efficiency in development. The velocity of the team is impacted when inconsistencies exist between individual or team members’ equipment or software, or when a common infrastructure is not utilized for submission of completed work.
Expertise
Three key questions related to expertise are:
What are the responsibilities of each team member?
Who on the team is the depth knowledge player for project domain, business requirement(s) and/or technology direction?
Where in the organization do you turn to find quick answers - outside or alongside of the project?
Fostering project leadership that clearly provides frictionless and unencumbered communication paths to expertise leads to success. Knowing with whom and where the expertise lies when integrating internal and external team members is evidenced by the productivity of the team. Ensuring access and a structure that does not become bogged down in hierarchy while maintaining order drives results.
Escalation
Three key questions related to escalation are:
What are the inter-team dependencies or dependencies on the IT organization, business and others?
How do I unblock the consultant and internal team communication to ensure there are no silos?
How do blockers and questions get prioritized and who is responsible for alleviating friction?
As important as having escalation paths in place is fostering an “ask early and often” culture in the team. To create communications and the means of resolving problems during a project, it is important to highlight when to raise a hand and where to go if the problem is not resolved over a specific timeframe.
Integration of the Agile Team
Adjacent Skill Sets
Consultants are often brought into a team because they contribute speed or something different or unique. In the world of agile/scrum, it is essential that the consultant is not a unique resource too much of the time. Otherwise a sprint becomes a mini-waterfall, and the consultants become a team of individuals.
One way to overcome this is to ensure the consultant is working on tasks related to other team members. Doing spikes for a prototype or creating groupings of mixed internal and external resources facilitates integrated understanding and learning. This will also help in avoiding ongoing reliance on the consultant team as a gate keeper for a particular task or sprint cycle.
The consultant should also proactively address the issue created by becoming an island of one by spending time with internal team members and informally having conversations about what he or she has delivered. Walking through previous projects to discuss strengths and weaknesses of the architectural or design direction, or conducting lunch and learns can help to surface skills, architectural biases, and viewpoints. Participating in code reviews and coming up to speed on the code base before GIT code reviews also helps instill collaboration and integrates the full teams’ understanding and capacities.
Acceptance Criteria
Acceptance criteria is a core part of agile, but is often times a stumbling block. There are no written requirements to determine that work is done right as documentation is limited and the product owner usually interprets results. For these reasons, it is imperative that both internal team members and external consultants understand how to arrive at acceptance and effectively communicate to achieve metrics.
Key questions around acceptance may include:
Is the time and work spent on estimates worthwhile given unknowns, complexity and time available to think about the level of effort?
What is the estimation variance (over/underestimated)?
How closely is estimation tied to success criteria?
Should creation of acceptance criteria be part of the sprint effort cycle (reasoning/designing)
Accountability
Internal agile teams typically measure velocity and use this over a series of sprints to understand how to pivot to achieve more value. By contrast, consultants may be trusted to take the time to think about problems and bring an outside perspective. When those two objectives do not tally, it is important not to undermine the metrics of the rest of the team.
Ensuring that a common set of expectations is understood across the integrated team is paramount to the agile team’s success. Through assignment of responsibilities and shared understanding of roles and expectations, an effective and productive team can be built.
Key Take Aways
Agile team communication is a two-way street. As an internal team member or an external consultant, agile does not mean there is a removal of accountability. Being accountable to your specific role and responsibility while understanding the dependence and interplay with others is each team members’ responsibility.
Agile metrics matter. Agile can be undermined as team members move around. As core team and internal team members collaborate in the agile engagement to achieve a greater result, no one should be permitted to adopt the mentality that something does not involve her or him. Velocity is determined by the collective achievement of defined goals, metrics and measures.
Guiding the conversation can be as valuable as facilitating it. Where you fit within the team (product owner, EN lead, devops, designer, front and back end coders, business lead, team or business unit lead) may impact the actual hands on contribution you make to building a solution. At the same time, the team member who asks the right questions to draw out the right information or assignments can be as impactful as the person who creates flows and tasks, processes and procedures, or code.