As an iOS developer intern participating in the DVT graduate programme, we have a lot to learn. We spent the first three months working on our own personal projects which were exciting. The personal projects came from ideas we each thought of and hoped to make something out of, but we did not just jump into them. Within the programme, we were taught many things in workshops, discussions and articles from which we could draw useful and relevant experiences and skills for our personal projects.

While each of the graduates in iOS had different project ideas, it did not stop us from interacting and asking each other for help. We had full control of what we decided to put in our projects (according to what we had learnt) but we showed our code to each other for quick approval (through a pull request, to be explained later) and went on our way. Thus, when we got to the fourth month of our programme where we would now no longer be in individual projects but rather work as a team, we thought that we knew what we were getting into. From the fourth month, we were introduced to a working approach which we have now come to know as an Agile team. This is very different from working alone or from what we thought working in a team meant — there are new valuable features.

An Agile team refers to a method of project management where work is divided into tasks of short phases of work. This is to increase the production of a project. Agile (methodology or mindset) involves lots of planning, reviewing, reflecting and iterating. This was far different from the directionless way our personal projects went, which only involved having to worry about what would become the next addition to our projects as we went through workshops. We did not know what we were going to do next, nor did we spend much time reflecting on what we had done so far. However, we have learnt a great deal and are excited to see what we can do with the lessons learnt.

Now that workshops are over and our personal projects are behind us (not really, they are being used for portfolios, and could become real apps if we give them more attention), we are finally working on team projects (or real-world projects)! However, if you thought that meant that you have learnt everything you need to work on that project you are wrong! There are still many things to learn, not to mention, many new techniques and behaviours that you need to get used to. The list of techniques for undertaking a team project that will be discussed today consists of sprint planning, retrospectives, and pull requests (you might have thought that you knew everything to know here but that is not the case).

Sprint Planning

Before you get started with your new team project you go through something we call sprint planning. A sprint is what you work on in a time period you and your team decide on iteratively until a product or output is completed. Sprint planning is when you organise what will happen in that time period such as how much work you can do, what each task entails and how much time you need to do all of the tasks. It is a very straightforward way of making sure that everyone in the team has enough work to do in your time period of interest and, if not, eventually you will. To start, you will create what we call a backlog, a list of features that need to be done. From the backlog, the team will pick out tasks that you all think can be handled within the time period you set. Finally, you will estimate how much time each task will take to complete and with that sprint planning is done! Do not worry about getting it perfect the first time. Sprint planning happens after every time period your set up ends, so you have many chances to get it right.

Here is an example to understand the full concept: Let’s say that as a team you decide that a sprint for you will last for a week. To plan before the week starts, you list all of the tasks of importance or priority to complete (a backlog). Then you give yourselves tasks for the week and estimations on how long each task will take to get done. Then you start your sprint, working on your project according to that plan. When the week ends you decide what you need to do in the next sprint. Any tasks that were not completed in the sprint will move to the backlog again. A small tip I could give you is to use project management software to handle the behaviour of sprint planning. A software tool will make your life easier and provide you with feedback on how your sprint went so that you will know what to work on in the next sprint whether that will be the number of tasks or the estimations given to them.

When it comes to sprints, it is imperative that you are honest with yourself. Do not take on more work than you can handle in a particular sprint. In this way, there is a sense of accomplishment amongst all the team members to carry into the next sprints. However, if you find that you have completed all the tasks before the sprint period is over then discuss the idea of more tasks to add to the sprint to make the most of your time.

Retrospective

This was a relatively new concept to me — not the principle of it but rather the structure of it. A retrospective is a reflection of the work done in a sprint. Before you start with a new sprint a retrospective of the ‘just ended’ sprint is necessary. In a retrospective, you and your team need to think about what went well, what did not go well and new ideas to add to the new sprint. You could honestly do your own retrospective on how you have been spending your week in and out of work to really make the best of your days. The principle of a retrospective is so good! A big thing to mention though is that if your team members are not honest with each other, then the concept of the retrospective will not be that useful. If there are things that your team needs to change, then they have to be mentioned transparently for change to occur.

Pull Requests

If you thought that you understood the full extent of pull requests, then you may be surprised that there is still more to consider. A pull request is a notification that changes have been made to the code base, such as a feature, that is discussed, reviewed, accepted and eventually added to the code base. While you had control of what happened to pull requests in your own project, this concept will change in a team project or real work project. In a real-world project, you may never have the ability to add and change code (when I say this I mean merge in code). That ability falls on the business analyst/ lead programmer. The code you write and review needs to follow the behaviour your team has decided on. Reviewing code may not have been as easy as you thought because of that same reason; you do not get the final say on what enters the project. Something else that you may not like to hear is that you may have to reject pull requests. I know that no one likes it when their code is rejected, but here’s the thing: The earlier you get things right, the earlier these rejections stop. Thus all members of the team should be vigilant when looking through code. In the end, all the questions, suggestions and requests to change code will improve your abilities as a team.

If I had to give tips concerning pull requests, I would advise on the following:

• That you try to learn to look for the things that do not look or behave right as early as possible. The more you do it the more you will start to notice when things are out of place. This does not mean that you are rude or disrespectful when asking for changes or making suggestions. If you want the best learning experience, then respect is key.
• Ask questions when you do not understand. You are not helping yourself by approving things that you do not understand. Instead, you are inviting code that may not be up to standard or allowing others to believe that you will follow the same technique. Do not be afraid to ask. Nothing beats understanding things.

In conclusion, if you look closely at all of the concepts, you may have noticed the term “honesty” standing out. All of these techniques and concepts work well when people are honest with each other. If you really want to grow as a team and as individuals, then you will need to be honest when tasks seem too big or too small, too complex or too simple for a sprint. When things are going well or not going well, you need to address them constructively in a retrospective.

Finally, when code is not looking right or well understood, you need to let people know in a pull request so that you grow individually and as a team. After all, you are stronger together.