devopsy.kinsta.cloud

Tag: DevOps practice

Best of 2020: 5 Project Management Skills Every Developer Should Have

As we close out 2020, we at devopsy.kinsta.cloud wanted to highlight the five most popular articles of the year. Following is the first in our series of the Best of 2020.

The days of the siloed project manager and “skilled” development team are becoming a thing of the past, thanks to the increasing complexity of dev projects. In many cases, the knowledge gap between the project manager and the developer is large, making it nearly impossible for any non-technical person to effectively manage the entire scope without significant input from the development team.

These days, every member has to have a basic level of project management skills to be able to contribute to the overall direction. With the days of Gantt charts behind us and more companies using project management software as they work from remote locations, all team members have better access to all of the components of the project and an expanded sense of responsibility.

When the developers take an active role in the management of the overall project, the benefits are numerous. Not only do the developers have a better sense of how long each step of the process will take—and their contribution to the larger project—but they can also more accurately prioritize the crucial elements needed to take the project across the finish line or recognize where errors, scope creep or delays may derail a project. In short, individual team members become more active collaborators in delivering better, tighter code and applications more quickly.

Project Management Skills to Know

That said, project management doesn’t happen magically, and it would be foolish to assume that just because someone is a skilled developer they know how to manage a project. But familiarity with a few critical PM skills and requirements can go a long way. Here are five aspects of project management every developer should understand.

Estimation and Scheduling

Like any sector of business, project management has its key skills and lingo. The most significant areas of focus for project managers tend to be scheduling and estimation. Scheduling is critical, as you have to assign tasks and accurately manage the workload across the team.

Estimation is also necessary and important to get right, especially for the product development team. The estimation of a completion date triggers many other teams to perform their functions across the company and is often used by the executive team to target success or failure. But delivery dates are notorious for being missed. Working within date ranges versus single-point deadlines is highly encouraged. Ranged estimates capture and help manage the uncertainty so common in software development today, giving the entire team more opportunity for success and allowing for the unexpected roadblocks that occur with nearly any project.

Critical Communication

As a team, it’s essential to keep the lines of communication open. We’re not talking about unnecessary chit chat; we’re referring to critical updates that may affect the overall project. This includes having strong interpersonal skills, namely the ability to maintain clear team communication, complete document reviews and have succinct interactions about project deliverables and expectations.

Technology and online collaboration skills are also important. Ensure all team members know how to effectively estimate their time and keep their progress updated in software the entire team can access. Ensure document sharing and team updates are enabled, so there are no excuses for missed or mixed messages.

Problem-Solving

You can tell a lot about a project team by how the team members solve the major and minor technology and business-related problems that occur—often daily. You might expect that Agile development and DevOps teams have institutionalized troubleshooting in development and engineering. However, teams still need to treat problem-solving as a skill that should be continuously strengthened, especially as technologies evolve. Appointing a lead to coordinate and direct others when problems arise can be an efficient way to take control of a spiraling situation quickly.

Technical Documentation

Writing technical documentation can be a neglected task but a valuable skill for project teams. Too often, documentation isn’t part of the team’s workflow, but it should be. Whether a project team has a staff or contract technical writer assigned to its project, documentation is an important skill. It’s also important to note that documentation doesn’t necessarily need to take place in traditional-type documents. Today’s project teams are often better served by wikis, enterprise social tools and online project management tools. What matters is that the documentation is centralized, online, secure, auditable and searchable by the team and by management.

Risk Management

Many of the above skills lead to an end-goal of managing risk—in this instance, the risk of not delivering a stable, feature-complete project on time. Risk management is a skill that is most effective when distributed among the project’s team members. This is especially important with teams that consist of cross-functional specialists and those with no clear oversight or direct leader. The key to distributing risk management across a project team is to make individual team members accountable and to explain the potential risks in their project tasks to the greater group. This “ownership” of their function and deliverables allows for the most realistic planning possible, requiring each team member to take accountability for precise timelines for their piece of the project. These timelines then roll up to the greater project plan and provide a more accurate estimation of completion date and potential pitfalls.

The Well-Rounded Developer

Project management skills are useful for all employees across an organization. There are no downsides to embracing proven tactics from the project management playbook as they’ll only serve to increase efficiency and promote better team organization and cohesiveness. Developers who have technical skills in collaboration with project management knowledge are always in high demand. Dedicating time to honing these skills is a worthwhile endeavor for any developer.

December 24, 2020
HCL Software Expands DevOps Portfolio

HCL Software has launched a DevOps practice and portfolio along with three updates to HCL tools.

Version 2.0 of HCL Accelerate 2.0 adds support for policy management and out-of-the-box reports to the value stream management platform, while version 7.1 of HCL Launch automates the application of corporate governance rules to the continuous delivery platform.

HCL Software has also updated HCL OneTest 10.1 to include OneTest Server, a wizard-driven test authoring environment and OneTest Data, a data fabrication tool that ensures the right data is on-hand for testing, along with support for Kubernetes and Red Hat OpenShift application development and deployment platform.

Finally, HCL Software is making available HCL Software DevOps Power Pack, which bundles HCL Accelerate, HCL Launch and HCL OneTest, along with 40 hours of services for installation, configuration and team adoption into a single offering.

Steve Boone, head of product management for HCL Software DevOps, said the goal is to make sure IT organizations that adopt HCL tools as part of a DevOps initiative are successful.

Boone said HCL Software is focused on extending the value of investments made in continuous integration (CI) platforms. Most organizations today have multiple CI platforms installed, some of which even come from different vendors. The HCL Software portfolio enables DevOps teams to scale deployment processes across multiple platforms along with tools such as value stream management software to better manage DevOps processes.

In contrast, CI/CD platform providers often offer many of the same capabilities, but those offerings are optimized for a specific CI/CD platform.

The HCL Software portfolio of DevOps tools traces its lineage back to IBM, which sold its AppScan, BigFix and Lotus Notes technologies to HCL at the end of 2018. Since then the company has expanded its portfolio to include DevOps tools and services but it is no longer committed to developing those offerings in lock-step with IBM. As a result, IT organizations should expect to see more frequent updates, Boone said.

In the meantime, interest in DevOps tools and processes has increased in the wake of the COVID-19 pandemic, as organizations accelerate multiple digital business transformation initiatives, he said. As part of those efforts, those same organizations are starting to appreciate the need for DevOps tools that go beyond providing basic CI capabilities.

Different organizations are, of course, going to achieve a level of DevOps maturity at varying rates. It’s not uncommon for different teams within the same organization to differ widely in terms of DevOps maturity. Rather than simply providing software, Boone said HCL Software is committed to providing the expertise in the form of services that enable organizations to maximize the potential of any DevOps investment.

It’s not clear to what degree organizations will want IT vendors to include professional services engagements with the acquisition of software. However, the less proficient any organization is in terms of their DevOps processes, the more valuable those services generally become.

July 2, 2020
Untapping the Potential of DevOps, Part 1: Why Is It so Critical Today?

Apps are making the world a simpler, faster place. Mortgages can be verified in minutes. Food shows up at doorsteps with a few clicks. A safe ride is just a pin-drop away. For consumers, having a smooth, flawless and enjoyable app experience is the status quo. However, what goes on behind the scenes to make it happen is infinitely more complex.

From developers to architects and QA to test automation engineers, the software we interact with requires connected teams to ensure that security, reliability, speed and quality are consistently being delivered. For years, technical teams operated in silos that were worlds apart. Application and software delivery processes were slow, painful and error-prone—a dangerous mix for failure.

About a decade ago, DevOps was introduced as a remedy.

While definitions of DevOps can vary, it is essentially about aligning people, tools and processes to make software delivery better, faster, cheaper and more enjoyable for those involved (which tends to lead to happy customers, too). However, with the boom in DevOps technologies and resources, cutting through the noise and honing in on what will make the biggest impact can be something of a struggle.

In this series, we will address why DevOps is a key enabler for success, the trends impacting the software delivery industry, DevOps challenges, tips and more. First, let’s dig into why DevOps should be a part of an overall business strategy.

Why is DevOps Critical Today?

Times are changing, and so are IT best practices. So, what makes DevOps great for business success?

