# data[].attributes.body
Pick an article/video in this Padlet

Share key insights/ surprises around the actions and steps that these organizations applied

Reflect how this could work (or not) at BOS

Be prepared to share your insights tomorrow with your team

# data[].attributes.attachment_link.readable_text
BACKGROUND: KNOWLEDGE WORKERS AT THE SPEED LIMIT
Lonely Planet's legal team are a fascinating example of the innovation of long-standing work practices that has infected Lonely Planet's Melbourne head office since 2008, where the techniques of agile have gone far beyond IT, and have been taken up by other knowledge workers in the 300 strong organisation, becoming inevitably lean along the way.

The Legal Affairs group has a highly strategic role at Lonely Planet - on top of getting the run of the mill 'business as usual' (BAU) stuff done like contracts for suppliers and distributors, they assist with commercial negotiations, advising on business strategy for the various legal entities within the group, and managing risk.
KEY BUSINESS CHALLENGES FACED BY LEGAL AFFAIRS
1. The legal team was commonly working late, sometimes until midnight. This was beginning to cause burnout and frustration. Working across multiple time zones supporting London and San Francisco offices did not help this!

2. Job satisfaction was waning, with few of the improvement 'project' ambitions identified in the annual off-site planning session ever achieved in the face of day-to-day demands. The backlog of work to be done was substantial, and a weight on their shoulders.

3. Some of that work backlog involved significant changes to document structures (eg contracts and work orders) to cope with an increasing adoption of agile methods of working across the whole Lonely Planet enterprise, with many old contracts obsolete in a 'trust, time and materials' world.

4. A good deal of the legal team's work was found to be generated by 'failure demand' (as John Seddon terms it) where rework on a detailed contract written without all the parameters of the deal known (eg too early) meant abandonment of much of the work produced, for another document structure entirely. For example, it is fruitless to iterate a profit-share based partnership agreement into an outsource agreement.

5. The 'drop-in' nature of demand from internal clients, and the general assumption that lawyers sitting quietly at their computer screens were not really doing anything productive, so could apparently be interrupted, was highly frustrating.

6. Frequent task swapping was the stock in trade of the team's approach to managing multiple priorities.

7. The lack of transparency of priorities of work being done by the team led their clients to generally assume they were not working on anything as important as their need for a non-disclosure agreement or contract review. An internal survey suggested they were sometimes perceived as a blocker, rather than a partner or valued advisor for the business people needing legal support.

8. The productivity of two retained external legal services suppliers (a small generalist firm, and a large specialist group) was low, with little work actually farmed out - it was easier to just 'get on with it' and have the internal team members do it themselves by working late, rather than briefing and supervising a partner's work.

9. The costs were not managed holistically - internal staff resistance to engaging the external partners was based on the false perception that the internal lawyers were free of charge, whilst the external lawyers cost cash.

10. Internal clients would commonly provide deadlines for work that were ahead of the real deadlines, in order to force prioritization of their contract over other people's work. Similar exaggeration of deal value was also evident, to get work prioritised.

11. The professional ethics and standards of lawyers is a natural source of perfectionism, which is not well suited to fast-moving environments where an internal client may come to them for advice and service at an early stage in their process (ie not knowing all the facts). This also leads to rework.

12. There was not universal support for the work priorities of the team being advertised on a board like an agile board in a public place - there was a perception that would compromise their position as advisors to the multiple internal clients. This provided an interesting cultural constraint to the adoption of agile.
AGILE AND LEAN SOLUTIONS IMPLEMENTED BY THE TEAM
The Legal Affairs team quickly became Lonely Planet's most 'lean' operational group in the traditional sense of the term - where the principles of delivering value, reducing waste and continually improving the flow of work through the system are the highest priorities, and the system is viewed (and reviewed) continuously from end to end.

The team adopted an agile board having seen how they could get their own requirements prioritized with IT-focused project teams around the organisation, when attending planning or standups with a legal card or story in hand in 2008. They had a strong sense that their old way of working until the job was done was not sustainable - the end result is a fascinating hybrid of agile, kanban, scrum and lean practices.

The most notable components of systems thinking, lean and agile that were implemented include:

1. The team's entire workload is represented on a single whiteboard. This has resulted in greater respect for the team's ability to carry a diverse and heavy load, keep it prioritized and deliver value in a weekly iteration with an element of continuous delivery of value - there is no 'release' as such.

2. The initial exercise to 'out' all the hidden demand resulted in 2 whiteboards completely wallpapered in backlogged projects and tasks of a myriad of types.

3. A new style of agile board had to be invented - recognisable to IT practitioners as having a backlog; a 'blocked' section; an 'in progress' section; testing (document with client); and 'done' columns; while allowing for individual lawyers having specialised skills (eg international law, digital contracts), each team member owning their prioritized backlog and daily work list.

4. Work is written on specially designed and printed cards, which track effort spent by

internal and external team members. These are referred to as stories, and the time the card spends on the legal board is logged (on the card) and monitored closely.

5. The team analyses productivity through a shared system of sizing work - an agile tool based on 'points' of effort per a card. The team use a Fibonacci sequence for sizing work, and calibrate against known pieces of work, allowing for variance around the difference in time taken that will occur if an expert lawyer picks up that card, versus say the Paralegal.

6. Work is tracked all the way to it turning to cash. Cards stay on the board while they are back in the hands of the LP party who requested it, as well as the third party. Blockers to executing the contracts or agreements are monitored by whoever worked on that card. The team uses a questioning approach akin to the '5 whys' of Systems Thinking to understand the root cause of any delayed work.

7. The team has a daily standup at 9:30 to discuss the day's work and evaluate any new priorities. This takes around 15 minutes. The standup thoroughly reviews the do-ability of the remaining days of work given the output to date that week.

8. Other teams requiring legal work now bring their cards/stories to the Legal Affairs board - leaving a placeholder card back on their originating agile board. These are fed into the board by the team from a 'daily news' section at the left side - mostly weekly (but sometimes daily) by re-prioritising other tasks.

9. Prioritisation by business value is largely delegated to the Legal Affairs team, who act as the trusted broker for the many business stakeholders. The transparency of their priorities on the board helps this considerably.

10. The board has an element of Kanban in that work in progress (WIP) is limited by the size of the column for each team member (after running for a year, cards now conform to a more regular size in points), and the 1-week backlog 'box' as well. Stories have evolved to being of similar size, but there is still variation.

11. The working rhythm is a week, starting on Tuesday to allow for international work to be completed on Monday for the USA and UK offices. Retrospectives are held two-weekly.

12. Work is tagged on the cards (using sticky coloured dots) as being revenue focused, corporate support or otherwise - this enables prioritization and communicates to other clients why a particular card (especially revenue stories) has priority.

13. The Manager's role is the maintenance and improvement of the overall system - represented by the board from end to end. The whole team engages in the maintenance and continual innovation of the system of working, reviewing it through retrospectives and client surveys. Thus the board has changed substantively in the two years the team has worked this way.

14. The team uses the Net Promoter Score toolkit to measure internal customer satisfaction. Staying in touch with their internal clients is vital to them, but the main focus is the external customer or end customer for the work. The job is done when cash flows from the contract.

15. There is an allowance that cards/stories grow in size during the week because of complexity of the work - it is accepted that legal complexity (especially in foreign jurisdictions) will be uncovered along the way, and that complete definition of the issue up-front rarely happens.

16. The team has developed a strong grasp of the 'minimal marketable feature set' in the way they draft contracts - putting an early copy in front of the internal client as quickly as possible for discussion. They encourage people to consult early on their business challenge.

17. Cards for system improvement (including project work to build smarter ways of enabling clients to self-serve with template solutions and advice) are a different colour (green) and are fed into the overall weekly program. There is less of this 'templating' work done than was originally envisaged, as the team now focuses on coping with inevitable variation in work.

18. Unrealistic planning of long-term goals has been abandoned in favour of putting the team's energy into regular innovation of their processes and the system by which they get work done.

19. The outside legal partners worked within the team for several weeks to understand the new process, and are now utilized fully in that process.

20. Reporting to internal stakeholders is now reduced as they can drop by the team and see exactly where their work is prioritized on the board.

Other Lonely Planet teams who have the same operational parameters - individual specialists in a team situation, have picked up many of the innovations developed by the Legal Affairs team.

The team adopted these new work techniques with great enthusiasm and enjoyed mastering their own destiny. With coaching and support, the fundamental change to a lean way of working took less than 100 days, and their commitment to continuous improvement will likely return even greater results for customers going forward.

The team have grown their internal Net Promoter Score consistently, and most importantly of all, regularly head home early in the evening after highly productive working days. The focus on end-to-end process and the adoption of the final customer as their own customer (rather than a traditional shared service mentality with internal customer focus) resulted in about a 25% improvement in productivity overall for the team. This was reflected in the ability to absorb a reduced headcount in 2011, in a period where demand for the team's services was continuing to grow.
Our special thanks go to the Legal Affairs team and all the people who have worked on making this amazingly innovative work environment at Lonely Planet - Suyin, Chaman, Kate, Jasna, Naomi. We hold you in awe.

# data[].attributes.attachment_link.title
Lonely Planet Legal Affairs: smart people + lean work practices = innovation

# data[].attributes.attachment_link.description
BACKGROUND: KNOWLEDGE WORKERS AT THE SPEED LIMIT Lonely Planet's legal team are a fascinating example of the innovation of long-standing work practices that has infected Lonely Planet's Melbourne head office since 2008, where the techniques of agile have gone far beyond IT, and have been taken up by other knowledge workers in the 300 strong organisation, becoming inevitably lean along the way.

# data[].attributes.attachment_link.readable_text
Tune in to our podcast for the full story of how to use actionable behavior-changing tools that will build a business' digital core:

A Bank That Needed To Fundamentally Transform

"In 2009, Piyush Gupta takes over as the CEO of DBS. And he takes over a bank that's kind of lost. It has the lowest customer satisfaction scores in Singapore."

"Piyush looks around and he comes to a conclusion that the organization needs to fundamentally transform. No longer can it be a traditional bank where it's biased towards obligatory compliance. It has to function, in his words, like a 27,000 person startup."

The most important thing DBS did over the next 11 years, is to create a culture where everybody would think and act like they were working at a 27,000 person startup, changing people from sheep to wolves.

"And today (DBS) is an organization transformed. It is known globally as a digital and innovation powerhouse. "

"It became the first bank to simultaneously hold the three most prestigious awards related to being the best bank in the world, the best digital bank and so on."

Mojo Ritual: Unlocking The Startup Mindset

DBS identified 5 characteristics of what a 27,000 people startup looks like. "It's agile, it's a learning organization, it's collaborative, it's data-driven, it's experimental. Then they said, okay, what is it that stops us from following these behaviors? They pointed the finger at meetings."

"They ran surveys that found only 40% of people said that meetings were encouraging collaboration."

So in its Singapore home base, DBS introduced a meeting ritual called Mojo. 'Mo' stands for the Meeting Owner, and 'Jo' is the Joyful Observer. These two roles work together to run better meetings.

DBS ran a survey after introducing Mojo and found that 90% of meetings were now encouraging collaboration.

"DBS estimates that it saved a half million employee hours by having more effective, more efficient meetings."

Scott explains that the Mojo is essentially a BEAN - a behavior enabler, artifact, and nudge. "It is a way to overcome blockers that stop you from doing digitally oriented behaviors and encourages then those behaviors."

Find The Root Issue With A Glassdoor Analysis

DBS had built a Development Center in Hyderabad, part of DBS's effort to drive digitization to the core and own technology.

In 2011, despite having driven substantial transformation in Singapore, the slick new Development Center looked like the old DBS. The obligatory compliance DBS and not the new DBS. Developers were unhappy.

Why weren't people following the behaviors of a 27,000 people startup?

"This required detective work to really unearth. You ask people why they're not doing things. You often get superficial answers.

"So, we went and did a Glassdoor analysis, what were people saying in the words that they use to describe their experience? We had developers keep diaries to describe their day by day experience. We went and sat in the meetings to watch the way interactions were happening."

The Blockers: Lack Of Common Language And Hierarchy

First, there was a real lack of clear common language. People would talk past each other. People also hesitated to bring up problems because they didn't have a language to describe it.

The second thing: "Even though everyone worked at DBS, the people in Singapore were so used to working with tech vendors in India that they treated their colleagues in India like vendors. They called it order taker, order maker. It wasn't collaborative at all. They weren't working together to experiment and use data to solve problems. It was a very hierarchical relationship."

"Then finally, we saw that decisions clearly weren't being made by data. Decisions were being made by HiPPO's. If you don't know the acronym, that is the highest paid person's opinion. Again, the hierarchical effect seeped into the discussions and the behaviors weren't being followed."

Using BEANs To Plant Change

Having identified the ideal behaviors and the blockers, it was time to make the BEANs.

Team Tap: Every Monday morning, teams respond to an app that asks two questions: 'how are you feeling on a one to seven scale' and 'if you could pick one word to describe your feeling, what is it?'

"This is a way to encourage the candor and give a quick view about how people are feeling."

70-20-10: 70% of an employee's time is focused on doing the core of their job, 20% is about improving their job and 10% is time to experiment and do different things.

This helps to break the order taker/order maker mentality because it makes clear that you've got time specifically allowed to do other things.

Culture Canvas: A physical artifact that described team members, roles, what guard rails, common rituals, and things that they would do to be one team and so on.

