Agile organizations - experiences with an insider's eye - part 3

In our 4-part article series, we explore the differences between traditional and agile organizations, their difficulties and advantages. First-hand experiences.

Fragmented and incomplete information

Many teams are faced with having to work and defend themselves based on severely incomplete information:

• They mention the lack of specifications on every forum, which is fine, the bigger problem is when they don't do this anymore,
• Malfunctioning software is being developed, which is no longer working.

However, there is a difference between the fact that a specification is never prepared in sufficient detail and the fact that the depth of elaboration of each document varies.

• The former most likely indicates professional incompetence, the wrong person is in this position and the organization's goals would be better served by a more suitable person.
• It could also be that someone is protecting their position by withholding information.
• The second, however, is more likely to be overloaded, perhaps because the team or organization was under-planned from the product manager's perspective.

The context will determine which of these versions proves to be true, but either way, both call for immediate intervention. This will certainly make it more difficult to progress the work.

The agile structure helps by enforcing backlog transparency, but only tangentially discusses its depth.

A few tips regarding this, the following worked for me:

• Every development need must be preceded by thorough research, where business needs are thoroughly assessed and prioritized, and then these are published in a document repository accessible to everyone.
  • This could be a Wiki or even a Confluence page.
  • In the latter case, it is definitely worth attaching it to the Jira ticket.
• In addition to the business part, it must be preceded by thorough planning from the technological side, which must also be described.
• At the kickoff meeting, we gather all the roles that will be involved in the development, and there will be two goals here.
  • The product owner should provide all necessary information.
  • Everyone should get as much information as possible.
• Every day, we answer newly emerging questions in short synchronization meetings.

As with the previous topic, it is extremely important to make competent and quick decisions.

Inappropriate team structure

Agile methodologies provide some pretty rough guidelines for team composition. Of course, they should be cross-functional, have all the necessary roles, and preferably everyone should be dedicated. This is great in principle, but in reality, there are a number of mistakes that can slip in if you don't pay enough attention:

• Not all the necessary expertise is available,
• The experience is not adequate for the given task,
• The number of staff is under-planned,
• In the case of one or more roles, the possibilities are limited, you have to work from a so-called resource pool, i.e. shared with other teams,
• The team members are not compatible in terms of personality.

I have several pieces of advice regarding this:

• When putting together teams, you as a leader must pay special attention to ensuring that the team is a good fit. Often, people who are otherwise professionally high-level destroy the teams around them, unfortunately.
• On the technical side, many people are very trainable and can quickly pick up new knowledge.
• Resource problems must be escalated in a timely and effective manner; the later they are discovered, the more likely they will have bad consequences.

Continued in part 4 of our Agile article series !

Related courses

1. Digital product management
2. App management and marketing