Managing Resistance To Change: Seven Techniques You Can Start Using Today

Change Isn’t Easy But It’s Not Impossible

I recently had the pleasure of participating in the first cohort of Change Ambassadorship with the state of Nevada. Our certificate program was facilitated by Dr. James R. King, PMP who is currently our Organizational Change Manager with the Nevada Department of Administration. The program was developed to support one of the largest IT initiatives the state has undertaken to date, SMART 21 — Nevada’s response “to serve Nevadans with an efficient and responsive State government by modernizing Nevada’s Enterprise Resource Planing (ERP) ecosystem.”

This post is inspired by some of the lessons we learned during our 3-day course and I hope you gain as much value from it as I have because change isn’t easy. Whether your next, or current, change effort is in the form of a project or an organizational transformation, leaders should arm themselves with the proper techniques to help their employees or customers adopt, utilize, and become proficient with the change. To do that, leaders need to approach their people and:

  • Identify the barriers to change,
  • Focus their change management plans and activities,
  • Diagnose resistance factors from critical people,
  • Understand and measure work-group adoption rates; and
  • Identify opportunities to strengthen the desired outcome

Below is a list of techniques that you, as leaders, can start using today to start managing resistance to change.

Listen And Seek Understanding To Objections

  1. Listen
  2. Acknowledge their desire to be heard
  3. Seek a path that leads to a desired resolution for both parties.
  4. Identify any miscommunications

Listening and understanding are two different things. While being a vocal and active change agent is important, there are also times when you need to just keep quiet and listen to what others are saying. Acknowledge where they are coming from and look for a path that gets them to the desired outcome of the change. I’ve found that just keeping quiet practicing empathy, most objections come from miscommunication.

Focus On The “What” And Let Go Of The “How”

  1. Focus on the desired outcomes
  2. Let your employees own the solutions
  3. Focus on involving each employee

Note that I say, “involve each employee” and not all employees. This means you need to tell a story for each employee and tell them how their participation and involvement is critical to the change. Don’t tell them “how” they’re going to do things different, tell them “what” their involvement will mean for the organization and how their life, or the life of the customer (hopefully), will become easier as a result of the change.

Remove Impediments And Be An Enabler For Success

  1. Consider family, personal issues, physical limitations or finances
  2. Seek to understand each person; impediments may be disguised as resistance or objections
  3. Identify impediments clearly
  4. Determine your ability or the organization’s ability to address the impediments

Part of listening and understanding, is getting to know your people. Perhaps they don’t have the skills necessary for the change so there’s a training deficit? Perhaps that training deficit, to them, reflects on their ego or makes them fearful of losing their job? Your job, as a leader and mentor is to give them the resources they need to be successful and enable their success.

Convert The Strongest Dissenters

  1. Consider special interventions to convert vocal dissenters
  2. Make strong dissenters, strong advocates — they are often equal in their support as they were in dissent

I’ve always felt that ignoring the nay sayers is bad advice. Dissenters have usually been around the block, seen past failures, and experienced a variety of initiatives from different management regimes. Over the course of their careers and tenure, they’ve accumulated sage like experience. Just because they are a bit jaded and skeptical of a new “initiative” doesn’t mean they won’t come around. It just means they likely understand the risks far more than you do. Convert these folks, consider what they have to say, and brainstorm solutions with them and they’ll become your biggest supporters.

Create Hope For The Future

  1. People respond to the opportunity for a better future
  2. Leaders create desire by sharing passion for change, creating excitement, and enthusiasm
  3. People follow leaders who inspire hope and whom they respect

Inspiring hope for the future and getting people to look forward to the change can be tough. While resistance is a natural part of change, you can help people get through that resistance by being a leader they respect and trust. Use the JEDI JED BHUCKLIT acronym to remind yourself of the kind of traits you should be demonstrating to be a leader your people respect.

“The secret of change is to focus all of your energy, not on fighting the old, but on building the new”

-Socrates

Make A Personal Appeal

  1. “I believe in this change”
  2. “It is important to me”
  3. “I would like your support”
  4. “You would be helping me by making this change work”

Sometimes people will make the leap simply because they trust your judgement and believe in your leadership. Making a personal appeal signals your people that you are committed to the change and seeing it through. Asking for their support and demonstrating why you believe in the change can help nudge people in the right direction. Ask for their help. Be genuine. You can’t fake this.

Show The Benefits In A Real And Tangible Way

  1. Show how the change will improve a current process or help the organization stay viable in the long term
  2. Be an information radiator by sharing information and lessons learned
  3. Gather and communicate personal testimonies
  4. Visibly demonstrate the success of pilot programs or trials

Most people can conceptualize why a change is needed. However, having some hard facts, lessons learned from other organizations, or using real and relevant data builds confidence in the change. Pilot programs are a great way for organizations to engage in validated learning before rolling the change out across the entire organization. Go big or go home is risky. Managing organizational change should be done strategically and smartly.

If you’d like to discuss more about managing resistance to change, I’d love to hear from you! Connect with me on social media as well!

Related Posts

Thoughts On The 15 Leadership Traits

The People And Process Balancing Act

Agile Leaders Understand Customer Service And Culture

Urban Legends In Our Organization. Listening To Our Naysayers, Seers, and Jaded Sage

References

What Is SMART 21?

 

Photo Credit: Pixabay

Side Stepping Landmines: Managing Risk With Sprint Futurespectives

Risks Are Landmines

Risk and project issues are one of the roots of poor project performance. There are three areas that we measure regarding the success or failure of a project; these three areas are what we call in project management, the triple constraint. The triple constraint consists of scope, budget, and time.

The interactions of these three areas are a lot like Newton’s third law of motion. For every action, there is an equal and opposite reaction. Was there a decision to increase the scope? You’ll likely need more time and money. Has there been a cut to the project’s budget? There most likely needs to be a cut to the scope. Has the schedule been crashed and we need to get to market in two months instead of the planned six? Better give me more money and be prepared to cut some of that scope down to a “minimal viable product.” I think you get the idea.

