Personality Matters- Ops and Learned Helplessness

+
-
0
Personality Matters- Ops and Learned Helplessness

Personality Matters- Ops and Learned Helplessness
By Leslie Sachs

The recent series of high-profile system glitches have increased focus on the role of IT operations and other key personnel in maintaining a stable and reliable system environment. The technologies involved are obviously complex with many moving parts, any of which could be responsible for a system crash, potentially impacting thousands of users and ultimately the company itself. Some organizations foster a highly effective environment where employees feel empowered to always do the right thing. Unfortunately, some organizations have a very dysfunctional culture that results in employees who do not believe that they can be effective and, worse, are not motivated to take appropriate action when serious incidents do occur. Instead, they focus on protecting themselves and ensuring plausible deniability. Dysfunctional operations teams are often a consequence of a dysfunctional organizational culture that breeds distrust and results in employees who just sit back and allow disasters to occur. What kind of organization do you want to work in and, if you are in a leadership position, what kind of organization do you want to help shape?

The majority of high-profile systems incidents – from the reliability-challenged Obamacare website, healthcare.gov, to outages impacting numerous trading firms and trading exchanges – have almost all had one thing in common: published reports indicating that technology professionals warned of issues and problems that resulted in risks and potential systems outages. These warnings were largely ignored, or even overruled, by senior officials who had the positional power to make decisions that ultimately led to disasters. No doubt many of the technology professionals who spoke and tried to warn of impending danger were frustrated and discouraged seeing that their alarm went unheeded as they watched helplessly while serious incidents threatened their jobs and the very existence of the company that they worked for. It is certainly difficult to be optimistic in these circumstances.

Martin Seligman is credited with developing a new branch of psychology that focuses on promoting the type of positive behavior that helps to create effective teams and leads to successful results. We will be writing much more about Positive Psychology [1] in future articles, with a view towards helping you lead your organization, including the technology professionals who are on call all hours of the day and night running your systems operations, towards success and productivity . Dr. Seligman was born in 1942 in Albany, New York and received his Ph.D. in psychology from the University of Pennsylvania. Even before his work on Positive Psychology, Seligman was quite well-known for his work on Learned Helplessness [2]. In order to really appreciate the importance of Positive Psychology, we need to first understand learned helplessness.

In early studies on Learned Helplessness, dogs, who were used in the study, reacted to events that were beyond their control by apparently accepting the inevitability of their fate and actually stopped trying to prevent bad things (such as an electronic shock) from happening. Similar studies involving other animals, as well as some including college student volunteers, yielded similar results, thus providing more support for the assertion that some people (and animals) just stop trying to overcome problems when they learn that there is no point in attempting to prevent such incidents from occurring. Related dysfunctional behavior included cognitive learning deficits and depression. In other words, the results suggest that subjects who have learned to be helpless essentially give up trying, have difficulty learning and are depressed about their situation. So how did IT get to this unacceptable situation and how can we help our teams overcome learned helplessness?

Operations teams may find that they do not have the required training, procedures, and knowledge available to be effective at identifying and addressing issues when they occur. Development teams may themselves find that they have to write complex software without well-defined requirements and testers may feel that they just don’t get enough time in order to really ensure that the software is free from defects. Published reports indicate that all of these issues occurred with regards to the much-publicized release of the healthcare.gov website. Technology professionals involved with this effort have indicated that requirements shifted late in the process, warnings about system reliability went unheeded and essential security testing was not completed due to a lack of sufficient time. When warnings such as these are ignored, it is no wonder that some professionals become discouraged and resigned to the fact that the system just won’t work as required.

A related problem is management’s often dysfunctional reaction to honest mistakes. Many organizations punish employees severely for serious mistakes, creating a culture where employees are afraid to step forward and admit when an error that could potentially impact the systems and the organization has occurred . Successful organizations understand that mistakes can be acceptable (and even good) if people learn from them. Quality guru Joseph Juran referred to mistakes as “gold in the mine” [3] a reference to the value that comes from a lesson learned. You want your employees to be willing to step forward and admit when they have made a mistake and then you want the entire team to refrain from finger-pointing and help address the problem.

