Openness, Grapevines, and Strangleholds

If you truly value openness on your Agile teams, you must untangle them from the grapevine.

Openness is one of the core scrum values. As stated on Scrum.org:

“The scrum team and it’s stakeholders agree to be open about all the work and the challenges with performing the work.”

This is a very broad statement, encompassing not only openness around work products and processes, but also each individual’s responsibility for ensuring that any challenges related to overall team performance are identified, acknowledged, and resolved. In my experience, issues with openness related to work products or the processes that impact them are relatively straightforward to recognize and resolve. If a key tool, for example, is mis-configured or ill-suited to what the team needs to accomplish than the need to focus on issues with the tool should be obvious. If there is an information hoarder on the team preventing the free flow of information, this will reveal itself within a few sprints after a string of unknown dependencies or misaligned deliverables have had a negative impact on the team’s performance. Similarly, if a team member is struggling with a particular story card and for whatever reason lacks the initiative to ask for help, this will reveal itself in short order.

Satisfying the need for openness around individual and team performance, however, is a much more difficult behavior to measure. Everyone – and by “everyone” I mean everyone – is by nature very sensitive to being called out as having come up short in any way. Maybe it’s a surprise to them. Maybe it isn’t. But it’s always a hot button. As much as we’d like to avoiding treading across this terrain, it’s precisely this hypersensitivity that points to where we need to go to make the most effective changes that impact team performance.

At the top of my list of things to constantly scan for at the team level are the degrees of separation (space and time) between a problem and the people who are part of the problem. Variously referred to as “the grapevine”, back channeling, or triangulation, it can be one of the most corrosive behaviors to a team’s trust and their ability to collaborate effectively. From his research over the past 30 years, Joseph Grenny [1] has observed “that you can largely predict the health of an organization by measuring the average lag time between identifying and discussing problems.” I’ve found this to be true. Triangulation and back-channeling adds significantly to the lag time.

To illustrate the problem and a possible solution: I was a newly hired scrum master responsible for two teams, about 15 people in total. At the end of my first week I was approached by one of the other scrum masters in the company. “Greg,” they said in a whisper, “You’ve triggered someone’s PTSD by using a bad word.” [2]

Not an easy thing to learn, having been on the job for less than a week. Double so because I couldn’t for the life of me think of what I could have said that would have “triggered” a PTSD response. The only people I knew who had been diagnosed with PTSD were several Vietnam veterans and a cop – men who had been through violent and life-or-death circumstances. This set me back on my heels but I did manage to ask the scrum master to please ask this individual to reach out to me so I could speak with them one-to-one and apologize. At the very least, suggest they contact HR as a PTSD response triggered by a word is a sign that someone needs help beyond what any one of us can provide. My colleague’s responses was “I’ll pass that on to the person who told me about this.”

“Hold up a minute. Your knowledge of this issue is second hand?”, I asked.

Indeed it was. Someone told someone who told the scrum master who then told me. Knowing this, I retracted my request for the scrum master to pass along my request. The problem here was the grapevine and a different tack was needed. I coached the scrum master to 1) never bring something like this to me again, 2) inform the person who told you this tale that you will not be passing anything like this along to me in the future, and 3) to coach that person to do the same to the person who told them. The person for whom this was an issue should either come to me directly or to my manager. I then coached my manager and my product owners that if anyone were to approach them with a complaint like this to listen carefully, acknowledge that you heard them, and to also encourage them to speak directly with me.

This should be the strategy for anyone with complaints that do not rise to the level of needing HR intervention. The goal of this approach is to develop behaviors around personal complaints such that everyone on the team knows they have a third person to talk to and that the issue isn’t going to be resolved unless they talked directly to the person with whom they have an issue. It’s a good strategy for cutting the grapevines and short circuiting triangulation (or in my case the quadrangulation.) To seal the strategy, I gave a blanket apology to each of my teams the following Monday and let them know what I requested of my manager and product owners.

The objective was to establish a practice of resolving issues like this at the team level. It’s highly unlikely (and in my case 100% certain) that anyone new to a job would have prior knowledge of sensitive words and purposely use language that’s upsetting to their new co-workers. The presupposition of malice or an assumption that a new hire should know such things suggested a number of systemic issues with the teams, something later revealed to be accurate. It wouldn’t be a stretch to say that in this organization the grapevine supplanted instant messaging and email as the primary communication channel. With the cooperation of my manager and product owners, several sizable branches to the grapevine had been cut away. Indeed, there was a marked increase in the teams attention during daily scrums and the retrospectives became more animated and productive in the weeks that followed.