The triple constraint consists of scope, budget, and time. The interaction of these three areas are a lot like Newton’s third law of motion. For every action, there is an equal and opposite reaction.

This is why scrum is so effective. It allows for business agility via quick decision making from the Product Owner and iterative delivery of working software from the team. Scrum deals with actions effecting the triple constraint rather well. Project issues concerning the budget or schedule can quickly be addressed by everyone and the Product Owner can assess the business impact to make a decision that usually concerns scope.

However, when a team starts off on a new project that has a medium to high amount of risk and uncertainty, I recommend allowing teams the time to mull over possible risks and to perform some pre-planning. Otherwise, the project can blow up in their face or decisions will be made for them by the changed environment. We address this with risk planning — we don’t send our soldiers into a battlefield knowing land mines exist. So how can scrum teams plan for risk?

Risks are landmines. Some we know about. Some we don’t. Creating a plan to navigate and manage the consequences of a triggered mine is the only way to help us navigate a minefield responsibly.

Conduct A Futurespective

Thinking ahead and talking can help, but writing down potential risks and plans to address them is even better. This is the point of the “Futurespective;” To conduct risk planning at the start of a project or product enhancement and to give the team some time to do some planning before stepping on a potential minefield. It’s an activity outside of the typical scrum events and because of that, it should not be done before each iteration. Instead, it should be done provided select circumstances:

  • Just before beginning a new effort (i.e. Sprint Zero);
  • Just before a critical milestone (i.e. a new feature release to Production);
  • A significant change to a project constraint is anticipated (i.e. change to schedule, scope, budget, or quality). 

Just Before A New Effort – The Sprint Zero As A Futurespective

The Sprint Zero is an activity I’ve seen successful teams use when they conclude one effort and move to another. There is no such thing as multi-tasking and that is why we should frown upon teams who work on multiple projects at once. What they’re really doing is engaging in “task-switching” or inefficient “serial-tasking.” Instead, we encourage the team to wrap up a product feature and release it to production for general use before moving onto another product.

The Sprint Zero is the time between efforts that allows teams to assess what the new project or product enhancement is. If they’re cracking open the code for an existing product to add a new feature set, they should be allowed up to two weeks depending on the complexity of the code. For older, more monolithic applications, carrying large amounts of technical debt, I’d recommend no time-box on this activity. Let the team take their time getting familiar with the product, the code, and documentation (if it exists or is up to date). If there is no documentation, stress the importance to managers that they should not be rushed into starting the project until they are ready. Let the team decide when they’re ready to begin and use common sense.

If the team is about to spin up a new project and create a new product from the ground up, there should already be a product backlog and roadmap ready for them to review. The Sprint Zero is a great opportunity for the team to familiarize themselves with the backlog, Product Owner, Subject Matter Experts (SMEs), and stakeholders of the new product. The team should be conducting working sessions to create better acceptance criteria for user stories, sketching wireframes, and getting a better understanding of what they are going to build. Encourage them to seek continual feedback on their wireframes and designs. Make it an iterative activity. Teams may also take some time to engage in training if they will be developing in a newer development framework. Again, exercise common sense and decide on a reasonable time-box before kicking off the project.

Just Before A Critical Milestone – Release Planning As A Futurespective

Usually a sprint or two before releasing a larger feature, the team should have a handle on the stability of their product. Testers have been giving Developers feedback on the quality of their code via Integration & Performance Testing and of course, Bugs. The Product Owner is busy preparing, coordinating, or wrapping up User Acceptance Testing (UAT).  The Scrum Master is busy assisting everyone with Impediments and UAT. It can be chaotic or running smoothly… sometimes too smoothly…but, maybe I’m just naturally pessimistic?

I find this is a great opportunity to use the time normally allocated for a Retrospective as a way to plan for risk and get everyone together for the release plan. Of course, the need for this will eventually disappear as practices become better and code is pushed into production more rapidly via continual integration and continual deployment, however, I recognize that it can take a while to get to this point.

The need for this will eventually disappear as practices become better and code is pushed into production more rapidly via continual integration and continual deployment.

There are multiple ways to conduct a Futurespective and each one could use their own article. However, it’s a good idea to invite the Product Owner and SMEs to this event. To be concise, I’ll give you the meat and potatoes of what makes a good Futurespective.

  1. Identification of plausible risks regarding the release
  2. Statement of assumptions about the release
  3. Statement of the issues currently occurring (problems & challenges the team is experiencing).
  4. Identification of dependencies effecting the release (technical or cross-team dependencies the team or organization has). 
  5. Written mitigation plans that is developed by the team and Product Owner.
  6. Assignments/Owners for each plan (“if risk 2 is realized, who is the person responsible for leading the plan?”). 

A Significant Change To A Project Constraint

When a business priority changes and the project’s budget, schedule, or scope, is effected, the Product Owner may decide to stop the iteration and cancel the sprint. The Product Owner should call the team together and appraise them of the situation and call on the team for advice. Ultimately, the Product Owner will likely make some tough decision about cuts to the product scope. The Product Owner should use her Subject Matter Experts, stakeholders, and Delivery Team to make the most informed decision possible. It’s a great opportunity for everyone to brainstorm with the Product Owner about the best way to continue moving forward and exercise business agility.

Prioritizing the Product Backlog and refining user stories that were in the “freezer” takes a lot of effort and planning. Schedule as many backlog grooming sessions as needed and run a Futurespective before proceeding.

Thanks for taking the time to read and I hope you found it useful. I’d love to hear your thoughts on risk management or any experience you’ve had with Futurespectives. If you’d like to have a discussion, leave a comment below or contact me. I’d love to connect on social media as well!

Photo Credit: Pixabay

Related Posts

The Scrum Product Owner Chooses Business Value

The Product Owner Steers The Ship

Urban Legends In Our Organization. Listening To Our Naysayers, Seers, And Jaded Sage

Top Secret! Successful Program Management In Government

Case Study Review: Milestones To Efficiency and The Factors That Influence Program Success In U.S. Federal Agencies

Formal project and program management has not been as diligently applied in government agencies relative to their counter-parts in private industry. This is alarming, as a large percentage of organizations, both public and private, are unable to deliver their projects successfully — “nearly 56 percent of strategic initiatives meet their original goals and business intent” (PMI, 2015). As a result, organizations are “losing $99 million for every $1 billion invested in projects and programs” (PMI, 2018). That’s roughly 10 cents per dollar spent on a project initiative. This article is aimed at summarizing the case study performed by the Project Management Institute (PMI) in 2015. The full case study can be found here.

Using Organizational Project Management — OPM

Just over a third of government agencies report that they “fully understand the value of project management” (PMI, 2015) and this case study examines three Federal Agencies to demonstrate what “successful Organizational Project Management (OPM) looks like in government” (PMI, 2015) in the:

  • Social Security Administration (SSA)
  • Bureau of Indian Affairs (BIA)
  • Federal Aviation Administraiton (FAA). 

Success Factors

While the specific mission and goals of each agency are unique — they all strive to effectively manage their budgets and spend tax payers money wisely, serve their constituents, and adopt and realize the benefits of OPM within their respective programs and projects. Below is a list of the success factors all three agencies report as

  1. Strong Leadership Capabilities: Hands on leadership from program managers effectively support project management activities, better engages stakeholders, and “serves to increase camaraderies and confidence within the team (PMI, 2015).”
  2. Commitment to OPM: Each agency had a subject matter expert (SME) available or leading the adoption of OPM; investment in training and certification made “formalizing principles and practices” (PMI, 2015) much easier and the appetite for change outweighed risk & avoidance. 
  3. Executive and Senior Level Support: Executives budgeted for training and were called upon when their influence was needed to remove project impediments — signaling a “strong sign of commitment to lower echelons” (PMI, 2015) of the organization. 
  4. Effective Training Programs, Ongoing Coursework, & Certifications: Training and experience go hand and hand; critical employees were afforded training and certification opportunities to better serve their constituents.

    “For the team involved in the Bureau of Indian Affairs program, to lower violent crime rates, Indian Country police officers received sensitivity training. This familiarized them with Indian cultures and customs, helping officers to avoid cultural missteps. This in turn helped promote acceptance of the program.”

  5. Transparent and Effective Communication: Regular communication, both formal and informal, were highly effective as they fit the needs of stakeholders and the programs, resulting in “identification of problems that could be pre-empted — reducing the likelihood of escalation” (PMI, 2015). 
  6. Team building and Stakeholder Engagement: Coalesced communication, training, and agency buy-in culminates into shared “understanding and respect among parties, which helps avoid resistance and misunderstanding that can lead to delays” (PMI, 2015). 

Common Obstacles

Each agency identified obstacles that were unique to their programs and mission, however, two common obstacles were identified:

  1. Lack of Understanding: Specifically, understanding the value of a project or program management.
  2. Limited Funding: Resources are finite and government agencies must carefully budget and distribute their funds across multiple portfolios, programs, projects, and operating activities. 

Lessons Learned

The Project Management Institute has not performed a study on the adoption of Organizational Program Management in Government Agencies prior to this case study. The case study servers as a baseline for future research and the impetus for other agencies to collectively learn and increase adoption of OPM.

Lessons Learned By Agency

  1. Social Security Administration: “Project and program career development benefits the entire organization” (PMI, 2015).
  2. Bureau of Indian Affairs: “Project and program management practices can be implemented to fight crime and promote better understanding between police and the community, thus creating efficiency and lowering the violent crime rate” (PMI, 2015). 
  3. Federal Aviation Administration: “Greater reliance on standardization of processes transforms program management at the FAA” (PMI, 2015). 

I’d love to hear your thoughts on OPM or any experience you’ve had with program and project management you’ve seen in government. If you’d like to have a discussion, leave a comment below or contact me. I’d love to connect on social media as well!

Photo Credit: Pixabay

 

References

Project Management Institute. (2014). PMIs Pulse of The Profession: The High Cost of Low Performance 2014. Project Management Institute Global Operations Center. Newtown Square: Project Management Institute.

Project Management Institute. (2015). Milestones to Efficiency: Factors That Influence Program Management Success in U.S. Federal Agencies. Project Management Institute Global Operations Center. Newtown Square: Project Management Institute.

Project Management Institute. (2018). PMIs Pulse of The Profession: Success in Disruptive Times. Project Management Institute Global Operations Center. Newtown Square: Project Management Institute.

Ditch “The Three Questions” And Adopt The Agile Mindset Already

Ditch “The Three Questions” And Adopt The Agile Mindset Already

Scrum teams that have been using Scrum for a while are most likely settling into the new framework. The chaos and dust from the change has settled and things are normalizing a bit. However, each team has their own unique way of doing things and, from the outside, managers may be holding onto their “command and control” mindset. Shouldn’t a process, like the daily scrum, be repeatable and look the same for all teams? Perhaps their mentality is that Scrum is a “methodology” and it should be strictly adhered to vs. a light weight framework in the “Agile toolbox?” Maybe they’re too focused on accountability of individuals vs. team autonomy? Whatever the cause, the Agile mindset just hasn’t quite set in yet. With a little bit of coaching, they’ll get there. Exercise patience.

One thing I’ve observed from leaders who haven’t quite fully adopted the Agile mindset yet is their insistence on strict adherence to “The Three Questions” during the daily scrum. There exists a feeling that “Vanilla Scrum” is the best way to do Scrum (There’s no such things as ‘Vanilla Scrum’ by the way). There’s a perception that the best way to do Scrum is to make everyone answer the three questions:

  1. “What did you do yesterday?”
  2. “What will you do today?”
  3. “Do you have any impediments?”

While I agree that the scrum guide can be prescriptive at times, the three questions listed above are not, in fact, mandatory. Seriously, read the section on the Daily Scrum and then come back.

