Working with agile methods can be particularly useful within the IT sector and for IT departments. However, they are often defined, practiced and implemented in different ways. In our blog, we will explain scaled agility to you and debunk some myths.

With each blog article, we’ll take a closer look at a specific project, company or team from the perspective. Using an example case we will provide some solid explanations of buzzwords such as ‘agility’, ‘customer involvement’, ‘OKRs’, hopefully giving you a better understanding of agile methodology.

A quick introduction to the reality of an IT team

In today's article, we will look at a classic scenario from an IT team of about 5-7 people, who all are in charge of several internal stakeholders. Every day, co-workers, supervisors and service providers approach the team with various issues. New projects are started quickly and priorities are constantly redistributed. In day-to-day business, it is getting more and more difficult for the team to handle all requests in a fast and focussed way. An additional challenge is the distribution of responsibilities and knowledge, given the large number of people involved. Surely many of you are familiar with this situation.

In this article, we will take a look at five common challenges and present approaches to solving them using standardised agile methods. We will also give you some practical tips from our own experience.

To ensure a common understanding of agile methods, we have illustrated SCRUM in the infographic below. The solutions and tips given are based on this method.

Challenge 1: Lack of prioritisation

The first problem we’ll address is a lack of prioritisation. Due to the volume of new requests, existing or new projects and bug fixes, it is nearly impossible to keep track of everything. Each team member is forced to re-prioritise tasks themselves on a daily basis. It is not uncommon that work processes have to be stopped ad hoc because other issues have been defined as urgent by higher management levels. This makes smooth processing and an estimation of the potential date of completion very difficult. Particularly in software development, this often leads to long development times or bug-fixing periods.

Solution: A central point of contact for requirements

The first thing we will establish in our team is a product owner. This is a fundamental role in the SCRUM methodology. It is the person who serves as a channel for new requirements and re-prioritisation requests from the team. New issues are only brought to the team by the product owner and by no one else. This allows the dev team to focus on the defined tasks within the sprint. 

Constant simultaneous communication streams with many stakeholders and interruptions to the development work are now a thing of the past.

Tips:

1. Introduce a consultation hour for the product owner that is dedicated
   exclusively to stakeholders and their requirements.
   
   
2. Establish a time slot each day during which the product owner formulates the requirements.
   
   
3. When you’re starting out: Have a daily consultation with the team to quickly pass on questions about new requirements to the stakeholders.
   
   

Challenge 2: No long-term planning or working on an issue

Due to the direct contact of each team member with stakeholders, a small request can quickly turn out to be a big problem. As a result, working days are rescheduled and other issues are pushed back. It becomes almost impossible to schedule a specific period of time for focused work; instead, the work process becomes fragmented and less effective. The constant interruptions make it difficult for the team to give stakeholders an estimated date of completion.

Solution: Fixed time periods for working on predefined topics

For planning purposes, we recommend introducing a "sprint" for the team. The sprint is a period of time in which the team concentrates on tasks they have previously defined together. The key advantage here is that during this time, no new tasks are accepted or processed. The sprint should always have the same duration, e.g. 2 weeks. This allows the team to work more effectively and allows them to give stakeholders a timeframe by which the task will have been completed.

Tips:

1. Starting out, a short cycle of 2 weeks is recommended to give the team the chance to give quick feedback on progress.
   
   
2. The scheduled time per day and per sprint to work on the sprint tasks with the whole team should be max. 20 % of the total working time at the beginning.
   
   
3. Setting specific times per day for this sprint-related work helps to introduce new routines, e.g. every morning from 8 to 10 AM for the whole team.
   
   

Challenge 3:  Lacking overview of the task status

The constant change and the wide range of topics often make it difficult to arrange regular exchanges between co-workers. If one person in the team then drops out, it's usually hard to understand the latest status of a task. Having an extensive set of tools to work with and communicating with stakeholders makes it all the more challenging to immediately know the status. A substitution rule for absent employees is rarely in place in teams of this size.

Solution: One central tool as digital support for agile working

Implementing a dedicated tool with digital options to map different elements can be very useful. The maintenance and documentation of the requirements, the actual tasks and also the current status can thus be displayed in one tool. Another important point is to use a sprint board to document the status of all sprint-related tasks on a daily basis. Clearly distinguishing it from other used tools will make it easier for the team to associate the new tool with the new way of working, and speed up the familiarisation process.

Tips:

1. Less is more: Even in the tool, we recommend starting out with only the limited options of entering user stories, breaking them down into tasks and displaying a sprint board.
   
   
2. Regularly updating tasks at the end of a working day is helpful to ensure that no one forgets to document information and mention it in the next Daily.
   
   
3. Assigning responsibilities per task to specific team members is useful as it creates a direct point of contacts for the whole team.
   
   

Challenge 4: Frustration because nothing ever seems to get done

Many of you might know the situation: You’re working to finish something by the end of the day, but you are constantly confronted with new requests, colleagues and other issues. Before you know it, the day is over and you have only completed a fraction of what you wanted. This can easily lead to the impression that it is impossible to complete a task in a day, and to fading motivation among the entire team.

Solution: Establish a Daily with the whole team

As mentioned before, the sprint board provides an overview, also when marking tasks that have been completed. By working consistently and regularly on sprint-related tasks, achieving successes becomes quicker. It is important that everyone mark their successes as completed in the sprint board in the respective tool. In SCRUM, the everyday coordination of the team is called the Scrum Daily. Every day, the team gets together for a meeting of no more than 15 minutes. Together they review the board and discuss the day ahead. This is the time when completed tasks and available capacities are discussed, celebrated and scheduled flexibly. It is beneficial for team spirit and motivation.

Tips:

1. Establish a Daily at a certain time each day as a mandatory meeting for the whole team.
   
   
2. Celebrate small successes together by asking: What worked really well yesterday?
   
   
3. Move completed tasks to the "completed" column on the Sprint Board as a team.
   
   

Challenge 5: Long processing periods due to slow response times

Small IT teams certainly know this situation: You are working on a project and come across a major error that has an impact on more than just the original task. As a result, the processing time can become prolonged. If you look at this scenario in classic project planning, there are consequences for all subsequent tasks. It is not possible to react accordingly because there is a fixed, long-term plan. Frustration spreads as management has to be informed that the entire project has been pushed back. A lack of initial task analysis could have caused the problem.

Solution: Initial clarification of the requirement and flexible response through sprint cycle

As every new requirement is explained to the team by the product owner, it is usually done in a way that everyone understands. In addition, questions are addressed in advance. Regular estimates by the team before a sprint can give faster indication of the completion of a particular part of a requirement or task. The short time periods of a sprint mean that any new findings can be dealt with and consequences evaluated right afterwards.

Tips:

1. Schedule meetings with stakeholders and the team for complex requests to clarify issues in advance. This is a task of the product owner.
   
   
2. Hold a sprint review of the requirements in order to receive direct feedback after a sprint and to pass on new insights from the team accordingly.
   
   
3. Discuss iterative planning on the basis of the sprints with the stakeholders to get their support and to make flexible planning the norm.

This was just one example from the everyday life of a small IT team. We have demonstrated the tried and tested SCRUM methods that you can use to overcome these daily challenges.

These standard methods are particularly helpful in mastering new complex projects and tasks together in the future and help simplify everyday life.

In the next blog article, we’ll take a closer look at the limitations of agile methods as a standalone solution.

Are you interested in implementing agile methods in your company? Don't hesitate to contact us to provide your customers with the best possible experience!