Successful organizations ensure that their employees believe that they can be successful and feel empowered to identify and report risks. Senior management values their input and responds to the advice of the technology professionals who are most knowledgeable and capable of assessing potential issues. If you want your organization to be successful, you need to ensure that you drive out any aspect of learned helplessness and embrace a positive culture that enjoys a can-do attitude!
References:
[1] Seligman, Martin, Authentic Happiness: Using the New Positive Psychology to Realize Your Potential for Lasting Fulfillment, Free Press, New York 2002
[2] Abramson, L. Y.; Seligman, M. E. P.; Teasdale, J. D. (1978). “Learned helplessness in humans: Critique and reformulation”. Journal of Abnormal Psychology 87
[3] Harvey Robbins and Michael Finley, Why Teams Don’t Work – What Went Wrong and How to Make it Right, Peterson’s Pacesetter Books, 1995, p. 87
[4] Aiello, Bob and Leslie Sachs. 2010. Configuration Management Best Practices: Practical Methods that Work in the Real World. Addison-Wesley Professional.

jfrog CTO Yoav Landman

+
-
0

jfrog’s Chief Technology Officer Yoav Landman is interviewed by Bob Aiello

 

 

 

 

 

 

 

Training Video:: Bob Aiello On Understanding DevOps

+
-
0
Training Video:: Bob Aiello On Understanding DevOps

Personality Matters—CM Top Down or Bottom Up

+
-
0

Personality Matters—CM Top Down or Bottom Up
By Leslie Sachs

Configuration Management focuses on software process improvement in many important ways. This can include software configuration management along with application build, package and deployment. Some organizations are more open to change than others. If you want to be successful at bringing about positive change then you need to be able to assess and understand the personality of your organization along with identifying the key change agents who can help you get the job done. This article will help you get started.

Organizations have cultures that foster many traits that are often associated with specific personality types. For example, some organizations (e.g. hedge funds) are very insular with a strong air of secrecy. Others may promote an overt theme of creativity and exceptionalism. Individuals and teams within the organization also have identifiable personalities, which may be in alignment with the corporate culture or at odds with the status quo. Being at odds with the existing culture (and environment) is not always bad, but may impact how you are perceived by others, and ultimately your effectiveness. As Jurgen Appelo notes “a person’s behavior is a function of his or her personality and the environment.” [1]. Jurgen further notes that, “without the right team personality, it is hard to get any creativity out of a team.” [2]

To bring about change you need to assess and understand the culture of the organization and also the personalities of the teams (and team members). Keep in mind that there are many factors that may impact how a team operates – and each of the members, too. For example, some people operate solely as individuals and others are far more focused on being in alignment with the other members of the group. In psychology, there has been a tremendous amount of research on how individuals and teams operate. For example, “in many Asian cultures, personality is constructed on the basis of an alternative model of the person as interdependent. In these cultures, then, personality is experienced and understood as behavior that is characteristic of the person in relationship with others in particular social contexts.” [3] Understanding how the team and the organizations views itself is essential for bringing about positive change.

Bringing about positive change in many organizations must be a top-down endeavor with all stakeholders being given a clear directive by senior management. However, this is not always sufficient as some members of the team may be very skeptical having heard senior management make similar, or unfulfilled, proclamations in the past.
In our book on configuration management best practices[4], we discuss at length the importance of understanding team dynamics as a prerequisite to overcoming resistance to change. Make sure that you match your process to the culture of the organization. For example, some organizations really require a full explanation for the reason for any change in order to have the new rules or procedures be viewed as acceptable and fair. If you do not approach change in this manner, don’t be surprised when some members of the team show a creative ability to circumvent your proposed change.

Taking baby steps works well in some environments and others require a clear directive from senior management. My advice is to spend the necessary time speaking with key change agents and to carefully align your proposed changes with the existing culture.
Some traits to consider within the organization often mirror personality traits found in people. For example, conscientiousness and openness to other cultures are traits that are measured within the so called “big five” personality traits. [5] Understanding the people side of the organization will always help you design effective processes and procedures that are more likely to be accepted and implemented to bring about positive change.

Conclusion
Many organizations have clear and distinct cultures. The teams and individuals within them may also have specific personality traits that can impact how they operate within the existing ecosystem. If you want to bring about effective change then you need to align your efforts with the existing people and personalities that make up the organization.

References
[1] Appelo, Jurgen, Management 3.0 – Leading Agile Developers, Developing Agile Leaders. Addison-Wesley, 2011, p. 287
[2] Appelo, Jurgen, Management 3.0 – Leading Agile Developers, Developing Agile Leaders. Addison-Wesley, 2011, p. 64
[3] The Cultural Psychology of Personality – Journal of Cross-Cultural Psychology January 1998 29: 63-87
[4] Aiello, Robert and Leslie Sachs. Configuration Management Best Practices: Practical Methods that Work in the Real World. Addison-Wesley, 2010