This combatted this idea that decisions were made by HiPPO's, and the mindset of "I don't know what I can experiment around."

Where Does The Bean Tool Work?

"We think (the BEAN instrument) is a very widely deployable tool that you can use in many contexts."

However, there are two things you need in the environment:

Clarity: "Often where we see people screw up, they're not clear in their intent, they're not clear in the language."

Clear Connection Between Behavior And Strategy: The behaviors you want to encourage should be congruent with what your organization is trying to do.

Can Innovation Be Done In A Regulated Environment?

There is this idea that a startup moves fast, and breaks things. It is potentially dangerous for a bank to do that.

Scott brings an important caveat: "There are some kinds of failures, some kind of things that you can break, totally fine. There's other things that you can't break. You can't break the law. You can't break your backend systems. You can't break the things that are compliance related regulations. So, I think the key thing that DBS and any organization has to do is just define the circumstances, in which you can take risks, in which you can do different things in which it's okay to fail."

Tactics for Remotely Making Behavior Change

In times when most of us are working from home, " one of the things that organizations need: They need BEANs and they need them fast right now, because everybody is being forced to adopt new behaviors. So, the more that you can give people [...] the more it can help them with the massive habit change that the world is undergoing right now."

There are BEANs that can be applied in a digital setting. For example, DBS has one called 'Gandalf' scholarship. It grants employees funding to learn a new skill, with the only requirement that you teach it back to the organization. With long-distance courses and video recording and calling technology, this is possible even in a remote setting.

# data[].attributes.attachment_link.title
How Sheep Turned Into Wolves: The Transformation Of DBS

# data[].attributes.attachment_link.description
Tune in to our podcast for the full story of how to use actionable behavior-changing tools that will build a business' digital core: "In 2009, Piyush Gupta takes over as the CEO of DBS. And he takes over a bank that's kind of lost. It has the lowest customer satisfaction scores in Singapore."

# data[].attributes.attachment_link.readable_text
In Amazon's 2017 letter to shareholders, CEO Jeff Bezos tackled the question "What does Day 2 look like?" According to Bezos, "Day 2 is stasis. Followed by irrelevance. Followed by excruciating, painful decline. Followed by death. And that is why it is always Day 1." Bezos' thoughts on corporate mortality are substantiated by recent research finding that companies listed on the Fortune 500 from 2000 to 2009 had only a 63 percent chance of survival. ¹ The primary reasons for their failure were inflexible, non-agile business models and the lack of innovation. Thus, Bezos' provocative shareholder letter comment was a call to all Amazon employees to stave off Amazon's potential demise, maintain its Day 1 startup culture, and continue to launch innovative products and services.

In fact, customer obsession and quick decision-making are key to avoiding organizational stasis and are essential for maintaining Amazon's unique Day 1 culture. These two factors have enabled Amazon to rapidly go-to-market with its innovative products and services. Cameron and Quinn's Competing Values Framework ² would describe Amazon's Day 1 as an adhocracy culture type that is flexibly structured and externally focused on customers. Companies with an adhocracy culture value growth, variety, and stimulation, which encourage risk-taking, creativity, and agile ways of working. Compared to Day 1, Day 2 organizations are described as: (1) being too focused on following organizational processes even if the outcome is undesirable to the customer; (2) unable to quickly embrace external trends (e.g., cloud computing and artificial intelligence); (3) managing to proxies (e.g., using market research as a proxy for customers); and (4) making slow decisions. ³ A Day 2 culture would be described by Cameron and Quinn as hierarchical, focusing internally on stability, control, and efficiency and valuing routine, formality, and consistency. See Table 1 for characteristics describing Day 1 versus Day 2 companies.

There are numerous empirical linkages between organizational culture type and organizational effectiveness, with a Day 1 culture as the most predictive of product innovation and team creativity. ⁴ A hierarchical culture type has little success when it comes to innovative output.

As startup organizations grow exponentially in size and complexity, how do their leaders and teams make the right decisions quickly to build customer-obsessed products and services while remaining Day 1? What is the optimal team organizational design for accelerating high-velocity decision-making and innovation? These are just some of the questions that Amazon and other high-growth startup companies face every day as they work to remain relevant and avoid organizational stasis. Having a Day 1 strategy alone is not sufficient for increasing innovation. Organizations must also have the right organizational structures and agile practices in place to facilitate customer obsessed teams and high-velocity decisions that subsequently result in risk-taking and quick implementation of creative ideas. ⁵

Amazon's Agile Team Design

With rapid changes across technology, regulations, demand, and external trends, it is critical for companies to respond and adapt quickly in order to innovate faster than their peers. Companies are more likely to be successful staying close to their customers and adapting to changing conditions if they use flexible, agile team structures. ⁵ Agile teams are small and composed of multidisciplinary employees (defined as employees in job families outside of their own and generally includes tech and non-tech employees) who break up large, complex problems into manageable modules and build solutions for each component that are then integrated into a comprehensive whole. ⁶ Amazon has adapted a nimble "two-pizza team" structure to stay close to the customer, avoid distractions and competing priorities, and make quick decisions. The two-pizza team model is exactly what it sounds like-no team should be larger than what two pizzas can feed (about six employees). This implies that if a team is empowered to innovate and problem-solve on their own, they will be more successful in the long run.

Various studies have supported that smaller, agile teams (usually four to six employees) innovate more and make quicker decisions ⁷ compared to larger teams. The advantages of smaller teams can be attributed to higher levels of employee motivation and enhanced coordination. ⁸ As teams get larger, employees feel less motivated and responsible for the output. ⁷ Furthermore, coordination among team members increases for every member added since it requires understanding how to gather information in an organized efficient way. ⁹ Acknowledging the downsides of large teams, the two-pizza team is designed to optimize for the most efficient work flow from a small, closely integrated group of employees.

McKinsey & Company conducted a survey across a full range of companies, industries, and sizes to understand various characteristics and outcomes of organizations leveraging agile teams. ⁵ More than 80 percent of respondents from agile organizations developed new products and services by having close interaction with their customers and field-testing new ideas and prototypes quickly to gather data and rapidly improve the product. Those leveraging an agile team design and practices were 1.5 times more likely to financially outperform others and 1.7 times more likely outperform their peers on nonfinancial measures.

Managing Single-Threaded Organizations with Two-Pizza Teams

A Single-Threaded Owner (STO) is a leader responsible for managing one or more two-pizza teams and protecting them from distractions. The STO approach guarantees that at least one person at Amazon will wake up every day trying to drive a single critical initiative forward without competing priorities. STOs also act as a bridge to larger organizational efforts. Amazon uses an annual strategic and operational planning process for teams to describe critical investments and goals for the upcoming year and the associated required resources. Coming out of the process, team goals are created that align to overall priorities for the organization. This process provides senior leadership visibility to proposed key investments. Because the business moves so quickly, Amazon uses weekly, monthly, and quarterly business reviews; roadmap reviews; and program reviews for STOs to audit against deliverables and update their plans. For example, individual teams will set goals that map to their development cadence (e.g., monthly, quarterly) and the STO conducts audits against these goals in the rhythm of the business. These mechanisms allow STOs to understand work required and allow independent, autonomous progress against key efforts. STOs also understand higher level organizational goals and are free to make the right tactical decisions on their own. Additional mechanisms ensure that teams are delivering the right results at a consistently high bar.

Evaluating Amazon's Agile Team Structures

STO and two-pizza team organizational structures are not always perfect. As a result, Amazon continuously evaluates their organizational designs and the impact of the team structures on execution speed and innovation. The Amazon Devices organization, responsible for building products such as Alexa, FireTV, Kindle, and other Amazon products, uses organizational network analysis (ONA) to inspect and audit its team structures. ONA is a way to visualize how communications, information, and decisions flow in an organization by analyzing the informal employee relationships. ¹⁰ ONA results pinpoint strengths and potential opportunity areas through team collaboration and coordination. Amazon has used ONA to identify decision-making bottlenecks, unnecessary dependencies, and untapped expertise to improve decision-making speed and collaboration for innovation. When assessing innovation collaboration, Amazon used ONA to identify development connections. Development connections develop locally and refine big ideas so that they can be brought to life as prototypes, concepts, and solutions. ¹¹

A few recent ONA studies were conducted within the Amazon Devices organization to ensure teams were operating efficiently, maintaining Amazon's Day 1 culture, and making high-velocity decisions. The purpose of the ONA was to understand how STOs make decisions and identify barriers that stand in their way of making smart and fast decisions and that lead to innovation. A short survey was administered to employees in several organizations within Amazon Devices to gather ONA data on decision-making and innovation. Sample ONA questions included:

List a maximum of 10 people within the (X Devices Organization) reporting to (Y Leader) that you most frequently contact for sign off/reviews before making a decision necessary for execution.

List a maximum of 10 employees that you frequently turn to in order to gain input, direction, or to discuss a new or innovative idea within the (X Devices Organization) reporting to (Y Leader).

Which of the following has a significant impact on your team's ability to deliver results faster? Select all that apply: (1) too many approvals; (2) difficult to align on priorities: (3) documents (emails, PR/FAQs); (4) errors/re-work; (5) meetings.

Findings revealed positive insights about the STO organizational structure in which STOs were operating with little to no dependencies on other teams when developing new ideas (i.e., the intended organizational design). STOs were also acting as bridges across teams in the organization as a way to manage across organizational-wide efforts, while protecting their team (i.e., development connections) from distractions (see Figure 1). Barriers to STO teams moving fast were also identified as seen in Figure 2, with too many meetings, challenges obtaining approvals, and aligning on priorities. As a result, one specific action by all teams was to identify and eliminate unnecessary meetings and streamline approval processes, which resulted in quicker decision-making. STO leaders also met across teams to further align on priorities through their weekly business review process.

The ONA data helped leaders of Amazon Devices identify a few highly utilized employees who could potentially be bottlenecks in the network as well as underleveraged employees. All of the ONA data was analyzed to load balance decision-making and collaboration for innovation development, and to build the right mechanisms to improve fast decision-making. In sum, ONA was an effective tool for assessing overall Day 1 organizational health to ensure the right informal team structures were in place to make high-velocity decisions and increase innovation development. The ONA data helped identify the right interventions to double-down on current strengths and address various opportunities to develop new innovations on behalf of customers.

Mechanisms and Adaptive Practices for Inventing and Simplifying at Amazon

Arena and Uhl-Bien ¹² describe how organizations become and remain adaptive through adaptive space. In the ONA findings discussed earlier, even Amazon's agile-designed organizations require inspection and intervention to ensure employees' creative energy is not stifled by the larger organizational system. Outside of formal organizational structures, Amazon uses various adaptive practices ¹¹ to enable "Think Big" interactions in order to address complex problems that are difficult to address without creating adaptive space.

A signature adaptive practice Amazon uses to identify and solve customer needs is encapsulated in Amazon's Working Backwards process. Before assigning budget to any new initiative, teams at Amazon test the idea by writing a press release, a set of FAQs, and even a product manual as if the product has already launched. The press release is a one-page narrative that uses customer-centric language to explain how the new product would look to the customer. It is written before building starts to confirm that the solution is the right thing to work on and to refine ideas.

With the press release, writers look into the future and imagine what they want a customer to experience and ideally, what they want them to say at launch. It is written for the customer and focuses on the customer experience. The press release also includes quotes from Amazon business leaders talking about the benefits of the new product. It takes a lot of hard work and collaboration to write a good press release, but Amazon has found it to be incredibly effective at testing ideas-building an enduring vision of the product or feature. Something really interesting happens during the Working Backwards process. The moment Amazon leaders sit down and start interacting with a press release, the idea evolves. The goal is not to get approval for the idea, but test its quality and make it better. Is it really customer-centric? Is this the right thing to pursue? Amazon is more interested in getting to the right answer than in getting buy-in on the proposal. The press release will go through multiple iterations with the goal to refine thinking and find the best customer-focused, innovative path forward. Only then does the team begin to invest in headcount or roadmap changes to build on the idea.

Amazon also uses FAQs to channel its customers and stakeholders to define how something will work and how best to execute. The press release describes the essence of the idea whereas FAQs describe the details. Solid FAQs uncover risk and help decide if a project is the right investment because big or small, every project is an investment. Virtually every product and innovation that Amazon has launched in the past 15 years-from Amazon Prime to Frustration-Free Packaging to Alexa and the Kindle e-reader-have started out with press releases and FAQs.

Like other companies, Amazon has adopted hackathons (i.e., co-labs) to combat business-as-usual thinking. Amazon hackathons vary in duration and purpose. Some run for a few hours, but the most common format is a day-long competition where people team up to invent and quickly prototype solutions to enduring problems or find novel ways to use existing systems and data. Participants then vote for their favorite solution, and awards are handed out to the winning teams. Hackathons not only generate new ideas for the hosting team, but they provide a sense of community for participants. Some example ideas developed from hackathons include a novel configuration of AWS services to prototype an automated hard-hat detection system for construction sites and an automated career growth planning tool for stronger career conversations.

While hackathons are effective for innovating on existing problems, grand scale invention often needs a different platform-one that is unconstrained by current project teams or lines of work. One of the adaptive practices Amazon has employed to foster this type of invention is a two-and-a-half day technology conference (i.e., adaptive summit). This is an annual gathering of technologists from across Amazon using Open Space Technology methodology to drive the agenda. On the first day, all participants are invited to propose sessions on any theme-related topic about which they're passionate, with some guidance from conference organizers and senior Amazon technologists. On the second day, participants vote to converge on a subset of Day 1 topics to further problem-solve; these sessions are hosted by experienced moderators to foster quality discussions and drive the innovation process. At the end of the second day, participants vote on the top three innovations to be converted into detailed organizational-level project proposals and presented to senior leadership.

