What’s with the Chicken?

Yaacov Apelbaum-Chicken

Over the past 50 years, quality and optimization have bloomed into a mature set of practices that are now leveraged in almost every industrial and manufacturing environment. Six Sigma and TQM are just two good examples for such practices. In manufacturing, unlike software development, the relationships between project schedule, component quality, and order of assembly are clearly defined and optimized (i.e. unnecessary motion is reduced.).

For team working on an automotive assembly line, the practice of stretching deliverables to the extent possible (so long as the assembly line continues to move) is legitimate. Unfortunately, this is not the case in software development.

As product development evolved from mechanical devices to complex software packages, some previously benign scheduling habits have become vices. One such transgression is the practices of the "Schedule Chicken". And no, this does not refer to the cafeteria’s daily practice of serving charred poultry. The origin of the term comes from 1950’s and has been documented in the movie Rebel Without a Cause. In it, two drivers are racing their hot-rods and are supposed to jump out just before their cars go over the cliff.

The first one to jump out of the car is labeled a “chicken” while the one closest to the cliff’s edge wins bragging rights. From the psychological point of view, it is interesting to note, that the rational for the "Schedule Chicken" behavior is related to the Hawk-Dove method of conflict used by players in game theory. The software development equivalent of this occurs when two or more areas of a product team claim they can deliver their features at an unrealistically early date because each assumes the other team is stretching the predictions even more then they are.

This pretense continually moves forward past one project checkpoint to the next until just before the functionality is actually due. The more mature "Schedule Chicken" practitioner will often delay addressing the obvious for as long as possible, hoping that someone else will hit the breaks and stop their car first. The ceremony in which the team lead finally admits that he can’t deliver the features on time climaxes in a primeval ritual that is reminiscent of ancient Aztec human sacrifices, albeit it’s somewhat more painful.

In the end, it is very difficult for the failed team to recover from being behind schedule, because once the truth is out, all other teams will blame them for the delay. Even if they actually do end up beating the deadline (which is highly unlikely), it will be forever impossible for them to remove the associated stigma of having been “chickens”

So how do you combat the chicken? Here are my top indications that your project has possibly been infected with an avian flu:

1. While discussing the production schedule people use terms like guesstimating and SWAG

2. The proposed schedule is not based on a documented matrix of previously developed products

3. In private conversations, cross team members challenge the validity of their own schedules

4. The team hopes to make up for lost time by adopting silver bullet tools or technologies

5. The amount of code necessary and it’s complexity do not match available development resources

6. Failed smoke tests, quality of builds, and bug bounces do not match the published  status reports

7. The team is opting to build low level functionality rather than buying it and is insisting that this will actually help accelerate their delivery

8. Development teams are regularly burning the midnight oil, are putting an exceptional amount of overtime and appear to be worn-out

9. Project stake holders are starting to use e-mail for the creation of a "legal trail"

10 Team leads are showing compartmentalized understanding of the project and are unable to walk through all of its dependencies (for example, they may be insisting that it’s not necessary for them to thoroughly understand other team’s implementation details or how the entire solution is going to work)

11. Project leadership continues to commit itself to unrealistic deliverables like “zero critical bugs” or significant performance improvements, despite having priority bugs and stability issues.

The practice of Schedule Chicken may seem harmless and in some cases may even be encouraged because it promotes survivalist behavior, but in fact, if left unchecked it can have long term devastating psychological effects on the entire team and its ability to develop efficiently.

From my experience, the best mechanisms for combating the chicken are to demand open and honest communications, insisting on peer reviews, and maintaining deep visibility into all project activities.

This is not a simple task as it may goes against the grain of the entire organization but in the end, it beats the alternatives of failure and the blame game.

© Copyright 2010 Yaacov Apelbaum All Rights Reserved.

Advertisements

The Überteam

Yaacov Apelbaum-The Team

A High Performance Team in Action

It’s tempting to view all development teams as homogeneous masses that operate with equivalent efficiency. When looking for ways to improve our team productivity, we tend to overlook the human factor in the equation and either embrace new management methodologies or focus on incrementally improving some existing processes (i.e. requirements management, bug tracking, etc.).

Certainly, there is always room for process optimization and by doing so, we can probably realize some additional efficiencies. But ultimately, these actions will translate to a relatively small enhancements to the team’s overall performance.