Personality Matters— Personality and CM Strategy

+
-
0

Personality Matters— Personality and CM and ALM Strategies
By Leslie Sachs

Effective collaboration, the central goal of any CM or ALM strategy, is dependent upon both strong communication and cooperation. If you have been involved with any technology-related efforts then you will instantly recognize how often teams struggle with effective collaboration, communication, and cooperation. Successful managers learn how to deal with these challenges and help their teams smooth out the conflicts that often threaten to disrupt the team’s effectiveness. This article will discuss several of the key “people” issues that you should consider when implementing CM and ALM strategies.

CM or ALM – Which Comes First?
Configuration Management (CM) is a broad discipline that touches every aspect of the software and systems lifecycle. Application Lifecycle Management (ALM) actually takes an even broader view and often requires working between teams or even divisions within an organization. It is hard to say whether you need to focus first on CM or ALM and perhaps, for our purposes, it doesn’t matter. What does matter is that we address the personality-based challenges of implementing CM and ALM strategies. Let’s start by considering how we lay out the work.

Laying Out The Work
Robust ALM solutions facilitate communication by automating the process of specifying and assigning work to each member of the team. This is usually done through creating Change Requests (CRs) or work items including tasks, defects and requirements. Laying out the work in this way is the first step in any successful CM or ALM strategy. This provides the clarity and transparency which is a fundamental prerequisite to any successful effort. Once you have a clear idea of the work required, you should consider some of the inherent group dynamics.

Groups Have Personalities Too
The behavioral norms of any group will have a significant impact on the way in which you can implement CM and ALM strategies. Obviously, understanding the various personalities in your team is essential. However, many managers completely miss the fact that groups have personalities, too. The key is to understand your own behavior within the context of the environment that you are working in. Once you understand that you and your team are operating within a context, you can best navigate the challenges that are inherent within the group. Whatever context you find yourself in, coordination will make the difference between success and failure.

Coordination
Coordinating the work involves ensuring that every member of the team knows precisely what they need to do on any specific day. Most organizations are mired in the chaos of not being able to coordinate their activities. Coordination is equally as important as collaboration.

Collaboration
Many teams are very challenged when it comes to being effective at collaboration. We see this problem in many different organizations. The opposite of Effective Collaboration can sometimes be described as a competitive game of “Volleyball”, where teams simply try to send the ball over the net to each side (shifting responsibility). In Configuration Management Best Practices: Practical Methods that Work in the Real World (Addison-Wesley, 2010), I discuss that the only way out of this dilemma is to consistently and conspicuously reward effective collaboration between the two groups. [1]

Communication
Communication is fundamental and you need to have both formal communication plans for long-term goals, as well as strategies for handling day-to-day communication challenges. Delivering the message is only the first step. You also need to consider the dynamics of competition and cooperation. Styles of communication can either help your team be more effective or result in them being mired in dysfunctional dynamics. This is often related to competition between members of the team. Most forms of competition are very distracting and counter-productive, but some mild-and good-natured rivalry can occasionally inspire creativity and progress.

Competition and Cooperation
As Jurgen Appelo points out, competition and cooperation are found among many species and illustrated by the behavior found in different species that exhibit a type of “selfish cooperation” that is counter-intuitive, although highly pragmatic. [2] This type of behavior is often found in cross-functional teams. Your job is to keep the interactions constructive and the mission of the team on track.

Cross-functional Teams
Agile practitioners are certainly strong proponents of self-managed cross-functional teams. The truth is that cross-functional teams have been around for a long time. Cross-functional teams have specific requirements for their success. Successful cross-functional teams display coordination across team boundaries about practices, standardization, and shared resources. [3] Cross-functional teams also rely upon effective communication and coordination to make sure that the various components are working toward a common goal.

Communication and Coordination
“The Purpose of Communication and Coordination is to establish timely communication throughout the organization and to ensure that the workforce has the skills to share information and coordinate activities efficiently.” [4] Communication and coordination are implicit in establishing effective CM and ALM-related activities and also play an essential role in helping to foster cooperative behavior.

Cooperative Behavior
Helping your teams to be more collaborative will help improve cooperative behavior. Tom Tyler notes this in his book, Cooperation in Groups, “It would be hard to overemphasize the importance of the level and type of cooperative behavior engaged in by group members in shaping the extent to which groups can function efficiently, effectively and, ultimately, successfully.” [5]

