Working agile

Every now and then we get a question, what does Agile working arrangement that you guys preach, really mean? As we truly believe in it and practice it daily, we will take a look at our everyday life.

Complete dedication to a project

Our developer teams are 100% dedicated to its customer. As we practice pair programming, that means two, 4 or more people. They have no other work during the tenure of a project and focus only on single customer issues. Main reason - switching from one topic to another takes time and time is very precious in our world.

Having a flat organisation at Codeborne, our customers communicate directly with developers, there are no proxies in between. Information passes back and forth unchanged. Team lead is still assigned as the primary communication point. As stated in Agile Manifesto - business people and developers must work together daily throughout the project.

Continuous communication

We are in regular communication with the customer, being it weekly iteration meetings, continuous chat in Skype or other medium like Slack or Fleep, plus of course emails. With our Estonian customers iteration meetings mostly take place face to face either at customer premises or in our office. With international customers (bi)weekly meetings are mostly held via Skype.

To keep the human touch, we try to keep a rhythm of meeting tet-a-tet every month, so either we visit the customer or vice versa. We often recommend new customers, especially international ones’ to take a tour to our office to check out personally how we work.

Iteration meeting

What do we do during an iteration meeting? First, we demo in live the work done since last iteration (usually a week) and second, go through the details and set the priorities for the upcoming iteration.

We use Pivotal Tracker as the base of work and main documentation center during the project - writing down user stories, setting priorities between them and giving feedback that something is ready to be tested and accepted or rejected. User stories are written in language understandable for everyone, that can be later simply validated - does the feature work or not. For instance, “user can log in” or “administrator can see and modify product types”, easy to test and validate.

Storytelling

When we start a project, we do a more general storytelling and prioritisation session with customer and set main milestones. For this, no “100-page specifications” are required, rather a clear business understanding of what needs to be built.

We aim to develop only the functionality that adds value to our customers (and not that is written down somewhere in documentation some time ago). In our practice we see that even if a good spec exists, we can in joint discussions come up with cases that could not be thought in advance. Flexibility needs to be in there.

Changes are welcome

With short iterations and constant contact with the customer, we are ready for changing priorities. And priorities do change! Either caused by competitor or just better ideas come along during testing or we discover something in the customer’s back end systems that makes us together to change priorities - we are ready and used to this. Most important is to do these decisions together to boost customer’s business.

Continuous delivery

One of the principles of Agile Manifesto state, that the highest priority is to satisfy the customer through early and continuous delivery of valuable software and working software is the primary measure of progress. We follow that and deliver new software at least once a day, sometimes not that often.

Getting feedback in short weekly cycles is also a good motivation for team members in a flat organization like ours - did we satisfy the customer or not? If yes, great, new stories. If not, we can quickly fix it and again take on new stories.

Launch the project quickly

One of the first goals we aim at is going live with limited number of users and testing out in real life whatever we do. For instance with banking customers we are offering to go live internally (for employees) after 4 weeks with first functionality. This approach gives the overall project the best and fastest feedback. Employees are the best to know their company products! Even more, this sort of hands on involvement prepares the customer team for public launch more thoroughly.

Minimum viable product

Agile approach with constant delivery of working software has another bonus - the customer can at any moment during the project decide it is enough of development, let’s stop it here. For instance, when it looks that MVP has been reached. In some cases MVP level is reached sooner than initially planned and the service can be publicly opened. The rest of the features can be added iteration by iteration while the system is already in full use or put on hold for the next project.

Knowledge transfer through cooperation

Our customers become the owners of the software and are free to decide with whom they continue developing it further - continue with us, with their own people or other partner.

To facilitate knowledge transfer, quite often one can notice customer representatives in our office sitting and coding together with our team in mixed pairs. In our practice working together in pairs is the best way of knowledge transfer. Likewise our team is sometimes working at customer premises.

Agile customers

Working Agile sets some extra requirements for customers as well. We expect 1-2 key roles to be fulfilled, depending on a project:

• Product owner, who will know the business needs in general and can organise contact with other business people to clarify any details in business processes and is highly available throughout the project as the primary communication point;

• IT contact for larger projects with established infrastructure at customer end. IT contact would take care of all technical issues to enable smooth working conditions. As we work from our office, VPN and all other connection questions are most common.

These requirements of dedicated personnel seem rather common sense when the goal is building or changing something.

Code reviews

In our relentless focus to quality, we have regular code reviews when more than 1 pair is involved in a project. That means a 30-45 minute session for involved team reviewing what was done yesterday and discuss future issues, how to solve one or another topic.

Weekly TeX

For regular and frequent internal knowledge sharing we have weekly “technology exchange” sessions where team members share what they have done, seen or tested.

Presenting a case in front of colleagues and facing potential challenging questions not only raises everyone’s knowledge about new ways of solving things, but also trains presentation skills, so needed in everyday life.

Retrospectives

To learn from the past and improve in the next phases, in larger / longer projects we arrange a project retrospective either internally or better yet, together with the customer. These sessions usually follow the Keep / Change / Try model: what are good practices to Keep, what needs to Change to bring more value, what new ideas can we Try to become better. Facilitating overall development of the company, we do similar retro sessions at least once a year.