Blog

Simplicity in Agile Teams

We’ve been at agile for a while now, long enough to know that coaching high performance is not so easy.

We’ve accrued a great deal of experience and a number of theories and methods have been offered up.  The question is, are there any simplicities in all this that we’ve missed, or relative importances that would help us better order and leverage all this data?

I think so.

Here’s what I have observed:

Purpose is king.  Really the broader concept of purpose driven by out of inspiration.  Inspired purpose.

Inspiration and purpose create alignment.  They are the heart and connecting thread of culture.  With gobs of inspired purpose other factors like presence and collaboration, even trust, can surface.  Teams are moved to rise above dysfunction and to discipline themselves.  Conversely, in the presence of a weak purpose you struggle mightily to establish any of these other necessary behaviors.

Another bedrock is communication.  I know; this is a bit like saying your body needs food to keep going.  Not all that enlightening.  But zeroing in and anchoring on communication is quite helpful. As Westrum pointed out, it’s information flow that signals the culture.  Communication – good or bad, present or not – is both the leading indicator and step number one in remedying most of the situations we confront.  We can break it down into any number of facets – into presence, listening, empathy – but simply knowing to start by looking at communication has power.

The last one is leadership. Probably cooking is the only subject that has more books written on it, but we want to focus on just a few elements.  First is creating safety for the team, simply by standing up for them, having their back.  The second is being straight with the team; honesty.  These first two require courage.  These behaviors are also part of “being the change” in Gandhi’s words, and of leaders going first.

So what’s the point?  It’s that these are the first things you need to attend to in establishing a team, and the first things you should look to when examining a team’s functioning.

For example, Mike Cohn suggests getting a team started by having them begin producing together quickly.  Then think about other team building.  This is actually brilliant.  On a very immediate basis you’re establishing communication and some alignment to purpose; something you can then build on.

And in remedying problems, even root causes like missing skills for example are evidenced by the person or group slipping out of communication with their work or their environment.  You can easily spot similar examples of fundamental impact of a lack of leadership.

The hypothesis, then, is that when you have these three elements, the rest – things like trust, like positive conflict, empathy, continuous improvement, team self-awareness and management – can follow.  Without them, you will struggle to achieve any of them.

Another hypothesis is that they are symbiotic; they reinforce each other.

Communication certainly improves in the presence of strong purpose. But good communication provides a supportive environment for purpose to express itself as well, and for leadership to emerge; leadership that will further nurture the other two.  And so on.

These elements and relationships have power because they are simple.  This is not to suggest throwing all other team building and coaching tools overboard!  Not at all!  But these fundamentals can provide quick reference points leading to the precise problem to be addressed and the best technique to apply.

And, admittedly, the more coaching tools we acquire the more susceptible we can sometimes become to missing the obvious.  Like when the help desk asks us, “Is the computer plugged in?”

Starting with these three bedrocks can help us to face and address some of the really hard problems, the elephants in the room – the lack of real communication, the lack of courageous leadership, the lack of purpose.

With these three fundamentals solidly in place, you will have a team.

But when it comes to a high performing software development / digital services team, there’s another key element: tools. The team needs DevOps (which is more than tools; effective implementation of the DevOps principles and practices depends on the three elements we’ve discussed, so we focus here on tools as an additional ingredient) .  They may hang together and be inspired, but if they’re blocked from fast learning cycles and experimentation, encumbered by the technical environment, they will be constrained from ascending.

So that’s the picture

Get those three fundamentals in, support them with tools, and all the other approaches suddenly can be applied to result.

Some references:

  • The core values of both Scrum and XP, both of which include courage
  • Gene Kim presentation Meet Gene Kim (preview of The Unicorn Project) DC Scrum Users Group, April 24, 2019
  • Conversations, Don MacIntyre, on Sutherland’s emphasis on simplicity
  • Patrick Lencioni’s The Five Dysfunctions of a Team
  • Mike Cohn’s Succeeding With Agile
  • Mark Schwartz’s A Seat at the Table
  • Simon Sinek’s Start with Why
  • Sinek’s presentation/video Leaders Eat Last ­– speaking to the need for courage and honesty in leaders
  • Westrum’s A Typology of Organisational Cultures

 

