Personality Matters- Ops and Learned Helplessness

0

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

 

 

 

 

 

 

 

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.

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

Personality Matters- The Danger of Agreeable People

0

Personality Matters- The Danger of Agreeable People
By Leslie Sachs

Technology professionals often need to get along with some interesting personalities. While sales and management professionals pride themselves on their people skills, some technology geeks find it challenging to deal with others, especially those with noticeable quirks. I work closely with a number of interesting personalities in our consulting practice- including our lead principal consultant, a well-known expert in configuration management. Truth be told, sometimes stubborn opinions can be tough to accept even when the person is an industry expert. Sometimes, I wish that the person that I am dealing with could be just a little bit more amicable. However, it is equally true that too much of a good thing certainly comes with its own set of challenges. In fact, dealing with overly agreeable people can be fraught with obstacles, although quite different than those usually associated with the stereotypical stubborn geek who seems to not be able to bend or compromise. This article will help you understand and deal with the unexpectedly challenging aspects that you may experience interacting with some agreeable people.

Psychologists have spent decades researching personality [1] and formed many different models to explain the behaviors that we may observe in the people we interact with on a daily basis. One of the most well-respected models, known by the acronym OCEAN, is the five factor model based upon many studies. The five factors, openness, conscientiousness, extraversion, agreeableness, and neuroticism describe essential dimensions of personality. We all have some degree of each of these core qualities in our own personality, although the specific balance of each factor can certainly vary considerably from one individual to another. Successful sales professionals are typically high in extraversion while police and law enforcement personnel are often focused on conscientiousness. Folks who have personalities more geared towards being agreeable typically exhibit highly social behaviors and enjoy the company of others, often demonstrating more kindness, empathy and affection for others than the average person. Sometimes these people come across as “pack animals” who seem to be most comfortable operating within the context of a group. By definition, folks who are agreeable prefer to get along and their tendency to reflexively concur with others is exactly why problems may arise.

The dysfunctional side of agreeableness manifests itself in extreme conflict avoidance. These are the people who just cannot take a stand and always seem to forgo their own will for the sake of “getting along” with others. In our book on configuration management best practices, we discussed the middle child who is often the peacemaker in the family [3]. This behavior is often beneficial and can come in handy in helping others understand one another’s differing views. Unfortunately, though, being agreeable becomes dysfunctional when the person just cannot take a stand or will not engage in uncomfortable conversations, including what most of us would regard as necessary negotiation. The overly agreeable person will often avoid letting you know where they really stand on the issues and will typically do almost anything to avoid conflict. Agreeableness is nice in appropriate amounts, but someone who habitually goes along with the crowd may reach a breaking point where they just cannot take the disparity between what they say and what they feel and, at such stressful times, their response may be extreme as it has been building up for so long.

Technology professionals often need to analyze tough problems and collaborate to arrive at consensus on how best to address and resolve problems. It’s no surprise that smart people don’t always agree on how to fix complex technology problems. When dealing with a systems outage, the situation may be very tense and effective technology professionals must be able to express their views and listen to the opinions of others, too. In a crisis, tact and diplomacy may be less than optimal and people with a thin skin may find it hard to cope with the stress of feeling that they are under attack. Some people back off and actually become passive-aggressive, allowing those with either positional power or perhaps just a loud voice to make the decisions – which may or may not be the optimal choice. Effective leaders create environments where everyone can feel safe expressing their professional views and experience-based opinions.

Dealing with a smart analytical person who tries to steer clear of conflict may require some very strong people skills and this is exactly where you can emerge as a leader within your group. Creating an environment where everyone’s opinion is expressed and the team collaborates to reach consensus is by far the best problem-solving strategy. The most effective teams frequently consist of diverse personality types and have a common value of respect and consideration for each person. Although most people enjoy the validation of hearing opinions in alignment with their own views, confident members of successful technology teams work together to encourage the selection of correct decisions based upon facts, whether they come from the most popular member of the team or the quiet non-confrontational guy in the corner who just happens to really know how to configure the software to get your system up and running!

References:
[1] Byrne, Donn. 1974. An Introduction to Personality: Research, Theory, and Applications. Prentice-Hall Psychology Series.
[2] Wiggins, Jerry S. PhD (Editor), The Five-Factor Model of Personality: Theoretical Perspectives The Guilford Press; 1996
[3] Aiello, Bob and Leslie Sachs. 2010. Configuration Management Best Practices: Practical Methods that Work in the Real World. Addison-Wesley Professional.
[4] Harvey Robbins and Michael Finley, Why Teams Don’t Work – What Went Wrong and How to Make it Right, Peterson’s Pacesetter Books, 1995
[5] Meyer Friedman, Type A Behavior: Its Diagnosis and Treatment (Prevention in Practice Library). Springer 1996

