“Why didn’t we succeed to release the required scope in this sprint?”, is a typical question of classical project managers comparing project achievements and budget with the Earned-Value-Analysis (EVA). Not to mention, that even in agile projects the outcome is as essential as in classical projects. Representative answers are often:
Scrum Master: “I’m not sure, we were exactly following the agile processes and have accurately fulfilled the negotiated tools. Probably we faced dynamically changing requirements during the sprint (…)”
Product Owner: “I think that we have to learn to correctly calculate the developing effort. The T-Shirt sizes didn’t fit the actual work (…)”
Agile Coach: “During the next sprint we will focus on the mitigation of disturbances (…)”
Developer: “What is missing? We did what we were asked to do (…)”
Who hasn’t experience this kind of conversation in a sprint review?
The transformation initiatives heading towards agile enterprises are accelerating.
In order to survive on the market, enterprises need to get fast, to face current and future challenges.
On the one hand, these go along with dynamic, cross-linked and globalised ecosystems. On the other hand, especially a more and more well-informed customer full of expectations with respect to product, service and process excellence puts pressure on companies to develop and refine.
This evolutionary change is closely linked with the new implementation of approaches, methodology and engagement or the modification of existing ones. An exemplary view on the insurance industry illustrates the current trend to transform entire classical organisations into agile communities. So, the establishment of self-organized, cross-functional and elastic units is an attempt to withstand the pressure to innovate. However, this change is often closely linked to an operational mistake: Sin #6.
We see several issues in association with this development:
- If you are trying to ensure existing hierarchical responsibilities alongside political correctness, in many cases you will tend to prefer strong decision-makers like department heads, managers or team leads as product owners, product manager or tribe leads. So, they are responsible for the business mission in agile projects and the leadership of agile teams. But these people are often not the actual business experts with the best overview across market trend and business processes. They also need to do a mind change in team leadership and probably have to learn, how to empower and lead cross-functional, self-organized teams. But remember, successful changes are based on the acceptance by decision-makers and the team.
- If you are trying to ensure ongoing projects shifted to agile mode, you will probably try to prioritise the involvement of people with first touchpoints to agile projects. These employees are usually settled in IT departments. Many of these have near-business skills acquired during previous IT projects. But these people are generally not the best fitting business experts. However, to build successful cross-functional teams, deep business know-how within the team is also necessary. Therefore, the qualification of employees affected business departments is costly and coherent with a temporary lack of process expertise in routined and optimised organisations.
Even with a cultural view, it is hard for business departments to benefit from an agile framework. Organisational structures and responsibilities have grown over the decades, so business departments are mostly aligned to the efficiency of labour. Project engagements are often arranged as special and specific actions – an exceptional case. And not seldomly, project assignments are rewards or appreciation for achievements of staff. IT departments, however, are used to deal with ongoing and growing dynamic environments.
Why Is Functional Expertise So Important?
An agile transformation has to address all levels of business drivers. Starting from vision throughout mission, values and strategy. It ends with goals, respectively requirements or usable applications. Advanced frameworks like LeSS and SAFe provide a wide range of recommendations and references and can be used to re-focus the company on customer centricity by enhancing the reactivity on changing business demands and customer expectations.
To get faster, from a methodology perspective it can be attractive or even seductive to surrender the so-called reminder or warner in the team.
They are dealing with processes, functions and interdependencies between business components for years. They might urge for “ugly details” and a focus on functional expertise could be assumed to be old fashioned.
The business perspective, especially the historically grown organisation, on the other hand, has been accompanied by people with deep insights into the functional landscape as it is. The mapping on the new business capability map deriving from the requirements engineered by agile teams can just be done by experienced and proven functional experts.
The Blind Spot of The Agile Textbook
As mentioned before in this publication row examing the Seven Deadly Sins Of Agile. The Agile Textbook shows weaknesses in defining critical preconditions for a successful agile transformation or even support from other disciplines if the preconditions are not met. This means, that every enterprise which is aiming at becoming agile must individually identify what preconditions must be fulfilled before starting. The extent of inclusion and consideration of business functional expertise in particular is a substantial challenge in between.
Recommendation
We recommend carrying out an agile assessment before or at the start of agile initiatives. Parts of the assessment will be the determination of the current position (where do we stand today?), defining first goals (what do we want to achieve with agility?) and derivation of first measures (how can the goals be achieved?). In this publication, we will focus on the agile assessment of functional expertise.
Determination of the current position (where do we stand today?)
With a view on the functional expertise, this will be the heart of the workshop. Because we will figure out, how the cooperation between IT departments and the business department looks like today, what critical processes there are and what boundary conditions have to be observed. Answering the following questions may be helpful:
- Is there comprehensive process documentation, and does it match reality?
- Are all parties involved satisfied, where are the current problems?
- Are critical third-party processes in place that are necessary for the company’s success (e.g., given by customer, partner, or regulator)?
- What is the volatility of the processes?
- What are the external dependencies – e.g. interfaces to other organisations, projects and releases?
- Are there identified shortcomings in these processes?
- Are there disciplines that must define the margin for an agile team that should be responsible for the considered process?
Defining first goals (what do we want to achieve with agility?)
One possibility for achieving first goals can be, for example, identified issues with existing processes. The following examples illustrate this necessity:
- Companies need to be agile because of rapidly changing market conditions. So most probably their processes are subject to a more and more frequent and fast change. Therefore, fixing a concrete issue of the company`s processes is desirable, but it does not increase the agility in the long run. The better way is to define what “properties and principles” the new agile company should fulfil to maintain the described dynamic changes. For example, when business units are weak in describing requirements accurately, one might try to formulate the principle that each significant step in a company process needs to be assigned to a responsible agile team. These properties and principles give guidance to every team member. So, a possible goal would therefore ensure transparent requirements for all involved persons
- Another significant aspect of the process landscape is the block of governance processes. Agile teams should work independently, be highly motivated and take responsibility for their decisions. The question is whether or not an agile organisation needs governance processes. Some agile coaches say no. But is that really an option? Is an agile team able to terminate a contract with an important customer or their own mother company? Can an agile team ignore compliance requirements? Surely not! The need for governance in an agile organisation is as crucial as in organisations today. By the way, especially for the financial industry like Insurance, this is a real obstacle. Cross-cutting teams like legal, compliance, enterprise architecture, and others have the responsibility to give agile teams a framework of guidelines and principles, to consult them in all phases, and to govern them, if a team tries to deviate rules, guidelines, or principles. To involve them early and appropriately is mandatory.
So, a possible goal would therefore be governance guidelines for operating agile teams.
We recommend addressing potential issues as early as possible. Especially, how to deal with critical business processes or success factors. Should they be incorporated as they are? Or should these rather be reconsidered and optimised?
Another goal, especially when setting up cross-functional teams, is to qualify all future team members and stakeholders (including the management) in the methodology. By close involvement, everyone should be committed to the best possible.
Derivation of first measures (how can the goals be achieved?)
As already mentioned, advanced scaled agile frameworks like LeSS, SAFe or NEXUS provide a wide range of recommendations and references. Now it is possible to check, which framework fits best to the specific situation of the company. If no one fits, it’s maybe better to create an individual solution as the assembly of eligible and suitable tools, measures and approaches deriving from the different frameworks.
Furthermore, as already described, business departments should be involved at an early stage in addition to the IT departments. For the start, these can be, for example, training courses or training on the job offers. Unescorted certifications are, from our perspective and compared to our experiences, not sufficient to act successfully in complex agile projects. Skills have to be trained and exercised.
Summary
A successful agile transformation goes far beyond IT departments. Therefore, we recommend an early involvement and qualification of business departments to ensure functional expertise and deep business know-how in cross-functional teams. At best, the management is part of the required organisational change, particularly leads by adopting an agile mindset. Last-mentioned, addressing potential challenges and issues (e. g. how to handle critical processes or dependencies) should necessarily be done early stage. Otherwise, people will blame agile for poor processes.
And if all these recommendations were considered the conversation from the beginning of this article, would probably be answered by an Agile Business Analyst likewise:
“During the sprint, we learned that our current processes address business transactions that currently don’t fit the requirements coming from the customer needs. So we refined the backlog in forms of a reprioritised user story and will develop the missing capabilities in a future sprint (…)”