Agile Courage

“It was the best of times, it was the worst of times, it was the age of wisdom, it was the age of foolishness, it was the epoch of believe, it was the epoch of incredulity, it was the season of light, it was the season of darkness, it was the spring of hope, it was the winter of despair.”

This of course is Charles Dickens, speaking as a fellow Agilist about our current times.[1]

It is the best of times as Agile takes root and expands into the business world.

It is the worst of times as our transformations fail.

It is the age of wisdom as Lean and Agile expose a path to productive societies.

It is the age of foolishness as we argue our practices.

It is the epoch of belief as we observe the immense possibility of our principles

It is the epoch of incredulity, as we see these principles twisted with doublespeak to validate status quo

It is the season of light, as DevSecOps opens another mile of our digital journey

It is the season of darkness as discipline and empathy seem to fade in the world around us

It is the spring of hope as we see what well-intentioned people can accomplish with the right mindset

It is the winter of despair as the world to which we are attempting to communicate the promise of Agile is distracted by myriad points of societal stress.

Not often enough do we step back and look at Lean and Agile, their potential impact on the broader society, and what this has to do with us personally and as a group.  Our own belief in the power of a strong vision and purpose suggests that we should do this.  As does Simon Sinek’s Start with Why. We as Agilists need to maintain large reserves of inspiration and purpose as we push out into a world that has worked against its own better nature for more years than is worth dwelling on.  We need this larger view even to sustain our morale and empathy locally and day-to-day, as we help the control-oriented manager in front of us to envision another way of working.

Transformation is hard work.  It is not for nothing that courage is one of the core principles of both Scrum and XP.  I have come to appreciate that more and more.  And that leads to why I have written this blog.

When it comes to Lean and Agile, we are, I believe, entering an age of delivery.  That the going is tough is simply evidence of this fact.  The thing to do is to simply continue communicating, continue selling.  Per Daniel Pink (To Sell is Human) the average person today spends 40 percent of her time selling in one way or another.  As we continue to move into flatter organization structures and self-organization, this percentage will probably grow.

Don’t consider the word “selling” here as a criticism. If we could turn all this selling time into effective communication, we would be incredibly productive.  And that, essentially, is what I think we need to do.  We, individually and as a group need to communicate and collaborate a lot – and well.  We need to be the change (Mahatma Gandhi).  It is a practiced skill.  When things get tough, we need to have the courage stand in and, with empathy, do it some more.

This juncture in our Agile evolution holds risk.  Having innocently found our way into Agile we suddenly are faced with the daunting task of transforming organizations. Being, many of us, analysts or engineers at heart, we are inclined to study this problem, to analyze it.  Certainly, we need to inspect and adapt.  In the face of insufficient courage or awareness though, we are susceptible to over-analysis, a retreat into reassuring complexity.

The results of this misstep could be serious.  It could put us more out of communication with our public, make what we are trying to share more inaccessible to them and to some degree buried beneath additives.  So much of what I see in Lean and Agile is age-old truths about man’s inclinations toward personal and group accomplishment, packaged to unleash these capabilities.

I suggest we focus on action.  There are organizations and populations waiting to benefit from these principles and practices. For every three or four who dismiss these ideas, there are ten or twenty who will celebrate them and thank us for having effectively communicated these concepts.

There is a time to focus on differences and a time for alignment.  Let’s learn, ourselves, to collaborate better.  Let’s, together, move into another level of action and communication.  Let’s embrace the opportunity this moment holds for all of us.  Let’s be the change.

Art Moore, Clear Systems LLC

[1] OK, it’s from A Tale of Two Cities, Charles Dickens

Agile and Who We Are – a memorable moment care of Lyssa Adkins

Lyssa Adkins – We are the Leaders We Have Been Waiting For

(At DCSUG, 20 March, 2018)

https://www.youtube.com/watch?v=s6pPQ3W7npY&feature=youtu.be  (At the end, about 1:03:50 – 1:05:30)