Welcome back. So now that everyone’s educated, let’s talk about creativity. There’s a lot of room for creativity from each team and every individual. The Scrum Guide tells us “What we should do,” however, each team is left to figure out “How best to do it.” The format of the daily scrum is no different and there’s a lot of room for creative and constructive discussion questions. Strict adherence to the three questions can become an impediment to communication.

When speaking to your leaders, it’s usually not a good idea to open the scrum guide and show them where they’re wrong. It’s not very tactful and you miss a great opportunity to make the conversation a teachable moment.

When discussing this with leaders, start by asking some simple questions. I usually start with, “what does ‘vanilla scrum’ look like to you?” Their answer will likely reveal one of two things.

  1. Focus on the process; or
  2. Focus on individual accountability.

It makes sense, doesn’t it? As a manager, their ability to reliably deliver products, services, or projects is a reflection on their ability to lead their unit. Managers are accountable to stakeholders, customers, and their bosses. Yes, managers have bosses too. It’s pretty simple when we put ourselves in their shoes and I think we can empathize with their position. It can be a great deal of stress. Management isn’t for the weak of heart.

Yes, managers have bosses too.

Creativity Over Strict Processes

Command and control via processes can be effective. Set up a process. Follow the process. Repeat. But at what cost? I’d argue at the cost of creativity. I’d argue at the cost of low employee engagement. I’d argue complete and utter mediocrity. Of course I’m not advocating for zero processes either. That would be irresponsible. The people and process dependency is a balancing act, but let’s not rehash that discussion.

My recommendation would be to challenge the manager’s perspective about creativity and engagement. They may say they value it, but their actions may speak differently. Perhaps they view the daily scrum as a status report? That’s an anti-pattern you don’t want to have. Trust me. Been there. Done that. Got the t-shirt.

Scrum shouldn’t be “standardized across all teams.” If the pain point of the organization is variable quality and unreliable delivery, Scrum won’t fix that for you. But if you allow creativity to happen, then your employees will become engaged. And engaged employees who are empowered can move mountains. They’ll fix things on their own because at the end of the day, everyone wants to go home at five thirty, have a beer and spend quality time with their family. It’s the mindset, not the framework that we should strive for. Intrinsic motivation, not another carrot.

Responsibility Over Individual Accountability

I’m not advocating for zero accountability. Again, that would be irresponsible. But, the need to hold people accountable for their actions is another “command and control-ism” and it makes people fearful for their jobs. As a result, it stifles creativity and people will do just enough to stay of the RADAR and out of trouble. This is a much tougher problem to address because a manager focused on “holding people accountable” likely suffers the same from their own management. We can all empathize with our managers on this. Just like us, they’re subject to the same influences of organizational culture. As a coach, you must be courageous enough to address this with everyone in the organization, especially when another witch hunt is just around the corner. Are we trying to figure out who put crappy code into production? Or are we trying to figure out how crappy code got into production? You see the difference? The first question is about assigning blame. The second question is about addressing a problem. Stop with the witch hunts. People make mistakes. It’s a part of doing business.

My recommendation would be to re-frame the conversation around responsibility. Accountability is for Product Owners who must own the success or failure of a project. They are the single wring-able neck. However, responsibility can be shared and is something reserved for teams who share the responsibility of managing risk, keeping on schedule, staying within scope, and producing quality work. Product Owners are accountable for the overall performance of the project and guiding the team with a product road map. The Product Owner provides the what. The Team provides the how.

Stopping the flow of communication so they neatly fit the mold of the three questions can introduce risks into the project. It jeopardizes the quadruple constraint (Scope, Schedule, Cost, and Quality). So let your team discuss the sprint goal. Let your teams talk about the future beyond the next 24 hours. Let them self-organize in a way that’s most comfortable for them. They’re responsible for delivery — have the courage to step back so they deliver.

I’d love to hear your thoughts on the daily scrum or the anti-patterns you’ve recently spotted. If you’d like to have a discussion, leave a comment below or contact me. Feel free to connect with me on social media as well!

Photo Credit: Pixabay

Related Posts

Scrum Anti-Pattern: Daily Stand-Up As A Status Report

The People and Process Balancing Act

Agile Leaders Understand Customer Service And Culture

A Story On Anti-Patterns

The Anti-Pattern

In one of my past posts, I asserted that the Product Owner Steers The Ship and that as a coach, we don’t want to make assumptions about the anti-patterns our Product Owners may have inherited from their previous roles. After a few conversations I had with people, I decided to expand a bit on the topic of anti-patterns. There are multiple areas in Agile that need their own list of anti-patterns and context. But isn’t that true in life? I think so. So for this post, I’m going to dive into anti-patterns as a behaviors and a mind-set and treat you with a story. Enjoy!

“An anti-pattern is a common response to a recurring problem that is usually ineffective and risks being counterproductive”

-Andrew Koenig

Design Patterns

 

Figure It Out, Larry!

Samantha is a District Manager for a manufacturing company and she’s dealing with a new employee, Larry, who isn’t quite performing up to par with the rest of her team. For the third week in a row, Larry has submitted “sub-par work.” The numbers and calculations in his reports are way off from the previous ones she’s used to seeing. It’s obvious to Samantha that Larry isn’t following the templates and checklists correctly. But, she can’t figure out how to get through to him. She doesn’t want to start micro-managing his assignments, but she and her team have been so backlogged that she expected him to follow all the documented procedures and figure it out. He seemed so bright on paper. Maybe she was wrong about her newly hired employee?

After reviewing his first report, she made a passing comment, some thing along the lines of, “you really must have grinded this out at the last minute, Larry?” It was meant as a half-serious joke. She doesn’t really know Larry that well, being that he’s new to the team, but she’s known for being sarcastic in the office and most of the team dish it right back at her. His first day on the job the team had a particularly rowdy meeting. He knew what was up and that no one took the jabs seriously. She has a healthy working relationship with her team, despite what it looks like on the outside. She has full confidence in her staff and she chooses to be hands off with them. Everyone is brilliant. Except maybe one?

