Architecting an Agile Enterprise
In the insurance industry, be it life, health or P&C, the need to innovate is dire. Disruption is the word of the hour. Discussions around innovations in core systems, business processes, omnichannel experience for producers and policyholders, and digitization (e.g. e-application, e-signature, e-delivery, etc.) abound.
The common thread weaving through all of these discussions is the role of technology: It is expected to lead the charge. And why shouldn't it? Technologies such as social networking, mobile computing, big data, neural networks, machine learning, and artificial intelligence, are all expected to disrupt the marketplace, and pay big dividends to those willing to make the bet. Venture Scanner's Insurance Technology Market Overview and Innovation Quadrant for Q1 of 2017 shows them tracking 1,050 start-up companies in 14 categories across 54 countries with a combined $17 billion in funding.
For carriers, often viewed as evolving slower than a speeding microorganism, the challenge is figuring out how to participate in the market disruption that presumably awaits their fate. According to the venerable Harvard Business Review (HBR), the answer lies in being agile. In the May 2016 edition, in an article titled "Embracing Agile," the authors posit that the same agile innovation methods that have worked wonders for software development teams over the past 25 to 30 years are ripe for the picking as innovation methods of choice in a broad range of industries and business functions. In other words, agile approaches are no longer just for skunkworks projects; they are the way to innovate.
With HBR's recommendation understood, the challenge for carriers is figuring out how to architect their enterprises to be (more) agile. To frame this portion of the discussion in the proper context, let's define a few key terms.
- By enterprise, we mean the three-legged stool of people, process, and technology that supports any given business function, and more specifically in our current discussion, any given innovation project.
- Next, by agile, we are not referring to any of the specific agile software development methodologies such as Extreme Programming (XP), Scrum, Kanban, and their ilk. Rather, we're referring to the underlying values that make a given approach or methodology agile. In a manner of speaking, we're discussing not just "doing agile," but also "being agile."
- Finally, by architecture, we`re referring to the structure or structures of a system, which comprise elemental building blocks of the system, the externally visible properties of those building blocks, and the relationships among them. This is an adaptation and generalization of the definition of software architecture, as defined by Bass, Clements, and Kazman in the 2nd edition of Software Architecture in Practice, published by Addison-Wesley in 2003.
Since we`re borrowing a methods leaf from the software development community, we should address an issue many agile software developers would take with mixing in architecture. Agile software developers have an aversion to heavy and seemingly endless documentation of a system, which, in traditional methods, would be the outcome of an activity they would call “big design up front” or BDUF.
Instead, they prefer an emergent design that`s the result of following the principles of “keep[ing] it simple” (KISS) and “you aren`t going [to] need it” (YAGNI), the latter a reference to attempts to build product features and capabilities that are not required currently, but are being anticipated as being required at some future point.
Such disdain for architecture by agile software developers is misplaced. The reality is that in viewing architecture as defined herein, we find that every system has an architecture; it's only a matter of whether that architecture is intentional or accidental. Even the "emergent design" that agile software developers gravitate towards is the outcome of operating in some context that is pre-defined.
To borrow an analogy from construction, when building a house, one can certainly start out by building a single story structure, but if one anticipates needing to build a second story at any point, it had better be factored into the foundation. Not doing so will require tearing down the structure and rebuilding with a stronger foundation. This is an example of a feature that will not emerge. On the other hand, adding an additional room to the first story could certainly be an emergent feature, issues of physical space notwithstanding.
As to living the values of agility in order to be agile, in 2001, a group of individuals branding themselves as the Agile Alliance promulgated an Agile Manifesto as a way to codify the values of agility they adhered to. While these were in the context of software development, the premise of HBR's recommendation is that agile methods are broadly applicable, so it's worth discussing.
The manifesto states, "… we have come to value: individuals and interactions over processes and tools; working software over comprehensive documentation; customer collaboration over contract negotiation; [and] responding to change over following a plan. That is, while there is value in the items on the right, we value the items on the left more." Let's imagine how these values might be seen in action on a project team.
In assembling a team, valuing individuals and interactions over processes and tools can manifest itself in several forms. First, team members should not be assigned to the project by managers. Instead, positions on the team should be filled much the same as any open position is filled in a company: through a process of applying for the position, interviewing candidates, and reaching a joint commitment to join the team between the project leads and the candidates. In doing so, the bar on required skills should be kept high, and not compromised due to the presence of other factors. The skills being sought should be a versatile set of skills, enabling team members to perform a variety of tasks. They should not be a narrow and specialized skill-set, constraining team members only to perform tasks within their specialized area of skill. The team should look more like a military special operations team, rather than a complete army.
Second, in valuing a working product more than a specification of it, we should measure our progress regularly and often. The only measure of progress should be demonstrable features and capabilities. Descriptions and status reports will not suffice. The purpose of this is to see the progress in action directly against the desired final outcome. Measuring frequently enables the team to detect issues early, allowing the team to address them sooner rather than later.
Third, valuing collaboration more than contract negotiation can have many manifestations as well. For instance, teams should be collocated, with access to spaces for face-to-face interactions and collaboration. Since most organizations have teams comprising individuals spread across different locations, this isn't always possible. In such cases, the team should invest in real-time collaboration tools such as web and video conferencing, shared editing and drafting tools, instant messaging, etc. Investing in such tools even for completely collocated teams has benefit. As basic as these might sound, many carriers have not yet made these investments.
Another manifestation would be to have the innovative project be a full-time focus, at least for key team members. Having competing commitments and differing availability between team members prevents spontaneous collaboration, requiring interactions to be formalized, which slows things down at best, and prevents progress at worst. Finally, the team ought to be empowered to make decisions on the spot during the collaborative interactions. When such empowerment is lacking, decision point has to be taken back to the true power of authority, thus undermining the effectiveness of the collaborative process.
Finally, in valuing responding to change more than following a plan, I'm reminded of a quote from President Eisenhower: "In preparing for battle I have always found that plans are useless, but planning is indispensable." A manifestation of this is engaging in the planning process regularly, and frequently. Such checkpoints allow the team to adapt based on feedback it`s receiving. They also create an opportunity for the team to benefit from new information that might have become available. Thus, at every checkpoint, the plan going forward can be refined.
The aforementioned are just a few practical examples from real-life experiences in executing agile projects that are manifestations of living the values of agility. While the practices are examples of "doing agile" it's important to tie them back to values of "being agile," without which they end up being mindless habits whose benefit start diminishing over time. As these values spread to more areas of any organization, the enterprise will inevitably become more agile in the best possible sense.