Tuesday, 15 September 2015

A team in search of a process

This is a short story covering some aspects of Tranzact's evolution as we've grown from a 1 developer company to a team of 9 over the last few years. If you're mostly a developer and you've started a company or you have a team to manage perhaps you'll be able to relate to some of this story.

Tranzact was a small 2 person 1 project company in 2007. I had one focus and almost no communication points. I could work from wherever I liked. I have memories of me and my laptop going on various holidays and getaways. Together we wrote beautiful code in very beautiful settings. Mostly we annoyed my friends who wanted no reminder of work. We annoyed them frequently because we could go on pretty much any adventure. I was living the dream.

Today Tranzact is still small but we're now 9 people who manage 4 projects. We have many communication and focus points and it's no longer simple. In most ways it's more rewarding being part of a team but we realised we needed to focus on how we work together. We had heard people talk about development process. Some of us had even learned about development process. So we decided we needed a process.


Strangely I'd heard of CMMI* in our early stages. I don't think I knew we were soundly at Level 1.

Our first take was to do what developers naturally do. Forget everything we may have learned and build our process from the ground up. Without asking anyone. We ended up with our own task management software, role names and process flow.


The home baked issue tracking software

What we built was completely our own and that was very rewarding. Everyone in our small team contributed to how we build software in some way. Hein and I created the task management software. Warren got build automation up and running. We all sat down and documented our company values. At one point we even had a daily status update. Later, thanks to the help of one of our new clients, we came up with roles and a weekly cycle in order to have touch points for all the steps we needed to build and deploy our software.

What we created was quite pretty but also often inefficient and ineffective.


Building our process from the ground up.

The "from the ground up" exercise taught us that spending time with our challenges can be useful. We started to understand problems that were previously invisible. We learned how to work together. However there were still signs of trouble. Warren would often ask, 'What exactly are my responsibilities here?' and I would have no clear answer. We had moved offices to Cape Town but Hein remained in Joburg and he would comment that he felt like he wasn't part of the team. We had reached a point where we felt inadequate to come up with solutions for our troubles and decided to adopt an existing process rather than learn every lesson ourselves.

Being naturally logical and technically minded I spent some time with engineering strong, design first approaches like IDesign but felt that our problems were less about how we designed and built and more about how the team needed to work together. The next stop was Agile. Agile development seemed much more focused on solving people problems and provided a simple framework for managing all those communication points we previously tried to invent ourselves. After some quick courses on the mechanics of an agile process we committed firmly to the change. We stopped using our own issue tracking tool and adopted a tool that could easily adapt and most importantly could easily express the new process.

As soon as we formally adopted Agile and the new issue tracking tool, things got worse. We struggled with little glitches the new issue tracking had that our home grown beauty handled perfectly. We lost some elegant integrations we'd done with our build automation tool. We struggled with doing things just because "The process says we must" especially with all the downside. Many members of the team wanted to go back to the old way we were doing things. We pushed on.

Things started to get better. We started to realise some of the promised benefits and the pain of doing things differently subsided. It turned out that we still needed to learn every lesson but what we had adopted was much more than just a new process. It was an approach that allowed us to learn and improve quickly. In fact it goes a step further and mandates continuous improvement by building it into the process. It is the beginning of our new journey.

This blog itself is a new journey. I hope to write about our experiences and learnings - technical, process, business and people related - on a semi regular basis. I hope that the process of writing down my thoughts will cement the lessons and I also hope that our stories may be of use and spark interesting discussion.

*Image referenced from www.campusoxide.com. CMMI wiki

1 comment: