Book Read Free

Leading Exponential Change

Page 20

by Erich R Bühler


  If a technology department is affected, many will try to measure the relative improvement in the tools, increase in unit testing, time for product integration, and decrease of defects.

  When the purpose for the change initiative is forgotten, executives will try to get their questions answered by requesting more performance measurements in the affected areas, or the exchange between those areas and the rest of the departments. The result could be data reflecting an increase in efficiency in the measured team while the rest of the company is negatively affected, increasing the complexity of the organization and waste in its processes.

  The previously discussed metrics have an impact on the client, but they are not adequate for evaluating transformation from the business point of view. Seeing the question from different perspectives is essential, and focusing on the impact of the change is crucial. How will this change help the business better serve its purpose?

  Answering this question requires an understanding that the change could have an indirect impact on external customers and a direct impact on internal departments. Measuring the transformation involves an awareness of the exchange between the impacted department and the rest of the company, as well as clearly establishing a cause-and-effect relationship.

  You might think there’s a relationship between the amount of ice cream sold and jellyfish stings, but this is far from being a true cause-and-effect relationship. For this reason, you’ll have to facilitate workshops where people are exposed to different metrics and are able to experiment with them. This will allow them to feel comfortable experimenting with diverse metrics, challenging initial assumptions, and ensuring that they’re measuring something useful.

  There are three types of metrics you might find useful:

  Business performance metrics (often called KPI or Key Performance Indicators).

  Organizational health metrics.

  Habit-improvement indicators or driver metrics.

  Business performance metrics indicate what will matter to the clients or influence improvements in their lives. If consumers can’t distinguish changes in the metrics, then they do not belong under business performance. It’s common here to define a range and for executives to worry when the metrics fall below an established threshold. The number of updates of a product and a client’s level of confidence could be an example of a direct cause-and-effect relationship.

  Health indicators, on the other hand, are normally internal and refer to habits and aspects of the organization that will directly impact the interactions and mental health of employees. They affect performance metrics, but they aren’t directly perceived by clients—although they could be indirectly noticed.

  Habit-improvement indicators refer to actions that influence behaviors and help to achieve new and better conduct. Once the indexes have indicated that a goal has been achieved, they tend to disappear. Normally, these metrics are local (used only within teams) and help to visualize what teams should improve in their day-to-day work situation.

  One of the risks of habit-improvement metrics is that they can lead to local optimizations, where improving a habit in one team can harm another.

  In general, metrics on organizational health and habit-improvement indicators are used within the Transformation Team and help those groups to change, while business performance indicators help teams answer the following question from executives: Is there concrete evidence that the effort will result in a positive and sustainable economic impact on the company?

  All managers and executives should understand the business performance metrics, as should others involved in the change. The transformation of traditional companies toward new ways of thinking and behaving usually implies a cultural change that requires an understanding of new values and principles.

  Remember that face-to-face communication and feedback should always take precedence over the use of indicators, especially with executives and middle managers. This helps us to reason based on a collective understanding of objectives, practices, and processes. It also makes it possible to collectively think and encourage actions that improve reward systems, promote techniques that decrease resistance to transformation, and get everyone to reflect on how to replace scarce areas with exponentials.

  Express Team Liftoff… Shaping a High-Performing Team in Record Time

  By: Stefan Sohnchen, Business Agility Coach

  A team messed up at its foundation cannot be fixed. Hence it is important to nail the culture right from the start. We know successful sports teams work hard on building their performance. We know that successful orchestras are similarly built on focused effort to build a well-arranged foundation. But in the workplace at the office we often assume that high performing teams just emerge because they have to. In reality it needs a lot of structured effort for people in office settings to become high-performing teams.

  When looking back at working in a team setting, characterized by a well-formed foundation years later, you will realize that you will have forgotten what people said, you will have forgotten what people did, but you will remember how working in such a team made you feel.

  Let me tell you about such an occasion from my own experience. A couple of years ago, I worked with Joe Justice and Tim Myer, both well-known Agile Coaches, on an Agile Transformation for Tait Communications in Christchurch, New Zealand. Back then Joe and Tim worked as consultants for SolutionsIQ in Seattle and they were members of Team Wikispeed.

  A Team Wikispeed is a global team of enthusiastic agilists creating super-efficient commuter cars. You can read more about it here: wikispeed.org

  While Joe has joined Scrum Inc. since, both he and Tim are still with Team Wikispeed.

  The Tait Communications delivery team we worked with was cross-functional, using Agile project management techniques, Scrum, eXtreme Programming, and extreme manufacturing. There were software developers working with hardware developers, working with marketing, working with sales, etc. The close-knit setting that we managed to achieve produced a positive vibe that made people flow and get on with what needed to be done as traditional dividing lines between functional departments had become highly porous.

  On day one, the team created a prioritized list of Tait’s customers’ wants. Four days later, the team had a working prototype of a new radio, a customer in the room with the team using that prototype, and a cross-functional team getting direct customer feedback faster than they ever had before.

  In the previous “phase gate” model, the customer feedback loop would have never reached the engineers and the prototype would have taken at least 3 months.

  How was this possible? It was possible because we started out with what is known as a Team Liftoff in the lead up to the week we worked with Joe and Tim.

  Running a Team Liftoff is a golden opportunity to set ground rules and establish the structure—or lack of one—in which things get done. Think this through with a 2 x 2 matrix. On one axis you have highly trusted team members and less trusted team members. On the other axis you have a low alignment structure with poorly set rules, and then a high alignment structure where the rules are well set. The combination you want to aim for is ‘high trust’ people with a structure that provides a high degree of alignment.

  Trust and Alignment Table

  As a result, people are rowing in the same direction, and not by accident. The team members are in sync, and henceforth, they can move on to the rest of the equation.

  The one-day event of my express Team Liftoff starts with reiterating the purpose—Why are we doing this? This is tied in with the company’s roadmap—How and what will we do?

  Make it fun and invite people to come up with a name for their team. This is followed by the team creating their own Team Charter—a type of loose yet binding contract—to agree on the ground rules and factors that will make your team successful.

  Once this is in place participants are given an overview on what it means t