As mentioned, customers expect new product features to be delivered continuously—with quality and security guaranteed. In order to deliver on this promise, the entire IT organization must work in unison toward the same goals, and these goals should be centered around better customer experience. Much of a DevOps transformation is focused on culture, and when everyone from developers and business leads to legal and marketing teams are collaborating and happy, it leads to positive business outcomes. In fact, according to the findings in the 2019 Accelerate State of DevOps Report, organizations that invest in creating a culture of psychological safety and collaboration are more likely to be high performing.

Being a high performing organization sounds like a no-brainer, but what does it really mean? According to the same report, the highest performing organizations have 208 times more frequent code deployments, recover 2,604 times faster from incidents and deploy 106 times faster than low performing organizations. DevOps is the foundation that makes this high performance possible. This means that organizations that aren’t adopting DevOps will be left in the dust.

DevOps is a set of practices that combine software development and information technology operations to shorten the systems development lifecycle while delivering features, fixes and updates frequently in close alignment with business objectives. The practices help deliver features to end-users much faster and with higher quality, testing and documentation. Processes should be reproducible and auditable, making the technical infrastructure more secure and reliable as a result. Ultimately, DevOps leads to happy and productive teams, satisfied customers and keeps the budget in the black.

There’s much more to uncover when it comes to DevOps—in the next part of this series we will look at some of the common mistakes made along the DevOps transformation journey.

— Jonathan Fries

November 25, 2019
Achieving Organizational Change Through Scaled DevOps

The rapid pace of technological change has had a major impact on customer expectation, forcing IT decision-makers to adopt agile processes to ensure the continual delivery of innovation. This has led to the mass adoption of DevOps practices, with 77% of organizations indicating they rely on DevOps to deploy software, or plan to, in the near future.

DevOps is a key ingredient for building and deploying better software faster. It enables developers to spend less time on onerous tasks and more time creating new features that drive competitive advantage and elevate customer experience.

But, for DevOps to streamline organizational change, it can’t be a one-off initiative. Scaled DevOps requires aligning team members on common goals and best practices and establishing a DevOps maturity model tailored to a company’s individual needs. This is no easy lift and has led teams to abandon DevOps initiatives before they even get started. While the road to scaled DevOps can be daunting, the benefits can have a positive ripple effect across the organization.

Business

The business benefits that accompany DevOps are endless. Think: expanding your customer base, spearheading organizational readiness and achieving unmatched speed. As the consumer landscape continues to change, you will be able to adapt accordingly to generate new features and pathways to customers. Plus, DevOps provides a prime opportunity to get more information from your client base and relay it back to developers, equipping your organization with opportunities to learn from its failures and develop a company-wide, reflective model that better accommodates customer demands.

Once your organization establishes a successful DevOps practice, it will be better prepared to take on other emerging trends and undergo a full-scale digital transformation. With DevOps as the catalyst for change, you can surpass competitors and disrupt the industry with innovative ideas, enabling you to stay ahead of the curve. Once an organization is fully committed to DevOps practices, the company will also enjoy a competitive advantage due to increased speed by empowering your business to provide customers with capabilities faster than rival industry players.

Culture

DevOps may require a daunting corporate culture makeover, but it also allows businesses to enjoy unbeatable cultural benefits by improving communication, establishing a foundation for continuous learning and boosting corporate morale with more meaningful work. When effective processes for communication are in place, employees can avoid the misunderstandings and missteps that often lead to failed initiatives and low morale. Once DevOps improves communication between teams, it sets the stage for more collaboration and cross-departmental education, allowing an organization to develop new operational efficiencies and empowering staff with highly specialized knowledge. With reduced inefficiencies, team members are empowered with more free time to create and meet new goals, plus budding talent from competitors will be drawn to your organization’s innovative environment.

Operations

Empowered by scaled DevOps, businesses will enjoy huge operational and technical rewards with automation, controlling costs and revamping security practices. Since establishing a DevOps practice requires the successful adoption of automation processes, a DevOps initiative includes the same key benefits that automation boasts by delivering the coveted digital experiences that consumers, employees and stakeholders demand. Automation not only meets these demands, but also sets the groundwork for a DevOps journey with CI/CD pipelines that automate software releases to rid your organization of manual release challenges.

