A brief history of time (in mobile applications team)

My adventure as a Scrum Master (SM) in mobile applications team started over half a year ago in company Grupa Pracuj. I already had several years of experience as a programmer and later SM in other companies, working mainly on Web applications. As it turned out, the characteristics of a mobile team are much different from what I had experienced before. But let’s start from the beginning.

The Big Bang

When I joined Grupa Pracuj, mobile applications team practically didn’t exist. It began to revive after two developers, constituting 100% of the team, had decided to develop in other organizations. The main reason for their leave was that the team only consisted of mobile applications developers (iOS and Android), while they lacked other competences such as backend developers (.NET). The team was not able to solve this issue on their own, and as a result it had big problems with delivering working software. I can add that the team did not work in Scrum.

©2005-2015 agcm

After this lesson, the decision was made to build a mobile applications team with all the competencies needed to create the Increment. This team was supposed to be cross-functional and self-organizing. It was supposed to build applications on all platforms including iOS, Android, and Windows Phone. The team should also have a Scrum Master and a Product Owner. In conclusion, the decision was made to build a solid Scrum team.

An additional factor that affected the development of a new team were high requirements imposed from the top of the organization. The world of mobile applications is growing extremely fast and to be competitive you have to be able to verify new assumptions and deploy new solutions very efficiently and quickly.

It turned out that Scrum, with its incremental approach to developing solutions and validating assumptions, was very helpful. However, before we caught the wind in sails we had to solve a few problems. And as on every war, we had some casualties.

Inflation epoch

Most of the problems we had to deal with are rather common issues among young Scrum teams. One problem was the low level of understanding Scrum. The team was growing rapidly. On average, once a month a new person joined the team. The daredevils joining our team came mainly from non-Scrum or even worse Scrum-fall environments. This meant that they did not have any experience in Scrum or their experiences were painful. An example note from one retrospective was “I believe that the Daily Scrum is a waste of time. Why waste an hour and a half each day on talking?”.

Similar situation was with transparency and communication, both between the PO and the team but also within the team itself. At the beginning PO visited the team only once a week and did not fully understand what the team is working on. The team defined the tasks in the backlog. On the other hand, team didn’t have anyone to answer their questions and doubts.

© fat-quarter.blogspot.com

We have managed to resolve all of the aforementioned problems. The cost we had to pay are hours of stormy, but also interesting discussions about the world of Scrum and incremental approach to software development, and one PO, who due to the lack of time, had to delegate his responsibilities to another person.

However, the real challenges in the mobile team are associated with the complexity of relationships and dependencies that are required to create mobile application on all platforms. This complexity is due to the large number of required competences. To create a mobile application we need developers for Android (Java), iOS, WP, .NET and also UX designer, tester and graphic designer. Their work is quite heavily dependent on each other and you need to do your best to get an Increment after each sprint.

You can also develop mobile applications using one of the cross-platform tools. This approach reduces the number of required various competencies in a team, but unfortunately also reduces the ability to optimize applications per different platforms. We chose greater flexibility for the cost of greater complexity.

In our case, all the competencies needed to create the Increment have been added to the team. This means that we have transferred the whole complexity and all of the dependencies into the team. This doesn’t mean, however, that all of the problems and dependencies have disappeared, it is just easier to manage and resolve them.

© StarWarsToyBox.com

One of the returning issues, which we are struggling with, is cooperation between the UX designer and the rest of the team. On the one hand, we would like our UX designer to work as close to programmers as possible, and we are trying to speed up the design process. On the other hand, we want to verify our ideas quickly and with the lowest possible cost. This is possible, to a certain extent, with the use of a prototype. It is a component of our process, which we want to use in our advantage and we try to improve it. Recently, we tested some prototyping tools (InVission, Marvel, etc.) which will help to accelerate this process. We have also included our graphic designer from the beginning of the design process and we are working on acceleration of the user tests.

Another difficulty is to have all of our platforms developed at a same pace. It is not always possible. This problem is related to very clear division of competences in the team. Developers are specialized in one of the technologies (.NET, Android or iOS) and do not know the other in advanced level. The same is with non-developer skills, such as the UX or graphical design. Overall, as a team they have all the skills necessary to create the Increment, however, they are not able to replace each other.

Initially, I thought that work in each Scrum team should be based on collaboration1. In this case, however, it turned out to be impossible, at least not today. According to what Lyssa Adkins2 says, a team can function well using only cooperation3. What’s more, good cooperation is the basis of collaboration. In practice, the entire team is responsible for the outcome of the Sprint (the Increment) and for solving problems. The work inside the Sprint is done mainly in cooperation, which means that everyone has their own tasks. To make sure everything goes smoothly, the team members regularly communicate with each other and integrate their work. We are also constantly looking for ways to improve collaboration in the team.

Galaxies epoch

I must admit that we’ve gone quite a long way and we fought in many battles. We have learnt a lot about the world of mobile applications, where the speed in which you validate your assumptions is the key, and competition is ruthless. During that time we have worked on several applications like Pracuj.pl, profil Pracuj and HuntMe. These applications have pretty good ratings. For example profil Pracuj, the first application entirely written by us, at the time of writing this article was on the 5th place in the iOS store and on the 19th place in Google Play, in its category.

We have also learnt a lot about our issues and how to deal with them. I can confirm that Scrum works well in mobile applications team. The approach we took, to build a cross-functional team also works. It allows us to manage the complexity of relationships and solve emerging problems more efficiently. As a result, this leads us to more effective work and more value delivered to the customers.

© fat-quarter.blogspot.com

This is just the beginning of our journey. Still we learn how to live in this world, and we look into the future with optimism and courage.

Ps. All resemblances with “A brief history of time” by Stephen Hawking and Star Wars are purely intentional.

1 https://en.wikipedia.org/wiki/Collaboration
2 Lyssa Adkins, „Coaching Agile Teams
3 https://en.wikipedia.org/wiki/Collaboration