Product Development Evolution at Yesware

When I started at Yesware just over two years ago I was its first ever Scrum Master. I had worked as a Scrum Master for years at a few different companies and I was really excited to come to Yesware. I loved the people, the location in downtown Boston, the office space (and that has since gotten even better!) and the culture.

One thing that wasn’t so great at the time was the product development process. I was hired to help with that.


The first thing I noticed was that standups didn’t seem to be delivering much value. The team went around in a circle and talked about what they were up to, but it wasn’t always clear which work items they were referring to, and how many items they were working on at once. To manage project work, the teams were using a bug tracking tool. That’s great for bug tracking, but not great for Scrum teams. So I switched tools to something designed for Scrum teams (JIRA) and I began using the work board feature as the visual in standups. When team members spoke about what they were doing it was very obvious if it was actual sprint work or if it was outside work. I think standups improved.

I take the rules of standups very seriously. We only get fifteen minutes. People should not go into deep dives; take it into a separate conversation. People should let their fellow team members know if they accomplished what they said they would in the prior standup.

Since I work with all the teams at Yesware, I am in a ton of meetings, but that doesn’t mean that everyone should be. Standups are so valuable because they reduce the need for other meetings. Everyone knows there’s an opportunity to sync up with the team at the same great time, same great location every day. When issues arise, the involved individuals can hold a follow up meeting, not dragging everyone into the discussion if that’s not prudent.

In case it’s not obvious, I love standups.


So, standups were improving. I wish I could say the same for planning meetings!

At the time, we were working in two week sprints. Our meetings were scheduled for four hour blocks and more often than not the teams used up the entire four hours. It is really hard to sit through a four hour meeting, even if you love meetings, which I do. Teams would discuss sprint work in great detail, and then several days into the sprint everyone would forget what we had talked about in planning. Definitely not a good use of time.

Also, since estimating in story points and tracking velocity had worked well at my past companies, I wanted to do that at Yesware. It just didn’t work here though and it was another time suck. So we stopped spending time on any detailed estimating and now do only high level, t-shirt size estimates.

Where we are now

Fast forward to our new and improved process! We don’t strictly follow Scrum anymore, but instead do kind of a hybrid of Scrum/Kanban/Yesware special sauce. We still do standups, because they are awesome! Every morning (but not too early) we meet up, talk about what needs to be done, and get on with our day.

We still do planning meetings but they are nothing like before. We take more of a just in time approach to planning. Teams have two planning meetings a week on their calendars but they only happen if there is work to discuss. We talk about what we are doing now, and once we have enough detail for people to get to work, we break and go back to our desks. Oh yeah, and each meeting is only scheduled for an hour. There’s no worrying about anyone falling asleep due to meeting exhaustion.

Other improvements

In addition to the day-to-day process changes, we’ve made improvements at a higher level as well. I’d like to highlight some of those.

Besides standups, my favorite meeting from the Agile world is the retrospective. I love to talk about things we should change to work more efficiently. We have retrospectives about every two weeks and it’s a closed door meeting, meaning only the team members may attend. People are free to say whatever they feel, and what happens in retro stays in retro. Many process changes have come as a result. For example, discussing issues with using our work board has led to changing work-in-progress constraints and simplifying the board’s workflow. Even little things, like putting a status dashboard on a big TV and tracking standup tardiness to encourage faster meetings, had their roots in retros.

The simplification of daily process has made it easier to see the big picture and what’s really going on. Back when we did Scrum I kept an eye on how many work items a team member was working on, but it wasn’t a focal point for the entire team. Now it is! We closely monitor our work in progress to make sure we are not spreading ourselves too thin and working on a bunch of stuff when we could be delivering fewer things sooner.

Finally, reducing the duration and frequency of meetings has allowed us to improve our scheduling. Back in the old days we would have essentially all day meetings at the start of each Sprint. Now the majority of meetings are in the morning, generally right after standup. People attend their meetings and then have a big chunk of uninterrupted time to actually get stuff done. The cost of context switching is well known and I try hard to minimize that at Yesware.

Wrapping up

Things work differently than they did when I started here, but I think nearly everyone feels it’s been a change for the better. We certainly haven’t figured everything out at Yesware. But we have taken plenty of steps to improve our process, and we continue to tweak it.