Southwest Glitch Strands Thousands

0

On Wednesday, July 20th, Southwest Airlines suffered a massive systems outage which resulted in the airline being essentially grounded, with over a thousand flights cancelled [1]. This incident forced the airline to temporarily resort to manual procedures which could not handle the normal volume, causing widespread delays and cancellations. The airline had previously suffered a significant outage in 2015 when over 500 flights were cancelled due to another systems glitch. Southwest CEO Gary Kelly was quoted as saying that the cause of the latest outage was a backup system which failed to take over when a router failed. Ironically, this more recent incident occurred shortly after the airline announced record profits, raising the question of whether or not enough efforts are being made to upgrade the airlines critical support systems. Kelly was further quoted as saying, “Southwest has an aging technology infrastructure”, but “the airline has been making significant investments to upgrade it”. Southwest is reported to claim that “it expects to replace the longstanding reservations system next year and replace other key systems over the next three to five years”. Let’s hope that the airline will embrace industry best practices, including DevOps, related to software and systems upgrades. Otherwise, future reports will likely describe outages due to the attempted improvements themselves.

Editor footnote added July 26th, 2016
[1] According to an article published July 25th, 2300 flights were cancelled and thousands more delayed. The cost of the outage may be as high as 10 millions dollars.

Behaviorally Speaking – Using ALM to Drive DevOps

0

Behaviorally Speaking – Using ALM to Drive DevOps
by Bob Aiello

DevOps focuses on helping the development and operations teams work together more effectively by enabling better communication and collaboration. One way that this is accomplished is by moving the application build, package and deployment upstream, allowing operations to more effectively participate in automating the entire deployment pipeline earlier in the lifecycle and as well as gain the requisite knowledge required to understand how to support the application. DevOps clearly works well and both development and operations benefit from DevOps best practices. But there are other essential stakeholders who can also benefit from improved communication and collaboration, including information security, QA and testing. The fact is that every stakeholder, from the business analyst to the DBA, needs to understand their particular role and assigned tasks as well as the work being accomplished by other members of the team. Application Lifecycle Management (ALM) provides the structure and framework that ensures that every member of the team knows what they need to accomplish and how to communicate effectively with the other members of the team. This article explains how the ALM can drive DevOps!

DevOps is a set of principles and practices that focus on helping development and operations communicate and collaborate more effectively. Developers are typically focused on creating software with new features and responding to customer requests as quickly as possible. Operations has a very different focus and is primarily concerned with maintaining a reliable service environment. Much has been written about the natural conflict that exists between development and operations. But the truth is that many other groups also have a focus that often fails to really consider the requirements of the other stakeholders. Organizational silos can have a detrimental impact upon any development effort and DevOps provides us with the best practices necessary to foster effective communications and collaboration. The ideal scenario is to develop teams that are cross-functional and self-organizing. This approach provides a lesson as to exactly why DevOps is effective.

High performance teams are typically self-organizing and often cross-functional [1]. While having a team of technology experts who can perform any role is ideal, it is often not very practical. You can still realize the benefits of DevOps by embracing application lifecycle management (ALM) which helps by defining the workflow for the entire software and systems lifecycle. ALM has its roots in the software development lifecycle (SDLC) which typically defined stages including requirements, design, development, and testing. The ALM actually takes a much wider view.

The ALM defines the tasks, roles and responsibilities that are required to support the entire software and systems lifecycle. This effort includes defining requirements, design, development, testing, but also other related functions including ongoing systems support functions such as the service desk. Application Lifecycle Management takes an integrated and comprehensive approach and relies upon a robust workflow automation tool for its organization and success. The ALM provides transparency, traceability and, most importantly, knowledge management and communication which is the key lesson that we learn from effective DevOps. While cross-functional teams are often ideal and very effective, sometimes organizations must maintain a separation of controls.

In highly regulated industries such as banking and finance, federal regulatory requirements exist for a separation of roles. For example, the technology professionals who write the code are not permitted to be the same resource who build, package and deploy the code. These restrictions, known as IT controls do not prevent organizations from embracing DevOps principles and practices. Whether you are agile or have reason to use a waterfall methodology, the core lesson from DevOps is really about communication and collaboration. Developers have specialized knowledge that must be shared with the operations team in order to successfully maintain and support the runtime systems. The fact is that each team has specialized knowledge that can benefit each of the other stakeholders.

