When you start a new project, the excitement is often mixed with anxiety. What can you do to feel more confident? It’s better to be safe than sorry, so it’s best to be well prepared for the process of building your app.
To make it easier, I explain to you what the app development looks like at Holdapp. Find out more about the specialists that are in the agile teams, their responsibilities, and tools. It will make you feel more secure and help you get ready for future tasks.
What is an agile team?
It takes many skills to create a functional product. According to the agile framework guidelines, every team consists of people who together have all the competencies to reach the goal. In this case, the goal is the launch of the app.
All these specialists make up the development team and are responsible for building a product. Although its name suggests that only developers can be a part of it, in fact, it’s a cross-functional group of people, such as business analysts, QA testers, designers, and other specialists. Everyone engaged in creating software is in. You’ll get to know all of them during the kickoff meeting.
Agile team structure
Every company has its own methods. The team composition presented below doesn’t have to be the same in your case. But anyhow, it gives you a better understanding of what specialists usually are in such teams.
- A project manager (or scrum master) – it’s a person directly responsible for a project. They make sure the communication between a team and a client is trouble-free. PM also keeps an eye on a budget and a schedule.
- iOS developer – creates apps for Apple devices.
- Android developer – builds apps for devices with the Android system.
- Flutter developer – builds apps in cross-platform technology.
- QA specialist – tests the apps and checks whether all the functionalities work according to the requirements for different types of devices.
- UX/UI designer – designs the views of the app and its graphics, and creates wireframes; sometimes tasks related to UX and UI are divided and assigned to two people.
- Business analyst – identifies the requirements and the specifications of the functionalities.
- Backend developer – it’s usually an external API provider or a member of the client’s team; these developers work on the backend solutions that the mobile app relies on.
The product owner and their role in a project
A product owner (PO) is the most important agile team member on a client’s part. After all, they represent an organization that commissions app development. The product owner has decisive power when it comes to setting priorities, the scope of the project, and the budget.
They decide how every functionality should work. PO also approves the results of the team’s work if they are compliant with the requirements. The product owner works closely with a project manager (PM).
The organization of work in the agile teams
Agile teams work in an iterative mode. This means that the duration of the project is divided into small periods called iterations or sprints. They usually last about 2 weeks. Over this time, the team develops the product.
This system allows us to monitor and adjust the work plan on the fly. We also control if the progress we make leads us the right way.
Meetings that take place in the iteration
The rhythm of the iteration is set by the meetings agreed upon during the kick-off.
Planning is a meeting of the entire agile team that takes place before the beginning of every iteration. Its purpose is to identify the goal and the scope of the work that needs to be brought off in the upcoming sprint. We need to set what each team member is going to work on. Such tasks will be added to the sprint backlog. Over the course of this meeting, we also try to clarify the requirements regarding the functionalities we’re going to work on. That’s the reason why a product owner must be present at the planning. After this meeting, everyone knows exactly what to do and how.
Daily – short meetings of the internal development team that take place every day. Usually, the client is not present. The goal is to get updated about the progress of the work, to find out what everyone works on, and what we have already implemented. We also talk about the problematic issues we came across. This way everyone knows what’s happening, and the project manager can quickly react to risks.
A demo is the first of the two meetings that take place at the end of a sprint. We organize them to collect information about the product. It helps us set the right direction for app development. During the demo meeting, every developer presents what they achieved in the last iteration. It is also the right moment for the PO (or anyone else who represents the client) to raise an issue concerning the implemented features. Apart from the team and PO, sponsors or other stakeholders can be present, too.
A retrospective is the second meeting that ends the sprint. That’s when the team discusses possible improvements and past problems. We also talk about the solutions that should allow us to prevent them in the future. It’s an internal meeting when the agile teams focus on the feature delivery process. As a result, we decide what corrections we need to make. They are formulated as action points and are supposed to improve the efficiency of software development projects.
Refinement (weekly) usually takes place between planning and demo. At the weekly meeting, PO and the team decide what should they do next. They add these tasks to the product backlog. Then, during the planning, we choose the deadlines. This is also the time when we go through the tasks that were already in the product backlog and analyze their status. It’s a way of organizing the backlog.
What tools do we use?
It’s not enough to realize who does what in the app development process. To have a complete picture, you need to know the tools that allow us to manage the projects effectively. These are the most important ones.
How can you find out at what stage we currently are? Where to check how much we have already done and what is yet to do? Jira is the tool that supports us in planning the work and accounting for it.
It’s a professional project management tool. Every project has its own place called a board that resembles its current status. The entire team has access to such a board. It is managed by a PM or a scrum master together with a product owner.
A default view shows a current sprint. You can check its number and goal there, along with the team composition or sprint’s starting and ending dates. There’s even information on how many days are left until the end of the sprint.
A board is nothing more than a set of properly named columns. The naming may differ depending on the project and organization but there are some basic columns that are used often:
- TO DO – at the beginning of the sprint, you can find all the planned tasks in this column. In the course of time, the number of tasks decreases.
- IN PROGRESS – it shows all the tasks the team is working on at the time.
- CODE REVIEW – a developer always checks the code written by a different developer. It allows us to keep the high quality of our solutions. So, in this section, there are tasks that technically are completed, but their code is currently verified by another specialist. They may, for example, suggest corrections or other optimizations.
- TEST – in this column, you can find tasks that our QA team puts in the functional tests.
- DONE – here you can check the tasks that have successfully completed the path described above.
Additionally, you can add other columns, such as:
- BLOCKED – with the issues related to tasks that had to be paused, usually for reasons hard to predict, such as not working API.
- CLIENT TEST – we use this column if our clients have their own, additional team of testers.
The way the board looks depends on the scope of the project and the composition of the agile team. It’s best to first figure out your needs in order to find the best layout for your project.
Jira’s Board view.
Every task or issue is assigned to a certain person. You can see who it is on the issue screen. In the details of the task, you can also find the info about:
- a type of the issue (user story, task, bug)
- a detailed scope of work
- acceptance criteria
- the epic to which the issue was assigned
- the number of the app version in which the solution has been implemented
- the estimation of the time it takes to complete the task
- time spend on a task
- version history
Jira’s Issue view.
Apart from the view of the current sprint, Jira also shows you a preview of the project roadmap, project backlog, and sprint backlog.
Jira’s Backlog view.
It’s good to know that there’s a possibility to check the scope of the particular app versions that you can see in the Releases tab. This view comes in handy when you want to make sure what has been done and at what stage.
Jira’s Releases view.
With Jira, you can check what every person does at the moment. But what if you need to ask someone a question? Writing emails is inconvenient, especially if you want to have a discussion with several people at the same time.
That’s the reason why we use Slack in our everyday communication. It’s a tool that lets us exchange private messages and chat in groups.
Every project has its own Slack workspace. It’s a place everyone engaged in app development can access. If the agency cooperates with some external providers (e.g., backend), or a client has an additional, bigger team, it’s important for everyone to have their own place where they can talk.
As part of a workspace, we create channels. Every project has several of them. Their selection depends on the provided services. A channel is a place that gathers selected people (e.g., specialists from one field and a PM) and allows them to quickly exchange information. This way team members don’t receive requests that don’t concern them.
The examples of channels:
- #api – a place for asking questions / reporting bugs / making changes in the environment that allows communication between the mobile app and backend
- #design – to inform about the changes made to the designs, to discuss the views or graphics.
- #builds – this channel is synced with the build distribution tool that informs the team about releasing the new app version to tests
- #general – here are the most important arrangements, recaps of the meetings, the agreed release dates, etc.
Depending on the project and the app development stage, you can add new channels, such as #bug where you can report bugs detected by the client or the final users.
Below the channels, there’s a section for sending private messages.
Please, remember that we should exchange most information on the public channels to keep up the transparency and fast information flow.
You know how an agile team works. What’s next?
When you know the agile methods, it’s easier to understand what tasks wait for you at the planning stage and later – during the product development and continuous improvement phase. It allows you to determine in advance what information the development team is going to need. This way you are also able to decide what competencies should you work on as a product owner.
This will all come in handy in your everyday work on product development. And it will be easier for you to cooperate with other team members.