Back to resources

Choosing the Perfect Implementation of Agile

Goal Setting
New Manager
Agile / Scrum

25 October, 2021

Shubhro Roy
Shubhro Roy

Engineering Manager at box

Shubhro Roy, Engineering Manager at Box, stresses the importance of the holistic nature of Agile methodology; picking and choosing à la carte may cause more problems than it solves.


New managers and new teams tend to struggle as they try to establish a steady rhythm of work on a day-to-day basis. I didn’t realize that it was such an issue before I had actually become a manager myself.

I’ve had this conversation with many new managers. The standard solution is a prescription of Agile. All of the teams that I’ve worked with have followed the methodology, at least to some extent. Some teams adopt a much stricter implementation. Others do their own thing with it, casting some of the more restrictive processes and conventions aside.

As teams scramble to figure out the best way to proceed, they may struggle to do enough as they transition to a better system. They may have little visibility into what the rest of the team is doing. I focus less on tracking an individual’s productivity. It’s more about identifying any barriers preventing the progress of the team as a whole.

Actions taken

When a team is working synergistically, it feels like a well-oiled machine. The team acts as a single unit. You can track metrics for the group’s success; teams tend to do well when what is expected of them is outlined clearly.

Most teams will follow Agile at least to the extent that they will plan formal sprints as a group. Each sprint lasts a given period of time, usually anywhere from two to three weeks, but this can vary depending on how their work weeks are distributed. Typically, companies will be working on a half-or quarter-based system that corresponds to the financial year. Work is allocated throughout these windows of time.

This ensures that the technical work is being conducted on the same schedule as the business itself. Typically, the work is broken down into objectives and key results to attain, or OKRs for short. It’s really helpful for any type of team; two weeks before the beginning of the quarter, to come up with what your team’s objectives need to be. Once you know what needs to be done, you can begin to match these objectives with the key results that validate whether or not the initiative succeeded or failed.

The higher-level goal of a search team, for example, may be to release a new relevance model. What would be the key result that goes along with this goal? A ten percent increase in user engagement might be one to consider. Another OKR for a service team might include the desire to reduce the operational costs of the team; one key result could be reducing the storage of clusters by twenty percent.

Once you have this, you now have a tangible goal that you’re working toward. The team knows that this will be what they need to accomplish by the end of the quarter. Working backwards, the sprint then has goals of its own that work toward each of these OKRs. That’s when you begin to enter this Agile framework where you have a sprint composed of a key result that has been broken down into smaller, more attainable tasks.

At Box, our way of rating each task in terms of difficulty and complexity involves consensus over a rubric of metrics. The person who is leading the initiative defines the task and its purpose explicitly. Everybody on the team is then able to voice their agreement or disagreement with a vote on the complexity of the task.

This paves the way for a conversation about the results. Once everybody has agreed upon the cost of a task, it can be wedged into a sprint so that the team may carry it out.

I notice that a lot of teams miss out on a daily stand-up. Stand-ups are not just for keeping track of the team’s progress. They are also the forum where blockers are identified and resolved. The last thing that you want is to arrive at the end of your sprint and realize that you had only accomplished half of what you needed to get done. You likely could have identified some of the factors holding you back while the sprint was still in full swing.

There is a certain way that we do things, and it works really well for us. I’ve seen it done many different ways, though.

Lessons learned

  • If you’re thinking about implementing Agile into your own workflow, a good place to begin is by coming up with some sort of metric that you can use to measure how difficult a given task will be to do. A scorecard-based system may assign each task a numerical value, with one representing something very easy, such as making a config change to a service or writing a doc on something that is understood well. A higher complexity rating will take more time, thought, energy, and resources. This system allows you to assign tasks fairly, without overburdening one person more than everybody else.
  • Coming from an engineering mindset, if you’re an IC writing service, you wouldn’t put all of the work that the service does into one instance of that service. This is the classic bottleneck that many of us will be familiar with. The same applies to engineering teams. What if one person leaves, or is out sick? You do not want your team to have a single point of failure, the same as with any other system. You also don't want to burn out a single member of your team by overburdening them.
  • The mental health of the team is just as essential as anything else. As a manager, you need to make sure that your team is working in a sound state of mind. A bit of social interaction really does open people up to one another. They gain visibility into the work of the rest of the team and begin to ask new questions and share their insight.
  • I, personally, am a huge proponent of soliciting the team actively for advice. There are so many opportunities to suggest something for them to try. They are then able to tell you exactly how they feel about the change. Any process that is enforced in a top-down manner has a smaller likelihood of succeeding than something that the team comes up with themselves. It fosters a sense of ownership in the team. That's what you want.

Discover Plato

Scale your coaching effort for your engineering and product teams
Develop yourself to become a stronger engineering / product leader

Related stories

People, Process & Product

5 February

As an Engineering Manager, what to focus on more? People or Process or Product?

New Manager
Kamal Raj Guptha R

Kamal Raj Guptha R

Engineering Manager at Jeavio

Assessing the Performance of Your Team

20 August

Parallels between Work and Sport.

Goal Setting
Different Skillsets
Coaching / Training / Mentorship
Ron Pragides

Ron Pragides

SVP Engineering at Trustly Group AB

Congratulations you're an Engineering Manager! Now What?

29 July

Congratulations, you have just been promoted to an engineering management role. Once you are done celebrating the promotion you have worked hard to earn you might start to ask yourself, now what do I do?

New Manager
AJ St. Aubin

AJ St. Aubin

Director Software Engineering at The RepTrak Company

Team Development Framework for new managers

26 June

Individual Contributors are familiar with a technical development framework that helps them with building products. Managers, especially new managers can leverage a parallel framework to help them build their teams while drawing analogies from an already familiar framework.

Building A Team
Team Processes
New Manager
Viswa Mani Kiran Peddinti

Viswa Mani Kiran Peddinti

Sr Engineering Manager at Instacart

How Product Marketing Can (and Should) Help Product Development

20 June

Pavel Safarik, Head of Product at ROI Hunter, discusses the frequently overlooked role of product marketing in getting high user adoption rates for your product.

Goal Setting
Product Team
Different Skillsets
Cross-Functional Collaboration
Pavel Safarik

Pavel Safarik

Head of Product at ROI Hunter