Part 3: Tooling in Scrum – tame the evil!

Software tools can be helpful in supporting the scrum agile software development process, but at the same time they can be overwhelming to use and maintain and cause overheads for the whole team. Read the story about how we cope with them and what we've learned (not) to do.

 

Our story

In Scrum, it is important that the team members work closely together. The optimal way how to achieve it, is to lock them up in one room with a white board so they can move the colorful sticky-notes around, talk to each other and see what’s happening on their way towards the commitment they gave. This way, no extra tools are needed to plan their work, to keep track of its progress or to communicate. However, a good coffee machine would be an appreciated additional tool here. :)

 

source: https://www.zazzle.co.uk/scrum+mugs

 

Unfortunately, we don’t have that luxury. Since Davinci teams are usually spread across several geographical locations, we have to use a number of tools to eliminate the influence of this fact. In addition to supporting the agile software development, we have to stay on the top of the software quality and deliveries. This already requires certain tooling, processes and rules in order to do it efficiently and in an automated way.

Since we started to develop software we are on a quest for the best way how to overcome the geographical barriers and make the distributed team act as one soul. We reconsidered our tools selection many times and we will do it again and again. This is not just because our needs are changing over the time, but also because the tooling is evolving giving us new possibilities to minimize the overhead and organize our Scrum teams better.

 

What we've learned

Here is a short summary of the wisdom we collected over the years. This is what we always keep in mind when making a decision about tooling:

  • Use tools only to the extent that they help you.
    Don’t overdo it with the configuration, restrictions, rules and processes. Trust your team members, they are clever and self-responsible individuals. Give them the freedom to use the tools in a way they need.
  • Don’t let the tools to rule you.
    Never let a tool dictate you the way you should work.
  • Use tools which you can easily integrate with each other.
    Easy access to linked information gives a quick overall overview and greatly increases effectivity and pleasure of work (like issue tracker, source control, planning tool, quality assurance tool, etc.).
  • Don’t use too many tools.
    Adding too many tools to your tooling infrastructure can lead to the opposite result as you aimed for.
  • Don’t waste your time on tools.
    There should be no bending, no hacking and no maintenance of the tools. If possible and affordable, use them as services – you will be able to concentrate on the software development instead of fooling around with the tools (installing, updating, backing up, restoring, supporting, crosslinking, etc.).

 

Davinci tooling portfolio 

We can divide the tooling we use to support the agile software development into 3 categories (listed in the order of importance):

  1. Tooling for collaboration and communication,
  2. Tooling for planning and issue tracking,
  3. Tooling for development, continuous integration and quality assurance (this category is not directly Agile or Scrum related. I decided to list it here as it is an important part to get the whole picture).

 

1. Collaboration and Communication tools

Communication is the key element of a successful Scrum team. And this is not a cliché. At the very beginning we severely underestimated the importance of the communication tools. There were many of them available for free. However, we used them only minimally. We had to learn ourselves that having the right channels to support communication in the team is even more important than having the tasks properly planned.

Once we understood the importance of using the communication tools, we wanted to make sure that the team members can approach each other without feeling that there is an overhead involved. Also, we needed an easy-to-setup and use N:N and 1:1 channels, including screen sharing and presentation capabilities. Another breakthrough in uniting the teams was a discovery of the collaboration tooling. Having a channel on which all team members are always available, from any device, and from any location changed our teams forever.

Of course, there is nothing like a personal contact, so we travel and meet as much as possible.

  

Collaboration and Communication tool stack

  • For N:N video calls, screen sharing and presentations we use Polycoms. They are installed in the conference rooms with one or more TVs connected. 2 ways and 4 ways systems are supported. Polycoms are connected to the Exchange calendar for easier planning of the meetings. Each geolocation has 1 to 3 devices.
  • For 1:1 video calls (if Polycom is not available) we use mostly Skype.
  • For 1:1 screen sharing (if Polycom is not available) we use TeamViewer or Skype.
  • For N:N and 1:1 audio calls we use Polycom Sound station, phones, Skype, etc.
  • For a collaboration tool we use the hosted version of Atlassian Hipchat (maybe not the greatest tool, but it nicely integrates with the other tooling from the Atlassian family we utilize). 

We invested into Polycoms (that are rather expensive) but the investment returned quickly. We don’t have to spend half of the meeting setting up the connection and getting frustrated before the actual meeting starts. We just press a button and all is well set from the beginning.

Planned improvements in communication