In order to realize an order of magnitude improvement, we need to focus on the cornerstone of the technology and development process, the “individual”. It has been shown in numerous studies (e.g. Steve McConnell’s Rapid Development) that different teams within the same organization can have significantly varying delivery efficiencies.

So how do we explain the formation of islands of excellence within the same organization? After all, don’t all teams within the company share the same HR resources, training, tools and culture?

The short answer is that operational excellence has a lot to do with management style, team structure, and makeup. Let me explain.

Building and managing strong development teams goes beyond the simple managing of developers to quarterly objectives and delivering functional products. What sets apart a high performance team from the garden variety team is that in addition to delivering acceptable products, the high performance team tends to exhibit more loyalty and less splintering. It works smarter, is more creative, is more cohesive and its members are more independent. A high performance team has certain qualities and a distinct spirit which emanates from the individuals in the team.

A high performance team’s esprit de corps is derived from a strong sense of individual belonging, common culture and shared vision. Building and managing this type of a team requires a clear definition of the team’s identity, documented history of success (and failure!), the cultivation of elitism (i.e. an aggressive selection process which makes team membership a coveted privilege), stoking the competitive fire (identifying the competition and targeting it), striving for being different than others and having a reputation for taking on and delivering difficult assignments. Above all, it should be a fun and intellectually rewarding environment.

Even though high performance teams are independent of project type and technology (they are certainly not limited to early stage startups), they all share certain characteristics. I call these the Seven Golden Habits, they are:

  1. Preach and Practice Honesty and Integrity – Always insist that all team dealings and communications (internal and external) be honest and open. The primary building block of all human relationships and the cornerstone of good leadership is integrity (both professional and personal), so you must show personal integrity (in moral decisions always follow the "Et si omnes ego non" principal) and instill its importance in your directs and their team members. You can always explain incompetence and overcome it. Not so with dishonesty and poor integrity.
  2. Promote Proficiency and High Technical, Operational and Personal Standards – Place strong emphasis on recruiting bright and talented individuals who are passionate about their work and are domain experts. Demand that each team member provides leadership in one or more areas. Work with each team member to develop customized training and professional growth plans and make sure that each has a clearly defined career path that goes beyond basic corporate training (plans for an advanced degree, leadership opportunities, professional certifications, etc.). Inspire them to continually learn so as to further excel. Organize training in emerging technologies, standards and best practices. Promote industry visibility for team members by encouraging them to present papers at conferences and to publish. Public visibility for individual members = visibility for you and the entire team.
  3. Emphasize Accountability and Responsibility – Carefully delegate responsibility and provide your directs and team members with ample opportunities for exposure and high visibility success. Never micro manage! At the same time, expect all assignments to be completed promptly and with a high level of quality. Do not tolerate procrastination and repeated failure to deliver projects on time, over budget or with inferior quality. Provide talented team members with frequent leadership opportunities. Generously give credit where it is due and swiftly sanction habitual underperformers.
  4. Promote Cultural Diversity, Sociability and Friendliness – Recruit heterogeneous individuals (promote cultural, racial and gender diversity). Consider the stimulating exchange of ideas between team members critical for team success as well as for your own personal growth as a manager. As such, encourage the establishment of forums and strategies to build strong collaborative teamwork, some of which may include: inner team mentoring and tutoring, brown bag technical luncheons and sponsorship of after work activities. Do not tolerate any abusive behavior within your team. Get to know each team member personally. Learn about their hobbies, their family and their personal concerns.
  5. Stop the Buck and Delegate – Serve as a single executive focal-point for your management and directs (handling both inbound and outbound escalations). Build, motivate and promote inner team leadership and a successful culture that is based on mutual benefits. Empower direct reports to contribute to the development strategy, while insuring that their action plans and implementations are based on the official strategic goals and well defined market opportunities.
  6. Develop a Competitive and Rewarding Workplace – Institute spot cash bonus programs and prizes (gift cards are a favorite), permit a certain amount of telecommuting when possible, subsidize technical books, on-line education, and hardware and software for personal use, place strong emphasis on social bonding (including after work hours activities and membership in online social networks).
  7. Deal with Ambiguity Effectively – Due to their intangible nature, ambiguity and uncertainty can have devastating effects on any development team. Ambiguity tends to increase with project size and complexity and can stem from many sources that may not be under your team’s control (i.e. budget, schedule, requirements, technology, strategy, etc,). You should expect ambiguity as a given and develop approaches to elevate and counter its effect on your team’s ability to shift gears quickly without having all the facts.

    Some of the coping techniques I have used to deal with ambiguity include:

  • Avoid "analysis paralysis" and “deadlocks” – Even though most of us subscribe to a structured, orderly and predictable management methodology, in the absence of more information, you should feel comfortable relying on your team’s advice as well as your personal experience and intuition to reach a decision without endlessly pondering all of the options.
  • Keep clear from the tried-and-true trap – Under conditions where the work threatened by various conditions of uncertainty, traditional solutions may not be feasible, you should push the team to innovate, think out the box, and take prudent risks to insure that business objectives are met.
  • Manage the effects of ambiguity on the team – Understanding the relationship between anxiety, impatience and uncertainty, you should work to develop an effective communication plan and control the effects of uncertainty on the team by: providing daily communication (meetings, e-mails, briefings, etc.), fighting rumors, requiring every team member to provide constructive suggestions, eliminating team splintering and factioning, speaking externally with a single voice, and avoiding finger pointing and blame.

These rules work well whether you are first forming a new team or transitioning forward a mature (and perhaps stubborn) one. Whatever the constellation of your corporate environment and culture is, these are tried and true methods that will yield significant improvements in operational efficiency and product quality.

Contrary to the old adage, you certainly can (and should!) teach an old pooch new tricks.

Good luck!

© Copyright 2008 Yaacov Apelbaum All Rights Reserved.

It’s All About Trust

Yaacov Apelbaum-Trust me

Mata Hari and Friends (Robert Hanssen and Aldrich Ames)

Over the years, I’ve had this recurring conversation\argument with security technologists regarding the trust lifecycle. The crux of it revolves around how you go about effectively assigning, monitoring and adjusting individual trust levels. Most of us when questioned about trust will tell you that it’s made up of behavioral elements like:

Indeed, these are all virtuous traits, but how do we use them in designing a complex security infrastructure? After all, it’s hard to code a function that will check if a user has a hidden agenda. In order for these social concepts to be of any use, we need to understand the nature of trust; we must go "Beyond good and evil”. Under the microscope, trust exhibits the following four characteristics:

  1. It’s transferable—We assign a higher degree of trust to individuals who come recommended by people we already trust,
  2. It’s inheritable—we tend to trust a relative of a trusted friend,
  3. It’s socially derived—We tend to trust individuals who share our cultural heritage,
  4. It’s cumulative—We tend to increase our trust levels in individuals who previously have proved themselves trustworthy.
    These evaluation criteria (which, interestingly enough, are essentially deterministic Turing tests) work very well in social relationships, but frequently fail in complex security infrastructures. The source of the problem is that most of us instinctively tend to classify the world into a “friend”, “foe” or “unclassified TBD” categories. We also like to believe that once categorized, the subject in question will continue indefinitely to conform to our classification. This simplistic tendency is hard wired into our evolutionary decision making process and to a large degree also forms the basis for many irrational behaviors like anti-Semitism.

After conducting quite a few security sweeps and post mortems, I have come to conclude that most individuals—given the right opportunity and enough curiosity—could spontaneously flip the color of their “hat”.

The concept of credential-based security (that is, non-expiring clearance) is reminiscent of cheese, especially the cheap Swiss variety, the one with too many holes. Now, don’t get me wrong I have the same tolerance for curious mice as the next guy, but the text books are full of big rats that were—paradoxically—supposed to guard the cheesy comestibles, not eat or sell them! Recall that Aldrich Ames, Robert Hanssen and Kim Philby, just to name a few, each had the highest top-secret clearance and all the right personal and social attributes.

So ultimately, it’s not the rogue, external, blood thirsty anarchists or money hungry crackers one needs to worry about. Rather they are the trusted senior employees responsible for the daily maintenance, administration and security of the corporate resources. This could run the gamut from as high as the CISO who spies on the CEO’s e-mail all the way down to DBA who is running Select statements on the HR comp database.

The lesson that I have learned from all of this is that most people regardless of how trustworthy they seem, cannot be completely trusted at all times.

And you can trust me on this one.

© Copyright 2008 Yaacov Apelbaum All Rights Reserved.