“There are some things that we do now that are not quite getting us there.  So let me just name a couple of them: When we argue about this framework, that framework, the other framework; when we snipe at each other on social media; when we allow our Agile values to be compromised as we grow our Agile businesses and we move toward more practices that could be looked as a little greedy; when we do those things, those are from a bygone era and they are not worthy of us, not anymore.  That’s not who we are.

“When we allow, in organizations, when we allow our efforts to be put toward a product that really doesn’t matter, when we give the organization what it wants, or what it thinks it wants, versus what we know it needs, and when we ignore that little voice inside that’s saying, ‘You don’t have forever to make a difference,’ those things are from a bygone era, and they’re not worthy of us either.  We’re headed toward something else.”

Self-Awareness Demystified

Self-awareness can be hard to pin down. The very term “self-awareness” sounds a little bit intense and mysterious.  As the great philosopher Socrates said, “Know Thyself.” It can seem like self-awareness is a long deep journey and the key to everything.  That may very well be the case, but how does one apply it practically?

It can help a great deal to take an action or purpose-based approach to the question.  In other words, what are we trying to accomplish with self-awareness?  In coaching, we are trying to be sufficiently aware of our own mental state and condition to make sure these don’t get in the way of us being able to be there and observe clearly, and so assist our team or the other person we’re helping.

Self-awareness then is connected to both self-management and presence.  Using the same action-based perspective, we can come up with some useful definitions for these as well.

Presence, we could say, is being there, which includes extroversion and interest.  That’s the goal. Presence enables judgment and proper action.

Self-management would simply be doing what’s needed to address a departure from presence that is identified through self-awareness.

“No reacting” is a very limited view of self-awareness and self-management.  Focusing on what we perceive as our flaws, or some attitude, in order to control them can, if carried to far, be introverting and produce the opposite result we’re trying to achieve. We get so caught up in watching for and holding back certain behaviors that we cease to be present.  The frustration builds and you end up either exhausted or erupting, much to your regret.

That doesn’t mean you shouldn’t self-manage. What it suggests is that if you self-manage toward presence, not just away from what you’re trying to avoid (and so inevitably pulling in on yourself it seems), you will have more success.

When you focus on being more present, you shift your attention to your environment, to your level of interest and how to improve it.  Your attention is on the goal, not the barriers.  Self-awareness helps in spotting those barriers, and being aware of some that might arise, and getting them out of the way of the real purpose.

So the self-awareness we’re talking about is not a “vision quest.”  It’s a tool to improve presence through self-management.

Think of a time you facilitated a great meeting or participated actively in one, or had a great discussion.  How much of your attention was on yourself?  In most cases probably not a lot. Your attention was on the topic, the people.  You were interested.  At the same time, your self-awareness was probably quite high! But it was positively directed, and you were not caught up in mechanics. You perceived clearly your relative position in the group and embraced the dynamics of the situation.

Self-awareness, self-management and presence are interdependent. The more you do or have of one, the more the other two are enhanced as well.  It can be counter-intuitive until you look at it.  For example, if you just made the decision, “I’m going to improve my self-management,” You would see, just by acting on that decision, that your self-awareness comes up.  Similarly, the more present you are in any environment or situation, the more your self-awareness is enhanced.

Think of self-awareness, self-management and presence as three corners of a triangle.  Expand one, and the other two corners expand.  And the reverse is also true.  If you are not at all present to begin with, your self-awareness is inevitably reduced. If you take no responsibility for self-management you will, inevitably become less aware and less present.

This opens the door to a number of simple exercises you can do to improve across these three areas.  For example, if you just got actively interested in the room, in a person, not only is your presence going to increase, but so is your awareness of yourself relative to this person.  Try it sometime.

At least in terms of coaching – and probably more broadly – if we take an action or purpose-based approach to self-awareness, it becomes suddenly demystified.  And when we view it holistically, together with presence and self-management, we have a practical framework for better, and more satisfying, coaching.

Have great conversations.

Self-Management and the Agile Coach

 

