Sometime you need something to keep cars off of the sidewalk!

Guardrails are a tool to ensure alignment with the organization’s goals and objectives and to keep people on the right path. Guardrails are an everyday fact of life. Several years ago, I was on vacation in Lima, Peru. During the vacation, we ventured into the heart of the city to see the sights, at the end of the day four of us piled into a cab on a very crowded street to go back to the hotel. Mass was just ending at the cathedral and there were throngs of people taking to the street. The driver inched along for a few minutes then pulled the car up on the sidewalk and began rocketing forward (the rocketing part is my recollection). I still wake up occasionally picturing people diving into doorways. Jason Bourne had nothing on this guy. In most societies, there are laws, standards or just social norms about driving on the sidewalk.  I was in India for the past two weeks. When we in touring Mysuru, several coroners had physical barriers (concrete and metal poles) to keep cars from cutting corners and driving on the sidewalk.  Both of these examples represent types of guardrails. Guardrails channel behavior for the benefit of the greater society by abridging, formally or informally, the range of action individuals can take. Breaking through a guardrail requires a conscious decision. Software development, in all of its forms, requires guardrails unless every decision made by a team is scrutinized and approved before it is made. Without guardrails words and phrased like self-directed and empowered teams are hollow.  In order for guardrails to be effective, there need to be a few simple’ish guardrails for the guardrails: (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…)

Constraints encourage creativity

Constraints encourage creativity

Charters in Agile can be used to help a team bond and focus. As efforts scale up to require teams of teams, the charter also is useful as a communication vehicle. The four categories of information are typically included in Agile Charters are:

  1. Envisioning Success
  2. Behavior
  3. Timing
  4. Constraints

Each category addresses different concepts that are important to help a team or a team-of-teams in a scaled effort to act in coordinated manner. We complete our tour of the four basic topics of Agile Charters by reviewing the possible topic areas with the components that can be used to address constraints.

Summarized below are the most common components used to address constraints. A quick definition is included for each component and a recommendation whether the component should be used for either a team or scaled Agile charter. Yes means the component should typically be used, meh is an unenthusiastic maybe and no means don’t. (more…)

The Mythical Man-Month

The Mythical Man-Month

In the ninth essay of The Mythical Man-Month, Fred P. Brooks discusses the impact of building a system with a size constraint. In most corporate organizations, size is not generally a constraint programmers need to consider. While you don’t hear as much discussion of the physical size of the code as in the past, I recently heard an IT professional lamenting the size of iPad applications. In this case the size of an app impacted how many apps that could be crammed onto a device. Perhaps as devices become smaller, the old constraints of code size will rear back up. Similarly, size is still a constraint when dealing with embedded systems. The discussion of how and why we need to manage a size constraint is a reminder that all physical constraints must be managed.

Managing size is not as straightforward as building to a single executable size for the entire application. For example, building an app to fit within a 400 kb footprint might be the ultimate goal, but while the overall app might one goal each component or function considered could have different size constraints. Interfaces often require more space to code than an algorithm; therefore the number of interfaces may need to be more constrained than the number of algorithms. When managing size one has to account for all of the component parts and the whole at the same time. In this essay, Brooks used his experience with OS/360 to provide examples and discuss different components, such as core and peripherals. While most of us will never write one of premier operating systems, the lessons are still useful.

Management of the size a program, application or any constraint must include setting goals for each component and also the ability to simulate performance against those goals. Just planning, represented by setting the goal, is not enough. A feedback loop is required. Performance testing provides feedback to ensure that the work is meeting the goal and whether the goal was set correctly in the first place. I have been involved with projects that required rethinking when constraints were found by the programmers to be impossible to stay within. Ask me about the DOS COBOL and macro assembler monsters that once upon a time stalked my world due to a compiler constraint. Brooks drew three basic lessons from managing size (or any constraint) based on his experience:

  1. Set size goals/budgets for the both the total application and individual components.
  2. Define exactly what the application and each module must do. Functionality and size are typically related. The more functionality, the larger the component or application. Understand the functionality required holistically, not just from one single point of view.
  3. Identify a central point to foster continuous communication so that teams all work toward the overall goal. Brooks reflects that on large projects team and sub-teams often pursue goals that sub-optimize the overall application due to competition and communication problems. This point highlights the need for a structure for scaling large Agile efforts to address common constraints.

Budgeting and control, while important, are not sufficient to alleviate any technical constraint. In software development (in its broadest sense), once you have a goal, you need to address that goal as a constraint. Addressing a constraint requires both invention and craftsmanship.

