Behaviorally Speaking – CM Excellence

+
-
0
Behaviorally Speaking – CM Excellence

Behaviorally Speaking – CM Excellence
by Bob Aiello with Dovid Aiello

Configuration management (CM) is a comprehensive and awesome discipline with practices that can help improve quality and productivity throughout the entire software and systems delivery lifecycle. Configuration management is the basis of DevOps and without excellent CM you are not going to be successful implementing continuous practices such as integration and delivery.

The lack of CM Best Practices or poorly-implemented CM can be disastrous for an organization. Although, interestingly enough, disasters themselves can provide a great opportunity to improve your configuration management because they highlight the importance of getting the process right. As Winston Churchill once said, “never let a good crisis go to waste”. For example, software installation and upgrades can result in major outages that are so disruptive that they threaten the very existence of the corporation. Conversely, excellence in configuration management can be just as beneficial. Read on if you would like to truly achieve CM excellence.

It is always important to start by considering what excellence will look like. For me, CM Best Practices means that we always know exactly what version of the code (actually configuration items or CIs) is running in production (or QA) at any point in time. We also want to be able to retrieve the exact version of the code used to build and deploy the release to production (or QA) and we need to be able to make a small change to the code without any chance of the code regressing due to the wrong version of a header file or some other dependency. These three capabilities are the starting point for CM excellence. Unfortunately, many companies do not have the necessary procedures in place to guarantee these capabilities . Here’s how to implement them.

It is always essential to start with version control, including baselining your code using a tag or label. Baseling refers to identifying all of the configuration items (CIs) for a specific milestone. You also want to be able to link changesets to workitems so that you have traceability as to exactly why a change occurred and who gave the authorization. When a bugfix is necessary, it is non-negotiable to have relible variant management (using branches or streams).

Automated application builds with immutable version IDs embedded in each configuration item (CI) are also essential as is packaging the release with a manifest specifying the contents (often called a bill of materials or BOM). The package also needs to contain a procedure that can verify both the contents of the package and also the application that has been deployed. Physical Configuration Audits verify that you have the correct configuration items (CIs) and a functional configuration audit verifies that the CIs are performing as they wre intended.

Application deployment must also be fully automated and should enable you to deploy applications frequently and painlessly. It is ideal to have a complete deployment framework to help ensure a consistent and reliable methodology for automated application deployment. There are many challenges that can impact the successful implementation of configuration management. The most challenging that I have found is a lack of communication between developers and the operations folks who are responsible for ensuring reliable and continuous service. One aspect of this challenge involves the sharing of technical knowledge. Developers get to learn new technologies and spend countless (truly countless) hours working with complex technologies. Operations folks get the runtime code when it is about to go live and often have only a short period of time to get up to speed. I have experienced this exact challenge as a build engineer. It is particularly difficult when the technology changes and there is less than adequate communication and training to help operations get up to speed.

DevOps has emerged as an industry best practice that focuses on improving communication between development and operations. I often explain that in CM we mix the ingredients and in DevOps, we make the pie. Applications should be built with the tools necessary to maintain them and, equally importantly, ensure continuous and excellent service. Moving automated build, package and deployment upstream means that automated procedures required for deployment to production can also be used for deployment to development test regions, QA, and UAT. This approach allows us to achieve excellence by having our automation developed and tested early in the process.

Excellence in CM requires that you implement best practices that meet the needs of your team. Implemented well, automated build, package and deployment can help streamline the entire software and system development process, improving quality and productivity for your entire team.

 

Micro Focus Announces Intent to Merge with Hewlett Packard Enterprise’s Software Business Segment

+
-
0

Micro Focus Announces Intent to Merge with Hewlett Packard Enterprise’s Software Business Segment

Strategic Combination Furthers Company’s Long-term Strategy to Maximize Mature Technology Investments, Accelerate Innovation Opportunities for Customers
________________________________________
ROCKVILLE, Md., Sept. 7, 2016 /PRNewswire/ — Micro Focus (LSE: MCRO.L) announced today its intent to merge with HPE’s Software Business Segment in a transaction valued at approximately $8.8 billion. The merger is subject to customary closing conditions, including anti-trust clearances and shareholder approval and is expected to close in Q3 2017. Micro Focus and HPE also announced as part of the transaction the intent to enter into a commercial partnership naming SUSE as HPE’s preferred Linux partner.

