Written by After continuous integration, which evolved to discrete integration, and continuous delivery, why not try continuous communication to avoid misleading messages inside your team?
Why communication matters?
It’s known that communication issues results in many software development problems.
Some agile frameworks, such as Scrum, have well defined communication activities like daily meetings and sprint plannings.
Communication is an important subject, not only for software development, but also in many other areas. There are some social frameworks, such as colletive impact and collaboration for impact, that use continuous communication to help people achieve their goals.
Here at Plataformatec, we take this quite seriously as well. We’re always evolving our communication practices, to achieve our goals and to keep our culture strong.
Continuous communication at Plataformatec
We talk a lot to each other. We use Campfire for team chatting, Basecamp for persistent messages and hangouts or skype for face-to-face calls.
Besides the day-to-day communication, we use some agile practices such as daily meetings and retrospectives. Some of these meetings/tools are used inside projects, others inter-projects and finally, we have company-wide meetings. Let’s see how these practices evolved to fit our current Modus Operandi.
Inside projects
Dailies
In order to keep everyone inside the project on the same page we use daily meetings. An important detail here is the client presence. The client’s daily presence helps to avoid re-working tasks, since they know what is happening on a day-to-day basis.
Weekly project meetings
Once a week, every project team also has a meeting with the Account Manager. Our Account Manager is the person who helps the team solve problems at a higher level, typically overseeing multiple projects at a time, so they are not directly involved in the project’s day-to-day tasks.
We have an open communication channel with them, but it’s important to make a follow-up with all the team together. This is to ensure that the team exchanges more information and keep the Account Manager better informed about the project. Then he can provide the team with better advice on how to solve day-to-day challenges.
Inter-projects
Dashboard meetings
Every Friday our company daily meeting gets a new attribution. In addition to company announcements, we also share the projects status, what happened in the current week, new technical challenges, applied techniques, releases delivered, and so on.
Everyone in projects assigns a grade to the project, which can be a value between -1 and 2. A -1 grade means “We are performing really bad” and 2 means “We are performing really well”. Together with the grade we write a brief explanation justifying it.
We start the dashboard meeting analyzing the current and past grades so we can check how the project is evolving. This is important because everyone can have a basic knowledge of how the other projects are moving on and new things that our colleagues are using. Having a big picture of each project paves a way for advice and knowledge sharing.
Company-wide
Company Dailies
Back when the Plataformatec team was smaller, we used to do dailies to exchange projects information and other company announcements, such as new employees or new clients. But as the team got bigger, we had more and more projects teams, and exchanging all that information became complex.
Our dailies couldn’t involve sharing project information anymore, so we changed its purpose, and today we use it to share information at a company level. Information about projects is now shared in the dashboard meetings, weekly.
Weekly reports
We also have a weekly summary email, where we point our project highlights, new leads, new employees, next events. It’s a very good tool for those who lost some meeting during the week.
Monthly retrospectives
Back when our team was smaller, we used to have biannual retrospectives, where we listed our good points, things to be maintained, and points we needed to improve. We also used the retrospectives meetings to do team appreciation, where everyone has the opportunity to congratulate or appreciate someone else’s work in the team.
We used to have one day for this meeting, but as new members joined the team, it was not enough anymore. So we changed to have a monthly retrospective, focused on the good points and the points to improve. Every month we select one or more subjects to be discussed, and quarterly we re-prioritize and list new subjects, if necessary. The appreciation now is done in the Biannual reviews.
Biannual reviews
With the retrospectives occurring monthly, now we have more time in our biannual reviews. We keep doing the team appreciation, and we also:
- check our goal status (Mid-Year review, usually in June or July) and
- present the year analysis in the ending of the year, usually in November.
Kick-Off
At the very beginning of each year, the partners share the company goals and the strategic vision. This is the moment to review where we were last year, where we are now and where we want to be in the near future. It is also at this meeting that we get last year’s balance and financial projections.
One-on-one conversations
The main reason of all these meetings is to give and receive feedback. The communication problem occurs when some information is not crystal clear; the feedback mitigates this problem since everyone has more opportunities to solve one’s doubts.
However, some people have difficulty talking in crowded places, so we created an opportunity for those people too. We have a face-to-face meeting with the HR bi-monthly. Also, all partners have a weekly hour slot on their agendas to receive anyone who wants to talk about any subject.
How to evolve
It’s part of our culture to have good and clear communication. The practices we are using now certainly will not stay the same way forever. Our team is still growing; every year we have more and more projects and people joining us. Adapting and improving these practices are required to keep the company communication evolving.
It may appear that we have a lot of meetings, but they are organized and prepared to be efficient and avoid problems that having only ad-hoc communication could cause. All cited meetings here are timeboxed and have a specific goal. We work hard to achieve the meetings goals in the given timeframe for each meeting.
But beware! This is not about creating new formal meetings per se. You should focus on promoting a healthy culture of good and clear communication, and keeping feedback channels wide open within the whole company is crucial.
And what about you? What are your communication practices? Do you ever changed them?
Great post.
One of the things within projects that we’ve recently introduced at Table XI is affectionately named “Story Time”. All the devs on the project get together in a room and go through a few of the in progress and upcoming stories. We go through and discuss the story, make sure everyone understands what the story means, and develop a plan of attack. Sometimes it’s as simple as reading the story, and everyone saying “yes, we all agree on what this means”. Sometimes it goes into deeper discussion and we make known the unknowns and risks within the story. We don’t start on any story that hasn’t been story timed recently. This is especially valuable for stories that were written a while ago and are possibly ambiguous or vague.
On my current project we often roll this up into our standups, so it’s much more of “What is the status of this story” vs the traditional “What am I working on today”. It also allows us to say that a story is no longer valid, doesn’t provide sufficient value vs amount of effort, needs additional analysis, or requires feedback from the client. These are things that could be part of the traditional IPM, but is much more focused on the actual implementation details.
I also had a comment on the previous post, http://blog.plataformatec.com.br/2015/02/introducing-discrete-integration/ but the discussion is closed there.
Something that’s been incredibly valuable for us regarding “continuous integration” is that many of our projects are set up to have our CI server run on all pull requests. We no longer commit directly to master (we actually use a `develop` branch–that’s what on our staging server, `master` is what’s on production). Everything goes through a PR. That way, we know that everything should work just fine once we merge it in.
We’ll often use Work in Progress (WIP) PRs for longer running or more complicated features. We’ll still use feature flags when necessary, but if the feature really is big enough to warrant it, usually the overhead and effort of implementing the flag–and eventually removing it–becomes small enough within the context of the feature.
@jhanggi:disqus first of all, thank you for the comments! 🙂
I really liked those practices you are using at Table XI!
It’s very nice to see how other companies evolves their practices. We use something similar with your “Story Time” here. Few days before our planning meetings we do a “Grooming” meeting, to clarify what the stories really means and put all the team on the same page. It makes the planning meetings more smooth and fast!! I’m really glad to know that at Table XI you are doing this too.
I’ve never tried this standup practice, but it seems to be very valuable since it gives focus to the work in progress instead of the traditional “daily report”. I’ll suggest this in my current project and maybe write another post about how it goes.