Egeniq Development Process
Egeniq is a highly distributed company. Unlike most other software development companies our developers do not work from a central office but from various locations. Currently we are doing projects with developers located in Amsterdam, Utrecht, Doetinchem, Koudekerke, Ghent (Belgium), Kuala Lumpur (Malaysia) and Singapore. This means that there are both geographical and timezone challenges to overcome. Still we manage to do large projects (some are in the 1000-1500 man hour range) successfully. In this post I’ll try to explain what our development process looks like. I’ve gotten some questions about our processes lately and Writing it down will help me explain the process to future customers and employees, and I hope it will serve as inspiration to other development companies looking to refine their development processes or to introduce a more distributed approach to development.
Since we work with smart people we’ve been working with ‘self organizing teams‘ from the start. Project management basically consists of solving problems and making sure developers can focus on their work. To do this we have implemented a set of tools that we think empower our developers instead of slow them down – traditional project management is reduced to keeping track of overall progress and customer expectation management. We generally work in multidisciplinary teams consisting of interaction designers, graphical designers, business analysts, users and of course developers. There is often an overall project manager, external to Egeniq itself, to keep all of the different parties in sync. Egeniq’s project management can therefore focus on the development process. This is why we don’t currently employ dedicated project managers; The lead developers that have project management responsibilities need a solid technological background and a thorough understanding of development processes.
Project Management Tools
Distributed development requires distributed tools. We have a few basic requirements that we feel tools should adhere to:
- They should be hassle free. They should help us do something better, not add overhead to our process.
- They should be distributed in nature. This typically means we choose ‘software as a service’ or ‘cloud’ tools when available.
- They should be flexible. We constantly refine our development process and we like tools that fit our changing processes (we feel many companies make the mistake of adjusting their processes to their tools).
Currently, the central tool in our development process is Pivotal Tracker. It is our project dashboard that shows us what’s done, what’s currently being worked on and what’s still on the horizon. We estimate all stories in story points, and Pivotal does a great job of telling us our project velocity and showing us if we are on schedule or not, what gets into a release and what won’t make it.
Pivotal is a great tool to manage individual projects, but it didn’t allow us to perform higher level planning. We wanted to make sure developers know what projects they are supposed to be working on, and we want to have insight in how much time we have available to take on new projects.
We ended up using Google Calendar as the main planning tool. It’s a convenient way to see what everybody’s working on (everybody has a regular calendar and a work plan calendar that just contains the projects someone is working on). These work plans are open to everyone in the company so it’s also easy to see what someone else is working on without requiring any additional tools. Google Calendar has an API so we were able to write a small custom PHP script (available in GitHub here but be warned it requires tweaking to your own processes) that gives us an overall overview of who is working on what, how many days we have available and when we can work on new projects. The tool takes into account our 20% time (we generally only schedule developers 4 days a week; day 5 is for slack, company stuff and to work on any of our own pet projects) and allows us to tentatively schedule projects based on their global estimates.
The 20% time I mentioned is crucial; not only does it help prevent schedule stress (there’s always this extra day that you can use to finish something), it is also a great way to motivate developers to stick to their plan as that helps them work on the really fun things on friday.
Distributed Source Control
Source control systems are essential to anybody doing serious development. At Egeniq we’re using Git as our source control tool of choice. Why Git? Because it’s highly distributed, which fits our nature. We have developers working in different timezones on different features, and by working in your own so-called fork of a project, nobody is in your way and you can be more focused on your job. Git makes merging features from multiple developers a piece of cake, so working separately and integrating often works great for us.
I must say however that we’ve only truly unlocked git’s potential when we started using GitHub. GitHub isn’t just a ‘convenience’ tool, it’s a crucial factor in making the most out of git. GitHub allowed us to implement a very smooth distributed version control process. In a nutshell it comes down to the fact that every project has a main Egeniq repository and 2 or 3 maintainers. Every developer forks the projects they work on. When they have work completed, they send a pull request up the line which then gets integrated into the main repository.
Our continuous integration environment ‘Buildozer‘ (which we will launch as a ‘software as a service’ product for other developers soon) fetches updates from the main repository, builds the apps, signs the code with the proper developer certificates and provisioning profiles, and generates an over the air download package for our testers and clients.
Code Review Process
We use the GitHub pull request and commit comment system to perform code reviews. Because changes need to be pulled into the main repository by a maintainer every single line of code in any of our projects gets reviewed. Although adding a code review process seems to add a significant overhead to a project, it is actually a great time saver. I bet that one of the reasons our projects get completed on time is caused by the fact that we catch mistakes early in the process. And it’s not just coding mistakes; we also catch functional or architectural issues early on in the process.
A code review process based on GitHub’s tools is truly collaborative. A person is always responsible for performing a review before the code lands in the main repository, but it doesn’t stop there. Developers often review each others code if they want to know if a certain dependency they expect is properly coded. They can even pull from each other’s repositories to try out integrated code or to help fine-tune code.
Overall we’ve seen that our code review process leads to higher quality code. In turn this leads to code that is easier to maintain, and that helps us offer flexibility to our customers when they need changes to a product during the project or afterwards.
Testing deserves a post on its own so I will not dive into too much detail here. In short, we use Pivotal’s story life cycle to manage human-based testing of software (stories get ‘accepted’ or ‘rejected’ based on test results), but we also work with unit tests to prevent software regressions and to guard the quality of existing code when changes are committed. The author of the Kiwi test framework for IOS works at Egeniq, so expect some more specific content about software testing in the future.
Ticket Systems and Customer Support
Finally I’d like to say a few words about how we handle customer support. I get a lot of questions why we decided not to use a tool like Jira, so let me explain. Jira, in my opinion, is a tool that is targeted at developers and keeping track of activities. When we tried out Jira, we found out that it wasn’t a joy to use and it seemed to add more overhead than we wanted. What we ended up using is ZenDesk and its great integration into Pivotal. Zendesk is focussed on the customer and making sure they are able to report what they need. It facilitates a structured communication between us and the customers or end users without introducing hassle (sometimes customers aren’t even aware that a tool is used; it’s very transparent).
Items from ZenDesk that require work by a development team are flagged in ZenDesk, and Pivotal automatically picks up these items and adds them to a project. Developers working on the project can simply fetch stories from the ZenDesk column and start work on them.
This way of working is an example of a very lightweight approach that adds hardly any extra processes for anybody involved (developers already use pivotal stories so that doesn’t change, customers already send us bug reports and that doesn’t change either, it’s just that someone makes the link between what a customer wants and what a developer then needs to do – this will always remain a human’s job.)
This post contains a brief description of the way we run projects at Egeniq. One thing that is important is that the process will continue to evolve and to change, adapting itself to the needs of our customers and of ourselves. Since the way we run projects is the single most important process we have, we regard it as ‘polishing a diamond’. Constant, careful attention is paid to what we do and every time we encounter something that has room for improvement, we improve it. The basis however will always be there: a lightweight process that is designed to aid, not to burden, our team.
Comments are closed.