Craftsmanship in software development is built on deep knowledge of tools, languages and techniques. Standards, frameworks and architectures provide guidance and team members provide support and mentor each other. An example of craftsmanship can be found in managing size. As decisions are made craftsmanship often provides guidance so that progress can be sustained.  Brooks uses the example adding new functions as individual items rather than bundles.  Individually controllable functions generally require a larger footprint than a bundle of of the same functions. The understanding of structure and packaging of features by developers (craftsmanship) , allows better management of a constraint.

Innovation requires the radical rethinking of how a constraint will be addressed and leaping past that typical approach to address a constraint. Brooks wrote that “innovation is often a result of strategic growth and bold cleverness” that rethinks the constraint from a different point of view. Changing your perspective is an innovation tool. Brooks identifies representation as a tool for reflection and introspection that can lead to innovation. Representation a method of thinking about and modeling both the logic and data rather than just the logic. For example, when considering a constraint, consider the representation of the data required by a function to identify a different way to accomplish the function.

In this essay Brooks was focused on constraint of size. Most programmers will not need to address size as constraint; however, every effort has some type of constraint. Constraints might include functional performance, transaction speeds, a delivery deadline or disk space. Constraints are a fact of life that need to be recognized and managed. While controlling and budgeting for constraints can be avoided, constraints can also be used to provide the impetuous to link the whole effort together. Goals and budgets provide a platform for an architect (or a similar role) to champion the big picture so that team don’t sub-optimize the whole application to meet their own need. Constraints also generate the energy needed to search for innovative solutions. Constraints, whether size or any other constraint, don’t have to be enemy in any effort.

Previous installments of the Re-read of The Mythical Man-Month

Introductions and The Tar Pit

The Mythical Man-Month (The Essay)

The Surgical Team

Aristocracy, Democracy and System Design

The Second-System Effect

Passing the Word

Why did the Tower of Babel fall?

Calling the Shot

A dam releasing water is an  example of flow through a constraint.

A dam releasing water is an example of flow through a constraint.

The Theory of Constraints (ToC), as defined by Eli Goldratt in the book The Goal (1984), is an important concept that shapes how we measure and improve processes.  ToC takes a systems thinking approach to understanding and improving processes. A simple explanation of ToC is that the output of any system or process is limited by a very small number of constraints within the process. Kanban is a technique to visualize a process, manage the flow of work through the process and to continually tune the process to maximize flow that can help you identify the constraints. There are three critical points from the ToC to remember when leveraging Kanban as a process improvement tool.

  1. All systems are limited by a small number of constraints. At any specific point in time, as work items flows through a process, the rate of flow is limited by the most significant constrained step or steps. For example, consider the TSA screening process in an Untied States airport. A large number of people stream into the queue, a single person checks their ID and ticket, passes them to another queue where people prepare for scanning, and then both people and loose belongings are scanned separately, are cleared or are rescanned, and finally the screened get to reassemble their belongings (try doing that fast). The constraint in the flow is typically processing people or their belongings through the scanner. Flow can’t be increased by adding more people to check IDs because that is not typically the constraint in the flow. While each step in a process can act as a constraint based on the amount of work a process is asked to perform or if a specific circumstance occurs (the ID checker has to step away and is not replaced, thereby shutting down the line), however, at any one time the flow of work is generally limited by one or just a few constraints.
  2. There is always at least one constraint in a process. No step is instantly and infinitely scalable. As the amount of work a is being called on to perform ebbs and flows there will be at least one constraint in the flow. When I was very young my four siblings and I would all get up to go to school roughly at the same time. My mother required us to brush our teeth just before leaving for school. The goal was to get our teeth cleaned and out of the bathroom so that we could catch the bus as quickly as possible. We all had a brush and there was plenty of room in the bathroom, however there was only one tube of toothpaste (constraint). One process improvement I remember my mother trying was to buy more tubes of toothpaste, which caused a different problem to appear when we began discussing who’s tube was who’s (another constraint). While flow was increased, a new constraint emerged. We never found the perfect process, although we rarely missed the bus.
  3. Flow can only be increased by increasing the flow through a constraint. Consider drinking a milkshake through a straw. In order to increase the amount of liquid we get in our mouth we need to either suck on the straw harder (and that will only work until the straw collapses), change the process or to increase capacity of the straw. In the short-run sucking harder might get a bit more milkshake through the straw but if done for any length of time the additional pressure will damage the “system.”  In the long run the only means to increase flow is either change the size of the straw or change the process by drinking directly from the glass. In all cases to get more milkshake into our mouth we need to make a change so that more fluid gets through the constraint in the process.

