Agile on a Budget

Blaine Willhoft
Aug 25, 2017 · 7 min read

Those of us who work with Agile teams are used to the dizzying array of job titles people working on or supporting a single team can have. Engineering Manager, Agile Coach, Scrum Master, Product Owner, Project Manager, Developer, Team Lead — the list can go on and on.

For startups or small businesses, it can be challenging to assess how to apply a Scrum-like team structure given that teams are often smaller (both in size and in number) and budget is often limited. Several times, I’ve had to help teams and organizations answer variations on the same types of questions:

  • “Do we really need a full-time Scrum Master?”
  • “How many teams can a Scrum Master/Product Owner reasonably handle?”
  • “Can we support the team with the people we already have?”

I’ve been on teams that have a Scrum Master, a Product Owner, an Engineering Manager, and one or more Principal Engineer(s) or Team Lead(s), which means that there may be almost as many people supporting a team as on the team itself! Is having one of each of these roles devoted to your team critical to success? If your organization can’t support this many people, can you still build a great Agile team?

Image courtesy of Pixabay (Creative Commons).

Responsibilities

I’ve found that when answering this question, that defining and then focusing on a set of responsibilities can make this decision easier.

First of all, there needs to be someone who is an advocate for the customer and the business. This person owns the requirements and timeline for the work being done. This person is responsible for setting and communicating timelines to other stakeholders within the organization — thus it is fundamentally this person to whom the team is making a commitment when they commit to accomplishing a given scope of work within a given time. When the team needs to renegotiate a commitment, it is this person’s job to ensure that the new commitment still meets the needs of the business and the customer.

This person should be a domain expert for the team so when questions regarding what should be built come up, someone with deep knowledge of that particular domain is available to help resolve them.

Second of all, there needs to be an advocate for the team. This person should be able to negotiate with the customer/business advocate on behalf of the team. For instance, often the team may scope and commit to an Epic or Story, only to later discover that it was actually much more technically complex than originally expected. It is this person’s responsibility to communicate (or at least facilitate) to the customer/business advocate what the roadblock is, what the options to resolve are, and what the new commitment the team can make is.

During negotiation or renegotiation of an Epic or Story, it is this person’s job to balance out the customer/business advocate’s job to ensure the business and customer are protected with protection of the team and their interests — whether that’s protection against overwork or stress, or protection against taking on unacceptable levels of technical debt to meet a near-term goal (thus hindering the team’s ability to get future work done). Having a balance between a strong team advocate and a strong product advocate is critical to ensure both that the team is healthy and happy, and that the team’s resources are being best utilized to build the product.

The team advocate should also be responsible for identifying things blocking the team from delivering their work, such as process problems or other teams’ work blocking your team, and work with the appropriate stakeholders to ensure those issues are identified and resolved.

Third, there needs to be someone who just keeps the machinery of the team moving. This is not a complex job, but it is very important and can be time-consuming. This person schedules team meetings and ensures that everyone can attend. This person facilitates team meetings (e.g. grooming, retrospective) and either follows up with action items themselves or delegates those to the appropriate person.

There also needs to be someone that keeps the work pipeline flowing. This person ensures that the backlog has enough work that is ready and works with the appropriate stakeholders to ensure work is identified and prepared. For many organizations, this may be duplicative with the product advocate role; however, since there is so much benefit to be had from keeping teams together and moving them to the most valuable work, it can often be more effective to have POs move between teams as needed — which makes this role necessary.

There also needs to be one or more people that coach the team and ensure they follow their own practices. What exactly this means will vary widely based on what the team is finding as it conducts retrospectives. If the team is having quality issues and commits to having test plans on every ticket, someone should help remind the team to keep their commitment to each other. If the team is having problems over-committing, someone should challenge the team during planning to ensure they consider all aspects of the work being undertaken. If the team is not effectively using retrospectives to examine their own failures and identifying issues like the above, someone needs to help examine the team and prompt them on some areas to start looking to ensure the team is asking — and answering — the right questions.

Finally, there needs to be one or more people who are responsible for assessing the performance of and ensuring team members are progressing in their careers. This person is responsible for recognizing and growing those that are successful, and providing coaching and guidance for those that are not yet successful. In most cases, this person is also responsible for ensuring enough people are present on the team and that the team has the right balance of skillsets and experience levels. If this person is not directly responsible for hiring and firing, they should at minimum be closely involved in those decisions.


Guidelines

When deciding how to best utilize the folks you have, there’s a few general things I personally keep in mind.

  • Your product advocate should not be a direct contributor to the team and cannot be the same person as your team advocate. This is critical to ensure that the balance and negotiation between the product and the team advocate, as mentioned above, is present. Every time I’ve seen this rule violated (including a few times I violated it myself, tried to fill both roles, and inevitably eventually failed in one way or another), it has led to inferior work and an unhappy team.
  • The primary throttling factor on being able to handle a single responsibility across multiple teams is meeting load, particularly for facilitators. Personally, myself and Scrum Masters I’ve worked with have found that facilitating any more than two teams is generally not sustainable. A product advocate may be able to support more teams if they are able to selectively attend meetings (for instance, only attend a subset of groomings focused just on their work), but even in that case going beyond two simultaneous teams it can become difficult to give each team the focus they deserve.
  • Roles that are mostly focused on the team itself (team advocate, coach) can be successfully delegated to someone who is also a direct contributor to the team; conversely, trying to have team members exercise roles that require more cross-company collaboration (e.g. identify and prepare work for the team) can hamstring their ability to actually contribute any meaningful amount of work reliably to the team.
  • It’s important for the people supporting the team to be as integrated with the team as possible. It’s better to try to ask one of your developers to help coach the team than someone from an unrelated part of the business — the external person will be missing crucial context on the decisions being made and thus will be ineffective at least and downright harmful at worst.
  • It’s much more important to have a product advocate that is deep rather than wide. Much of the value the product advocate provides is in being able to provide detailed context around a change and make complex trade-off decisions from a standpoint where they know all of the necessary inputs (stakeholders involved, other priorities, etc.). Because of this, it’s more valuable to have product people go deep on a particular functional area or product and move between teams if necessary than trying to ensure that product advocates stick to a given team.

Find a match for your team’s strengths

Below are just a few examples (drawn from my experience) of ways to divide up the above responsibilities amongst different people within the team.

  • Product Manager(s): Product Advocate (across a few teams)
  • Team Lead: Facilitator, Coach, Team Advocate
  • Engineering Manager: Career Management, Pipeline Management

  • Product Owner(s): Product Advocate, Pipeline Management
  • Scrum Master: Facilitator, Coach, Team Advocate (on two teams)
  • Team Lead: Career Management (with next level of management managing the Team Lead)

  • Product Manager(s): Product Advocate, Facilitator
  • Engineering Manager: Coach, Team Advocate, Pipeline Management, Career Management

These are just a few illustrative examples — there are countless ways to find people to fill each of the required roles.

By far the most important thing is to honestly assess the people you already have on your team alongside the responsibilities needed and be creative to find good fits, both in interests and in aptitude.

As one example, on one team I worked with we found that our QA lead on the team had a knack for organization, so we gave him the responsibility to facilitate and advocate for the team. He succeeded in the role to the point where he is now a full-time Scrum Master across several teams at the same organization.

Having a devoted support staff such as Scrum Master, Product Owner, and Engineering Manager for each team can certainly be ideal. However, by thoughtfully laying out the responsibilities needed to make a team work, it’s very possible to have a very successful team without needing to invest in a lot of extra people right away.

)
Blaine Willhoft

Written by

Engineering Manager at Uptake; former Consulting Engineering Manager at Vodori.

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade