People Over Process

Leadership for Agility

Michael K. Levine

• Publisher: Productivity Press
• Year: 2019
• Print ISBN: 9780367369903
• eBook ISBN: 9781000682908
• Topic: Business
• Subtopic: Business generale
• Index: Business

This book helps participants in agile software development environments learn to become leaders. Facilitative leaders should be at every level of the organization, from individual contributor to informal team leader to managers of all stripes -- it takes much focus and intentionality from senior organizational leaders, who have special obligations in creating successful lean and agile development environments. But, beyond the principles of facilitative leadership for agility, People over Process provides tips and demonstrative scenes for the more important and common software meetings: architecture simulations, project planning, team configurations, retrospectives, and more. The author fully illustrates the principles and shares proven techniques for the most important leadership events in agile projects.

While this book focuses on facilitating extraordinarily well-prepared meetings, it serves as a metaphor for leadership more broadly. The leader's obligation to help their team make rigorous fact-based decisions; to gain broad input and have participants aligned on the outcomes and next steps; and to do so in an efficient way that respects the time of the participants is as relevant to every-day leadership activity as it is to conducting meetings.

The author mixes background and explanation with demonstration -- in this case, the story of an agile project at the fictitious Pacifica Bank. The scenario constructed at Pacifica illustrates the concepts of effective leadership and productive workplace environments. The book concentrates on the flow of software from understanding what is needed through design, development, testing, and deployment.

Essentially, the author provides a simple and powerful model of leadership, examples, and tips. This is not a cookbook on how to lead -- It is a set of principles and examples. All leaders must find their own way for their team, their organization, and their unique challenges.

Section 1

Introduction to Facilitative Leadership for Agility

• In this section the leadership model is introduced for both initiative leadership and organizational leadership.
• Our fictional case study, Pacifica Bank, has begun a major technology product development project. The Bank and the team are introduced, and we see the project slightly off track.
• Our archetypical facilitative leader, Mary O’Connell, diagnoses the issues and helps the team get back on track. In so doing the hiring manager, Sai Kapoor, demonstrates some of the organizational leadership principles that have been introduced, while Mary demonstrates facilitative leadership behavior appropriate to the Bank’s important project.
• The important role of meetings is explained and techniques to prepare for and conduct extraordinary meetings are elaborated upon. The section ends with Mary conducting a course correction meeting and putting the project onto a better path.

1

Pacifica

“It’s Not Agile If There Is No Software!”

Mary O’Connell sat by herself in one of the huddle rooms overlooking the new agile studio. It was late Thursday afternoon on a cool, Southern California, January day. After four busy days of observing and talking with the Pacifica agile team, Mary was processing. She twiddled her pen nervously as she considered what she had seen this week and pondered what to do about it.

Mary had two topics on her mind as she looked over the emptying studio expanse as the sun set behind the coastal hills to the west. The first was formulating conclusions on what was happening in the hip new space below her; the second was deciding what to do about it.

Three months into its conversion to agile, Pacifica Bank’s studio team was energized and excited. Guided by Davidson & Guilderson (D&G), a major international consulting and integration firm, Pacifica was attempting to make the leap to digital relevance by junking its cubicles, ending its silos, and turning its view from internal barriers to true customer needs. From what Mary had seen in the last few days, the feelings were real and progress was well underway, but a tweak in direction was needed.

The studio had all the modern elements of an effective team space and was well along the road of a customer-focused agile program. The walls were filled with personas representing Pacifica’s target customers including Jenni the mid-market US CFO, Hiro the Japanese export broker, and Sanjeev the Indian treasurer of an importing retailer. A state-of-the-art customer engagement center stood next door, where the team had engaged with persona stand-ins to learn what they thought about Pacifica’s and competitors’ products and services. Decisions had been made about tracking and management tools and those tools were now filling up with user stories describing what the team had learned was needed in Pacifica’s new mobile apps. Every day the team gathered for the daily standup as the loudly ticking round clock on the back wall ticked past 9:00 AM, right after the catered free breakfast drew them in. Yet, something was wrong, and Mary now saw it clearly. She was encouraged that a few of the participants in the studio and at least one of the managers engaged in the light governance group had a similar sense of unease.