Each situation is unique, but the intervention pattern is more broadly applicable: Reduce the number of node hops and associated lag time between the people directly involved with any issues around openness. This in and of itself may not resolve the issues. It didn’t in the example described above. But it does significantly reduce the barriers to applying subsequent techniques for working through the issues to a successful resolution. Removing the grapevine changes the conversation.

References

[1] Grenny, J. (2016, August 19). How to Make Feedback Feel Normal. Harvard Business Review, Retrieved from https://hbr.org/2016/08/how-to-make-feedback-feel-normal

[2] The “bad” word was “refinement.” The team had been using the word “grooming” to refer to backlog refinement and I had suggested we use the more generally accepted word. Apparently, a previous scrum master for the team had been, shall we say, overly zealous in pressing this same recommendation to a degree that it became a traumatic experience for someone on the one of the teams. I later learned this event was grossly exaggerated. The developer had a well known reputation for claiming psychological trauma to cower others into backing down and would laugh and brag about using this club. The strategy described in this article proved effective at preventing this type of behavior.


Photo by Ben Neale on Unsplash

Autopilot Agile

There is a story about a bunch of corporate employees that have been working together for so long they’ve cataloged and numbered all the jokes they’ve told (and re-told) over the years. Eventually, no one need actually tell the joke. Someone simply yells out something like “Number Nine!” and everyone laughs in reply.

As Agile methodologies and practices become ubiquitous in the business world and jump more and more functional domain gaps, I’m seeing this type of cataloging and rote behavior emerge. Frameworks become reinforced structures. Practices become policies. “Daily Scrum” becomes code for “status meeting.” “Sprint Review” becomes code for “bigger status meeting.” Eventually, everyone is going through the motions and all that was Agile has drained from the project.

When you see this happening on any of your teams, start introducing small bits of randomness and pattern interruptions. In fact, do this anyway as a preventative measure.

  • One day a week, instead of the usual daily scrum drill (Yesterday. Today. In the way.), have each team member answer the question “Why are you working on what today?” Or have each team member talk about what someone else on the team is working on.
  • Deliberately change the order in which team members “have the mic” during stand-ups.
  • Hold a sprint prospective. What are the specific things the team will be doing to further their success? What blockers or impediments can they foresee in the next sprint? Who will be dependent on what work to be completed by when?
  • Set aside story points or time estimates for several sprints. I guarantee the world won’t end. (And if it does, well, we’ve got bigger problems than my failed guarantee.) How did that impact performance? What was the impact on morale?
  • During a backlog refinement session, run the larger story cards through the 5 Whys. Begin with “Why are we doing this work?” This invariably ends up in smaller cards and additions to the backlog.

There’s no end to the small changes that can be introduced on the spur of the moment to shake things up just a bit without upsetting things a lot. The goal is to keep people in a mindset of fluidity, adaptability, and recalibration to the goal.

It’s more than a little ironic and somewhat funny to see autopilot-type behavior emerge in the name of Agile. But if you really want funny…Number Seven!


Image by Ronald Plett from Pixabay

What does Agile documentation look like?

Reading through Dusty Phillips’ second edition of “Python 3 Object-oriented Programming,” this quote caught my attention:

Further, the most important person you will ever have to communicate with is yourself. We all think we can remember the design decisions we’ve made, but there will always be the Why did I do that? moments hiding in our future. If we keep the scraps of papers we did our initial diagramming on when we started a design, we’ll eventually find them a useful reference.

That strikes me as a good benchmark for acceptable documentation in Agile. Whether coder, UI/UX designer, data architect, or whatever, if you are keeping a good record of what you decided and why, you’ll probably be able to recreate the rationale for why things got to be the way they are for anybody who needs to know. Especially if that anybody is you. And there is a good chance that someone following in your footsteps will be able to pick up the same rationale even in your absence. All this without putting an unnecessary burden on project progress for the sake of detailed documentation.

