Building an Agile Team from Scratch
Embarking on a new project is both exciting and scary. Generating new ideas, exploring new technology and working with new people, while exhilarating, can be fraught with uncertainty. This article serves to help a ScrumMaster or Team Lead to build an effective Agile team from scratch when embarking a new project, which is essential for the project to succeed. The article will cover 3 main areas to setup an effective Agile team for project success: People, Process and Tools.
People
Agile Team
How? An Agile team will comprise of Product Owner and Development Team. The Product Owner is responsible for the business direction of the product and, who will create and prioritise of the user stories. Development Team is responsible for the technical direction of the product and, who will deliver the user stories.
Why? Business and technical responsibility are intentionally separated between Product Owner and Development Team, so that Product Owner focuses on building the right thing while Development Team focuses on building the thing right. When conflicts arises, Product Owner and Development Team will have to negotiate to achieve win-win for both business and technical domains, to avoid one side being fully compromised over the other.
Development Team Size
How? A single Development Team should be 7 to 8 members in size. If team size grows beyond 8, it should be split into two smaller teams.
Why? The team size should not be more than 8 as too many team members will result in significant communication overhead or even “Bystander Effect”.
Development Team Structure
How? Development Team should be self-managing and cross-functional, with the ability to deliver user stories on its own with the following roles as a guide.
- 1 ScrumMaster
- 1 Tech Lead
- 1 UI/UX Designer
- 3 Developers
- 1 Quality Engineer
- 1 DevOps Engineer
However, the ratio of the roles will depends on the needs of the product.
Why? Ideally each team member should be experienced and multi-disciplinary, but in reality most new teams start off with team members with a mixture of experience and/or a single specialisation. To overcome this, a new team needs to be made up of cross-functional specialisations as a start, so that the team can deliver user stories on its own as a team. Over time, team members can also learn from each other through pair programming to become multi-disciplinary agile specialists.
Product Owner’s Co-location
How? Product Owner must be co-located with Development Team.
Why? Development Team can clarify with Product Owner instantly and Product Owner can review delivered user stories immediately to provide feedback. This results in effective communication between Product Owner and Development Team, enabling the product to be delivered quickly.
Product Owner’s Decisiveness
How? Product Owner must be able to make decisions and respond fast. If the Product Owner is not able be co-located with Development Team, but a Proxy Product Owner can be located with the team instead, however Proxy Product Owner must be empowered to make decision.
Why? The real cause of failed product delivery is not bad decisions but slow or no decisions. That’s why it’s crucial for a Product Owner or Proxy Product Owner to make decisions and respond fast, to ensure development isn’t impeded.
Process
SCRUM
How? Team that is new to Agile should begin with SCRUM.
Why? SCRUM is one of the most structured Agile methodology. Even though SCRUM has more meetings, called SCRUM ceremonies, this structure helps teams learn and understand the benefits of Agile. In SCRUM, the product is delivered in iterations of 2 to 4 weeks called Sprints, where there are 5 Scrum Ceremonies as follows:
In SCRUM, the product is delivered in iterations of 2 to 4 weeks called Sprint, where there are 5 Scrum Ceremonies as follow:
- Sprint Planning
- Product Backlog Refinement (PBR)
- Sprint Review
- Sprint Retrospective
- Daily Standup
Sprint Planning
Sprint Planning occurs at the start of the Sprint and has two parts, Part 1 and Part 2.
Sprint Planning Part 1
Who? Product Owner and Development Team
Duration? 2 hours for a 2-week Sprint
How? Product Owner will move user stories from Product Backlog to Sprint Backlog (Scrum board).
Why? Sprint Planning is used to determine which user stories from the Product Backlog will be developed in the Sprint. This is then known as the Sprint Backlog. When the Sprint Backlog is decided, it is then frozen or locked for the Sprint. Only the Product Backlog can be changed or updated. This allows the Development Team to focus on the Sprint Backlog and work without any distractions or disruptions, while allowing the Product Owner the flexibility to adapt the Product Backlog to changing business requirements.
Sprint Planning Part 2
Who? Development Team
Duration? 2 hours for a 2-week Sprint
How? Development Team will break down user stories into tasks on the Scrum board. and then each Developer will take up one task to kickoff the Sprint.
Why? Development Team uses Sprint Planning Part 2 to break down the user stories into tasks and discuss the ‘plan of attack’ for delivering the user stories for the Sprint. Developers will know which tasks they can develop and what tasks they will need help in. Tech Lead can also identify important user stories for pair programming to train up Developers to be cross-functional individuals.
Product Backlog Refinement (PBR)
Who? Product Owner and Tech Lead
Duration? 4 hours for a 2-week Sprint, and decreasing as the project matures
How? Product Backlog Refinement occurs in the middle of the Sprint and can be arranged as many times as required on demand. Tech Lead will clarify the user stories of the next 1 or 2 Sprints with Product Owner and then estimate the user stories with Scrum Planning Poker.
Why? The purpose of Product Backlog Refinement is to plan ahead but not too much, by refining the user stories to be ready for development in the coming Sprint. Only Tech Lead is involved as the clarification and estimation usually involves discussion of higher level application design and implementation strategies, and not all Developers are involved as it may take up too much development time. The thought process of user stories estimation helps both Product Owner and Development Team to understand the user stories across the domains and setup a common understanding among them.
Sprint Review
Who? Product Owner and Developers who delivered the features
Duration? 2 hours for a 2-week Sprint.
How? Sprint Review occurs on the last day of the Sprint. Developers will demo the accepted features to the end users to collect feedback. The feedback will become new user stories in Product Backlog to be prioritised accordingly.
Why? Sprint Review is the ceremony where user give their feedback on the product incremental, to improve and adapt the product continuously. However, the feedback will be considered as additional scope to prevent scope creep and allow Product Owner to prioritise what is really important.
Sprint Retrospective
Who? Development Team
How? Sprint Retrospective occurs after Sprint Review. The Development Team will discuss on how to improve the process for the next Sprint using retrospective techniques such as Glad, Sad, Mad.
Duration? 1.5 hours for a 2-week sprint.
Why? To build a high performing team, team members need to understand each other well to work together effectively. Sprint Retrospective allows team members to discuss such issues regularly to improve the development process continuously.
Daily standup
Who? Development Team
Duration? 15 minutes
How? Daily standup occurs daily, usually in the morning. Developers will update each other of their progress and/or seek any help.
Why? Daily standup provides the shortest feedback loop through the development process. Developers use Daily Standup to sound off any blocks or bugs early, so that they can resolve the issues quickly, in order to ensure good development flow.
Tools
Working Agreement
How? Before the project commerces, Development Team should setup a working agreement to set the ground rules to be observed by everyone. Development Team will continuously update working agreement during Sprint Retrospective.
Why? Working agreement sets up a mutual understanding and expectation of everyone in Development Team, so that everyone can work effectively with each other. In long term, as the working agreement is updated continuously, the regular discussion will bring about greater trust within the team.
Definition of Done (DoD)
How? Before the project commences, the Dev Team should agree on the Definition of Done to define what are the criteria for an user story to be considered done and ready for acceptance by Product Owner. Development Team will continuously update Definition of Done as needed as the product grows in complexity.
Why? Definition of Done set ups a common understanding of the expectations for a user story, so that Development team will work towards the criteria and Product Owner will know what to expect for the done user stories.
SCRUM Board
How? SCRUM Board, which is also Sprint Backlog, contains all the tasks to be developed for the Sprint. Developers will take tasks from the Scrum Board to develop and update the status accordingly.
Why? SCRUM Board serves as the common board for Development team to see, so as to make sure there is only a single source of truth. SCRUM Board is also an information radiator, whereby Development Team can easily know what is the progress of development at any one point of time, which creates transparency across the team.
Conclusion
With these 3 areas of People, Process and Tools in place, the new team will be in good shape to grow into a high performing team with continuous learning and improvement. The quality of a product is largely due to the quality of team that delivers it, so ensuring a high performing team will ensure a high quality product.
At GDS, this is how we ensure our Agile teams are high performers, so they can deliver better quality digital services to citizens. If you’re interested in what we do, we’re always hiring! Just drop me a note to find out more.