The second report came in and she was a bit agitated. She decided to remind everyone at the next staff meeting about using the correct template and the expectation of “quality work from each individual — everyone is busy with their own projects and programs and is expected to pull their weight.” She made eye contact with Larry, letting him know that the message was meant for him. Larry didn’t hold her gaze for long. It was clear he got the message.

After week three, Samantha lost it when she got Larry’s report. Not only was the report turned in late, but Larry was no where to be found. Who was Samantha going to yell at? Samantha immediately navigated to the HR SharePoint page and downloaded the Word document titled “formal written reprimands for employees.” It was time to send a message to Larry, “it’s time to shape up or ship out” she thought to herself. Three weeks and he still hasn’t figured it out.

Samantha went through the report closely and began documenting discrepancies like formatting and the fact that the report wasn’t turned in first thing in the morning — she noted each item on the reprimand document. She combed through it more closely than she had in the past few weeks and saw that Larry added a section titled, Raw Material Rework & Waste. “What is this?” Samantha asked herself. She went on to read the report, “each plant has had a remarkable spike in waste due to poor raw materials after switching to the new South American supplier, Corpo Corp resulting in 18% of  all finished products requiring rework and 2% of finished products un-shippable and designated as waste.” If this was true, Samantha had a serious problem on her hands. This was a multi-million dollar problem. It could end the career of the plant manager.

Samantha saw that Daniel Ramon, one of her plant managers and a close friend, was listed as a reference on this part of the report. She quickly pulled out her phone and called his personal number.

“Samantha, to what do I owe the pleasure?” Daniel’s booming voice broke through the noise of the factory in the background.

“Hey, Daniel. I’m just reading Larry’s report here and I had a few…” Samantha was abruptly interrupted by Daniel.

“Larry saved our butts, Sam! I tell you, you got an eye for talent! He’s here with that intern from upstairs helping us out! I tell ya’, since we switched to that new vendor, Corpo Corp or whatever they’re called, the materials we’ve been getting in have been shit, Sam! I can’t believe this! Larry is just finishing up over here, do you need him?”

“Finishing up with what?” Samantha’s heart was beating hard.

“He helped us re-organize the plant lay out so we can do re-work without missing our ship dates! Ain’t you know what your boy is up to out here?” Daniel laughed.

“You don’t say… uhm.. No, I’ve been so behind… I was just checking in… honestly, no I haven’t looked carefully at his reports until just now,” Samantha admitted and felt a weight on her chest and she was suddenly felt with grief. She was getting ready to write Larry up, to begin his journey to termination, and he was busy saving her ass. Saving Daniel’s ass.

“That’s okay, Sam. Larry didn’t say much about what’s been going on between you two but I heard through the grapevine. Anyways, I scheduled a meeting with some of the big wigs in two weeks. I want you and Larry to present his results to those penny pinchers up-stairs, you got more pull upstairs than anyone and it’s a good way to introduce Larry to the new CEO. You let them know that switching over to this cheaper vendor is actually costing us money in OT, re-work, and useless product,” Daniel exclaimed.

“Of course, Dan. If you don’t mind me asking? When did Larry first start helping you out at the plant?”

“About three weeks ago, I ‘reckon! That boy came down here on his own for a tour of the plant. Don’t you usually bring the newbies down here? Oh, right. Too busy. Anyways, after about twenty minutes of my showing him the place, he had the audacity to tell me that ‘there’s too much waste.’ Can you believe that, Sam? Lecturing me! ME! ABOUT WASTE! I’m the Six Sigma trainer over here and have been the plant manager for going on eight years! I reckon..” Daniel was known for swearing like a sailor and long winded rants. Samantha quickly interrupted before he could take another breath and continue.

“So he tried to tell you how to do your job?” Samantha interjected with a question.

“Nah, not really… Maybe I was bein’ too defensive with the young gun. I had a busy morning fighting fires and I could tell he didn’t mean anything by it when he started blushing and pulled out his binder and reports from purchasing, payroll and sales. He showed me the data and pointed down to the plant where we had bottlenecks and piles of work building up. He showed me there’d been no increase in sales or large volumes of material from purchasing, but our payroll has gone way up in over-time. I wouldn’t have caught it for another two weeks from now because we’ve been practicing lean and Six Sigma for so long that I usually only need a monthly report anymore,” Daniel lowered his voice and took on a serious tone.

“I dropped the ball on this one, Sam. I didn’t have the feedback loops in place to catch this. We would have been screwed royally this quarter if it weren’t for your boy Larry. We still have to deal with the re-work until we can get our old vendor back, but we’ll have minimal overtime and we should be able to meet all our ship dates with Larry’s re-design. I told sales not to run any discounts so we don’t have any large swings in production just to be on the safe side. We’ll break even this quarter but we need our old vendor back,” Daniel finished.

“Of course, I’ll get with Larry and we’ll make sure HQ knows what’s going on, Dan” Samantha assured her long time friend.

“Thanks, Sam! And hold on to Larry, he’s a rockstar! I’m taking him and that intern out for a few drinks tonight after we wrap-up over here. Meet us at AppleBee’s around quittin’ time if you ain’t got any plans for tonight,” Daniel finished and hung up the phone.

“I’ll be there,” Samantha said quietly to herself. She owed someone an apology.


That evening, Samantha walked into AppleBees. She spotted the two at one of the tall tables in the bar area, but she knew where to look because she could hear Daniel’s loud and booming voice over the chatter that filled the crowded restaurant. She ordered a martini and two more drinks for Larry and Daniel before making her way to the table to join them.

“Sam, I’m glad you made it! I was just telling Larry here about the company barbecue and the finer points potato sack racing!” Daniel boasted with a hearty laugh.

“Dan, are you trying to recruit poor Larry here so you can reclaim that trophy? You know My hubby and I won’t be giving it up this year,” Samantha smiled over at Larry who was looking down at his feet.

