Ideas for Successful Agile Teams

Agile is the most discussed software development methodology, and probably the most widely accepted as the way forward for modern software development teams. The reason (IMHO) anything is this much discussed and written about is that the practices haven’t been carved in stone yet, are still in the evolving phase, and are in some way even disputed. There is so much going on in the Agile transformation initiatives that it’s possible the definition of agile development is different from company to company.

So, we wanted to shed some light on what being a team with agile ideas really means for us!

Mainly and most importantly, it is software development with a focus on collaboration and self-organizing, independent, and effective teams.

Lots of things fall under the Agile Umbrella, including processes, practices, roles or even just a mindset. Here, we share a few tips and techniques that help our teams achieve this goal of being collaborative and owning the SDLC from start to finish:

1) Feature Owner:

Who: Anyone on the team, either a developer or tester can be the feature owner

A feature owner steps up when there is new functionality to implement. The feature owner is responsible for the design, implementation and testing of the feature; as well as coordinating with the business key stakeholders and executive team to make sure that the business requirements are met and executed in the most efficient way possible.

The feature owner works closely with the product owner to:

• Get a clear understanding of the feature from the stakeholders
• Craft stories for the feature
• Keep track of timelines and ensure timely delivery
• Escalate blockers that impede timely delivery
• Own the feedback-iteration loop through sprint review
• Be the go-to person for the feature domain knowledge

2) Story Analysts:

Who: Developers or feature owners, who may also pair with a product owner

It is always better to perform story mapping before it gets picked up in the next Iteration Planning Meeting (IPM).

Below are the points we can consider for story analysis

• Are the acceptance criteria specified such that there is no ambiguity?
• Is there any technical debt related to the story?
• Is there a need to split the story into thinner slices?
• Does the story need a spike?

The outcome of story analysis is that the story is ready to be picked up in the next IPM.

3) Kick-Off:

Who: The product owner, tester and developer pairs who will be working on the story

Before picking up a story for development, participants get together for a quick walkthrough of the story according to the business needs.

During this kick-off, participants discuss the acceptance criteria, whether there is any analysis remaining, and whether there are any blind spots, blockers, or dependent stories.

The objective of a kickoff is to ensure that the product owner, tester and developers are on the same page, have a common goal, the story value is well understood, blockers they may face while developing the story have been identified, and a plan is in place to resolve the blockers before picking up the story.

If there are any blockers, like unclear Acceptance Criteria, dependencies on other stories, which are still in development, UI implementation questions, or others, the story won’t be picked up for development.

4) Desk-check:

Who: Product owner, tester, feature owner, and the developer pairs working on the story

Desk-check comes after development is done. The developer showcases the story to all participants.

During Desk-check participants check if the story is completed and all Acceptance Criteria are implemented.

If any bugs are found, or if there is feedback for improvements, development on the story won’t be considered done, and the developer pairs will continue working on the story.

This is the primary testing of the story to get early feedback even before it is considered as development done, allowing us to optimize time and efforts during testing.

5) Knowledge Transfer:

Who: Knowledge bearers and knowledge seekers

For self-driven teams, we should always ensure that knowledge is never limited to a few people in the team, there should be a gradual knowledge transfer either during pairing sessions or by signing up for stories.

It should never be the case that only the feature owner has all domain knowledge about a given feature and if they are unavailable, the rest of the team is at a loss on how to proceed.

The responsibility of a team member here is two-fold - to transfer gained knowledge within the team and to ensure acquiring knowledge of any technology/feature, which they don’t know much about.

To avoid knowledge hoarding, the following things can be done:

• Pair Rotation: If a story is taking a few days to complete, one of the developers from the pair can roll out, say after 2 days, and the new developer can join in. The developer already working on the story will ensure that the new folk joining gets all insights into work done so far, and what needs to be done next.

• Sessions: Conduct sessions within the team showcasing the architectural implementation/discussion, new feature integration, and its design decision, sharing domain knowledge of the feature, what are the requirements from the product owner, etc.

6) GO-TO Person:

Who: A team member can self-sign up for being a GOTO person for any particular technology, epic or feature.

A GOTO person is kind of an expert. Team members can go to them to resolve any issues or to get their advice on a problem.

For example, while introducing a new technology like Kotlin or while creating a new microservice, we might have a teammate with Kotlin experience, and he/she can be the GO-TO person for Kotlin.

Having a GOTO person saves a lot of our time as we can seek help from our in-team expert, this also helps in knowledge sharing and growing the skill set of the team as a whole, thus helping us in higher-value deliveries.

7) Huddles:

Who: The whole team

The engineering team should be available to get together for a quick discussion when any team member shouts out for a huddle. Huddles should not be long meetings and should not need booking a meeting room, instead, the team gathers together in a circle or just online meetings in case of a remote team.

While implementing a story we might face some issues or have confusion about which approach to go with, each having its own pros and cons.

In such cases, we may call for a quick huddle where the team discusses the issue, shares their agile values, or votes for a particular solution to go with.

Feedback:

Who: The whole team, managers, business stakeholders, clients

Feedback is one of the core principles of an Agile team.

We should make sure that the feedback we give is constructive and should also take feedback constructively.

Feedback can be given while pairing after we are done with the story, daily stand-ups, or even on catch-up one-on-one.

Group Feedback:

Who: The whole team

We can have group feedback where all team members write feedback for a particular team member. Also, when the team discusses effective retrospectives, the teammate getting feedback may not be present in the discussion and will join in once the team is ready with their feedback.

When he/she receives the feedback it is what the entire team has agreed to, and is from the team rather than a particular individual.

Each one on the team should get group feedback in this manner to build high-performing agile teams.

Does it feel like lots of meetings?

Yes, after going through this blog it might seem to you that the product teams will end up having lots of daily meetings, we will end up spending half of our days in a meeting room or on teams calls, and a wall full of sticky notes…

Most of what’s listed here should not be necessarily long meetings. Participants usually get together for a quick discussion without needing to book a meeting room or send out an invitation email. These become second nature over time as compared to being time-consuming, enforced rituals!