The Theory of Constraints provides a tool to think about the flow of work from the point of view of the constraints within the overall process (systems thinking).  In most process, just pushing harder doesn’t increase the output of a process beyond some very limited, short-term improvement. In order to increase the long-term flow of work through a process we need identify and remove the constraints that limit the flow of value.

IMG_3635The work performed to develop, test and implement any software package is a process flow. Not every team or organization will follow the same flow. Many factors can influence the flow of the work in order to deliver maximum value. Kanban is a popular technique to help a team or organization visualize, control and improve the flow of work so that more value is delivered. Kanban is especially valuable because the visualization exposes bottlenecks and constraints. When applying Kanban, one of the values implicit is adopting wait and see approach to making process changes.  In Kanban, you only make changes when data exposes a constraint or bottleneck. The determination of whether any flow problem is a constraint or bottleneck will affect how they are solved. While similar, bottlenecks and constraints are different and these differences drive how we address them.

A bottleneck is a resource that has a capacity that is less to demand placed on that resource while a constraint is a physical factor that limits performance. Applied to the typical software development or enhancement project, resources typically reflect the amount of effort people can apply. A tester with a backlog of 100 hours of testing to perform would be a bottleneck.  In the same development environment, an example of a constraint would be if the organization had one system testing environment and two teams wanted to use that at the same time and could not due to systemic conflicts. The limitations in the environment would be a constraint. Bottlenecks can be solved by changing or adding resources while constraints require changing the environment as part of changing resources.

Our poor tester is saddled with a backlog of 100 hours of testing.  The backlog reflects a work in progress that is sitting, waiting to be tested to determine whether the code works and meets business requirements. Defects in that code can potentially impact other work that is currently waiting to be tested, currently being coded or work that has previously tested, therefore waiting to test delays feedback.  Two simple changes can be made to improve flow.  The first is slow the amount of work coming to the tester so that work gets to the tester just when it can be tested (reduce the amount of code being written or changed) or increase the number of testers (real or virtual). To remove the bottleneck the organization could reduce the amount of work that needs to be tested or increase the capacity of testing by adding tester. Bottlenecks can be solved by adding, rearranging or reducing resources used in the overall process without changing the environment..

In the article Kanban: Process Improvement and Bottlenecks we used the metaphor of water pouring from a bottle to visualize bottlenecks.  The neck of the bottle is a constraint. If the goal was to improve flow would need limit the amount of water entering the neck of the bottle or remove the constriction.  Adding more neck to the bottle would not affect the flow positively.  In our testing environment example, in order to improve the flow and reduce waiting we would either have to plan project work better so that only one group wanted to use the environment at a time or make a physical change to the test architecture by adding a second (or perhaps more) system test environment.  In order to solve constraints the environment must be changed to solve the flow issue (other resources may also be changed in addition).

Note – Either case requires an overall systems view of the development and enhancement process used by the organization or team. This ensures that removing one constraint or bottleneck just doesn’t create another!

The difference between bottlenecks and constraints may seem to be overly nuanced however understanding that a constraint can be addressed by adjusting resources whereas a bottleneck will require physical changes to the environment is critical to ensuring effective change.

 

Cemetary Angel

We spend a lot of time memorializing the past. Celebrating lives, successes and remembering what has gone before. In many cases remembering helps us avoid the mistakes of the past. The problem is that the many ideas and innovations of the past were one time events or were built on attitudes and behaviors that changed. The Internet will not be invented again and the idea that the world is really flat is not going gain traction again. Holding on to ideas and attitudes based on outdated premises will rob you and your organization of value.

Remember and learn from the past but recognize that the past is just that, past. New ideas might need to be shaped by the past but ultimately the constraints applied must reflect the world as it is today and will be tomorrow.

Lots of Avacados

Abundance sounds great.  If you are making guacamole for a Super Bowl Party then standing next to the avocado bin at Whole Foods would make the process easy.  Without constraints we would never need to dig deep to find a solution to overcome those constraints.

Unlike making guacamole at Whole Foods most of us face constraints.  Normal constraints include too few resources, not exactly the correct tools or not having perfect information.  The academic literature has documented that some constraints can help drive innovation but there is very little evidence that abundance improves innovation.

My wife always asks why the witches and warlocks shown in the Harry Potter movies seems stuck in the middle ages,  does their “magic” cause abundance?  Don’t let constraints hold you back rather think of them as an invitation to innovate.