Over the years, topics discussed at the conferences have included, "What happens when everyone has a 3D printer in their home?" and "The Age of Thought Computing." The conference has also been the source of many new product ideas including a long-term AWS storage data archive and using computer vision in fulfillment centers-a predecessor to the Amazon Go store.

Conclusion

To address the hard problems that are difficult to solve in the larger organizational system, Amazon has created adaptive space ¹¹ and used various adaptive practices. ₁₂ Some example Amazon practices include its Working Backwards process (i.e., press release, FAQs, etc.), hackathons, and adaptive summits, which result in multiple creative ideas evolving into customer-focused, innovative, revenue-generating products and services.

The lifespan of corporate existence has been shortening ¹ and competition is Darwinian. The fittest organizations with chances for survival are adaptive, agile, and flexible to the changing needs of customers, technology, regulations, demand, and external trends. Consequently, agile organizations have the ability to innovate on behalf of their customers. Organizations that foster adhocracy produce the most innovation as compared to organizations with other culture types. ³ Nevertheless, organizational culture is a strong, stable phenomenon that is difficult to change by leaders ¹³ so organizations should foster adhocracy in order for leaders to successfully innovate. ¹⁴

Amazon's two-pizza team and STO organizational structures (i.e., agile structures) are designed so that employees stay close to Amazon customers, make high-velocity decisions, and avoid distractions and competing priorities. Multiple studies have supported that smaller, agile teams quickly produce more innovation. 7 Amazon STOs manage two-pizza teams by acting as a bridge across organizational boundaries and using the right mechanisms to audit and inspect deliverables while delivering right results with a high bar. Amazon has leveraged ONA to inspect their organizational designs and ensure teams are making high-velocity decisions and producing innovation. ONA findings helped identified strengths, opportunity areas, and interventions for staying Day 1.

HR Professional Applications

The following are practical applications for HR professionals to consider for helping their business make Day 1 a repeatable and embedded element of their organizational culture:

Assess and address organizational culture. Organizations require innovation to survive and the culture to support innovation. HR professionals should consider using Cameron and Quinn's² 24-item Organizational Culture Assessment Instrument, a valid measure of organizational culture, to determine their organization's current and desirable culture. If an organization has low levels of Day 1 culture, HR professionals could partner with their business by realigning their organization's culture. Denham and Kaberon¹⁵ suggests using a Frame Stretching (FS) technique to help with making the cultural shift. FS helps leaders change their organization's current frame with a new frame-of-reference so that leaders can reimagine their current situation and potential.

Consider implementing agile team structures and STOs. HR professionals could partner with business leaders by starting small, launching a few agile teams, and gathering data to determine the agile team value and constraints faced.⁶ Determine if increasing team agility gets employees closer to the customer, increases innovation, and delivers positive financial results. Then scale up agility in other parts of the organization if benefits outweigh costs. It is also recommended that HR professionals partner with the business to design or identify STO roles in the agile teams. Below is a checklist to ensure single-threaded ownership:

Are they responsible for only one thing (program, product, platform, feature, or service)?

Are they able to make all/most of the decisions regarding the one thing they're responsible for (absent of corporate/product priorities)?

Do they have a direct reporting relationship with all of the headcount required to execute the work?

Continuously evaluate organizational structures. HR professionals could partner with business leaders to assess the extent to which employees are making high-velocity decisions and are producing innovative products and services. They can use ONA as a tool to identify strengths, opportunity areas, and interventions for increasing execution speed, creating adaptive space, and appropriately leveraging talent.

Implement adaptive practices. Business leaders should find adaptive space opportunities and implement adaptive practices¹² to foster a climate of creativity and produce high-quality creative ideas with the help from their HR partners. They could start small with hackathons and then spread more larger-scale practices (e.g., adaptive summits, mechanisms to get closer to the customer) across the organization.

Beth Galetti is Senior Vice President of Worldwide Human Resources for Amazon. John Golden III, Ph.D., is Head of Devices Talent and Leadership Development at Amazon. He can be reached at goldenj@amazon.com. Stephen Brozovich is Head of AWS Talent Management at Amazon. He can be reached at sbroz@amazon.com.
1 George, P. (2016). The scary truth about corporate survival. Harvard Business Review, December, 24-25.

2 Cameron, K.S., & Quinn, R.E. (1999). Diagnosing and changing organizational culture: Based on the competing values framework. Reading, MA: Addison-Wesley.

3 Amazon Corporate (2017). 2016 Letter to Shareholders. Retrieved from https://ir.aboutamazon.com/static-files/e01cc6e7-73df-4860-bd3d-95d366f29e57

4 Hammond, M.M., Neff, N.L., Farr, J.L., Schwall, A.R., & Zhao, X. (2011). Predictors of individual-level innovation at work: A meta-analysis. Psychology of Aesthetics, Creativity, and the Arts, 5, 90-105.

5 Ahlback, A., Fahrback, C., & Murarka, M., Salo, O., (2017). How to create an agile organization. Retrieved from https://www.mckinsey.com/business-functions/organization/our-insights/how-to-create-an-agile organization

6 Rigby, D., Sutherland, J. & Noble, A. (2018). Agile at Scale. Harvard Business Review, May-June, 88-96.

7 de Rond, M. (2014). Why less is more in teams. Harvard Business Review Onpoint, Spring, 13-14.

8 Steiner, I. (1972). Group process and productivity. New York, NY: Academic Press.

9 Mueller, J. (2011). Why individuals in larger teams perform worse. Organizational Behavior & Human Decision Process, 117, 111-124.

10 Cross, R., & Parker, A. (2004). The Hidden Power of Social Networks: Understanding How Work Really Gets Done in Organizations. Boston, MA: Harvard Business Review Press.

11 Arena, M. (2018). Adaptive Space: How GM and Other Companies are Positively Disrupting Themselves and Transforming into Agile Organizations. New York, NY: McGraw-Hill Education.

12 Arena, M. & Uhl-Bien, M. (2016). Complexity leadership theory: Shifting from human capital to social capital. People + Strategy, 39, 22-27.

13 Hogan, S.J., & Coote, L.V. (2014). Organizational culture, innovation, and performance: A test of Schein's model. Journal of Business Research, 67, 1609-1621.

14 Golden, J. & Shriner, S. (2017). Examining relationships between transformational leadership and employee creative performance: The moderator effects of organizational culture. Journal of Creative Behavior, October.

15 Denham, J., & Kaberon, R. (2012). Culture is king: How culture contributes to innovation. Journal of Product Innovation Management, 29, 358-360.

16 Ingham, A. G., Levinger, G., Graves, J., & Peckham, V. (1974). The Ringelmann effect: Studies of group size and group performance. Journal of Experimental Social Psychology, 10, 371-384.

# data[].attributes.attachment_link.authors[].name
Beth Galetti, John Golden III, and Stephen Brozovich

# data[].attributes.attachment_link.title
Inside Day 1: How Amazon Uses Agile Team Structures and Adaptive Practices to Innovate on Behalf of Customers

# data[].attributes.attachment_link.description
In Amazon's 2017 letter to shareholders, CEO Jeff Bezos tackled the question "What does Day 2 look like?" According to Bezos, "Day 2 is stasis. Followed by irrelevance. Followed by excruciating, painful decline. Followed by death. And that is why it is always Day 1."

# data[].attributes.attachment_link.readable_text
To endure such turbulent times, AirAsia recognized the importance of being agile and holistic at managing risk

With its huge wealth of data, AirAsia expanded its business to be more than just an airline, in a bid to outlast the pandemic

AirAsia Digital president Aireen Omar shares lessons for SMEs to adapt and survive the pandemic

Even among the sectors most hard-hit by Covid-19, one of the industries affected considerably worse than most has been the aviation space. Indeed, there was less than half the passenger traffic in the whole of 2020 than in 2019. For Southeast Asia's favorite low-cost carrier AirAsia, it has been disrupting the airline industry since its 2001 inception, and the pandemic-caused setbacks were an opportunity to speed up its digital transformation and pivot its business to something more than just an airline.

Following the widespread global lockdowns beginning March 2020 that have brought the air industry to a virtual standstill, the overall number of flight passengers by last April had already plummeted 92% from 2019 levels. There was a 98% average drop-off rate in international travel traffic and an 87% average fall in domestic air travel, according to data from the International Civil Aviation Organization (ICAO).

Seating capacity fell by around 50% for the whole of last year, which left just 1.8 billion passengers taking flights through 2020, compared with around 4.5 billion in 2019. That added up to a staggering financial loss to the industry of around US$370 billion, "with airports and air navigation services providers losing a further US$115 billion and US$13 billion, respectively", ICAO said.

To rise to the challenges of running an airline during a global pandemic, decided to focus on developing its and other non-passenger airline businesses. AirAsia Digital president Aireen Omar reckons the "the silver lining is that the pandemic presented the airline with the opportunity to fast track its digital and non-airlines businesses that has actually kickstarted way before the pandemic."

Tech Wire Asia had the opportunity to discuss with Aireen how the low-cost airline thought outside-the-box to reinvent itself and stay afloat amid the worst global crisis yet.

Data - the new gold for AirAsia

To Aireen, AirAsia's competitive advantages were in the low-cost carrier's gargantuan data pool and coupled with the foresight to transform their digital ecosystem, which gave the Group a significant advantage over its competitors when the pandemic unexpectedly struck in Q1 2020.

"Our digital transformation exercise actually started way before the Covid-19. It happens when we realize that we have a good wealth of data in our whole ecosystem which is not just data from our airline passengers' booking system and their behavior on how they use the web and mobile app, but we also have a large pool of data involving all the movements and the operations of our aircraft. So we're sitting on a huge wealth of data, which we thought could turn us into more than just an airline," she added.

The data that AirAsia had also allowed it to become more cost-efficient from the way the carrier consumes fuel to how it could replace work with algorithms and machine learning. "It is also about how we use data for a seamless experience, not just for the consumer but also for the workforce. The journey in fact started way before this Covid situation and as a result, the idea of AirAsia Digital was born because we thought that people could relate better."

Previously known as RedBeat Venture, AirAsia Digital was launched in 2018 as the digital venture arm of AirAsia Group. By using the data to gain further insights into its customers, Aireen said AirAsia has been able to create other relevant products and personalized offerings through the same platform and cross-sell beyond the travel space.

Turning AirAsia into a digital airline

In October last year, the airline's official online ticketing platform - airasia.com - underwent a major transformation and has expanded to offer various products and services. The application, coined as a ' super app' by the AirAsia Group, now includes an ecosystem of new services including food delivery, grocery delivery, and even online shopping, in addition to the usual listing of flight tickets and hotel rooms.

On the other hand, AirAsia's digital payment service, called BigPay, has 1.2 million users and offers money transfers, with remittances available in 10 countries including Singapore. So then the other two businesses are more financial services. "We aim to be a digital asset bank because of the licenses that we have obtained so far. So we have e-money, remittances, and lending licenses in Malaysia," stated Aireen. "We hope to be able to launch our lending product as soon as this year."

The company is also hoping to get lending licenses in Singapore and the rest of ASEAN countries like Thailand, the Philippines, and Indonesia, between this year and next. As for BIG Rewards, one of Southeast Asia's largest travel and lifestyle rewards platforms with over ​35 million members, it evolved from an airline loyalty program to a broader lifestyle rewards service, offering points redemption on a range of dining, shopping and entertainment deals.

AirAsia has also expanded into other F&B verticals such as the Santan Kitchen which will gradually take over the production of Santan meals as well as provide cloud kitchen space for aspiring F&B entrepreneurs and "OurFarm", a farm-to-table (F2B) platform that connects businesses directly to producers supported by AirAsia's comprehensive ecosystem.

Adapting to post-Covid reality and recognizing customers' preference for home delivery orders, AirAsia's cargo and logistics division Teleport pivoted once more to concentrate on last-mile deliveries, transporting parcels, restaurant orders, and fresh produce from AirAsia shop, AirAsia food, and AirAsia fresh. Teleport now has over 5,000 delivery partners, with deliveries available across 70 cities, making them a major Southeast Asian e-commerce transportation provider.

Lessons for SMEs

For businesses to make it through the pandemic, especially for small and business enterprises, Aireen believes there are a few steps that can be taken from having an open mind, to understanding the business' current demand, as well as not losing out on digital transformation.

"It is best to always have an open mind and you must be agile because anything can happen along the way. Secondly, entrepreneurs need to understand where the current demand and business operations are. We have to accept that things will never go back to pre-Covid days because people's behavior changes, so we need to know how to go about meeting those new demands and seize the opportunities available.

"And I suppose the third aspect is to never lose sight, especially in this digital world. Never underestimate what data can do for you and do not be too focused on the bottom line as accumulating certain data helps us to understand what we can do better in order to expand and gain bigger returns in the long term," she added.

The AirAsia Digital president also naturally emphasized the importance of digital skills. "I think the biggest challenge got to do with talent resources, like how do I get good talent and not overpay for it. Because there' is really no point in becoming a digital-savvy corporation in a digital economy but the rest of your force isn't well equipped with the talent and skills."

