Author: Jeremy Brien

THE 5 STAGES OF CONFLICT HURTING YOUR CROSS FUNCTIONAL TEAM

| Jeremy Brien

 

Helping cross functional teams navigate conflict

High performing teams don’t avoid conflict; they manage it effectively. There are four main types of conflict that can occur on a team in your business.

  • task conflict – differing opinions on how to approach a problem or complete a project goal
  • relationship conflict – personal disagreements or hurt feelings between team members
  • process conflict – the team’s decision-making procedures, including how decisions are made and who has the final say
  • value conflict – differences in beliefs or goals.

As team leader, it’s important to identify the types of conflict that are occurring within your team so you can initiate intervention strategies, facilitate open communication, or at the very least, not get caught in the mud flinging in your business.

High performing teams succeed because they have psychological safety in a group of highly motivated individuals. High performing teams focus on success and sustainable practices.

Psychological safety is a shared belief that it’s safe to take risks and be vulnerable with each other. This doesn’t mean that there’s no conflict; rather, it means that team members feel comfortable enough to speak up when there’s a problem and trust that their suggestions will be heard and respected. Progress is an endless pursuit and creating psychological safety is essential for managing conflict constructively so that it doesn’t escalate into team dysfunction and distract from project goals.

As a team leader, you know that conflict is inevitable. But did you know that there are different stages of conflict? And that each stage can hurt your team in different ways? In this blog post, we’ll explore the 5 stages of conflict and how they can impact your cross-functional team. By understanding the stages, you can take steps to mitigate the hurt and keep your team succeeding.

STAGE 1: QUESTIONING AND CONSTRUCTIVE DISAGREEMENT ON HIGH PERFORMING TEAMS

Usually characterized as constructive disagreement, stage 1 conflict is a hallmark of a team focused on fixing the problem at hand. Information flows openly and honestly. Team members use language that is direct, specific, and based on facts — clarifying questions are used to discern what was said.

One of the key characteristics of a high level team is their high degree of trust and mutual respect. This level of conflict is healthy and indicative of a team that values technical excellence and a commitment to continuous improvement. They typically adopt agile processes and sustainable development practices. They value early and continuous delivery and help prioritize the customer’s competitive advantage.

Team’s naturally resolve conflict at this stage because well formed cross-functional teams are aware of the team’s performance goals and high level objectives. Their leaders prioritize continuous learning and celebrate wins.

One of the frameworks I promote is scrum (which is an agile process and lightweight framework). It helps create self organizing teams and promotes early and continuous delivery. Following agile processes will help ensure that conflicts are resolved in a timely and efficient manner with improvements scheduled on a regular basis. Agile processes harness change, efficient development processes, and face to face conversation. In my years as a team leader and facilitator, I have yet to find a more effective method for building high performing teams with motivated individuals.

“If we don’t trust one another, then we aren’t going to engage in open, constructive, ideological conflict. And we’ll just preserve a sense of artificial harmony.”

Patrick Lencioni

–The Five Dysfunctions of a Team

STAGE 2: PERSONALIZED DISAGREEMENT AMONG HIGH PERFORMING TEAM MEMBERS

Team members start to own their perspectives about the problems. This is usually a good thing. However, it’s really easy for team members to personalize opposing perspectives and may engage in separate conversations outside the group as a whole. This is common among self organizing teams. However, when healthy joking around starts to look like personal jabs and shots, there might be a problem and team goals are at risk.

Technical excellence suffers when team members start building walls and are wary to extend their bridges to members with opposing perspectives.

Clarifying questions are used to discern why something was said vs what was said. This is an interesting among a high performing team culture if open communication is present and deeper problems can be uncovered and resolved quickly. If team members perceive that they can openly communicate with one another, then a positive team culture will develop and thrive.

If team members do not feel that open lines of conversation is present, then a negative team culture may develop. It’s important to schedule time with the team at regular intervals to support a positive team culture and ensure that ideas can be expressed safely with organizational and team goals in mind. When the team reflects on their interactions, positive cultures strengthen. Conflict is natural and can be managed by anyone on the team.

The key here is to always ask clarifying questions. They help to keep expectations open and prevent misunderstandings from occurring. When high performing team members feel that they can openly communicate with one another, they are more likely to trust one another and work together more effectively. Trust is essential for high performing teams, and clarifying questions help to build trust by ensuring that everyone is on the same page. By fostering support and trust, clarifying questions help high performing teams to thrive.

When the team reflects on their interactions, the organization wins.

STAGE 3: TEAMS START CHALLENGING PEOPLE INSTEAD OF IDEAS

Team members need to feel like they own their perspectives and that an opposing point of view is not a threat to them as a person. When members start attacking and challenging each others instead of an idea, business goals are at risk and your team is now navigating in a hostile environment.

If you’re a team leader, stopping conflict from escalating further should be your highest priority. Otherwise, employees quit because your business and its leaders fail to build a healthy culture.

Managers should get involved and lead discussions focused on fixing the problem, and not on winning. Past mistakes should not be brought up and used against others; this will only lead to power struggles and factions forming within the organization. If this happens, you’ll no longer have a sustainable development and you’ll struggle to use any agile processes harness change.

Effective communication is essential in team environments, especially when requirements are constantly changing. All team members need to be aware of the progress being made, and what needs to be done in order to achieve success. Focus on the complementary skills and conveying information that support understanding and common ground.

STAGE 4: THERE’S A CALL TO ARMS BETWEEN TEAMS

When team members are committed to their point of view, it can be difficult to come to a consensus. It’s important to support each team member’s ability to share their opinion and expectations for respectful debate, but when face to face conversation becomes hostile, the team’s ability to resolve conflict on their own is gone. Other teams in the organization should be made aware of the issue and instructed to steer clear or you’ll risk other organizational goals.

The most effective method for leaders in this situation is to reflect on the various points of view and focus on finding common ground among the employees. When factions within the team start to form, it is important to nip it in the bud and lead by example by initiating one on one conversations and conveying information about how the interactions being reported are impacting other people’s ability to do their job.

Factions can often be divisive and create office conflict. Ideologies, pressure from faction leaders, and recruitment of others from outside the team can all be signs that factions are forming. If left unchecked, this can lead to tension and polarization within the team or among teams. It is important to address these issues early on so that the team can reset some of their practices and revisit their working agreements. Leaders should revisit working agreements with these teams at regular intervals.

STAGE 5: TEAMS ARE ON THE BRINK OF ALL OUT WAR

The tension in the room is palpable when employees are forced to work together in close quarters. Members find themselves physically distancing themselves from one another and raising their voices at inappropriate times. The pressure to perform is high, and dissension among employees is not tolerated. This can lead to a hostile work environment where employees are afraid to voice their opinions or offer constructive criticism.

In some cases, violence may even be imminent. In these situations, it is important to remember that employees are still people with feelings and needs. Businesses should do everything they can to avoid putting folks in this type of situation. By promoting a healthy workplace environment, businesses can ensure that employees are able to work together efficiently and productively without fear of reprisal.

ENCOURAGING TEAMWORK TO FOSTER AGILE TEAMS

Fostering healthy communication and trust between employees is essential for creating a successful work environment. It is important to establish clear expectations and guidelines for how teams should communicate. When issues arise, managers need to be prepared to step in and mediate any conflict that may arise. By doing so, teams can maintain their productivity while avoiding the risk of an all out war.

As a leader, the goal is to avoid conflict between teams by encouraging teamwork and collaboration. To do this, managers should focus on promoting a culture of respect and openness. Team members should be encouraged to openly share their ideas and solutions without fear of reprisal or being judged. Managers should also strive to create a work environment that encourages collaboration, creativity, and innovation.

When teams are equipped with the information they need and given the resources they require, they can work together effectively and efficiently towards common goals. This is a leader’s highest priority in order to promote high performing teams and avoid costly conflicts.

With proper guidance, teams can work together towards common goals without resorting to destructive tactics.

Photo Credit: Flickr

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

| Jeremy Brien

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

Thoughts On The 15 Leadership Traits

| Jeremy Brien

During my time in the Navy, I was housed on a Marine Corps base; it was just a few blocks away from where my ship was moored. It was my time there that I befriended a Marine Corps Sergeant — we were close drinking buddies and remain friends today. More importantly, we were both Non-Commissioned Officers (NCOs) in our respective military branches. One topic we discussed at length was leadership. Somewhere during my career, I learned the acronym JEDI JED BHUCKLIT, which has helped me remember the 15 traits of leadership. Each of these traits have specific meanings for a military leader, however, they are timeless qualities of leadership and endure for leaders regardless of their organization.

