Taking a look at corporate communication holistically
The continuous shift towards agile work environments confronts enterprises with new challenges. Classically formed sections lose touch with more agile units within the organization.
This circumstance is due to the different nature in organizational structure. Within the departments, communication and processes are fundamentally clashing. To reunite the areas, there are varyingly radical solutions, which can be realized with diverse levels of effort. On the smaller end, the focus is on promoting communication between departments, while large-scale solutions establish integrated and complete exchanges across the enterprise.
With which structures and concepts do the two separate business branch- es work?
Management, HR, controlling, finance, marketing, purchasing, and sales are usually organized in a classical way. Depending on scale, there is a numerous amount of roles across various levels of hierarchy.
If the field is large enough to war- rant a department, it is led by a department head. This is followed by team leads and the single members of each team. The chain of command runs top-down.
Often, each role is supported by individuals, who act as stand-ins when necessary. The supervisor handles the distribution of tasks outside of daily operational duties, as well as their review after completion. These tasks occur ad-hoc and are processed accordingly. Clear rules on communication are usually set aside and the information flows primarily within the levels of hierarchy. Reports from teams are forwarded bottom-up.
Departments organized using agile principles, such as Scrum, work in an iterative system. Regular meetings support this process. The Scrum Master role moderates these meetings and supports and safeguards the team. The foundation for the planning of these iterative periods, called Sprints, are To-Dos, which are collected in the Product Backlog, sorted by priority. The prioritization is handled by a further role – the Product Owner – working closely with the relevant stakeholders.
During the Sprint Planning, teams plan their capacities for the upcoming two to four weeks, depending on the chosen Sprint length, into a separate Sprint Backlog, and formulate the Sprint Goal. This goal states what the minimum required outcome to be achieved during this period is, and assists the team to guarantee, that a new deliverable result can be handed to the stakeholders.
To keep the team internally aligned, the Scrum Master introduces a brief meeting at the start of the day, the Daily Stand-up. Once the Sprint is completed, there is another meeting – the Sprint Review – which, next to the team, also includes the Scrum Master, Product Owner, and all relevant stakeholders. The attendees determine, whether or not the Sprint Goal has been achieved, and the Product Backlog is adjusted, if necessary. Additionally, any non-completed tasks are discussed and how to proceed further is defined. The Review, which considers technical factors, is followed by the Sprint Retrospective, during which there is room for feedback on the social aspects of cooperation. Topics include the communication within the team or how to avoid impediments.
Figure 2: Scrum Flow
The very different approaches and workflows present companies, in which both organizational structures are used, with challenges.
Take the following setting: An IT department, working according to Scrum, and a classically organized HR department. The HR department wants to publish its newest job posting on the website and requires assistance from IT as soon as possible. It is an urgent vacancy and time is a factor. The requirement is however not communicated during the transition between Sprints, but instead while a regular work cycle has already started. The Sprint Backlog is already filled with selected tasks, which the team is currently working on. There is no extra time, or resources, planned. This causes both departments to be dissatisfied; IT is overloaded, and the other department becomes impatient. There is a different communication and work rhythm.
Time for Feedback?
In classic departments, feedback of- ten happens incidentally and takes place, when a problem occurs, or can sometimes also be given in regular departmental meetings. This differs from the Scrum methodology, in which the Review and Retrospective offer fixed slots for feedback, and every event is treated as a potential opportunity to inspect and adapt.
Back to the example. Both departments are displeased, and HR reports its dissatisfaction directly to IT. There, neither the feedback nor the actual requirement can be processed and integrated without causing unplanned overhead and disruptions in the standard Sprint procedure.
It is optimal for HR if IT addresses the request promptly. This is possible if a time slot for such short notice tasks is integrated into every Sprint Back- log. This way, resources are set aside to handle various foreseeable urgent requests from other departments without impacting overall planning stability.
If all tasks are completed before the end of a Sprint and no or not many planned tasks from other departments remain, new backlog items can be taken into the current Sprint. The order of these potential tasks should already be discussed during Sprint Planning to avoid unnecessary idle periods. Feedback and discussions with other departments can also deplete this time slot.
Part of the challenge is thereby resolved. The case, that the department organized in agile methods is approached by multiple other departments, however, remains open. Then, further differentiation by urgency and priority is important. In this case it is critical that not only bilateral communication but also an exchange be- tween multiple parties is guaranteed.
Figure 3: The Para-Team
To restore communication between all parts of a company, there is no need for large discussion groups with all employees and grass-root democratic ballots. It is entirely sufficient for each part to offer someone to take charge of inter-departmental communication. Within the agile context, there are dedicated Communities of Practice, where there is a place for such exchanges. This method of communication can be expanded onto the entire enterprise. In the face of this challenge the term Para-Team arose. “Para”, stemming from Greek, can be translated to “over”. It is a team, which communicates across departments, with the goal of accommodating other parts of the company. Para-Teams thus function as a link and a continuous dialogue is re-established.
This approach only works, if each member of the Para-Team is allocated a time budget for these activities and doesn’t incur overload as a result of their participation. In our example, this Para-Team would include a dedicated member of HR and IT, along with every other relevant department. Clear communication via this channel could alleviate potential planning problems and inter-departmental dis- satisfaction.
In our example, clear communication through a Para-Team, including a member of HR and IT, as well as every other department, could alleviate potential planning problems and inter-departmental dissatisfaction.
The next step would be to partially model other classically organized areas along agile principles. For daily tasks, this only conditionally makes sense. Nevertheless, there are smaller projects in each department, to which agile methodologies can be applied. This can promote mutual understanding and open new points of view.
The enterprise appears rounder on the out- and inside.
– Scrum Guide
– https://www.duden.de/ rechtschreibung/para_
Manager HR & Finance, Co-Founder
Anne- Sophie Schwindenhammer
Working at Yuna Visions GmbH,
an agile IT & HR Consultancy in Darmstadt.