An Interview with the Authors of "Stand Back and Deliver: Accelerating Business Agility"
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Stand Back and Deliver – Accelerating Business Agility is written for leaders and provides a toolset to help them capture their organization's strategy and use that information to make decisions. In this interview with the authors they share some of their thoughts and insights to will help you, the reader, determine if this book would be useful in your context.
Who should read this book? What should they expect to get out of it? Is this book useful if you are not high up in the food chain?
We have tried to write this book to deal with leadership issues. However, leadership issues impact followers as well. Decision filters are a good example. For decision filters to be effective they need to be used by people making decisions, i.e. everyone. We have found that it is easier to lead people if they understand how and why they are being led.
What we hope people get out of this book is a set of immediately usable tools they can use to improve their focus and generate sustainable results. People should not expect that this book will give them a detailed prescription for solving their challenges. Instead, they should expect to learn about concepts and models that they can apply to their wide range of situations. For example, the business value model is a common-sense, immediately usable way to improve decision-making. Once readers learn this model, they can use it on project decisions, process decisions, product decisions, market decisions, strategy decisions, and everything else. The book does not tell them how to make a product decision, it teaches them how to, in general, make better decisions.
We have seen leaders put these tools to work within hours, helping them solve difficult confrontations, reaching a way forward, giving ownership, helping people find common ground, and deliver. Collaboration helps teams find solutions they can work on together - finding where they have common goals and objectives. We don't see many organizations today that deliver products and services in isolation. These tools help break down silos and get input from valuable views to innovate.
We have seen project managers take these concepts, apply them to their projects, and improve the project results. We have seen functional managers in human resources, IT, product management, finance and accounting, et cetera use these concepts to improve their internal processes and results. We have seen executives apply these models and tools to their entire organizations and improve organizational focus and financial and market-share results. The models seem to work at all levels in the organization.
A neighbor of Niel’s purchased a copy of the book. He is a high school Spanish teacher. He told Niel a few days later that he and his fellow teachers were using the principles in the book to improve their teaching and student performance. We can't figure out what he got from the book but, evidently, he feels like it was worth reading.
The bottom line is that everybody should buy and read this book.
1) There are four authors on this book, one model, and several great examples. How long have you been using the model in this book? Have you been working together on projects or independently?
The four of us have not worked together in the traditional manner. We have collaborated on several unconventional projects such as this book, the Agile conferences, and the APLN. As we met and learned from each other, we quickly realized how well our individual approaches worked together and complemented each other. We worked independently from each other trying to make sure that our projects and initiatives delivered value. We each developed models and thought processes that worked. Our separate solutions and models relied on principles that were common to what we were doing. As soon as we became familiar with each other's work, we knew that it made sense to collaborate and bring them together. Together, the models cover the wide range of issues that organizations and teams face today.
The tools in this book are a result of our collective 90 years of experience leading projects, teams, and organizations. The purpose alignment model, first identified in 2002, asks the team or organization to answer questions about where they should focus. The collaboration model and process, first put to use in 1970 on a manganese mining project and later used in the delivery of control systems for ABB and on the Swiss Electronic Stock Exchange, is the best way to gather and prioritize the cross-functional inputs that purpose alignment needs. The context leadership model, identified in 2002, is a pragmatic, highly effective way to analyze risk and its impact on current and future decisions. The business value model tool is a synthesis of all of our experiences relating to effective decision making.
Does this approach recommended in this book need any form of software process underneath to allow the organization to benefit, or will this work even with traditional (waterfall) environments?
When we consider the projects we have managed, both agile and waterfall, all of them would have benefited from better decision-making, better alignment, improved collaboration, and a simpler, better understanding of risk. The models work well for all types of projects, initiatives, and organizations. We have seen others use our models on projects as disparate as software development, construction, manufacturing, and organizational development. In one architecture firm, they used a waterfall model for design. As they began to collaborate with designers and customers, they saw a 90% increase in revenues in one year.
The Context Leadership Model actually provides some guidance as to what type of process may be the most appropriate for a given project, so the requirement for this model to work isn't so much a specific process as it is an acceptance that one size does not fit all and a willingness to use different approaches in different situations.
In chapter 2 you suggest that alignment to purpose is the most important issue and that non-alignment will get people in deep trouble. How does this fit with the 'alignment trap' (http://www.infoq.com/news/2009/02/alignment-trap) which basically says that if you try to become aligned before being technically fit then you'll end up losing and actually performing worse than when you started?
One of the points made in "Alignment Trap" and by others (such as Nicholas Carr) is that it is possible to over-invest in IT that does not generate business value. This not only creates waste but also over-engineering, over-complexity, and IT becoming a stumbling block and bottleneck. Purpose Alignment is a very pragmatic, common-sense way to identify what parts of IT truly differentiate the organization in the marketplace and which parts need to achieve and maintain parity. In other words, what IT functions and capabilities should I make better than my competitors? This applies to "fixing the machine" as much as it does to defining features and functionality. In this context, Purpose Alignment can be a powerful tool to use to identify which parts of the IT machine need to be fixed and how good the machine needs to be.
What is important is to have solutions that fit business needs being developed by teams that are technically fit. Using our own dogfood, technology fitness for most IT organizations would be considered parity. Skills need to be good enough and on par with the industry standard, but in only a few organizations and on a few key projects do the technology skills need to be differentiating. However, at many organizations the IT technical fitness is below parity. These organizations need to get on a fitness program to bring the skills up to parity. For other organizations there really is a need to be differentiated based on technology. But even in this case the differentiation will flow from a differentiation in the business.
The idea of 'filters' to communicate the guiding strategies for an organization is wonderfully simple and seems to be extremely powerful. Can you tell someone who has not read the book what this is and what problems it solves?
Every day, people throughout the organization, especially those closest to the edges of the organization- the market and customer needs, need to make decisions. A filter gives those people a way to check if their ideas are in line with the direction of the corporation.Will this help us differentiate us in the marketplace? Or, will this be something that we need to do well but not better than anyone else? That is the value of defining the decision filters and then communicating them throughout the organization.
As an example, one company was struggling with a way to evaluate where to invest its resources. This company had plenty of opportunities but where should it focus its investments? We sorted through the options, the competitors, and customer types and identified a single decision filter the company could use to align its decisions with its strategy / sustainable competitive advantage. This focused the company on how it differentiated itself. This decision filter was: "Will this help us secure long-term supply contracts?" The management team communicated this filter to all levels of the organization and people started to use it. That was three years ago and the results have been outstanding. Growth rates have tripled and the company has expanded into areas that are not a distraction but continue its sustainable competitive advantage. Along the way, the company has learned to accept that it does not need to excel at everything. It accepts "good enough" and focuses its innovation on those things that will help it secure long-term supply contracts with its customers. Best of all, by pushing this decision filter down to their employees at their manufacturing sites, the employees can make immediate, nearly instant decisions without having to route them and back to get approvals, opinions, and direction. As a result, they make rapid but strategically-aligned decisions.
The key with decision filters is that they need to be actionable and they really need to be filters. If the filter is nebulous, such as "make great software," it won't be very effective. Another aspect that is key to an effective filter is that everyone needs to know what it is and what it means. At Landmark Graphics we set out the vision that we were going to be differentiating by providing improved integration across our software line. We made sure that everyone knew the importance of integration, and then we recognized that to integrate the software we needed to do a better job of integrating the people and the teams. Then, we invested in bringing people face to face and in reiterating the importance of integration. These actions demonstrated the commitment and investment and there was very strong buy in. The teams delivered remarkable results and the result was substantial market growth.
The authors of this book are leaders in the Agile field, yet I notice very little (if any) familiar Agile practices and many of the Agile values. Are the practices so far described in the literature ineffective? Or are they at the wrong level, i.e. they are more tactical than strategic for the purposes of your book?
Most of the "familiar" agile practices deal with better ways to manage work and perform the technical practices involved with software development. Using these agile practices, a team can do a really good job of delivering a project that is over-engineered and overly complex. But, if that team can use the tools in our book to determine that the purpose of the project is to achieve parity, not differentiation, they will deliver the right project in the right way.
We have all been active in the Agile movement and believe in the values, principles, and practices. That being said, we are not Agile zealots; some of us aren’t even comfortable being named as leaders in that field. We are pragmatists. When we set out to write this book, our focus was on the culture leaders can create and tools leaders can use to support an agile, adaptive organization. We wanted to suggest some pragmatic approaches to doing the right thing in the right context, when those agile approaches are most appropriate, and ways to unleash the talent within teams by letting them decide which practices work best.
You claim that project decomposition is one of the best ways to reduce risk. Tell us a little about this. Is this contrary to the idea of building things end-to-end instead of decomposing into components? What about the complexity that lies in integration – the inevitable problems that arise from decomposition and only show up when components are put together?
Obviously we don't want to trade one form of complexity for one that is just as bad or worse. The issue of team decomposition is similar to that of software component decomposition using principles of loose coupling and strong cohesion. We want project teams that are working on similar aspects (cohesion) and where the teams have well defined interfaces across projects (loose coupling). The project management challenge becomes one of managing the interdependencies at those interfaces and allowing the individual teams to work within their areas in a manner most efficient for their needs.
The value of this insight to risk reduction is recognizing that it is possible—in fact, desirable— to break high risk projects into less complex, less uncertain components. Too many of us have aged and exhausted ourselves and our teams working to deliver highly complex, highly uncertain initiatives. But segregating those initiatives based on complexity and uncertainty allows us to focus on specific ways to mitigate the risks associated with complexity and uncertainty. Using this approach has helped us reduce risk on both IT and non-IT projects. For example, we recently finished a project that had a high degree of technical uncertainty—we were playing on the bleeding edge—and a high degree of process complexity. We reduced our overall risk by loosely coupling the technical uncertainty with the process complexity. We used agile methods to go through multiple, rapid cycles of pilots and tests with the technology while we used lean tools to sort through the process complexity. What seemed like a very daunting, nightmare project fell into place very nicely. No one died and everyone was very happy with the result.
Of all the skills you discuss in your book, which is probably the most lacking in organizations (both Agile and traditional) and what is the effect on the organizations?
Interesting question—the most honest answer is “it depends”. The key is to recognize your biggest pain at the moment and apply the appropriate tool. In addition to sarcasm, the effects are typically an inability to deliver as much value as desired, through longer delivery times, misaligned initiatives, or wasteful processes. Three skills we see lacking more often than not are the proper balance of collaboration and purpose, the ability to trust, and the ability to keep things simple.
The organization that encourages collaboration but struggles with its purpose generates a "kumbayah" culture that may feel good about working together but has no sustainability as they wander from one idea to the next. On the other hand, the organization that does a good job with defining its purpose, but does not foster collaboration is not tapping in to the full potential and is usually stifling creativity and innovation. Too often we find many basic skills missing. Followers have high expectations of leaders and when those expectations are not met it leads to a lot of sarcasm. Lack of trust can be extremely debilitating in delivering results and fostering innovation. As we work with leaders, they believe they are trusted by their peers but they do not feel they are trusted by those higher up in the organization. Without trust, people cannot take ownership. Without ownership, their productivity will fall as their motivation decreases. We are still a culture that micromanages, even through we know that this is debilitating and reduces productivity. Our tools help leaders transition to a more responsive and adaptive organization, where people are valued and are able make full contributions to their success and the success of the organization. The Fortune 100 Great Places to Work research shows that the 100 high trust companies out perform the next 100 lower trust companies by 43%. The price tags for lack of trust are high.
We have observed a natural, human tendency to over-complicate pretty much all that we do. Much of what we discuss in our book deals with simplification and the tools and skills that help us sort through the chaff so that we can focus on what generates the most value. Lacking the help that our tools provide, organizations suffer from a range of issues. One example is what Niel describes as strategy ADD. The organization whipsaws around, pursuing the opportunity or program of the day and, as a result, never pursues what could be its sustainable competitive advantage and never excels at anything. Another example is a type of organizational constipation (that is not a very pleasant analogy). There is so much complexity in how the organization makes and implement decisions, in its internal processes, and in its operations that the organization cannot respond to changes in the marketplace. Both of these create cynicism among and sap the energy of the members of the organization and cause the organization to never be as good as it could be. If leaders would use the tools we describe in our book to develop the skills to both focus and simplify actions and decisions, they would unleash the power of the organization while having a great deal of fun.
Are there any questions that I should have asked and didn't? Please ask and answer.
Why should leaders who are already successful use these tools?
First of all, these tools are not about changing your leadership style. They can help you in fast changing, high pressure situations where you might need a new way to move forward. These tools can be used in many different circumstances, and can reduce the churn to increase speed to market. They are simple and easy to use. At IBM, one product's road map is done over 2 years. In the past, it took the team 3 months to build this map. Using these tools. they developed the road map in three days! Think of the time saved from the team! And, an entire quarter was spend delivering instead of churning.