So, what is leadership? In the military, we define leadership as “the ability to lead, guide, or influence others so as to accomplish a mission in the manner desired.” This definition has stuck with me for as long as I can remember. Some leaders are defined by their position in the organization and are recognized formally by their title. Others are considered leaders because of their influence on others or their technical expertise. Regardless of your current position, you can always be a leader if you possess and strive to practice the following traits.

Leadership is the ability to lead, guide, or influence others so as to accomplish a mission in the manner desired.

The 15 Traits Of Leadership (JEDI JED BHUCKLIT)

Judgement – The ability to weigh different facts, opinions, or the expertise of those who serve under you. Taking in information, whether complete or not, and making a decision based on your own experiences and training.

Enthusiasm – Radiating genuine excitement for the goals of the organization. Emotions are contagious and a leader who sincerely believes in the goals of the organization will inspire those around them to believe in those goals as well. 

Dependability – Reliability and consistently following through on personal and professional commitments.

Initiative – Spotting a problem and taking action to address it in the absence of instructions from supervisors, managers, or even peers. 

Justice – Giving clear and concise expectations. Remaining consistent when delivering rewards or punishments based on those expectations. Holding oneself and others accountable in accordance with those expectations. 

Endurance – Keeping long and short-term goals in mind. Following through with them to completion, even in the face of adversity. 

Decisiveness – Making decisions in a prompt and timely manner — making your decision known and easy to understand for others to act on.

Bearing – Being a team player and presenting yourself in a positive manner, even in the face of adversity or stress.  

Honor – Treating yourself and others with esteem and respect. 

Unselfishness – Lifting others up and sacrificing one’s own comfort for the sake of others or the mission at hand.

Courage – Recognizing one’s own weaknesses and fears but proceeding forward with calmness and firmness. Pressing forward and following your values, even in the face of criticism. 

Knowledge – Skills and expertise related to one’s profession and recognizing when to lean on the advise and expertise of others.  

Loyalty – Remaining faithful to one’s subordinates and organization and acting in a way that best servers their interests over yours. 

Integrity – Doing the right thing, even when no one is looking. 

Tact – The ability to speak honestly to others without creating offense. 

Thanks for taking the time to read. I’d love to hear your thoughts on leadership. 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!

Related Posts

Figure It Out, Larry! A Story On Anti-Patterns.

Reflections On Courage. What Rocky Balboa Taught Me About About Failure.

Agile Leaders Understand Customer Service And Culture

 

The Difference Between QA & QC

| Jeremy Brien

What’s The Difference?

Quality Assurance and Quality Control are often used interchangeably. Many development teams have one or two members designated as “testers” or “QA/QC.” Unfortunately, this is a symptom not knowing the difference between Quality Assurance and Quality Control. Most likely, these teams have a consistent bottleneck between development and testing activities. This causes frustration with the customer because they’re only getting new functionality delivered every few months vs. after each iteration.

Quality Assurance – It’s Everyone’s Responsibility

Quality Assurance are the processes and activities that ensure something is built well. This means it’s something everyone practices. Test-driven development (TDD) is an example of “baking in quality.” Instead of creating something and then testing it, we test and build at the same time.

I like to think of quality assurance like safety in a factory. A factory may have a “safety officer” who’s in charge of the overall program, but safety is everyone’s responsibility. It’s not the job of the safety officer to make sure you’re not misusing any equipment; the safety officer is charged with teaching practices about safety and creating a culture of safe practices. This is because the safety officer can’t be everywhere at once. Instead, it’s everyone’s responsibility to enforce safety and call out violations when they see them. It’s not to punish or harass, but to save lives and save the company from liability.

The same goes for your QA people. They shouldn’t sit over the shoulder of developers like hawks, inspecting every line of code. They don’t have the bandwidth or technical knowledge to carry out that task — and it’s not effective either. Instead, QA should be inspiring a culture of quality and encouraging creativity. QA should be helping with process improvement and identifying ways to remove waste and promote quality.

They shouldn’t sit over the shoulder of developers like hawks, inspecting every line of code. They don’t have the bandwidth or technical knowledge to carry out that task — and it’s not effective either.

Quality Control – Marking The Checkbox

Where Quality Assurance relates to “how” the software was made and making it everyone’s responsibility, Quality Control is the activities related to formally documenting and inspecting the product. This is where standardized documentation can help. Use just enough documentation as it makes sense, to ensure conformity to the

inspect
Inspect and test at the same time. Photo Credit

