Agile project management is favored for its speed, but even teams that claim to have Agile values are not working that quickly.
Just ask the Financial Times, a company that spent four years redesigning their media platform in a supposedly Agile way. When they realized the new product wasn’t a resounding success, they stopped working on it and had to start again. From this failure, they learned they had favored processes over product. To fix this, they cut out unnecessary meetings, pared down workflows, and gave team members product ownership. The second time, they met all their goals on time and the product release was a success.
Established project management frameworks like Agile are too often thought of as templates to copy and paste. But if you really want to work quickly, submit deliverables on time, and stay ahead of your goals, you need to make Agile adaptable for your team.
To really understand how to build an Agile team, let’s go back to basics. Using the example of a product team working on a new search engine, we’ll outline the structure and roles of an Agile team and how each person contributes to continuous, rapid improvement throughout the project.
How an Agile team works
Agile project management was developed as an alternative to traditional project management, which is directed towards a major final deliverable. Agile instead breaks goals down into several independent products that can be developed, released, and iterated upon quickly.
The two main styles of Agile project management are Scrum and Kanban, which both utilize a board to visualize tasks in columns of to-do, in progress, and done.
There are a few defining characteristics of an Agile workflow:
- Daily standup – A daily meeting in which contributors and managers discuss what work was done yesterday, what they’re working on today, and any questions that come up.
- Sprints – Short spans in which products are planned, developed, reviewed, and released. They are projects within the projects.
- Regular reviews and retrospectives – An Agile team manages itself, but there are built-in measures to make sure work is being delivered at a consistent quality. Peer review and reviews by managers occur before tasks get completed and after the sprint is over.
With short task spans and demanding schedules, an Agile workflow requires a coordinated team. Roles have to be circumscribed enough so that people know what they ought to be doing at all times, yet flexible enough to allow people to take the initiative and exceed expectations.
A Scrum team is small, lean, and results-driven. The ideal Scrum team is 5-6 people. An Agile team working in Scrum has three roles:
- The Product Owner – Often an executive or key stakeholder, the Product Owner has a vision for the end product and a sense of how it will fit into the company’s long-term goals. This person will need to direct communication efforts, alerting the team to major developments and stepping in to course-correct and implement high-level changes as necessary.
- The Scrum Master – The Scrum Master is most akin to a project manager. They are guardians of process, givers of feedback, and mentors to junior team members. They oversee day-to-day functions, maintain the Scrum board, check in with team members, and make sure tasks are being completed on target.
- The Team Member – Team members are the makers: front- and back-end engineers, copywriters, designers, videographers, you name it. Team members have varied roles and skills but all are responsible for getting stuff done on time and in excellent quality.
In a Scrum team, independent products are created in short spans of time known as sprints. The team uses the Scrum board as a common touchpoint throughout the sprint period. In our example, the sprint lasts a month.
By setting clear expectations at the beginning for how each role contributes to the final product, you can make room for each contributor to iterate quickly, grow, and improve as the project progresses.
The Product Owner leads with vision
If the project is a ship, the Product Owner is the captain. The Product Owner directs the ship on its intended path, establishes order, and has the final word on any changes. The Product Owner contributes to continuous rapid improvement by defining the work that needs to be done, making objectives transparent, and setting the expectations for quality.
According to the original Scrum definition, the Product Owner is
responsible for maximizing the value of the product
resulting from the work of the team. In our small team example, the Product Owner is the CEO of the company.
The Product Owner defines the end goal and the tasks that it takes to get there. The Product Owner therefore creates the backlog of to-do list items and reviews deliverables before the product is delivered.
The Product Owner is passionate about the product and has the clearest idea of why it should exist – therefore, they will know instantly when it’s not right. They need to be clear communicators and create maximum transparency within the team.
In our search engine example, the CEO participates in daily standups. They ask team members to clarify what they’ve done and why they’ve done it that way. They can also call ad hoc meetings or 1:1s if necessary.
The most efficient way to create transparency is to maintain an accurate, detailed, and up-to-date Scrum board and to record all changes. The Product Owner may not “own” any individual tasks on the Scrum board but oversees all and intervenes when necessary. The Product Owner is ultimately responsible for making sure the workflow is going smoothly.
By actively participating in the Scrum, the Product Owner works towards creating the most valuable product possible and bettering the team in the process.
The Scrum Master holds the team accountable
If the Product Owner is captain of the ship, then the Scrum Master is first mate. The Scrum Master is responsible for crew welfare and making sure team members follow protocol. This role contributes to an Agile team’s success by giving the team processes, deadlines, and guidance to support their development or creative work.
Heresy.io defines the Scrum Master as
for the Scrum team. The Scrum Master is perhaps the most agile of roles since it requires so many different skills. The Scrum Master is a trusted manager who has worked on successful product teams before, is comfortable measuring progress qualitatively and quantitatively, and knows the ins and outs of Agile workflow.
The Scrum Master maintains the Scrum board on a daily and task level, conducts analysis to find out how to reduce workflow friction, calls daily standup, and demands accountability from the Product Owner and individual team members. If the Product Owner is not clear enough about expectations or a team member is not hitting their deadlines, then the Scrum Master needs to step in.
In our example, the Scrum Master helps team members understand their assignments and offers guidance on how to go about executing each task.
Often the support a Scrum Master offers comes from hard-won lessons from working on products. They know common pitfalls and how to avoid failure. They also know how to recognize success and encourage people who are doing well. Perhaps, most importantly, they can easily empathize with the difficulties team members encounter and are deeply invested in improving workflow for all.
By safeguarding process, Scrum Masters take some of the weight off of contributors and can give Product Owners peace of mind. By occupying the space between both, they serve as an important link in the Agile chain.
The team member focuses on product
Team members make up the majority of your small Agile team. In the ship metaphor, they are the varied and spirited crew. Each team member brings unique skills and work styles to the Scrum. Self-starters in particular will thrive within Agile because the model encourages worker autonomy and creativity – as long as they ship products on time.
Team members are, in one word,
Team members get stuff done. They accept assignments, work on them independently and collaboratively, consult each other and the Scrum Master when they have questions, and have to ward off distractions for the duration of the sprint. As long as the work gets done, there’s no right way to do it.
Team members also support each other. In an Agile development team, colleagues review each others’ code and brainstorm ways to make work easier and faster. Everyone brings different experiences and can learn from each other.
Team members contribute to continuous improvement by consistently delivering products that go above and beyond expectations. When given the tools and techniques that empower them to direct themselves, team members will always be discovering new and better ways of doing things that will move the entire organization forward.
Building a team for continuous improvement
Ultimately, the people on your team matter just as much, if not more, as your project structure and plan. If you’ve set people up in roles they can excel in and set clear standards to hold them accountable to those roles, you’ll see not only better products but a team and company that improves measurably with each project.