Conclusion
Effective collaboration, communication, and cooperation are essential for the success of any endeavor. Good managers model and encourage the interpersonal skills required to help an IT team be successful. Taking into consideration the personality of the group, as well as, each of its individual members will help you design strategies for effectively implementing CM and ALM. Focusing on effective collaboration, communication, and cooperation are essential ingredients for establishing successful CM and ALM strategies.

References
[1] Aiello, Robert and Leslie Sachs. Configuration Management Best Practices: Practical Methods that Work in the Real World. Addison-Wesley, 2010, p. 153.
[2] Appelo, Jurgen. Management 3.0. Addison-Wesley, 2011, p. 262.
[3] Appelo, Jurgen. Management 3.0. Addison-Wesley, 2011, p. 292.
[4] Curtis, Bill et al. The People Capability Maturity Model. Addison-Wesley, 2002, p. 136
[5] Tyler, Tom and Blader, Steven L. Cooperation in Groups. Psychology Press, 2000, p. 23
[6]  Aiello, Bob and Leslie Sachs. 2016. Agile Application Lifecycle Management: Using DevOps to Drive Process Improvement. Addison-Wesley Professional.

Training Video:: Bob Aiello On CM Best Practices

+
-
0
Training Video:: Bob Aiello On CM Best Practices

Behaviorally Speaking—Release Management and Deployment Essentials

+
-
0

Behaviorally Speaking—Release Management and Deployment Essentials
by Bob Aiello

Managing the release-and-deployment process can be very difficult to accomplish. If your business environment involves risk, then challenges can be even greater, but this is also precisely where you have the greatest potential for reward. I have had some spectacular successes as a release-and-deployment manager and no shortage of painful moments, too. Sometimes, it seemed that I had the magic to tame the most dysfunctional and error prone release and deployment scenario, and other times I couldn’t move the needle and show any significant improvement at all. I have learned a lot from these experiences, and this article discusses what I consider to be the most essentials aspects of effective release and deployment management.

Stepping into the Line of Fire

My approach to fixing the processes around release management and deployment has always focused on stepping right into the line of fire and assuming the role of the release-and-deployment manager. This isn’t always practical, as sometimes I am asked to come in on a consulting basis simply to observe and advise. I have done this job enough times that I often know exactly what needs to be fixed. Unlike most process improvement folks, I really prefer to get hands-on and make recommendations directly from my own experience. That puts me at great risk for failure.

Failing as the Release Manager

When writing the chapter “Mistakes that I Have Made” in my book Configuration Management Best Practices [1], I noted that I could have written a whole book describing my own mistakes. But, the reason that I have been successful in CM is, in part, because I am willing to take risks, which also often leads to my recommendations often being precisely what needs to be done to fix the problem. Understanding release management and deployment essentials is a lot easier when you look at a few failures first.

Knowing When to Ask for Help

I love being hands-on and technical, which is usually the best approach, but technology can be very complex. Developers spend years getting up to speed in different development frameworks and methodologies, yet I may work on automating release management in C#/.NET one day and on IBM mainframe deployments the next. Within the past three months, I have worked on developing release practices for software as a service for customer relationship management (CRM), data warehousing, databases, and complex Java J2EE N-tier applications with WARS and EARS running under a variety of web and application servers. It is certainly nice if you have a development background with the technology that you need to automate, but you also need to know when to ask for help. It is essential for you to ascertain and communicate what you need in order to be successful with the release-and-deployment process.

Involve the Developers

Developers are often very busy and sometimes not very open to being told to do things differently. It may seem prudent to just handle the work yourself, but I have learned that sometimes it is better to share the work with developers and show them that improving the release-and-deployment process is in their best interest. For example, it is essential to have procedures identifying the version of every configuration item (CI). Being able to conduct a physical configuration audit often requires embedding an immutable version ID into the CI. For example, in C++, you usually create a static char variable via a global header file and stamp the version ID at the time of the build. In Java, we tend to create a class that returns the version or, even better, we stamp it into the JAR (WAR or EAR) manifest and provide a method for pulling out this value.

Communicate Early and Often

Effective communication with all stakeholders is also essential in release management and deployment. Ensuring that all stakeholders understand their roles and deliverables is obviously critical, but I have also found that communicating obstacles and challenges can help, especially when seasoned colleagues have experience dealing with these challenges and may even offer to assist.

Don’t Try to Boil the Ocean