On the financial front, as your company moves toward a consumption-based economics model for things like public cloud, your DevOps practice will help control costs and environments by alleviating unused tools. In the long run, improved security will also prove profitable because there is no fiscal nightmare worse than a breach. Upon defining your DevOps model, compliance and control are not only maintained, but rapidly transformed through automated policies and configuration management.

With knowledge of the transformational qualities that come with an effective DevOps approach, IT leaders are eager to adopt DevOps to improve efficiency, boost profitability, deliver superior customer experience and establish a culture of empowerment. However, they must understand that successful DevOps initiatives do not happen overnight. DevOps is reliant on continuous testing and education to ensure that companies can keep pace with their new collaborative culture, rapid delivery process and new technologies. Nevertheless, motivated by the promise of positive business, operational and cultural transformations, organizations will be more willing to prioritize the key credentials necessary to start, and maintain, an efficient DevOps practice.

— Tim Curless

November 14, 2019
DevOps Disillusionment? 4 Behaviors to Get Your Team to the Other Side
For most teams, the adoption of DevOps and an agile mindset involves many twists and turns on the path to maturity. It’s not uncommon for teams to experience a “trough of disillusionment” period as:
- Initial euphoria and “us-against-the-world” team mentality ushered in by adoption of new work patterns wanes with time.
- Client demands and pressures to produce intensify.
- Sustained leadership engagement and support fails to materialize.
- Key evangelists move on to new roles.
- Apologists for organizational status quo never tire.
And before you know it, what once felt like a cultural movement seems mired in the realities of metrics, tools and keeping the operational wheels on.

Pushing through these challenges and self-doubt is a critical step in DevOps maturity that can refine and strengthen a team’s character. Getting to the other side of “the trough” requires a team and its leaders to reconnect with why they embarked on the DevOps journey in the first place, and remind themselves that a lasting shift in behaviors is the ultimate goal. Where behaviors change, results follow.

What are these behaviors? With so much written by thought leaders in the DevOps community, teams have the luxury of expressing the behaviors they intend to model in a way that resonates with their situation. Ultimately four actions, practiced faithfully, will build the team muscle memory necessary to get to the other side.

Choose Wisely

Overcoming the urge to please others and having the courage to say “no” to work that is unlikely to add customer value is perhaps the most important behavior of all. Doing it in a way that preserves credibility and trust is a skill that can only be learned through deeply understanding who your customers are and what problems they are trying to solve. Choose wisely and prioritize ruthlessly. Flawless IT delivery of unnecessary features is a shared failure for both customer and DevOps team alike.

Commit Boldly

Go “all in” on the work you choose to take on. Ensure that the desired outcomes and acceptance criteria of your work are clear before committing, and rely on those closest to delivery to determine how to get it done. Once established, game on! Commit boldly to small deliveries that add customer value and invite accountability for what you take on—knowing that customer satisfaction is the ultimate measure of your success.

Adapt Quickly

Sometimes, we fail. In big and small ways teams employing DevOps don’t always meet their own expectations or those of their customers. Our failures don’t define us; how we respond to them does. Learn. Adapt. Move on. Welcome the changes to requirements you know will come and adapt quickly by leaning in to the power of small and frequent deliveries to place you back on track quickly.

Share Freely

Teams employing DevOps are part of a larger community of like-minded individuals committed to delivering customer value quickly and making their organizations better. Take your obligations to continuous improvement seriously, share best practices freely and solicit expertise to help improve the pace and quality of your delivery and those around you. Helping others succeed has the remarkable effect of making yourself better in the process!

— Chad Sands
February 12, 2019
The Third Way of DevOps: From Knowing to Being
Why is the Third Way of DevOps so difficult to master?

We all know the feeling. You’ve seen an opportunity to improve things and genuinely want to do something about is. But you soon feel the clarity and anticipation draining out of you. First there’s the pressure of the day job. Then there’s the inertia of your co-workers who are oblivious of, or indifferent or hostile to, your ideas. And finally, as if these concerns weren’t enough, you’re faced with the difficulty of unlearning old habits and developing new ones. You wonder why you bother. In a way, it’s a bit like a lottery: You buy a ticket fully knowing that the odds are stacked against you, but it’s the worth it for the uplifting short and illusory dream that it might just happen.

