devopsy.kinsta.cloud

Tag: project management

Tips for Successfully Adjusting to Life as a Project Manager

When you switch to a new work environment, it takes time to adjust to the new surroundings. As a project manager, you have to be ready to lead your team on the path to success while ensuring a good system of supervision and support. At this stage of your career, if you are feeling a little tense, you are not alone: Many managers often feel anxious about adjusting to being a business manager. You need to spend more time to develop the characteristics of a good manager so that you can handle the most delicate responsibilities in the business. Here are several highlighted tips to successfully adjust in your role as a business project manager.

Source – Pixabay

Learn Team Management Skills

There is no doubt that independent work has its own importance in an organization, but you cannot ignore the importance of teamwork. The idea of team management is to develop a supportive and collaborative company culture by encouraging team members to work together. Make some efforts to encourage communication within your team and provide a proper channel for feedback. In addition, take the time to organize individual meetings to build trust and a higher sense of responsibility in your team members.

Implement a Growth-Oriented Approach

Every project manager needs to work diligently to help employees progress on an individual level as well as on group level. Every great business needs a good leader to grow, so it is important to establish healthy personal relationships with all members of your team so that you can know more about their interests and hidden talents. Effective managers always make efforts to facilitate a growth-oriented approach for overall employee development—this, in turn, pays off in the form of greater productivity and team chemistry.

Follow an Inclusive Process

Although you want your team members to take risks and be proactive in pursuing project goals, it is also important to help them feel comfortable in doing so. Make efforts to motivate team members and create an inclusive work culture. Let your team raise their individual ideas, opinions, and concerns so that they can find easy ways to cope with challenging work conditions. When team members have the flexibility to start a conversation and share their feedback, they can be more innovative in tackling challenging projects.

It is easy to feel anxious as you step into the role of a project manager for the first time. The direction of the team and how projects are completed will be based on your ability to lead. However, the primary approach to reducing these types of feelings is by focusing on building and molding your team. To paraphrase Benjamin Law, owner of Crazyleaf Design: By prioritizing your team interests, highlighting every member’s unique skills and creating an integrated work environment, you can better adjust to being a project manager. These can contribute to being a more successful manager in the long term.

— Wendy Dessler

November 2, 2018
Empower Agile Teams with a ‘Bell Curve’ Approach

There’s no feeling better than ending a project on a high—until you notice the mountain of work looming ahead for your next project. At those times, it may seem hard to start grinding all over again. The struggles of adjusting to new teammates or a new client can be daunting. When a new project kicks off, early success is a must. Quick wins secure the customer’s trust and help keep projects moving swiftly. Agile methodology has proven to be one of the most effective delivery models for early wins: According to Harvard Business Review, innovation cycles can be compressed by more than 75 percent thanks to agile.

But in search of these early wins, teams often bite off far more than they can chew. They take on the brunt of huge projects before being fully prepared. To be self-managing, teams need to take into account their group maturity before tackling new projects. So, how can teams make sure their delivery models and their maturity models are aligned?

Solving Team Maturity Issues with a Bell Curve Approach

One of the clearest ways for teams to make sure that they are taking on appropriate projects at appropriate times is for them to follow a bell curve approach.

The idea is to follow the agile delivery model, prioritizing risky unknowns and high-value work early, but not too early. First, the team needs to ramp up, ensuring that team maturity is at a high-performance level. The team dynamics models of Bruce Tuckman or William Schutz are helpful to understand how to put together and develop a group to autonomous self-management and hyperperformance.

By requiring teams to focus on less complicated projects first, a bell curve approach allows teams to adapt and refine their practice as they work their way up to the most difficult tasks. Similarly, the approach ramps down after the most complex iterations, increasing the chance of success and lowering risk. Here’s how teams can follow a bell curve approach:

Warming Up

The ramp-up period is part of the front end of any successful project. During this phase, the team learns its way around each member’s style. Some hiccups and tension will naturally occur during this phase, but the idea is to work it out early so that everything is running at peak optimization for the height of the curve later on.

Think of it this way: Old cars with carburetors needed to be warmed up during the winter months before they could run. Gasoline is thicker in the cold, and the fuel must heat up so it can mix with air and reach the vaporization point to be used by the engine. Otherwise, the vehicle risks stalling out.

That’s how I like to think of this stage of the project. We must first regulate the environment and work out the kinks of the team before we move forward. If we don’t control for a good foundation, the team and project may later stall out in the middle of a critical stage.

Find Your Peak

After the team finds its rhythm during small, early challenges, it’s time to ramp up and get the real business done. While there still may be smaller tasks to accomplish, you’ll get to those later. Now is when you want to capitalize on fresh energy right as your team hits its stride to deliver on the the most critical portion of the project.

This phase—at the height of the bell curve—is a true test of the rhythm that a team has found. Don’t be surprised if some moments give way to tension as the members push through the most challenging portion of the journey.

Coming Back Down

On the way down from the peak, work intensity slows as the team starts completing the lower priority pieces of the puzzle purposely left aside when the project kicked into high gear.

In addition to tying up loose ends, a slower period on the way out of a project provides the opportunity for reflection. What would you do differently during peak time on the next round? What aspects of the project can use fine-tuning? These important questions are much easier to consider with a clear head and a shorter to-do list after the most critical and complicated components have been put to bed.

This sort of approach is not only applicable to software development teams. From administrative to marketing, teams across an enterprise can institute a bell curve approach to their big projects. By embracing agile methodology, any team can streamline its members’ output and decrease risk in high-pressure, mission-critical projects.

— Patric Palm

August 31, 2018
How Systems Engineering Can Help Avoid Product Development Pitfalls

Product development programs all start with great optimism regarding their potential to provide an excellent product to customers, along with excellent profits to the company. But research shows that a majority of product developments end in failure. The reasons for each failure are unique, but the overarching reason often can be described as the lack of systems engineering.

I managed a program several years ago that is a great example of how programs that have an excellent idea, sound technical basis and talented people working on them can still fall into this trap, and how systems engineering and a systems mindset can rescue these programs from the brink of failure and propel them to a successful conclusion.

Here’s the scenario: Scientists working for a Department of Defense electronics supplier devised and patented a method for doubling the frequency range of a radar amplifier in the same physical footprint. Additionally, advances in technology allowed two of the most sensitive components to be replaced by components that were substantially more reliable, increasing the amplifier’s projected life by more than 500 percent. Further, these new components were not destroyed by the absence of a vacuum, allowing easier, faster and cheaper repair of the parts. Funding was secured, and the product development process commenced. The project was not plagued by requirements issues (though many product developments are), as the performance requirements were identical to the product it was replacing, aside from the increase in bandwidth and reliability.

Unfortunately, prototypes were failing to meet the requirements in either bandwidth, power or both. As the program neared the end of its allocated development funding and the pressure on the engineering team increased, each subsequent amplifier prototype was billed as being “full spec,” with multiple changes made in each iteration to meet this promise. Each prototype failed to live up to this billing, and the program was eventually deemed a failure and scheduled for termination.

How did this program devolve to this point? The scientists and engineers involved were brilliant individuals with a history of successful projects and a long list of patents to their names. The requirements were well-understood, and the program had avoided the all-too-common pitfall of neglecting to consider how the piece would fit into the overall system and its effects on upstream and downstream components, overall system power and cooling budgets, etc., which tends to happen in projects run by component designers that focus on the design and capabilities of their particular widget. However, as the program budget and schedule for development was steadily consumed, those involved felt obliged to make each next prototype do everything, rather than taking a deep breath, seeing how far they’d come and how far they had left to go and then creating a road map to get there.

When I was brought in to the program and we had secured some additional development funding, we got down to the business of creating the road map. In addition to the electronics company’s scientists and engineers, we brought in experts from both academia and a federally funded research and development center to review the initial concept and progress to date, determine whether the program had a path forward and, if so, delineate a series of experiments that would culminate in a successful prototype.

