Is it a god-send or a cult? The Agile project management methodology is certainly divisive. But when utilised only as a general framework for software delivery; empowering teams to shape the processes, we show how it can be used to increase both the productivity and engagement of team members.
Going Agile: A Practical Guide
Nothing divides software developers like the Agile Methodology, a simple Google search will throw up articles on both sides of the argument.
But in our experience, when the Agile approach to software development is used to empower individuals and create autonomous and result-oriented teams, it can help to unmask the intrinsic motivations we all have to develop quality products that make us proud.
In this practical guide, we will take a look through our view on how to best implement Agile teams that work best and balance the interests of engineers, product owners, UI/UX, QAs and all other product stakeholders.
In this article, we will be restricting our focus to the Scrum approach, as this is the format most used in our teams. Some basic understanding of Scrum terms and processes is also assumed.
What Agile is Not
- Agile is not a cult - There is no one-size-fits-all methodology to follow, the structures and processes should be crafted over time to suit the team
- Agile != Quality - Using Agile does not magically produce quality software. It can help to empower teams and build shared knowledge, but it cannot transform the code quality
- Agile is not for micromanagement - Daily standups and other such meetings should not be used for constant evaluation and monitoring
- Agile is not an excuse to push unfinished product plans to developers - The approach needs to work hand-in-hand with product roadmap planning and long-term UI/UX design
An Agile Team
An Agile team is expected for the end-to-end delivery of a product, and so must be self-sufficient. Thus a standard team will contain one or more of the following team members:
- Product Manager — leads with product planning
- Team Lead — coordinates and oversees the delivery of product features
- UI/UX — leads the vision on crafting the user experience
- Frontend, Backend, Mobile and DevOps as needed
While individuals and interactions are valued over processes, we do believe that certain processes facilitate and streamline the communication between individuals and increase accountability, and so we see them as important to ensuring fast iterations and adaptable teams.
In the Backlog Refinement meeting, a Product Manager sits down with the Team Lead to prioritize user stories and tasks for the team.
- Write stories from the user’s perspective (whether it is the end user or internal user) and refine
- Add acceptance criteria to define what is meant by “Done” for the task.
- Prioritize stories and tasks
- Get ahead of the team (ideally 1–3 sprints ahead)
- Estimate delivery times
- Finalize on tasks to be delivered in the sprint
In the Sprint Planning meetings, the team sits down to review and decide the commitments they will make for the upcoming sprint, carefully evaluating the complexity of each task and splitting the workload across team members.
- Use story points over man days — developers are notoriously bad at estimating time to complete a story
- Measure team velocity
- Question stories and tasks and break down further if necessary
- Breakdown tasks by modules, share across team and integrate often — leads to knowledge sharing across the team
- Reduce tasks if story points exceeds team velocity — teams should decide their commitment based on team velocity
- Include Product Manager if not necessary — the Team Lead should have sufficient knowledge following the Backlog Refinement sessions
During the sprint, we focus on delivery and try to make the best use of workflows within our project management platform of choice, to make transparent our progress.
- Use the best workflow to integrate your team
- Make progress transparent
- Generate sprint burn down charts
- Introduce (too) many changes
- Introduce context switching
During standups, we share the progress happening during the sprint and mention if there are any blocking issues impeding progress.
- Talk about what you did yesterday, what you will do today and whether there are any blockers
- Include Product Managers
We include a sprint presentation open to everyone, at the end of sprints, to showcase the progress made on each product. This is generally an informal affair to present what the team has accomplished, but it also raises accountability and keep us on track to deliver user-impacting outputs.
- Present what the team has accomplished
- Discuss user experience of the deliverable
- Rotate presenters within team
- Make it technical
At the end of each sprint, we allocate time to gather feedback from team members for discussing positives and potential improvements. These meetings allow us to craft the processes to suit the needs of the team. For example, one team may switch to evening standup meetings to synchronize across team members.
- Praise team members for their work and effort
- Discuss improvements without mentioning names
- Encourage participation
- Blame others
Using this structure and processes within our teams helps us to get out of our own way, limit the impedances that cause delays in our projects and keeps us focussed on delivering software as we measure ourselves by it. We also find that the autonomy and empowering of teams through these measures allow us to boost engagement within our teams as well.