by Rob

Swarm. An agile approach

Swarming is an Agile practice where the entire team focuses on a single task or a small set of tasks to get them done quickly. Instead of each person working independently on their own tasks, everyone “swarms” around a priority item, helping to complete it as efficiently as possible.

The main idea is to reduce work-in-progress (WIP) and improve flow. Swarming allows the team to collaborate closely, share knowledge, and quickly remove any obstacles. It’s particularly useful when a task is critical, complex, or blocking other work.

Scrum features, like autonomy, transparency are part of swarm

  1. utonomy: In a swarm, team members self-organize and decide how best to tackle the task together. They bring their unique skills to the table, deciding as a group how to contribute and how to move forward. This autonomy lets the team leverage each member’s strengths while adapting on the fly.
  2. Transparency: Since everyone is focused on the same task, swarming naturally encourages open communication and visibility. Team members constantly share updates, identify obstacles, and make progress visible to the entire group. This level of transparency helps ensure that the team is aligned and can quickly spot and address any challenges.

So, swarming really embodies the principles of autonomy and transparency, which makes it a great fit within Scrum’s framework!

Swarm is also about grouping people with the same expertise, is a topic which can be often read?

Swarming can sometimes involve people with the same expertise, but it often benefits from a cross-functional approach. Here’s how it works in different contexts:

  1. Same Expertise: In some cases, people with the same skill set (e.g., several developers or designers) may swarm together on a task that requires a deeper focus on a specific area. This can be helpful for resolving particularly challenging technical issues or quickly advancing a task that needs specialized knowledge.
  2. Cross-Functional Swarm: More commonly, swarming is cross-functional. The team brings together members with different skills (e.g., developers, testers, UX designers) to tackle a task collaboratively. This cross-functional approach helps address different aspects of the task, making it faster and more well-rounded.

So, while swarming can involve people with the same expertise, it’s typically more powerful when a mix of skills is involved. The cross-functional nature ensures that the team can address all parts of a task without waiting for handoffs between specialists.

Creating a team internal swarm, when a requirements (user story) is complex

Creating an internal swarm within a team for a complex requirement (or user story) can be highly effective. Here’s why:

  1. Deep Collaboration: For complex stories, swarming allows team members to work closely together, sharing insights and problem-solving on the spot. This collaborative effort helps break down the complexity and ensures that everyone has a clear understanding of the requirement.
  2. Faster Problem-Solving: Complex stories often come with unexpected challenges. A team swarm brings together different perspectives and expertise, so issues are identified and resolved more quickly than if only one person were tackling them.
  3. Shared Knowledge: When the whole team is involved in a complex story, knowledge is shared across the team, reducing dependencies on individual members. This helps the team become more resilient and flexible, as multiple members gain insights into the complex area.
  4. Higher Quality: The team’s collective expertise means that potential quality issues can be identified early. For example, testers can provide immediate feedback during development, and designers can ensure the user experience is considered from the start.
  5. Improved Flow: By swarming on one complex story, the team can often get it “done” faster, allowing them to move on to other tasks more quickly. This reduces the impact on the overall flow and helps maintain momentum.

So, for complex requirements, internal swarming can really amplify the team’s strengths and lead to better outcomes. It’s a great example of how flexibility and collaboration can enhance agility.

This means, that during a sprint planning, this particular feature/task should be handled differently

For a complex feature or task that may benefit from swarming, it’s helpful to give it special attention during Sprint Planning. Here’s how you might handle it differently:

  1. Highlight Complexity: First, make sure the team recognizes the complexity and understands why this particular task might require a different approach. Discuss any uncertainties or potential challenges, so the team can prepare.
  2. Plan for Swarming: Agree as a team that you’ll use a swarming approach. This could mean dedicating several team members to work on the task together from the start, rather than assigning it to one person. Be clear about which skills will be needed and who will join the swarm.
  3. Define Subtasks: For complex tasks, it’s often helpful to break down the user story into smaller subtasks. These can include design, coding, testing, and any other activities required. This breakdown will help the team coordinate efforts during the swarm, even if they’re working on different aspects simultaneously.
  4. Timebox or Prioritize the Swarm: Since swarming can be resource-intensive, you might decide to timebox the swarm effort or make it a priority focus for the beginning of the sprint. This ensures that the team doesn’t spend too much time on one task and can move on to other stories once the complexity has been managed.
  5. Regular Check-Ins: Plan for daily or even more frequent check-ins on the swarming task. This will help the team stay aligned and adjust as needed, especially if new challenges emerge.
  6. Adjust Other Workload: Since swarming involves multiple team members on one task, you may need to adjust the sprint workload. It’s a good idea to leave a bit of buffer in case the complex task requires more time than expected.

By planning for a swarm approach during Sprint Planning, you set the team up to handle the task collaboratively and effectively, giving them the best chance to overcome the complexity and deliver a high-quality outcome.

It could be useful, to add a micro project as a separate branche. Which runs alongside with the regular sprint backlog

Adding a micro-project as a separate branch that runs alongside the regular Sprint Backlog can be a useful approach in certain cases, especially for complex or exploratory tasks. Here’s why and how it could be beneficial:

Why It’s Useful

  1. Focus on Complex Work: A micro-project branch allows the team to dedicate specific time and effort to a complex feature or task without impacting the progress on other sprint items. This separation helps manage the complexity while keeping the rest of the sprint moving forward.
  2. Dedicated Exploration Space: For tasks that involve a lot of research, experimentation, or prototyping, a separate branch provides a safe space for the team to explore different solutions without affecting the main codebase. This can be especially useful for tasks with high uncertainty.
  3. Reduced Disruption: By treating the complex feature as a micro-project, you minimize disruption to the regular sprint backlog. Team members can swarm on this task as needed, while others continue working on regular sprint items. This approach keeps overall progress steady.
  4. Better Risk Management: Complex features can often carry higher risks or require iterations. By having them in a separate branch, the team can focus on delivering smaller, more manageable increments, reducing the risk of blocking other sprint goals.

