Boundaries, like fences are one potential difficulty.

Boundaries, like fences, are one potential difficulty.

Systems thinking is a powerful concept that can generate significant for value for organizations by generating more options. Dan and Chip Heath indicate that options are a precursor to better decisions in their book Decisive. Given the power of the concept and the value it can deliver, one would expect the concept to be used more. The problem is that systems thinking is not always straightforward.  The difficulties with using systems thinking fall into three categories.

  • Boundaries
  • Complexity
  • Day-to-Day Pressures

Organizational boundaries and their impact of the flow of both work and information have been a source of discussion and academic study for years.  Boundaries are a key tool for defining teams and providing a send of belonging; however, some boundaries not very porous. As noted in our articles on cognitive biases, groups tend to develop numerous psychological tools to identify and protect their members.  Systems, in most cases, cut across those organizational boundaries. In order to effectively develop an understanding of a system and then to affect a change to that system, members of each organizational unit that touches the system need to be involved (involvement can range from simple awareness to active process changes). When changes are limited due to span of control or a failure to see the big picture, they can be focused on parts of a process that, even if perfectly optimized, will not translate to the delivery of increased business value.  In a recent interview for SPaMcast, author Michael West provided examples of a large telecommunication company that implemented a drive to six sigma quality in its handsets, only to find out that pursuing the goal made the handset too expensive to succeed in the market. In this case the silos between IT, manufacturing and marketing allowed a change initiative to succeed (sort of) while harming the overall organization. (more…)

USA border crossing

USA border crossing

Are unit and integration testing the same things masquerading under a different name? No. Unit testing is a process in which a developer tests a very specific self-contained function all by itself, whereas we have defined integration testing as testing in which components (software and hardware) are combined to confirm that they interact according to expectations and requirements. Unit testing and integration testing are fundamentally different forms of testing.  There are three major differences.

Boundaries: All levels of integration testing cross boundaries either between classes, functions or components.  The goal is to determine if the parts of the application fit together and perform as expected.  Unit tests focused on the performance of a single function by definition can’t cross boundaries and do not test dependencies outside of the function being tested.

Scope: A unit test is focused on answering a single question: Based on the test input, does the specific function perform as expected? An example of a simple unit test might be, “if I put a number in a field that only accepts letters, do I get an error?” Because integration tests reflect the interaction between functions or components, they must answer several questions. For example, in Test Driven Development: An example of TDD with ATDD and BDD attributes, we described a simple beer glass collection tracking application. In the application, the user enters the glass being collected into a screen, and after validation, the database is updated. An integration test would need to be written and performed that tests sending the information from the data entry function to the database.  The test would cover several different specific points such as, was the information sent from one module to the other, was it received by the other, and was it inserted in the database correctly.

Role Involvement: Unit testing is part of the coding process.  Occasionally I see tester doing a developer’s unit testing – this is a VERY POOR practice. At its very simplest, the coding process can be described as think, write code, see if it works, if it doesn’t work, go back to thinking. Then repeat, and if it works, commit the code and go to the next requirement. The “see if it works” step is unit testing. Integration testing in its most granular form reflects a transition between coding and validation processes. The transition means that the results need to more broadly seen and interpreted to ensure that all of the parts being developed or changed in a project fit together. Testers, business analysts, developers and sometimes business stakeholders and product owners can be part of executing, interpreting and consuming integration tests.

Unit testing and integration testing are at times easily confused, this is most true when considering integration tests focused at the connections between functions within a single component. However, if we consider whether boundaries are involved and the number of conditions/questions the test is resolving (which suggests that number of roles need to understand the results) the distinction becomes fairly stark.

Boundaries, like fences are one potential difficulty.

Boundaries, like fences are one potential difficulty.

Systems thinking is a powerful concept that can generate significant for value for organizations by generating more options. Dan and Chip Heath indicate that options are a precursor to better decisions in their book Decisive. Given the power of the concept and the value it can deliver, one would expect the concept to be used more. The problem is that systems thinking is not always straightforward.  The difficulties with using systems thinking fall in to three categories.

  • Boundaries
  • Complexity
  • Day-to-Day Pressures

Organizational boundaries and their impact of the flow of both work and information have been a source of discussion and academic study for years.  Boundaries are a key tool for defining teams and providing a send of belonging; however some boundaries not very porous. As noted in our articles on cognitive biases, groups tend to develop numerous psychological tools to identify and protect their members.  Systems, in most cases, cut across those organizational boundaries. In order to effectively develop an understanding of a system and then to affect a change to that system, members of each organizational unit that touches the system need to be involved (involvement can range from simple awareness to active process changes). When changes are limited due to span of control or a failure to see the big picture, they can be focused on parts of a process that, even if perfectly optimized, will not translate to the delivery of increased business value.  In a recent interview for SPaMcast, author Michael West provided examples of a large telecommunication company that implemented a drive to six sigma quality in its handsets, only to find out that pursuing the goal made the handset too expensive to succeed in the market. In this case the silos between IT, manufacturing and marketing allowed a change initiative to succeed (sort of) while harming the overall organization.