DevOps includes information security (InfoSec), QA and testing as key stakeholders. InfoSec can learn a great deal from developers and both development and information security can learn from the QA and testing professionals. The ALM helps to define what each stakeholder brings to the table and facilitates sharing knowledge and information which is essential for success. These practices improve productivity and quality. It is my own experience, that the most effective way to embrace DevOps with the wider ALM perspective is in small steps. Continuous process improvement (CSI) is one of the effective methodologies that can help you to start at the beginning and work your way through embracing each of the roles in the ALM. DevOps focuses on effective communication, collaboration and knowledge sharing. Using the ALM, you can understand all of the different roles and tasks required in the software and systems lifecycle. Using the ALM to drive your DevOps efforts can help your team embrace DevOps principles and practices for success!

[1] Mankin, Don, Cohen, Susan G., Bikson, Tora K., Teams and Technology : Fullfilling the Promise of the New Organization, Harvard Business School Press, 1996
[2] Harvey Robbins and Michael Finley, Why Teams Don’t Work – What Went Wrong and How to Make it Right, Peterson’s Pacesetter Books, 1995
[3] Bob Aiello and Leslie Sachs, Configuration Management Best Practices: Practical Methods that Work, Addison-Wesley Professional, 2011
[4] Deming, W. Edwards (1986). Out of the Crisis. MIT Press
[5] Bob Aiello and Leslie Sachs, Agile Application Lifecycle Management – Using DevOps to Drive Process Improvement, Addison-Wesley Professional, 2016

Subscribe to the Agile ALM DevOps Journal !!

0

Subscribe to the Agile ALM DevOps Journal !!

Hi,

I am excited to invite you to subscribe to our new online publication which provides guidance on Configuration Management Best Practices, Agile Application Lifecycle Management (including videos) and, of course DevOps. Our publication explains hands-on best practices required to implement just enough process to ensure that you can build software and systems that are reliable and secure. Based upon our new book, Agile Application Lifecycle Management – Using DevOps to Drive Process Improvement, the Agile ALM DevOps Journal seeks to promote a dialogue that is really needed in the industry today. We will discuss practical approaches to implementing the Agile ALM using DevOps best practices including continuous integration, delivery and deployment. We will also discuss process improvement strategies that work in large organizations that must comply with federal regulatory guidelines, along with smaller teams that may very well grow as they become successful. We are taking this journey together and our goal is to ensure that you have a voice and can share your experiences along with learning from other colleagues too.

Enjoy Leslie Sachs’s amazing column: Personality Matters and Bob Aiello’s column: Behaviorally Speaking.

We will also report on major incidents where organizations clearly need to improve on their ability to develop and deliver software effectively, including the recent Southwest systems glitches which resulted in thousands of flights being cancelled and thousands more being delayed. We will also bring you exciting technical product announcements such as jfrog’s new xray, which helps to scan your runtime objects, including docker images, for vulnerabilities. This is an exciting time to be in the technology field. Join the revolution!

You can submit your articles for publication to share your own knowledge and experience!

Bob Aiello
http://www.linkedin.com/in/BobAiello
@bobaiello@agilealmdevops@cmbestpractices
bob.aiello@ieee.org

PS. you received this announcement because you registered on the CM Best Practices website. If for any reason you do not wish to be on our mailing list, just drop me a note and I promise that I will remove your contact information immediately.

Personality Matters- Introducing Positive Psychology

0

Personality Matters- Introducing Positive Psychology
By Leslie Sachs

Many of my articles focus on identifying and dealing with dysfunctional behaviors in the workplace, such as paranoia or the learned helplessness that we have seen in many IT operations shops when systems went down even after the technical personnel warned that there was a problem. Psychology has long focused on pathologies in a valiant effort to identify and cure mental illness. However, one limitation with this approach is that focusing on the negative issues can sometimes become a self-fulfilling prophecy. First year medical students are notorious for thinking that they have almost every illness that they learn about in their classes. If you want an effective and healthy organization, then it seems obvious that it is essential to focus on promoting healthy organizational behavior. Psychologists Martin Seligman and Mihaly Csikszentmihalyi have pioneered a new focus on a positive view of psychology and this article will help you to understand and begin to apply these exciting and very effective techniques.