This is, of course, all about the Third Way of DevOps—creating a culture that fosters two things: continual experimentation, which requires taking risks and learning from success and failure, and the understanding that repetition and practice are the prerequisites of mastery. It all sounds great in theory, but why is it so difficult to put into practice?

Information Abundance

It’s not due to lack of knowledge and skills. We have more information available to us and more easily accessible than ever in the history of our planet. We can thank technology for that. But has it really made us more effective at what we do? If I know something and don’t apply it, how is that so different than not knowing it at all? If I know how to read but choose not to, how is that so different that not knowing how to read? If I don’t use what I know, how long will I retain it and how will I integrate it with the other things I know? Most importantly, can and will I apply what I have learned to make things better?

Lifelong Learning

We have been learning and studying all our lives in an attempt to make things better: our ability to understand IT, frameworks, methodologies, capabilities, practices, work processes and, of course, tools. Consider how many thousands of hours you invested in school, self-study, read out of curiosity, listen to podcasts and do work-related training and certification. Most of my friends proudly describe themselves as “lifelong learners” and one claims the day they stop learning shall be the day they die!

Training in Skills

We’ve also invested considerable time and effort into improving ourselves so that we may work more effectively with others: communication skills, teamwork, shared rituals, structured problem-solving, leadership and coaching all fit into this category. Who (in IT) has not been a part of some Service Management, Lean, Agile, Scrum, Kanban or DevOps training? After all of our training, you’d think we’d be further along than where we find ourselves.

Knowing and Understanding

Knowing and understanding are not the same thing—I can know the Four P’s of IT Service Management (People, Process, Products and Partners), yet not view it as a lifecycle model and understand that to obtain the benefits of this knowledge, my team must determine the roles of people and objective of work of processes and then implement tools to automate the processes enabling people’s roles and tasks.

Understanding and Doing

Nor are understanding and doing the same thing—I can know that structured problem solving is based on the scientific method and can be broken down into four stages (Plan, Do, Check, Adjust). I may also understand that structured problem-solving is preferable to the reactive educated guesswork my team engages in whenever it encounters a problem. But if we do not change our behavior when it comes to problem-solving, our understanding will not manifest as action.

Doing and Being

Neither are doing and being the same thing—I can be doing something and still not have internalized it so that it becomes who I am. I can know the core principles DevOps (engage in systems thinking, amplify feedback loops, foster a culture of experimentation and learning). I may understand that all three principles must be applied to foster a sustaining DevOps environment. I may be even be holding initial planning sessions with my team during which we map out the DevOps value stream, identify bottlenecks, create feedback loops and introduce changes to create a create a culture of experimentation and learning.

Moment of Truth

But what happens when we meet with our next P1 incident? Does the knowing, new understanding and behaviors get tossed aside while we fix the problem, or do we hold fast to the new way of doing things as we grapple to not only remediate the incident but to view it within the context of DevOps?

So, What’s a Person To Do?

The velocity and degree to which we can move from knowing to being determines how effectively we can apply what we know. Here are a few things you can do to smooth the transition from knowing to being and help put the Three Ways of DevOps into practice:
1. See and feel the potential impact from moving beyond knowing to being
2. Use the uplift to get motivated
3. Take action by changing something within you and your team’s circle of control
4. Reflect on the fact that you have realized potential (this is very powerful when you share it with your team)
5. Check and adjust based on the outcomes of step #3
6. Allow the feedback from the previous step to motivate you to carry on!
Curiosity and Humility

This approach requires a certain attitude. One of curiosity and humility. You need to be inquisitive so you keep striving to understand. And you also need to be unassuming and you see yourself as having plenty of room to learn and grow; being deeply (almost obsessively) interested in what’s going on and how things could be improved; trying to be aware of and to set aside any preconceived ideas—adopting a beginner’s mind.

To Be Continued …

In our next post, we’ll explore specific steps you can take to leverage The Third Way of DevOps and make tangible progress based on what you know and don’t know, understand and don’t understand, and do and don’t do.

This article was co-authored by Mark Smalley.

