Farming as a Metaphor for Workplace Culture

Michael Wade has an interesting post considering how non-agricultural workplaces can resemble farms.

Workplace cultures are in large part a reflection of the underlying metaphor driving the organization, whether by design or chance. When much younger, I used and advocated the “business is war” metaphor. I have been much more successful (and much less stressed) organizing around a farming metaphor. For truth, there can be times of battle on the farm that, as in the war metaphor, require the immediate and drastic mobilization of resources: the barn is on fire, the locus are coming, a tornado approaches. Life on the farm is more than endless summer days spent blissfully feeding magic ponies and dancing under rainbows. One must be prepared to “take up arms” and employ non-farm related tools and tactics in order to deal with any short term crisis that may occur.


Photo by Lucy Chian on Unsplash

Plans, Strategies, and Uncertainty

“It is difficult to make predictions, especially about the future,” is an insight attributed to about two dozen sources. Actually, any one of us could have said this for it’s certain we’ve all had an intuitive feel for the truth revealed by these words. This is undoubtedly why we work so hard to tease out the details about what the future may hold by making plans, laying out strategies, and running scenarios based on our version of the best data available today. Each of these tools are employed in an effort to reduce uncertainty about the future. But which tool to use? Therein lies the rub. The answer, rather unhelpfully, is “It depends.”

  • How complex is the problem space?
  • How well is the problem space understood?
  • What is the availability of resources (time, money, people, materials, etc.)?
  • What is the skill level and experience depth of those tasked with developing a plan or a strategy?

Stated simply, creating a plan and sticking to it is ideal for simple, well understood, small scale problem spaces where one or more resources are limited. They work if the individual or team tasked with finding a way through the problem space is inexperienced or lacking skills required by the problem space. As complexity and uncertainty increase, the way forward benefits with a more flexible approach. This is where it’s helpful to have a strategy, something that is more than a single course of action. Rather, a strategy is a collection of possible paths, each with its own set of plans ready to be implemented if the need arises. Working a strategy requires a higher order of skills. It requires systems thinking that has been tested and vetted for competence rather than just a shallow claim of being a “systems thinker.”


Image by Maddy Mazur from Pixabay

Collaboration vs Clobber-ation – Redux

A reader took me to task for “not being a team player” in my example of walking away from an opportunity to co-develop a training program with a difficult Agile coach. It was easy to set this criticism aside as the person offering it was in no position to be familiar with the context or full story. Nonetheless, the comment gave me pause to consider more deeply the rationale behind my decision. What experiential factors did I leverage when coming to this seemingly abrupt decision?

I can think of five context characteristics to consider when attempting to collaborate in an environment charged with conflict.

  1. Is the disagreement over the details of the work to be done? My peer and I didn’t have agreement on whether or not it was important or useful to include information on basic story sizing as part of the story splitting presentation. I wanted to include this information, my peer did not.
  2. Is there a disagreement over how the work is to be done? I wanted to preface the story splitting section with a story sizing section whereas my peer was intent on eviscerating the story sizing section to such an extent as to make it meaningless.
  3. Is there any type of struggle around status or who “should” be in charge? My peer demonstrated unambiguous behavior that she was “The Coach” for the company and that anything that may be presented to employees should be an expression of her authorship. When she instructed me to send my deck of slides to her for “revision” and I refused, she visibly bristled. By this point, I wasn’t about to release my copyrighted material into her possession.
  4. Are there corporate politics that promote – intentionally or unintentionally – silos and turf protection? My client’s organization could be be held forth as a textbook example of Conway’s Law. The product reflected an uncounted number of incomplete efforts and failed attempts at unifying the underlying architecture. The Agile Coach’s behavior was just one more example of someone in the organization working to put their stamp of value on the ever-growing edifice of corporate blobness.
  5. Is there a conflict of personalities or communication styles? Again, this was true in this case. I wanted to co-create whereas my peer wanted to commandeer and direct. I wanted to present, she wanted to interrupt.

No work environment is free of these characteristics and it may be they are all present in some degree or another. I expect these characteristics to be in place no matter where I work. However, in this case, it was clear to me we were not in alignment with any of these characteristics and each of them were present at very high levels. Sorting this out wasn’t worth my time at just about any price. Certainly not at the price I was being paid. Walking away wasn’t going to burn any bridges as no bridges had been built.