Technology leaders from CTOs to Scrummasters work every day to foster the optimal behaviors that lead to improved productivity and quality. That said, we all know that dealing with difficult people and dysfunctional behaviors can be very challenging and sometimes disheartening. Seligman and Csikszentmihalyi wrote that “psychology has become a science largely about healing. Therefore, its concentration on healing largely neglects the fulfilled individual and thriving community.” [1] Instead of concentrating so much energy on remediation, it would be better to empower technology leaders to focus on and encourage positive and effective behaviors in the workplace. Martin Seligman and Mihaly Csikszentmihalyi, note that “the aim of positive psychology is to begin to catalyze a change in the focus of psychology from preoccupation only with repairing the worst things in life to also building positive qualities [2].” Seligman delineates twenty four strengths, ranging from curiosity and interest in the world to zest, passion and enthusiasm, which he suggests are the fundamental traits of a positive and effective individual [3]. Notably, playfulness and humor, along with valor, bravery and a sense of justice, are also listed among these traits that Seligman describes. So, how do we apply this knowledge to the workplace and how can we use this information to be more effective managers? The fact is that we all know people whom we admire and we have all had more than a few employers who seemed less than completely effective.

Effective leaders do indeed exhibit valor, bravery and a sense of justice in identifying barriers to organizational success. The best leaders are not afraid to deliver a tough message and also use their positional power to help teams achieve success. Technology leaders are often particularly motivated by curiosity and exhibit interest in the world, as well as a love of learning. Most also display considerable enthusiasm and passion for their work. Other traits frequently observed in strong leaders include kindness and generosity, along with integrity and honesty. Successful leaders usually also exhibit perseverance and diligence. It hardly comes as a surprise that so many of these strengths are specified as beneficial traits. In fact, many of these aspects had been discussed earlier by Abraham Maslow and Carl Rogers in their work on Humanistic Psychology, a discipline which focuses on helping people to achieve success and realize their full potential. Positive psychology is providing a useful framework for understanding the traits which lead to success both at an organizational level, and also for each of us individually. Much of what positive psychology advocates aligns well with agile methodologies and the agile mindset which many organizations are finding to be so effective, especially in creating an environment where each stakeholder feels empowered to do the right thing and to speak up when there are problems or barriers to success.

Quality management guru W. Edwards Deming noted long ago the importance of healthy behaviors such as driving out fear, in order to ensure that your employees are willing to speak up and warn of potential issues [4]. Clearly, positive behaviors lead to highly effective teams and successful organizations.

Positive psychology cannot solve every problem and there is no doubt that many organizations have cultures and environments that just do not foster success. However, if you are a technical leader (or wish to emerge as a technical leader), then understanding the significance and impact potential of encouraging positive traits is essential for your success. In future articles, we will discuss strategies for employing these techniques in the workplace. Helping your organization to embrace and cultivate positive and effective behaviors will increase the productivity and success of every endeavor!
References:
[1] Seligman, M. E. P., & Csikszentmihalyi, M. (2000). Positive psychology: An introduction. American Psychologist, 55, 5–14
[2] Seligman, Martin.  (2002). Authentic Happiness: Using the New Positive Psychology to Realize Your Potential for Lasting Fulfillment, Free Press, New York
[3] Abramson, L. Y.; Seligman, M. E. P.; Teasdale, J. D. (1978). “Learned helplessness in humans: Critique and reformulation”. Journal of Abnormal Psychology, 87
[4] Deming, W. Edwards (1986). Out of the Crisis. MIT Press

Aiello, Bob and Leslie Sachs. 2011. Configuration Management Best Practices: Practical Methods that Work in the Real World. Addison-Wesley Professional.

Aiello, Bob and Leslie Sachs. 2016. Agile Application Lifecycle Management: Using DevOps to Drive Process Improvement. Addison-Wesley Professional.

System Outages Cast a Cloud Over Amazon

0
System Outages Cast a Cloud Over Amazon

By Bob Aiello