Termination of programs is always an option and should not necessarily be viewed as a bad outcome for a program in dire trouble. In evaluating whether it the right move, look beyond the siren call of spent budget, take a stark look at the chances for success and determine if the program or project can still deliver its anticipated benefits. Many programs in trouble attempt to recover by “dumbing down” the requirements; while that may offer an “out” for a development that is in trouble and allow the program to move to the next phase, ask whether continued investment in the system worth the lesser benefits of a product that meets the revised, easier requirements.

After careful review, we determined that the program had a path to success. A series of six prototypes were planned: three experiments to evaluate the performance of individual design changes, a fourth to combine successes from the three experiments, a fifth planned to be production representative/fully specification-compliant and a sixth to show repeatability.

With this new plan in place, the project was able to proceed in a systematic fashion without pressure to produce instant success. Previously, multiple improvement ideas were incorporated into each new prototype with the hope that this would be the full-spec version, and the program could then proceed into production (and the company could reap its financial reward). Experiments were defined up front, and their results were evaluated without the uncertainty of multiple changes masking the successes (or failures) of individual changes.

Success was achieved on the fourth prototype, and the program eventually was successful in creating a significant capability and reliability enhancement for this weapon system. Much of the credit belonged to the hard work and dedication of the engineering leader for the electronics firm (who received its Product Development of the Year award). But even more so, the credit for this dramatic (and very unusual) recovery was earned by the team that had the wherewithal to take a step back and apply basic systems engineering principals to lay out a plan to recover the project from its death spiral.

All too often, companies or program offices bring in a “Cleaner,” but many of these are just tyrants who bully everyone into working long hours, hoping that if you try everything under the sun, something will work. A systems engineer, however, has the composure to take a step back and review, despite the immense schedule pressure. Rather than rushing into the next setback, a systems engineer will look at what the program or project is supposed to accomplish (high-level requirements), review the efforts underway to support those requirements and set a plan with discrete steps and measurable progress points. By not trying to do everything all at once, wherein successes and failures are indistinguishable and possibly masking each other, having a systematic (there’s that word “system” again) approach allows the system engineer to move toward a path that will result in meeting the original requirements.

About the Author/ Jay Schatz

Jay Schatz is senior program manager at Base2 Solutions. He is a high-performing technical project management and program management professional with the breadth of experience that comes from over 22 years of experience managing programs for the aerospace industry and in the US Air Force. Jay is currently providing program management and systems engineering support to the Boeing 787 program, providing expert advice to clients on program management, supplier relations and engineering solutions. Connect with him on LinkedIn.

December 8, 2017
DevOps Introduces Complexity. Really

The larger the project, the more resources are generally dedicated to it. That is true of the vast majority of fields of human endeavor. Consider building the San Francisco Bridge versus building a crossing over a stream. Or World War II versus the Spanish Civil War. The resources dedicated scale with the size and complexity they need to support.

This is true of IT projects also. A four-line script does not require the attention that a highly available web app with dynamic data does. It is a pretty simple concept, we all are aware of it, and methodology doesn’t much change it.

The problem is that we are often terrible about acknowledging this concept when it comes to internal support projects. We don’t see a compiler as a tool in need of regular maintenance and locking down, and largely it isn’t. There definitely are cases where the newest compiler/interpreter should be implemented, but except for massive change such as Python 2.x to 3.x, there isn’t a driving need to have the newest and shiniest.

It’s Complex—and Growing More So

What happens when we apply this relaxed attitude to DevOps? A mess. The reason is simple: The automation side of DevOps is generally implemented with tools. Lots of tools. Tools that require maintenance, troubleshooting, interfacing to other tools … It gets complex fast.

And where on the calendar is time for these things set aside? Almost always the answer to that question is “nowhere.” But these aren’t compilers and interpreters. If your Bugzilla DB goes bad, you have a major problem. Since compilers and interpreters are generally read-only—changes aren’t made to them except to upgrade—it generally requires a disk-level error or serious human failures for them to stop working as planned. That’s not true for things with constantly changing datasets. And many DevOps tools have constantly changing datasets.

In an increasing number of organizations, the DevOps infrastructure should be listed as the largest application portfolio the organization manages. And that is where you need to be.

Make DevOps Tools a Project

