Agile is the most discussed software development methodology , and probably most widely accepted as the way forward for modern software development. 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 universe that it's possible the definition of agile is different from company to company.
So, we wanted to shed some light on what being an Agile team really mean for us!
Mainly and most importantly, it is software development with a focus on collaboration and self-organizing, independent 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:
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 design, implementation, and testing of the feature; as well as coordinating with the business stakeholders and developers 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 demos
· Be the go-to person for the feature domain knowledge
Who: Developers or feature owners, who may also pair with a product owner
It is always better to analyze a story 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.
Who: Product owner, tester, and the developer pairs who will be working on the story
Before picking up a story for development, participants get together for a quick walk through of the story.
During this kick-off, participants discuss the acceptance criteria, whether there is any analysis remaining, and whether there are any blockers or any dependent stories.
The objective of a kickoff is to ensure that the product owner, tester, and developers are on the same page, 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.
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.
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:
1. Pair Rotation: If a story is taking a few days for completion, 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 get all insights into work done so far, and what needs to be done next.
2. 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.
Who: A team member can self-signup 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 micro service, 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 skillset of the team as a whole.
Who: The whole team
The 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 has a group call in case of remote working.
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 opinions or votes for a particular solution to go with.
Who: The whole team, managers, business stakeholders, clients
Feedback is at the core of being an Agile team.
We should make sure that feedback we give is constructive and should also take feedback constructively.
Feedback can be given while pairing, after we are done with the story or even on catch-up one-on-one's.
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 the feedback, the teammate who 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.
Does it feel like lots of meetings?
Yes, after going through this blog it might seem to you that the team will end up having lots of meetings, we will end up spending half of our days in a meeting room or on teams calls.
Most of what’s listed here should not necessarily be long meetings. Participants usually get together for a quick discussion without needing to book a meeting room or sent out an invite email. These become second nature over time as compared to being time consuming, enforced rituals!