Image by Dirk81 from Pixabay

Accountability as a Corporate Value

My experience, and observation with clients, is that accountability doesn’t work particularly well as a corporate value. The principle reason is that it is an attribute of accusation. If I were to sit you down and open our conversation with “I need to talk to you about something your accountable for.”, would your internal response be positive or negative? Similarly, if you were to observe a person of higher status on the corporate ladder clearly engaged in a behavior that was contrary to the interests of the business, but not illegal, how likely are you to confront them directly and hold them accountable for the transgression? In many cases, that’s likely to be a career limiting move.

There is a reason no one gives awards for accountability. Human nature is such that most people don’t want to be held accountable. It carries the inference of shouldering the blame for something when it goes wrong. Credit is what we get when things go right. People do, however, want others to be held accountable. It’s a badge worn by scapegoats and fall guys. Consequently, accountability as a corporate value tends to elicit blame behavior and, in several extreme cases I’ve observed, outright vindictiveness. The feet of others are held to the accountability fire with impunity in the name of upholding the enshrined corporate value.

Another limitation to accountability as a corporate value is that it implies a finality to prior events and a reckoning of behaviors that somehow need to balance. What’s done is done. Time now to visit the bottom line, determine winners and losers, good and bad. Human performance within any business isn’t so easily measured. And this is certainly no way to inspire improvement.

So overall, then, a corporate value of accountability is a negative value, like the Sword of Damocles, something to make sure never hangs over your own head.

Yet, in virtually every case, I can recognize the positive intention behind accountability as a corporate value. What I think most organizations are going after is more in line with the ability to recognize when something could have been done better. To that end, a value of ‘response ability” would serve better; the complete package of being able to recognize a failure, learn from the experience, and respond in a way that builds toward success. On the occasions I’ve observed individuals behaving in this manner repeatedly and consistently, the idea of “accountability” is near meaningless. The inevitable successes have as their foundation all the previous failures. That’s how the math of superior human performance is calculated.


Image by Chris Pastrick from Pixabay

Teams, Tribes, and Community – 0.1.0

Several months ago, I made bold decision: Take command of the helm for a brilliant tribe of diverse creative thinkers dedicated to helping each other succeed. This is the first of an on-going series of posts – maybe once or twice a month – describing this evolving effort.

For an extrovert, this might not have been a bold decision. But in my case, you should know I designed the card that card-carrying introverts carry. So this decision involved a more thorough application of my already robust decision-making process. On a professional level, this may be the most significant challenge I’ve taken on to date. Will my years of experience with forming and guiding teams help this tribe further their success? Will I be able to find the gravitational force that holds us together and the spark that keeps us inspired? These are open questions. They are also questions that occupy much of my thinking.

We are not dedicated to achieving a single goal or moving in a unified direction. We each have our areas of expertise and independent business goals. We are much more a tribe than a team. As such, I believe we will be guided more by tribal dynamics and models than team rules and policies. The path is not clear, but this much I know…

  • There is no leader of this tribe. Not in the sense of a single person who’s responsible for setting the direction and making all the decisions that impact the organization. There is no “Chief” or “Czar” of anything. I’ll fill the role of Launch Commander and Flight Commander in order to get us organized and moving forward. However, I have been clear from the start about my intention to structure our tribe on principles of self-organization.
  • The emphasis is on simple and accessible technology and easy ways to organize meetings based on Agile principles and practices – lean coffee, for example, has served us well for our initial meetings. What has emerged since then are more involved and interactive meeting formats, such as client role-plays and accountability exercises. Keeping things simple and remaining mindful of barriers to participation is vital. Too many tools with too many logins risks the creation of a Tower of Babel. For now, the weekly video call is the center-point around which we all meet. This in itself is enough of a challenge given the global participation. Other than this, email is the acknowledged primary channel for asynchronous communication.
  • We are not accepting new members. Whether or for how long this remains the case is undecided. We have discussed various ways of introducing new members, but have decided to decide on this issue later. The circumstances that brought each of us together created a unique bond of trust and familiarity with each other’s business interests that makes the introduction of new members a risk to maintaining these relationships. At the moment, we are tipped slightly toward being on the large size and everyone acknowledges if we grow much bigger the meetings may become unmanageable and the interactions less valuable. Since trust is foundational, none of the details related to who we are and what we discuss will be revealed in this space. My writing will be limited to the general case of what I discover from having participated in and helped guide our tribe. It is my hope this may help others with forming and guiding their own teams and tribes.