It is that simple. Tooling is a massive bit of overhead that seems to be not so big because it streamlines the development/deployment process. In short, the tools save enough time that their cost seems smaller than it is. But that cost will not go away, and once the pipeline is fully automated with a stable toolchain, keeping it running is a cost IT will have to continue to bear. Don’t just treat it like something you can check into when it fails; give it the same treatment that you use it for. Make certain you have backups—if possible, make your DevOps environment totally dynamic—so a failed instance of X can just be replaced by a new copy. You can’t “just spin up” complete and accurate datasets, but the backups fill that void.

It’s More Than Just DevOps

Stay on top of tool updates and improvements, just as you would for any mission-critical software. Because once your software factory is dependent upon the DevOps toolchain, it is mission-critical software. Learn how changes will impact the environment you are using the tools in.

And it’s more than just the tools themselves. The DevOps environment is highly complex with a lot of variables that can have a negative impact. The move from RHEL/CentOS 6.X to 7.X is a good one. Sure, it’s better by objective standards, but there is enough change that it breaks a lot of things. Mostly the change in networking, but libraries and tools also. In fact, I helped someone work through inter-process communications (IPC) issues caused by the upgrade. This is a stumbling block for the DevOps team in a RHEL/CentOS environment, even though the DevOps team may not be the one choosing to upgrade.

It’s All Good, Though

So there is a cost. The cost is not small. But the benefits still far outweigh the costs, and I’m not arguing otherwise. What I am arguing is that it needs to be a cost that is accounted and planned for. “When it breaks, we’ll fix it” is too relaxed for the toolchain that will run your software factory. Once it’s right, take the time each week to keep it right. Set up the policies, processes, and time to keep it clipping along smoothly.

And keep kicking rear. This is just a cost of doing business, much the same as database maintenance. Make sure you’ve got the time set aside, so your other projects can keep moving the org forward, and all is good.

— Don Macvittie

October 5, 2017
Engaging Adoption of DevOps
Executive mandate does not immediately translate into a change in behavior. Organizations inherently grasp the value of embracing DevOps, but the timing of exactly when it begins and is completed is another matter. The devil truly is in the details—or rather, in the ability and willingness of the organization to adopt a change in thinking and a change in the actions that follow.

“Adoption” is then a common term to describe the measurement of how far along an organization is in its transition between legacy and future, between the beginning and the completion of embracing DevOps services. As you might guess, adoption does not happen overnight, nor does it occur because of mandate or willingness. These factors influence the speed of adoption in some cases, but can act as deterrent in others. Adoption—like most other services provided to a given organization—occurs because its value proposition is sufficiently defined and resources are budgeted and assigned to it.

The level of resources you dedicate to tracking and facilitating adoption of DevOps in your organization is directly proportionate to the complexity of your development efforts. If for example, you have a new development team well-versed in cloud technologies and comfortable with using software-as-a-service (SaaS) tooling with only few applications under development (small app portfolio), your proportionate adoption efforts will be small, and transition should occur very quickly. However, if you have a large number of applications spread out across a wide variety of hardware platforms and are using a wide variety of development languages or tools, your proportionate adoption efforts will be far more substantial to keep the timeline manageable. In either example, a complete lack of attention to adoption results in elongating the timeline two to eight times longer than it would have been if formally engaging adoption was considered.

Adoption Engagement 101