That was the idea behind , where AirAsia Digital partnered with Google Cloud as part of combined efforts to enhance digital skills at a national level. First launched to RedBeat Academy up-skill and cross-train AirAsia employees, the training program is now open to the wider public with a specific focus on artificial intelligence, machine learning and software engineering, alongside cybersecurity, big data, and infrastructure technologies.

# data[].attributes.attachment_link.title
How AirAsia pivoted its airline business to survive a pandemic

# data[].attributes.attachment_link.description
To endure such turbulent times, AirAsia recognized the importance of being agile and holistic at managing risk With its huge wealth of data, AirAsia expanded its business to be more than just an airline, in a bid to outlast the pandemic AirAsia Digital president Aireen Omar shares lessons for SMEs to adapt and survive the pandemic Even among the sectors most hard-hit by Covid-19, one of the industries affected considerably worse than most has been the aviation space.

# data[].attributes.headline
Batman, Iron Man, Wolverine, and the Avengers (8 min.)

# data[].attributes.subject
Batman, Iron Man, Wolverine, and the Avengers (8 min.)

# data[].attributes.attachment_link.readable_text
Superheroes were everywhere at the Agile Singapore Conference.

At Hotel Fort Canning, one could not escape the official t-shirts -four designs inspired by Batman, Iron Man, Wolverine, and the Avengers, representing the four pillars of Agility.

And the audience heard about the almost superhuman background of how a brand new Government agency came about.

Much like the Avengers or the Justice League, the origin story of the Government Technology Agency (GovTech) of Singapore brings together a group of people with the right abilities to solve real-world problems with technology.

GovTech is heralding a new era for the Singapore Government as a new organisation that embraces the Agile movement, a set of principles originally used in software development and now being adapted as a new way of working for organisations all over the world.

"The ability to morph and keep adapting to situations is important; because of that, we can pivot very quickly," said Mr Chan Cheow Hoe, the Deputy Chief Executive Officer of GovTech and also the Government's Chief Information Officer, at the Conference launch on 6 October 2016.

An Agile journey

The journey towards GovTech included creating a skunkworks team.

"In the beginning, I found that nobody in the government can code," Mr Chan said, explaining how among 1,000 staff, he only managed to find seven individuals he could pull together to form a coding team for cutting-edge projects.

These seven were regularly carrying out skunkworks projects, which refer to projects developed by small groups with the intent of pushing the envelope of innovation.

They became the pioneering members of the Government Digital Services (GDS) unit of GovTech.

"I told them, 'You are the new future'," Mr Chan recalled.

The GDS team's homebase slash lab is known as Hive, housed within the Sandcrawler building in Fusionopolis.

But Mr Chan shared that the team almost had to comb the desert for another location.

"The Sandcrawler management said that we only have creative guys like Lucasfilm and Industrial Light & Magic leasing with us. We spent quite a bit of time convincing them not to worry, that the Government can be cool like them," he said with a laugh.

The argument worked, and today, there are about 120 highly committed and inspired people keeping the buzz high at the Hive.

Trust in the agency's abilities was another issue to contend with in those early days.

"Initially, there was some doubt within the Government. A senior leader once came to up to me and said, 'What these guys can do, can be done by a polytechnic student. What's the big deal?'" Mr Chan shared.

"But the group proved that it could deliver some really outstanding stuff over the period of just a year and a half."

GovTech's portfolio is a vast and varied one that includes many tasks: supporting many fellow Government agencies on the ICT front , procuring ICT equipment for the Government, developing digital Government services like the Business Grants Portal, and also apps like the lifesaving myResponder - co-developed with the Singapore Civil Defence Force, the app crowdsources for CPR-trained volunteers and responders when someone has a suspected heart attack.

According to Mr Chan, the organisation stands out in that it was able to create not just the technology, but also the process and most importantly, the culture.

"Then, there is the Agile part of it, which is getting more and more interesting," he said.

"To me, this is an experiment not just in technology, but also in organisational development and management."

Culture of Collaboration

His desire to learn more about agility in organisations took him to the United States, where he learned about Holacracy, a self-management system that replaces the management hierarchy a new peer-to-peer 'operating system'.

In traditional companies, each person has exactly one job; managers' decisions always trumps others; and organisations are mandated from the top.

But in Agile companies, job roles are dynamic and defined around the work or project; authority is distributed among team members; and organisational structure is constantly updated, with each team being self-organising as well.

This new way of working allows companies to become more transparent, accountable, and agile.

GovTech's approach is evident from its three main values, which are now emblazoned in bright colours on official GovTech t-shirts: Agile, Bold and Collaborative.

"Being Agile is about being able to pivot; being flexible about doing things. It's also about being bold and having the courage to experiment," Mr Chan explained.

"And most importantly, no one person can make it happen. The collaborative culture is imbued into our organisation, and many of our people join us for that."

In addition, GovTech offers an "overlapping service of capabilities".

The GDS team is a microcosm of that.

"We started off with a small group of software engineers, but soon the team realised that user experience (UX) is important. So we started a UX group. Then, we said that data is very important, so we started a data science group," Mr Chan said.

Groups for both application infrastructure and Internet of Things (IoT) soon followed.

At the end of the day, GovTech strives to be more than just a government agency for technology and digital services; it is an example of how organisations can succeed with a different mindset.

"It's about what impact you have on citizens if you are serious about solving problems," Mr Chan remarked.

"The empowerment is there-we have taken out a lot of bureaucracy. Many people question whether Agile will work in government and I can tell you, it does."

"We have made it happen."

https://www.tech.gov.sg/media/technews/as-agile-as-govtech

# data[].attributes.attachment_link.description
Superheroes were everywhere at the Agile Singapore Conference. At Hotel Fort Canning, one could not escape the official t-shirts -four designs inspired by Batman, Iron Man, Wolverine, and the Avengers, representing the four pillars of Agility. And the audience heard about the almost superhuman background of how a brand new Government agency came about.

# data[].attributes.attachment_link.title
Spotify Engineering Culture (by Henrik Kniberg)

# data[].attributes.attachment_link.readable_text
Established businesses around the world and across a range of sectors are striving to emulate the speed, dynamism, and customer centricity of digital players. In the summer of 2015, the Dutch banking group ING embarked on such a journey, shifting its traditional organization to an "agile" model inspired by companies such as Google, Netflix, and Spotify. Comprising about 350 nine-person "squads" in 13 so-called tribes, the new approach at ING has already improved time to market, boosted employee engagement, and increased productivity. In this interview with McKinsey's Deepak Mahadevan, ING Netherlands chief information officer Peter Jacobs and Bart Schlatmann, who, until recently, was the chief operating officer of ING Netherlands, explain why the bank needed to change, how it manages without the old reporting lines, and how it measures the impact of its efforts.

The Quarterly: What prompted ING to introduce this new way of working?

Bart Schlatmann: We have been on a transformation journey for around ten years now, but there can be no let up. Transformation is not just moving an organization from A to B, because once you hit B, you need to move to C, and when you arrive at C, you probably have to start thinking about D.

In our case, when we introduced an agile way of working in June 2015, there was no particular financial imperative, since the company was performing well, and interest rates were still at a decent level. Customer behavior, however, was rapidly changing in response to new digital distribution channels, and customer expectations were being shaped by digital leaders in other industries, not just banking. We needed to stop thinking traditionally about product marketing and start understanding customer journeys in this new omnichannel environment. It's imperative for us to provide a seamless and consistently high-quality service so that customers can start their journey through one channel and continue it through another-for example, going to a branch in person for investment advice and then calling or going online to make an actual investment. An agile way of working was the necessary means to deliver that strategy.

The Quarterly: How do you define agility?

Bart Schlatmann: Agility is about flexibility and the ability of an organization to rapidly adapt and steer itself in a new direction. It's about minimizing handovers and bureaucracy, and empowering people. The aim is to build stronger, more rounded professionals out of all our people. Being agile is not just about changing the IT department or any other function on its own. The key has been adhering to the "end-to-end principle" and working in multidisciplinary teams, or squads, that comprise a mix of marketing specialists, product and commercial specialists, user-experience designers, data analysts, and IT engineers-all focused on solving the client's needs and united by a common definition of success. This model [see exhibit] was inspired by what we saw at various technology companies, which we then adapted to our own business.

The Quarterly: What were the most important elements of the transformation?

Peter Jacobs: Looking back, I think there were four big pillars. Number one was the agile way of working itself. Today, our IT and commercial colleagues sit together in the same buildings, divided into squads, constantly testing what they might offer our customers, in an environment where there are no managers controlling the handovers and slowing down collaboration.

Number two is having the appropriate organizational structure and clarity around the new roles and governance. As long as you continue to have different departments, steering committees, project managers, and project directors, you will continue to have silos-and that hinders agility.

The third big component is our approach to DevOps and continuous delivery in IT. Our aspiration is to go live with new software releases on a much more frequent basis-every two weeks rather than having five to six "big launches" a year as we did in the past. The integration of product development and IT operations has enabled us to develop innovative new product features and position ourselves as the number-one mobile bank in the Netherlands.

Finally, there is our new people model. In the old organization, a manager's status and salary were based on the size of the projects he or she was responsible for and on the number of employees on his or her team. In an agile performance-management model, there are no projects as such; what matters is how people deal with knowledge. A big part of the transformation has been about ensuring there is a good mix between different layers of knowledge and expertise.

The Quarterly: What was the scope of this transformation? Where did you start, and how long did it take?

Bart Schlatmann: Our initial focus was on the 3,500 staff members at group headquarters. We started with these teams-comprising previous departments such as marketing, product management, channel management, and IT development-because we believed we had to start at the core and that this would set a good example for the rest of the organization.

We originally left out the support functions-such as HR, finance, and risk-the branches, the call centers, operations, and IT infrastructure when shifting to tribes and squads. But it doesn't mean they are not agile; they adopt agility in a different way. For example, we introduced self-steering teams in operations and call centers based on what we saw working at the shoe-retailer Zappos. These teams take more responsibility than they used to and have less oversight from management than previously. Meanwhile, we have been encouraging the sales force and branch network to embrace agility through daily team stand-ups and other tactics. Functions such as legal, finance, and operational risk are not part of a squad per se, as they need to be independent, but a squad can call on them to help out and give objective advice.

It took about eight or nine months from the moment we had written the strategy and vision, in late 2014, to the point where the new organization and way of working had been implemented across the entire headquarters. It started with painting the vision and getting inspiration from different tech leaders. We spent two months and five board off-sites developing the target organization with its new "nervous system." In parallel, we set up five or six pilot squads and used the lessons to adapt the setup, working environment, and overall design. After that, we were able to concentrate on implementation-selecting and getting the right people on board and revamping the offices, for example.

The Quarterly: Was agility within IT a prerequisite for broader organizational change?

Peter Jacobs: Agility within IT is not a prerequisite for a broader transformation, but it certainly helps. At ING, we introduced a more agile way of working within IT a few years ago, but it was not organization-wide agility as we understand it today, because it did not involve the business. You can certainly start in IT and gradually move to the business side, the advantage of this being that the IT teams can test and develop the concept before the company rolls it out more widely. But I think you could equally start with one value stream, let's say mortgages, and roll it out simultaneously in the business and in IT. Either model can work.

What you can't do-and that is what I see many people do in other companies-is start to cherry pick from the different building blocks. For example, some people formally embrace the agile way of working but do not let go of their existing organizational structure and governance. That defeats the whole purpose and only creates more frustration.

The Quarterly: How important was it to try to change the ING culture as part of this transformation?

Bart Schlatmann: Culture is perhaps the most important element of this sort of change effort. It is not something, though, that can be addressed in a program on its own. We have spent an enormous amount of energy and leadership time trying to role model the sort of behavior-ownership, empowerment, customer centricity-that is appropriate in an agile culture. Culture needs to be reflected and rooted in anything and everything that we undertake as an organization and as individuals.

For instance, one important initiative has been a new three-week onboarding program, also inspired by Zappos, that involves every employee spending at least one full week at the new Customer Loyalty Team operations call center taking customer calls. As they move around the key areas of the bank, new employees quickly establish their own informal networks and gain a deeper understanding of the business.

We have also adopted the peer-to-peer hiring approach used by Google. For example, my colleagues on the board selected the 14 people who report to me. All I have is a right of veto if they choose someone I really can't cope with. After thousands of hires made by teams using this approach at every level in the organization, I have never heard of a single veto being exercised-a sure sign that the system is working well. It's interesting to note, too, that teams are now better diversified by gender, character, and skill set than they were previously. We definitely have a more balanced organization.

A lot is also down to the new way we communicate and to the new office configuration: we invested in tearing down walls in buildings to create more open spaces and to allow more informal interaction between employees. We have a very small number of formal meetings; most are informal. The whole atmosphere of the organization is much more that of a tech campus than an old-style traditional bank where people were locked away behind closed doors.

The Quarterly: Was a traditional IT culture an impediment to the transformation?

Peter Jacobs: In IT, one of the big changes was to bring back an engineering culture, so there's now the sense that it's good to be an engineer and to make code. Somehow over the years, success in IT had become a question of being a good manager and orchestrating others to write code. When we visited a Google IO conference in California, we were utterly amazed by what we saw and heard: young people talking animatedly about technology and excitedly discussing the possibilities of Android, Google Maps, and the like. They were proud of their engineering skills and achievements. We asked ourselves, "Why don't we have this kind of engineering culture at ING? Why is it that large enterprises in Holland and Western Europe typically just coordinate IT rather than being truly inspired by it?" We consciously encouraged people to go back to writing code-I did it myself-and have made it clear that engineering skills and IT craftsmanship are what drive a successful career at ING.