Daniel looked over at Larry and then at Samantha who was looking ashamed. He excused himself for a much needed restroom break so the two could have a moment together.

“Larry, I owe you an apology. I’m so sorry for the way I’ve been treating you. You saved us from a disaster,” Samantha met Larry’s gaze as he looked up with an embarrassed smile.

“It’s okay, water under the bridge,” Larry said lightly.

“No, it’s not okay. Just like how Daniel didn’t have the appropriate feedback loops in place to catch the re-work issues, I don’t have the appropriate feedback loops in place to see that there’s something wrong with the way my team is running,” Samantha said with sincerity. “Help me out, please?”

“Okay, then can I give you some honest feedback about some of the anti-patterns I’ve seen?” Larry asked tentatively.

Samantha hadn’t heard that term in a while. Anti-patterns was something she remembered during her Lean training last year but could never think of an instance that it applied to her so she forgot about it. He paused and then went on when Samantha nodded her head and smiled; signaling for him to continue.

“Well, I sense there’s little room for outsiders in your group. When I first joined your team, I felt like I an outsider looking in. The first meeting I was in, there was a lot of inappropriate joking and the team engaged in put downs. I don’t know if I can fit in with a culture like that. I believe it’s important to treat each of my team mates with respect and to act professionally,” Larry went on.

“We all respect each other, Larry. There’s so much trust in our group that we can do that and there’s no hard feelings,” Samantha countered.

“Right, I know that. I don’t mean to imply that the group isn’t tight. It’s obvious you are — but, there’s a consequence when those types of behaviors occur. New people feel like outsiders and communication is effected,” Larry said firmly.

Samantha thought on this and saw his point. “Okay, what else?” Samantha asked.

“Well, I observed that everyone on the team is really wrapped up in their own work. People don’t pair up on work or double check things for each other,”

“That’s only because everyone is so swamped with work. Even I put in late nights and weekends just to stay ahead,” Samantha said matter of factly.

“Right, but taking the time to double check each other’s work ensures quality and protects us from mistakes. Pairing up on projects and special tasks ensures the highest quality of work is produced. It’s just like in the factory. We can churn out product quickly, but if we’re doing rework constantly, then we’re really not as productive as we would like to think. It’s no different in the office.” Larry explained.

“True, but that’s why we have established processes and procedures,” Samantha answered.

“Yea… when’s the last time those were updated or even audited?”

Samantha closed her eyes and thought to herself. She couldn’t recall. She opened her eyes and saw Larry starring at her with a look that said he already knew the answer. “I guess it’s been a while.”

“Right, why do you think I made those changes to that report? It was dated and wasn’t fitting our needs anymore. Always be ready to adopt sensible alternatives to fit your needs; otherwise, you’ll be too busy doing work that isn’t adding value. Or worse, people stop thinking and blindly follow a process,” Larry said softly to soften the feedback.

“But, we spent weeks creating that process,” Samantha recalled working on it when she first took over as the District Manager.

“Simplicity. Focus on the most simple and direct solutions possible. I know it can be hard to kill a process that you worked hard on. But if it’s complex and hasn’t been updated in a while, it probably isn’t really being followed anymore or needs to be removed.”

Samantha started to feel the weight on her chest again. She knew deep down that everything Larry was saying was right. It was all so painfully obvious but she had failed to see it. Even after starring it in the face for so long. She must have been deep in thought because she didn’t notice the server take her empty glass away and return with another drink.

Daniel’s hearty laugh finally snapped her out of her haze and she looked up and saw him returning to their table. She looked back to Larry and smiled. “Larry, I’m glad I hired you. I guess I need to make some changes.”

Larry smiled back, “one step at a time; we’ll figure it out.”

Anti-Patterns Are Hard To Spot… Even When You’ve Been Starring Them In The Face For A Long Time

It’s hard to spot anti-patterns. Mainly because we, as humans, are a collection of past behaviors, our genetics, and the environment which acts upon us. Of course, we’re not just behaving creatures, we feel and think as wellMany times, we are unaware of the secondary effects of our behaviors. We start with a certain intention and behave in ways that are similar to our past; however, there can be unintentional consequences that impede the results we initially wanted. This is an anti-pattern.

Just as Larry explained above, Samantha never intended to foster a team culture that made outsiders feel unwelcome. In fact, she felt her team culture was one of trust. But her new employee was unwilling to speak up for himself. Team members were unwilling to pull themselves away from their work to help out a new team mate. It was clear that everyone on that team, even Samantha, was using the same anti-pattern.

Larry also went on to explain that there is too much work on everyone’s plate. So much so that old processes have not been updated and that the quality of work being produced by Samantha’s team was probably questionable. Did you know that putting more paper in the printer doesn’t make it print any faster? There’s only so much we can do in a given work day, and we should ensure quality is a part of our ever day work routines.

Producing quickly should not be the goal of a team. It’s not efficiency either. It’s stability and effectiveness. How long do you think Samantha was receiving that report without really questioning the quality? Without questioning how effective it was anymore? It wasn’t until Larry came along and started doing things effectively that Samantha even noticed.

Putting more paper in the printer doesn’t make it print any faster. Producing quickly should not be the goal of a team. It’s not efficiency either. It’s stability and effectiveness.

One quality of an effective leader is the ability to prioritize work. Not everything is “priority 1.” That sort of defeats the purpose of the word ‘priorities’ and if that’s your management style… Well, your employee turn over rate is probably high and employee satisfaction is likely low. Just saying. Figure out what’s important and let your team know. Only change the priorities after a business need exists. Command and control the priorities, not the people. People can’t produce quality work if they’re constantly being pulled in multiple directions by several priority 1 projects.

One quality of an effective leader is the ability to prioritize work. Command and control the priorities, not the people.