Whatever the outcome, it’s been more fun thus far than I’ve had in a loooooong time.


Image by Youssef Jheir from Pixabay

Fall Reflections – 2021

Over four years ago, I was in a position to retire early. After some thought, the idea didn’t suit me. I was, in the arc of my life, in an entirely novel position. I could be much more selective about where I chose to exchange my time for money. With nothing to lose and a lot to gain, I sought work with a company that would put Agile principles and my coaching skills to a rigorous test. Did I have what it takes to guide a global legacy corporation into an Agile learning organization? I ran this experiment within the software divisions of two different medical device manufacturers. The first was a 6 month engagement that ended when a better option opened up at a much larger manufacturer with more pay and less commute. I was there for three years until a layoff in the spring.

So it is I’ve come to wrapping up an extremely active spring and summer after having tripped a wire that launched me into a career shift about six months earlier than planned – a span of time I’m affectionately calling an unplanned sabbatical. I’m still not ready to retire, but I’m in an even stronger position then I was four years ago – the silent advantage of a Stoic minimalist lifestyle. Shedding the corporate baggage has opened up a universe of space and time for unfettered thought and exploration. Sabbaticals should be integrated into the work lives of every employee who demonstrates integrity and a strong work ethic.

In the coming months, I’ll be writing more about what this new direction involves. A change in direction doesn’t begin to capture the shift. There’s a multi-leveling up in play, too. This fall and winter – seasons ideally suited for deep reflection and planning – will see a continued pace of activity and preparation. Belying the quite stillness of winter, I will be extremely busy moving fieldstones into position and crafting a renewed foundation for success.

The purpose and mission I declared at the very beginning of 2020 is still in place. When I crafted that mission I was at the very beginning of a grand experiment, full of optimism and yet fully aware of the daunting task ahead. The company I was working for presented me with choice: I could accept a new management role or pursue a stated goal of mine to create an official Agile Coach position within the software group. The organization had just created an official scrum master role in the org chart, but the PMO was strongly resisting the idea of an official product owner role. I was an epic turf battle.

The management path offered greater security but had significant downsides. Not only would I have the decidedly unpleasant task of managing people in a highly regulated and bureaucratic organization, I would also be expected to fill in the scrum master gaps on various teams. This sounded like a good way to end my career as an Agile Coach.

The coach path offered the highly appealing challenge of implementing Agile and SAFe in a 60 year old medical device manufacturer. The known risks included a certain tsunami of resistance. I’d be out on a limb, working to navigate in uncharted and dangerous waters. But I had excellent support. The arrival of a new CEO broke up many of the old ways of organizing software development and opened a window of opportunity. After a rigorous decision process, I chose the Agile Coach path. My 2020 mission reflects the enthusiasm I had for having made this choice.

Then things went sideways. The new CEO brought a much bigger broom than anyone imagined and my key executive support left the organization. Two new senior execs were hired that had a rather stunted understanding of Agile, SAFe, and working with software professionals. Progress stalled as head nods and “Yeah, we’ll get to that.” can-kicking substituted for action. A lot of really good people started to leave the organization, including what was left of my support and allies. A deeply disturbing experience while serving as the Unofficial Official Agile Coach and the effects of the pandemic lock-down sunk the Agile Coach boat. The bubble I placed myself on became more so. I’m surprised I wasn’t laid-off sooner.

The period since separating from my previous employer in early 2021 has been a period of immensely positive growth. The gain in perspective on the prior three years has enlightened me to just how toxic the work environment was. Taking that job was an experiment and in the end the primary failure was not discovering sooner that the experiment was destine to fail. My optimism was misplaced. I trusted untrustworthy people. The greater sadness is that the organization has a wonderful mission and excellent products, each held back from what they could be by a select few and their caustic alliances within the organization. My health and well-being are much the better for having left on their dime.

 I finished my 2020 declaration with “Here’s to moving into 2020 with mind and eyes wide open.” And so I did. Where to next will be on my terms. Free from people who talk inclusion but practice exclusion, talk diversity but practice conformity, talk about change but fight for stagnation, and talk about collaboration while protecting their tiny fiefdoms with vindictive ruthlessness. My tuned purpose and mission for 2022 will reflect this. And a good start will be to conduct business operations in ways that are aligned with the Mission Protocol.


