Content Freaks & Mob programming adventure

cf-logo-v3In Holidaycheck’s Poznań IT department we work in teams that consist of frontend & backend developers. We pay a lot of attention to knowledge sharing within a team in order to have a common understanding of our architecture and why we’ve chosen one solution over another . For a long time we’ve had well balanced sprints, meaning that we had a few frontend and backend tasks in each sprint. Recently however, due to our business strategy and migration process of our platform, more and more tasks have became frontend focused.

We didn’t want our backend devs to get bored! We wanted to use the potential of the whole team, which meant involving backend devs in frontend tasks. We started looking for solutions that can be helpful in learning new technology stack. One of the things that came to mind was pair programing, which is a great idea for sharing knowledge, but… our scrum master proposed to try MOB programming… We thought: “Why not!? We are an agile team, so why not to try something different and learn !?” 😉

MOB programming in a nutshell, is a scaled up version of Pair programming, with more than two developers. In our case it was four: two frontend and two backend guys. We’ve prepared one of our conference rooms  to be the headquarters of our MOB programming session. We used a big TV as an external monitor – just to feel more comfortable and not to squeeze four people in front of a tiny laptop screen for hours 🙂  Second laptop was used for research, to not disturb the main flow of coding.

mob2

We’ve picked one frontend story, which was not very complex, but great for learning the basics. At the beginning of our MOB  session, backend part of our team had a feeling that the story is just a piece of cake … but it wasn’t. Backend guys haven’t had any experience with our current frontend stack and didn’t have a clue about how complex and tricky the story  might be. After we’ve discussed how we would implement the story, we were ready to code! Development process looked a little bit different from pair programming. One of the developers was a “driver”, sat in front of the laptop and owned the keyboard. He was coding what was discussed and agreed on by everyone.   The session revolved around frontend guys suggesting how the story should be done, which was then being discussed by everyone. From time to time, we also had a discussion regarding more general programming ideas like testing approach etc. The MOB session was divided into short iterations  (15-20 min) in which each of us became the driver, which allowed previous driver to focus on research and discussion.

Good parts:

  • sharing knowledge
  • new angle of looking at solutions that we are using on daily basis
  • rise  of team spirit and collaboration
  • backend guys started to like coding on frontend stack

Other observations:

  • the session slowed down the progress of product features in the current sprint, but that was expected and accounted for, as we believe it will enable us to be faster in future
  • frontend guys would love to do a similar session with a backend story 🙂
  • a whole day is too long to develop in that style
  • MOB approach shouldn’t be abused!  🙂

In summary, although we had certain reservations before we started, MOB programming turned out to be a really great experience for us! We think we will be using it   in future, as a mean  of fast learning and knowledge sharing… Maybe frontend guys will learn & love Scala? 🙂   Time will tell… 🙂

Journey to T-Shape team

t-shapeThere is a trend on the IT market to be software developer who has expertise in one specific technology (vertical line in “T”) and knows others at levels that don’t stop him from understanding a full code (horizontal line in “T”). This whole idea seems to help building cross-functional team, one of core thing in Agile world.

Currently the team that I’m working with has decided to try to become T-Shape one. There have been a few discussions how to tackle it, what should be assumptions and how we can manage dependencies. We have used brainstorming session to create a plan that all of us would support. Here is our approach:

  1. Create skill matrix to get knowledge what kind of expertise team has.
  2. Identify skills that should be strengthened.
  3. Verify in which directions team member would like to develop.
  4. Each team member proposes plan of skill’s development with clearly stated goals.
  5. Scrum Master facilitates and challenges progress on skills’ learning plan on monthly basis.

On top of this, the whole team has agreed that during transformation into T-Shape developer we still need to follow principles mentioned as below:

  • Each team member has main focus on core skill/-s.
  • We will plan how to grow individual horizontal skills during sprint planning so we could forecast more accurate sprint deliverable.
  • Each team member is responsible for his/her skill’s development.
  • Each team member seeks actively new ways of skills’ learning.

As you can see the team has decided to move closer to be cross-functional team in structured way, doing it step by step. Such approach gives them a chance to adjust it if needed and to validate their progress (see points 4. & 5.). Additionally it should help minimizing an influence on sprint deliverables. Keep finger crossed!

If you have any experience in creating T-Shape team let me know. I’m curious to find out how you have transitioned to it and I’m open for your advice!