The Quarterly: Can you say more about the companies that inspired you?

Peter Jacobs: We came to the realization that, ultimately, we are a technology company operating in the financial-services business. So we asked ourselves where we could learn about being a best-in-class technology company. The answer was not other banks, but real tech firms.

If you ask talented young people to name their dream company from an employment perspective, they'll almost always cite the likes of Facebook, Google, Netflix, Spotify, and Uber. The interesting thing is that none of these companies operate in the same industry or share a common purpose. One is a media company, another is search-engine based, and another one is in the transport business. What they all have in common is a particular way of working and a distinctive people culture. They work in small teams that are united in a common purpose, follow an agile "manifesto," interact closely with customers, and are constantly able to reshape what they are working on.

Spotify, for example, was an inspiration on how to get people to collaborate and work across silos-silos still being a huge obstacle in most traditional companies. We went to visit them in Sweden a few times so as to better understand their model, and what started as a one-way exchange has now become a two-way exchange. They now come to us to discuss their growth challenges and, with it, topics like recruitment and remuneration.

The Quarterly: Without traditional reporting lines, what's the glue that holds the organization together?

Bart Schlatmann: Our new way of working starts with the squad. One of the first things each squad has to do is write down the purpose of what it is working on. The second thing is to agree on a way of measuring the impact it has on clients. It also decides on how to manage its daily activities.

Squads are part of tribes, which have additional mechanisms such as scrums, portfolio wall planning, and daily stand-ups to ensure that product owners are aligned and that there is a real sense of belonging. Another important feature is the QBR [quarterly business review], an idea we borrowed from Google and Netflix. During this exercise, each tribe writes down what it achieved over the last quarter and its biggest learning, celebrating both successes and failures and articulating what it aims to achieve over the next quarter-and, in that context, which other tribe or squad it will need to link up with. The QBR documents are available openly for all tribes: we stimulate them to offer input and feedback, and this is shared transparently across the bank. So far, we have done four QBRs and, while we are improving, we still have to make them work better.

In the beginning, I think the regulators were at times worried that agile meant freedom and chaos; that's absolutely not the case. Everything we do is managed on a daily basis and transparent on walls around our offices.

The Quarterly: Can traditional companies with legacy IT systems really embrace the sort of agile transformation ING has been through?

Peter Jacobs: I believe that any way of working is independent of what technology you apply. I see no reason why an agile way of working would be affected by the age of your technology or the size of your organization. Google and ING show that this has nothing to do with size, or even the state of your technology. Leadership and determination are the keys to making it happen.

The Quarterly: Are some people better suited to agile operating approaches than others?

Bart Schlatmann: Selecting the right people is crucial. I still remember January of 2015 when we announced that all employees at headquarters were put on "mobility," effectively meaning they were without a job. We requested everyone to reapply for a position in the new organization. This selection process was intense, with a higher weighting for culture and mind-sets than knowledge or experience. We chose each of the 2,500 employees in our organization as it is today-and nearly 40 percent are in a different position to the job they were in previously. Of course, we lost a lot of people who had good knowledge but lacked the right mind-set; but knowledge can be easily regained if people have the intrinsic capability.

Peter Jacobs: We noticed that age was not such an important differentiator. In fact, many whom you may have expected to be the "old guards" adapted even more quickly and more readily than the younger generation. It's important to keep an open mind.

The Quarterly: How would you quantify the impact of what has been done in the past 15 months?

Bart Schlatmann: Our objectives were to be quicker to market, increase employee engagement, reduce impediments and handovers, and, most important, improve client experience. We are progressing well on each of these. In addition, we are doing software releases on a two- to three-week basis rather than five to six times a year, and our customer-satisfaction and employee-engagement scores are up multiple points. We are also working with INSEAD, the international business school, to measure some of these metrics as a neutral outsider.

The Quarterly: Do you see any risks in this agile model?

Peter Jacobs: I see two main risks. First, agility in our case has been extremely focused on getting software to production and on making sure that people respond to the new version of what they get. If you are not careful, all innovations end up being incremental. You therefore have to organize yourself for a more disruptive type of innovation-and you can't always expect it to come out of an individual team.

Second, our agile way of working gives product owners a lot of autonomy to collect feedback from end users and improve the product with each new release. There is a risk that people will go in different directions if you don't align squads, say, every quarter or six months. You have to organize in such a way that teams are aligned and mindful of the company's strategic priorities.

The Quarterly: What advice would you give leaders of other companies contemplating a similar approach?

Bart Schlatmann: Any organization can become agile, but agility is not a purpose in itself; it's the means to a broader purpose. The first question you have to ask yourself is, "Why agile? What's the broader purpose?" Make sure there is a clear and compelling reason that everyone recognizes, because you have to go all in-backed up by the entire leadership team-to make such a transformation a success. The second question is, "What are you willing to give up?" It requires sacrifices and a willingness to give up fundamental parts of your current way of working-starting with the leaders. We gave up traditional hierarchy, formal meetings, overengineering, detailed planning, and excessive "input steering" in exchange for empowered teams, informal networks, and "output steering." You need to look beyond your own industry and allow yourself to make mistakes and learn. The prize will be an organization ready to face any challenge.

# data[].attributes.attachment_link.description
Established businesses around the world and across a range of sectors are striving to emulate the speed, dynamism, and customer centricity of digital players. In the summer of 2015, the Dutch banking group ING embarked on such a journey, shifting its traditional organization to an "agile" model inspired by companies such as Google, Netflix, and Spotify.

# data[].attributes.attachment_link.title
Why And How Volvo Embraces Agile At Scale

# data[].attributes.attachment_link.description
Across the world, automotive leaders are fighting to gain an advantage in the implementation of new technologies, such as autonomous driving, vehicle connectivity, electrification, and shared mobility." Heike Freund et al, McKinsey & Company As cars steadily become "computers on wheels", Agile management is spreading from software development to the whole firm.

# data[].attributes.attachment_link.readable_text
Despite President Trump's promise that the United States would have 100 million people vaccinated for Covid-19 by the end of 2020, according to the Washington Post only 6.6 million people have received the vaccine to date. At this rate, it may take ten years to vaccinate the whole population. The vaccines have been produced: the bottleneck is in the distribution.

President-elect Biden has different ideas, with the goal of vaccinating 100 million Americans in the first 100 days. In tackling the implementation issues, particularly concerning "the last mile," it could be is helpful to recall the experience of HealthCare.gov in Obamacare, some seven years ago.

HealthCare.Gov

In 2009, around 46 million Americans lacked health care insurance. The Affordable Health Care Act of 2010 sought to make health care insurance available to millions of Americans. It was to be the heart of the new health care program. It was probably the most complex project in such a compressed period of time that the federal government had undertaken until then. It was the first time that healthcare had been offered to the entire American public. It started out as one office in the Department of Health and Human Services.

The launch was a failure. "At the end of the first day," says Jeff Gallimore, Chief Technology and Innovation Officer and Co-Founder of Excella, "only six people were able to enroll for health care insurance. That's six people, not 60,000 people: just six. And despite the numerous red flags and lack of testing, all the systems were said to be ready to go."

President Obama displayed his frustration with the launch. It was his flagship policy change and he had staked his administration's credibility on it.

"In terms of size and scale and complexity," says Gallimore, "the website under the Affordable Care Act was the biggest challenge the federal government had ever taken on in such a compressed time frame in its history."

The problems weren't due to lack of preparation. Three and a half years had elapsed between the time the law was passed in March 2010, and the time when the first enrollment period opened on October 1, 2013. During that time, there was a lot of uncertainty in almost every aspect of the project. Which states and insurers and participants would enroll? What would the insurance plans be? They didn't know.

The federal government did not anticipate what was involved or have a handle on exactly how complex its implementation was going to be. They had been running large programs with massive IT infrastructure needs, but none were as complex as this.

The troubled launch became the focus of attention on Capitol Hill. Eventually, the Secretary of Health and Human Services Kathleen Sebelius admitted under tough questioning in congressional hearings that she was accountable for the debacle.

The coordinating unit began within the Department of Health and Human Services, but was eventually moved to the Centers for Medicare and Medicaid Services (CMS). In time, they realized they didn't have the expertise or the resources or funding they needed to do what needed to be done. There was a lack of prioritization. They didn't manage the risks or the amount of coordination that would be required or the needed integration of the technology.

Many federal agencies were involved and there were more than 50 different companies contracted to work on different parts of the website. Eventually there were 36 states and more than 300 insurers with more than 4,500 insurance plans all coming together in the website known as HealthCare.Gov.

The federal government reserved for itself the job of coordinating how all this was going to come together. But at the time, there was no single technology authority in the federal government charged with coordinating everything.

A major problem for coordination was the culture of confidentiality and agency turf that prevails in government. Because of the way contracts are drafted, where people are forbidden to share information, it was very hard to get people to communicate in an organic way. Instead, everybody acted as if they've never heard of each other before. Moreover, as they were in dozens of different buildings spread around the city.

There was a lot of uncertainty about how much participation from the general public was going to occur. And they decided to buy physical infrastructure in data centers as opposed to using the limitless resources of the cloud.

The managers of Healthcare.gov left testing very late in the process so they failed to detect the lack of overall visibility of the progam until it was too late. When news started to come out about how the planned releases were not going well, everyone panicked. They didn't have the visibility that they needed either in terms of progress or quality or functionality. They only had inklings of that in a real way in the summer of 2013, well before October 1. But even within two months of the live release, they were still not seeing the whole system work. Without that, there was no way of uncovering errors, and yet the political commitment to release on October 1 remained, meaning that they had to go forward, without adequate preparation.

How Agile Helped Resolve The Obamacare Crisis

In such a setting, it was no surprise that what was meant to be a major government accomplishment turned into a burning platform. Yet the fact that it became a burning platform created a lot of impetus for change. People get very receptive to change in the middle of a crisis. It generated a huge push for fixing the problems. It meant people working overtime 24/7 to boost capacity, and that meant filling key leadership positions that had remained vacant. And it also involved bringing in ad hoc technology experts from the private sector, many of them from Google.

The US Digital Service was created when HealthCare.gov broke down and began spitting shrapnel everywhere. The situation was so bad that those working on the website had to turn on CNN to see whether the website was up or not.

One of the first changes they made, says Gallimore, was to create an exchange operations center, The second thing that they did was to change the culture. It didn't matter where you were from or who you are employed by or what your title was. You were there to get the site back up and running and stable.

There were steps that were just battlefield medicine, commonsense steps that helped a lot in a very short period of time. For example, having all the people meet together, some of whom had never met before. Another was to perform blameless post-mortem sessions, using best Agile engineering practices. These were the kinds of things that allowed Healthcare.gov to make it through the enrollment period.

"It was very mission oriented," says Gallimore. "It was very focused, and it was not political. It was about creating teams of people who had a singular focus on getting the site back up. It became very clear the project had been rescued using Agile methodologies and that Agile had a lot to offer to government in projects of this magnitude and this complexity.

In the first day of that first enrollment period, October 1, 2013, there were only 6 people who were able to sign up for a plan. By contrast, on the first day of the second enrollment period, just over a year later, the enrollment hit 60,000.

One of the conclusions of the experience was that more technologists were needed in government. An important legacy of the Launch and Crash of Healthcare.gov was the creation of the US Digital Service, which is still collaborating with many Federal agencies. In the words of Matt Cutts, a former engineer at Google and now Director of the USDS, working with the government can be very frustrating but sometimes, it is also infinitely rewarding.

Covid Vaccines And Obamacare

There are obviously many differences between the Covid vaccine rollout and the Obamacare rollout. One is a vaccine; the other is software. But the logistical issues-the political implications of success or failure-are similar. Both have huge lasting impacts in the lives of citizens.

LAWRENCE, MA - Police Department first responders receive the Moderna COVID-19 Vaccine
Boston Globe via Getty Images

Because the political fallout of failure or delays was enormous in both cases, both programs have in common the intense involvement of the White House. But the vaccine program can benefit from the experience of Healthcare.gov.

There are also major differences in the amount of policy involved. Healthcare.gov was the last step in implementation of a new law. The vaccine program is a much more focused and time bound exercise and there are established channels for similar but less urgent programs such as flu shots. There may be some policy questions at state level possibly regarding issues like: who is a certifiable healthcare organization, or who is qualified to perform the tasks involved in injecting vaccines into people's arms? In Healthcare.gov, the issues were complicated in terms of establishing permanent inter-agency mechanisms.

The vaccine program is a logistics and supply management problem with inter-agency coordination between State and private parties and the federal government. On the face of things, the vaccination program is simpler than Healthcare.gov. But there is the urgency of life and death and of reactivating the economy that was not present with Healthcare.gov. This gives it a special kind of challenge: the need to provide rapid response in the face of complexity. An Agile approach seems particularly useful for the task at hand.

And read also:
Explaining Agile
... Read More

# data[].attributes.attachment_link.title
What The Covid Vaccine Rollout Can Learn From Agile

# data[].attributes.attachment_link.description
Despite President Trump's promise that the United States would have 100 million people vaccinated for Covid-19 by the end of 2020, according to the Washington Post only 6.6 million people have received the vaccine to date. At this rate, it may take ten years to vaccinate the whole population.