Banking and financial services firms are among those companies required to provide secure and reliable platforms, both to comply with regulatory requirements and to meet their own business objectives. It has become common for many of these firms to embrace cloud-based service providers as they offer highly scalable and elastic services, often at a significant cost savings. Such choices are not without their own dangers, though, as banks and other firms recently discovered in Sydney, Australia. According to published reports, a number of firms were impacted by an Amazon Web Services outage. Those adversely affected included banking services and retailers, among others. It was also reported that “Amazon Web Services, a web hosting platform popular with several banks and retailers, has been blamed for many of the ATM and Eftpos problems which have affected a number of banks and their customers, including ME Bank and Commonwealth Bank”. Among those hit were ATMs from ME Bank and Commonwealth Bank. Millions of Australian banking customers were unable to access ATM and Eftpos services … after severe storms on the east coast caused widespread damage, including a major outage at a cloud computing service used by several banks. While the banks blamed the weather and their cloud service provider, Amazon itself focused on their platform’s ability to provide consistent and reliable service. As reported, Amazon itself blamed the clouds (this time the real clouds). Amazon provided additional details saying “that bad weather meant that… our utility provider suffered a loss of power at a regional substation as a result of severe weather in the area. This failure resulted in a total loss of utility power to multiple AWS facilities.” Amazon was quoted as explaining that its backups employ a “diesel rotary uninterruptable power supply (DRUPS), which integrates a diesel generator and a mechanical UPS.” Amazon’s supposedly uninterruptable power supply was consequently interrupted.

Amazon was not the only company which suffered outages due, in part, to inclement weather and no one can say that the impacted banks would not have suffered outages if they had not been using Amazon Cloud Services. But this much is certain: banks and other financial services firms have regulatory requirements to provide secure and reliable platforms. When a storm, hurricane or other natural disaster hits, consumers want to be able to get access to their money. Most regulatory experts would agree that banks cannot just blame their cloud service providers when their systems are not available. In the banking industry, this is pretty close to a “dog ate my homework excuse”. The cloud has many advantages, but firms may want to have an “on-prem” [2] disaster recovery capability – just in case.

 

[1] Additional technical detail included “a set of breakers responsible for isolating the DRUPS from utility power failed to open quickly enough.” That was bad because these breakers should “assure that the DRUPS reserve power is used to support the datacenter load during the transition to generator power.”

[2] – On-prem means “on premises” instead of outsourced cloud-based providers.

Behaviorally Speaking – DevOps Drives Cybersecurity

0

Behaviorally Speaking – DevOps Drives Cybersecurity
by Bob Aiello

DevOps focuses on improving communication and collaboration between the development and operations teams. This is no easy task as they each have very different priorities and the truth is that DevOps impacts other groups as well including QA, testing and, most importantly, information security (InfoSec). In a time when Cyber attacks can originate anywhere from a lone high school student to an organized crime, Cybersecurity is becoming a major concern, and this is where you need to focus on ensuring that your InfoSec function has all the necessary support from the other members of the team. DevOps is, above all else, a set of principles and practices that focus on improving communication between all stakeholders. Information security is a key stakeholder within any organization and depends upon effective DevOps for its success. This article will help you use DevOps to drive your InfoSec initiatives.

Information security is responsible for establishing policies that help ensure a secure environment. Understanding your threat level is an essential first step. You may be dealing with hackers from far away lands or a lone antagonist trying to show that he knows how to break into systems and post his message on your website. Other more serious forms of cyber attacks can involve state sponsored cyberterrorism designed to sabotage critical infrastructure from electrical grids to nuclear facilities. InfoSec encompasses a set of practices that help maintain a secure environment. The completely secure environment is known as the trusted base, and includes the underlying hardware platform, operating system and the applications which provide your end-user functionality. The National Institute of Standards and Technology (NIST) publishes a series of standards including the Guide for Security-Focused Configuration Management of Information Systems (NIST 800-128). There are several other security related standards that also impact configuration and release management. But the interesting fact that is that Information Security and the NIST related standards actually depend upon Configuration Management (CM).

Configuration Management best practices are described in industry standards including IEEE 828, EIA 649 and ISO 10007 along with frameworks such as CMMI, Cobit and ITIL. The security standards include the NIST and ISO 27000 family of standards and they all reference and depend upon the aforementioned configuration management standards and frameworks. InfoSec could not possibly be effective without CM and we increasingly see that DevOps facilitates InfoSec too. To understand the real life application of these standards and frameworks, it is best to start by examine how application code is built, packaged and deployed.

DevOps helps to ensure that we know exactly what configuration items (CIs) need to be built and that we use the correct source code baselines to build them. These best practices, based upon industry standards and frameworks, enable you to build fully verifiable configuration items (CIs) and to embed immutable version IDs as part of the automated build procedure. Immutable version IDs are essential for conducting a physical configuration audit which an essential function to comply with audit and regulatory requirements. InfoSec also relies upon the configuration audit to verify that the correct configuration items were built and deployed as planned. Release packaging is also a key aspect of this process.