Of course, what qualifies as “good” is the tricky part. A suggested threshold would be to specify only as much information as makes sense or for what is known given the current situation. Documentation should be subject to iterative practices just as much as code.


Image by Pexels from Pixabay

Broken Windows and Broken Scrum

Recently, I was in a conversation with a scrum master that was of the opinion that correcting teams on all the small details of practicing scrum was the best way to develop them into a high performing team. They compared this to the Broken Windows Theory of crime reduction. For example, if someone is a minute late to the daily scrum, call them out. Or the daily scrum must not deviate from the “Yesterday, today, and in the way” script regardless how well the team is communicating.

I can see the merits of developing discipline. However, without explanation or coaching that includes the rational for practicing scrum in such a way, there is a real possibility for negative unintended consequences.

  • The broken windows theory was meant to be applied in situations where the goal was to reduce crime. To apply this approach to scrum practices is to imply that any deviation from the scrum framework is criminal.
  • Similar to how the broken windows theory resulted in the emergence of “zero tolerance” laws, applying such an approach to scrum teams and strictly enforcing how they may or may not follow the scrum framework will result in a lot of command-and-control zero tolerance practices. The guides will become rules and, in turn, inflexible laws.

The approach I’ve found to be more effective is to hunt down the root causes to issues, for which being late to daily scrums or poor communication are symptoms. It’s more like being a big game hunger. Seek out the root of the problem, solve that problem, and many of the lesser issues will resolve themselves.


Photo by Tobias Tullius on Unsplash

The Team Hero

Very good article from Margaret Heffernan, “It’s Finally Time to Retire ‘Good to Great’ From the Leadership Canon.” This quote stands out:

Collins insists that great companies get the right people on the bus and the wrong ones off. But how do you identify them proactively? Collins is thin on detail. Their values matter more than skills, but how can you tell? They’re unafraid to face brutal truths — but we all avoid unpleasant realities, so how do serious leaders foster candor? There’s evidence that what distinguishes high-achieving teams is the quality of connectedness between people rather than the individuals themselves, but such systemic thinking is absent from Good to Great, which inhabits a strictly linear universe. You either are Level 5 or somewhere lower on the ladder. The people on the bus are right or wrong. The toughest parts of leadership are, apparently, easy.

This reminds me of the the 1998 Sydney to Hobart yacht race as described by Dennis Perkins and Jillian Murphy in their book “Into the Storm.” Larry Ellison’s purchased professional crew on his yacht, “Sayonara,” put in a mighty fine performance. But the race was won by the scrappy and tight knit little crew on the “Midnight Rambler.”

If the quality of connectedness between people is a distinguishing characteristic of high-achieving teams, what does that say about the team “hero” – that individual who insists on outperforming everyone else on the team? In my experience, the team hero’s contribution to the team effort is much more likely to be disruptive than productive. I’ve observed the following qualities:

  • They manufacture crisis that only they can solve.
  • They work outside the team, pleasing others – particularly people with status – while progress on work assigned to the team suffers.
  • They hoard information and work assignments.
  • Show little interest in mentoring or helping others on the team succeed.
  • Are acutely sensitive to criticism and dismissive of feedback.
  • Display many of the attributes of a fixed mindset.

Managing a team with a hero on it usually means you spend most of your time managing the hero or scrambling to mitigate the adverse effects of their behavior. The team suffers and second order effects soon follow. I’d much rather manage a team of solid performers who understand how to work together.

 

Photo by Javier García on Unsplash

Responding to change over following a plan

Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.

Agile Manifesto Principle #2

Following from the Agile Manifesto value that is the title of this post, Principle #2 may be the most mis-interpreted and misunderstood principle among the set of twelve. Teams frequently behave as if this principle was prefaced with the word “always.”

Constantly shifting requirements leads to a frustrating and unsatisfying environment in which to work. It feeds burn-out and erodes morale. The satisfaction of a job well done depends on the opportunity to actually finish the job, no matter how small. Consider the effects on a finish carpenter who has just spent several days installing and trimming a full set of kitchen cabinets when the homeowner declares they want to change the kitchen design such that all those new cabinets will need to be ripped out and work begun on a new design. Or a film editor who has just worked 21 days straight to pare down an hour’s worth of video to fit into 7 minutes only to learn the scene has to be re-shot from scratch in order to match a change in the story line.

