The Five Dysfunctions of a Team Cover

The “Book” during unboxing!

Five Dysfunctions of a Team, Patrick Lencioni:  Re-Read Week 6

Today we continue our re-read of the business novel The Five Dysfunctions of a Team  by Patrick Lencioni (Jossey-Bass, Copyright 2002, 33rd printing). If you do not have a copy of the book, please buy a copy from the link above and read along.

This week, we get are exposed to Lencioni’s whole model of team dysfunctions. Lencioni continues to illustrate the model through a series of problems and crises that make the DecisionTech team into a dysfunctional collection of individuals.

Deep tissue (more…)

risk-curve

Risk tolerance can be visualized as a curve. Above the curve represents a combination of high probability and a potential negative impact that will prevent the team from accepting the risk. Below the curve, the risk is deemed acceptable.  Outside of a few psychologically damaged individuals, everyone has a risk curve (whether they know it or not). On a team, everyone’s natural risk tolerance differs.  Complicating the discussion is that risk tolerance changes depending on context the person or team faces.  For example, at one point in my life riding my bike down a hill at top speed to see if I could slalom stop at the bottom was an acceptable risk.  I have the scars to prove I was that silly. Thinking back, I am not sure why I am alive today.  My risk tolerance is different now. While reminiscing about my unsafe days as a seven-year-old is fun, what is more important is to recognize that the same lesson can be applied to teams and in organizations. This leads us to the conclusion that we must talk about risk tolerance.   (more…)

The Five Dysfunctions of a Team Cover

The “Book” during unboxing!

Today we begin the read of  The Five Dysfunctions of a Team by Patrick Lencioni (Jossey-Bass, Copyright 2002, 33rd printing) as part of our Re-Read Saturday feature. This book uses a business novel approach to make his points. As I noted as we completed the re-read of XP Explained, Steve Adams suggested this book. This is a first read for me.  Please buy a copy and read along.  When we are done I will invite anyone that has contributed to the discussion to appear on the Software Process and Measurement Cast for a wrap-up discussion.

The book includes an introduction, two major sections, and 4 additional chapters. The two sections are titled:

  1.    The Fable.  The fable has five parts noted in the table of contents; however, it is made up of a large number of subsections.
  2.    The Model with three parts.

I suspect that we will read the book over 12 -13 weeks, each week representing a review of roughly 20 – 30 pages (depending on breaks in the book and the need to discuss the Lencioni’s ideas). Now without further ado… (more…)

Team Dynamics

Team Dynamics

Teams are a common theme in the discussion of how Agile delivers value.  Teams are a collection of individuals that bring a range of capabilities.  Some people are specialists, others generalists and a very few are  renaissance people that are great at a wide range of activities.  Understanding the depth and breadth of capabilities in team members provides the team with the flexibility to dynamically allocate capabilities based on the technical context and business need (staff liquidity).  This is an incredibly powerful theory that only works if the team dynamics are conducive.  Team dynamics are an expression of how the team interacts with each other and those outside the team. When assessing the dynamics of a team there are many factors that are important; however, a few are more critical than others. (more…)

Looking at the map to starting an Agile effort?

Looking at the map to starting an Agile effort?

What is needed to start an Agile project?  There are a number of requirements for beginning an Agile effort.  Those requirements typically include a big picture understanding of the business need, a budget, resources, and a team.   Somewhere in that mess, someone needs to understand if there are any unchangeable constraints. A high-level view of the five categories of requirements for starting an Agile effort are:  (more…)

People are chaotic.

People are chaotic.

Have ever heard the saying, “software development would be easy if it weren’t for the people”? People are one of the factors that cause variability in the performance of projects and releases (other factors also include complexity, the size of the work, and process discipline.) There are three mechanisms built into most Agile frameworks to address an acceptance of the idea that people can be chaotic by nature and therefore dampen variability.

  1. Team size, constitution and consistency are attributes that most Agile frameworks have used to enhance productivity and effectiveness that also reduce the natural variability generated when people work together.
    1. The common Agile team size of 7 ± 2 is small enough that team members can establish and nurture personal relationships to ensure effective communication.
    2. Agile teams are typically cross-functional and include a Scrum master/coach and the product owner. The composition of the team fosters self-reliance and the ability to self-organize, again reducing variability.
    3. Long lived teams tend to establish strong bonds that foster good communication and behaviors such as swarming. Swarming is a behavior in which team members rally to a task that is in trouble so that team as a whole can meet its goal, which reduces overall variability in performance.
  2. Peer reviews of all types have been a standard tool to improve quality and consistency of work products for decades. Peer reviews are a mechanism to remove defects from code or other work product before they are integrated into larger work products. The problem is that having someone else look at something you created and criticize it is grating. Extreme programing took classic peer reviews a step further and put two people together at one keyboard, one typing and the other providing running commentary (a colloquial description of pair programing). Demonstrations are a variant of peer reviews. Removing defects earlier in the development process through observation and discussion reduces variability and therefore the risk of not delivering value.
  3. Daily stand ups and other rituals are the outward markers of Agile techniques. Iteration/sprint planning keeps teams focused on what they need to do in the short-term future and then re-plans when that time frame is over. Daily stand-ups provide a platform for the team to sync up on a daily basis to reduce the variance that can creep in when plans diverge. Demonstrations show project stakeholders how the team is solving their business problems and solicit feedback to keep the team on track. All of these rituals reduce potential variability that can be introduced by people acting alone rather than as a team with a common goal.

In information technology projects of all types, people transform ideas and concepts into business value. In software development and maintenance, the tools and techniques might vary but, at its core, software-centric projects are social enterprises. Get any group of people together to achieve a goal is a somewhat chaotic process. Agile techniques and frameworks have been structured to help individuals to increase alignment and to act together as a team to deliver business value.

The dwarfs of self-management are Committed-y, Hardworking-y, Assertive-y and Doc.

The dwarfs of self-management are Committed-y, Hardworking-y, Assertive-y and Doc.

Effective teams are self-managing. Self-managing teams plan and manage their day-to-day activities with little overt supervision. In order for teams to be self-managing individual team members have team have to be committed to the team, have a clear understanding of roles and capabilities, understand the concept of deadlines and be effectively assertive.

  1. Commitment: Team members must be committed to the team. All teams will go through periods of stress and conflict, committed team members will stay with the team and seek to work through issues. Commitment can only occur if team members believe that the team can succeed and that membership will have value to the individual.
  2. Clear Understanding: The ability to self-manage requires an understanding of the roles that individuals can and do play and their capabilities. For example a business analyst that does not understand how to read C++ can’t be asked (or volunteer) to review C++ code. An understanding of roles and capabilities allows the team to plan effectively, to evaluate performance and provide feedback to fellow team members.
  3. Deadlines: One of more important features of Scrum is the public affirmation to complete the stories accepted into a sprint. The affirmation is a commitment that the team must strive to meet. When teams commit to a specific delivery deadline they need to strive and strive hard to meet those goals.
  4. Being Assertive: Team members need to be assertive enough to initiate action, provide feedback, communicate and coordinate activities between team members. Every team member has the authority and responsibility to get the job done.  The ability to be effectively assertive means that team members have to interact so that communication occurs and does not actively to cause conflict.

In order for a team to self-manage, the team will need to exhibit all four attributes, failing any of the four self-management becomes difficult. All four attributes are a reflection of team self-knowledge. Teams that stay together and successfully deliver value to the organization tend to form bonds based respect and mutual support.