So what do these adoption/engagement resources do from day to day? The primary focus of the folks assigned to this duty breaks down into three major categories of work efforts:
1. Communications conduit: The first responsibility of the folks on this team is to develop and implement a communications plan to keep all stakeholders up to date on what is going on with DevOps services. This includes metrics-based information such as how many applications have been fully onboarded to DevOps. It also may include how many applications have been onboarded into a particular level of automation within the stack, from code to OS. A company may want to know how many apps have gotten their database efforts automated, as an example, or perhaps how many apps are fully automated with middleware messaging systems. But the communications also must include keeping executives up to date on the ROI progress, and what areas of the company may be exhibiting resistance (for both legitimate and non-legitimate reasons). Expressing these outcomes can be sensitive and should be done with a modicum of care, so the folks assigned should have these skills to start with.
2. Information Preparation & Follow-Up: When a given application in the portfolio is targeted for onboarding to DevOps, a significant amount of information is usually gathered about it. While a company can create an automated system for development engineers to provide the data into an electronic web page or other means, very often questions arise about “how” to respond. You do not want to have your DevOps services engineers constantly deterred from their work to answer basic questions such as this, so having an adoption team able to provide the data quickly facilitates the overall goals. In addition, often the development engineers are too “busy” to provide the DevOps team the data they need. Again, someone needs to follow-up to ensure questions are actually answered. While it is easy to assume engineers will behave professionally and respond accordingly, that assumption in the real world results in long delays and interrupted workflows across multiple teams.
3. Training & Feature Expansions: Finally, the tools and architecture practices behind them need to be communicated effectively to the practitioners and participants of the DevOps services. When new programmers are hired, for example, they should have access to training materials on accessing to the DevOps toolsets and using base functionality, what governance procedures will impact them and more. On occasion, to facilitate adoption, an application executive sponsor and his or her immediate direct report engineering team leads will request a demonstration of a given DevOps tool or function. The adoption team should handle these requests and not divert a production DevOps engineer from his or her duties. And when a DevOps tool is updated or upgraded, the adoption team should develop the method to communicate the new ability, edit the existing documentation and ensure every practitioner is notified about the new features and how to use them.
Adoption Engagement Financials

Deciding how many people to dedicate to this function is a mix of your development environment complexity and what you have currently to complete your DevOps rollout efforts. If you want a 24×7 rollout, then you will need staffing levels to accommodate three shifts, seven days a week, with additional folks for vacations, holidays and sick leave. If you are only rolling out a 9-to-5, five-days-per-week effort, staffing numbers drop significantly. Resources, then, can be organized as one per line of business or one resource for every 50 applications in the portfolio (higher ratios are supportable). Whether you align the resources to the services you provide or to the customer audiences you support won’t matter nearly as much as having at least some resources dedicated to these efforts. As I stated earlier, a complete lack of resources dedicated to this function results in greatly extending the timelines for adoption of DevOps; worst case, in the failure of the transition entirely.

This kind of function is inherently considered overhead. Most DevOps leaders (generally emerging from an engineering background) naturally don’t consider this more administrative function as necessary. It doesn’t strictly add to the engineering capability or skills of the main onboarding teams, so they simply do not include it or divert budget to more “necessary” folks during planning. Organizations that don’t actually provide a guided DevOps service—that is, they simply install the tools and tell the developers to have at it—find their adoption efforts lagging quite a bit as well. The early adopters jump right on without coaxing, but the folks too busy with their own efforts to “try something new” never seem to get around to it. Finally, the guys who think, “Since it ain’t broke, don’t fix it,” will never adopt. Even in this kind of tooling-only services deployment, dedicated adoption resources would have resolved these issues in a far more timely manner. The overhead may be painful, but the alternative is far more painful. Once a company or division experiences a failed DevOps rollout, it rarely returns to try again, and the overall costs could be doubled or worse.

For organizations with the vision and perseverance to employ dedicated resources to facilitate adoption, the converse of the problems outlined above becomes the norm. Developer teams have the information they need to understand their own need and, more importantly, the benefits of adopting DevOps. The work relations between DevOps service provider and DevOps service consumer become highly efficient and mutually beneficial. The entire organization benefits from effective communications from the executive sponsors at the top to the engineering practitioners at the bottom. Execs know the costs, the progress, what is new and how it will help them reduce costs or speed up delivery. Practitioners know how to use the tooling, why it will help them and how to stay current on the changes that come along (and they invariably do). Practitioners appreciate being current on a given tool or skill set; this provides a way to do just that.

Impacts to the Bottom Line

Discreetly measuring the ROI for the application of adoption/engagement resources is a bit squishy. As a general estimation, take the timeline of the DevOps rollout you originally planned and multiply that by two to three. The cost of that delay in timeline (plus the risk of complete failure) is the cost delta to measure against hiring a few more folks (or allocating them from lesser-used areas already on staff). Usually the cost of failure far outweighs the benefits of expanding the overhead support teams as needed. In addition, the cost of a failed communication effort can grow over time. At the outset or launch of DevOps, the communications, whether in document or oral forms, will be fully up to date. But over time, as vendors add new features and new versions of the tooling emerge, practitioners won’t know how to take advantage of the new capabilities. Since many of these new features enhance speed or accuracy, the tendency to not use them—or use the inconsistently for lack of knowledge—will add up.