The Oxford Dictionary defines “self-management” as, “the taking of responsibility for one’s own behavior and well-being.” It is said to be a key skill for an Agile Coach.  Perhaps in line with the word “management”, we are liable to get so caught up in methodologies and techniques concerned with controlling what we want to avoid doing or preventing what we don’t want to be, that we sometimes lose sight of what it is that we actually want to be and do as a coach.

“Self-management” comes into better focus when we view it from the perspective of what we are attempting to managing toward. When you look at it this way, it becomes apparent that if you’re not clear on that, if you’re not focused on what you want to be as a coach, and do, it’s probable that you’re going to encounter some difficulty in achieving it.  Yet for practical purposes, at least in terms of basic, personal interaction, we can state a lot of what the coach should strive for in a very few words, possibly even in an order of importance:

  • Interest
  • Caring
  • Extroversion

And happily, even though you might say, “Oh I’m an introvert,” or “Truthfully, I could care less,” these are, to a very workable degree, skills that you can practice and improve on.

For instance, you can, just walking in a room, look around and observe objects – let alone people – study them, and you will, inevitably, start getting a little more interested in the room, AND a little more extroverted at the same time, if you do the drill sincerely.

And you can study a person for a while and find something in them to relate to.

I’m sure, at one time or another, you have experience a moment of urgency in which your interest, extroversion and presence in the moment shot up, out of sheer necessity! Well, if nothing else that proves you can do it. Which means it’s something that you can actually practice and become more skilled at it. And we’re not talking about something faked here. You can spot that a mile away. We’re talking about the real thing.

This also goes to your attitude. If you find yourself feeling antagonistic, bored, angry, a little upset, or even apathetic, you can 1) learn to spot that this is the case and that it also means that you are less interested and extroverted – that’s just the way it works; so you can use it as an indicator and 2) rather than introverting in order to “figure out why this is” you can, tactically, just apply the technique of getting interested, just overtly making yourself do it.  And sometimes, to your great surprise, you just may, in a little while, cease to have any further attention on whatever it was you were sunk in.

Hope this is helpful.

 

The Perfect Definition of Done

In addition to whatever else it may have to offer, Large Scale Scrum (LeSS) has resting inside it an idea that is powerful in both its simplicity and scope. Its the idea of the perfect Definition of Done.

According to LeSS Rules, The perfection goal is to improve the Definition of Done so that it results in a shippable product each Sprint (or even more frequently).[1]

The big idea here is that we can use our Definition of Done as a measure or indicator of how well we’re doing on our road to integrating teams, providing rapid, end-to-end responses to customer need and market change, and becoming truly agile. Examining the Definition of Done can help us see and navigate through the incremental steps to achieve this agility.

The idea becomes clearer when we look at four basic steps that are suggested for defining your Definition of Done:[2]

  1. Establish all the actions needed to ship to end customers
  2. Work out what can be done in a sprint
  3. Step back and look at the “undone work” that will be left
  4. Come up with your first incremental improvement goal for expanding the Definition of Done to decrease the undone work.

Those four “simple” steps may include many impressive barriers and encompass a lot of hard work before we achieve the perfect Definition of Done, and in some cases we may not get there for a very long time. But I believe those few steps do express what we’re trying to achieve. You need, of course, to include empowerment, eliminating hand-offs, continuous improvement, and so on. But the fact is, driving toward perfection in your Definition of Done will necessarily involve these principles and practices. They represent the means by which you’ll get there.

There are a couple things I especially like about this approach to defining and maturing the Definition of Done.

First, the idea is scalable.

It’s scalable because the concept applies equally well to an individual team, a whole set of teams working together on a large product, or an entire organization. Regardless of where you are in the game, this approach can be applied. Even an individual team member can look at the current scene and ask themselves, “Am I contributing to a silo? What can I do to improve flow along with the scope of what I contribute?”  At the entire organization level, we can ask, “What’s our cycle time to customer delivery for the entire organization? Can we broaden our Definition of Done to also include measuring outcomes?” And, “Can we include our customers even more deeply in initial product definition? What incremental steps do I take in that direction?” Questions that again, any single team can also ask of itself.

A second thing I like about this idea of the perfect Definition of Done as a measure of and guide to agile maturity, is that it is non-judgmental.