Photo Credit: Original, Copyright © 2021, Gregory Paul Engel

Behind the Curtain: The Scrum Master Role

It’s popular to characterize the scrum master role as following a “servant leader” style of engagement with scrum teams. Beyond that, not much else is offered to help unpack just what that means. The more you read about “servant leadership” the more confused you’re likely to get. A lot of what’s available on the Internet and offered in trainings ends up being contradictory and overburdening to someone just trying to help their team excel. Telling someone they’ll need to become a “servant leader” can be like telling them to go away closer.

So let’s unpack that moniker a little and state what it means in more practical terms for the average, yet effective, scrum master.

To begin, it’s most helpful to put a little space between the two skills. As a scrum master you’ll need to serve. As a scrum master you’ll need to lead. When you’re a good scrum master you’ll know when to do each of those and how. Someone who tries to do both at once usually ends up succeeding at neither.

As a servant, a scrum master has to keep a vigilant eye on making sure their servant behaviors are in the best interests of helping the delivery team succeed. If the scrum master lets the role devolve to little more than an admin to the product owner or the team then they’ve lost their way. It will certainly seem easier to write the story cards for the team, for example, rather than spend the time coaching them how to write story cards. This is a case where leadership is needed. On the other hand, if someone on the team is blocked by a dependency due to an overdue deliverable from another team, then the scrum master would indeed serve the best interests of the team by working with the other team to resolve the dependency. Requiring the delivery team member to shift focus away from completing work in the queue risks an adverse impact on the team’s velocity.

As a leader, a scrum master has to recognize any constraints the context places on the scope of their responsibilities. In meet-ups and conferences I’ve heard people say the scrum master “should be the team spiritual leader,” the team “therapist,” or “a shaman,” and capable of administering to the team’s every emotional need. I take a more pragmatic approach and believe a scrum master should be able to recognize when someone on their team is in need of a qualified professional and, if necessary, assist them in finding the help they need. (HR departments exists, in part, to handle these situations.) This is still good leadership. It’s important to recognize the limits of one’s own capabilities and qualifications. Scrum master as therapist is a quagmire, to be sure, and I’ve yet to meet one with the boots to handle it.

Servant leader aside, the “master” in “scrum master” is the source of no end of grief. It’s partly to blame for the tendency in people to ascribe super powers to the scrum master role, such as those described above. In addition, the “master” part of the title implies “boss” or “manager.” It is a common occurrence for team members to address their stand-up conversation to me – as scrum master – rather than the team. I have to interrupt and specifically direct the individual to speak to the team. I’ve had team members share that they assumed I was going to take what was communicated in the stand-up and report directly to the product owner or the department head or even higher in the organization. “How come you’re not taking notes?”, they ask.”The stand-up is for you, not for me. Take your own notes, if you wish,” I reply. (I do take notes, but only for the purpose of following-up on certain issues or capturing action items for myself – things I need to do to remove impediments that are outside the team’s ability to resolve, for example.)

All the downside of what I’ve describe so far can be amplified by the Dunning–Kruger afflicted scrum master. Amplified again if they are “certified.” To paraphrase from the hacker culture on how you know you’re a hacker (in the classical sense), you aren’t a scrum master until someone else calls you a scrum master. There is always more to learn and apply. A scrum master who remains attentive to that fact will naturally develop quality servant and strong leadership skills.

Finally, the scrum master role is often a thankless job. When new to a team and working to establish trust and credibility the scrum master will need to build respect but often won’t be liked during the process. Shifting individuals out of their comfort zone, changing bad habits, or negotiating 21st Century sensitivities is no easy task even when people like and respect you. So a quality scrum master will work to establish respect first and let the liking follow in due course.

Having succeed at this the scrum master’s business will likely shift to the background. So much so some may wonder why they’re taking up space on the team. Working to establish and maintain this level of performance with a team while remaining in the background is at the heart of the servant part of servant/leader.


Photo by Eden Constantino on Unsplash

Behind the Curtain: The Product Owner Role