I find the resistance to the idea of adoption or engagement resources often is founded in the notion that engineers are plenty smart enough to figure this stuff out on their own and they will naturally gravitate to it, as ultimately it makes their lives easier and better. Yes, the engineers are smart enough and some will. However, engineers often build their own “ecosystems” of how an application should be built (which few others could understand or improve upon). They often are reluctant to tear this down in favor of corporately implemented templates (that everyone could understand and improve). They fear the loss of unique skills the company must depend upon. They fear the loss of being “special” and needed. Even though DevOps standardization makes builds and deployments consistent, reduces trouble tickets and improves quality and speed—which ultimately translates into fewer 2 a.m. phone calls for engineers to come fix—they are still reluctant to change (just like the rest of us). Having dedicated resources to help them through the value of this, and assure them of their continuing value in a differing area (the code we want them to write), can make a world of difference and ensure a transition does occur.

To continue the conversation, feel free to contact me.
July 29, 2016
Where’s the Heat? Talking DevOps, Use Cases and More

Transitioning your organization from a traditional IT infrastructure into the world of DevOps is certainly a journey. Sometimes a long one, with many obstacles, but undoubtedly a voyage with a worthwhile prize at the end. Many organizations just embarking on their DevOps journey find themselves wondering, what use cases should they attack first? And who is driving these initiatives?

Recently, Amy DeMartine, senior analyst at research leader Forrester, and Wesley Pullen, general manager and vice president of Deployment Solutions at Electric Cloud, participated in a discussion to answer these questions and discuss how to orchestrate the DevOps tool chain, how to approach application release automation, and how DevOps fits in the greater scheme of compliance and auditability. For folks just beginning their DevOps journey—and IT pros who have been walking the walk for years—there were some great takeaways from their discussion.

DeMartine started off the discussion with something so basic that many folks often forget to consider it before starting their journey. But it is one of the most fundamental and important steps before beginning to explore DevOps; that is, answering the question, “What is DevOps?”

Here’s a great definition used by Forrester:

DevOps provides a set of practices and cultural changes—supported by complementary tools—that automates the software delivery pipeline, enabling organizations to win, serve, and retain consumers better and faster than ever before.

Part of this is the idea of taking the huge monolithic releases of the past and breaking them up into smaller and smaller pieces—at least on the agile development side of things. Then infrastructure and operations folks get involved and complete the continuous delivery life cycle by automating builds and testing and making sure releases are consistent and fast. Finally, there is collaboration among development, operations and security to make the product even more successful than before—and in all of this, you are creating feedback loops and building quality as well as consistency.

So now that you’ve got an established idea of the fundamentals of DevOps, let’s dive right into use cases. One of the most often-cited use cases is the idea of governance. People venturing into DevOps love the idea of moving faster and delivering more quickly than ever before, but find themselves asking, “How do you do that safely?”

It’s helpful to look at this using the visual of an upside-down triangle, with governance at the top. It applies to all companies and gives them the ability to control their releases all the way from development to production. Part of the benefit of using DevOps is that all of these tools you are using are creating log files, which essentially are breadcrumbs that give you an easy way to follow an audit trail. If you’re using a standard technology stack across a single application and apply it to multiple applications throughout your organization, you have the ability to look at governance across all of these various applications through the same lens.

On the next level of the triangle is compliance, which, depending on your industry, can mean a variety of things, but they are usually predefined and concrete. Finally, the bottom of the triangle is the audit aspect, which is where the best practices of DevOps become the most important.

DevOps Drivers

Ultimately, there are three different drivers of use cases that we see in DevOps, each with unique needs and perspectives. The first of these drivers are folks involved with infrastructure and operations. We often see projects and initiatives coming down from CEOs, CIOs and other senior executives in which the operations staff is driving the initiative and ultimately is responsible, so the initiative gets the budget. This is very hot in financial services.