That may sound like an odd thing to say.  Here’s what I mean: Both Scrum itself, as embodied in the Scrum Guide, and LeSS are clear about the goal of having potentially releasable product every sprint.  But the way Larman and Bodde have laid out these suggested steps to creating the perfect Definition of Done, they have implicitly conveyed it in these terms:

  • What’s the specific ideal state – in terms of end-to-end production in a single sprint, for this organization we are dealing with?
  • What can we do now?  How close can we come?
  • What’s the next step we can take to get closer to the ideal?

To me this communicates that, while not compromising on what true agile development at scale means and the value in knowing what it should look like and moving relentlessly toward it, we may not achieve perfection overnight. What is important is that there is an alignment on the goal, and an intensity in moving in that direction. In the end, the market, along with the group’s own desire to produce and contribute, will determine what pace is necessary and achievable.

Any agilest would do well to familiarize themselves with the concept of the perfect Definition of Done, as described in LeSS. It’s in a way the simplest of lenses, one through which a team’s, a unit’s or an entire organization’s agile maturity can be brought into focus, and the optimum road forward viewed with greater clarity.

Of course broadening one’s view of the Definition of Done associates with how broadly the Product is defined, both initially and over time. But that is topic for another time.

[1] Large-Scale Scrum: More with LeSS (Larman and Bodde, 2016 Addison Wesley)

[2] Ibid

Coaching Rightness

As an Agile Coach, you are anxious to add value.  You have armed yourself with all the indicators of team dysfunction, all the techniques for managing conflict, all the bad behavior patterns to watch for in Agile ceremonies and ways to address them.  But with all this knowledge of what can be wrong with a team and how to fix it, there is one tool, stuffed in the corner of your tool bag, that can get neglected: recognizing what is right.

When you’re a hammer, to you everything looks like a nail.  When you’re an Agile Coach, you of course must find things to coach, right?  Sometimes the most courageous thing a Coach can do is not exposing the deep, unspoken problem that everyone is afraid to voice.  Sometimes the bravest thing you can do is to believe in them, focus on what is right about them, and their own ability to act.

What, after all, are you trying to do for this team?  You are trying to make them self-determined, self-organizing, confident enough in themselves to be decisive, and to trust and collaborate with each other.  You’re trying to increase their rightness.

The team’s capacity to address things that are wrong is proportional to how much rightness they have.  In a truly high performing team, wrongnesses don’t stand much of a chance.  They evaporate quickly in the bright light of the team’s smooth operation.  For such a team, looking hard for things wrong would itself be a wrongness, introverting the team away from its forward motion.

It is by making the team more and more right that you accomplish their independence and competence.  When you focus your attention on what is wrong, what needs fixing, you will inevitably find it.  There are an unlimited number of things that you can and will find.  You are the hammer, seeing nails everywhere.

Don’t misinterpret that to mean that a dedication to continuous improvement is a bad thing.  Not at all. A good Coach seeks to improve the team’s ability to continuously improve itself, and their capacity to do so.  That is measured in and enabled. by the team’s pride in quality and confidence that comes with success.

Recognizing and strengthening rightness is more than giving acknowledgements in standup or reviews.  There are number of specific actions you can take to do this.  For example:

  • Having members of the team demo and discuss their contributions to the product at Reviews
  • Taking them to client sites where they see their product in action, helping organizations in major ways
  • Introducing them to clients who tell about the value of the product to them
  • Probing with powerful questions not just in sorting out a situation or relationship needing fixing, but to bring about awareness of achievement when something goes right, that the team member or team just did something that was actually quite remarkable
  • In retrospectives, being just as rigorous about root cause analysis of things that went right as those that went wrong, and logging actions to reinforce them. Maybe nobody quite noticed that when the system was down and they took a hack day, they ended up with their most productive sprint ever.

But the first and foremost thing you can do is look.  Look for the strengths in your team.  And look for what you can believe in about each one of them.  If you can do that, and realize that the real power is theirs, and that you are just there to help them unleash and channel it, you’ll be a great coach.

Business Value – The Holy Grail