Mary was also encouraged that Pacifica’s executive management knew enough to ask for an independent review of their progress. Thus, her presence, recruited for this gig by an ex-teammate now at Davidson. Pacifica’s EVP of Commercial Banking, Sai Kapoor, had engaged and trusted Davidson to help him, but he was just skeptical enough to want more than one view. Rather than risk dissonance with D&G, Sai had asked the partner on the account, Melanie Strom, for a referral for a second opinion. Sai had also conferred with Heather Gilliam, the Pacifica CIO, who had agreed on the risk-management approach.

It was through Heather that Mary had been introduced to Sai. Heather had met Mary a few times at local technology events and had been impressed with her work at Mary’s previous employer, FinServia. At FinServia, Mary had led a complete transformation from outsourced rigid waterfall development to an in-house team following agile principles, with dramatically improved results. Heather had heard Mary speak at an event about both the need for lean and agile techniques and about how to adopt them effectively. Heather had since hired a few of Mary’s ex-team members as their careers matured and liked what she had seen and heard. When Sai asked for a recommendation Mary was the first name that came to mind. (Note: Mary’s full story at FinServia is told in A Tale of Two Transformations: Bringing Lean and Agile Software Development to Life, Michael K. Levine, Productivity Press, New York, 2012.)

It wasn’t often that a senior delivery-oriented executive like Mary was available as a consultant. Fortunately for Pacifica, Mary had been away from the work world for almost two years having her first child and was contemplating looking for a part-time way back in. She jumped at the opportunity to help a local company embracing the values and principles she championed and came on as part-time D&G consultant. She knew she could help, although she was nervous about the new role as a consultant rather than a direct leader of the work.

Mary must have heard the word “agile” 100 times in the last few days. Superficially, the agile studio had all the external characteristics one might expect. But one thing was missing – the software! No matter how much the people enjoyed working together, engaging with customers and thinking through what was needed to truly compete against earlier digital adopters, there was no software flowing and no real plan to get it going. One of Mary’s favorite agile principles from the now aged Manifesto (see Appendix 1: Manifesto for Agile Software Development, page 255) was “working software is the primary measure of progress.” In the room below, this meant no progress had been made. This wasn’t entirely fair, as Mary knew that the study period that should proceed jumping into a development project is critically important, and this period was progressing generally well. Nevertheless, the lack of concrete progress towards software was disturbing.

How could this be? Davidson had plenty of experience helping organizations set up what seemed to be agile processes. Pacifica had made a major commitment to the program. Pacifica’s people had done what was asked of them: learning about scrum, studying competitors, listening to customers, compiling user stories into their backlog in their agile management tool. But Mary saw, after just a few days, the missing ingredient: leadership. The team was stuck making the transition from study to code and seemed unable to break through. It seemed to lack either the expertise to apply the scrum methodology to its circumstances in an agile way, or the collective capability to apply its expertise and experience together. Or both.

Mary knew that her obligation was to help – both to get through this modest directional challenge, whereby what had become the standard agile scrum process was not a perfect fit, and to help the team build its own leadership muscle.

Signposts	Mary O’Connell is a highly experienced development leader, expert in lean and agile software. She has returned part-time after an extended break to have her first child. She has been asked by Pacifica Bank to evaluate their new agile development project, working with their primary consulting firm D&G. No warning signs are yet flashing for Sai Kapoor, the Pacifica business leader, but he wants to be sure Pacifica is doing the best they can.
Leadership Guides	When embarking on a new way of doing things, take advantage of expertise to get more than one perspective on the path. Avoid creating inherent conflicts among experts on your teams, as Sai has done by including D&G in the selection and management of their second opinion provider. Building complex technology solutions is about much more than just agile processes and excellent leadership. Towering technical expertise like Mary is bringing is foundational to success.
Coming Up Next	We break from Mary’s consideration of next steps at Pacifica to explore the nature of leadership needed to apply agile principles effectively. Agile’s heritage and principles don’t speak directly to leadership, so we will develop a model of agile leadership as a valuable ingredient to success. First, we will consider people and initiative leadership in general. Then we will consider the special case of the organizational leadership for agility. Following our backgrounders on agile leadership, we will return to hear Mary’s diagnosis of Pacifica’s situation.