Many build tools such as Ant, Maven, and Make provide routines to automate the creation of release packages such Java JARs, WARs and EARs. These automated procedures also enable you to create a manifest that contains essential information about the configuration items in the container and the release package itself. Another important best practice in the use of cryptography to ensure the integrity of the release package and its contents.
If you have ever downloaded software from the internet then you have likely come across packages that have been signed and verified using cryptographic hashes such as MAC-SHA1 and MD5. Cryptographic hashes can be used to ensure that the authenticity of the source or what is known as non-repudiation. They also can be used to verify that the package has not been tampered with itself. Cryptography can help by maintaining secure baselines and alert authorities to unauthorized changes. These practices enable you to create what is known as the trusted base.

The trusted base is the secure and verifiable runtime environment built using these security-focused best practices that ensure that you know exactly what CIs were built using the correct source code baseline in the build itself. There have been recent incidents where banks, exchanges and other financial institutions have suffered serious system glitches because of security issues including attacks by hackers. Knight Capital group reportedly suffered a $440 million loss due to the wrong version of networking software on its servers. These incidents highlight the need for robust configuration management best practices including DevOps that should start early in the development process. DevOps focuses on implementing automated application build, package and deployment for development, QA, integration, pre-production and production deployments. In all of these situations, testing is a must have.

Application testing is an essential best practice including smoke testing that should always be completed as the last step in an application deployment. Testing is fundamental and automated build procedures should include unit tests as part of the automated build stream. From a security perspective effective source code management and automated application build enables information security by facilitating the scanning of source code for security vulnerabilities using automated code analysis tools. You can also build variants of the code that enable specialized testing to detect potential security problems. DevOps helps to establish the core CM Best Practices including application build, package and deployment that are essential for establishing the trusted base.

DevOps implements information security best practices including source code baselining and automated build, package and deployment. Embedding immutable version IDs and effective use of cryptography are also essential and very effective at ensuring the trusted base. If you are using DevOps best practices effectively you will be able to drive your information security capabilities to new levels, provide secure and reliable services and most importantly, delight your customers!

.

Personality Matters- The DevOps Divide

0

Personality Matters- The DevOps Divide
By Leslie Sachs

IT organizations often face challenges that range from complex technology to even more complex personalities. When I work with consultants in our CM Best Practices Consulting practice, I often hear of the many types of problems that plague organizations. For example, build and release engineers often have to interface with software development, data security, project management and IT operations professionals. DevOps tries to address the dynamics between IT operations and highly skilled software and systems delivery teams. Recently, I had an opportunity to read The Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win [1] by Gene Kim, Kevin Behr and George Spafford and my first reaction was that many of the situations described in the pages of that novel were ones we frequently encountered. Organizations are often challenged by the divisions between development and operations, what I have termed the “DevOps Divide.” Read on if you would like to improve your skills in dealing with these challenging dynamics.

Organizations evolve within a complex ecosystem with many forces impacting all of the stakeholders. Some of these forces exist and are controlled from within the organization. However, external forces can also impact an organization in very significant ways, too. For example, pressure from competitors and other market forces may require that companies take on significant risk in order to just stay competitive and ahead of the competition. With complex new technology systems emerging every three to six months, many businesses are hard-pressed to handle rapid deployments. While automation is an absolute must, collaborative communication is also essential. The development team is a key stakeholder in the DevOps divide.

Development bears the brunt of ill-defined and rapidly changing requirements. But development also gets to learn the new technology and get up-to-speed ahead of anyone else on the team. For this reason, build engineers and IT Ops often need to depend upon the technical expertise of the development resources who, in turn, can sometimes feel like they are the only stakeholders who truly understand the technical details. In fact, these dynamics often create a sense of friction between development and other stakeholders such as IT operations. Improving communications can help solve these problems, but in practice, there is often a significant gap between the development and the operations team. While development forges ahead, operations ensures that the systems stay online and all services are reliable.

Much is made of the fact that operations has a very different agenda than development. Operations is responsible for providing reliable services and, consequently, can sometimes be averse to constant change. While development is always pressed to have the next release completed and deployed, operations focuses on minimizing risk and ensuring continuous and reliable IT services. These opposing forces are at the heart of the DevOps divide and you must address them if you want your team to be more effective. The data security group also often faces similar challenges.

