Choosing the Perfect Implementation of Agile

Problem

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.