When someone owns something they tend to keep a closer watch on where that something is and whether or not it’s in good working order. Owners are more sensitive to actions that may adversely affect the value of their investment. It’s the car you own vs the car you rent. This holds true for products, projects, and teams. For this reason the title of “product owner” is well suited to the responsibilities assigned to the role. The explicit call-out to ownership carries a lot of goodness related to responsibility, leadership, and action.

Having been a product owner and having coached product owners, I have a deep respect for anyone who takes on the challenges associated with this role. In my view, it’s the most difficult position to fill on an Agile team. For starters, there are all the things a product owner is responsible for as described in any decent book on scrum: setting the product vision and road map, ordering the product backlog, creating epics and story cards, defining acceptance criteria, etc. What’s often missing from the standard set of bullet items is the “how” for doing them well. Newly minted product owners are usually left to their own devices for figuring this out. And unfortunately, in this short post I won’t be offering any how-to guidance for developing any of the skills generally recognized to be part of the product owner role.

What I’d most like to achieve in this post is calling out several of the key skills associated with quality product ownership that are usually omitted from the books and trainings – the beyond-the-basics items that any product owner will want to include in their continuous learning journey with Agile. In no particular order…

  • Product owners must be superb negotiators when working with stakeholders and team members. The techniques used for each group are different so it’s important to understand the motivations that drive them. I’ve found Jim Camp’s “Start with No” and Chris Voss’ “Never Split the Difference” to be particularly helpful in this regard.
  • One of the four values stated in the Agile Manifesto is “Responding to change over following a plan.” Unfortunately, this is often construed to mean any change at any time is valuable. This Agile value isn’t a directive for maximum entropy and chaos. Product owners must remain vigilant to scope changes. And the boundaries for scope are defined by the decisions product owners make. So product owners must be decisive and committed to the decisions, agreements, and promises that have been made with stakeholders and the team.
  • Product owners need to have a good sense for when experimentation may be needed to sort out any complex or risky features in the project – creating spikes or proof-of-concept work early enough in the project so as to avoid any costly pivots later in the project.
  • Even with experimentation, making the call to pivot will require a product owner’s clear understanding of past events and any path forward that offers the greatest chance for success. As the sage says, predictions are difficult to make, particularly about the future. The expectation isn’t for clairvoyance, rather for the ability to pay close attention to what the (non-vanity) data are telling them.
  • Understanding how to work through failures and dealing with “The Dip,” as Seth Godin calls it, are also important skills for a product owner. The team and the stakeholders are going to look to the product owner’s leadership to demonstrate confidence that they are on the right track.

More than other roles on an Agile team, the product owner must be a truly well-rounded and experienced individual. Paradoxically, it is a role that is both constrained by the highly visible nature of the position and dynamic due to the skill set required to maximize the chances for project success.


Image by Free-Photos from Pixabay

Book Review: Tribes – We Need You to Lead Us

Tribes: We Need You to Lead Us by Seth Godin

 

Reading Seth Godin is a lot like going for an enjoyable mountain hike and finding a handful of small gold nuggets along the way. No heavy effort to dig for miles in order to find the deeper, richer vein of wealth. Just enough interesting shiny bits of useful wisdom scattered along the trail to invite the reader to explore further.

“Tribes” isn’t so much about the composition and character of tribes, per se, but more a call to serve as a leader for tribes yet to be formed. “Human beings can’t help it,” he writes. “[W]e need to belong. One of the most powerful of our survival mechanisms is to be part of a tribe, to contribute to (and take from) a group of like-minded people.” But left to their own devices, tribes dissolve or evolve into something directionless, perhaps unruly. What they need to persist is some form of leadership to set the rules and customs.

Speaking to aspiring or future leaders, Godin presents what he views as the biggest blocker to people stepping up and fulfilling leadership roles.

The only shortcut in this book, the only technique or how-to or inside info is this: the levers are here. The proof is here. The power is here. The only thing holding you back is your own fear….Dr. Laurence Peter is famous for proposing that “in a hierarchy every employee tends to rise to his level of incompetence.” In other words, when you do a great job, you get promoted. And that process repeats itself until finally you end up in a job you can’t handle….I’d like to paraphrase the Peter Principle. I think what actually happens is that “in every organization everyone rises to the level at which they become paralyzed with fear.”