The data security group needs to set policy, determine standards and establish best practices to ensure that the systems are reliable and protected from intrusion. However, the data security group can also find itself challenged to safeguard complex technology that changes rapidly and is not well-understood. Once again, communication is essential or else the security team may find itself without the necessary expertise to be effective. There are other important stakeholders in the complex ecosystem as well.

The QA and testing function needs to understand how the system works, including business requirements which are often less than perfectly defined. Project managers are often challenged to provide the governance required by senior management to answer the classic questions of “are we there yet?” While Project Managers can be highly skilled at planning, they often do not fully understand all of the tasks described in the project plan especially in terms of duration, complexity and risk. Let’s not forget the end users either, whether they be internal corporate users or external customers. The DevOps divide, while most obvious between development and operations, can be viewed as a paradigm for similar communication impasses between any of the stakeholders involved.

At the heart of any organization is a culture and family structure that may be highly effective, but also may be at times dysfunctional. We discuss many of these factors in my book on Configuration Management Best Practices [2]. You probably have worked in many organizations that handle communication well and you have probably worked in more than a few which are sorely challenged in this crucial area. DevOps brings a set of principles and best practices which helps the team improve both quality and productivity. The most essential of these practices is effective communication. Understanding the organizational dynamics as well as the personalities of each of the team members can help you comprehend and effectively manage the DevOps divide.

References
[1] Kim, Gene, Behr, Kevin, and Spafford, George. The Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win, IT Revolution Press; January 10, 2013
[2] Aiello, Robert and Leslie Sachs. Configuration Management Best Practices: Practical Methods that Work in the Real World. Addison-Wesley, 2010

Wendy’s Fast Food Chain Data Breach

0

Wendy’s Fast Food Chain Credit Card Data Breach
Hackers Pay a visit to Fast Food Chain And It Wasn’t Just to Grab A Hamburger
By Bob Aiello

Fast food chain Wendy’s has provided additional information on the data breach, first disclosed in January, in which customer credit information (including cardholder name, credit or debit card number, expiration date, cardholder verification value, and service code) was stolen by hackers from what is believed to be as many as 1,000 stores. It was previously reported that only 300 stores had been impacted. According to the company press release, the data breach is believed to have “resulted from a service provider’s remote access credentials being compromised, allowing access – and the ability to deploy malware – to some franchisees’ Point-of-Sale (POS) systems”. Wendy’s claims that “soon after detecting the malware, Wendy’s identified a method of disabling it and thereafter has disabled the malware in all franchisee restaurants where it has been discovered. The investigation has confirmed that criminals used malware believed to have been effectively deployed on some Wendy’s franchisee systems starting in late fall 2015.”

Wendy’s, the third largest hamburger fast-food business, has over a billion dollars in revenue annually and over 6,000 franchise locations. In May of 2016, the company confirmed discovery of evidence of malware being installed on some restaurants’ point-of-sale systems, and worked with their investigator to disable it. On June 9th, they reported that they had discovered additional malicious cyber activity involving other restaurants. The company believes that the malware has also been disabled in all franchisee restaurants where it has been discovered. “We believe that both criminal cyberattacks resulted from service providers’ remote access credentials being compromised, allowing access – and the ability to deploy malware – to some franchisees’ point-of-sale systems.”

In a July 7th statement, Todd Penegor ,President and CEO, of the Wendy’s Company stated that, “in a world where malicious cyberattacks have unfortunately become all too common for merchants, we are committed to doing what is necessary to protect our customers. We will continue to work diligently with our investigative team to apply what we have learned from these incidents and further strengthen our data security measures. Thank you for your continued patience, understanding and support.”

Commentary by Bob Aiello

The following is my opinion; feel free to contact me if you disagree.

I believe that too many companies are not accepting responsibility for ensuring that their systems are completely safe and reliable. Wendy’s does over a billion dollars in sales annually. They have the resources to create completely secure IT systems that will ensure that customer data is safe. There are PCI regulatory requirements in place and organizations which can help companies create secure and reliable systems. Yet, many companies continue to rely upon “experts” who can find malware which has been put onto their servers by hackers. This approach is at best, trying to find a needle in a haystack. We should be building systems to be completely secure and reliable from the ground up. As consumers, we need to demand that corporations implement their systems, which hold our personal data, using techniques such as the secure trusted application base.

Behaviorally Speaking – CM and Traceability

Behaviorally Speaking – CM and Traceability
by Bob Aiello