How to Implement It

  1. Define Scope and Goals: Clearly define the scope and objectives of the micro-project. Determine what the team aims to accomplish in the sprint, whether it’s creating a prototype, solving a specific challenge, or developing part of the feature.
  2. Allocate Resources: Decide who will work on the micro-project and when. You could assign a subset of the team to this branch, or rotate members as they complete other sprint tasks. Consider pairing cross-functional skills within this micro-project to address different aspects of the work.
  3. Use a Dedicated Branch: Set up a separate branch in your version control system specifically for this task. This branch can be merged back into the main codebase once the feature reaches a certain level of maturity or when certain milestones are met.
  4. Sync with the Sprint Backlog: Treat the micro-project as part of the sprint, but track it separately. You can include updates on it during daily stand-ups and make it part of the sprint review to discuss the outcomes and lessons learned.
  5. Regular Checkpoints: Plan for regular checkpoints or reviews to assess progress, adjust priorities, and determine if the work is on track to be merged into the main sprint backlog. This could be a short meeting or an additional discussion during the regular stand-up.

By setting up a micro-project as a separate branch, you allow for focused and dedicated effort on complex work, while also maintaining flexibility in your sprint. This approach can improve productivity and deliver a high-quality outcome for challenging tasks without disrupting the rest of the sprint backlog.

OKRs for the micro project

Creating an OKR (Objectives and Key Results) for the micro-project is an excellent idea! It provides clear direction, keeps the team aligned, and helps measure progress. Here’s how you might set it up:

1. Define the Objective

The Objective should be specific to the micro-project, reflecting the main goal or outcome you want to achieve. Think of it as a high-level statement that describes what success looks like for the project. For example:

  • Objective: “Develop a prototype to demonstrate the feasibility of the new feature.”
  • Objective: “Solve the key technical challenges related to the complex feature to prepare for full implementation.”
  • Objective: “Complete research and proof-of-concept for the [specific feature], reducing uncertainty and identifying potential risks.”

2. Set Key Results

The Key Results should be measurable outcomes that indicate progress toward the Objective. For a micro-project, these can focus on tangible deliverables or milestones that demonstrate meaningful progress. Here are some examples:

  • Key Result 1: Create a working prototype that meets 80% of the feature requirements by the end of the sprint.
  • Key Result 2: Identify and document three potential risks and corresponding solutions for the feature implementation.
  • Key Result 3: Perform tests and validate that the feature integrates smoothly with the current system architecture.
  • Key Result 4: Complete user feedback sessions and gather insights to inform the final feature design.
  • Key Result 5: Achieve a [specific metric, such as a 20% performance improvement] based on the initial experiments.

3. Align the OKR with the Sprint

Make sure the OKR for the micro-project is aligned with the broader sprint goals. While it should have its own focus, it’s helpful to ensure that the outcomes contribute to the sprint objectives. Communicate the OKR to the team during Sprint Planning, so everyone understands its purpose and priorities.

4. Review Progress Regularly

During stand-ups or checkpoints, review progress on the Key Results. Adjust as necessary if you encounter challenges, and keep the team aligned on the Objective. This keeps the micro-project on track and ensures that the team remains focused on achieving measurable outcomes.

5. Reflect in Sprint Review and Retrospective

At the end of the sprint, reflect on the OKR in the sprint review. Discuss what was achieved, any challenges faced, and what the team learned. This helps in planning future micro-projects and continuously improving the approach.

An OKR for the micro-project brings clarity and focus, ensuring that the team can measure success and learn from the experience. Plus, it’s a great way to make sure the micro-project is aligned with both the team’s and the company’s larger goals.

Add more experts to the existing team (most teams are very tight and are more than busy with the “regular” tasks)

adding more experts to the existing team can make a lot of sense, especially if the current team is already operating at full capacity with their regular tasks. Here are some reasons and considerations for bringing in additional experts:

Benefits of Adding Experts

  1. Specialized Knowledge: Complex projects often benefit from specific expertise. Bringing in experts with the right skills can help tackle challenging aspects of the task more effectively and reduce the learning curve for the existing team.
  2. Reduced Overload: If the current team is busy with ongoing responsibilities, adding extra hands can relieve some of the pressure. This way, they can focus on their regular work while the additional team members contribute to the complex micro-project.
  3. Faster Delivery: With more people involved, the team can potentially complete the task more quickly, especially if the new experts can work alongside the team on swarming or collaborative tasks.
  4. Knowledge Sharing: External or additional experts can bring fresh perspectives and knowledge that can be shared with the team, enriching their skills and helping them grow. This knowledge can then benefit future projects as well.

Things to Consider

  • Onboarding Time: Make sure there’s a plan for onboarding the experts quickly. Even though they bring specialized skills, they’ll still need context about the project, the team, and any technical setup.
  • Collaboration and Communication: If new experts are brought in temporarily, it’s essential to establish clear communication channels. Regular check-ins and updates ensure that everyone is aligned and aware of progress and any potential blockers.
  • Resource Availability: Check whether the team can support onboarding additional experts without impacting their regular tasks. Sometimes, a balance is needed to prevent the added complexity of managing a larger team from outweighing the benefits.
  • Team Dynamics: Consider how new members will fit into the existing team culture. Introducing people who are adaptable and open to collaboration can help maintain a positive dynamic and ensure smooth integration.

Bringing in extra expertise can be a good approach to ensure the complex project gets the attention it needs without overwhelming your core team. Just keep in mind the balance between gaining extra support and the time required to integrate new members effectively.