Another driver are members of IT ops, DevOps and enterprise architects. These members often are focused on cross-team, cross-project initiatives. These are the senior architects, developers and operations staff that all are working together on a single solution. They already have the tools in place, but want to drive and orchestrate an end-to-end solution. Whether they are doing a build or need to make a quick change to provision a server, their goal is to consolidate and have a seamless pipeline.

Finally, the development-driven initiatives are coming from senior architects, development leads and QA who are pushing all kinds of different automation aspects, including continuous integration, continuous testing and continuous delivery.

Diving deeper into these heat zones and specific drivers, it’s helpful to look at what these groups are really focusing on. The top automation initiatives within the subgroups of infrastructure and operations folks start with the need to do deployments faster. They need to drive deployment automation faster. They also are interested in release management, or coordination across a release stream for different teams. When an organization has a series of activities across multiple teams, there is a distinct need to release everything at once to make sure it works. This group also is focusing on compliance and audit—particularly in highly regulated industries such as health care, financial services and insurance—and is always driving initiatives in which it’s trying to build out auditing packages.

In cross-team-driven initiatives, members include IT ops, DevOps and enterprise architects who are focused on cross-teams, and the cross-project initiatives primarily focus on end-to-end orchestration. They also are concerned with cloud resource management. When teams are paying for tools, they want to make sure they are maximizing their value and getting the most use possible out of those resources. That can mean scaling up or down in strategic ways to get the biggest “bang for their buck.” Finally, this group also focuses on configuration management orchestration.

Lastly, developer team-driven initiatives are focused not only on items such as continuous delivery, continuous integration and continuous testing, but also on container orchestration. As there is a greater awareness of potential security holes in Docker, it is necessary to place an increased emphasis on container orchestration, particularly with more and more individuals moving to containers. There also is an increased focus on QA lab provisioning. With the incredible growth in the realms of the Internet of Things (IoT) and embedded, these areas are correspondingly heating up for developer team-driven initiatives. One example put forth in the discussion between DeMartine and Pullen was a recent issue around one of the most well-known IoT devices on the planet—the Nest smart thermostat. In January, Nest went down, leaving many people without heat. This is a great example of why development teams want to focus on IoT use cases: DevOps enables rapid fixes for the massive demands of the IoT world.

Ultimately, you can see from these use cases and initiative drivers that DevOps offers an incredibly dynamic opportunity, ideal for meeting the needs and perspectives of organizations from top to bottom—and the incredible growth of DevOps, as the organizational structure for IT organizations across multiple industries proves that out. In fact, DeMartine and Pullen polled the audience during their discussion and found that 61 percent of attendees planned to adopt DevOps practices in the next 12 months, while 83 percent of attendees planned to adopt deployment automation/ARA in the next 12 months.

If you aren’t already considering DevOps for your organization, whether you are and CEO or a developer on the front line, it is worth investigating to see how it can answer your most pressing challenges and use cases.

The full conversation between Amy and Wesley is available here.

About the Author / Sam Fell

Sam Fell is the Head of Marketing at Electric Cloud, responsible for driving awareness and demand for our DevOps Release Automation and Acceleration solutions. For 20 years, Sam has helped companies achieve success by marketing, selling, and implementing DevOps Release Automation, IT Change Management and Application Performance Management solutions. Prior to joining Electric Cloud, Sam held leadership roles at BMC, CA, Marimba and Nimsoft.

Sam holds a Bachelor of Arts degree from Illinois Wesleyan University.

June 10, 2016
The Limits of Project Management

Here are some other ROELBOB’s you might like

W Edwards Deming Finds His Roots

The Pink Slip

Another Pink Slip

Hot off the Press – Other great devopsy.kinsta.cloud content

DevOpsSec: 1 in 16 Chances

CIOs Must Fight for Relevance in Face of Tech Storms

— ROELBOB

December 17, 2015
Enterprise DevOps and the Project Management Office

