12/11/2014
At OutSystems were are huge fans of doing post-mortems/ retrospectives. Retrospectives are a way to avoid making the same mistakes over and over. It is also a great way to promote knowledge sharing across teams so that each team can learn with the mistakes of others.
For some time now, we have been growing fast, so it starts to be difficult to mange and promote knowledge sharing across teams. Nailing retrospectives on the product roadmap, is a way to ensure that we don't forget to look back and meditate. Meditate on what we've shipped, how we've shipped it, and how both can can be improved.
Retrospectives are a sort of Thanksgiving if you will
This culture of never ending improvement ensures that when a team fails, all other teams won’t make the same mistakes. It allows us to fail cheap and recover without much overall impact.
On July 2014 we launched OutSystems Platform 9 beta, and on September released the general availability version. Getting feedback from our customers early on was crucial to improve the version, and plan the roadmap ahead. By September we had fixed all major issues, and had planned two minor releases, one on October, another on December.
The October and December releases allowed us to polish some features, and bake new ones into the product. All with feedback from the field. Aahhh, now that the version was out and the next two releases planned and under way, it was time for some retrospectives.
So we organized two events:
An engineering kick-off scheduled for October 20-21. The first day was all about doing a retrospective and knowledge sharing. The second was to align ourselves for the future, and of course, some team-building time;
An Academy team internal retrospective, scheduled for October 27.
During those two days we got out of the main office to go to the country side. Fresh air, good food. Awwwweeesome.
During the first day, each team presented to the whole group the work they had done for the release. This was followed by a discussion of the processes that had been working for them, and some that they knew were failing.
The sessions were around 20 minutes, but had lots and lots of valuable information.
The first lesson I've got was that we are really growing. And fast. Teams are doing lots of stuff, things are moving so fast. The quantity and quality of what shipped on version 9 was just amazing.
Another thing that caught my attention was that some of the most innovative projects started during “My Fridays”. Just like Google, at the OutSystems R&D teams have some free time to do whatever they want. They can improve existing tools, try new tools, or try to change existing processes. Several features that shipped on release 9 started on this free time:
And I’m sure there are more examples of these, that I'm not even aware of. It was also interesting to see that almost all teams, including mine, were struggling with two things:
Note to self: write a post on how we plan a roadmap in the Academy team
So I think the main conclusion to take from this was:
Even with open spaces you'll have silos. You need to shake things from time to time and promote serendipitous knowledge sharing.
After the engineering kick-off, we started preparing our internal retrospective. This internal retrospective was to discuss some processes and tools that only we were using. Discussing it with all other teams would just be a waste of their time.
Also, things moved so fast for release 9, that some Academy team members felt we should share the work each team member had done on the previous six months.
Jaime proposed that each of us made a presentation:
The first thing I've learned was
Don't set an hard time limit for retrospectives. Let everyone present without at their own pace
We've tried to compress the four presentations in two hours, and it was frustrating. I felt that we didn't had enough time to discuss some topics that deserved serious attention.
Other than this, it was clear that everyone was worried about:
Improving team communication. There were several examples where we had failed to get the point across, and it had cost us time;
We had a medium truck factor. There are some tasks that only one or two people know how to do;
We didn't had clear guidelines for creating documentation;
We were not paying the necessary attention to mentorship;
We started some tasks later than we should, due to miscommunication with other teams.
Everyone agreed that we could work on the communication within the team. One symptom that communication was not working at 100% was that our daily stand-ups were taking 30-45 minutes. This happened, not because we were debating important subjects, but because:
Another symptom was that on several occasions we agreed that it would be productive to align the team on a decision, and let a single person implement it. After the discussion everyone had their own view of what needed to be done. Two days later and after seeing the result, we had to start over. That cost us to days of work.
A part of the team, myself included, felt that there where tasks that not everyone knew how to execute. The interesting part here was that this happened because we didn't create opportunities for job rotation.
For instance, some team members didn't knew how to create and upload captions for the videos we were producing. Our decision at the time, was that I would do it. Since I had done it several times, I would be fast doing it.
The interesting thing is that I was really wishing that someone else did that for me. Although I can make it fast, it is just repetitive work that I don't enjoy much doing.
If I had told someone this, probably we could had created the opportunity for someone else to do it, and learn how to do something new. I'm sure it would be fun for them. At least the first time!
The team members with less experience writing, were really concerned that we didn't had guidelines for writing the docs. They felt they would be more productive, if they could follow a checklist to ensure they didn't receive later lots of negative feedback. While I agree with most of their points, I think they felt this, because we paid little attention to mentorship (read ahead).
One of the things I tried to show, was that we where paying little or no attention to mentorship.
An example of this was that team members that were learning to write the docs, felt confused with the feedback they got. Since the feedback was too sparse, it was frustrating for them. They felt that had to constantly rewrite.
When a trainee carpenter wants to learn a new skill, they will not read a book nor a checklist. They'll find a mentor to guide them in the process. It might seem less efficient for both parts, but ensures the trainee has a tight feedback loop.
And by that I don't mean assigning a mentor to every new team member. It's the responsability of everyone on the team to help new team members improve daily. This culture also ensures that the new hire will absorb the company culture faster.
Everyone also agreed that we could have done a better job if we had started earlier. But we didn't started earlier because at the time we didn't knew that the development teams were working on a new feature.
While most companies document a feature only after it is implemented, we start following the dev team early on. Most times, we start to document while the feature is under way. This allows us to think about the feature in a global context, and give feedback back to the dev teams.
But if you don't know that they are making a new feature, then you can only document it after they finish it. Or worse, ship the feature without documentation.
The hard part is learning what and where things are failing. Stopping for a week and taking some time to do a retrospective and look back on the previous six months, allowed us to do this.
Before we've started doing new things, we've ensured we changed some of the things I've talked above. We've implemented metrics and checkpoints. When milestones get near and stress starts to increase, we'll not forget to check how they are improving.
Let's see if we can ship the next versions without repeating the same mistakes.