Of course, the second principle does not state we should “always welcome changing requirements.” Nor does anyone I know claim that it does. But that doesn’t stop people from behaving as if it did. The rationale offered for agreeing to change requests from the stakeholders may be “We’re an agile shop and agile welcomes changing requirements” when, in fact, the change was agreed to because the product owner didn’t challenge the value of the change or make clear the consequences to the stakeholders. Or the original design was, and remains, needlessly ambiguous. Or the stakeholders have changed without renegotiating the contract or working agreements. Or any number of reasons that are conveniently masked with “welcoming changing requirements.” At some point, welcoming changing requirements is about as attractive as welcoming a rabid dog into the house. This won’t end well.

So, what kind of change is the Agile Manifesto referring to? There are several key scenarios that embody the need for flexibility around requirements.

  • The change that results from periods of deliberate design, such as during design sprints.
  • The change that is driven by the lessons learned from exploration and prototyping. If it is understood that the work being “completed” is for the purposes of testing a hypothesis and the expectation is that the work will most likely be thrown away, there can still be a great deal of satisfaction derived from the effort as the actual deliverable wasn’t working software, but the lessons from the experiment (usually in the form of a wireframe or prototype.)

So what is it that locks out the option for additional change? It’s a simple event, really. A decision is made.

Each of these scenarios where adapting to lessons and discovery is essential nonetheless end in a decision, a leverage point from which progress can be made toward a final deliverable. Each of these decisions can themselves form the basis of a series of experiments which, depending on the eventual outcome, may change.  Often, a single decision point may look good but when several decisions are evaluated together they may suggest a new direction and therefore impact the requirements. If the cumulative insight from a series of decisions results in the need to change direction, that shift is usually more substantial and on the scale of a project plan pivot rather than a simple response to a single change in a single requirement. The need to pivot cannot reliably be revealed if the underlying decisions do not coalesce into some sort of stable understanding of the emerging design.

Changing requirements cannot go on indefinitely or a final product will never be delivered. Accepting change for the sake of change is what gets teams into trouble.

Much like the forces on evolution, there will always be some external force that seeks to change the project requirements so that the delivered product can be stronger, faster, better, taller, smarter, etc.  This must be countered by clear definitions of “minimum viable” and “good enough for now” relative to what the customer is expecting.

In addition, product owners would serve their teams well by vigorously challenging any proposed changes to the requirements.

  • What is the source of the change?
  • Is it random change or triggered by some agent that does not announce its arrival ahead of time?
  • Was the change in requirements a surprise? If so, why was it a surprise?
  • Will this (or something like it) happen again? With what frequency? At what probability?

Photo by juan pablo rodriguez on Unsplash

The Path to Mastery: Begin with the Fundamentals

Somewhere along the path of studying Aikido for 25  years I found a useful perspective on the art that applies to a lot of skills in life.  Aikido is easy to understand. It’s a way of living that leaves behind it a trail of techniques. What’s hard is overcoming the unending stream of little frustrations and often self-imposed limitations. What’s hard is learning how to make getting up part of falling down. What’s hard is healing after getting hurt. What’s hard is learning the importance of recognizing when a white belt is more of a master than you are. In short, what’s hard is mastering the art.

The same can be said about practicing Agile. Agile is easy to understand. It is four fundamental values and twelve principles. The rest is just a trail of techniques and supporting tools – rapid application development, XP, scrum, Kanban, Lean, SAFe, TDD, BDD, stories, sprints, stand-ups – all just variations from a very simple foundation and adapted to meet the prevailing circumstances. Learning how to apply the best technique for a given situation is learned by walking the path toward mastery – working through the endless stream of frustrations and limitations, learning how to make failing part of succeeding, recognizing when you’re not the smartest person in the room, and learning how to heal after getting hurt.

If an Aikidoka is attempting to apply a particular technique to an opponent  and it isn’t working, their choices are to change how they’re performing the technique, change the technique, or invent a new technique based on the fundamentals. Expecting the world to adapt to how you think it should go is a fool’s path. Opponents in life – whether real people, ideas, or situations – are notoriously uncompromising in this regard.  The laws of physics, as they say, don’t much care about what’s going on inside your skull. They stubbornly refuse to accommodate your beliefs about how things “should” go.