Usually, you cannot automate the entire effort overnight. I start by documenting the manual process and then automating pieces, effectively reducing the size of the manual checklist. This is a very pragmatic approach and shows immediate results. Your goal must be to automate the entire deployment pipeline in what some folks refer to as “zero-touch deployments.” Using a deployment framework that provides the structure around each piece of the automation you have created is an effective way to manage this effort.

Moving Upstream

I’ve learned to always move this effort upstream as quickly as possible, in what has become popular with DevOps enthusiasts to call “left-shift”. You will be much more successful if you can provide a service to developers. Release management and deployment usually is required to take over by the time the release is ready for production. It is much better to get involved earlier, when the release is ready for QA and user acceptance testing. Better still is to get involved during the development effort using your automation to build, package, and deploy to development test regions. This is precisely where continuous integration has shown the most value.

Conclusion

Taking some lessons from agile and lean, it’s best to develop your release management and deployment processes in an iterative and pragmatic way. I try to keep my processes as light as possible, with automation that is structured and can be refitted easily as requirements change. I also try to start at the beginning and provide a service to the developers. Release management and deployment practices are essential for your success. Please drop me a line and share some of your own release management and deployment essentials!

 

[1] Aiello, Robert and Leslie Sachs. Configuration Management Best Practices: Practical Methods that Work in the Real World. Addison-Wesley, 2010.

Six Misconceptions of Enterprise Agile

+
-
0
Enterprise Agile: Six Myths to Stop Believing

By: Ruth Zive, Vice President of Marketing, Blueprint Software

Enterprises across all industries are embracing Agile development practices, yet finding it challenging to adapt in a way that works with their environment. Why? “Pure” Agile approaches don’t take into account such enterprise realities as: creating business cases with a well-defined scope to secure funding; including audit and compliance regulations; and considering the broad range of stakeholders beyond the user, such as legal, marketing and operations.

In “The Impacts Of Missed Requirements In Agile Delivery,” Forrester explored the root causes of missed requirements in Agile adoption and the tangible business benefits organizations could achieve with better management tools. 96 percent of respondents reported problems in software development projects due to missed requirements, and 60 percent expected increased customer satisfaction from faster delivery as a result of avoiding missing requirements.

IT and business leaders can make Agile work in the enterprise if they are able to separate myth from reality. Here are the six most common misconceptions organizations need to address when implementing Enterprise Agile practices.

1. Enterprise Agile = no requirements
Critical discovery and scoping up front is still required, though the level of detail can be scaled back to include only what’s necessary to make business-level decisions. But, make no mistake – there are several critical elements that require explicit definition up-front, such as:

• Creating and defending a business case
• Securing funding for the project
• Determining and articulating business needs and objectives
• Identifying business rules
• Conducting stakeholder analysis
• Capturing and analyzing business processes
• Defining the scope of the solution

The business needs information from these elements to make key decisions; they are the foundation for the requirements that will evolve throughout the course of the project.

In an Enterprise Agile implementation, a business analyst can provide just enough detail (and no less) to establish the scope and business needs “up front,” while deferring the remaining detail for later iterations. This directly supports the Agile principle of “simplicity”: minimizing the amount of work done.
2. Agile revolutionizes how you manage your business

Decision makers continue to evaluate projects within the context of comparing costs to value. Project managers are still looking to measure progress against expected outcomes and reduce risk. Each level of management will simply use different data to make similar decisions. For example, a project manager may use a work breakdown structure as the basis for making decisions for a traditional project. However, in an Enterprise Agile environment, product backlog burnup charts will be used as the basis to make the relevant determinations.

3. Well-defined user stories define business needs just fine
There’s certainly a need for user stories; they provide a powerful way to look at the granular pieces of the application – but only from a user’s viewpoint. While crucial, it’s not the only perspective. Other stakeholders such as product managers, executives, finance staff and those who will maintain, operate and support the application have different needs. And many of these needs manifest as non-functional requirements or constraints on the application.

Additionally, user stories aren’t able to provide the different views that the business needs, either by abstracting up many levels to get the big picture or drilling down many levels into the details. User stories alone are limited in their ability to do this, compared to other approaches and techniques.

4. Compliance and audit can be supported by user stories alone
User stories cannot be relied on to ensure that what is developed and deployed will meet or exceed audit and compliance requirements. There are two main reasons for this. First, user stories are temporary. Once implemented, they are discarded. Second, user stories lack any inherent traceability, meaning even if they were kept, there is no direct, easily identifiable link between user story content and specific application features.

Persistent, traceable requirements in the enterprise are needed for audit and compliance reasons – whether driven by internal or external forces. One effective way to accommodate this is with requirements technologies that automate traceability and auditability, ensuring proof-of-compliance and visibility at every stage of the project.

5. We don’t really need business analysis
Some feel that business analysis is a drag on the organization, but underlying this idea is the misconception that business analysis equals requirements definition. And the error in thinking that ensues is: “If, with Agile, we are to do away with requirements up front, then we can do away with business analysis as well.”

Far more than just the collecting of requirements, business analysis involves understanding the business strategy and objectives, finding and eliciting “raw” information from a multitude of sources at different levels, separating the relevant from the irrelevant, and conducting an analysis to deduce a set of business needs and have them validated.

After this understanding and analysis, the requirements definition work can begin. The work of the business analyst is to define and manage requirements and understand their relationship to and impact upon the business before development resources are consumed. In Enterprise Agile, this work remains as important as ever.

6. You won’t need requirements software with Enterprise Agile
Enterprise Agile processes have the best chance of success when they are supported by a requirements application that integrates the Agile development group and the rest of the business..

Abandoning requirements is a recipe for disaster. Instead, Agile should be supported by a purpose-built application configured specifically for Agile environments, one that allows BAs to analyze the business and to evolve a set of system requirements iteratively over the course of the project, always in advance of ‘sprinting’ development teams. This way, it’s not just the business analyst who derives value from requirements tools, but also the business stakeholders and development team. Look for a purpose-built requirements application configured specifically for Enterprise Agile environments.

Creating Agility
People believe all sorts of myths about working with Enterprise Agile, and the resulting confusion can lead to project disaster. Rather than throwing caution to the wind, organizations should adhere to best practices, especially when it comes to traceability, communication, speed and regulatory compliance. However, large, complex IT projects with large teams can be difficult to scale, which is where Agile requirements software comes to the rescue. It helps create sound projects with minimal rework by supporting Enterprise Agile processes.

About the author:
Ruth Zive is a metrics-driven marketing strategist who has worked for two decades serving B2B clients in the technology, healthcare and financial services industries. At Blueprint, Ruth is responsible for product marketing, analyst relations, branding, demand generation and inside sales initiatives.

Behaviorally Speaking—CM, ALM & DevOps Strategies

+
-
0
Behaviorally Speaking—CM, ALM & DevOps Strategies

Behaviorally Speaking—CM, ALM & DevOps Strategies
by Bob Aiello

Configuration Management (CM), Application lifecycle management (ALM) and DevOps are not easy to implement. In our consulting practice, we develop and implement strategies to support CM, ALM and DevOps in many organizations and the truth is that we are not always satisfied with the results (and sometimes neither is the management who brought us in). We have also been very successful, and largely because we came up with a strategy that made sense for the organization where we were implementing these practices. Coming up the right approach is not always easy and we’ve learned a few lessons along the way that we’d would like to share with you in this article.

What is CM?
The Definition of CM is a topic that has triggered many an enthusiastic debate in the old CM Crossroads forums and groups. (Make sure that you jump in and participate right here by registering for an account!) Traditional CM experts will typically answer that CM is:

Configuration Identification
Status Accounting
Change Control
Configuration Audit

This is certainly true, but it can be very difficult to come up with a strategy to implement these practices in a large multi-platform organization. I have presented my own framework for understanding CM in terms of six core functions that I believe more closely represent the way in which CM is actually practiced on a day-to-day basis. [1]

The six functions are:
Source Code Management
Build Engineering
Environment Management
Change Management
Release Management
Deployment

We have many years of experience implementing each of these six functions in large enterprise-wide environments. The first thing that I always focus on is making CM compelling. You need to start by demonstrating how CM can help your organization (especially your development team) create the software (or what CM gurus call configuration items). Don’t expect everyone to just automatically accept (and believe in) the benefits of good CM. But over time, we have seen many folks come to the conclusion that CM practices make sense. Application Lifecycle Management (ALM) may be a little harder to fully grasp. The key to understanding ALM is to first understand the classic CM function called Status Accounting.

Status Accounting
Status Accounting involves following the evolution of a configuration item throughout its lifecycle. The terminology is a little confusing and you are certainly not accounting in the sense of counting rows of numbers. Instead, you are tracking the status of the configuration items that are being created during the development lifecycle. This sounds great now, but then how do you go about doing status accounting? On a practical basis this is exactly what ALM is all about.