o work in an agile way—or any other preferred way. Moreover, this is to align all team members in their understanding of the mindset required to succeed under the conditions of exponential growth opportunities.

  As the facilitator or part of the Transformation Team, you want to quickly move on to team building and people getting to know each other through encouraging individuals to share interests and motivations.

  Combine this with holding a Skills Market activity to see if the team has what it needs to succeed. Only then—and if you are planning to use the Scrum framework—should you suss out how you will work together in terms of Sprint Cadence and Daily Scrums.

  While you can get through all the aforementioned during the first half of the day, focus on the Backlog Refinement and Stakeholder Mapping after lunch. Make sure you include the following people: customers, stakeholders, partners, the core and supporting teams. This will help you with identifying dependencies and agreeing on the best communication tools for your situation

  You want to end the day with building a first version of your activity wall, or high-level view of a couple of Sprints out from where you are right now. Of course, don’t forget to reflect back on the day by running a retrospective. At the end of this one-day express event, people will be exhausted as much as they will share the feeling of having accomplished important things together.

  It is safe to say that without the express Team Liftoff at Tait Communications we would neither have been able to build the Sprint Backlog on day one nor deliver a working prototype on day five.

  A Team Liftoff is not simply a technique for fixing a broken team. In fact, for any team—regardless of whether struggling to perform or high performing teams that leave everyone else behind them already—there is value in pausing to sharpening your axe.

  A close cousin of the Team Liftoff is the Team Reset. Unlike the first, typically aimed at getting the team off the ground at the start of an initiative, the reset event aims at working with a team that lost its oomph while Sprinting for some time. The same structure applied for an express Liftoff can be tailored to re-energize a team at any time.

  My experience with Liftoffs over the years is that you best work with a tailored approach rather than an off-the-shelf textbook structure.

  Before running the liftoff it pays to invest time into understanding what really matters for the team, where they think they would get the biggest gain from pausing their day-to-day routine to reflect on their actions. An express liftoff well done will result in a return on the cost of losing one delivery day because the team will be enabled to collaborate more efficiently further into any project or initiative. Try it!

  What You Have Learned

  How to establish alignment and common understanding.

  The characteristics of a Transformation Team.

  The reciprocity pattern.

  How to use Impact Mapping.

  How to establish values, working agreements, and principles for a change initiative.

  Three types of metrics.

  Do you remember at least three characteristics of a Transformation Team?

  What objectives could an experiment have in your company?

  What questions does an impact map help answer, and in what situations could you use it in your company?

  What are the three types of metrics you could use?

  “Creative thinking inspires ideas. Ideas inspire change.”

  Barbara Januszkiewicz, Artist

  Chances are that your company has been looking for work styles that will allow it to quickly adjust to cultural changes and exponential market disruptions. If you add the effects of robotics, Big Data, cloud network, and always-connected consumers who provide constant feedback, then the result is constant pressure on every part of your organization.

  In the previous chapters, you learned why change doesn’t take place as fast as you might think. During the first months of a change initiative, executives mistakenly believe they can quickly deliver business value to customers without compromising the stability of the company. But the adjustments produced by an organizational transformation impact every department and can make processes ever-more complicated.

  Many managers and executives have taken a step in the right direction by using the Agile and Lean mindsets, the Scrum framework, or Kanban techniques. But we must keep in mind that Agile originated in 2001 as a collection of values and principles for solving problems in software departments by adapting and learning faster and creating better applications that deliver more business value to the customer.

  Today, you must go beyond Agile and Scrum if you want to transform the whole organization.

  Differences Between Agile and Business Agility

  Companies face the challenge of adapting Agile values and principles, as well as Scrum framework techniques (usually in the areas of IT), so that they fit with the rest of the organization.

  You’ve probably also heard about Business Agility—techniques that can be used not only in IT departments but also throughout the company.

  The Agile Manifesto for software development was created in 2001 to help companies create better software. Learn more here: en.innova1st.com/70A

  Table 7.1 shows the differences between the Agile and Business Agility perspectives, so you can understand where to use each approach.

  Agile

  Business Agility

  Focuses on making IT teams more flexible and adaptable to change.

  Focuses on organizational design aimed at making the whole company more flexible (structures, forms of governance, budget, etc.).

  Scrum, Kanban, etc.

  Creates new ways of working throughout the organization.

  Projects, products (fixed cost, variable cost, etc.).

  Changes the way business value is created by modifying existing value streams.

  Introduces a way of thinking.

  Challenges every existing organizational belief.

  Focuses on how the work is done (sequence, batches, etc.).

  Provides ideas to alter people’s patterns and behaviors throughout the company.

  Establishes the foundation for forming excellent software teams.

  Sets the foundation of a remarkable company.

  Table 7.1: Differences between Agile and Business Agility

  Successfully transforming a company, starting with IT teams and using Agile mindsets or the Scrum framework, requires that you do the following:

  Identify and adapt the practices and strategies from software departments so they can be used in non-IT areas of the company.

  Know which areas will offer greater or lesser resistance to change.

  Know which practices will not require any adaptation when used outside IT.

  Have in mind that changing or scaling an organization, scaling Agile, scaling Scrum, building new products or even developing new software, should never be your end goal. Your goal should always be to adapt as fast and effective as possible, to be able to deliver the most business value and greatest customer experience.

  The Seduction of Tools

  During the steps before a business transformation, companies frequently focus on a particular methodology, tool, or software that will help accelerate cultural change and create a more flexible organization. I have seen large companies invest millions in software tools that promised to speed up transformation. You will need some of these tools as you become an exponential growth company, but for cultural change, you need to pa
y attention to other factors.

  Many Transformation Teams, or sometimes even management, believe there are shortcuts to get employees to adapt more quickly. This often results in recommendations for team training, continuous improvement, process engineering, quality-control programs, cultural alignment, leadership development, and the like. I’ve even heard suggestions that the installation of a new software system (personnel management, tickets, defects, communication software, etc.) would solve most of the dysfunctions.

  I have visited companies where it was believed that the more sophisticated or expensive the tool, the faster the cultural change would be. You have to ask: Is your company using tools, or are the tools using your company?

  This is what we call the seduction of tools, a recurring trend you will find during the first months of the transformation of a business. But the real problem isn’t the tools themselves.

  “In the same way that music comes from the musician and not from the instrument, business adaptability comes from the people and not from the frameworks.”

 

‹ Prev