The same applies to Agile practices. If something doesn’t seem to be working, it’s time to step in front of the Agile mirror and ask yourself a few questions. What is it about the fundamentals you’re not paying attention to? Which of the values are out of balance? What technique is being misapplied? What different technique will better serve? If your team or organization needs to practice Lean ScrumXPban SAFe-ly than do that. Be bold in your quest to find what works best for your team. The hue and cry you hear won’t be from the gods, only those who think they are – mere mortals more intent on ossifying Agile as policy, preserving their status, or preventing the perceived corruption of their legacy.

But I’m getting ahead of things. Before you can competently discern which practices a situation needs and how to best structure them you must know the fundamentals.

There are no shortcuts.

In this series of posts I hope to open a dialog about mastering Agile practices. We’ll begin by studying several maps that have been created over time that describe the path toward mastery, discuss the benefits and shortcomings of each of these maps, and explore the reasons why many people have a difficult time following these maps. From there we’ll move into the fundamentals of Agile practices and see how a solid understanding of these fundamentals can be used to respond to a wide variety of situations and contexts. Along the way we’ll discover how to develop an Agile mindset.

Photo by simon sun on Unsplash

Taking Work to the Team

Every once and a while I have to work with someone who has the idea that productivity would increase if we had teams that floated from project to project. Worse, float individuals from project to project based on the particular skills they have. “It’s the professional services model,” they tell me. If you happen to work for a professional services firm, this would make good sense. Looking at the evolution of productivity since the industrial revolution reveals the professional services model as a niche approach to managing productive workflows.

A hundred and fifty years ago, if you wanted a horse drawn wagon and didn’t have the skill to build one yourself, you might go to “Smith and Sons Wagon Makers” and work out a deal. You brought the work to the team. In this case, the team is Mr. Smith and his sons. They’d take your order, put it in the queue, and when your order came up they would build your wagon from scratch.

Just over a hundred years ago, Henry Ford figured out a more efficient way to bring work to the team with the invention of the “assembly line.” This brought better quality, product consistency, lower costs, and faster delivery of the successor to the horse drawn wagon. The assembly line also brought greater specialization to the team members.

A modern day example of bringing the work to a team who’s members are extremely specialized is the Formula One pit crew. Twenty plus team members who’s sole objective is to service a race car in the shortest amount of time. The example video shows an amazing blend of team coordination and years of technical evolution to enable the pit crew to complete the task in under two seconds. It’s the end result of a century of scientific management, also known as “Taylorism.”

However, the assembly line and scientific management breaks down when working to improve the productivity of knowledge workers. It doesn’t even serve as a particularly good metaphor for knowledge work. What does “bringing work to the team” look like when searching for ways to improve software development and delivery, for example? Software developers and quality engineers don’t sit at an assembly line work station. Knowledge work, in particular software development, is also creative work. There is only one way a wheel can be attached to an axle if an automobile is going to function properly. But there can be many ways to create software that functions in a particular way. Among software developers and engineers, they may be able to tell which approach is better or more efficient or more robust. Assuming good QA, the the end user probably won’t. A mis-aligned wheel on a car is readily apparent to anyone who knows how to drive.

What is common when taking work to a team is a shared understanding of the process behind the workflow and the need for well-defined coordination among team members. Who does what when and why. The race car pit crew demonstrates this in under two seconds.

There is, in my view, a metaphor that does serve the team of knowledge workers well. That’s the jazz ensemble. Here is a team of highly specialized individuals who have come together to combine their understanding of music theory and individual creativity to produce some amazing music. But this doesn’t happen by accident and it isn’t something that can be scheduled. The musicians have to have complete trust in each other’s abilities and this takes time to establish. The “sound” each ensemble creates is dependent on who’s playing. The talent isn’t interchangeable with other ensembles. Even when it goes well, when an ensemble member is replaced there is a period of time where the trust needs to be re-established. And it’s likely that changing the member composition is going to change the ensemble’s “sound.” But it will still be jazz.

Keeping knowledge work teams together and taking work to the team allows for a number of desirable characteristics to emerge that are critical to high performing teams.

  • Clear and persistent understanding of each other’s capabilities
  • Shared understanding of the work involved
  • Trust in each other’s commitment to the goal

