[#]: collector: (lujun9972) [#]: translator: ( ) [#]: reviewer: ( ) [#]: publisher: ( ) [#]: url: ( ) [#]: subject: (Who is the glue person on your team?) [#]: via: (https://opensource.com/open-organization/20/6/glue-person) [#]: author: (Lauri Apple https://opensource.com/users/lapple) Who is the glue person on your team? ====== How to identify and utilize the role of a clear-headed, storyteller on your team. ![Business woman on laptop sitting in front of window][1] Here's a test: how long do you think it would take for your organization to kickstart a brand new effort? A few days? A week? How ready would your teams be—do they already know how to roadmap, align, prioritize, and coordinate with each other? Are your teams successfully ending any wasteful activities? These might include running unused AWS stacks, building the same thing twice, or consistently preferring tactical, localized optimizations over strategically collaborating with other teams. If your organization has such activities in motion, you're probably on the right track. If not, that's a warning signal that your team is lacking some core capabilities you'll need for successfully launching any new endeavor, pandemic or not. Does your organization allow your [glue people][2] to develop those core capabilities, or are you pressuring them to stay in their boxes? ### Zombie scrum, velocity counters, clipboard dogmatists, and other occupational hazards Not long ago, on a lark, I interviewed for some freelance project management work with a US-based company. The experience was bizarre. The recruiter, who expressed all the enthusiasm of a bowl of cold pea soup, asked me to do tasks that require much more time and context than what was allotted, even to achieve the goals at a mediocre level. I was penalized for stating that I have never seen scrum by the book—aka [zombie scrum][3]—succeed in any organization. And I was somewhat scolded for asking analytical questions that, in my experience, are critical to driving focus and clarity. I didn't get passed to the next stage of the process, in part because the recruiter said my zombie scrum comment was a red flag. I took that as a compliment. But I also felt sorry for any project manager—or scrum master, agile coach, or any other creative person—who's made to apply cookie-cutter solutions to situations that require listening, empathy, and creativity. "Follow the book" is a simplistic, anti-intellectual way to crush innovation and generates stereotypes about professionals whose valuable work aims to glue teams, departments, and narratives together. Countless books, articles, and tweets from frustrated agile practitioners have been written about the tendency of many companies to pick an agile framework and force it to stick. A well-meaning company picks scrum, then instantly gets dogmatic about it and hires a bunch of scrum masters to hold the required ceremonies. In this environment, it's easy for the scrum masters to tie their competence to existing certifications instead of growing and expanding their skills into areas like psychology or conflict resolution. The company then puts a bunch of additional requirements on top of their framework of choice—checklists, team working agreements that look a certain way, mandatory JIRA fields separating "internal work" from "external work" (whatever that means). Maybe this stuff works somewhere? I have never seen it. There's never a good time to pressure your people to dumb down process and now is especially not a good time. Your organization needs even more of what makes a highly effective glue-person: * Pragmatism * Objectivity and a habit of identifying assumptions * Communication skills, which most tech companies struggle with even in calm times * Good listening skills * Pattern detection * Research skills * Neutrality and diplomacy * Strategic mindset over tactical, quick-fix, trees-for-the-forest thinking If you're not supporting your team in valuing and encouraging these attributes in your people—regardless of whether their job title includes "agile" or not—please start now. Of course, some people who take on "agile practitioner" roles actually prefer to be dogmatists, by-the-book folks, and bug counters. In that case, you have two options: either see if they're willing to explore different approaches to their work, or, if they're not, explore other people. ### Know your PMO If you hear teams grumble that your project management office (PMO) is a bunch of non-technical clipboard people who block progress, challenge those biases. Maybe your PMO really is ineffective; some are. But maybe there's a different issue at work—either micromanaging on their part or lack of accountability on the rest of the organization's part. A friend described to me a situation in which the two engineering executives in their company constantly complained about the PMO, for reasons that were never clear. What was clear was that the engineering executives did not value transparency or accountability. Meanwhile, my friend stated that many people in the company swore that without the PMO, nothing would have gotten done within any reasonable amount of time. After a leadership change, the engineering executives were replaced; the PMO remained. If the issue is with the PMO, consider coaching the team to be more effective. This can be done through a retrospective or, if you have time, one-on-ones. I have been lucky enough to work in three organizations with high-performing PMO organizations. They framed conversations with teams to similarly focus on goals and broader developments taking place around them. They were empathetic—trying to understand why programs lagged behind, instead of blaming or nagging. They were focused on producing value—aligning teams, making work transparent, keeping meetings well-organized and constructive, and asking pragmatic questions that averted disasters or surfaced gaps in strategy. Instead of checking in to see if people were doing their work, they helped teams find out ways to help each other. In many cases, they helped drive knowledge exchange to cross-pollinate new ideas and solutions either by running effective meetings or hosting dedicated conversations. If the issue is with your organization, work with the PMO to see how your leadership team can become better advocates for PMO work. Sometimes the issue for PMOs is a lack of public relations and reputation management. Sadly, PMOs can become the canvases upon which disgruntled parties project everything they're mad about, and this really isn't helpful to anyone. Neither are out-of-the-box expectations that PMOs can solve product strategy problems when product managers abdicate responsibility, or solve your technical architecture, or resolve every conflict between two engineers. Your organization might simply be misapplying your PMO power in ways that reinforce existing biases or misunderstandings of their work. Find ways to stop that. As a PMO of one person, I work closely with stakeholders across my organization to break down complexity, clarify outcomes, and track work-in-progress through lightweight visualizations. It's all storytelling. I work closely with our agile coaching team, laying the groundwork with delivery teams to form a coherent vision for what to build, then collaborating with the coaches to work with specific teams to boost performance and ensure better flow on that vision. It's not wizardry, and I've recycled it from what other successful PMOs have shown and taught me over the years. It seems to work. ### Give your agile coaches and scrum masters meaningful metrics "I thought agile coaches just measured velocity and story points, and scrum masters do the same but also keep JIRA updated," more than one person on earth has said. How did they reach this conclusion? Possibly by working in an organization that asked coaches and scrum masters to focus on output instead of value. Maybe those organizations didn't expect or even care if the coaches demonstrated their effectiveness; the coaches and scrum masters were there to serve a purpose, like security blankets of agility. Story points and velocity are worthless metrics if the work delivered isn't valuable. So is counting the number of retrospectives, or counting the decline in the number of bugs per team (easily gamed), or the amount of time spent pair programming. These metrics do not necessarily tell a coherent story about your organization, and they do not help the coaches and scrum masters grow. I like [this list of agile coach metrics by Andy Sio][4]: measure impact by looking for evidence of efficiency, or reducing meetings, or collecting data points around teams using coaches' suggestions to make improvements. For the scrum masters, Ryan Ripley invites leaders to [rethink the role][5] as one of service, challenging the status quo. Find someone else to update the JIRAs and take the notes. Maybe you're cool with empowering coaches and scrum masters, but now you're asking, "we have product managers and business analysts—why do we need coaches to do this?" Because dysfunction in delivery is usually systemic. It's about a confluence of discussions, decisions, communications, and other bits and pieces of work going awry, slowly at first, until it all adds up to become A Bigger Problem. A coach can help your product managers, analysts, and devs surface those Bigger Problems, understand the root causes, and find more effective alternatives to right the ship. If urgent enough, this can mean the difference between success and failure. For example: * How effective can a scrum master assigned to two or three teams possibly be if those teams are facing a constant barrage of "this is urgent!" work chucked in from the leadership team? * How can a team align with other teams, if those teams aren't sharing roadmaps? * How can engineering and product remain aligned if there are two competing roadmaps? * If you're facing Coronavirus, will your product managers, devs, and analysts have time to unpack all of this systemic dysfunction, or could they use a little help? Identify the "glue people" in your organization and find ways to leverage them through focused programs dedicated to one or two outcomes at most. Consider forming a "community of practice," an informal setting (Lean Coffee or other formats) for them to share best practices or highlight and resolve process-related needs in the organization. If your glue people are already overwhelmed, consider hiring more of them. This might sound counterintuitive if you're laying people off, but what costs more—hiring one program manager to do the job well, or having ten developers and product managers do the job with less focus, while not doing their usual jobs? Hopefully, you're able to identify the people in your organization who can connect the dots, tell your story, and bring everyone together. Maybe you've even hired people specifically to mind your processes and haven't laid them off yet. Please don't! They might save you and everyone else in your company. But only if you empower them. If you're starting something from scratch, support your glue people in keeping everyone else from losing the plot. Then you build a culture of maintaining the plot. It's easier to iterate and improve upon such a culture when it's the foundation of your new initiative or product than to force it after developing lots of antipatterns and worst-practice habits. Sure, incremental change can bring teams and organizations back on track—but why tolerate being off-track in the first place? "Going faster at the beginning" isn't a good reason; you can go super-fast and be experimental and still hold your team together. Process can be simple and lightweight—in fact, it should be. But it can't be solved simply by putting some meetings in a calendar and writing everything down in Confluence. It has to be customized and curated, created to achieve and sustain flow, and designed to be adapted depending on what's necessary. Otherwise, it will be an obstacle and a waste of time instead of an aid, and people will hate it. And it probably won't come from following scrum by the book, or anything by the book. -------------------------------------------------------------------------------- via: https://opensource.com/open-organization/20/6/glue-person 作者：[Lauri Apple][a] 选题：[lujun9972][b] 译者：[译者ID](https://github.com/译者ID) 校对：[校对者ID](https://github.com/校对者ID) 本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出 [a]: https://opensource.com/users/lapple [b]: https://github.com/lujun9972 [1]: https://opensource.com/sites/default/files/styles/image-full-size/public/lead-images/lenovo-thinkpad-laptop-concentration-focus-windows-office.png?itok=-8E2ihcF (Woman using laptop concentrating) [2]: https://opensource.com/open-organization/20/6/glue-team [3]: https://www.scrum.org/resources/blog/zombie-scrum-symptoms-causes-and-treatment?gclid=EAIaIQobChMI97Cr6v-96QIVFO3tCh25RgrWEAAYASAAEgIgYfD_BwE [4]: https://www.strategicquadrant.com/blog/how-to-measure-your-successas-an-agile-coach/ [5]: https://enterprisersproject.com/article/2020/4/scrum-master-role-how-rethink