specifications of the client. This can be baked into the quality assurance process as well. Returning to our example of test-driven development, once a component is complete, saving the results of the unit test can be used as evidence of functionality. The combination of multiple components and testing their functionality is an integration test. Again, saving these results is evidence of interoperability via integration testing. Pushing new code into the existing code set and examining how the system reacts is called regression testing and we can save these results as well. I think you’re starting to get the idea though

 

Thanks for taking the time to read. I’d love to hear your thoughts on quality management. 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

Quality Is Anti-Fragile

The People And Process Balancing Act

Improving Agile Retrospectives With SMART Goals

 

How To Visualize Your Work And Be More Productive

| Jeremy Brien

Take Control Of Your Time

Do you find yourself saying, “if only there were more hours in the day?” There’s plenty of high-profile articles and advice by industry leaders like Warren Buffet advising us to, “keep control of your time.” If only it were that easy, right? I know I could do a better job of managing my time, but over the past few years I’ve gotten better at it. I started applying some of the principles I’ve learned in Agile to help me keep organized at work and in life. Here’s my advice to those out there who may be struggling to keep control of their own time.

Steps To Take Control Of Your Time

  1. Wrap Your Arms Around Your Work. The first thing I started doing was taking an inventory of all the work I was doing. It started in a simple excel sheet. It was a mess at first, but I kept adding things to it as stuff came up and I started to get a handle on what my time was being spent on.
  2. Classify and Categorize. I started taking 15 minutes during my lunch break to identify trends in the spread sheet. I started putting different things into “buckets.” I kept these buckets fairly high level. I borrowed from a book I read called The Phoenix Project. One of the lessons it teaches is that there are only four kinds of work we do in IT.
    • Business Projects – projects that generate revenue and crosses other departments.
    • Internal IT Projects – projects that your organization doesn’t typically “see” but is impacted by; like upgrading that database from SQL Server 2008 to 2016.
    • Changes To Production – operations. This can be something like pushing out new group policies to end users.
    • Unplanned Work – a time suck. We know this work well. Fire-fighting because it’s extremely urgent and important. Those familiar with Stephen R. Covey and his book, The 7 Habits of Highly Effective People know this as “living in quadrant 1.” 
  3. Find A Tool That Fits Your Needs And Get Organized. I’m a millennial, and keeping an excel spreadsheet up to date is difficult. On top of that, I prefer using tools that work on any device I choose. I use my iPhone, laptop, or desktop interchangeably throughout the day. I need a tool that works for me no matter where I am. That’s why I settled on two tools:
    • Microsoft Outlook – I use Outlook because it’s the primary calendar tool we use at work. It also gives me the ability to create separate calendars.

      ColorCodedCalendar.png
      Associate colors with projects, teams, or categories of work in Outlook

      I work full time during the day, I write, I blog, I’m helping a family member launch their business online, and I’m also taking 4 classes at the graduate level. Needless to say, I’m extremely busy. Not only do I have separate calendars for different parts of my life, I also color code things using the “categorize” option. I associate these colors with teams, projects, and my “categories of work.” Microsoft has a free app for outlook and allows you to connect multiple email accounts too. It’s perfect for someone like me who has 4 email accounts.

    • Trello – I use Trello because it allows me to organize my work at the task level. It has a simple and elegant interface on both desktop, web, and mobile. It updates immediately no matter where you connect. So I can add a task during a meeting and see it when I get back to my desk. The idea is to create “boards” for your projects and fill them with cards for your tasks. You can also add checklists, tags, and color code your cards too. My capstone group ran an entire software project on Trello and it worked like a charm. We created a drink recommendation app called B.A.R.T.E.N.D.E.R. — it’s still up but hasn’t been maintained since graduation. Trello also allows you to add due dates and to collaborate with multiple people. I set up my own personal board as a Kanban board and use it daily because it allows me to prioritize and keep my arms wrapped around my work.
  4. Start Saying, “No.” You are now armed with visual information about what your work load looks like. You’re likely juggling way too much that’s marked as “In Progress” and barely making headway on anything meaningful or important. You’re armed with empirical evidence that you’re over capacity and over committed. It’s time to start saying, “no” to things. Be respectful with your co-workers and managers and let them know that until you can start moving things to “done,” you currently don’t have the bandwidth to take on any extra work. Radical idea, I know. But did you know that your manager wants to hear these things? They may not take you seriously at first but you can easily show them. Let them know that if any new items land on your plate that is considered a high priority, they’ll need to move something else that’s “in progress” to the back burner and extend that deadline to accommodate the new task. If there’s a trend with things being swapped in and out of “in progress” and never getting “done,” then I’m willing to bet your manager needs some help staying organized themselves. That’s another conversation though. If you’re bombarded with meeting invites without an agenda, follow up and ask for one. If no one gets back to you, decline it. My philosophy is, “how can I come prepared and what will the action items be?” If I don’t get an answer, they probably didn’t need me. You can also ask if there’s anything that can be done without the meeting. A quick message on Skype or a few short email exchanges can make meetings avoidable all together.
  5. Find Ways To Streamline The Repeatable Tasks. Anything that is reoccurring can be scheduled around or automated in some way. You’ll need to research how to do this, but invest some time or find ways to cut out tasks that aren’t valuable. Eliminate the waste. If you’re a knowledge worker like me, using a programming language can help. One book I picked up a while back, Automate The Boring Stuff With Python, contains a wealth of information and ideas, and there’s an accompanying course on Udemy as well.
  6. Invest In Yourself. Many of my peers and colleagues think I’m crazy for how “busy” I am. But, I’m busy doing the things I enjoy. I’m investing time in myself and getting my Master’s degree. I write and I blog. I have a social life. I even mark of a few hours a week on my work calendar for training and development. I wouldn’t be able to do these things if I wasn’t taking control of my time and doing the things that truly matter.