# data[].attributes.attachment_link.readable_text
What is Agile methodology?

Since the early 2000s, the Agile methodology has become a staple project management approach for many technology organizations. Most software development teams today practice Agile in some form, and elements of it have made their way into many work environments. The word itself has even become more popular, as thought leaders today talk about the need to be more "agile" across the world of business. But what does it actually mean to use an Agile project management approach in your business?

The Agile methodology is a project management process which breaks up projects into smaller tasks and stages. This bite-sizing of work allows Agile teams to incorporate stakeholder feedback, re-evaluate work and take an iterative approach at every point of the process. One of the most common approaches to Agile involves chunking up work into short phases of development, known as sprints. This allows the team to work quickly and then re-evaluate that work with managers and stakeholders regularly in sprint planning and daily scrums. Upon review, the project team and stakeholders can then continue their current track or change plans for their upcoming sprints. Compared to traditional project management approaches, Agile prioritizes speed, flexibility, teamwork and stakeholder needs.

Where did Agile come from?

The idea behind Agile emerged in the early 2000s from a group of software developers who established four main Agile principles:

Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan

These values, enshrined in the Agile Manifesto launched in 2001, shaped the Agile project management approach and transformed the software development industry.

Up until that point, Waterfall was considered the preferred approach in tackling software development projects. While ground-breaking when it first appeared in the 1970s, Waterfall had become burdensome by the 2000s. Crucially, it involved heavy amounts of documentation and decisive planning before a project could even begin. Once work actually began, those plans were strictly followed by separate, often siloed teams, making it difficult to adapt to issues or changes in needs. By comparison, teams using Agile development methods could begin work faster, adapt to issues as they arose and plan directly with their customers and stakeholders.

Why is Agile project management so popular?

Compared to Waterfall, the benefits of Agile were obvious to technology companies in the 2000s. The advantages of Agile software development extend beyond just the world of programming as many other industries now incorporate Agile in their workflows. So, what has made Agile so attractive to so many project managers and business leaders?

Adaptability

At its core, the Agile methodology is about being able to respond to changes in goals, environment or process issues. With an Agile framework, the ability to evaluate your current work, timelines and project needs are built into the approach. If a stakeholder wants to change the scope or direction of a project, scrums and sprint planning provide opportunities for the team to change course. If a team member discovers an issue with a current task or part of a project, the schedule can be adapted to tackle the issue quickly. Rather than your project teams producing something that no longer meets customer needs, Agile allows you to quickly change course.

Stakeholder alignment

With this level of flexibility, Agile is also able to stay aligned with the ever changing demands and needs of clients and customers. With any project, the goals and scope outlined at the beginning between your team and your stakeholders rarely stays the same. Perhaps extra work and needs have arisen with your client that they hadn't foreseen, or the demands of the end consumer have changed over time. Whatever the reason for your stakeholder's change of plans, Agile allows you to be more responsive to those changes so you can deliver quickly and avoid backlog. This ensures that deliverables meet the evolving expectations of your clients, no matter how far they travel from the project start.

Speed

Of course, the Agile methodology wouldn't have the name if it wasn't agile by nature. By bite-sizing your teams' tasks and giving them shorter, defined work periods, Agile lets your team focus and work faster. At a basic level, this means that products can get to market or to clients faster. But this speed alongside the ability to adapt is the core combo that makes Agile compelling to businesses of all varieties. When problems arise, your team can change tack and deal with them quickly. There's no time spent going back to original plans or documents: you raise the issue in a scrum, schedule for it, and then solve it. In this way, Agile helps teams to stay focused on individual tasks and complete them on time.

What are the challenges to the Agile approach?

Agile isn't a foolproof solution, however. As with any project management approach, there are things that it excels at and things that need to be taken into consideration when using it. Just as Waterfall, there are drawbacks and challenges to using Agile that can get in the way of work if not managed appropriately.

Managing scope

With the ability to quickly adapt to issues and changes to process, it's important to watch your overall project and scope. Agile allows you to change plans and work fast but moving between tasks quickly can blind you to how much progress is being made overall. Even if your team is working efficiently, you may overshoot on budget or time if the list of tasks created by sprint planning grows unchecked. Agile teams and project managers need to stay on top of their project's scope and roadmap to ensure the amount of work they are taking on doesn't balloon out of control.

Scheduling

It's not just scope that can slip away from a team using an Agile process. When teams use sprint planning, they're able to be flexible in their schedules and priorities based on current needs. However, once team members start to move around and tackle new tasks or support on problems, the schedule needs to flex to accommodate that. If you're keeping to a strict schedule, you need to ensure that sprint planning is still staying within that timeframe.

Also, while self-organizing teams may be jumping between various tasks based on need, they will also eventually need to come back to their assigned tasks. At this point, it's on Agile project managers to know where the team is on all tasks and to ensure that nothing is left behind. Otherwise, work that was thought to be done may be forgotten over the course of numerous rapid-pace sprints.

Communication

In the Agile approach, the prioritization of teamwork and rapid response naturally means that communication is paramount. Team members need to be able to communicate their current progress, whether any issues have arisen and if they need help with ease. This communication needs to happen regularly between all members of the team, and it needs to feed directly into your planning. It's essential to stay aligned with stakeholders, as you're only able to change your plans if you know what your stakeholders want.

How to implement an Agile process

If you're interested in adopting the Agile project management methodology for your team, there are many tried-and-tested strategies and practices-sprints and scrums being some of the most common. Of course, using the right project management software and tools can also make or break an Agile planning approach. Here are some of the most important processes and methods to establishing and following an Agile methodology:

Track your tasks

In order to know what work needs to be done in the next sprint, you need to know what's already been completed. As such, your team need to be masters of keeping track of their progress. Backlog refinement, or backlog grooming, is a technique commonly used by Agile teams. It centers around providing teams with transparency, prioritizing backlog items and ensuring that the items topping the list are ready for delivery. Scrum teams will often use planning walls or Kanban boards to keep track of things, but many opt for a task management software. Dropbox allows for the integration of task management software, such as Trello, keeping your team synced up on processes across apps in real-time.

Communicate regularly and effectively

Proper communication is the cornerstone of any Agile project management framework. So, giving your team the means and opportunities to communicate at regular intervals is paramount. While sprints are typically run in 2-3 weeks bursts, many scrum masters host daily "stand-ups" with their teams to keep on top of progress day-to-day. While your specific communication cadence is up to you and your team, using tools can help you facilitate those conversations. Dropbox Spaces allow you to store all of your content in one organized place while effectively coordinating your team. By assigning to-dos or leaving comments you can provide your colleagues with the context and direction needed to stay in sync. Integrations with real-time chat and videoconferencing apps like Slack and Zoom can also help you host team meetings and planning sessions. You can share files and begin conversations directly from Dropbox, reducing the time spent switching between tabs and context-switching. This is especially useful for communicating with remote teams-or with team members whose desks are just too far away.

Stop and review

With Agile, it can be tempting to just jump straight from one task to the next, ticking them off as you go. It's important however to make space for reviews and sprint retrospectives in Agile processes to prevent cases of team tunnel vision. Building time for review at the end of each sprint allows for team members to re-evaluate their own work and prioritize.

Post-mortem style sprint reviews should also be used to examine how your planning has affected a project over its life cycle. For these, keeping track and having proper records of your work is essential. Dropbox has built-in version control features that can help you review your team's files at every stage of development at these times. It can also be used during stand-ups to see an individual team member's progress or roll-back changes that may not have been approved.

Working with an Agile methodology

The Agile methodology has been transformative for many businesses and managers in terms of the way they work and the success they see. It has been a driving force in software development processes since the 2000s, and elements of it have permeated across the world of work. Whether you're considering sitting down for a team scrum tomorrow morning or just sticking to emails, it seems that the Agile methodology is here to stay.

# data[].attributes.attachment_link.description
Since the early 2000s, the Agile methodology has become a staple project management approach for many technology organizations. Most software development teams today practice Agile in some form, and elements of it have made their way into many work environments.

# data[].attributes.attachment_link.readable_text
For many insurance carriers, launching new products can take several months. First, a product manager opens a project request, which takes the central project-management office several weeks to analyze. The office then appoints a business analyst to identify requirements, develop a business case, put the products into the pipeline, and allocate IT resources. In the meantime, actuaries build risk models, marketers design launch campaigns, and operations specialists prepare the underwriting and claims processes. These machinations are the start of a long journey involving at least six different departments while customers wait for their needs to be met.

Now, imagine a small cross-functional and agile team consisting of multiple actuaries, a marketer, a customer-journey design expert, a data scientist, and several software developers set on delivering new products and increasing sales through digital channels. This team does not dissolve after its project mission is completed; it continually maintains the product, collects customer feedback and improves customer journeys, and aims to improve its sales until other strategic priorities emerge.

One large European insurance company asked such an agile team to launch a new suite of digital insurance products. It developed the value proposition, pricing, and technical setup for two of the five highest-priority products. After four weeks, the team had minimum viable versions of both products ready for launch on the website. Once these versions went live, the team quickly gathered feedback from the customers and continuously made improvements, and during the following eight weeks the team launched the remaining three products. This team was one of more than 40 cross-functional agile teams that-following a multiyear, enterprise-wide agile transformation-were set up to permanently replace the previous functional organizations and run the business.

The concept of enterprise-wide agility is not new; many technology companies and service-industry leaders-particularly those in banking and telecommunications-have adopted it. More insurers are now turning to agile methods as they try to adapt to rapid industry changes. And COVID-19 is accelerating many of these recent structural shifts. For example, customer expectations are evolving to include more digital, seamless, and multiaccess experiences as well as fast and reliable responses during the few moments of truth, such as in sales and claims. As insurance products become increasingly commoditized, profit pools are eroding or shifting. Macro shifts in the workforce are emerging sooner than expected with remote-working models and a rising need for new capabilities, including data analytics.

The call for an agile operating model for insurers has never been clearer. While this multiyear process is complex, scaling up agile practices is not exceedingly difficult. To do so, insurance companies must break silos and move beyond singular agile teams to reap the full benefits of enterprise-wide agility. This requires deciding what the organization will solve with agility, redesigning the organization as a network of small empowered teams, and deploying agile governance and processes. The agile transformation also involves rethinking the people model in a nonhierarchical environment, and modernizing core technology components.

The case for adopting enterprise-wide agility in insurance

Traditional insurers' functional and hierarchical operating models are set up to succeed in relatively stable environments and are increasingly becoming outdated. These models were already posing challenges for insurers before the COVID-19 pandemic emerged. As they organize for the next normal, it will be critical for insurers to get faster, leaner, and more effective. Agility helps on all three counts. Agile organizations are designed to minimize handovers and maximize accountability on missions, allowing them to launch new products or update new pricing models up to five times faster. With business and IT working closely as a single unit, they spend less time on alignment, syndication, and decision preparation.

In addition to shortening time to market, agility can help delayer organizations, simplify governance, and deliver operational efficiency. One European insurer reduced the number of hierarchical layers in its organization between its CEO and entry-level employees from seven to three (Exhibit 1). As a result of creating this agile organization, the insurer was able to reduce its number of management committees by 30 percent. Also, its agile operating model design enabled the insurer to achieve 20 percent operational efficiency.

As a result of being faster, leaner, and more effective, agile ways of working typically lead to improved customer satisfaction and employee engagement. An Asian insurer, which completed its agile transformation, increased its customer-satisfaction scores by nearly 20 points while also raising average employee-engagement scores across its tribe members by more than 20 points after one year of agile operation (Exhibit 2).

Companies that adopt agile practices also tend to do a far superior job of adapting to remote ways of working, which have been critical during the COVID-19 pandemic. Small self-managing squads are a good recipe for remote work. Weekly agile ceremonies (planning meetings where teams set expectations and collaborate) and daily virtual huddles allow for superior vertical and horizontal alignment within teams. They also maintain high levels of transparency through fast-changing market conditions with regular virtual meetings and digital collaboration tools to plan sprints, conduct review sessions, and prioritize and manage backlogged items.

Without agile methods embedded in their enterprises, however, many of today's insurers are not ready to face the challenge of the next normal. To determine the need for an operating-model transformation, executives of insurance companies can work through this set of questions with their executive teams:

Is there constant confusion around ownership and responsibility when trying to deliver end-to-end business objectives that cross functions? Do these endeavors often lead to additional unnecessary management structures such as shadow committees and task forces?

Does delivering the most critical solutions-namely, customer journeys, products, and analytical models-require multiple handovers and therefore long lead times?

Is the organization overlayered or overstaffed (especially at middle management), creating inefficiency, excessive time spent gaining consensus, and loss of accountability on core business objectives?

Do the organizational culture and leadership approach make it difficult to collaborate across units, hinder fast decision making, slow down the pace of experimentation, and decouple decision making from facts and data?

Is the organization finding it difficult to attract the talent that it needs to win in a competitive environment?

Is the technology infrastructure built in a monolithic way that does not support the speed and flexibility required to keep up with tech giants and insurtechs?

If answers to some or most of the questions above are a resounding "yes," the insurer should strongly consider a shift to an enterprise-wide agile operating model to deliver on its strategic objectives and achieve business results.

Redesigning a fluid insurance organization focused on customer missions

When embedded across the insurance value chain, agility can help insurers improve their customers' experience. They can use two main agile building blocks to do so: cross-functional tribes and self-managing teams.

