Your agency has been using a waterfall model for years. With the rising popularity of agile methodology, your company decides to send a few team members to scrum training. Now you're excited to bring scrum to your company because you learned from an agile coach that scrum helps teams meet their deadlines, while building better product. Before you decide it's time to "go agile," here are 4 things to consider:
1) Do you have offshore team members in different time zones?
The Scrum Way: The scrum framework is based on the concept of self-managing teams and is recommended for collocated team members.
The Problem: It's not always possible to have collocated team members, not to mention, team members in the same time zone.
Offshore teams exist in companies not exclusive to agencies, but in small agencies, teams may be working with individual contributing contractors that are spread across the globe. Having a quick 9am meeting everyday at the office may be an inconvenience to one team member in Europe or impossible for another in Asia. Before implementing daily scrums, think about the communication tools that are needed to facilitate the new ritual. How much will the tools and equipment cost the company? How will you ensure everyone has the appropriate equipment to complement the communication tools? Will these tools or processes introduce obstacles and barriers for your team? How will these new processes make people's jobs easier? Is there anyone who does not need to participate in the daily scrum? If so, how will you ensure they stay connected to the team? If new processes create more barriers and inconveniences for team members, chances are they will not stick.
2) How are your team members contributing in meetings?
The Scrum Way: Scrum introduces many new rituals including the daily scrums, the sprint planning meeting, the sprint review, and the sprint retrospective. The framework emphasizes more collaboration to foster shared ownership.
The Problem: If not well-planned, meetings can be counterproductive. It's not uncommon to hear engineers complain "I just want to code."
Well, this is not just agencies. Before adding these events to the calendar, consider how much time you have to prepare for these meetings. Seems like common sense, but often times project managers will ask team members to block off time for a meeting only to come to the meeting unprepared, therefore, wasting precious resource time. I've been guilty of this. If you plan on incorporating any of these meetings into your processes, think about how you would like each person to contribute in each meeting. How can you make them productive and how do you plan to keep everyone engaged? Entering every meeting with a specific goal and agenda in mind is usually the first step towards having better meetings.
3) Are your clients asking "When can you finish?" and "How much will this cost?"
The Scrum Way: Scrum does not explicitly address how to estimate overall project costs and time. It focuses on breaking down a large project into smaller iterations, or releases. Calculating the average velocity after a few releases, the team can predict what it would take to complete the larger project.
The Problem: Clients want to know from the beginning, the cost and timeline for a project, before they sign off your team to start on the project.
For software companies, you may experience this with the product manager or stakeholders. For agencies, your ability to answer these questions "right," may determine whether or not the client choses you as a partner. The ability to calculate velocity after a few iterations will be valuable in validating the original estimate, but still, scrum does not address how to estimate the project from the beginning. This was one of my biggest challenges as an agency project manager because we could easily spend days coming up with a project estimate only for it to be inaccurate or to not win the bid for a project. I don't have a one-size-fits-all solution, but I would suggest starting by thinking about what the client is seeking in a partnership with your agency. Is it low-cost services? High-quality service? Long-term partnership? Strict or scrappy processes? Hard adherence to launch deadlines? What are the internal and external repercussions for missing deadlines and going over budget with this client? Do they have a high tolerance for risk? Having a good sense of this will help you determine the level of effort needed to compose an estimate and whether the client will be a good fit for your agency.
4) How will your team support a scrum master? How will having one improve current processes?
The Scrum Way: There are no "project managers" in scrum. There is a "product owner" and "scrum master." On a high level, the product owner is in charge of the vision for the product and the scrum master serves the team by facilitating communication and activities with the team.
The Problem: This framework adds an additional person to the team, which can add overhead, thus increasing cost and time, if the role responsibilities are not clearly defined or balanced. More traditional agencies who have project managers overseeing all aspects of client projects (resources, scope, budget, schedule, risk, communication, change, etc.) might also face a challenge figuring out which scrum role is better suited for their skill set or choosing which responsibilities to "give up."
Should you have a designated scrum master for the team? It depends on many different factors. How large are the teams and projects? How tight are deadlines and budgets? What are the current hiring and training challenges? How fast is the team iterating? What is the team's risk tolerance for scrappiness? What project management responsibilities are popular and which are not? In my agency experience, I've found it very difficult to implement a scrum master role seamlessly. Not divvying up the responsibilities between two roles meant a significant increase in new hire training costs, but the benefits often outweighed the costs. Having the extra person facilitating the development team sometimes slowed down projects, hindered client relationship building, and added overhead that caused us to burn through budgets too rapidly. This is not to say the agency should never implement this role. If anything, we were probably too busy to test out more approaches.
Implementing agile methodologies into our processes dramatically increased our team's ability to complete projects on time and within budget, but it did not happen overnight. It took much trial-and-error, patience, and creativity to find an appropriate "Agilefall" approach. Still, as team conditions, project size, feature complexities, and client partnerships evolve, the needs of the team will continue to change. No matter what the implementation is, I believe it's important to approach process change gradually and deliberately because what works with one company, may not work with another.
I'll end this with one of my favorite scenes from one of my favorite shows. Would love to hear about your experiences "going agile!"