Application Lifecycle Management (ALM)
The ALM is essentially the software or systems lifecycle used to create each of your configuration items. This means that CM is (and always) was a full lifecycle endeavor. So another aspect of your strategy has to be to realize that CM and ALM are focused on the entire lifecycle. So then what exactly makes ALM different than the CM function of Status Accounting? In practice, ALM has a very wide scope from tracking requirements to design, test planning, development, all the way to deployment (and even tracking and retiring configuration items that should no longer be in use). Obviously, CM touches many of the same points as requirements, test cases and design documents all need to be under version control as well. ALM also places a strong focus on tools and tools integration.

ALM Tools
Recently, a colleague of mine chanted the common view that the process is much more important than the tools. I used to believe this, but ALM has taught me that tools do matter a great deal and your strategy needs to include a robust tools selection process (e.g. bake off). ALM’s wide focus[2] means that you need to have the right tools (and process) in place to support every aspect of your software and systems development effort. In practice, this has meant implementing requirements tracking tools with integration to test case management systems. There are two essential reasons for this. The first is that requirements should map to test cases (you want to verify and validate your requirements – don’t you?) and the second reason is that incomplete requirements can be supported by well documented test cases. ALM tools need to focus on integrations to provide a complete and robust full lifecycle solution. One benefit of this approach is enhanced IT Governance and Compliance.

 

IT Governance and Compliance
IT Governance is all about providing the essential information that management needs to make the right decisions. These practices are an essential ingredient is seeing the management can make the best decisions with the input of information that is accurate and relevant. There are a number of organizations that provide information on implementing IT Governance including ISACA. Your strategy should include using industry standards and frameworks for guidance. This leads directly to Compliance which usually refers to complying with regulatory requirements. CM and ALM are essential for supporting both IT Governance and Compliance.

Agile and Lean for CM/ALM Strategy
One of the best strategies that I have implemented was using Agile and Lean practices to iteratively develop CM & ALM processes. For example, one ALM solution that I implemented recently has a complex workflow automation template that can be tailored to the individual needs of the team and project. There was no viable choice but to approach this effort in an iterative way. So I actually setup a separate project in the tool to track changes to the workflow automation template itself. I used the ALM tool to develop and implement the ALM tool! Make sure that you realize that implementing CM and ALM is an effort that requires industry best practices in alignment with your organization and culture.

DevOps consists of principles and practices that help improve communication and collaboration between teams that all too often have very different goals and objectives. While the principles are consistent across all projects, the practices may indeed vary from one situation to another. Read more about DevOps here.

Conclusion
CM, ALM and DevOps are essential for the success of any software or systems development effort. There are many lessons learned and effective strategies for success. Obviously, there are also risks that need to be addressed. The best strategy that I have found is to use the same principles that work for your development effort to guide and management the implementation of your CM and ALM functions. This is an excellent strategy that will help facilitate your success and the success of all of your efforts. Make sure that you drop me a line and share your strategies for CM, ALM and DevOps!

[1] Aiello, Robert and Leslie Sachs. Configuration Management Best Practices: Practical Methods that Work in the Real World. Addison-Wesley, 2010.
[2] Aiello, Bob and Leslie Sachs. 2016. Agile Application Lifecycle Management: Using DevOps to Drive Process Improvement. Addison-Wesley Professional

Personality Matters- Paranoia in the Workplace

+
-
0

Personality Matters- Paranoia in the Workplace
By Leslie Sachs

One of the most difficult personality types to deal with is the person who always seems distrustful of others. Sometimes, this lack of trust is well-justified and sometimes it is really a manifestation of some dysfunctional personality issue. Fortunately, you probably won’t find too many severe cases in your workplace where the person is actually so paranoid that they are dissociated from reality. Psychologists sometimes diagnose this mental illness as paranoid schizophrenia, which may require medications and intensive therapy to manage. What is far more common is the borderline personality who manages to operate within a normal workplace environment, but always seems to be a little “off”. Eccentric behavior is not in-and-of-itself a reason to suspect that someone suffers from mental illness, but sometimes the behavior and personality of a co-worker may be so extreme that it impacts other people’s ability to work. This article will help you better understand this situation and suggest a few ways in which you can deal with difficult personality types such as the paranoid.

