Preparation is key to reaching your goals.

Successful and efficient planning of any sort represents the confluence of preparing the work to be planned and proper logistics. Earlier in this series on planning, we reviewed the basic logistics needed for a planning event and defined a simple checklist.  While both are important, preparing the work to be planned requires more effort.  Preparing the work for planning requires knowing the capacity of the team and grooming the work items (stories, requirements, support tickets and/or defects). (more…)

Advertisements
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.