DevOps’ aim is to create efficiencies in the software delivery process. But, it doesn’t always work out that way. Sometimes DevOps initiatives lead to mistakes—something we lovingly call a “DevOoops.” CloudBees recently polled some colleagues and came up with five examples of a DevOoops in action. Following is a discussion submitted by consultant Viktor Farcic about siloed departments.
Scenario:
A real obstacle is cultural and caused by having siloed departments. When we start looking at a system as a whole and detecting areas of improvements, the answer tends to be, “This is not our department; we don’t know them, they won’t speak with us.” Those siloes are the main argument in favor of DevOps; it tries to remove them. But, in reality, most companies fake it by creating yet another silo called the “DevOps Department.” DevOps in practice directly contradicts DevOps ideas.
More than a half century ago, while working on compilers, Melvin Conway nailed what is now the crux of the problem we are seeking to solve with modern software development and DevOps practices: “Organizations which design systems,” he stated, “are constrained to produce designs which are copies of the communication structures of these organizations.”
This concept, known as Conway’s Law, suggests how failure to break down silos and organize cross-functional, collaborative teams lingers today as one of the most overlooked steps to implementing DevOps and, despite all best intentions, results in dysfunctional software.
Most companies are organized by function—with business, project management, project owners, developers, quality assurance, app deployment, infrastructure and security groups all focusing on their own areas of expertise.
DevOps initiatives attempt to break down these silos. But it’s easier said than done. Most organizations embarking on DevOps journeys have to deal with an “us versus them” mentality.
Organizational issues create tension, resulting in difficult, friction-laden handoffs between teams. The problems often show up in the software delivery process and in the software itself in the form of quality gaps, inconsistent user experiences and other issues.
Picture this: Input to the application is coming from multiple nonaligned sources, each with its own particular variant on the user experience. If a business analyst and a developer interpret a customer requirement for the customer differently, the end product won’t meet expectations. If you have one team responsible for login and authentication and another responsible for the primary landing page, you can have a login identification that looks and feels different than the core landing page does.
Organizations need to acknowledge that culture will have a direct bearing on DevOps success and commit to taking on those challenges. It won’t be easy. It won’t happen right away. But, with some work, it can get done.
Here are three strategies for removing organizational blockers and avoiding this particular DevOoops.
Alignment – Think about how to best align real or virtual teams organized around products, product functionality or features instead of skills sets or functional groups. For example, construct a small agile team around middleware that includes representatives from the business, developers, quality and operations input.
Communication – Continually encourage communication, trust and transparency. This can be done by using real-time communication tools such as Slack and by centralizing and sharing data using tools such as Jira. Teams need to break down the lingering feelings of distrust. It’s OK to not be perfect. Organizations should set up reporting mechanisms that include successes and failures—all in the name of creating a better final product.
Inclusion – Involve key stakeholders early and continuously. Once you have built these teams, as you embark on your DevOps journey, make sure all stakeholders in the software have a voice. You need to create a common understanding of what their individual needs are and align those around team needs, which sets the stage for ongoing collaboration and communication.
Takeaways
Organize your teams around subjects such as product and functionality and include all the stakeholders in the software development process in these product or feature teams.
Culture in DevOps is just as important as process, practices, tools and technology, yet it’s one of the most difficult things to change.
Takeaways from a recent conference suggest more work is needed in DevOps adoption among organizations
This was a question explored by CIO Platform Nederland and the DevOps Agile Skills Association (DASA) in a recent event I attended, hosted by Transavia. Many organizations have already embarked or are about to embark upon Agile transformation initiatives, driven by growing business demands. This event focused on sharing experiences, learning from the practical examples (successes and lessons learned) from Transavia and ABN AMRO, and exploring the way forward to successfully create a high-performing IT culture that is “Fit for the Future.”
The event was well-attended—unsurprising, really, when you remember the wise words from the late Robert Stroud, former Analyst at Forrester: “To unlock the promise of DevOps, CIOs must lead and support a cultural change within their technology management organization, but as any leader knows, changing institutionalized behavior is the toughest of all management challenges. CIOs must recognize when a trend becomes an imperative for survival. DevOps has become this imperative.”
DevOps and Agile transformations being seen as imperative for business survival. But not just business survival, according to the “2017 State of DevOps” report, which declared, “By 2020, half of the CIOs who have not transformed their teams’ capabilities will be displaced from their organizations’ digital leadership teams.”
Rik Farenhorst, CIO of Transavia and chairman of the DASA Leadership Forum, presented lessons learned from Transavia. He stressed the importance of changing mindsets and giving equal, if not more attention, to creating desired “behavior” change and not relying too heavily on structure, processes and automation and hoping that the right culture emerges. “People first,” “live your values” and “lead by example” were his key messages, stressing that values must be translated into corresponding desired behaviors as well as unlearning old ways of doing things. Another important discovery was accepting that not all teams are so far and not all teams can mature at the same speed.
A great example of “lead by example” was the leadership team’s daily standups and visualization of strategic priorities, gaining more situational awareness and shared understanding and commitment.
Matthijs Dee and Ivo Carton from ABN AMRO presented their journey from Agile to DevOps, also pointing out the fact that teams mature at different speeds and the need to share lessons learned between teams. ABN AMRO adopted a DevOps playbook that teams could use, containing a kind of toolkit for improving team capabilities. Equally, Dee and Carton noted ABN AMRO’s challenges in moving from “command and control” and traditional hierarchic management models to new leadership styles and behaviors. In ABN AMRO’s case, the organization needed to focus on BizDevOps—it’s not all about code, it’s about delivering business value.
Farenhorst mentioned “values” in his presentation, while Dee and Carton mentioned “principles.” Both of these concepts need translating into team behaviors and leadership behaviors must help empower teams to make this shift.
My presentation, “DevOps Will Fail … Unless,” I revealed the findings culled from more than 400 global teams having participated in the Phoenix Project DevOps simulation and gave a Top Three set of takeaways.
The first was the need to focus on BizDevOps—making the shift from “features” to “outcomes” and from a flow of “code-to-commit to a flow of “idea-to-value.” This was also one of the top challenges for organizations at the most recent DevOps Enterprise Summit.
My second tip mirrored advice from Transavia and ABN AMRO: The need to define, agree and commit to “desired behaviors” and what is effective collaboration (here is an example of what I mean).
My third tip was embedding continual learning and improvement as core behaviors. DevOps is new and all about experimenting—it is a long journey and needs to be done as iterative improvements. At the same time, the pace of change coming at us is increasing, as is the amount of change. Teams need to be able to respond to change. I also quoted Mike Orzen, author of “Lean IT”: “Improving your work is just as important as doing your work”; as such, impediments and improvements should also be made visible on the backlog of work for teams and leaders must ensure adequate time is given and reserved for work-in-progress, for teams to improve.
Following the presentations were three break-out sessions: “Value Creation and Management,” “Organizational Design – Agile/DevOps at Scale,” and “Sustainable Culture Change.”
These are some of the challenges raised in the Culture break-out session I attended as a follow-up to my presentation:
An interesting discussion was around “control” and how to empower the management layers and have them empower the teams. As a CIO, this layer between you and the work floor can diffuse your vision by the time it reaches the shop floor and at the same time leave you unaware of what is happening.
Management by walking around was suggested, as a CIO being visible on the shop floor and soliciting feedback. Listen to concerns and enter into a dialogue about vision, goals and what it means.
Teams often are faced with fear, uncertainty and doubt (FUD) about new ways of working. What will it mean to their job? To their responsibilities? And will they be able to do it? Leaders must remove the FUD and create a safe environment. Safe to take risk, to experiment, to fail, to give feedback. Managers must foster a “no blame” culture.
A study by Google (2012) called Project Aristotle, named in tribute to Aristotle’s quote, “The whole is greater than the sum of its parts,” looked into why some teams work and others don’t. One of the key conclusions was that “psychological safety” was the “it” factor: A sense of confidence that the team will not embarrass, reject or punish someone for speaking up.
Change team behaviors. We adopt these approaches and don’t see the behaviors we expect. Not everybody wants to change. Leaders need to be able to identify the silent killers, what is under the water, what are drivers for working against. At the same time, teams need to be willing and able to work effectively as a team and need team training (not just individual training). Team training also needs to address soft skills such as communication, feedback and collaboration.
Leaders also need new skills in organizational behavior management to be able to identify behavior drivers and how to create sustainable behavior change.
Lead by example was named, but what is that? What behaviors are expected from leaders? Sometimes managers are only one step ahead in this new working. DevOps is new, there is no fixed framework; it is about experimenting what is right for your organization. This is all new.
Ask yourself, “Why are we doing Agile, DevOps, Lean? Are we adopting these approaches as a goal in themselves? Or are they to solve a specific set of problems or deliver a specific set of results? And how does this relate to strategic goals?” This must then be translated into, “What is in it for ME?” for the various stakeholders (business, IT management, teams, customers). Success can only be achieved end to end, which means all end-to-end stakeholders must understand the “why” if they are to commit to the journey.
Build empathy and trust and asking questions to get open feedback—not telling (command and control).
Authenticity: To build trust, be empathetic to FUD; listen to concerns; demonstrate (words and deeds) how these will be taken seriously; and recognize achievements. Empathy must be authentic; if your behaviors are not seen as real, you will lose the trust you are trying to create.
Shift from a (real or perceived) “blame culture.” Failure is OK as long as we learn and improve as a result. If there is no trust, then people fear consequences of making mistakes and are less willing or likely to want to experiment or speak up.
Leaders should show vulnerability, too. Set an example of having failed and learned. Admit in these turbulent times when new ways of working really are new, managers don’t have all the answers—it is a journey of experimenting, learning and improving and giving feedback.
Allow teams time to learn and discover themselves. Recognize that not all teams mature at the same speed, appropriate leadership styles and coaching for teams. Use external (to the team) coaches.
Be prepared for the difficult discussions and decisions. Not everybody can and not everybody wants to change. If you are dependent upon heroes, get rid of them—literally or metaphorically. One example noted was a toxic working culture with teams held to ransom by the hero, while another example was having the hero share knowledge, coach and create more T-shaped capabilities.
Look for “change champions” in teams—peer level respect. Empower them with the right skills and recognize their contributions and the team successes. “Give a podium” to success from desired behaviors such as experimenting, learning and improving.
From the discussions it was clear that C-level managers need to learn new skills and demonstrate new behaviors, while management layers must learn more behavioral and organizational change skills. Teams must not only learn DevOps technical skills, but also team-building and soft skills.
CIO Platform Nederland and DASA will be organizing future events and sharing content and experiences from member organizations to address these needs as a follow up to this kick-off event.
A survey of 336 developers, web product managers and DevOps practitioners published by SolarWinds, a provider of IT management tools, finds they spend most of their time troubleshooting applications—so much so that there is little time for strategic projects such as transitioning to DevOps practices.
Joe Kim, executive vice president and global chief technology officer for SolarWinds, said that while senior IT leaders continue to preach about the critical role DevOps will play in changing their IT culture, IT staff still spends too much time dealing with tactical problems to implement any of the goals defined within a longer-term strategic plan. More than half of respondents (53 percent) said troubleshooting application issues is the top task completed on a given day.
Because most of their time is spent on troubleshooting applications and not on managing and/or deploying applications, Kim said, many employees suffer from low morale. Then, before many IT leaders realize it, their best people are being lured away by the promise of working for an organization that enables them to focus more on the parts of IT process they enjoy, he said.
In fact, Kim noted, in this situation IT leaders that embrace DevOps are in danger of losing credibility. If IT leaders tout the benefits of DevOps, and yet the internal IT staff is spending most of their time on application troubleshooting, chances are good many of the rank-and-file IT professionals will conclude their leaders are out of touch with their everyday reality. IT leaders would be well-advised to engage more with their IT staffs to make sure their strategies are more informed by that IT reality, he advised.
The survey also finds respondents are spending less than 25 percent of their time proactively optimizing performance of their IT environments. Being able to spend more time on this aspect of IT is critical, because if more time is spent on proactively discovering issues, less time must be spent on troubleshooting, said Kim.
IT teams should also be trying to push the boundaries of IT automation to reduce as much of the manual drudgery associated with IT as possible, added Kim.
To get a better appreciation for real state of the IT environment, Kim advised IT leaders gather and share metrics with their teams. Not only does that provide IT teams with some sense of accomplishment as specific goals are achieved, the metrics make it easier to get IT teams to rally behind transitioning to DevOps best practices, he said. That’s crucial because any transition to DevOps is likely to fail because of cultural rather than technical challenges.
It’s unlikely the need to troubleshoot applications ever will go away entirely. The developers that create those applications, after all, are only human. But it is possible to make working in IT a lot more fun and rewarding than what most IT professionals currently experience today.
Organizations today are focused on improving the IT delivery process and taking it to the next level. DevOps plays a key role in achieving this goal, if it’s done right. But while the concept of DevOps is not new—it’s more than a decade old—a significant percentage of organizations have not yet implemented or are facing challenges in leveraging DevOps to achieve the intended benefits. Why do some companies achieve success with their DevOps implementation and others struggle? Simple: Those making DevOps work for them started their journey with a clear and implementable strategy. In fact, a number of organizations have formed their business strategy around DevOps.
The relationship between DevOps and agile is complementary; however, DevOps implementation must be looked at differently than agile. It needs to be treated as a separate initiative other than the regular IT delivery scope until it’s established. It requires strategic thinking, significant focus and commitment make it successful.
Key Pillars of DevOps Strategy
The four key pillars for DevOps strategy are:
Identifying the vision and goals.
Identifying foundational factors.
Critical success factors.
Basing the strategy on measurements to track the progress and realization of benefits.
Vision and Goals
Drivers and challenges form the basis for vision and goals. Before embarking on the path to DevOps, it is crucial to analyze the “as-is” situation and understand the current challenges and drivers for doing DevOps. Current challenges could include:
Too many production defects.
Business stakeholders demanding features that the team is unable to deliver.
Painful deployments.
Team burnout and frustration.
Deployments done as ceremonies with multiple teams on call.
If any of these sound familiar, that’s a sure sign your project needs DevOps.
Drivers for creating the vision and goals may be external or internal. External drivers may be improving customer satisfaction by meeting expectations around availability, reliability, usability, performance, features, value and time to market. Internal drivers may be improving operational efficiency (speed, throughput, quality) or improving employee loyalty, improving technical capabilities or simply making deployments less painful.
Critical Success Factors
Below are the key factors in implementing the DevOps pipeline which includes continuous integration, continuous delivery and deployment. The continuous integration aspects cover configuration management, code packaging, branch/trunk implementation, static code quality analysis, code reviews and static security scans. The objective of continuous delivery and deployment is to move the code from the lower environment to the production environment in an automated way. The key aspects as part of the continuous delivery are embedding continuous testing within the pipeline and automating the applicable tests—unit testing, system testing, API testing and/or browser testing, along with the non-functional testing (performance and security). Another key aspect is integrating continuous monitoring into the pipeline—infrastructure monitoring (application and database servers) and application end user monitoring, which provides key input and metrics on how users are using the application and can be leveraged to improve customer experience.
Key pillars of DevOps strategy
Foundational Success Factors
Foundational factors are critical for DevOps to be successful in an organization. Before embarking on the journey, ensure foundational factors are in place, such as management buy-in and support, maturity of the current agile process, conducive culture, collaboration among teams, CI/CD tools and availability of technical skill sets.
It can be difficult for agile project teams to focus on working on the DevOps items along with the sprint-specific “functional” requirements. One way to increase the priority is to include the DevOps-related items in the sprint. That said, it can be challenging to focus and achieve DevOps objectives, as they may take a back seat to functional requirements during the sprint. Another option is to form a DevOps-focused group from within the projects (based on technical skills and inclination for innovation) that is assigned with the task of building and implementing a CI/CD pipeline. If necessary, this group can get help or expertise through suppliers. Forming a DevOps-focused group has been shown to be helpful in terms of achieving DevOps objectives.
Metrics: Identify, Measure and Continuous Improvement
Tom DeMarco famously said, “You can’t control what you can’t measure.” In DevOps, metrics and measurement are critical for success, as implementations take time. Metrics, therefore, should be aligned with goals and vision to track progress. Also critical are identifying the effectiveness of the identified metrics and making any revisions to existing metrics, as well as identifying and adopting additional elements for success.
It is helpful to quantify the “as is” situation at the start of the implementation by measuring the metrics. That allows you to see the kind of progress being made on each of the aspects as you go along.
Customer perspective (e.g. time to market, number of defects per deployments).
Internal perspective (e.g. average deployments per sprint, number of successful deployments, average time per deployment, mean time to repair).
Innovation perspective (e.g. number of enhancements to pipeline).
Though there are multiple DevOps aspects that can be measured, it is better to start small to avoid being bogged down by measurements. For example, you can start by capturing the average time per deployment or time to market and add other metrics as you go along.
Conclusion
DevOps is a critical initiative and focus area for organizations today. To be successful, a DevOps strategy—a top-down approach which provides clarity and transparency within the organization—is necessary. The key pillars of DevOps strategy can help lay the foundation and prepare—and keep—organizations on track during their DevOps journey. The strategy can be part of the project plan for a single project or can be leveraged for scaling out a DevOps initiative throughout the enterprise.
Carmen DeArdo is well-known in the DevOps space mostly because of his work at Nationwide, where he was DevOps leader and technology director. In August of last year, Carmen moved to Tasktop, where he works with other DevOps luminaries Mik Kersten and Dominica DeGrandis, helping organizations along their transformational journeys.
In this DevOps Video Chat, we speak with Carmen about his move to Tasktop and the culture shifts that are almost universal in embracing DevOps.
The video is immediately below, followed by the transcript of our conversation.
Transcript
Alan Shimel: Hi, everyone, it’s Alan Shimel, devopsy.kinsta.cloud, and welcome to a DevOps Video Chat. Today’s guest on our DevOps Video Chat is well-known DevOps personality, Carmen DeArdo, as well as huge Pittsburgh Steelers fan. Carmen, welcome to DevOps Video Chat.
Carmen DeArdo: Thank you, Alan. Great to be here. Glad to be talking to you.
Shimel: Absolutely. So, Carmen, to paraphrase a religious question, this one’s a little different than all other chats we’ve done before, in that we’ve always spoken to Carmen from Nationwide Insurance DevOps team, where you really pioneered a lot of DevOps – not only at Nationwide but set the tone and the course for a lot of DevOps journeys throughout the industry. But now you come to us as Carmen DeArdo as part of Tasktop.
DeArdo: As you said, I always enjoyed, within the DevOps community, talking to other companies. You know, we talked a lot at conferences, where I was a reference customer for some other customer – companies, like IBM, and I was just really intrigued by Mik’s book, which I know we’ll be talking about, and some of the concepts that Tasktop was getting involved with because we were a customer. And I really liked their vision and now I’m here on the Tasktop roster, so to speak, working with customers to help them go through the kind of journey that we went through at Nationwide and also to bring in some of the concept of Mik’s book, which I think can take it beyond, to the next level of what we were doing at Nationwide.
Shimel: That’s fantastic, Carmen, and I – first of all, I wish you a lot of luck in the new position, new sort of career path, and I’m sure you’ll do great because you’re just a great person with this. Well, you mention Mik’s book and I happen to have a copy of it here. It’s called Project to Product. It’s by Mik Kersten. And, not to brag, but I happen to have a signed-by-the-author copy of it, you know?
And I will tell you, Carmen, I was fascinated with some of the concepts in the book and I’ve discussed some of these concepts with people, as part of my devopsy.kinsta.cloud communication, and it really is – this concept of moving from a project-centric IT environment, right, to a product-centric is really – I mean, it’s fundamental, in a lot of ways, right?
DeArdo: Yeah, it is. So I think, you know, we were at DOES London and that’s where they galley copies of the book came out, so the official copy, I think, the coming out party, officially, I think is gonna be in the Vegas conference, and then the book will be available shortly after that to everybody. But – through IT Revolution, but it is a fundamental change and it was something even that Mik and I had been talking about and we had been trying to work through at Nationwide because, before I worked at Nationwide, I worked at Bell Labs for quite a while. And one of the things that struck me when I came to Nationwide was we went – at Bell Labs, we already had this concept of kinda like products, right, because you had your switches, you had your network control points, you had – so work really came to the team. And so we were always working on the next set, for example, way back when I worked on Advanced 800 features, and so we had a team that stayed together and the work came to us and we were very focused on our product, that 800 service concept and then the systems that we build.
So I came to Nationwide, what struck me was almost all the work was done through projects and these projects seemed to have a life cycle, a lot of ’em, that got funded as part of the funding for that year. They started up. You brought all these people to the team. You went through the “norming and forming and storming” kind of parts of the project. And then, once they were done, the project dispersed and the people went. And what you would do – it was very difficult to do – was, if a project touched five or six systems, you would start to allocate – you know, we were using Clarity – two people, three people, a half a person, a quarter person, whatever you thought you needed from those systems.
And so it was a very fragmented kind of experience because the project was temporal; the systems people were all separated and spread out among these projects. Sometimes, a person might be working on a half-dozen projects at the same time. And, you know, you were constantly forming in these teams and so one of the ideas of the product focus is you have a set of people that are focused on that product. They’re gonna live, eat, drink around that product. And it may be more than one team – we’d like to say it’s a two-pizza team that can solve the world’s problems, but we know, sometimes, it’s gonna be more than one team – but still their focus is on the product and now the whole idea of bringing them a continuous flow of work, you’re bringing it to this established product teams.
And the other thing that came up with projects a lot was there was this tension between doing the feature work versus the defects and the risk items and some of the technical debt because project managers were very focused on “You have a budget. You have a set of scope. You’re supposed to deliver that.” So who wants to pay if there’s a vulnerability in a Struts library or making the next thing faster, right? Technical debt is always about – is really about investing to make the next thing go faster, so, if you don’t really have a long-lived relationship with what you’re working on, you tend, just because of the nature of business –
Shimel: You make short-term decisions.
DeArdo: Make short-term decisions. Right.
Shimel: Yeah. I mean, you know, Carmen, that was one of the things I realized in talking to people, about shifting from a project focus to a product focus, and, to me, it was almost – I learned a lesson. I helped take a company public back in the dot-com days – ’99, 2000 – and the difference in how we managed the company as a pre-public, as a private company, to a public company just blew me away. Right? All of a sudden, we were managing in three-month cycles, right? ‘Cause we were managing quarter to quarter ’cause we had to just, you know, go to the street and tell them our results. And you start making decisions that ultimately led to the failure of the company, frankly, because we were making very, very short-term decisions that were maybe good for the short term but not for the long term.
DeArdo: Right. And you know I’m a – you know, we talk about Deming a lot and Deming warned about things like that, right, about the short-term thinking and lack of systems thinking, but you’re right. It drives you that way because the market’s saying, “Well, what’s your next earnings per share? What’s your next report gonna be?” So it does take more – it’s a different way of thinking about things and, really, you’re more in it for the long haul. Now that’s not to say you can’t do things well in the short term because absolutely you can. You can apply all the DevOps practices we’ve talked about. You can run your experiments or ideas of what you think is gonna get value. You can get that feedback much more quickly.
So you can still apply all the things that we’ve talked about and everything, over the last five, six years, but now you’re doing it for the benefit of that product and you can start to tie the business in with how the value’s actually flowing, right? Because, a lot of times, you don’t – a business doesn’t wanna go up and show ’em an Agile team board, with a bunch of different stories, if they can’t relate it to “What’s the value of what I’m getting through this value stream? Right? Where is my value? What’s going on with what I’m trying to do?”
And, with that product focus, it kinda tears down that wall and opens up that black box of IT and says, “Okay, all the way from the idea through deployment, we’re gonna make this work visible and we can see it and we can make decisions and priority calls based on how we’re gonna deploy our resources. And it’s across the features, the risks, the defects, and the investment in debt items so that we can continue to make this product good, not just now but in the future.”
So it seems subtle, but, actually, it’s a very different way of thinking and it even gets back into how things are funded. So I think, in the past, with Agile and DevOps, we stayed away from that left-hand side of the value stream, closer to the customer – we’re kind of in our comfort zone – but now it forces you to engage the business and really have them come along to the journey with you. So that’s another change, I think, in how this applies, versus some of the things we’ve done up to this point.
Shimel: Good. Now – I mean, Carmen, I think you’re so right on with that, though, in that it sounds subtle, but yet it’s so fundamentally different. And I guess one of my biggest fears around it is people are so resistant to change.
DeArdo: Right.
Shimel: And, thought – you know, maybe that it sounds subtle will help sneak it in, right, as a Trojan horse or whatever, but to tell people that they’re gonna have to shift the way they think about this, about the way they go about doing IT in products, knee jerk is “No, we’re not.” Right? It’s –
DeArdo: Right.
Shimel: And that makes it hard.
DeArdo: It makes it hard. And that’s an excellent point, Alan, and I think we’ve been talking about this since I joined, which it’s almost two months now, about the fact that, just like – when I was at Nationwide and gave some of the talks with Cindy and Jim, we talked about the journey. We even had that mountain which showed you climbing to the summit. This is a journey, right? And, if you start out with what you just said and saying, “Okay, you can’t even get started until you do all these things and they involve your business,” you’re right. You’re gonna lose folks right there because “Wait. I gotta change my organization. I gotta change how we do funding. I gotta change this.”
So the way you have to present it and the way I think we’re looking at is we’re taking the customer on a journey. And that journey starts, really, with – and I used to talk about this with you – thinking horizontally. Right? So, when you think of a value stream, a value stream starts and ends with the customer. And if you start to get people to think horizontally and the concept across that value stream and the artifacts that flow from your PPM, your portfolio planning, through your build cycle, through your deploy, and the fact that, in order to get flow, your tools have to be connected, which is where Tasktop essentially was started, was around this concept of connecting your tools, making your tools talk, synchronizing artifacts from tools so, when a defect is created in quality center, it can flow into the backlog of your Agile team. When an instance’s created in ITSM, it can become a defect; it can flow.
So it’s really starting with this concept of “Let’s start with getting the tools talking. Let’s get your artifacts flowing.” And even – and this may sound heresy – even if those artifacts initially are really focused on the work of an initiative or a team or even a project, dare I say, you can still start to utilize the concepts in Mik’s book around the flow framework and see things like lead time, flow time, the flow efficiency, flow velocity. You can still see those things as part of this journey.
Now I think, ultimately, yes, you need to turn the boat more to get that product focus, to get some of the things – advantages we just talked about, but you can start this journey, I think, from wherever you are, as a enterprise, and just take those incremental steps in order to get to the point where then you’re ready to experiment with one product. Right? And then you just wanna start with one product. Pick one product, get one business owner that is interested in this.
And then, from that, you even call it maybe an “experiment,” get some results, and then that’s what starts to change the culture. Right? It’s not gonna be me talking or giving talks; it’s gonna be – you know, I used to joke about this at Nationwide, right? When I would go around to different areas and talk, that didn’t have near the impact of getting one team to actually do something and get results ’cause then that opened people’s eyes and said, “Okay, that is possible. It’s possible right here, right now, and I wanna create my own story.” So you’re absolutely right. It needs to be structured in a way that allows companies’ teams to go on that journey; otherwise, the impact of the change is gonna be too much and you’re not really gonna get any traction.
Shimel: I agree. You know, Carmen, that was one of the first lessons I learned in business a long, long time ago, which is nothing succeeds like success.
DeArdo: [Chuckles]
Shimel: No one wants to jump on a sinking ship; everyone wants to be with the winner. And if you could show that you’re winning somehow, that you’re succeeding, you have upside, everything kinda flows from there. Right? People wanna be associated with that and they’re willing to tolerate and even embrace change, in some –
DeArdo: Yeah. Absolutely. And, you know, and some of the – you know, you can’t just decide you’re gonna wake up today and change culture, right? I mean, you have to do things through what you’re talking about, right? Creating those experiences, those successes, those stories. Stories are very powerful. That’s what ultimately will change the culture, right? Sharing credit. Right?
If it looks like – you know, at Nationwide, if it looked like, “Well, this is Carmen’s show,” that’s not gonna get anywhere. It has to be everybody’s show. It has to be Jim’s show and Jane’s show and Donna’s show and everybody’s show, where they’re now showing how they can be successful. That then really has the impact of changing the culture and showing people that, yeah, this is possible because that team on the fifth floor’s doing this, right? It’s not in this book. It’s not in this conference. It’s that team. It’s that team on the fifth floor and why can’t we do it?
Shimel: Agreed. Agreed. So, Carmen, you mentioned you’ve been at Tasktop now two months. We spoke a bunch about the book, Project to Product, by Tasktop CEO, Mik, but the Tasktop people have really amassed a great Murderers’ Row lineup there. They’ve got you; they’ve got Mik. And I can’t –
DeArdo: Dominica.
Shimel: Dominica DeGrandis, of course. You know, that’s a lot of brainpower. Lot of brainpower over there. What else are you working on?
DeArdo: Well, I mean, it’s obviously a pleasure. There’s a lot of – it’s a great company, it’s a great culture, and Dominica beat me over here by a few months, but to be able to collaborate with folks like Dominica and Mik and then just the whole community, right? Because they were folks that were already in the great community that has been built, that Gene’s built, other folks like yourself have helped build this whole community. I mean, yeah, it’s a pleasure. It’s an honor to be able to talk about these ideas. I mean, Dominica’s concepts of flow and visibility naturally just relate to what we’re talking about.
I thought it was interesting, in the London talk, the London conference, I mean, you go to all these conferences and you can sorta see, over year to year, how things are going and what topics now are becoming more in the mainstream. And there’re a number of talks this year where flow was either in the title or key concept. Jonathan Smart talked about it; Fin had a talk about flow. So flow is kinda where it’s at, I think, now, as people are seeing, “If I’m gonna accelerate my delivery, become more responsive, I gotta understand flow and, as my ex-boss, Tom Payter, would say, where things aren’t flowing.”
And so, with Dominica’s great work that she’s done with making work visible and concepts of flow, her book, Mik’s book now, I mean, yeah, it’s a great opportunity to be involved with just a great company, great culture, and great folks, to see how we can help other companies succeed in the marketplace.
Shimel: I think it also speaks to the coming maturity of the DevOps marketplace, where we’re seeing sort of leaders kinda come together, community leaders come together and combining in ways that it’s sorta synthesis, right? _____ synthesis and I think it’ll lead to yet another wave of innovation, another wave of thinking about these things.
DeArdo: Yeah, I agree. I mean, I think people like Gene have done a great job of bringing people – creating forums for people to come together and the community, as you know and as you contribute to, is very open about sharing ideas. Right? So, for example, I would use – Topo Pal, we both know at Capital One – I would use his example all the time at Nationwide, when people would say, “Well, we can’t do this. We’re not a unicorn. We’re a regulated industry.” I’d go, “Well, let’s see what Capital One has to say about this,” right? They’re a bank. They had a great presentation with auditing, where I think Jennifer Brady was the auditor that came up on stage with Topo and gave a talk.
So it’s just such a great community where people are willing to share and – you’re right – that allows everybody to get better and the whole community is kinda propelling each other forward. So it’s really been a great blessing, honor to be involved, getting to know all these folks and getting to do this kind of work.
Shimel: Absolutely. Well, Carmen, we’re about out of time, but I wanna wish you luck at Tasktop. I think they’re really, really lucky to have you. I’m sure we’ll run into you somewhere on the DevOps conference circuit and we’ll catch up in person. But congratulations on the move to Tasktop. You’ll make us proud, Carmen. Keep innovating. Keep leading. And thanks for being our guest today.
DeArdo: Well, I appreciate the kind words, Alan. It’s always great talking to you and I look forward to keep the conversation going. Thank you very much.
Shimel: All right. Carmen DeArdo – you know, Carmen, I forgot to ask, what’s your title at Tasktop?
DeArdo: My title is senior value stream management strategist.
Shimel: Carmen DeArdo, senior value stream management strategist at Tasktop, our guest today on DevOps Video Chat. Thanks, everyone. Have a great day.
We all learn from mistakes, right? But it would be better if we learned faster and didn’t repeat them in our future exercises. And this is exactly what we will discuss here in this blog.
For a while now, we’ve been overwhelmed by the idea of the DevOps principle. We love how the collaboration between development and operations provides room for automation, continuous integration/delivery and enhanced time-to-market.
But what about the tiny shortcomings we overlook in the process of continuous delivery?
When Carmen DeArdo, Tasktop’s senior value stream management strategist, posed two questions to a crowd of 200 people, they had no answer to give. What were the questions, you might ask?
How many treat their delivery pipeline tooling as an integrated product with a product owner and an architect?
How many have any measure of how long it takes for them to deliver a feature or defect?
Companies treat their delivery pipeline tooling as different components along the delivery chain. And, when it comes to measuring time taken, all that matters is getting the product to the finish line.
These components are important if companies need to avoid obvious mistakes on the path to success. Consider the above questions the next time you set out on your DevOps mission. Within this aspect, measuring team happiness is as important as an integrated delivery pipeline tooling, and time is taken to introduce a feature.
Companies need to strike a balance between managing work and achieving team happiness. This is important if the company has a long-term vision. Unhappy employees burdened with work don’t deliver the expected results. A sustainable pace helps companies ensure that employees don’t succumb to pressure.
Revise the Management Strategy
Organizations need to encourage their managers in a way that they are not put off by the DevOps process but rather motivated to build and maintain their team.
Most organizations emphasize giving managers incentives to deliver expected results, maintain quality, expand team size, set immediate goals and rake larger profits. However, this strategy could backfire when applied to a DevOps implementation.
Companies instead should encourage their managers to create an environment where the teams grow and become flexible, not only contributing to that process but also adding value to other processes, hence, the organization’s overall success. This thought process will lead to a chain of positive outcomes.
Upskilled and Cross-Skilled
Gone are the days when specializing in a particular skill was rewarding! The competitive market is looking for a workforce that is upskilled and cross-skilled. In short, employees need to be a package of multiple skills, with an emphasis on soft skills.
Being multi-skilled not only supports transformational goals but also supports an organization’s goals. When the lack of new skills becomes a constraint, companies must invest in hiring individuals to propel transformation, which is equivalent to investing in automation.
In the process, people have lost control over the overall management of DevOps. Either professionals are in a situation in which the code is not built in the intended way or that the automated part is managed but the steps required for automation are not.
Organizations instead should refocus their attention on the scalable nature of DevOps, building a new, fully automated process rather than automating an end-to-end process over time, as it is difficult and also time-consuming. Hence, automation does not equal the DevOps mission accomplished!
From Idea to Blackboard
DevOps once was more an idea of a team discussion rather than full-fledged process. But we saw 2018 transform DevOps from a mere idea to a part and parcel of everyday business—so much that it defines the way businesses plan their finances, regulations and organizational strategy as a whole.
Additionally, DevOps experts in 2018 emphasized the need for value delivery than just focusing on details of technical practices. This can be achieved by constructing a managerial framework that bridges the gaps between business and technology.
Relieve Your DevOps of Old Tech
Last year also witnessed DevOps professionals moving toward new technology such as containers, Kubernetes and serverless. Why? It’s obviousthese technologies enable DevOps to deliver its promises. Trying to innovate the DevOps process or even innovate its end product with old technology will only take you backwards in the DevOps process.
In 2019, we should realize that holding on to old technology will mean limiting your organization’s capabilities and impact.
Identifying the Right DevOps Adoption Patterns
While there are several DevOps adoption patterns out there, some organizations choose a central DevOps team enabling standard CI/CD tooling. The approach is in sync with DevOps thought leaders’ approach of reducing global complexity.
However, this approach fails at catering to the needs of different teams. With the focus only on addressing CI/CD tooling, many centralized teams struggle with adoption.
In another approach, companies seek to engage ambitious and autonomous tools to use DevOps tools and practices.
This approach tends to match the common DevOps belief, ‘First prove that new work methods fit the enterprise, then spread.’ However, these teams are only successful in delivering projects with high levels of automation involved but have quickly failed to convert team-level experience to company-level.
Let’s imagine Jim works on the development team for a food company and his colleague, Julie, works on the operations team. On a daily basis, Jim focuses on analyzing users’ needs, testing and developing software, while Judy manages IT infrastructure and policies.
Although they share the responsibility of software deployments and application support, Judy and Jim rarely interact with each other. In other words, they operate in siloed functions that do not encourage teamwork.
Many organizations recognize these silos. So, to enhance cross-team collaboration and reduce repetitive work, they are implementing the DevOps mindset. This methodology facilitates constant feedback and creates an environment where the building and testing of software occur simultaneously. But to successfully implement DevOps, business leaders first need to understand what a silo is, how it’s created and its impacts on employee morale.
What is a Silo?
Take development and operations teams as an example. Development and operations work with two distinct mindsets. Operations values stability, which can slow down software updates. On the other hand, development values speed and is encouraged to create, innovate and generate as much as possible.
Silos develop when these departments are structured to work as separate entities with their own visions, goals and responsibilities. If development employees aren’t passing information about software bugs to the operations team, then workflow quickly becomes bottlenecked and productivity suffers.
How Silos Impact Employee Morale
The lack of information-sharing across teams takes a toll on employee morale and transparency, preventing development and operations teams from forming trust and mutual respect. Within silos, the development team might not report a software bug to operations out of fear of being reprimanded. Without an honest and open information sharing system, workflow is not only delayed, but the potential for misinformation increases.
Silos create a structure in which departments focus on their own goals instead of working toward organizational objectives. Eventually, this mentality can lead to hostile relationships between departments, which negatively impacts efficiency and harms the bottom line.
How DevOps Can Eliminate Silos
Implementing DevOps is the natural first step when shifting employee attitudes from departmental focus to organizational goals. This way, employees don’t have to face the daunting task of completely eliminating all silos at once.
By breaking down silos with DevOps, companies can avoid overspending on departments that may be resistant to change. Employers can create momentum for upcoming changes in other teams with the end goal of cultivating a collaborative mindset within every department of their organization.
To facilitate this transition, organizations should assign a DevOps administrator to act as a mediator between departments. This administrator works to communicate and apply the DevOps methodology across teams while navigating cultural differences to facilitate cross-team collaboration. To successfully implement a DevOps mindset, the administrator should keep the following strategies in mind:
Direct teams toward common organizational goals. Team leaders should set specific goals that align with overall business needs. It’s crucial for leaders to point out how departmental goals directly support common objectives.
Design shared metrics. A consistent measurement tool holds everyone accountable and encourages stronger teamwork by enabling leaders to track progress and assign workloads accordingly. For instance, organizations can set up delivery cycle metrics for both development and operations teams to measure how much workflow speed increases for both teams while maintaining continuous delivery.
Organize regular meetings. Inviting team representatives to participate in recurring meetings creates an opportunity for everyone to give updates on project statuses.
How DevOps Impacts Organizations
Today, IT is no longer an isolated function but an essential department within organizations. It’s important that future leaders invest in technology that drives business success while keeping its employees in mind. For example, enterprise, or employee, service management is popular among businesses for its ability to deliver automated insights and support. Many organizations are turning to a modern IT service management platform to bring their employees fast and quality service—two central qualities of the DevOps mindset.
DevOps’ culture of continuous delivery helps shorten resolution time and encourages collaboration among development and operations teams. At first, businesses can struggle with continuous delivery due to siloed IT functions because these established support structures often come with lengthy and outdated processes that slow down delivery speed. However, a DevOps-focused culture supported by an IT service desk empowers developers and operators to deliver configuration changes and resolve issues at a faster pace.
In today’s competitive environment, a silo mentality is a detriment to the innovation required for companies to stay ahead of the curve. Through effective management strategies, the integration of the DevOps mindset will eventually break down silos, increasing collaboration and productivity.
Is your company seeking to hire a qualified full-stack developer? It seems like an easy enough task—create a job listing, read resumes, conduct technical interviews and make the hire. Finding engineers who understand every layer of the stack is difficult, however. Companies compete for the best and brightest full-stack developers and, unfortunately, they are in shockingly low supply.
What’s the solution? One way to circumvent the full-stack developer talent shortage is to leverage telework. By seeking to hire remote full-stack developers, you can gain to a global pool of talent.
There are many other benefits to hiring remote full-stack developers. However, hiring remote developers isn’t always the right fit. Read on to see if your company is ready to hire remote full-stack developers.
Is Your Company Looking to Save Money on Office Space?
Hiring remote full-stack developers is a major decision. When companies think about utilizing remote talent, they usually think of the headache of adopting a new form of work and of managing employees who work out of the office. However, it is also important to note one of the major benefits of leveraging remote developers: the cost savings.
Other benefits to consider: boosted productivity, higher workplace satisfaction and lower incidences of interpersonal issues between coworkers. If you believe your company might be able to benefit from hiring and managing full-stack developers remotely, then you may want to consider beginning your hiring journey seriously.
Does Your Company Prioritize Quality or Community?
Finding the top full-stack developers can be extremely difficult. By opening up your search and tapping into global talent by seeking developers looking for remote work opportunities, you can put a greater emphasis on quality and technical excellence.
If your company is more focused on creating a cohesive community or company culture, you may want to focus on hiring full-stack developers that can come into the office, interact with coworkers and build a rapport with managers, clients and fellow developers.
However, this isn’t to say that it’s impossible to foster caring and authentic professional relationships with remote developers. It may simply prove more challenging.
Are You a Brick-and-Mortar or a Click-and-Mortar Company?
If you run a traditional brick-and-mortar organization that’s been around for a while, it may be more difficult to adjust to change. If you run an online business or if you’re a burgeoning small business or startup that is heavily reliant on tech, then it may be significantly easier for you to adopt telework.
If you do run a traditional business with a traditional office and traditional approach to project management, it may take a bit of adjusting to accommodate for remote workers.
You may want to try out remote work in a trial capacity by bringing on remote freelancers or allowing current full-time developers to work from home for a few days out of the week. If you find your company easily adjust to the changes, then you may want to consider hiring fully remote full-stack developers as well.
Do You Want to Access Global or Local Full-Stack Development Talent?
As mentioned earlier, full-stack developers are in incredibly high demand. Unless your business is headquartered in a major city, it’s going to be next to impossible to find the top full-stack developers. If your company is just starting or simply short on cash, then it can be difficult to bring on such an expensive full-time employee as well.
If you want access to global talent, you’ll need to open up to remote work. Through telework, even companies in small cities and towns can gain access to top talent. If you’re more interested in fostering local talent, however, you might not be interested in leveraging telework.
Conclusion
Hiring remote full-stack developers isn’t always a simple process. It requires your company to remain open, adaptive and innovative. Without these traits, managing remote full-stack developers will prove challenging to say the least.
How can you ascertain if your company is ready to bring on remote talent? First, it’s important to assess how much cost savings, boosted productivity and higher workplace satisfaction rank for you. In addition, it’s important to gauge whether community outweighs the desire for the production of quality code.
Finally, you’ll want to access your technological readiness and ability to adapt. Are you willing to search for global talent and leverage technologies, platforms and software programs that will assist you in this endeavor? If so, you may want to consider hiring remote full-stack developers.
One of the things that has bemused me from day one of the DevOps movement is how culture is viewed with an odd dichotomy. It is simultaneously DevOps’ greatest strength and its greatest weakness.
Of course, there is a simple and reasonable explanation for this phenomenon. DevOps wants to change culture. Cultures that are resistant to change are typified as “bad” and those that are not are typified as “good.” It is never that simple, but that’s how the portrayal goes.
After a decade, you would think we’d have massive IT culture change supporting DevOps initiatives at one level or another (somewhere on a scale from pilot project to corporate standard) pretty much everywhere.
But data seems to indicate that this is not the case. Disclaimer here: I fall more on the “automation” side of the “What is DevOps, really?” question. I don’t think that matters here, since I’m pointing at data from the DORA “State of DevOps Research Report,” which is 1,900 of you all speaking, not me.
Image Credit: DORA State of DevOps Report
Most of the coverage on this report is by people who have bet their entire career on DevOps—a solid bet, but one that can lead to stilted coverage, which takes all the positives and hoists them high. And there is a lot of positive to be found. But I’ve noticed a trend of not looking at the data with a critical eye. The bit that I’d like to focus on today is what DORA labels “Firmographics”—a breakdown of respondents by title.
Only 27 percent of those who responded were on a DevOps team. Presumably because Google is a sponsor of DORA, it included Site Reliability Engineering with DevOps teams, and that’s a fair inclusion, since SREs by definition are doing DevOps.
Consider that data point representing “culture change” in a world where the respondents are, by self-identification, doing DevOps. Some will argue this is the wrong way to look at it, but one of the issues that culture people bring up constantly is breaking down silos and organizing around product or product portfolio instead of development and operations. But it seems more as though organizations are knocking holes in silos and communicating through them—which means we should pay more attention to that style of DevOps and quit harping on organizational change. Again, this fits well with my world view, which has always been “That specialist in a shared bit of hardware is not moving to a DevOps team.” The EMC specialist (for example) adds value to the entire org because of their domain-specific knowledge, not because of their deep understanding of the entire DevOps toolset. Once you’ve carved out exceptions for storage, networking and platform specialists, moving everyone to a DevOps team is pretty moot.
I won’t conjecture why only 27 percent are moved into dedicated teams, nor why that number did not go up from 2017. I have a predilection toward “because it’s not necessary,” but likely there will be two camps when this discussion gains steam because more reports show a low rate of change—Group A will be, “Because those people are resisting change,” while Group B will be, “Because those people don’t feel they need change.” Guess what? That will be the same group of people, and that angle of discussion will be irrelevant. The important bit will be, “Are you completing everything you need to get done, and what is your structure?” That’s where the meat of the discussion will need to occur. Because by deduction, 73 percent of people participating in the DORA survey are doing DevOps while not being on a dedicated (eg: reorged) team.
And that’s perfectly okay, as long as they’re achieving the goals, that’s what matters. The how is useful when deciding to move in a certain direction, but delivering is the thing IT should—and generally is these days—be gauged on.
With competition becoming more intense for development companies, project management is becoming a more integral part of every project. It’s no longer limited to the actual creation of a new project. Now, it’s about planning, communicating, collaborating and analyzing. With so many moving parts, it’s difficult to understand all of the important phases of project management.
This guide will cover all the phases of project management so you can understand how they apply to your projects in DevOps. Even if you don’t have a background in project management, you’ll be a pro in no time.
Defining Project Management
First, we need to articulate exactly what project management is. It’s the discipline of initiating, planning and executing the work of a team to achieve specific goals within a time frame. It involves a lot of interteam collaboration, and it isn’t any single activity.
Project management experts draw knowledge from areas including human resources, communications, risk management and even accounting. That being said, there are a lot of moving parts that can make project management tricky, particularly with large projects or growing teams. Knowing all of the phases of a project process makes it possible to navigate these areas effectively.
A project process is any unique action that represents the entire project internal process within DevOps. This is usually decided by the project manager. It might include instructions, procedures, plans or organizational software.
Understanding the Phases of Project Management
When you’re talking about the project life cycle, you need to understand the project management phases. Throughout the project life cycle, you should be able to define clear goals. These will include a combination of the following:
What will be accomplished?
How will you measure what has been accomplished?
Who will work on the project?
How will you monitor progress?
Having these questions above in mind will direct the project along its life cycle. Without any clear initiative or direction, you can’t expect team members to know where to go with their tasks. That’s why clear goals are key in the world of DevOps, where every task matters.
Now that you know the importance of clear goal setting, it’s time to finally define the phases of project management. There are five in total, and they are:
Initiation
Planning
Execution
Performance monitoring
Closure
Phase 1: Initiation
This is the beginning of the project. In this phase, you’ll want to define your goals, what the project is exactly, and how it fits into your company goals. One of the biggest pitfalls in the world of development is choosing to start a new project for technology’s sake. While there’s always something to be gained in innovation, avoid falling for shiny-object syndrome. Just because you have new technology doesn’t mean it makes sense as part of your bigger business strategy.
To make sure you’re choosing the right project for your team, ask the following questions in this phase:
Why are you choosing this project now?
Is this project realistic?
What does the end result look like?
From there, you’ll need to get approval for the project from higher-ups. This might take some time, so be sure to articulate your goals clearly at this stage so you don’t waste energy. Finally, you or your project manager will create a project initiation document (PID), which is a formal outline of the purpose and requirements of a new project.
It’s smart to include developers across teams in these initial meetings to ensure they can give guidance about the technical challenges of a new project. Remember, collaboration is key at every stage.
Phase 2: Planning
Now that you’ve gotten the green light, it’s time to create a plan of action. This will involve goal setting and job responsibilities for all team members of all levels. Don’t forget about the S.M.A.R.T. goal-setting process to make sure you’re creating goals that are realistic. Remember, smart goals are specific, measurable, attainable, realistic and time-bound by a deadline.
This is the most vital stage of project management. It’s when you’ll put pen to paper and work out any kinks. Poor planning will reflect itself in every stage after, so take the time to work with teams to decide the best plan of action. Limit your deadlines for every task to 10 days or les to ensure you don’t let obstacles take away from your final product.
Phase 3: Execution
The time for planning is over and now it’s time to get down to business. This is exciting because you’ll see your project start to shape itself. Your programmers are busy coding, designers are building graphics and managers are creating progress reports.
Don’t forget to update your higher-ups during this process, even with small changes. Regular updates are necessary to make sure everything is progressing according to schedule. Conduct weekly meetings to make sure everyone knows how the entire team is progressing as well as their own next steps. A project management software is valuable at this stage.
Phase 4: Project Performance
Now that the project is completed, it’s time to reflect on your success. Did everything align with your original goals? Did you meet your deadlines? Think about your objectives, your deliverables, your cost,and the performance of the project. How did all of these things measure up?
You’ll base your future project plans on the success of your analysis at this stage. Even though the project is officially done, that doesn’t mean there isn’t still more to learn. Also, don’t forget about preparing maintenance for your software going forward. You might need a program like Amazon CloudWatch – monitoring and logging service to continue to learn about the success of your project into the future.
Phase 5: Closure
Your project is completed and your analysis is coming to a close. It’s time to follow-up on any final pieces and close the door on your project for good. This is also known as the post-mortem phase because it’s when you’ll decide your key takeaways and stop progressing.
Project managers will meet together to decide key players, project performance, and deadline analysis. How can you learn from the events of the past few days or weeks to grow during your next project? Don’t overlook this stage. It’s important to reflect on what worked and what didn’t. If something didn’t work out the way it was planning, talk about it.
Finally, host a team meeting to talk about how the project went as a group. You might have a different perspective than those under you, and it’s important that everyone feels heard. Take team member feedback seriously so you can learn from it for next time.
Manage Projects Successfully
In the world of DevOps, project management plays a lead role. Don’t overlook any stage in the process as not being necessary. It’s important to have a well-rounded, thoughtful approach to leadership. There is no perfect way to lead a group in big projects, but you can use every phrase to carefully tackle new challenges and grow your team strengths.
When you practice these stages above, they’ll come naturally. You’ll notice each stage leading gently into the next, and that’s how you make a business that’s ready for anything. Every project manager will experience some level of failure, but learn how to roll with the punches and keep moving forward.