Welcome back to this occasional devopsy.kinsta.cloud series on Enterprise DevOps Q&A. Remember, if you have questions about DevOps in the enterprise, let me know and I will try to answer them (or find someone who can). E-mail me at andi.mann@ca.com, tweet me at @AndiMann, or leave a comment below.

This week brings a question about DevOps that could only come from a large enterprise:

Q. For software development and IT operations, the picture is quite clear. But in my company the PMO has so much control over what projects we take on, what their scope is, when they are due, etc. How can I encourage and enable DevOps in our PMO?

Startups and ‘DevOps unicorns’ likely have never worried about dealing with a Project Management Office (PMO), but this is a very common process gate for enterprise-scale organizations. The PMO provides essential capabilities to plan application strategy, gather requirements, prioritize projects, allocate resources and budgets, manage project risk, and report on delivery, especially across complex organizations. However, as with many uniquely ‘enterprise’ departments, the PMO often seems like a significant bottleneck too.

That means enterprise DevOps initiatives must bring the PMO along too. After all, you cannot deliver business-critical software faster if you have no idea of your business priorities or requirements. You cannot claim a successful release without measuring how (or if) it has delivered on business goals. While this will often happen organically in small businesses, in large enterprises this is the remit of the PMO.

Unfortunately I have not seen a lot of ‘best practice’ (or even ‘good practice’) advice on this yet, as DevOps discussions have focused mainly on smaller organizations. However, what I have seen working in large enterprises to foster a closer relationship between the PMO and the DevOps teams is a shared approach to agile Project and Portfolio Management (PPM).

I have seen this shared, agile PPM working in three key ways:

Align development with business priorities

First, a shared, agile approach to PPM helps the PMO and DevOps teams come together and collaborate to prioritize development of capabilities that matter to the business. The PMO shares portfolio priorities and project plans with dev, ops and other stakeholders; dev and ops share development estimates and operational requirements to enable accurate planning with realistic timelines. DevOps teams can help foster this collaboration by bringing PMO stakeholders into requirement gathering and agile planning, even into standup meetings as part of the scrum methodology. This benefits DevOps teams too, by ensuring immediate feedback and shared alignment against business goals.

Manage agile parallel development and continuous operations

Second, encouraging DevOps teams to track and report on timelines, resources, and deliverables helps the PMO to report back to business leaders on progress across multiple parallel projects. In large distributed enterprises, DevOps teams can assist by sharing granular project status (e.g. burndown, commits, etc.) with PMO stakeholders, so they can measure delivery against business objectives. Shared project reporting also helps DevOps teams to measure themselves, and assign responsibilities appropriately too. This shared commitment to business deliverables is itself a key objective of DevOps in any size organization.

Measure and iterate the SDLC

Third, a shared, agile PPM approach can help drive iteration back into development. After new features have been released, shared reporting means the PMO can immediately measure the impact of new releases on business priorities. This also allows them to ensure DevOps teams have delivered against the prior plan before they reassess the current portfolio and start on the next plan. With shared project reporting, the PMO can adjust project plans to reflect achievements, prioritize the new set of macro and micro gaps, and close the feedback loop back by driving requirements into the next development cycle.

Shared, agile PPM tools and solutions

Much of this change – as with all DevOps change – is primarily cultural; it is not necessary to use specific PPM tools to enable an agile, shared approach to PPM. However, as with many activities in DevOps, automation and tooling can certainly help. Especially in large enterprises with complex portfolios and geographically dispersed teams, a shared PPM toolset may be essential.

As you mature and move from waterfall to agile development and DevOps, all stakeholders will appreciate a shared PPM solution that allows a business view of the current application portfolio, a shared view of planning and priorities, common management for both waterfall and agile projects, and roll-up reporting of application delivery and portfolio value. You may find your current PPM solution already fits; or you may need to consider supplementing or replacing it.

Where agile and DevOps aim (at least in part) to accelerate time-to-market for new business ideas by bringing business closer to service delivery, a formal Project Management Office can seem like a brake on productivity. However, as the whole business needs to go faster, IT teams can help bring the PMO onboard the DevOps train with a shared, agile approach to Project and Portfolio Management.

October 7, 2014