IT expert: agile project methodology and role models

Below are suggestions for assigning responsibilities—analogous to the role model used in agile project work—for a software house.

I. Product Owner versus customer project manager

First thesis: The agile approach must anchor the role—and the limitations of authority— of our company’s customer project manager far more strongly than is commonly done in practice.

Risk

Customer requests are implemented individually and destroy the clean structure of my software foundation.

Strategy

My software house must act economically. The solution a customer receives should be implemented by using my software base. This base is expanded gradually—always with a view to my software standard*.

*This refers to: the established development environment, architecture libraries, function libraries up to the user interface— i.e., the results of previous development work. Alongside human capital, these are the most important assets of my company.

My customer owner / customer project manager—insufficiently represented in the author’s view in common agile models— must coordinate proposals for mapping customer requirements in software closely with the development lead / Product Owner.

Otherwise the foundation “frays”: every customer gets a bespoke variant, and second-level support can no longer work efficiently when investigating findings.

Note

Agree with the customer that special requests are specified in such a way that a new module can be delivered to all customers. The authorization concept is used to enable the module for the requesting party. Other customer owners receive the functional description as sales information and assess the value for their customers.

II. Product Owner versus development team*

*Agile development team: A self-organizing, interdisciplinary team that implements work from the Product Backlog and delivers working increments.

Second thesis: The “development lead” role (focus here: Technical Lead – owner of architecture and function libraries) is not defined precisely enough in common agile models.

Risk

Too much freedom is granted to the team or individual contributors.

Strategy

Anyone who has led software development knows the scenario: a smart team member finishes quickly but has introduced new—previously unknown— libraries. Often open-source software with very different license conditions. Free use may be over after an update and can impact cost calculations unpredictably. New libraries also bring new—and often unknown—vulnerabilities.

Note

Given the volume of third-party software, “library management” must be placed in responsible hands. Teams should only use approved components. New components must be requested from the Technical Lead. Whether the Product Owner or a named stakeholder performs this work is secondary—the task must be clearly owned.

III. Interaction design & usability versus agile changes

Third thesis: An interaction philosophy must meet today’s standards and remain consistent across the entire software.

Risk

Different interaction logics in different areas: sometimes context menu, sometimes scattered buttons, sometimes usable only with first-level support. Nobody has time for—or acceptance of—exotic interaction philosophies.

Strategy

Libraries used for user interaction must be validated for usability and aligned with widely adopted standards.

Note

Define the interaction philosophy. Pseudo industry standards are shaped by systems such as Amazon, PayPal & Co. Organize a “customer journey” (usability tests with people who are unfamiliar with the system). Push developers to engage with common standards to avoid creative but exotic custom designs.

IV. Exception handling & stability

Fourth thesis: No developer can anticipate every possible error scenario for inputs, corrections, copy & paste, or back navigation across different browsers.

Risk

The software “gets stuck”; only a hard restart allows work to continue.

Strategy

Provide functional building blocks for exception handling that restore the state before processing when errors occur.

Note

Provide multiple techniques (ideally as code examples): pre-checks, controlled processing, post-processing/result checks. This makes simple functions larger, but it stabilizes complex software systems and creates operational confidence. Every developer must be able to apply these building blocks safely.

Conclusion & recommendations

Success as a software house or in-house IT is achieved when customers can be served appropriately at any time—rather than with individually “cobbled-together” software that only 1–2 people understand.

What is needed are software components designed for adaptability that map customer needs within the function library/domain models (“digital twin”). If gaps exist, extensions must be designed so that they benefit all customers.

In addition, rigorous leadership of teams is required: consistent implementation guidelines (interaction philosophy, libraries, internal coding standards) and clear role accountability—from customer project leadership through Product Owner to Technical Lead.