The speed at which a knowledge work team gels into a high performance team is significantly influenced by the tactics employed by management.

  • Be clear with the team what process they are expected to follow (e.g. Scrum, SAFe, etc.) and where in the process they have full creative discretion. A jazz ensemble has full discretion over what they play. But if you’ve hired them, they also need to know where and when they’re expected to play. That’s the deal.
  • Minimize changes to the team’s composition. Like musicians, talent between teams isn’t seamlessly interchangeable. Replacing a team member will require a period of time for trust among team members to be re-established and until it is, performance will decline. How long this takes is dependent on how disruptive the change to the team’s composition has been. Did they lose a leader or a junior member? Did they lose a highly specialized set of skills and product knowledge or something more general and common?
  • The team is best evaluated by the quality of their output, regardless of how they put it all together. Resist the urge to pull out the scientific management stop watch and magnifying glass.

Parkinson’s Law of Perfection

C. Northcote Parkinson is best known for, not surprisingly, Parkinson’s Law:

Work expands so as to fill the time available for its completion.

But there are many more gems in “Parkinson’s Law and Other Studies in Administration.” The value of re-reading classics is that what was missed on a prior read becomes apparent given the accumulation of a little more experience and the current context. On a re-read this past week, I discovered this:

It is now  known  that  a  perfection  of  planned  layout  is  achieved  only  by institutions  on  the   point  of  collapse.  This   apparently  paradoxical conclusion is based upon a wealth of archaeological and historical research, with the  more esoteric details of  which we need not concern  ourselves. In general  principle, however, the method pursued has been to  select and date the buildings  which  appear to have been perfectly  designed for  their purpose. A study and comparison of these has tended to prove that perfection of planning is a symptom of decay. During a  period of exciting discovery or progress there is  no time  to  plan the perfect headquarters.  The time for that comes  later, when all the important work has been done. Perfection, we know, is finality; and finality is death.

Several years back my focus for the better part of a year was on mapping out software design processes for a group of largely non-technical instructional designers. If managing software developers is akin to herding cats, finding a way to shepherd non-technical creative types such as instructional designers (particularly old school designers) can be likened to herding a flock of canaries – all over the place in three dimensions.

What made this effort successful was framing the design process as a set of guidelines that were easy to track and monitor. The design standards and common practices, for example, consisted of five bullet points. Building just enough fence to keep everyone in the same area while limiting free range behaviors to specific places was important. These were far from perfect, but they allowed for the dynamic vitality suggested by Parkinson. If the design standards and common practices document ever grew past something that could fit on one page, it would suggest the company was moving toward over specialization and providing services to a narrow slice of the potential client pie. In the rapidly changing world of adult education, this level of perfection would most certainly suggest decay and risk collapse as client needs change.

Image by EWAR from Pixabay

Drive for Teams

I recently re-read Daniel Pink’s book, “Drive: The Surprising Truth About What Motivates Us.” I read it when it was first published and I was still managing technical teams. Super brief summary: The central idea of the book is that people are mostly driven by intrinsic motivation based on three aspects:

  • Autonomy — The desire to be self directed.
  • Mastery — The urge to improve skills.
  • Purpose — The desire to engage with work that has meaning and purpose.

I find this holds true for individuals. However, when applied to teams optimizing for these three aspects can be problematic. If an individual on a team seeks to maximize autonomy, they are likely to come into conflict with the objectives of the team. For example, a software team that is tasked with developing a component that is expected to interact with several other components developed by other teams. If a single developer, in the interests of maximizing their individual autonomy, has decided to develop the component according to standards, design principles, and tools that are different from those of teammates and other teams (essentially, a local optimization,) then the result is likely to be sub-optimal overall.

Some individual autonomy must necessarily be sacrificed in the interests of effective collaboration. It’s possible, even desirable, that individual pursuits of mastery and purpose can be maintained. However, it may be necessary for an individual to focus on mundane tasks and the objectives of the team for periods of time. Finding ways to maintain a healthy balance between the intrinsic motivators and the purpose of the team is no small task and, when found, requires constant attention to maintain.

Perhaps it is possible to attach the team’s or organization’s purpose to the interests of the individual. Or sort for hiring people who have a personal purpose that is in-line with the organization’s purpose.

Image by M. Maggs from Pixabay