Software and systems development can often be a very complex endeavor so it is no wonder that sometimes important details can get lost in the process. My own work involves implementing CM tools and processes across many technology platforms including mainframes, Linux/Unix, and Windows. I may be implementing an enterprise Application Lifecycle Management (ALM) solution one day and supporting an open source version control system (VCS) the next. It can be difficult to remember all of the details of the implementation and yet that is precisely what I need to do. The only way to ensure that I don’t lose track of my own changes is to use the very same tools and processes, that I teach developers, for my own implementation work – thereby ensuring history and traceability of everything that I do. I have known lots of very smart developers who made mistakes due to forgetting details that should have been documented and stored for future reference. It often seems like developers are great at running up the mountain the first time, but it takes process and repeatable procedures to ensure that each and every member of the team can run up the same mountain with tripping. This article will discuss how to implement CM and traceability in a practical and realistic way.

The most basic form of traceability is establishing baselines to record a specific milestone in time. For example, when you are checking changes into a version control tool, there is always a point in which you believe that all of the changes are complete. To record this baseline you should label or tag the version control repository at that point in time. This is basic version control and essential in order to be able to rebuild a release at a specific point in time (usually when the code was released to QA for testing). But how do you maintain traceability when the code has been deployed and is no longer in the version control solution? In fact, you need to also maintain baselines in the production runtime area and ensure that you can verify that the right code has been deployed. You also must ensure that unauthorized changes have not occurred either through malicious intent or just an honest mistake. Maintaining a baseline in a runtime environment takes a little more effort than just labeling the source code in a version control repository because you need to actually verify the correct binaries and other runtime dependencies have been deployed and have not been modified without authorization. It is also sometimes necessary that you find the exact version of the source code that was used to build the release that is running in production in order to make a support change such as an emergency bug fix. Best practices in version control and deployment engineering are very important but there is also more to traceability than just labeling source code and tracking binaries.

When software is being developed it is important to develop the requirements with enough detail so that the developers are able to understand the exact functionality that needs to be developed. Requirements themselves change frequently and it is essential that you can track and version control requirements themselves. In many industries such as medical and other mission critical systems, there is often a regulatory requirement to ensure that all requirements have been reviewed and were included in the release. If you were developing a life support system then obviously requirements tracking could be a matter of life or death. Dropping an essential requirement for a high speed trading firm can also result in serious consequences and it is just not feasible to rely upon testing to ensure that all requirements have been met. As Deming noted many years ago, quality has to be built in from the beginning [1]. There are also times when all requirements cannot be included in the release and choices have to be made often based upon risk and the return on investment for including a specific feature. This is when, it is often essential to know who requested the specific requirement and also who has the authority to decide on which requirements will be approved and delivered. Traceability is essential in these circumstances.

Robust version control solutions allow you to automatically track the sets of changes, known as changesets, to the workitems that described and authorized the change. Tracking workitems to changesets is known by some authors as task based development [2]. In task based development, you define the workitems up front and then assign them to resources to complete the work. Workitems may be defects, tasks, requirements or for agile enthusiasts, epics and stories. Some tools allow you to specify linkages between workitems such as a parent-child relationship. This is very handy when you have a defect come in from the help desk that results in other workitems such as tasks and even test cases to ensure that the problem does not happen again in the next release. Traceability helps to document these relationships and also link the workitems to the changesets themselves. Establishing traceability does not really take much more time and it does help to organize and implement iterative development. In fact, it is much easier to plan and implement agile scrum based development if your version control tool implements task based development with the added benefit of providing traceability.

Traceability can help you and your team manage the entire CM process by organizing and tracking the essential details that must be completed in order to successfully deliver the features that your customers want to see. Picking the right tools and processes can help you implement effective CM and maintain much needed traceability. It can also help you develop software that has better quality while meeting those challenging deadlines which often change due to unforeseen circumstances. Use traceability effectively to accelerate your agile development!

[1] Deming, W. Edwards (1986). Out of the Crisis. MIT Press
[2] Hüttermann, Michael, Agile ALM: Lightweight tools and Agile strategies, Manning Publications 2011
[3] Aiello, Bob and Leslie Sachs. 2011. Configuration Management Best Practices: Practical Methods that Work in the Real World. Addison-Wesley Professional
[4] Aiello, Bob and Leslie Sachs. 2016. Agile Application Lifecycle Management: Using DevOps to Drive Process Improvement. Addison-Wesley Professional