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. :)
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.
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:
We can divide the tooling we use to support the agile software development into 3 categories (listed in the order of importance):
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.
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.
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.
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.
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.
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.
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.
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):
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