Anti-patterns are not unique to Agile. Or business. They exist in every day life. They can have an impact on our relationships, finances, diet, and our health. That’s why it’s important to constantly seek feedback. Challenge yourself to get perspectives from the highest level and all the way down in the weeds. Challenge your own perspective and poke holes in your logic. Why do you think so many successful leaders read books? Why do you think they take time to meditate? Or take classes or take up new hobbies? It’s because these kinds of activities shape perspective. They help us learn new behaviors and ways of thinking about the world. They help us spot those anti-patterns. They make us better leaders and people.

I’d love to hear your thoughts on anti-patterns or the ones you’ve recently spotted. If you’d like to have a discussion, leave a comment below or contact me. Feel free to connect with me on social media as well!

Photo Credit: Pixabay

Related Posts

Urban Legends In Our Organization. Listening To Our Naysayers, Seers, and Jaded Sage

Agile Leaders Understand Customer Service And Culture

The Five Levels Of Conflict

The People And Process Balancing Act

The Agile Manifesto Teaches Individuals and Interactions Over Processes and Tools

There’s a common misconception, especially among those new to Agile, that the relationship between people and processes is one of friction — that it’s a dichotomy. The subtlety of the language used, “individuals and interactions over processes and tools” implies that both need to exist. The framers of the Agile Manifesto even state, “while there is value in the items on the right (Processes and Tools), we value the items on the left more (Individuals and Interactions).” I agree with this and would also argue that processes and tools are an input to productive interactions among individuals. We know what is more valuable according to the Agile manifesto but, which one is most important? People or Processes? Maybe we’re thinking about it all wrong?

Chinks In The Armor

Asking, “what’s more important, people or processes?” is a fair question to ask when you’re new to Agile. Especially since most organizations looking to “go Agile” start with Scrum (by the way, practicing Scrum does not mean you are Agile. It’s a great start as long as the leadership team continues to stay open minded and doesn’t limit the organization to just Scrum). Usually, a handful of developers, project managers, business analysts and line of business managers are sent to a two-day class scrum class; they receive a certificate dubbing them newly minted “Certified Scrum Masters/Product Owners/Developers” and are given a small project to show a “proof of concept” with the

storm trooper
Scrum Reveals The Chinks in the Armor

new framework. It’s chaotic and exciting at the same time; however, the organization’s weaknesses begin to show up (Scrum has a way of shedding the spot light on the problems that have existed in the organization for a long time). I call these the “chinks in the armor.”

The biggest chink I’ve seen most teams discuss in their retrospectives are the People vs Process Dependencies. Invariably, team members and managers dig in their heels about which one is better. This is because people default to what they know best. They use what has worked for them in the past. Change is hard, even when there’s clear evidence that what they’ve been doing will not work anymore because of changes in the business environment.

As a coach, it’s important to understand the pros and cons of the people and process dependencies. It should be explained clearly with not only your teams but, with the management team too. The organization will have to move past striking a balance and figuring out which areas need the most improvement. Instead, they should assess the parts of each dependency and figure out what works best for them today. Below are some extreme examples of each dependency to illustrate the pros and cons of both.

People Dependency

Pros

  1. It gives workers satisfaction – employees feel satisfied when they know they are valued
  2. Flexible – employees are empowered to perform work in the way they feel is best
  3. Adaptable – the ability to pivot and make changes is the hallmark of business agility
  4. Efficient – unnecessary steps in a process are avoided
  5. Helps to retain high-achieving, confident, people – people stick around because they know they are important and are good at their job

Cons

  1. Less repeatability – changing processes are not repeatable and leads to waste
  2. Makes customers nervous – customers feel comfortable when there’s visibility on the process
  3. Can provide a “false sense” of a high degree of control – processes are measurable. What get’s measured gets done. When managers rely solely on the self-reporting, certain messages may get filtered and there is no data to verify.
  4. Turnover impacts are much greater – institutional knowledge can walk out the door or get hit by a bus
  5. Higher risks – for the reasons listed above

Process Dependecy

Pros

  1. Repeatability – repeatability helps with predictability
  2. Easier to improve – a documented process is easier to improve with less risk to the organization
  3. Less people dependent – automation of easily repeatable tasks frees up resources for more value added activities
  4. Predictability – it can be measured objectively and relied on as a lever for control in the organization
  5. Brings new personnel up to speed faster and with less risk of poor performance

Cons

  1. Paperwork can overshadow the task – processes that are overly complex distract from value added work
  2. Resources must be spent enforcing or ensuring compliance – managerial debt is incurred. Managers spend less time removing impediments and more time micromanaging processes.
  3. Someone must own and manage the process
  4. Less “thinking” is needed – employees and managers can become complacent if there’s no impetus for process improvement. This leads to waste. 

Processes Come First But They Should Not Be Valued

I know I’m going to rub a few people in the Scrum community the wrong way (and probably piss of a few of the business process analysts too) But, processes should come first but they should not be valued in the same way we value our people and interactions. It’s easy for managers to regard processes as instruments for control. Some managers finely craft their business processes. They labor over them and build complex systems for the organization. But only effective processes facilitate people. Not complex ones. If you require a practical rule of me, I recommend you murder your darlings.

“Whenever you feel an impulse to perpetrate a piece of exceptionally fine writing, obey it — whole-heartedly — and delete it before sending your manuscript to press. Murder your darlings”

— Arthur Quiller-Couch,

On the Art of Writing

vintage scale.jpg
People and Processes Are Not Equal

I argue that people and processes should not balance each other. Many representations of this balancing act builds a false dichotomy. It implies that they are of equal value. Like the framers of the Agile Manifesto, I do not value them the same way.

Processes should support our people and facilitate their interactions. Processes are either operational, supporting, or management oriented. If they do not provide value. Murder them. It’s up to the teams to decide which processes they need most and which ones can be forgotten. Each organization is different. Each darling should be judged accordingly — but retain the ones that still add value. Don’t throw the baby out with the bath water. Don’t assume that just because you’re “doing Agile” that processes no longer needed to exist. No, processes are still important. They unlock your people’s ability to work at a higher level. But it’s time to end the love affair with processes and value your people.