The second category is complexity.  Even simple systems are complex. Complexity can be caused by the breadth of a system.  For example, consider the relatively simple product of a lawn service.  How many processes and steps are required to attract and sign-up customers, then secure the equipment and employees to perform the job, schedule the service, actually deliver the service and then to collect payment? The simple system becomes more complex as we broaden the scope of our understanding.  Add in the impact of a variable like weather or an employee calling in sick, and things get interesting.  Really complicated systems, such as the manufacturing and sale of an automobile, can be quite mind-numbing in their complexity.  The natural strategy when faced with this level of complexity is to focus on parts of the overall system. This can lead to optimizations that do not translate to the bottom line. A second natural strategy for dealing with complexity is to develop models. All models are abstractions, and while abstractions are needed, you need to strike a balance so that the ideas generated from studying the model or results of experiments or pilots run against the model are representative of results in the real world.  For example, let’s say you build a 1/8 scale replica of a server farm.  The replica is a model that could be used to study how the servers would be placed or used to plan how they would be accessed for service. This would be a valid use of a model.  But if the model was placed in the actual server room and the observation used to jump to the conclusion that since the model fit, the server farm would fit, a mistake could quite possibly be made. Because of the complexity, we tend to focus on a part of system or to make abstractions. However, both can make it hard to think about the big picture needed to apply systems thinking.

The final difficulty with the use of systems thinking is the pressure of the day-to-day.  As I noted when I re-read The 7 Habits of Highly Effective People, the urgent and important issues of the day can easily overwhelm the important but not urgent. The use of systems thinking and the systemic changes identified through the use of the tool will generally fall into the important but not urgent category.  A person who is having a heart attack due to cholesterol-clogged arteries needs to deal with urgency of the attack before identifying and addressing their diet and other root causes. Leveraging systems thinking as a tool to address large-scale systemic issues is not a magic wand, rather a concept that will require time and effort to use.  If the organization is being overcome by day-to-day events, systems thinking will be difficult to use.  One technique that I have seen to deal with this scenario is to create a cross-functional, highly focused (tiger team) with a specific time box to start the process. This will require removing the team’s day-to-day responsibilities until the team meets its goal. This is a very difficult tactic to use as the people you would want on the team are generally the best at their job. This can potentially have a negatively impact organizational performance for a short period of time. You must consider the ROI.

The use of systems thinking is not for the faint of heart.  There are difficulties in applying the concept.  Boundaries, complexity and day-to-day pressures are the most significant, however there are others such as ensuring the team has system thinking training. Systems thinking can deliver a broad overall perspective and great value, but as a leader you must balance the difficulties with the benefits.

A hockey rink reflects an external boundary.

A hockey rink reflects an external boundary.

Motivational Sunday

Boundaries are an integral part of everyday life.  Boundaries shape how we behave and how we interact with others. Boundaries provide context to help us determine who belongs on our teams, they help us understand the range of acceptable behavior and the constraints that the organization or market places on our projects. I was recently involved in helping an organization implement Agile.  The initial boundary of the transformation program focused on just the IT organization however the Agile techniques did not become effective until the business agreed to participate as product owners.  They had to agree to step across the IT team boundary and interact.  Boundaries can be external and more fixed, fluid or internally defined and each type impacts how we behave in different ways.

Boundaries can be external, generated by those around us.  For example, the physical boundaries of the department you work for or your desk in in a corporate office are assigned to you. Behavioral guidelines, outlined in an employee handbook, may have been provided to you the day you began your job. In order to avoid conflict with the group or groups you belong to, of you need to live within the boundaries that the group believes are important. These boundaries are part of the group’s culture.  Violating boundaries can be viewed as eccentric when the boundary being violated is not core to the definition of the group (the guy that wears a bow tie rather than a straight tie), or grounds for punishment when the boundary being violated is considered core (betting against your own team if you are a baseball player). If you disagree with the boundaries you should leave the group because unless you have significant power you can’t

Boundaries can be fluid – the meaning can differ depending on the circumstances.  For example, the consequences of violating a caution tape boundary around a newly seeded lawn would have different consequences than that of caution tape around a patch of poison ivy.  Similar contextual boundaries exist organizations as team form and reform, alliances between managers form and reform and even as strategic alliances between organizations change. (Remember when Apple and Google cooperated closely?)  We are obligated to continually be aware of our environment as formal and informal boundaries ebb and flow so that we can be effective and efficient.

Finally boundaries can be internal, generated by our perception of the environment and our place in that environment.  Boundaries shape how we behave and how we interact with others but perhaps more true for those that we frame for ourselves. For many years, I believed that I was a poor public speaker, I erected a boundary between myself and public speaking.  That boundary shaped how I interacted with the world for many years.   We are accountable for our behavior and the boundaries that we construct around ourselves.  The only thing we can truly control is our own behavior and therefore we need to accept that we can change the boundaries we construct for ourselves if we want to change how we interact with our environment.

Boundaries are a fact of life.  Whether a boundary is externally generated, contextual in nature or inside our own head, if your boundaries are in the way of our own self-actualization – change those boundaries.  Change may involve changing jobs, creating new friends and alliances or changing how you behave. In the long run, you have control over the boundaries that constrain you.

20130502-143225.jpg
It is a commonly held belief that a team comprised of a blend of skills and experiences can accomplish nearly anything. Because we believe that teams are effective, they are used to solve nearly every problem. In some cases the word ‘team’ has become a talisman without a practical definition. In many cases the lack of definition means that what we call teams have amorphous membership and boundaries which makes it hard to understand who is member, even for those who are on the team.

In his 2009 book, ‘Leading Teams’, J. Richard Hackman suggests that if teams are not bounded the effectiveness of team is reduced. This reduced effectiveness can be caused by many factors, including role confusion or by inability to invest in building trusting relationships. If you don’t know who is on the team today or who will be on it tomorrow, it is is difficult to invest the time and emotional capital needed to build relationships. This is especially true of diverse teams with people of different backgrounds.

Teams have great value. When we discuss the Agile principle of IT and the business working together on a daily basis, the underlying assumption is that the interaction happens at a team level. However, for the interaction to be effective the team needs to be effective. One critical component of building an effective team is that it needs to be bounded, so that the necessary relationships can be built for information and knowledge sharing.