Running an Agile Team
How I have experimented with cadence and processes of software development
Last updated
How I have experimented with cadence and processes of software development
Last updated
There are many methodologies that teams can adopt to build out a product. There is the more traditional , however, are the most popular approaches taken in modern tech companies. Some popular Agile methodologies are:
I will mainly go into detail about Scrum as that is the methodology I have had experience with in the past 4 years.
In general, teams will choose Agile methodologies because, as the name suggests, it allows for teams to pivot and respond to rapidly changing market requirements and customer feedback.
There are certain tenants in the Agile manifesto which, when relating to Scrum and working in product teams, I feel are too rigid. However, when you take the spirit of Agile and Scrum to your team and don't follow the manifesto specifically, it allows the team to be more flexible.
The Agile manifesto outlines four values:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
I have played the role of both Product Owner/Manager and Scrum Master and will share my thoughts on both roles below.
The product manager is the voice of the customer/user. They will do research into customer needs and feedback in order to come up with a backlog of items that should be completed to add onto the product. The backlog can consist of new features, existing bugs, administrative tasks or improvements to existing features.
The product manager will also assign priorities to these tasks so that the team can decide what to tackle during their sprints. As the team will have a finite amount of capacity to complete tasks in a given sprint, the prioritisation framework allows for a more structured approach to deciding what to do and when.
The scrum master will act as the enforcer to various scrum routines. They ensure that whatever needs to get done during the various meetings, like the sprint planning and daily stand-ups are done. They aren't necessarily project managers but they will ensure that the scrum team remains accountable for their commitments and tracks progress.
The scrum master can also assist in clearing any blockers for the team. While they might not be able to clear it themselves, they can point the team members in the direction of where they can get help.
These are the people who the backlog items are assigned to for them to complete during the sprint. Usually, they are Software Engineers and Designers.
Engineers will usually be assigned tasks to implement new features or tackle bugs
Designers will usually be assigned tasks to do up designs for new features
There are rough guidelines around how many people should be a part of a scrum team before it becomes too onerous to stick to scrum methodologies. The recommended scrum team size is 7, inclusive of scrum master and PM.
In scrum, there are several key meetings that happen in the development cycle.
Typical Duration: 5-15 mins
Each member of the team gives a short round up consisting of the following questions:
What did I do yesterday?
What do I plan to do today?
Am I being blocked by anything?
Anything outside of these questions, like questions for other team members, should be tabled till after the stand up
This allows for the team to give visibility to the scrum master so that they can help clear any blockers or correct the course if there are any impending blockers.
Typical Duration: 1 hour
Going through the whole backlog of items in order of priority
Reprioritising tickets - either higher or lower
Clarifying details in tickets
Removing unnecessary items that don't need to be completed
Breaking down epics/large features into smaller chunks of work
Perform effort estimations of higher priority items
Typical Duration: 1 hour
Taking the highest priority tickets and assigning them into the next development sprint
Based on the team's capacity, assign the tickets to team members to complete during the sprint
Last minute clarification questions + reprioritisation
Refine effort estimations for items in the sprint
There is usually a "commitment" to a total number of tasks completed in the sprint after the planning. After the commitment, new tasks shouldn't be added into the sprint unless some existing tasks are removed. It should be a 1-in-1-out situation.
Typical Duration: 1 hour
Demo any working features/software/designs that were completed during the sprint
Review the uncompleted tasks and try to understand why they weren't completed:
Unclear tickets/design doc
New requirements being added mid sprint
Inaccurate effort estimation
Usually, the each team member answers the following questions:
What went well?
What didn't go so well?
What can we improve on?
How long each sprint cycle takes depends on the team urgency, culture and nature of the product. I have worked with 3 styles of cadence:
2 week continuous sprints
This is the typical standard for the industry
A good balance of delivery and time to plan and execute
1 week continuous sprints
This felt too cramped as half the week was spent in the usual scrum meetings
2 week sprints with 1 week down time in between
I found this helpful for my team as they were able to take the time to thoughtfully plan out designs and solutions
The rate at which things was delivered slowed down but it helped with team morale
I go into more detail on and a I previously used