— Mike Orzen
December 3, 2018
Living in a DevOps World (Part 1)
The concept of DevOps has grown and evolved into a conceptual and working model for more effective and efficient software development and implementation. That said, there are some differences of opinion on the real-world value of any DevOps approach to date, and on the best way to create and implement a real-world DevOps environment. This two-part article will focus on what an agile DevOps approach is meant to address, and what it is not meant to address.

DevOps sits at the nexus of three essential business technology functions: software development, quality assurance and operations. A short and concise definition of DevOps proposed in 2015 seems as appropriate as any:

DevOps is a set of practices intended to reduce the time between committing a change to a system and the change being placed into regular production while ensuring high quality.

The definition was suggested in the book, “DevOps: A Software Architect’s Perspective,” and the authors have hit upon the essence of the practice. The key, of course, is how to put that concept into practice.

Perhaps the first step on the journey to effective DevOps is the recognition that the concept is the result of the rise of the Lean and Agile software development methodologies. Those methodologies, among other things, emphasize the following:
- A focus on customer value.
- The elimination of waste.
- Reduced cycle time (accomplishing work faster, releasing faster).
- Shared learning.
- Avoiding batching (don’t do things until required).
- Theory of constraints (break things up, focus on individual issues).
- Continuous integration, testing and delivery.
- Faster time to market.
DevOps in Practice

Adherence to the principles above meant that something had to be invented to accomplish them and that something was DevOps. Over time, an effective DevOps practice should address any number of business technology pain points. The following short list of those pain points and the DevOps response should prove instructive.

System Downtime

The developers’ curse since systems were developed, system outages are inevitable as long as systems are designed, tested and implemented—even with increased automation—by imperfect beings. DevOps acknowledges that by changing the focus from trying to create applications that never fail to designing systems that can recover quickly, thus decreasing aggregate systems outage time over the life cycle of any application or system.

Stagnation

This was a staple of traditional systems development and is most closely associated with the waterfall methodology for systems development. After requirements were created, the development team would be locked away for weeks, months or, in some cases, years before emerging with “fully” working software that inevitably no longer satisfied rapidly evolving business requirements. DevOps is designed to fit hand-in-glove with the Agile practice of short windows of incremental changes instead of long release cycles, putting working software in the hands of customers as quickly as possible.

Team Conflict

Having been borne from the cultural combination of Agile and Lean, DevOps has taken on the problem of functional silos that are often erected between development, operations and the business customers. It follows the methodological approaches of collaboration and teamwork first to understand what others know and to leverage the best of it to solve business problems more rapidly. There is also a cultural bent toward experimentation, continual learning and constant improvement. This leads to blameless post-mortems, where instead of finger pointing when something goes wrong there is collaborative discussion and learning to correct and prevent the problem from occurring again.

Knowledge Silos

Functional silos have led to compartmentalized knowledge. If the old game was that knowledge is power, the new game in the DevOps world is that knowledge is freely exchanged as an enabler to solving business problems. DevOps addresses the problem of information being lost in translation between the development and operations functions by eliminating the functional barricades and making knowledge sharing the highest form of collaboration.

Inefficiency

Waiting for things to happen used to be a standard operating procedure in the pre-DevOps world. Project plans were created and managed to account for the time it might take for new code to be moved into a testing, quality or even production environment. This was a momentum killer for projects and at times a morale killer for developers waiting to see what changes they might need to make to their code set. The combined Agile and DevOps approach has rewritten the traditional approach to code migration, smoothing and eliminating wait times so that projects flow more seamlessly from start to finish. It also has the benefit of keeping business resources—testers, approvers, etc.—more engaged as a result of a constant flow of new functions and features to test and use. And lest this be viewed as simply a way to keep the technical stuff moving along, it’s important to remember that there is a financial aspect to this as well. Reducing speed to market with new functionality, reducing or eliminating idle hands—be they technical or business—and delighting customers with a steady stream of enhancements and features all go directly to an organization’s top and bottom lines.

That, after all, is in many ways what the DevOps approach is all about. All of these critical areas become the means to accomplish it. Part two of this article will focus on some more of the benefits of a DevOps approach, and how to achieve them.

— Dave Farinelli
June 5, 2018