Even though a lot of time is spent working in teams, little time is spent on developing teams in order to improve performance. The study to become a software developer is mostly about “hard” topics (“algorithms and data structures” etc) and not focused on how to work with others to translate skills into great user-friendly software. The busy days of developing software makes it hard for many teams to prioritize working on the soft skills of the job – how much time does your team dedicate in order to work better as a team? Continue reading “Developing high performing software teams”
Tooling is an important part of development, and using the proper tools can increase productivity and simplify the developer’s life considerably. Confirmit’s internal Code Search tool is one of those.
Code search in general is an extremely powerful feature. You can use it for different scenarios, such as when searching for a specific class by name or for finding instances of a method or code snippet used by your colleagues etc. It could even replace your IDE when you need to analyze someone’s code.
When a new project is taken on by a team at Confirmit, it is often based on initial discussions among a very limited group of people. The rest of the team has no insight into the initial ideas and thinking. We have discussed and tried various ways of kicking off new projects, in this post I want to share our experiences with one of them: Lean Inception
First of all, if you don’t know what a Design Sprint is you should start here or just google it. There are a lot of good articles out there describing what a Design Sprint is and how you should go about running one. As always, nothing will go by the book; even less so the first time you do one, so this article will focus on our key experiences from running a Design Sprint for the first time.
When I started working for this company back in 2003 we used to upgrade our production servers pretty regularly every six months. A couple of times we decided to go nine or twelve months between upgrades, and in one very particular instance when we had to replace a core data storage system we went a whopping twenty months between releases.
Today we release to production four times per week (Monday through Thursday).
So, what happened? And perhaps as important – why? Continue reading “From big bang releases to deployment four times per week”
When I joined Confirmit R&D 17 years ago the entire department was seated together. Our product was limited in size and our organization was project-based. Today R&D is product-based and consists of 16 nearly autonomous Scrum-teams spread across Norway, Russia, US, and Canada. To ensure all these teams work toward the same vision based on the same high-level priorities, we arrange a week where we present and coordinate plans for the next six months twice a year . We call it “Team Review”.