Teams: Organizational Attributes

Teams don’t live in a vacuum. Every team is an intersection of boundaries of all sorts of organizations. Organizations facilitate teams to a greater or lesser extent. In the workplace, the employer’s organization will have the most significant impact on how teams form and perform but it is not the totality. Other influences can affect the structure and performance of teams. In the short run, many organizational factors are difficult and slow to change (not impossible).  Many of the behavior factors noted earlier in this thread might be an affectation of the organization. A few of the most critical attributes to consider are:

 

Teams: Behavioral Attributes

The second category of attributes that are important for teams to be effective is behavioral attributes. These attributes describe how individuals and teams as a whole act. While the first category, skills is about the individual, behavior is about the team as a group. All team members’ behavior should contribute to how the team works together to meet it’s goal. The most important behavior attributes are:

 

Teams: Skills Attributes

Most outcomes in software development and information technology are reflections of team activities. Whether coding a new function or provisioning a server people work together to achieve a goal. The great majority of these collaborations yield positive results; sometimes the results are even extraordinary.  The team or teams doing the work have a HUGE impact on the results.  A coach or a guide needs to be able to read the tea leaves so they can help teams improve. In Teams: The Heart And Soul Of Work, I identified three categories of attributes of good teams. They are:

1. Skils,
2. Behaviors, and 
3. Organization.

 

Simple Approaches To Build Trust On Remote Teams

Deconstructing Value Is Just Like Demolition!

Trust is an important component for building effective teams, unfortunately, you can’t buy a bag of trust and like plant fertilizer, sprinkle it on a team. In a special panel discussion aired on SPaMCAST 591, Jeff Dalton reminded us that trust is built; it does not magically appear because we want it to. Many of the Software Process and Measurement Cast and Blog listeners have been thrust into situations where they are suddenly remote and learning to build trust as part of newly remote teams. Sandeep Koorse made an interesting observation in the same podcast that many of us had been lulled in a false sense of trust and intimacy because we have been face-to-face for so long. The implication is that teams don’t invest the time needed to build trust that can withstand shocks like we are now facing. A few simple (no consultants needed) ideas to begin building trust on your suddenly remote team include:

 

SPaMCAST 591 Special! – Advice For Remote Teams, A Discussion with Dalton, McDonough, Koorse, Hurney, and Cagley

http://www.spamcast.net

Listen Now!

The SPaMCAST 591 is a very special podcast.  On the 18th of March, I convened a panel of luminaries to discuss how they were supporting and working with remote teams. I recorded both the audio and video, today I am releasing the audio version.  The panel for this show was  

Jeff Dalton jeff@broadswordsolutions.com 

Amy McDonough Amy.McDonough@spr.com 

Sandeep Koorse Sandeep@koorse.com 

Christopher Hurney    Christopherhurney@gmail.com

And myself! tcagley@tomcagley.com 

We kept the session short but full of practical advice!

 

Trust and Effective Teams (Remote or Not!)

Effective teams exhibit a number of common characteristics.  In an earlier article, we identified four critical attributes.  

1. Members actively support each other so the team succeeds as a whole.
2. Teams actively interact and communicate.
3. The team has a common goal.
4. How work is performed.

 

Calling Collaboration Before It Happens

Collaboration is no soft toss!

Many people have the idea of the lone innovator or the lone programmer developing solutions based on the wits to the adulation of the business deeply embedded in their subconscious.  These lone wolves don’t collaborate. The picture is wrong. Today’s business environment is fundamentally different. Teams and teams of teams are the problem-solving technique de jour.  Collaboration is an important part of solving business problems in teams. Because collaboration is so important, it is important to consider whether planned meetings, events, and interactions are set up to be collaborative before they occur.  Jonas Bull suggested a modification to the collaboration filter we have been using to evaluate whether an event is collaborative posthumously. Jonas’s suggestions (melded with Stephen Adam’s suggestions) follow below:

 

When Meetings and Management Styles Are Collaboration Fails!

Is a root canal collaboration?

We ended Part 1 of our evaluation of activities confused with collaboration with a reminder of logic: all dogs are mammals, but not all mammals are dogs.  All collaborative processes include communication and have a workflow, but, if we flip the equation, not all communication and workflows are collaboration.  Management and meetings are the last two areas of activities in all software development and maintenance organizations (and I do mean ALL) that we will discuss. Collaboration a critical part of delivering quality, in order not to dilute the power at the core of collaboration it is important to clearly understand which behaviors are easy to conflate with collaboration.

 

SPaMCAST 554 – Not Collaboration, Solutions Architects, Essays and Discussions

http://www.spamcast.net

Direct Playback

Subscribe: Apple Podcast
Check out the podcast on Google Play Music
Listen on Spotify!

SPaMCAST 554 features our essay on the misuse of the word ‘collaboration’. Collaboration is a hallmark of agile techniques, but people confuse collaboration with many other forms of interactions. When that happens everyone gets confused and disheartened. In order to stop the cycle, we identify four attributes to help recognize collaboration.

We’ll also hear from Gene Hughson who brings his Form Follows Function Column to the podcast.  In the second part of a three-part series on architects, Gene discusses the role of the solutions architect.  Part One can be found on SPaMCAST 543 – Value Chain, Solution Architects, Essays and Discussions Web Player and Show Notes: http://bit.ly/2L3tLku

 

Collaboration or Not? Applying A Framework To Evaluate

We recently developed a structure for evaluating whether an activity was collaborative or not.  The four-step evaluation process is important because the same activity is collaborative in one context and overhead in another.  There are four areas of activities in all software development and maintenance organizations (and I do mean ALL) that are sometimes collaboration and sometimes not, but almost always sold as collaboration.  Today we tackle the first two areas.