Going Agile: A Practical Guide

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
• QAs
• Frontend, Backend, Mobile and DevOps as needed

Agile Processes

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.

Backlog Refinement

In the Backlog Refinement meeting, a Product Manager sits down with the Team Lead to prioritize user stories and tasks for the team.

DO:

• 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)

DONT:

• Estimate delivery times
• Finalize on tasks to be delivered in the sprint

Sprint Planning

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.

DO:

• 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
  

DONT:

• ​Include Product Manager if not necessary — the Team Lead should have sufficient knowledge following the Backlog Refinement sessions

The Sprint

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.

DO:

• Use the best workflow to integrate your team
• Make progress transparent
• Generate sprint burn down charts

DONT:

• Introduce (too) many changes
• Introduce context switching
  
  

Standup

During standups, we share the progress happening during the sprint and mention if there are any blocking issues impeding progress.

DO:

• ​Talk about what you did yesterday, what you will do today and whether there are any blockers

DONT:

• Include Product Managers
  

Sprint Presentation

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.

DO:

• Present what the team has accomplished
• Discuss user experience of the deliverable
• Rotate presenters within team
  

DONT:

• Make it technical

Retrospectives

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.