Business value delivery is at the heart of Agile, and search for its real meaning has become a sort of Agile Holy Grail.  Yet when you step far enough back from any of our software development practices, we still seem, at the end of the day, seem to mostly operate within the zone of simply “delivering features the customer likes.”  I suppose if you want to stop there and maintain that mindset, then that is one way to play the game.

But if we want to broaden our horizons, move out our sphere of responsibility, and play a trusted role in more organic organizations, we need to look further.  The, for me astonishing, possibility, is that there may be one very simple step that teams and organizations can take to do so.

A good practice is for Business Managers or Product Owners, as a usual part of an initiative, to sort out the leading and lagging indicators that they will track to see if their business objectives have been met.  Methods like impact mapping can help with doing this.  The basic idea is not all that new.  It’s even part of older requirements engineering disciplines, under names like “success measures.”  It was just never much practiced in my experience.

What would be new, at least in many organizations, would be to share these indicators with the development / delivery team as a standard part of the process.  Invite them into the process, at least as observers and perhaps even as contributors of possible lagging indicators.  The idea:  allow the team the opportunity to understand and assume some ownership as well in achieving the actual business value sought by the organization.  This approach could apply regardless of whether the product had to do with software.

With that the picture starts to look more complete.  And to be honest, it resolves a little bothersome thought about Agile that has sometimes nagged at the back of my mind.  In the zeal to flatten organizations and become highly cross-functional, I sometimes sniff a tiny motivation to “finally get out from under the wings of the business” and to seize the opportunity to take the lead role in steering the business.  The fact is there are great business leaders.  They exist.  By broadening our role in the game, as systems people, by the simple step just described, we dramatically improve our ability to collaboratively help them help the business endeavor achieve high goals.  With that comes joint satisfaction.  It also makes gaps in that leadership more transparent, providing the opportunity for them to be addressed, and the opportunity for well-intended business people to evolve to better ways of working, right along with us.

I would love your thoughts on this.  We have all the theory and methods to simply begin doing this and let it become a de facto integral part of any Agile process.  And of course, inspect and adapt on making it work better.

Agile Scaling Conversations from the San Diego Global Scrum Gathering

The San Diego Global Scrum Gathering was a great success!  Between the formal presentations and the Open Space meetings, the topic of scaling, including Large Scale Scrum (LeSS) and comparisons with the Scaled Agile Framework (SAFe) and just basic Scrum, was an area of high interest as you might imagine.

No “final answers” of course, but here are a couple observations that emerged from conversations featuring a mix of coaches well versed in SAFe, LeSS, both, and neither.  It was a dialogue grounded in, but not jaded by a wealth of practical enterprise experience mixed with genuine agile passion.

One general conclusion offered was that some type of SAFe-based approach might be a workable step into agile development for large, complex, and conservative organizations where a full-on assault of the organizational structure would be a non-starter.  There was overall consensus that SAFe does not challenge the existing organizational hierarchy near as much as LeSS.  Craig Larman, in his presentation on LeSS, reinforced its emphasis on moving organizational structure away from local optimization.  Don’t ask how to do Scrum in a large, complicated organization, he said.  Ask why do you have such an organization?

Not that it was all about LeSS vs Scrum.  In his 5 Steps to Disruptive Innovation, Sanjiv Augustine provided a set of clearly articulated steps for transforming to a Product-Centric organization.  And there was the one very veteran coach who observed that after much familiarization and work with both frameworks that he now finds himself tending back toward simply Scrum and basic, incremental Scaling.

Alistair Cockburn observed that with models pushing vision and expectations heavily downward while trying to provide a space for empowerment and agility at ground level, the middle layer of management buffering those teams may take a beating.  In fact, he noted one agile implementation that collapsed upon the departure of just such key figure.  Backtracking with him, Cockburn discovered that this was exactly what had occurred.  The buffer was gone and the delivery teams ended up reverting.

I would be very interested in your thoughts on this topic.  The problem and opportunity of Agile transformation is certainly upon us.  Wouldn’t it be great to have an openly referenceable body of knowledge on empirical paths to success, and speed of transformation, based on some key organizational characteristics?  That would certainly be adaptive and transparent.