An agile approach in strategically important projects and effective corporate management – can they work together?

Prejudice 1: Agile approaches are time-consuming and inefficient, especially because of the numerous Scrum meetings.

In my experience, it’s crucial to talk to team members and stakeholders about the regular meetings before the project kicks off. Every employee will either have had their own good and/or bad experiences with the meetings or at least have heard something about them. That’s why the team should talk about the purpose and their experience of daily, review, planning and retrospective meetings. It’s important that the team then works out a preferred template for how long the meetings should last and how often they should take place as a collective. In line with the agile approach, this template can be adapted by the team at any time for the future. In my experience, people get used to process quite quickly and they come to recognise the benefits of these meetings. It’s vital that the Scrum Master makes sure everything sticks to the rules that everyone has agreed to.

Are the meetings really that time consuming?

The Scrum Master should make absolutely certain that the fifteen-minute daily doesn’t run longer than scheduled. This meeting is attended predominantly by the development team, product owner and, if necessary, stakeholders from the specialist department. This short daily meeting ensures that the project runs efficiently, provides transparency about activities and offers people the opportunity to address things that are bothering them. However, the fifteen-minute timeframe for the daily doesn’t stop issues relevant to individual team members from being dealt with in greater depth separately (later).

The review meeting at the end of each sprint can also be conducted efficiently within a fixed timeframe (one to one and a half hours is usually enough). In principle, every employee interested in the project should be able to participate. The development team presents the results of the previous sprint as part of the review. Feedback can be given and is expected. At the end of the review meeting, an outlook on the product owner’s objectives is given for the next sprint; at this point, stakeholders can share their ideas and also make requests for what gets prioritised.

Planning with the product owner, stakeholders and the development team is usually the most time-consuming meeting. Three hours should be expected for two-week sprints. It takes place at the beginning of the sprint. The aim is to determine the user stories to be implemented in the upcoming sprint for the sprint backlog. The better the user stories to be implemented are prepared and described, both in technical or specialist terms, the faster the planning will go. But planning also offers the opportunity to refine individual points, clarify questions of understanding and divide up work packages that are too large into smaller ones. All of the meeting participants contribute to estimating the complexity of the requirements.

Last but not least, the agile team meets after the sprint for a sprint retrospective. The aim of this meeting is to jointly look for useful changes to improve the effectiveness of the cooperation. Before the start of a project, feedback is often given that this time could be saved and the benefits of it are minimal. In my experience, however, it usually very quickly becomes clear that the retro meetings are immensely helpful and the team members are keen to have them.

In summary, is the time spent in the meetings really that disproportionate to the outcome? As a former project controller, I find the benefits in terms of efficiency and effectiveness in project work to be enormous! In practice, this leads to very intensive project work, also because the development team can concentrate fully on the previously agreed work packages. Nobody is left without something to do. If the team implements the scope of work of the sprint faster than expected, more can be provided in coordination with the product owner. This approach supports effective corporate management enormously! The stakeholders – including management – have the opportunity to influence how the product backlog is prioritised at any time by communicating with each other and with the product owner. However, changes – due to changes in prioritisation, for instance – will only affect future sprints.

Prejudice 2: an agile approach means poor documentation and a lack of transparency

Where does this prejudice come from? The traditional approach often sees a detailed technical concept created before the development phase begins. This concept describes the IT system to be created in detail and in full, complete with all of its functions, data and interfaces. This is a very time-consuming process that sometimes produces very extensive documentation.

In contrast, with the agile approach, the customer only specifies a few basic functionalities and the IT project starts immediately without delays. This is perhaps the reason why employees who lack knowledge about agile approaches think that little is documented in agile projects.

Documentation is still important in the agile approach, too. The requirements should be specified precisely within the framework of the user stories. In addition, clients of agile projects often contractually agree to the documentation in the project with the contractor. It’s important that the documentation is organised efficiently in this situation. Practical experience shows that standards should be presented, agreed upon and set in the team right at the beginning. The Scrum Master and the client in particular are responsible for ensuring compliance with the specifications.

How can documentation be created and maintained without requiring serious effort? Does this even save time?

Project documentation

The results of relevant votes and architectural decisions are documented in the form of result logs. This is always done in the same place and in the same format. This is particularly efficient in Confluence, for instance – there is no need to send documents to regularly changing distribution groups.

PowerPoint documents are usually prepared to vote on fundamental decisions (processes, tools, methods). These are also filed in Confluence. The actual decision can be found in the log.

All of the requirements and tasks are always documented in one place exclusively, such as in Jira, a web application for task, requirement and error management.

Software documentation

Generally applicable standards should be agreed for the development of the code as well as the documentation in the code itself (such as clean code).

Documentation tools are used to create supporting overviews (such as Draw.io).

Conclusion on documentation

Yes, documentation is also part of the agile approach. It’s vital that an issue is only ever documented in one place. This saves time and avoids conflicting information. This type of documentation ensures transparency and saves time.

Summary

There are good reasons as to why agile approaches are so widely accepted. The easy-to-understand agile methods ensure the project is efficient thanks to the support provided by the Scrum Master. Another positive aspect is the high level of motivation in the agile team as a result of the open communication and short decision-making processes. I’m currently working in an IT project as a Scrum Proxy Product Owner and Project Coordinator. From this point of view, I can confirm just how effective this approach is since the full solution is not sought immediately. Instead, individual building blocks and/or functions are implemented step by step, aligned with the company’s requirements.

Would you like to learn more about exciting topics from the world of adesso? Then check out our latest blog posts.