Harry Stack Sullivan was an American psychiatrist who noted that paranoia may be associated with suspicion, a tendency to blame others and also a heightened sense that one is being persecuted. [1] If you have a co-worker who exhibits some or all of these dysfunctional behaviors then you are not alone. Some folks just have a disposition where they are always expecting the worst from others and, quite often, this tendency may actually result in a self-fulfilling prophecy such that their overly defensive behavior elicits responses from others that actually reinforce their view that someone is always out to “get” them. As Dr. Sullivan noted, it is common for the person to then resort to blaming others in an attempt to protect themselves in what may seem like a silly turf war. Unfortunately, many of these folks take these incidents very seriously and may truly feel that they are being persecuted. These defense mechanisms may be quite destructive to not only the person themselves, but to everyone around them, too.
People who have trust issues often find it difficult to collaborate and cooperate with others. This can make it very tough in a technology organization where everyone has to rely upon each other for specialized expertise. Sometimes, people with difficult personalities actually focus on being experts in a specific technology area that enables them to feel safe because they have complete control and power due to their specialized knowledge and often extensive knowledge of institutional history. However, try not to pre-judge specific situations and consider for a moment that sometimes a little suspiciousness can actually be justifiable and perhaps partially a consequence of a given circumstance.

For instance, there are some organizations that just do not foster trust and collaboration. Employees who work in dysfunctional organizations may understandably exhibit dysfunctional behavior. If you are the new guy on the block, you may not know all of the organizational history and consequently may not fully understand why some employees seem unusually distrustful or have developed other defense mechanisms to defend their turf. One typical example is the organization that attempts to “motivate” their employees through a constant threat of layoffs or other termination. Creating a state of fear does not often result in productive, effective and loyal employees. Some managers use their positional power to try to control and motivate others through fear and intimidation. While respect for authority is important, there are much more effective ways to motivate employees than just fear, including fear of losing one’s job and livelihood.

The middle ground often involves understanding the person within the context or situation that they must function. If you are working in an army during a time of war then you will likely react very differently than if you are working in an internet startup company. So, here are some thoughts on how to navigate these difficult situations. First and foremost, effective communication is essential. If you find yourself dealing with a person who seems unreasonably distrustful, listening carefully to their view is a good starting point. After you have demonstrated an interest in their input, you can share your perspective and try to be clear about what you need. Conflicts in the workplace are often the result of a misunderstanding or even some institutional history that occurred long before you even joined the organization. You should consider who else can help you navigate these waters.

Your own manager may be able to fill you in on what factors have led to this state of affairs. Sometimes dysfunctional behaviors are a consequence of corporate politics, but also consider that there may be some other much more benign factors in place. We all go through life stresses. You may be catching someone as they are trying to handle their “day” job while also dealing with a demanding family situation that would make anyone short-fused. Another possibility is that the person is taking medication for some medical condition that results in behavioral side effects. Employees obviously have a right to privacy, but sometimes managers are made aware of these issues by HR so that the company may be as supportive as possible.

The best organizations consider the needs of their employees and try to provide a workplace that is conducive to success and productivity. Even in such well-run organizations, though, you may encounter difficult personalities. Hopefully, you won’t have to deal with too many people who are truly paranoid, but you will probably encounter at least a few colleagues during your career who seem remarkably distrustful, blame others and seem to believe that they are truly being persecuted. These situations are never easy and your best approach is to try to communicate effectively, if possible. The goal is to demonstrate understanding of their position while explaining your needs, as well. When possible, reach out to your own available resources – from your manager, and, in extreme cases, to HR. I know of one case where an employee who was on medication was actually physically threatening other employees. The workplace must be free of hostile and disruptive behavior from both a legal and business perspective. Feel free to drop me a line if you come across challenging situations that you would like us to address in future articles. The best work environments are both productive and respectful of their employees and, with good communication, you should be able to navigate successfully even when confronted with some difficult personalities!
References
[1] Harry Stack Sullivan, Personal Psychotherapy Early Formations, W.W. Norton & Company, Inc., 1972
[2] Meyer Friedman, Type A Behavior: Its Diagnosis and Treatment (Prevention in Practice Library). Springer 1996
[3] Harvey Robbins and Michael Finley, Why Teams Don’t Work – What Went Wrong and How to Make it Right, Peterson’s Pacesetter Books, 1995
[4] Aiello, Bob and Leslie Sachs. 2010. Configuration Management Best Practices: Practical Methods that Work in the Real World. Addison-Wesley Professional.
[4] Byrne, Donn. 1974. An Introduction to Personality: Research, Theory, and Applications. Prentice-Hall Psychology Series.
[5] Appelo, Jurgen. 2011. Management 3.0: Leading Agile Developers, Developing Agile Leaders. Addison-Wesley Signature Series.

1...456...10Page 5 of 10