Share your thoughts in a comment below. If you’d like to have a discussion, please contact me or connect with me on social media!

Photo Credit: Pixabay

Related Posts

The 5 P Pyramid Model. Assessing Policy, Process, Procedure, People and Personalities In Scrum

Improving Agile Retrospectives With SMART Goals

Six Elements of An Effective Strategy

 

 

 

Talking About Communication: A Fun Game For Your Next PMO Meeting

Telestrations – A Game For Communication

Today I was cleaning out my school bag and came across some old index cards that I had used in my Advanced Project Management class. We used it during our lecture on communication management and the instructor had us play a quick game of Telestrations

Why It’s Important

One of the greatest threats to the success of any project is the failure to communicate. Our goal, as Project Managers and Product Owners is to ensure the timely and appropriate generation, collection, dissemination, and disposition of information. Communication is the oil that keeps a project running smoothly. 

This game is easy, fun, and provides some laughs. Additionally, it’s a great opportunity for everyone in the Project Management Office to be reminded of the basic principles of communication. I can’t tell you how many times I’ve sat in a PMO meeting and was either bored to death by power point (death by power point… ugh…) or the group wasted an hour and a half reviewing project status reports (couldn’t I have just sent an email?!?… double ugh…).

The game I describe below takes about 2 minutes of set-up and about 5-10 minutes to execute depending on how many participants are involved. It’s a great ice-breaker and will keep everyone focused if you’re one of those evil managers with a habit of scheduling the PMO meeting after lunch.

Supplies – What You’ll Need

  1. Pink (or any color) note cards x4
  2. White note cards x16
  3. Sharpies x4
  4. Stop watch x1
  5. 1 person to facilitate and keep time
  6. 4 or more people to participate

Setup

Write 4 different project management topics on your pink notecard (in the examples below, my team used: integration, program management, execution, and procurement)

Place 4 of the blank note cards (or more if there are more than 4 people in a group) under a pink card with the project management term written on it.

Write the following instructions on a whiteboard for everyone to read:

  1. Please get into a group of 4 people.
  2. Each person will be given a group of note cards (keep them together at all times).
  3. The 1st note card will have a Project Management term on it (Do not share this word with anyone in your group until we are done with the game).
  4. Every 1 minute, we will rotate through the note cards as follows (The facilitator will keep time and ensure the note cards pass to each person):
    1. First Person, read the term on the pink card, then place that card behind the stack of cards and draw the term on the first blank note card. Pass all of your note cards to the next person with your drawing on top.
    2. Second Person, Based on the drawing the first person made, Write the term on the next blank note card. Pass all of your note cards to the next person with the term you wrote on the top.
    3. Third Person, Read the term the second person wrote and place it behind the stack of cards. Draw the term the second person wrote on a blank note card. Pass all of your note cards to the next person with your drawing on top.
    4. Fourth Person, Based off of the drawing the third person made, Write the term on the next blank note card. Pass all of your note cards to the next person with the term you wrote on top.
    5. Assuming a group of 4, the first person should have the original project management term they started with — the pink card they first read to start the game. Starting with the pink card, each person read the original term and share the pictures and terms in the order they were drawn. 
    6. Facilitator should allow each person to describe their pictures and encourage a few minutes of conversation.
  5. Final Note: Drawings can not have any written words or prompts on them. Pictures only!

Below is an example of the final results our group had:

Topic: Integration

As you can see, the first three people were able to communicate “integration” pretty well. The fourth person wrote “tools & techniques.” When we discussed this as a group, the pot in the third picture reminded the fourth person of tools and cooking techniques used in the kitchen.

Topic: Execution

This one was pretty funny. I started off this iteration and chose to draw a stick figure getting decapitated at a guillotine. I felt this was a an obvious example of “execution.” Unfortunately, the second person didn’t pick up on this and guessed “penalty.” Naturally, the third person figured this was a “penalty” and related that to budget and drew a picture that led the fourth person to assume “over budget.” We were way off the mark with this and shared some laughs.

Topic: Procurement

On my opinion, this was the hardest topic. During our discussion, the first person stated they had a tough time trying to draw a picture for “procurement” in 1 minute or less (heck yes! I still don’t know what I could draw). The closest thing they could draw looked like communication management and that was what we all guessed at. Again, we weren’t even close!

Topic: Program Management

I think the first person did a great job with their picture. A program is a group of similar projects or activities. The use of a the box plot diagram was straight out of the PMBOK. Unfortunately, as we discovered, the artist chose to use 5 circles to represent the projects inside of the program. The second person focused on this fact and guess “the 5 phases of a project.” The third picture, which is mine, has a stick figure using a phaser on a column of 5 (pretty creative if you ask me). The final person guessed “5 knowledge areas.” I guess my picture wasn’t as good as I thought it was.

Take Aways – Common Mistakes With Communication

There’s plenty of material about the basic communication model. I’ll try not to rehash something we all know, so I’ve just highlighted a few of the key takeaways from our lecture and subsequent discussions.

Confirm communication is actually received and understood.

Research says that in a face-to-face interaction:

  1. 58% of communication is through body language
  2. 35% of communication is through how the words are said
  3. 7% of communication is through the content or words that are spoken
  • Pay attention to more than just the actual words someone is saying.
  • A person’s tone of voice and body language say a lot about how they really feel.
  • Ask people what information they need and when.
  • Plan communications to all stakeholders and project team members and a way that fits their needs.
  • Customize communication standards within your organization to the needs of the project. Don’t stick with a template if it’s not effective!
  • Use multiple methods of communication.
  • Realize that communication is two-sided, to and from a stakeholder or project team member.

Share your thoughts on communication or using the Telestrations game in your next meeting in a comment below. If you’d like to have a discussion, please contact me or connect with me on social media!

Photo Credit: Pixabay

Related Posts

The Quick And Dirty On Stakeholders

Scrum Product Owners Part 2

Scrum Product Owners Part 1