Jul 30 2016

Learnings: branching, stand-up, DB Automation, OKRs

This week we had a branching strategy meeting. The organizer and I expected quite a bit of fighting but with great surprise the meeting was smooth and we reached an agreement very quickly. As a team, we all prefer short lived branches and use feature branches and feature toggles only if strictly needed. If we do, we never want master to be merge back to a feature branch but we always use an integration branch. We aim to ship once a week.

I always encourage this strategy because offers so many benefits:

  • Avoid big bang merges
  • Force to do a better task breakdown
  • Encourage opportunistic refactoring 
  • Encourage pair rotation
  • Reduce the work in progress
  • You can ship partial work to customers and get feedback
  • Continuous integration and early detection of problems

I also attended an internal stand-up training organized by our Agile coaches. It was fun as it involved some role paying. In addition to how make a stand-up good, we collectively identified what we think are the biggest benefits of stand-ups:

  • Communication
  • Face to face time
  • Visibility
  • Celebration of progress!
  • Serendipity
  • Goals/focus
  • Unblocking people
  • Check-in on goals
  • Accountability
  • If right then helps build the team
  • Shared ownership
  • Coordination

I spent some time setting up an end to end environment to do a release testing of our DLM Automation Build and DLM Automation Release plugins in the Visual Studio Marketplace. I set up a project in Visual Studio Online, committed a script folder using SQL Source Control, configured CI to create a build artifact from the source and finally configured the release to automatically deploy the changes to a SQL Azure database. It was a basic setup but good enough for me to understand how the plugins fit together and be confident everything worked. You can learn more in our DLM page.

I watched a video on how google set goals (OKR: Objective and Key Results). I found this approach interesting and when I tried to set some personal OKR I struggle a lot. It’s not easy but it helps to identify what really matters for you. Objectives should be ambitious and feels uncomfortable. The key results make the objective achievable and measurable. OKRs should be set at personal, team and company levels and should be public. The benefits of this approach is to make major goals visible, measure progress and focus effort. The idea is that they should come from the bottom up and not be used as a performance evaluation weapon.

Other small peaces of learning





Permanent link to this article: https://www.productivecsharp.com/2016/07/learnings-branching-stand-db-automation-okrs/