Thanks for taking the time to read. I’d love to hear your thoughts on how you stay organized! 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

 

 

 

 

 

Quality Is Anti-Fragile

| Jeremy Brien

As the adoption of Scrum continues to grow,  non-technical people begin to fill the role of Scrum Master or Product Owner. This is a great thing, as it helps the business align with Information Technology. The organization’s IT unit isn’t seen as a service any longer; instead, they become business partners. Conversations break through company silos as Developers learn the business lexicon and Line of Business personnel learn how to build better software. Processes form to create quality. Quality software is beautiful.

Quality Systems Are Anti-Fragile

So what’s quality? It’s one of those things we know we need. But, what are we talking about when we say, “bake in the quality?” There’s so many definitions that exist today, but I like to think of quality as “anti-fragile.”

What do I mean by “anti-fragile.” It’s a concept developed by Professor Nissim Nicholas Taleb in his book called Antifragile. He describes “systems,” whether those systems are processes, organizations, software, or even cultures, that can withstand the stresses of the environment which act upon them. Anti-fragile is much more than “resilient,” meaning it stays the same despite what the environment throws at it. In software development, we strive to produce more with less effort. We strive for business agility. We pivot and adjust our processes as the environment throws things at us and we are anti-fragile. We use feedback loops, like retrospectives, Six Sigma, and Continual Integration.

We give developers freedom and autonomy by giving them “what” needs to be done, they tell us the “how.” Antifragile means being adaptive. Selection of the right tools and technology for the right job — versus prescriptive.

Anti-Fragile As An Analogy

Professor Taleb uses a great analogy in his book. He asks you to picture something in your home that you’d consider “anti-fragile.” This might be something like the remote control for your television or even your sofa. Of course they can break, right? But, they’re designed to take a bit of punishment. They’re designed to conform and adapt as they are used — they are serving a function and withstanding inputs from the environment. In fact, your sofa tends to feel more comfortable over time as it conforms to your body.

Now picture something in your home that you’d consider “fragile.” This might be something like your grandmother’s china or an ancient grandfather clock. They’re usually tucked away in the safest part of the house and are rarely touched. Why? Because we’re afraid we’ll break them. They’re designed to be aesthetically pleasing — serving a function and withstanding stresses from the environment were not considered in their design. These objects are fragile and saved for “the special occasion.”

Beauty In The Anti-Fragile

So what approach should we take to software development? Should we design something that’s large and complex but liable to break whenever a code commit is pushed? When there’s a tight schedule, should we spend our effort designing something beautiful to the eye but doesn’t serve our purposes? No, we shouldn’t.

I contend that there’s beauty in software when it just works. There’s beauty in software when it serves our users and solves their problems. There’s beauty in software when it gets better over time — not when it falls apart.

Thanks for taking the time to read. I’d love to hear your thoughts on quality or anti-fragile. 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!

Related Posts

Improving Agile Retrospectives With SMART Goals

 

Side Stepping Landmines: Managing Risk With Sprint Futurespectives

| Jeremy Brien

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

| Jeremy Brien

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

| Jeremy Brien

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