Cross-functional tribes

An agile, cross-functional tribe structure is ideal for delivering change initiatives. These tribes provide and unify all the resources necessary to deliver on their missions. While they are responsible for managing the business, and building and maintaining product and services, they typically do not run the day-to-day operations. Their obsession is improving how the customer is served and they possess all the capabilities needed to fulfill their missions. A product tribe may develop new products, maintain customer journeys on various sales and service channels, drive penetration in the market, and manage a customer portfolio. An after-sales tribe can, for example, work on improving the effectiveness of indemnity management, improving central procurement for certain spare parts, automating internal claims operations, or designing a new digital first-notification-of-loss journey.

Self-managing teams

While tribes are managing the business, delivering change, and improving how products and journeys are delivered, agile self-managing teams can run everyday operations. These flat, multiskilled teams distribute work within itself. These teams can run sales operations in the field, run claims operations, run the underwriting processes, and answer customer calls. Their ultimate objective is to run operations flawlessly and as tribes have designed it for them, while meeting relevant key performance indicators (KPIs).

In one European insurance company, the claims handling department adopted agile ways of working by, for each type of claim, combining all activities, including claims handling and call center operations, under the same team. These teams have all the skill sets needed to process one type of claim from end to end, and are accountable for results. Each of these teams has clear KPIs and service-level goals, and works without a formal team leader to achieve them. Unit leaders and agile coaches helped the teams continuously improve their operating model. The result was increased customer satisfaction through end-to-end ownership, higher productivity, and efficiency with fewer handovers across teams and more "doers" within the team, and more-motivated employees by giving them the authority to make decisions.

Given these agile building blocks and an organization's overall objectives, insurers need to answer several design questions as they define their aspirations and desired organizational architecture. The following questions are not exhaustive but are a good starting point for all insurers as they start this journey:

Will the tribes be built on product lines, customer journeys, customer segments, or sales channels? How will the organization architecture work based on how the tribes are designed?

How will we approach digital channels and digital transformation? Will we incubate them as a separate tribe or tribes, or embed these missions into existing tribes?

How will we design the link between "change" tribes and "run" self-managing teams? Should we directly link corresponding units or group all "run" elements under a single umbrella for efficiency benefits?

How will we organize our sales self-managing teams? Will we assign them by channel, region, or product?

How do we keep our functional edge while distributing functional elements into permanent tribes?

The answers to these questions are not straightforward and will vary by insurer. However, two guiding principles should always hold true. First, the organization design should minimize handovers to enable faster delivery and improved accountability. Second, the design should allow for economies of scale and avoid duplication of resources. From the very start and before the insurance organization embarks upon a multiyear, enterprise-wide agile transformation it is essential for company leaders to agree on an end-state vision. That vision, which includes how these agile building blocks should come together, should be in service of creating a better end-to-end customer experience (Exhibit 3).

The nuts and bolts of insurance tribes

Today, many traditional insurance organizations are built on functional domains, which helps ensure technical excellence for each business line. During the past two decades, this approach has indeed resulted in function-based innovation, effective sharing of best practices, and tighter control over standards. However, easier access to data and information have diminished the advantages of functional experts working in separate silos. In today's fast-paced, omnichannel, and "always on" market environment, it is nearly impossible for insurers to deliver seamless and comprehensive experiences that customers want without breaking down functional silos. This is precisely why most insurance companies begin their journeys toward agility with cross-functional tribes.

In a nutshell, the delivery organization is split into tribes where full accountability is given to the tribe lead (Exhibit 4). The tribe lead is responsible for effectively delivering the mission with the help of squads. A squad is a cross-functional team accountable for an end-to-end mission based on tribe objectives. Squads minimize dependencies with nontribe functions and maximize autonomy within tribes-they have the authority to launch new services and products, change prices, and make in-budget purchases.

Squad members come from multiple functions, forming chapters within the tribe. Chapters are essentially capability houses, similar to functions within traditional organizations. Insurance tribes typically have several indispensable chapters that ensure best-practice sharing and compliance with functional standards across the organization. For example, product and actuarial resources bring product and pricing know-how to the tribe, while the marketing chapter manages the above-the-line and below-the-line campaigns and customer experience. The data chapter includes resources such as data engineers, architects, and visualizers who help multifunctional squads use analytics as an enabler. Lastly, the engineering chapter brings in software-development capabilities that help squads deliver software solutions from idea to execution. Other resources may be in the form of additional chapters or flow-to-tribe depending on the tribe mission and priorities.

Chapters ensure tribes have the functional excellence insurers have always required, and squads ensure they have the flexibility and agility they need in the next normal. Tribes are the delivery centers of insurers, defining how products will be marketed and distributed, how they will be priced and underwritten, and how customers will be served in line with the company strategy.

For any insurance company this organizational structure of squads and chapters is at the heart of agile transformation, but it is only one piece of the puzzle. Insurers that undergo such a journey must also redesign their processes around agile principles; develop an entirely new talent model to fit their new, flat organization; and establish their technology foundations to operate in an agile way (Exhibit 5). This is a long journey that requires serious commitment and continuous collaboration across multiple departments.

Where and how to begin?

As with most large-scale transformations, there is no single or correct path to the end state. However, several steps can certainly increase the rate of a successful outcome.

Set a "north star" from the beginning. Agile transformation is a multiyear journey that requires full buy-in from the leadership team; it must set a vision from the beginning and be engaged in every step of the process. The transformation team for one European insurance company conducted a diagnostic survey across its top 30 executives and gathered them in a workshop to analyze results and gain support for an agile transformation. After four full-day executive committee workshops and two visits to other companies that have gone through similar journeys, the whole executive team got on board with the end-state vision for the organization and how to get there.

Start with a small front-runner tribe. Adopting agile at an enterprise level from the start is a challenging undertaking; rather, insurers should begin the journey with a single front-runner tribe before scaling it across the organization. A typical front-runner covers an end-to-end business-such as the home insurance product line-including functional areas such as product management, pricing, marketing, data, engineering, design, as well as claims, operations, and sales. The front-runners should be comprehensive and bring the model to life in its entirety with all necessary agile elements; they shouldn't just be testing few agile ceremonies.

These front-runner tribes should be designed to impart "what enterprise-wide agile will feel and operate like" to let the organization digest this transformational change. They should not be set up to test if agile ways of working are appropriate, which is why many organizations have stopped referring to these as pilots. A good front-runner tribe is sizable and has a well-aligned leadership team. For example, one insurer decided to pick one of its biggest lines of business where it saw a high growth potential as the front-runner tribe. During that experience, company leaders gained invaluable lessons on how to design agile ceremonies and performance management processes that best fit the company culture.

Learn from front-runner tribes and then scale agility across the organization. Agile transformations acknowledge that not everything can be known and planned for and that the best way to implement is to adjust as you go. With lessons from the front-runner tribe, agile transformation teams can iterate the design to better fit the insurer and scale across the organization either instantly (launching all remaining agile units at once) or stepwise (spreading the launch of agile units according to a time frame). One insurer, for instance, monitored the performance of its front-runner tribe for six months, made several changes to its "tribe design blueprint" based on the observations and then launched four other tribes in the course of another six months.

Do not wait to transform human capital, including capability building and hiring. Agile requires new skills and capabilities -including a growth mindset, performance orientation, and empowerment-that do not often come naturally to those who are steeped in traditional operating models. Insurers should therefore focus on rapid upskilling and hiring top talent to fuel tribes. Following the launch of new tribes, one insurance company developed individual learning programs for its agile coaches, product owners, and chapter leads. It also put its executive team through an agile leadership learning journey to help the team role model agile behaviors. Finally, it introduced new and diverse talent to the tribes when it hired ten "superstar" product owners. These new product owners, coming in from the likes of banking, telecommunications, and technology, brought the much-needed new blood that agile organizations typically require.

Focus on culture from day one. Cultural transformation takes much longer than organizational change, so insurers should initiate a culture program from the very beginning. One insurer defined the key behaviors it wanted to change across the whole organization and created a nine-person cross-functional "culture squad" that includes one representative from every company function (agile or nonagile). The culture squad's sole job is to catalyze cultural transformation by encouraging specific behaviors in the organization. After one year, the team deployed a leadership development journey, a brand-new performance management system, and a communication strategy that inspired conviction in an agile operating model.

The insurance industry is undergoing tremendous change at the start of the next normal. Smart business strategies are critical to succeed in this environment. But with their traditional, siloed, hierarchical operating models, many large incumbents are in danger of failing to deliver strategies set by their executive committees. Many insurers are finding that enterprise agility gives them the upper hand in meeting customer expectations, improving time to market, creating efficiency, and increasing employee engagement. Front-runners are already seeing results; many others are following. Now is the time to organize for the future.

# data[].attributes.attachment_link.title
Scaling agility: A new operating model for insurers

# data[].attributes.attachment_link.description
For many insurance carriers, launching new products can take several months. First, a product manager opens a project request, which takes the central project-management office several weeks to analyze. The office then appoints a business analyst to identify requirements, develop a business case, put the products into the pipeline, and allocate IT resources.

# data[].attributes.attachment_link.readable_text
Software development used to be a long, drawn-out process, with teams of workers spending years if not decades to develop the next generation of the next big thing. Enterprise tech teams were structured around these longer timelines and threw up their own gates to gather requirements, contract out the development, deploy the release, and validate solutions before handing them over to the service teams that would manage the solution for the rest of its lifetime.

Origins of agile development

This model worked for decades, but with the dot-com boom, a new generation of technologists and futurists began building solutions that could be stood up and torn down in a matter of weeks or months instead of years or decades using the new "world wide web" as a platform for communication, applications, and software development.

Coming out of the chaos of the dot-com boom was the dot-com bust that left the famed Northern California Silicon Valley in shambles. As the dust settled, entrepreneurs worked to redefine a set of software development best practices that would support a more standardized approach to short-cycle iterative development.

The resulting process became known as " agile development " and came to the Valley with its own set of "agile ninjas" that wielded their own sets of tools, standards, and language to bring stability and a new norm to the valley.

At its core, it is this iterative software development methodology that has shaped the culture at Tesla. Tesla does not follow the long development cycles that have been the standard in the automotive industry for decades. Tesla does not wait to roll out improvements. It has instead applied the tenets of agile development to its automotive design and manufacturing processes, and in the process, it has revolutionized the industry.

It is Tesla's relentless pursuit of not just the best electric vehicle, but the pursuit of the best vehicle, period, that has defined its trajectory more than any other. Tesla, unsurprisingly, operates like a software company. It iterates and rolls out improvements as they come. It takes in feedback regularly, as if it thrives on new ideas, solving problems, continuous improvement and iteration.

Use of agile principles like "scrums" - or regular meetings designed to put structure around ingesting and vetting improvements - have helped Tesla to perfect its vehicles and bring innovations to market that would have taken more traditional automotive companies years if not decades to get into the hands of customers.

The downside of rapid development in the automotive industry

The downside of this model - and current software development - is that, while development may happen at breakneck speeds, the vetting of the software in the millions of applicable scenarios still takes many weeks, months, and years. The result is what we have seen in Tesla's production vehicles - a total system that is effectively in a permanent beta state. The software is more than functional most of the time, but is expected to have bugs that rear their angry heads.

Tesla's phone key issues, panel gaps in early vehicles, road noise, seat improvements over time in most of its vehicles, issues with early Model X falcon-wing doors, Tesla Model S door handle issues, etc., etc., ad nauseam are all the symptoms of this strategy. Fortunately, the vehicles themselves are so much better than everything else on the road - and Tesla continues to deliver innovative, low-cost service solutions to fix its vehicles - that owners still rate Tesla at the top of the pack. Actually, most Tesla owners wouldn't be able to have a Tesla vehicle and so much innovation today if it wasn't for this approach, and they generally understand that and appreciate being able to have the cars (potentially with bugs) rather than having to wait for a similar thoroughly vetted vehicle to come out years from now.

We do not spend a lot of time covering the smaller issues with Tesla's vehicles because, at this point, they're more or less expected. It's not a big deal and they are typically resolved rather quickly. The issues do not typically continue in perpetuity, but rather, Tesla tends to stabilize each platform over time. We've seen this play out with the Model S and the Model X, and we are now right in the middle of this evolution with the Model 3.

Extreme manufacturing - agile development for factories

Applying software development methodologies to automotive manufacturing looks great and maybe even obvious in retrospect, but it has been nothing short of a miracle to actually build a company and a business around them, which is what Tesla has done so successfully over the last 15 years.

At its core, agile development takes in new requirements as " user stories." These don't attempt to describe how functionality works, but instead take on the challenge of describing how the functionality will be used and what the actual customer needs. These requirements flow into the project management process not only at the beginning, though - user stories are vetted on an ongoing basis as part of a weekly scrum.

The scrum framework defines a standard set of tools that are used in weekly development cycles, called " sprints." As the name implies, a sprint is a very short timeframe wherein the development team attempts to build a specific set of functionality based on a single user story.

Quick 15 minute meetings at the start of each day help the team to check status, ask for help, clarity, etc., before getting back to the actual work of developing the functionality. Overall progress delivering new functionality - as measured by the number of user stories that have been completed - is measured as the " velocity " of the team.