And the source of that fear is rooted in misaligned beliefs about criticism and failure.

As with almost everything I read, my eye is searching for ways the information I’m acquiring can be applied to improving team performance. The notion of tribes appeals to me from a social community perspective. I firmly believe there are deep psychological patterns in the human mind that unconsciously gravitate toward the idea of belonging to a tribal structure. And yet, there are limitations to that structure in the 21st Century business world. As Godin notes, “[I]n addition to the messages that go from the marketer or the leader to the tribe, there are the messages that go sideways, from member to member, and back to the leader as well.” What about communication between tribes? How might we avoid the formation of silos and corporate turf battles? These are questions for which I’ll need to continue searching as they are not addressed in “Tribes.”

Written more than ten years ago, there are elements of the book that have not aged well. For example, writing at a time which many today are considering the Golden Age of the Internet, Godin observes “In the nonsquishy tribal world of this decade, Twitter and blogs and online videos and countless other techniques contribute to an entirely new dimension of what it means to be part of a tribe.” And later, while writing about how easy it is for tribes to connect, communicate, and spread messages: “The tribe thrives; it delivers value and it spreads. Internet folks call this viral activity, or a virtuous cycle.” More commonly today the technology noted by Godin – particularly Facebook and Twitter – have resulted in the formation of more mobs than tribes and the cycles are 2021 are more vicious than they are virtuous.

However, I don’t think Godin was casting his gaze into the future through entirely rose colored glasses. He notes that crowds (and their blunt force object version: mobs) and tribes are “[t]wo different things: A crowd is a tribe without a leader. A crowd is a tribe without communication. Most organizations spend their time marketing to the crowd. Smart organizations assemble the tribe. Crowds are interesting, and they can create all sorts of worthwhile artifacts and market effects. But tribes are longer lasting and more effective.”

Several of the gold nuggets I picked up pointed to the importance of systemic thinking and analysis:

Leaders don’t care very much for organizational structure or the official blessing of whatever factory they work for. They use passion and ideas to lead people, as opposed to using threats and bureaucracy to manage them. Leaders must become aware of how the organization works, because this awareness allows them to change it.

Working in an environment that’s static is no fun. Even worse, working for an organization that is busy fighting off change is horrible.

When you fall in love with the system, you lose the ability to grow.

The status quo is persistent and resistant.

The last quote is a clear reflection of Shalloway’s Corollary. The status quo is the system pushing back.

I’ll round out this review with a few quotes that apply to a life in general.

Leaders have followers. Managers have employees.

If you need the alternative to be better than the status quo from the very start, you’ll never begin.

Life’s too short to fight the forces of change. Life’s too short to hate what you do all day. Life’s way too short to make mediocre stuff.

Defending mediocrity is exhausting.

Instead of wondering when your next vacation is, maybe you ought to set up a life you don’t need to escape from.

People don’t believe what you tell them. They rarely believe what you show them. They often believe what their friends tell them. They always believe what they tell themselves. What leaders do: they give people stories they can tell themselves. Stories about the future and about change.

Baseballs and Hockey Pucks

“Keep your eye on the ball!” I was always coached when learning how to play baseball. Seemed like reasonable advice while standing at the plate, facing down the pitcher for the opposing team. Certainly wouldn’t want to be daydreaming or casting my gaze to the horizon. It didn’t seem to help, though. I excelled at striking out.

Later…much later…I came across Wayne Gretzky’s quote: “Skate to where the puck is going, not where it has been.” I wonder if I had learned to figure out where the baseball was going to be and made sure my bat was there to meet it if I might have spent more time on bases. Keeping my eye on the ball didn’t tell me much about when to start my swing.

No regrets. I still love the game (as it was, not as it currently is.)

I think of this Gretzky quote when I watch product owners struggle with organizing their backlog. (I also think how tragic it is that the business world has beat this quote into an intolerable pulpy platitude.)

Ask a product owner what their team is working on today, they should be able to give a succinct answer. Ask them what their team is going to be working on in three months and watch the clock. The longer they can go on about what their team is going to be working on, the healthier their backlog is likely to be. Struggling product owners scramble to keep their teams busy sprint-to-sprint. Good product owners can see where their teams are going to be in several months. Great product owners see to the end of the game.


Photo by Chris Chow on Unsplash