2

Background

The Facilitative Leader for Agility

THE EMOTIONAL ROOTS OF AGILE

The Agile Manifesto (c. 2001, see Appendix 1: Manifesto for Agile Software Development page 255) was so named intentionally, as a revolutionary document aimed at restoring the centrality of the software developer. Developers, the Manifesto implicitly declared, are not just resources that can be outsourced. They aren’t a cog in a machine fed through contracts and documents. To be successful in software development, the Manifesto declares, you must be developer-centric. Some of the declarations are right to that point.

• We value people and interactions over processes and tools.
• Business people and developers must work together daily throughout the project.
• Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
• Working software is the primary measure of progress.
• Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
• The best architectures, requirements, and designs emerge from self-organizing teams.

The values and principles were a scream of frustration against the horrors of Dilbertesque corporations by self-described software anarchists. It was a reaction against corporate pursuit of reliable and low-cost software development typified by infatuation with the Capability Maturity Model, offshore outsourcing, and productivity measurement by counting lines of code and/or function points.

The Manifesto struck an enormous chord of sentiment in the industry (and in me). That resonance has echoed through the last 15 years, and as a result agility in technology has become common if not dominant. Clearly the anarchists had insights that mattered. Many of the ideas work.

However, we are left with a challenge for those of us who actually manage these Dilbertesque organizations. Are we consigned to find great people, put them on a team, and hope for great results from self-managed teams? Is that the extent of our responsibility? Or do we have a higher calling?

Let’s consider one other perspective on the agile revolution. It wasn’t just that the clueless corporations disrespected creative artists and teams, although the pursuit of turning software developers into automatons was in full mistaken flight. That goal, of prescribing process and measurement and standardization, reflected a fundamental misunderstanding of the current nature of the large-scale software development process itself. Before we address the obligations of organizational leaders for agile endeavors, we need to have a clearer understanding of software processes.

PREDICTIVE VERSUS ADAPTIVE PROCESS CONTROL

In my first book, Tale of Two Systems, I explained how this agile rebellion was a reaction to a widespread confusion about the nature of complex software development. There was a strong strain of belief that software development could be turned into a reliable factory, with requirements going in, a series of repeatable and improvable steps being executed, and great software emerging reliably out the end. After all, if an automobile factory could turn out a high-quality car every minute, shouldn’t we be able to engineer software development into a reliable manufacturing process? The idea makes great sense but kept running into reality: the larger and more complicated the project, it turned out, the less likely success.

The frustration of large-scale failed software development projects was exacerbated by equally large adoption and implementation issues. Large organizations increasingly were able to buy software packages but found that installing and getting their people to productively use the new technology could be as difficult and dangerous as the software creation process.

It was, and is, the unfortunate and long-resisted truth that the best business analog for large-scale software development is not a manufacturing model; it is a new product development model. Figure 2.1 contrasts key features of manufacturing versus new product development. One is highly predictable, measurable, reliable; the other is by its nature a series of experiments and learning and adaptation.

FIGURE 2.1
Manufacturing vs. new product development.

Because the nature of manufacturing and product development are so different, they must be managed and c...

Table of contents

• Cover
• Half Title
• Title Page
• Copyright Page
• Table of Contents
• List of Figures
• Preface: People over Process
• About the Author
• Introduction
• SECTION 1: Introduction to Facilitative Leadership for Agility
• SECTION 2: Three Major Frameworks (Architecture, Plan, Team Structure)
• SECTION 3: Background / Pacifica Routine Meetings
• SECTION 4: Project Retrospectives
• Conclusion
• Appendix 1: Manifesto for Agile Software Development
• Appendix 2: Tool Tips
• Index