Commanders know the objective; leaders grasp the direction. Commanders dictate; leaders influence. Controllers demand; collaborators facilitate. Controllers micro-manage; collaborators encourage. Managers who embrace the leadership-collaboration model understand their primary role is to set direction, to provide guidance, and to facilitate connecting people and teams
—Jim Highsmith (2000)
All of the agile practices we apply, from scrum and kanban to big-room planning, are just that—practices. They are the result of the incremental discovery, over decades, of challenges with prevailing methods, and of trying different solutions to address those challenges. As we’ve inched toward what we now call agility, we’ve tried, and accepted or discarded, many ideas that we thought might alleviate the issues we found with predictive, big, upfront plan techniques. We’ve codified certain sets of practices, like scrum or XP, often as a set of rules to follow. We’ve come a long way from the faulty ideas that held us back, like the hubris to think we could predict the future and put a firm fixed price on it. Many enterprises have evolved substantially toward a lean, agile set of methods that, taken together, lead them to believe that they’ve achieved agility.
The application of methods and practices, even for teams that have evolved to agile strategic and big-room planning , is still “doing agile.” Our teams and leaders have learned and internalized the techniques and tools of agility, and they are seeing results from their efforts. The enterprise is not truly agile, however, until both the leaders and the ultimate customers have made the transition from “doing agile” to “being agile.” Agile theorists, from Mike Cottmyer and Michael Sahota to Jim Highsmith, have addressed this issue of migrating to an agile mind-set across the organization, and thus enabling the enterprise to truly be agile. As with any transition that is about more than just following a set of rules, and requires a change in attitude, behavior, and perspective, it’s easier to learn the moves than it is to become adept. We’ve heard, from second grade on, that we need to learn the rules before we know enough to break them properly. Learning the rules, however, is necessary but not sufficient. To go beyond blindly following rules to the adaptive mind-set required for enterprise agility, executives and clients must abandon traditional ideas and embody a different approach to leadership. Leaders and customers, and the teams that deliver value to them, need to go beyond the “know how” and internalize the “know why.” For the agile consultant, the ability to both coach the enterprise in the know-how required to begin the agile journey and then embody and transmit the know-why that enables agility to permeate the enterprise is the ultimate challenge.
Lean Leadership Basics
When thinking about guiding enterprises to agility, it’s always my inclination to go back to first principles. In agile, my first principles are based on lean thinking. One of the key elements of lean, which we rarely see addressed in agile discussions, is the idea of “leader-standard work .” While I don’t believe that all of the lean ideas and processes included in leader-standard work, heavily weighted to a manufacturing climate, are applicable in agile, a basic understanding of the concept can add significant value to our discussion of the leadership role in agility.
Leader-standard work , in a lean manufacturing environment, is designed to solve a number of problems. In many organizations, every time a new executive, manager, or supervisor joins the team, his initial impulse is often to bring a new set of management techniques, new processes, new metrics, new teammates, and a new cultural style. David Mann,1 whose work is the source of many of these ideas, calls this phenomenon the “new sheriff in town” mentality, and, as anyone who has spent time in a corporate enterprise knows, it can be an extremely disruptive and confounding experience. As an agile consultant, I hear stories constantly about organizations that were in the midst of an agile transformation, only to be pulled back to waterfall when a “new sheriff” showed up in the executive suite. Thrashing back and forth from traditional to agile practices is common in many companies, as different leaders and different silos either embrace or resist agile methods, and as the difficulties of migrating to agility start to emerge.
Providing a standard set of expectations for leaders helps protect teams, and the organization, from this sort of thrash. When we define the leader’s set of responsibilities, from the immediate product owner and scrummaster to the executive suite, we set a baseline of behaviors and attitudes that are applied regardless of personality. One of the known wastes in any process is variability, which can subvert the gains made by lean and agile adoption. When new leaders know that the option of throwing the cards up in the air and starting over is not available, the risk of disruptive variability is diminished.
Leader-standard work also has the advantage of making agile leadership qualities visible. As with our big visible indicators in agile team practices, leader-standard work provides transparency at the executive and management levels. Existing managers who are unwilling or unable to make the transition from predictive, hierarchical styles to adaptive, collaborative styles will be recognized quickly, and can be trained, reassigned, or managed out as required. The whole point of agility is to evolve from a “hope and wish” corporate mentality in which we wait for leaders and teams to “get it”, to a transparent, reality-based conversation that enables kaizen and action. The clear expectations of leader-standard work allow executives to make quick decisions about their talent, address them, and avoid the risk of delay and confusion that can result from active or passive resistance.
Leader-standard work is based on a few foundation ideas. The first is that leaders work in a complementary fashion, with the leader at the team level managing execution of each task, the supervisor spot-checking work periodically throughout the day, the value stream manager managing daily accountability and managing resource capacity and issue resolution, and executives reviewing trends, performing Gemba walks (management walkthroughs of the work site), taking ownership of quality produced by the entire value chain, and leading kaizen efforts. The second key idea is that this work is driven by a neatly defined set of processes that drive the daily activities of each leader in the chain, with the intention of developing a set of best practices for leaders to follow.
The language applied in lean manufacturing differs greatly from the agile lexicon, but many of the basic concepts remain. Leader-standard work typically refers to supervisors, value stream managers, and plant managers, while we talk about scrummasters, product owners, and executives. Leader-standard work refers to things like shift changes, Gemba walks, and buzzer-to-buzzer spot-checks, while we use velocity, detours, blockages, and big-room planning sessions in agile leadership practices. Despite the differences in language, lean concepts still apply. We still measure daily progress, but instead of buzzer-to-buzzer meetings we use stand-ups. We still manage progress across the iteration or cycle, but we do it in sprint planning and demo sessions instead of Gemba walks. We still collaborate to improve blockages and inefficiencies, but we do it through retrospectives and scrum-of-scrum sessions, rather than supervisor “tier 2” sessions. For more detail on the fundamentals of leader-standard work refer to Mann.2
From Lean to Agile
Lean thinking is the basis for agility, but agile was designed for software development, and has mutated significantly from original lean concepts. While collaboration, customer focus, self-managed teams, and kaizen originate in lean, the Agile Manifesto and Principles originally evolved to correct deficiencies in predictive software development . Enterprises have now discovered that these ideas can go far beyond the software team, but the original principles addressed technical architecture, iterative development, working software, and changing requirements. Many of the artifacts of lean manufacturing don’t apply in agile, and agile has simplified lean practices significantly. While “simplicity”—maximizing the work not done—came from lean, a walkthrough of many lean manufacturing enterprises can look anything but simple, with dozens of charts, checklists, sign-ins, and pitch charts scattered around the plant. While the same can be said of scrum rooms and kanban boards, the process focus of lean manufacturing has been replaced by a less prescriptive “inspect and adapt ” mind-set, less likely to focus on multiple daily quality and progress spot-checks, and more likely to vary widely in implementation based on local conditions and decisions. Agilists would much rather talk about the expected behaviors and mindsets of executives than about leader-standard work. So where does the twain meet? The opening quote from Jim Highsmith can be applied equally to lean or agile, but the practices required for effective agile leadership differ. Let’s take a look at the roles and mindsets expected of different leaders in the agile enterprise, and see how those can be both harmonious and divergent from lean practice.
Every agilist knows that scrummasters and product owners each have defined areas of responsibility, with the scrummaster owning the process of scrum or agile, and the product owner representing the client’s interests in developing the product. Undefined in the Scrum Guide or in most other agile literature is the equivalent of leader-standard work . We’ve looked at various scrum scaling frameworks , some of which, like SAFe (Scaled Agile Framework 4.0), attempt to address the question of leadership standards by prescribing a clear set of roles and responsibilities, from the Portfolio to the Team level. In this scaling strategy , as illustrated in Figure 9-1, roles from Portfolio Manager to Epic Owners at the Portfolio level, through Value Stream Engineers, Solution Architects, and Release Managers at Value Stream level, Release Train Engineers and System Architects at the Program level, and down to the product owner and scrummaster at the Team level, are designated by the framework. As we’ve discussed, many agilists find this prescriptive model too similar to a corporate hierarchy for their taste.
On the other end of the spectrum, Ken Schwaber3 describes an organic scaling strategy in which one agile team begets others, which then multiply and scale further, rearranging the product backlogs so that subsets can be assigned to new teams. The original team now becomes an integration scrum team , with the mission of taking responsibility for all the new scrum teams and integrating their efforts into a quality product. New scrummasters report to the original scrummaster, and new product owners report to the first product owner. This becomes a natural hierarchy, in which the original team spawns new teams, new scrummasters, and product owners, and those teams in turn generate additional teams, with responsibility for overall product conformance and quality reaching up the chain. Nowhere in Schwaber’s description is any role defined for executives, whom, it is assumed, focus on strategic direction, and on exhibiting the collaborative qualities outlined in Highsmith’s quote opening this chapter.
Somewhere on this spectrum lies the appropriate vision for leadership in a particular enterprise. It’s the agile consultant’s job to help the enterprise determine the suitable model for its unique circumstance. As noted in Chapter 9, SAFe is a great choice for large, complex organizations migrating to agility from a predictive, hierarchical model , while still exercising some control from above, and still performing some predictive budgeting and strategy alignment. Enterprises that are already more focused on egalitarian, participative management, and have experienced some success with grassroots agility, might prefer Schwaber’s organic model . In either case, the mind-set and behavior of managers and executives will still need to evolve. Again, to go back to lean principles, let’s take a look at the criteria for lean leadership set by James Womack, the original popularizer of lean ideas through his bestselling study of Toyota lean culture4:
Lean leaders:
eagerly embrace the role of problem solver.
realize that no manager at a higher level can solve a problem at a lower level—problems can only be solved where they live, by those living with them.
believes that all problem solving requires experimentation.
understands that no problem is solved forever. The introduction of countermeasures will create new problems at some other point in the organization. The critical, probing mind of the lean manager stays active in the pursuit of perfection.
These overarching principles apply in agile as well as lean. Let’s examine them with a bit more focus on agile language and practice.
Eagerly Embrace the Role of Problem Solver
Too often, in my experience, managers and executives play the role of problem creator, rather than problem solver. They drive sales teams to sell more and more, while starving delivery teams of resources. They commit to unrealistic and overly aggressive dates and budgets, forcing teams into “death march” projects that sap morale and disappoint customers. They remain remote from their organization, hiding in mahogany suites on the executive floor with little contact or interaction with the enterprise. As noted in Chapter 2 management resistance and cultural norms are often the key barrier to agile adoption. The traditional, hierarchical style of management we explored in Chapter 2 often leads to counterproductive, adversarial relationships across the enterprise, as individuals jockey for position and hide bad news for fear of reprisal or corporate shunning.
The lean or agile leader displays the opposite of these behaviors. In agile, every bit of bad news is a lesson to learn and an opportunity for improvement. Rewards and incentives are focused on team achievement rather than adherence to discipline and corporate conformance. Executives and managers exist to enable teams to achieve and to remove barriers to that success, not to manage the daily tasks of their teams. Teams self-manage the details of their work, and management creates the environment for them to perform to their highest potential. Leaders address broken processes, lacking skill sets, and ineffective leaders or employees, rather than kicking the can down the road. They manage intake, ensuring that the organization doesn’t commit to more than it can reasonably deliver. The concept of service leadership is key in this context. Agile leaders work for the team, not the other way around.
Problems can only be Solved where they Live
This may seem in conflict with the previous statement, but they’re actually complementary ideas. There are local problems and global problems within an enterprise. Agile leaders must be problem solvers at the global level, working on the repair of broken corporate processes and norms, and must also have the proper amount of Zen to leave the local problems to the local teams and resist the temptation to jump in and prescribe a cure. We’ve learned from decades of lean practice that only the local team has the intimate understanding of the sources of their challenges and obstacles. We also know that ownership of those issues is a key component of team dynamics and enablement. I’ve advised too many teams, disheartened by repeated frustration, that have adopted a posture of “learned helplessness,” learning from repeated failed attempts that any ideas they come up with will be shot down or overruled by management. These demoralized teams will simply wait to be told what to do, and how to resolve their concerns, by managers, always staring upward in the hope that some direction will rain down. This learned passivity is a powerful obstacle to team empowerment, and is especially tangible in organizations that have run the cycle of organizational panaceas, only to repeatedly devolve to previous patterns.
While successful agile leaders want to avoid prescription, that doesn’t imply disengagement. Leaders can provide the forum for collective problem solving, applying big-room planning sessions and “Gemba walks .” The concept of Gemba walks, mentioned earlier, is a central element of lean, and is, I believe, a missing element in many agile transitions. By simply walking around, visiting teams and uncovering their concerns and challenges, executives can project an attitude of caring and concern and encourage teams to let go of the fear of reprisal and blame. They can gently remind team members of their commitment to agility, and provide coaching and direction that improves strategic alignment, without digging down into prescriptive management. MBWA (Management by Walking Around ) is an old idea, but it is institutionalized as the Gemba walk in lean organizations, and is an overlooked tool in enterprise agility.
All Problem Solving Requires Experimentation
The enterprise is, by its nature, a conservative entity, utilizing proven methods and processes to achieve a consistent and repeatable result. Typical organizations have two key fears: risk and change . The transition to agility exacerbates both of these concerns. Agilists embrace disruption, while enterprises avoid it. Experimentation and emergent outcomes are key to agility; predictable results drive corporate planning, with experimentation confined to the research and development function. The continual feedback and improvement loop of any kaizen enterprise makes the basic assumption that feedback will result in change; otherwise, what’s the point? We also assume that we can speak freely and point out deficiencies and inefficiencies without censure. Many executives forget that the proven methods to which they cling became “tried and true” through decades of trying, and cannot be sacrosanct as markets evolve. Strong agile leaders also recognize that kaizen efforts can never reach their goal, which is perfection. Only consistent experimentation in an open, collaborative environment enables improvement. The hierarchical idea that only constant pressure from the top can motivate workers to achieve has been discredited for years, but it is still the ruling philosophy in many enterprises. Agile leaders must be encouraged to drive fear and reprisal from their mind-set and behavior, and accept the reality that risk and change are essential elements of improvement and innovation.
No Problem is Solved Forever
Agile theorists often talk of enterprises as complex adaptive systems (CAS ) . According to an MIT paper,5 “Complex Adaptive Systems are dynamic systems able to adapt in and evolve with a changing environment.” In a CAS environment, everything we touch touches something else, and every change spreads across the system, creating unforeseen circumstances that we then need to iteratively adjust. Systems thinking, a core precept of both lean and agile, reminds us that, as with technology, the bug we fix here has the potential to blow up something there. This is one of the reasons that legacy-bound organizations fail; they fall in love with, and, worse, enforce their own history and culture while the world sweeps by at exponential speed. Those who favor stability over change make the fundamental flaw of believing that the universe cares what they want. Complex adaptability requires us to go beyond merely anticipating the implications of the changes and experiments we undertake. It also requires us to acknowledge that we’ll be wrong most of the time when we try to foresee unforeseen consequences. Kaizen is eternal and systemic.
The cited MIT paper also notes that “complexity results from the inter-relationship, inter-action and inter-connectivity of the elements within a system and between a system and its environment. This implies that a decision or action by one part within a system will influence all other related parts, but not in any uniform manner.” It’s this interactive influence that disrupts predictability, and upsets predictive managers. In the predictive corporate world, one of the worst things a manager can do is keep coming back to the same intractable problems. This is perceived as a sign of incompetence and failure, in the traditional view. Agile managers grasp the idea that yesterday’s solution will soon become tomorrow’s problem, and that challenges, especially in evolving complex enterprises, will circle back around numerous times as circumstances change.
Agile Leadership Responsibilities
The point of this discussion is clarity of roles and responsibilities. Agilists understand the accountabilities that product owners, scrummasters, and teams take on in agile practice, but more ambiguous is the commitment of leaders. To ensure that clarity, I’ve assembled the following list that lays out, in my view, the actions and behaviors that leaders, from executives to managers and team leads, must assume:
Executives :
Determine and communicate enterprise strategy.
Empower and encourage team achievement and ownership.
Ensure that enterprise-level commitments match capacity and capability to deliver.
Practice service leadership, understanding that they work for the teams and not vice versa.
Leave the executive suite to go, see, encourage, and guide.
Take on the hard challenges of enterprise improvement that create the environment for success.
Encourage enterprise-level collaboration, and break down silos and barriers.
Embody the Agile Principles.
Managers :
Communicate corporate strategy and guide team alignment to strategic objectives.
Understand their teams’ capacity and capability.
Protect teams from unreasonable demands and expectations.
Influence executive strategic planning by building a robust feedback loop.
Create a kaizen atmosphere in which dissent, disagreement, and concerns can be freely discussed and solved.
Respect the autonomy of their teams while ensuring alignment with enterprise priorities.
Be a leader and coach rather than a foreman.
Embody the Agile Principles.
Team leads , including scrummasters and product owners:
Respect the agile processes: don’t succumb to the temptation to change the process rather than addressing the dysfunction.
At the same time, inspect and adapt both the product and the process through kaizen methods.
Encourage and sustain evolutionary gains in productivity and quality.
Fearlessly call out unforced errors and gaps.
Create a feedback loop to ensure leaders stay connected to customer-level realities.
Take problems to the team rather than prescribing remedies.
Encourage team-level collaboration, and break down silos and barriers.
Embody the Agile Principles.
Of course, these lists are not complete; whole books can be written about the commitments of agile leaders. While not conclusive, agile leaders who exhibit these qualities will have a head start on evolving their organizations to agility, and to transforming themselves and their companies into open, fearless, honest, responsive, and continuously improving enterprises.
Customers Are Leaders Too
After all this discussion about internal leadership, it’s important to remember that customers have leadership responsibilities as well. In the customer-centric world of agile, it is customers, and their representatives, the product owners, who determine what we work on, how we prioritize it, and whether or not we’ve achieved their vision of the product. When we evolve from an internal-facing, product-led strategy to a customer-focused, market-led view, the role of the customer transitions from a passive consumer of new products, created based on internal needs, research, and metrics, to the central figure in the entire enterprise value chain. We move from the push of a marketing-led product cycle to a customer-pull model, offering new versions and features based on feedback from our clients. We shift from an internal clock of product cycles and upgrades to a customer-focused and market-led cadence. “The customer is king” has been a business motto for 100 years, but in the agile world, the customer is more than king; he is collaborator, innovator, product designer, partner, and judge.
Many customers of information technology (IT), whether internal users of enterprise systems or external customers using technology systems or products, have adversarial relationships with their IT providers. Projects or products are late, buggy, unfriendly, and obsolete. IT support and delivery teams talk in technical jargon and don’t understand the business’s needs. Specifications are thrown over the wall, and are often incomplete and obscure. Expectations are missed, promises aren’t kept, tempers are frayed, and mistrust escalates. The daily interactions between delivery teams and customers become tense, fraught, and unproductive, and the pressure mounts with each new defect or miss. The vicious cycle of technical debt leads to increased defects and support, which leads to further pressure and mistrust, and around we go with no exit in sight.
When the enterprise begins the journey to agility, it’s not uncommon for the customer to be negatively impacted. Their list of committed fixes, changes, and upgrades are often wildly out of sync with the team’s capacity to fulfill, sales teams are out selling more and adding to the pipeline of commitments, and executives are exerting pressure to fill the 200-pound bag of capacity with 500 pounds of work. The mandate to get things done does not change the capacity to deliver, except by forcing teams to sign up for death march projects, further sapping morale and quality. In the end, someone has to transmit the bad news to the customer that commitments previously made, totally out of whack with capacity, will need to be reprioritized, rescoped, and in many cases delayed or dropped. This is not a happy message, on either side of the conversation, which often leads product owners and executives to avoid it, thus exacerbating the vicious cycle even further.
Not a happy picture for anyone. Coaches can train small teams in agile practices all day long, but unless the ultimate customer is engaged in the conversation, and persuaded to adopt an agile mind-set that’s ready to accept experimentation and sustainable development, agility will falter and fail. As important as it is to guide teams and leaders to agility, failure to also guide the customer on this path will undermine our efforts. On the positive side, a customer who grasps the advantages of agility, understands that change can mean disruption but can also drive improvement, and is willing to take the journey with us and accept the uncertainty and experimentation that come with agile, is an invaluable partner. These customers can back off the intransigent expectations and relationship tensions and give the team some space to get itself sorted and try the agile approach.
For the agile consultant, the job of helping our sponsor’s enterprise bring its customers into the agile fold is decisive. We need to elevate our focus from just the team and its practices, and convince leadership, marketing, and sales teams that their customers are not only at the end of their value streams but also at the beginning, driving their product direction with their needs, desires, and expectations. We need to help them understand the difference between a push system, with its focus on ever-new methods of marketing and promotion, to a pull system, in which the focus is on responding to the market and partnering with the customer to understand their expectations and challenges. We must help sales teams learn to throttle commitments to fit capacity, a difficult chore when their compensation is based on selling more stuff. Finally, we need to convince leaders that the traditional metrics, like sales quotas and advertising impressions, must be combined with disciplined intake processes and customer feedback loops. These systemic organizational adaptations are as important as the agile behaviors of delivery teams, and far more difficult to coach.
It should be clear that, in addition to the grassroots activities we undertake with delivery teams, we must have a parallel top-down effort that persuades and educates. When I take on an agile evolution project, one of the first things I focus on is discovering an internal agile advocate at the executive level. Sometimes it’s the sponsor who engaged me, but often the directive comes from further up the leadership chain. Agility has been the subject of much publicity lately, from the Harvard Business Review to Forbes and Fortune magazines, and there often exists a level of curiosity, or even commitment, in the executive ranks. If we’re to change the attitudes and perceptions of the ultimate customer, we need to have sponsorship from the top, as all the incentives and metrics we’ve discussed run against the grain of the message we intend to send. As discussed previously, we first need to help leaders understand and embrace their roles before we can start realigning customer expectations.
How Agile Consultants Encourage Change
In Chapter 1we discussed the change management techniques recommended by Mike Cohn and John Kotter. From Cohn’s ADAPT (Awareness, Desire, Ability, Promotion, Transfer) framework to Kotter’s XLR8 principles, there are proven methods for guiding enterprises through major change. In simple terms, we educate and persuade, create awareness of the need to change, develop a sense of urgency through a Big Opportunity or idea, build a supporting coalition or team, and encourage an evolution of values, culture and practices across the enterprise. These theoretical ideas simplify into the techniques that I use when persuading both leaders and customers to work in a different way.
I’m a believer in social proof, the idea that it’s easier to persuade people and organizations to change when they see others successfully adapt. I therefore am an advocate of both evidence, like the Standish Group agile success metrics we saw in Chapter 2, and anecdote, like the voluminous case studies available on the Web. I often start my engagements by compiling a bibliography of articles and studies that demonstrate the potential benefits of agility. While we can’t make anyone read a study, we can provide them for those who might want to dig deeper. I’ve developed many training programs, from “Agile Basics” for teams and product owners to “Agile for Executives” to “Agile for Customers,” and I’ve presented them worldwide to both sponsors and their clients. I’ve invited previous clients to recount their journeys, triumphs, and struggles, to help prepare my new client for the road ahead. All of these methods of social proof can be helpful with both sponsors and customers, to allay their fears and truthfully prepare them for the challenge of wholesale transition.
Visibility is a key agile value, and also a potent change enabler. I’ve observed that it often takes beginning scrum teams a few months to grasp the basic practices and put them in motion, but, once my initial teams start to experience success and generate consistent velocity and quality, I want to make them visible to both the leaders of the enterprise and its customers. I find that seeing a well-functioning team in the act of planning a sprint, refining a backlog, or presenting a demonstration can go a long way toward getting all parties on board with the migration. It’s important to wait until these practices are running well; we don’t want to expose too many warts in front of our audience. However, some challenges should be visible, such as the reality of the team’s capacity and the technical challenges that are holding the team back. “Waiting for customer” is an area of blockage that may be beneficial for the end client to see, and “stuck due to technical issues” might motivate leaders to put some urgency into those eternal system fixes.
In our discussion about Exploration and Engagement, in Chapter 4, we emphasized the importance of knowing your sponsor and her organization. I begin engagements by seeking out the advocates of agility, from the executive to the business analyst, so that I know where the resisters and supporters might lie. Consultants with the persuasive and personal skills to build a supporting coalition of agile believers, to help guide and encourage the enterprise in its evolution, are more likely to lead a successful transition. When the team gets into the inevitable trouble, the teammate who encourages them to push on, who picks up the agile ideas and reinforces them with the team, is invaluable. Likewise at the executive level, the leader who understands that organizational transition is hard, and can send a positive message through the enterprise to keep the momentum going and allay fears, is an essential partner for the agile advisor.
The same is true on the customer side. The agile consultant who can educate the client, understand the history of the relationship, their concerns and disappointments, and can paint a compelling picture of benefits to come, has a greater chance of alleviating some of the pressure and mistrust that has built up over years. When agility starts to show some results that benefit the customer, it amplifies our message and begins to reform the adversarial relationship, slowly and over time, into one of enhanced trust and collaboration.
Summary
The key, of course, to both executive and customer acceptance and participation in agility is successful results. Once we persuade sponsors and clients to trust us to make things better, we must do so. We must provide the metrics and visibility that illustrate our successes. We must truly collaborate, and hear the sponsor and customer when they are faced with challenges, or have improvement ideas. We must, as always, demonstrate our understanding that transition is difficult, and that there will be many bumps and detours before we reach agility, and that kaizen is eternal. We’re now on the hook to deliver the results that customers value and that our sponsors expect. Our skills as facilitators, persuaders, educators, advisors, guides, and mentors will be tested to their limits. Finally, we must embody the agile principles and model the behaviors so that we train, coach, and mentor through our own behaviors rather than simply with words and theories.
Footnotes
1 David Mann, Creating a Lean Culture: Tools to Sustain Lean Conversions, Second Edition (New York: Taylor & Francis Group, 2010).
2 Ibid.
3 Ken Schwaber, The Enterprise and Scrum (Developer Best Practices). Redmond, WA: Microsoft Press, 2007).
4 James P. Womack Daniel T. Jones, and Daniel Roos, The Machine That Changed the World: The Story of Lean Production (New York: Free Press, 1990).