Joe Justice is leading the charge to adopt the agile development methodology to factories and is putting structure behind what can otherwise become a haphazard application of software development principles to manufacturing. He started doing this with his company Wikispeed and has since joined Scrum, Inc as a consultant, where he promotes the adoption of the agile development framework in manufacturing.

One key learning he and his team at Wikispeed came away with is that "Morale is multiplier for velocity across the team." That's logical and goes along with the disproportionate value of positive feedback versus negative feedback, but rarely seems to make the leap into software development, let alone manufacturing.

The Alien Dreadnought

Joe called out that Tesla has taken the principles of agile development and built its factory to mimic the founding principles of the methodology. A system comprised of robots and flexible, adaptable factories is essentially a naked programming language that can be adapted and dynamically tweaked over time as the incoming user requirements change.

For example, if Tesla's engineers design a door that's better - lighter, safer, and cheaper - Tesla can reprogram its factory to build the new door and to integrate it into the existing factory process. The factory has not been hardcoded to only build a single car. Rather, it can shift and adjust as new requirements - or user stories - are added and designed for on the front end.

With Model 3, Tesla aspired to build the ultimate factory production line, which idealistically could be almost entirely automated. It was also hoped that it could deliver greater flexibility for the future and the highest safety in the industry by removing people from dangerous assembly tasks. Furthermore, the target was to achieve significantly lower cost by increasing production speed to levels humans are incapable of delivering. As the production lines for Model 3 were vetted out, Tesla had to refine and adjust some of these areas, giving some complex tasks back to humans that were previously slated for automation.

That work wrapped up at the beginning of 2018 and that's when Tesla started ramping up Model 3 production in earnest for the first time. But the iteration and improvement isn't over - it never ends. We're now seeing that Tesla continues to refine and put a polish on its production lines as the bugs in the system are worked out.

Tesla is already looking to the next big step into the future, with CEO Elon Musk noting that Tesla is working to "finish production design & build it, while avoiding dumb mistakes made with Model 3 production system." Those who have watched Tesla for any amount of time know that, while Tesla will continue to improve, it will also continue to push the envelope - and that comes with its own set of new, unforeseen challenges.

It gives me hope for the future. It gives many of us hope for the future. The future is electric, but it will come faster with Tesla's rapid iteration and agile development.

Take a look at Joe's keynote from REConf 2017 here, where he unpacks the iterative process he and his team used to translate the agile development framework for manufacturing plants.
Editor's note: I'll tag something on here that I was planning to turn into its own story. Tesla Motors Club forum member "dondy" wrote a superb summary today that explains why Elon Musk's manufacturing leadership is still so critical to Tesla. In response to the idea that Elon Musk would step down from the CEO role, dondy wrote (edited slightly for grammar & clarity):
Let's take the example of Doug Field.

I am sure he is a very good, talented engineer who does and will continue doing amazing work.

In 2016 he took over of Model 3 program.

He misjudged initial difficulties and issued overoptimistic prognoses reflected in Q1, Q2, and Q3 2017 reports. He missed issues in Gigafactory 1 completely. He missed required adjustment of Fremont's General Assembly 3 (GA3) line (famous gaps normal due to unpredictability of idealized design transfer to hard reality). When GA3 stalled thanks to misaligned robot stations, Musk took over.

So, let's compare: Doug Field in 1.5 years: from 0 to 20% of the production capacity. Very respectful achievement which would earn him a place in any company.

Elon Musk in 3 months: from 20% to 80%, fixing quality problems in the process, adding extra line with 20% capacity production.

In another 2 months, streamlining conveyor line.
Indeed. Elon Musk is superb at leading extreme manufacturing. It isn't always perfect. It isn't always easy. It isn't always pretty. But the progress is substantial and rapid.
Appreciate CleanTechnica's originality? Consider becoming a CleanTechnica Member, Supporter, Technician, or Ambassador - or a patron on Patreon.

Advertisement

Have a tip for CleanTechnica, want to advertise, or want to suggest a guest for our CleanTech Talk podcast? Contact us here.

# data[].attributes.attachment_link.title
Tesla Has Applied Agile Software Development To Automotive Manufacturing

# data[].attributes.attachment_link.description
Software development used to be a long, drawn-out process, with teams of workers spending years if not decades to develop the next generation of the next big thing.

# data[].attributes.headline
Civil Service College: From traditional to agile  (12min) 

# data[].attributes.subject
Civil Service College: From traditional to agile  (12min) 

# data[].attributes.attachment_link.description
Agile is an approach, commonly used in software development, which has been widely adopted by tech organisations to deliver their products to consumers more efficiently. The public sector, which has traditionally not used Agile ways of working, can benefit from adopting Agile in many areas, including strategy, policy, communications, HR, and IT.

# data[].attributes.attachment_link.readable_text
The outcome: a more flexible organization

At the outset, the organization was traditionally structured along functional silos, which carried out different parts of a single process without the benefit of having a complete view of its execution. This way of working proved inadequate for the bank's new challenges and prevented a "liquid" resource pool where people could be assigned to the highest priority projects or processes at any given time.

In light of this situation, BBVA elected to radically shake-up its organizational structure. The Group approached this change with the experience it had gained by implementing agile techniques and with the goal of creating a more transparent, flexible, and productive organization.

This organizational change also called for the total visibility and transparency of the projects that were underway. To gain this visibility, BBVA created the Single Development Agenda (SDA), which serves to prioritize all the bank's global projects taking into account their criticality and alignment with the Group strategy, avoiding duplication and lack of strategic focus.

By establishing the SDA, the Group was able to obtain a holistic view of the bank's capacity to deliver projects and has thus become the essential foundation for a staffing model that meets demands. Finally, the model has been designed to assign each resource to the projects where she or he will add the most value based on knowledge and experience.

A new organization, new tools for professional development

BBVA is the first large enterprise to have completed an agile transformation of its central service functions across all its subsidiaries worldwide. This accomplishment represents an all-encompassing milestone: not only was the organizational and governance structure changed, but so to was the way of working and the professional development of more than 33,000 people who work in the bank's central services.

This change has redefined the traditional concept of departments and functional divisions, establishing a new structure composed of five main blocks for each department:

Customer management ("front line"): small teams that manage the relationship between different departments.

Project teams: autonomous, multi-disciplinary teams empowered to reallocate resources on a quarterly basis depending on the bank's strategic priorities. Typically, they adhere to a "scrum model."

Process teams: tasked with executing recurring processes supporting business activity or project teams. Typically, they work according to a kanban model.

Disciplines: smaller teams, focused on managing and sharing the bank's knowledge and best practices in areas of technical expertise.

Control: teams that cut across all the Group's management, business, or operational departments.

In parallel, for each discipline, Communities of Practice (CoPs) have been established, conceived to be expert communities that share knowledge and expertise and co-create solutions and tools that will be made available to the entire Group.

Teams, therefore people, are the cornerstone of the bank's new organization, because they are the ones responsible for the success of the bank's transformation

Tools designed to promote employee professional development in the new organization were also created. They include an evaluation model aligned to the new project approach to work and the role of the "people leader" to give employees career path advice and give employees visibility within the organization.

At the same time, to ensure the transformation's bedding-in, the bank staff had to be trained on the new work methodologies and given support during the transition to a model that broke with tradition. To this end, firstly, the bank created a team dedicated to both promoting the agile model across all the bank's departments and geographical footprint as well as to measuring the degree to which the new methodologies were adopted. Second, the " agile coach" role was defined to support all teams in order to guarantee that the techniques and tools of the new model were adopted, thus ensuring maximum benefit from the new approach. Agile coaches teach the teams how to work independently and support the required change of mentality, helping teams focus on deliverables, quality, and customers.

# data[].attributes.attachment_link.title
Agile at BBVA: a journey of continuous transformation

# data[].attributes.attachment_link.description
At the outset, the organization was traditionally structured along functional silos, which carried out different parts of a single process without the benefit of having a complete view of its execution. This way of working proved inadequate for the bank's new challenges and prevented a "liquid" resource pool where people could be assigned to the highest priority projects or processes at any given time.

# data[].attributes.headline
Key insights/surprises: Tesla operates like a software company. The system is in constant beta state, with expected bugs. (Anne)

# data[].attributes.subject
Key insights/surprises: Tesla operates like a software company. The system is in constant beta state, with expected bugs. (Anne)

# data[].attributes.body
- But Tesla owners understand and prefer to have such cars with defaults instead of waiting for vetted vehicles in few years.

- factories process can be updated anytime to integrate an update, resolve an issue, etc..

# data[].attributes.body
In DBS, people are working in silos and pointing fingers in meetings. No collaborations and decisions made by HIPPOs. They introduced BEANs to encourage right behaviours, clear goals and introduce team tap to give staff time to experiment and do different things. BOS has similar problems experienced by DBS and i am positive with the clarity and clear connection between behaviour and strategy, we should see similar success achieved by BOS

# data[].attributes.body
Key insights:
- Agile was introduced in 2015 based on customer behaviour only. Company financials were good, there was no business/financial imperative.
- Leadership team spent a lot of time in being a role model and ensured cultural change happened.
- Use of the peer-to-peer hiring approach used by Google whereby colleagues recruit for others, only a veto right can be applied.

# data[].attributes.body
Key Insights / Surprises:
- As Spotify scales, they moved away from Scrum to Agile and built Autonomous Squads to improve the decision-making efficiency. However, all the Squads are still aligned to the overall Corporate Goal.

- Spotify believes that Alignment enables Autonomy – contrary to the belief that they lie on 2 ends of the spectrum.

- Aside from Squad, Spotify has Tribes, Chapters and Guilds within their Community which are less familiar structure.

Reflection:
At BOS, with the many different stakeholders and departments, it might make sense for us to build Autonomous Squads as well. Since each Working Group would have their own goals and problem statements, the practice or tools used should not be standardized. We should just be guided by the Corporate Values and Outcome for better efficacy.

# data[].attributes.body
DBS started at rock bottom - the lowest customer satisfaction scores in Singapore, 3rd CEO in 5 years etc.
- This shows that no matter where you are in the spectrum you can always make a change and emerge successful!

3 Key thing s DBS did:
a) Go digital to the core - drove digital tech all through the bank
b) focus on customer - embed themselves in the customer journey
c) Systematic Cultural change - act like you belong to a 27K person startup

MoJo (to make meetings more collaborative) - every significant meeting follows this ritual.
Mo - Meeting owner
Jo - Joyful observer
DBS recons that they saved a half minion employee hours by having more effective/efficient meetings.

Remarkable how they didn't just go swap people to build their success rather they got people to think and act differently.

In BOS, most of these changes can be easily implemented.
You can purposely change culture by introducing multiple clear elements.
Clarity
Be Clear in your intent and language.
Be clear in the connection between the behavior you are trying to enable and what the organization is trying to do
MoJo ritual will certainly make a huge impact.
Decisions not being made necessarily by Hippos.

# data[].attributes.body
- FBI used to have such an old IT system from the 80s that no one used
- Post 9/11 in an attempt to upgrade their IT systems, they spent (wasted) 8 years and USD 475m of taxpayers money in upgrades that were never used!

Enter Agile....
- Contracts reduced from existing 220 to 40
- Budget was slashed to USD 20m
- Time to achieve slashed to 20 months until full implementation
- They used the motto of " 80 percent of the value in any piece of software is in 20 percent of the features" to focus on getting the 20% done.
- Focused on scrum (2 week cycles) of increments

In BOS context:
- From all the requirements, weed out all the items that are not a priority
-prioritise by value
-stick to the sprints and implement them
- whatever doesn't work, get rid of it
- showcase to the people that use it
- DON'T FORGET HOW IT STARTED (agile) OTHERWISE IT'S NOT AGILE, THE NAME ALONE DOESN'T MAKE IT AGILE

# data[].attributes.body
In 2009 DBS had the lowest customer satisfaction score and today DBS known globally as a digital and innovation powerhouse.

How it transformed:

Cultural change and work as a startup mindset with the 5 identified characteristics:

Agile, Learning organization, collaborative, data driven, experimental

DBS introduced methods such as MOJO to improved meeting collaboration and BEANs to overcome blockers that stops people to adapt to the digital oriented and encourages the above behaviours.

DBS also noted on the root cause analysis such as:
Lack of common language

Decisions were being made by HIPPO’s

BEANs and two elements required to make it more effective.

Clarity on the intent and language

clear Connection Between Behavior and Strategy

Reflection:
In BOS, with clarity on the intent and clear connection between behaviour and strategy, we should be able to achieve what we are driving to. Tools such MOJO for effective meeting collaboration and BEANs to encourage right behaviours can be useful .

# data[].attributes.body
DBS transformed the organization culture in Piyush Gupta's leadership and transformed itself into a digital powerhouse

From Mojo meetings to BEANs, funding to learn new skills & culture canvas - the story of digital & cultural transformation at DBS is truly inspiring

# data[].attributes.body
The CEO of DBS had a very clear approach and wanted to transform DBS. With all the actions taken, in hindsight, this was a successful journey and driving the culture.

# data[].attributes.headline
Lonely Planet Legal Affairs  - Sheherazade (Sherry) 

# data[].attributes.subject
Lonely Planet Legal Affairs  - Sheherazade (Sherry) 

# data[].attributes.body
The move from working at desks till midnight, different time zones, and constant interruptions due to assumption of Legal team not doing anything - to AGILE: tasks being listed to assess workload, standups, and getting external team members to understand the new way of working stands out. Abandonment of long term goals in favour of innovation of new systems to get work done.