The proposed merger brings together two well established enterprise software vendors with highly complementary portfolios. With revenues of approximately $4.5 billion, it creates one of the world’s largest pure-play infrastructure software companies with a truly global footprint, agility and financial strength to drive software innovation across both traditional and emerging IT market segments.

“Today’s announcement marks yet another significant milestone for Micro Focus and is wholly consistent with the long-term business strategy we have been pursuing to be the most disciplined global provider of infrastructure software. The proposed merger with HPE Software is consistent with our recent acquisitions of Serena Software and the Attachmate Group,” said Kevin Loosemore, Executive Chairman, Micro Focus. “The combination of Micro Focus with HPE Software will give customers more choice as they seek to maximize the value of existing IT assets, leveraging their business logic and data along with next-generation technologies to innovate in new ways with the lowest possible risk.”

Organizations continue to seek technology solutions that improve their time to market and create new avenues to further engender customer loyalty and improve employee productivity and more. HPE Software brings additional breadth and depth across IT Operations Management, Software Delivery & Test, Enterprise Security, Information Management & Governance and Big Data Analytics, giving Micro Focus additional advantage to deliver richer solutions that effectively bridge existing IT infrastructure with emerging technologies to meet those business demands.

“We believe that the software assets that will be a part of this combination will bring better value to both our customers and shareholders as part of a more focused software company committed to growing these businesses on a stand-alone basis,” said Meg Whitman, President and Chief Executive Officer, HPE.

At the same time, Micro Focus and HPE have announced their intent to enter into a commercial partnership naming SUSE as HPE’s preferred Linux partner as well as exploring additional collaboration leveraging SUSE’s OpenStack expertise for joint innovation around HPE’s Helion OpenStack and Stackato Platform-as-a-Service solutions. SUSE and HPE are working together to define the specifics of the commercial partnership.

“SUSE and HPE have a long history of successful strategic partnership,” said Nils Brauckmann, CEO, SUSE. “We are excited now to explore new ways of expanding upon that with a commercial partnership focused on areas such as cloud computing, software-defined networking and application platforms. The combination of SUSE’s open source expertise and OpenStack capabilities with HPE’s Helion and Stackato offerings can create best-in-class enterprise solutions for our mutual customers.”

About HPE
HPE is an industry leading technology company that enables customers to go further, faster. With the industry’s most comprehensive portfolio, spanning the cloud to the data center to workplace applications, our technology and services help customers around the world make IT more efficient, more productive and more secure.

About Micro Focus
Micro Focus (LSE: MCRO.L) is a global enterprise software company helping customers innovate faster with lower risk. Our software helps customers build, operate and secure IT systems that bring together existing business logic and applications with emerging technologies to meet increasingly complex business demands. For more information, visit: www.microfocus.com.

 

Personality Matters- Ops and Learned Helplessness

+
-
0
Personality Matters- Ops and Learned Helplessness

Personality Matters- Ops and Learned Helplessness
By Leslie Sachs

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

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

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

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

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

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

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

jfrog CTO Yoav Landman

+
-
0

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

 

 

 

 

 

 

 

Training Video:: Bob Aiello On Understanding DevOps

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

Personality Matters—CM Top Down or Bottom Up

+
-
0

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

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

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

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

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

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

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

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

Personality Matters— Personality and CM Strategy

+
-
0

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Training Video:: Bob Aiello On CM Best Practices

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

Behaviorally Speaking—Release Management and Deployment Essentials

+
-
0

Behaviorally Speaking—Release Management and Deployment Essentials
by Bob Aiello

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

Stepping into the Line of Fire

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

Failing as the Release Manager

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

Knowing When to Ask for Help

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

Involve the Developers

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

Communicate Early and Often

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

Don’t Try to Boil the Ocean

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

Moving Upstream

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

Conclusion

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

 

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

Six Misconceptions of Enterprise Agile

+
-
0
Enterprise Agile: Six Myths to Stop Believing

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1...456...11Page 5 of 11