We are migrating to Office 365 and we are researching tools available in the package. It looks like using Skype for Business would give us a robust and feature-rich platform for communication, screen sharing and collaboration. Using it next to the Polycom systems will allow us to always stay in touch. At the same time, it will significantly decrease the number of tools currently used.

As I already mentioned, no tools can prevail over the personal contact. That is why we will support travelling between the offices more extensively in the coming years.

We also would like to test a permanent channel/window between the offices. So, when you want to talk to someone in another location, you both walk into a room with the window and you can talk the same as if you’ve walked to a someone’s place in the office.

Our biggest challenge for future is to find the right tool or a platform for efficient knowledge sharing. We’ve already failed with a few tools and approaches and it looks like it is not that much a question of the tool than a question of the proper mindset.

 

2. Planning and issue tracking tools

In the early days, we’ve decided for the hosted solutions in order to concentrate on using the tools instead of configuring and maintaining them. We decided for Atlassian product stack (which was available as a hosted service as one of the first at that time). We had our issues with the Atlassian products and even now after the years they still manage to surprise us J But in general, we are satisfied with the choice.

 

Planning and issue tracking tool stack

  • For planning and issue tracking we use hosted Atlassian Jira and Confluence.

Over the years, Atlassian product family has grown and now, apart from the products mentioned above, we are also using the Service desk, GIT on Bitbucket and Hipchat. Everything is nicely integrated, so with no extra effort, everybody has a pretty good overview on the progress of the planning and development.

I will repeat myself here again, but you have to be very careful and don’t overdo it with the tools configuration! Defining all kinds of specific workflows, planning boards, statuses, issue types, mandatory fields, etc.  which you may think helps and guides the team is a direct road to hell. Let the configuration loose and let the team figure out to what extent they need to use it, if you do configuration changes they should be based on the requests from the teams.

 

Planned improvements in planning and issue tracking

We plan to stick to the Atlassian product stack also in the future. We review available plugins regularly to see if there is something useful that can help us to move forward.

 

3. Development, continuous integration and quality assurance tools

As I already mentioned, this part is not directly connected to the agile software development. However, without the tooling we couldn’t do the agile development at all.

In general, the tooling is there to support development and automate everything that actually can be automated; from the continuous integration process, through automated testing, down to the code quality. We started using the tooling way before we started with the agile development. It helped us a lot in the agile transformation as we already had most of the tooling in place.

It is very important that the whole team (in fact the whole company) has a full access to the tooling. It helps to create a sense of responsibility and awareness for all parts of the development process and for all team members. Anyone can find enough information on how the things are done (such as creating a release, deploying the software, etc.) and actually perform or adjust any of these actions. 

Next to the real tooling, we also developed a set of rules and agreed standards (coding, database, etc.) which we enforce for the sake of maintainability and continuity of our software. To keep the code in a good shape, these rules become an integral part of our tooling and they are checked and enforced automatically as a part of our continuous integration process.

  

Development, continuous integration and quality assurance tool stack

This is just a list of the fundamental tools, frameworks and technologies. I won’t go to details as that would be enough for another blog or two): 

  • IDE of any choice (we use mostly IntelliJ IDEA or Eclipse STS),
  • Maven for building the projects,
  • Internal instance of Nexus as the company repository for mirroring public Maven sites
  • Hosted GIT at Atlassian Bitbucket for sources for mandatory usage of feature branches and pull requests,
  • Internal instance of Jenkins for continuous integration – each project has jobs for building, automated testing, code quality, release, deploy, etc.,
  • Internal instance of SonarQube for continuous code quality,
  • Liquibase framework to stay on top of the database changes.

  

 

I can paraphrase the famous quote saying: can't live with 'em, can't live without 'em. You have to make a choice and decide how far you let the tools help you and how far you let them to make your life miserable! It’s all up to you!

 

Publikované: 09. mar 2017 10:09
  • Peter Kobes

    CTO / Software Architect

    Peťo je náš Chief Technology Officer. V softvérovej oblasti pracuje od čias, keď sa veľkosť programov merala na bajty. V Davinci sa stará o to, aby softvér, ktorý robíme a to, ako ho robíme, robilo šťastným nielen zákazníka, ale aj všetkých developerov. Má rád nové veci a rôzne gadgets. Cení si netradičné pohľady na (obyčajné) veci a nemá rád slová "nedá sa".

We want you

Do you see yourself working with us? Check out our vacancies. Is your ideal vacancy not in the list? Please send an open application. We are interested in new talents, both young and experienced.

Join us

Podobné články