Team Management Resources

DZone's Featured Team Management Resources

Scaling SRE Teams

By Stelios Manioudakis

This is an article from DZone's 2023 Observability and Application Performance Trend Report.For more: Read the Report From cultural and structural challenges within an organization to balancing daily work and dividing it between teams and individuals, scaling teams of site reliability engineers (SREs) comes with many challenges. However, fostering a resilient site reliability engineering (SRE) culture can facilitate the gradual and sustainable growth of an SRE team. In this article, we explore the challenges of scaling and review a successful scaling framework. This framework is suitable for guiding emerging teams and startups as they cultivate an evolving SRE culture, as well as for established companies with firmly entrenched SRE cultures. The Challenges of Scaling SRE Teams As teams scale, complexity may increase as it can be more difficult to communicate, coordinate, and maintain a team's coherence. Below is a list of challenges to consider as your team and/or organization grows: Rapid growth – Rapid growth leads to more complex systems, which can outpace the capacity of your SRE team, leading to bottlenecks and reduced reliability. Knowledge-sharing – Maintaining a shared understanding of systems and processes may become difficult, making it challenging to onboard new team members effectively. Tooling and automation – Scaling without appropriate tooling and automation can lead to increased manual toil, reducing the efficiency of the SRE team. Incident response – Coordinating incident responses can become more challenging, and miscommunications or delays can occur. Maintaining a culture of innovation and learning – This can be challenging as SREs may become more focused on solving critical daily problems and less focused on new initiatives. Balancing operational and engineering work – Since SREs are responsible for both operational tasks and engineering work, it is important to ensure that these teams have enough time to focus on both areas. A Framework for Scaling SRE Teams Scaling may come naturally if you do the right things in the right order. First, you must identify what your current state is in terms of infrastructure. How well do you understand the systems? Determine existing SRE processes that need improvement. For the SRE processes that are necessary but are not employed yet, find the tools and the metrics necessary to start. Collaborate with the appropriate stakeholders, use feedback, iterate, and improve. Step 1: Assess Your Current State Understand your system and create a detailed map of your infrastructure, services, and dependencies. Identify all the components in your infrastructure, including servers, databases, load balancers, networking equipment, and any cloud services you utilize. It is important to understand how these components are interconnected and dependent on each other — this includes understanding which services rely on others and the flow of data between them. It's also vital to identify and evaluate existing SRE practices and assess their effectiveness: Analyze historical incident data to identify recurring issues and their resolutions. Gather feedback from your SRE team and other relevant stakeholders. Ask them about pain points, challenges, and areas where improvements are needed. Assess the performance metrics related to system reliability and availability. Identify any trends or patterns that indicate areas requiring attention. Evaluate how incidents are currently being handled. Are they being resolved efficiently? Are post-incident reviews being conducted effectively to prevent recurrences? Step 2: Define SLOs and Error Budgets Collaborate with stakeholders to establish clear and meaningful service-level objectives (SLOs) by determining the acceptable error rate and creating error budgets based on the SLOs. SLOs and error budgets can guide resource allocation optimization. Computing resources can be allocated to areas that directly impact the achievement of the SLOs. SLOs set clear, achievable goals for the team and provide a measurable way to assess the reliability of a service. By defining specific targets for uptime, latency, or error rates, SRE teams can objectively evaluate whether the system is meeting the desired standards of performance. Using specific targets, a team can prioritize their efforts and focus on areas that need improvement, thus fostering a culture of accountability and continuous improvement. Error budgets provide a mechanism for managing risk and making trade-offs between reliability and innovation. They allow SRE teams to determine an acceptable threshold for service disruptions or errors, enabling them to balance the need for deploying new features or making changes to maintain a reliable service. Step 3: Build and Train Your SRE Team Identify talent according to the needs of each and every step of this framework. Look for the right skillset and cultural fit, and be sure to provide comprehensive onboarding and training programs for new SREs. Beware of the golden rule that culture eats strategy for breakfast: Having the right strategy and processes is important, but without the right culture, no strategy or process will succeed in the long run. Step 4: Establish SRE Processes, Automate, Iterate, and Improve Implement incident management procedures, including incident command and post-incident reviews. Define a process for safe and efficient changes to the system. Figure 1: Basic SRE process One of the cornerstones of SRE involves how to identify and handle incidents through monitoring, alerting, remediation, and incident management. Swift incident identification and management are vital in minimizing downtime, which can prevent minor issues from escalating into major problems. By analyzing incidents and their root causes, SREs can identify patterns and make necessary improvements to prevent similar issues from occurring in the future. This continuous improvement process is crucial for enhancing the overall reliability and performance whilst ensuring the efficiency of systems at scale. Improving and scaling your team can go hand in hand. Monitoring Monitoring is the first step in ensuring the reliability and performance of a system. It involves the continuous collection of data about the system's behavior, performance, and health. This can be broken down into: Data collection – Monitoring systems collect various types of data, including metrics, logs, and traces, as shown in Figure 2. Real-time observability – Monitoring provides real-time visibility into the system's status, enabling teams to identify potential issues as they occur. Proactive vs. reactive – Effective monitoring allows for proactive problem detection and resolution, reducing the need for reactive firefighting. Figure 2: Monitoring and observability Alerting This is the process of notifying relevant parties when predefined conditions or thresholds are met. It's a critical prerequisite for incident management. This can be broken down into: Thresholds and conditions – Alerts are triggered based on predefined thresholds or conditions. For example, an alert might be set to trigger when CPU usage exceeds 90% for five consecutive minutes. Notification channels – Alerts can be sent via various notification channels, including email, SMS, or pager, or even integrated into incident management tools. Severity levels – Alerts should be categorized by severity levels (e.g., critical, warning, informational) to indicate the urgency and impact of the issue. Remediation This involves taking actions to address issues detected through monitoring and alerting. The goal is to mitigate or resolve problems quickly to minimize the impact on users. Automated actions – SRE teams often implement automated remediation actions for known issues. For example, an automated scaling system might add more resources to a server when CPU usage is high. Playbooks – SREs follow predefined playbooks that outline steps to troubleshoot and resolve common issues. Playbooks ensure consistency and efficiency during remediation efforts. Manual interventions – In some cases, manual intervention by SREs or other team members may be necessary for complex or unexpected issues. Incident Management Effective communication, knowledge-sharing, and training are crucial during an incident, and most incidents can be reproduced in staging environments for training purposes. Regular updates are provided to stakeholders, including users, management, and other relevant teams. Incident management includes a culture of learning and continuous improvement: The goal is not only to resolve the incident but also to prevent it from happening again. Figure 3: Handling incidents A robust incident management process ensures that service disruptions are addressed promptly, thus enhancing user trust and satisfaction. In addition, by effectively managing incidents, SREs help preserve the continuity of business operations and minimize potential revenue losses. Incident management plays a vital role in the scaling process since it establishes best practices and promotes collaboration, as shown in Figure 3. As the system scales, the frequency and complexity of incidents are likely to increase. A well-defined incident management process enables the SRE team to manage the growing workload efficiently. Conclusion SRE is an integral part of the SDLC. At the end of the day, your SRE processes should be integrated into the entire process of development, testing, and deployment, as shown in Figure 4. Figure 4: Holistic view of development, testing, and the SRE process Iterating on and improving the steps above will inevitably lead to more work for SRE teams; however, this work can pave the way for sustainable and successful scaling of SRE teams at the right pace. By following this framework and overcoming the challenges, you can effectively scale your SRE team while maintaining system reliability and fostering a culture of collaboration and innovation. Remember that SRE is an ongoing journey, and it is essential to stay committed to the principles and practices that drive reliability and performance. This is an article from DZone's 2023 Observability and Application Performance Trend Report.For more: Read the Report More

Be a Better Team Player

By Alvin Lee

CORE

API development is a big part of what I love about software. Whether it’s building integrations or crafting APIs for decoupled web applications, it’s usually just me and the code. Most of the time, I work as a solo API developer. Going solo has its perks: fast decisions and full control. But it's a double-edged sword since keeping everything in my head makes handoffs and delegation tricky. And going solo limits the size and complexity of projects I can work on. After all, I am just one person. Postman is my primary tool for API work — sending requests, managing environments, and running tests. I’m familiar with my solo workflow. But I’ve started to wonder: in a team environment, what more can Postman offer? How might it enhance collaboration and streamline the dev process? To explore these questions, I started working on an example API, which I call “X Nihilo.” Example API: X Nihilo X Nihilo helps you generate 280-character tweets based on parameters you store or send. You provide a topic, a goal, a description of the tone to take, and a description of the audience. Behind the scenes, the API will send a request to OpenAI’s API for text completion, which will assist in generating the tweet. In addition, you can save the strings you use for tone and audience then reuse them in subsequent tweet requests. Let’s walk through my basic API dev workflow. Going At It Alone: My Solo Workflow The first step in my workflow is to design the API and write up an OpenAPI spec. In Postman, I created a new API, and then I started a new API definition. After some thinking (and working directly with ChatGPT, which was great for generating an initial OpenAPI spec based on my descriptions), I had my spec written: With my OpenAPI spec in place, I came to a fork in the road. Should I set up a mock server and some example requests and responses to show what it would look like to interact with this API? Or should I start writing implementation code? As a solo developer, I can only be an API producer or an API consumer at any given time. So I decided: no need to build mocks — the consumer in me would have to wait. Let’s write some code! A Few Moments Later… Using Node.js with Express, and talking to a PostgreSQL database, I had my basic API implemented. Here’s a rundown of everything that I needed to build: POST /signin takes a username and password, authenticates against records in the database, and then returns a signed JWT which can be used in all subsequent requests. POST /generateTweet generates a 280-character (max) tweet. It takes a topic (string) and a goal (string). It also takes either a tone (string) or a toneId (integer ID of a stored tone), along with either an audience (string) or an audienceId (integer ID of a stored audience). Whenever tone and/or audience strings are provided, the API will save these to the database. GET /tones returns a list of tone IDs and corresponding strings. GET /audiences does the same for reusable audience strings. DELETE /tones takes a tone ID and deletes that tone record. DELETE /audiences does the same for audience records. After the initial implementation was done, it was time to get back to Postman to start running some requests. Create an Environment With Variables First, I created a new environment called “Test.” I added variables to store my root_url along with a valid username and password. Create a Collection and a Request Then, I created a new collection and added my first request: a POST request to /signin, to try out authentication. With my API server running in a terminal window, I sent my first request. Success! I got my token, which I would need in any future requests. I created a new request, this time to generate a tweet. I made sure to set the Authorization to use “Bearer Token,” and I provided the token that I just received from the previous request. Here’s the response: It works! Summing up the Solo Approach That’s a basic sneak peek into my solo workflow. Of course, I would do a few other things along the way: Write a pre-request script to perform a /signin request and then set an environment variable based on the token in the response. Create requests for all other endpoints in the OpenAPI spec. Write tests for each endpoint, making sure to cover my edge cases. If I’m working solo, this basic workflow gets me pretty close to the finish line. While that’s fine, I know that I’m probably only scratching the surface of available features in Postman. And I know that I would need a lot more from Postman if I was working on a team. The Aha! Moment: Why Consider Postman for Teams? What if I could no longer be a solo API developer for X Nihilo? This could happen due to several reasons: X Nihilo grows in size and complexity, and a single API developer is no longer enough to support it. X Nihilo is only a small part of a larger API project involving multiple API developers or maybe even multiple API teams. Not all of my API projects for clients will be small ones that I can build on my own. At times, I’ll need to be part of a team that builds an API. I might even need to lead the API team. When that happens, I would need to leave my solo mindset behind and leave my solo way of doing things in Postman. That motivated me to look into Postman’s team-related features. Exploring Postman's Team (Enterprise) Features Postman has a free tier, and it offers some limited collaboration features, which might be sufficient if you’re a small team (meaning not more than three developers). Postman has additional features as part of its Enterprise Essentials tier. These are great for API teams in larger organizations that use Postman across the board. Workspace Sharing A workspace lets your teams collaborate on multiple API projects. This is great if you have different teams working on different APIs, but those APIs interact with one another (which is typically the case in larger software organizations). Workspaces are excellent for enabling real-time collaboration. Team members can edit API documentation, work together on crafting requests or writing tests, and build out a mock server that the entire team can use. As edits are made, they’re synced with the entire team in real-time. Version Control While I cared about version control for my code, as a solo API developer, I didn’t care much about version control of my Postman collections or environments. If I change something (modify a request, update a test, remove an environment variable), I’m the only one affected. No big deal. When you work on a team, you definitely want to know when things change. And sometimes, you need to roll back changes. Fortunately, for teams using Postman Enterprise, Postman gives you access to a changelog for collections, workspaces, and APIs. You can roll back collections to earlier points in time. As an API developer on a team, you’ll need this. Most of the time, it’s because Bob screwed up the collection. Sometimes, though, you’re Bob. Role-Based Access and User Organization Not everybody in a Postman workspace should have the same level of permissions. Some team members are testers, and they just need the ability to send requests and run tests — but not modify them. Others might be designers who are only allowed to modify API definitions. In Postman, you can assign roles to team members. This affects the kind of access and level of permission that each team member has within a team or workspace. Teams can also have private workspaces, restricting access from others outside the team. I also noticed that Postman Enterprise supports “domain capture.” This basically means you can set up all the users in your organization by giving access to everyone from the (for example) mycompany.biz domain. Inline Comments and Discussions Postman does have one collaboration feature, which is available on all its plans, not just its Enterprise Essentials. This is the ability for team members to add comments to collections (on folders, requests, examples, or pull requests). Being able to comment and discuss directly in Postman is huge for team API development. Since most of your team’s API dev work will happen in Postman, it makes sense to have your discussion there (instead of in GitHub or some other external service). Team API Development: Postman for the Win Whenever I join a team, I bring the tools that I love using, but I don’t really push them on my teammates. I figure they’ve got their own tools. So, to each their own. But I have a feeling that most API developers have Postman in their toolbelt. It would just be a shame if several API developers on a team all used Postman individually, with a solo mindset, and without taking advantage of some of these team features. If they took advantage of Postman Enterprise features, they would get… Increased Efficiency In a shared workspace, you get to start with the shared API definition. Whenever a team member edits the definition (or documentation or tests or environments), the edits sync up, and everybody has the latest and greatest. Everybody works off the same set of requests in a collection, and everybody has access to all the tests that will be used. All of these conveniences will improve a team’s efficiency, which in turn will skyrocket their development velocity. Fewer Misunderstandings When everybody is working from the same source of truth (your workspace), and they can make comments and converse within the tool they’re using for development, this will lead to fewer misunderstandings. Your team won’t lose time to confusion over whether that endpoint was supposed to take query params or path params. Everything will be clear. Key Takeaway I didn’t know that Postman was for teams and enterprises. Now that I know, here’s my big takeaway: Team players use tools that are good for the team. Postman has been great for me when I’m a solo API developer. Fortunately, it also has features that would make it great for me when I’m on an API dev team. For me, that’s real-time sync of edits within collections, changelogs, and version control, and granular permissions for access. Now, I’m excited to take on larger API projects with larger teams. Happy coding! More

Architecture Decision Records

By Rakesh Rao

Project Oxygen: Breathing New Life into Teams and Organizations

By Arun Pandey

Feedback Loops: The Secret Ingredient for Efficient Platform Engineering Teams

By Keshav Prasad Kuruva

An Agile Coach’s Guide To Storytelling [Video]

On September 5, 2023, we had the opportunity to listen to Bob Galen on “An Agile Coaches Guide to Storytelling.” In this session, Bob shared his experience coaching an Agile coach struggling to connect with a development manager. He underscored the transformative impact of incorporating personal narratives, lessons learned, teaching stories, and purpose or vision stories into coaching conversations. Moreover, Bob demonstrated the compelling power of storytelling in Agile coaching by using stories to share knowledge and wisdom while fostering dialogue. Watch the video now: An Agile Coaches Guide to Storytelling — Bob Galen at the 53. Hands-on Agile. Abstract “I’m going to tell you a story.” “I was coaching an Agile coach who lamented that they weren’t connecting with their coaching client, in this case, a development manager. I asked them to share a typical coaching conversation, and they spoke about a series of questions they asked that essentially went unanswered — leaving them and the client quite frustrated. I asked them what other coaching techniques they had tried, and it boiled down to only coaching stances and only open-ended questions.” “I suggested they experiment with weaving some stories into their coaching conversations. Personal stories, lesson-learned stories, teaching stories, purpose or vision stories, and relationship or connection-building stories. I spoke to them about sharing their knowledge and wisdom with the client via story, not dominating the conversation but augmenting it, and using the story as a backdrop to their questions and explorations with the client.” “They later told me that this small change significantly impacted their coaching after a bit of practice. This talk is about bringing the power of Storytelling INTO your Agile coaching and discovering the magic of the Story. Now, please share this story with others, and I hope to see you in the talk…” Watch the recording of Bob’s session now: During the Q&A, Bob also answered the following questions: How can you utilize stories in Agile coaching without being prescriptive? Any tips to get over the feeling of “people don’t want to hear about me and my stories; they just want facts”? When you are an introverted Scrum Master struggling with ad-hoc verbal creativity, how can you improve storytelling?

By Stefan Wolpers

CORE

An Effective Mechanism for Preliminary Analysis on the Effects of Propensity To Trust in Distribution Software Development

The abstract of this study has established trust is a crucial change for developers, and it develops trust among developers working at the different sites that facilitate team collaborations when discussing the development of distributed software. The existing research focused on how effectively to spread and build trust in not the presence of face-to-face and direct communications that overlooked the effects of trust propensity, which means traits of different personalities representing an individual disposition to perceive another as trustworthy. The preliminary quantitative analysis has been presented in this study to analyze how the trust propensity affects the collaboration success in the different distributed projects in software engineering projects. Here, the success is mainly represented through the request of pull that codes contribute, and changes are successfully merged to the repository projects. 1. Introduction In global software engineering, trust is considered the critical factor affecting software engineering success globally. However, decreased trust in software engineering has been reported to: Aggravate the separated team's feelings by developing conflicting goals Reduce the willingness to cooperate and share information to resolve issues Affect the nature of goodwill in perspective towards others in case of disagreements and objections [1] Face-to-face interactions (F2F) in current times help to grow trust among team members, and they successfully gain awareness related to both in terms of personal aspects and technical aspects [2]. On the contrary, the F2F interaction is more active now, which may be reduced in software-distributed projects [3]. Previous empirical research has shown that online or social media interactions among members over chat or email build trust among team members of OSS (open-source and software projects) that mainly have no chance related to meeting with team members [4]. Furthermore, a necessary aspect, especially for better understanding the trust development and cooperation in the working team, is the simple way of "propensity to trust" [5]. It is spreading the personal disposition of an individual or trust or taking the risk internally addicted to the trustee's beliefs and will behave as evaluated and expected [6]. However, the propensity of trust also refers to team members or individuals who generally tend to be perceived by others as trustworthy [7]. Moreover, we formulated the supporting research questions for this study that include as: Research Question (RQ): How does the propensity of trust of individuals facilitate successful collaboration even in software globally distributed projects? The most common limitation of this research is its relevance to empirical research findings based on supporting trust [8]. The trust represents no explicit extent measures to which individual developers' trust directly contributed to the performances of projects [9]. However, in this study, the team mainly intended to overcome the supporting limitation by approximating overall project performances, including duration, productivity, and completion of requirements. Through successful collaborations, the researcher's team indicated a situation where mainly two developers are working together and developed cooperation successfully due to yielding the supporting project advancement through adding new features or fixing bugs. By such nuanced and supporting gain unit analysis, the research aim is to measure more directly how trust facilitates cooperation in distributed software projects. Modern distributed and software projects support their coordination and workflow in remote work with the best version of control systems. The supporting pull request is considered the popular best way to successfully submit contributions to projects by using the distributed new version of the control system called Git. Furthermore, in reference to the development of pull-based development and model [10], the central repository of projects is to avoid the share among the different developers. On the contrary, developers mainly contributed through forking, that is, cloning repositories and successfully making the changes from each other. The primary condition and working of the pull repository is that when a set of supporting changes is successfully ready to finally submit the results into the central repository at that time, potential contributors mainly create the supporting pull request. After that, an integration manager, also known as a core developer, is effectively assigned the responsibility to individuals to inspect the integrated change in line with the project's central development. While working on software-distributed projects, an integration manager's main role is to ensure the best project quality. However, after the pull repository contribution's successful receipt, the pull request was closed, which is suitable for projects. That means the request of pull is either changed and accepted are integrated into the repository of the leading project or can be considered incorrect that considered as the pull request is changed or declined are rejected. Whether declined or accepted, the request for closed pull requires that the consensus is successfully reached by discussion. Furthermore, project managers also use the development collaborative platforms, including Bitbucket and GitHub, that make projects easier for developers or team members to collaborate by pull request [11]. It helps to provide a supporting and user-friendly interface web environment for discussing the supporting or proposed changes before the supporting integrating them into the successful source code of the project. Accordingly, researchers represent the successful collaborations between the individual developers concerning accepting the request of pull and refine the best research question as supporting or follows: Research Question (RQ):How does the propensity of trust of individuals facilitate successful collaboration even in software globally distributed projects? The researchers successfully investigated the refined questions of this research by analyzing the contributions history of pull requests from the famous developers of project Apache Groovy. Apache Groovy mainly provides archived supporting history through email-dependent communications. Researchers analyze the trace interactions over the supporting channels that assess the developers in an effective way known as “Propensity to trust." The remainder of this research paper is well organized: the next section mainly discusses the challenge and supporting solutions to propensity quantifying trust. In sections three and four, researchers described the supporting empirical study and related its results. In the fifth section, researchers discuss the limitations and findings. At last, the research finally drew a conclusion and better described the future in the sections of this research. 2. Background Measuring the Term “Propensity To Trust” The five-factor or big five personality effective model is used as a general taxonomy to evaluate personality traits [12] mentioned in Figure 1. It includes supporting higher levels such as openness, extraversion, conscientiousness, neuroticism, and agreeableness. However, each higher-level dimension has six supporting subdimensions that are further evaluated according to the supporting dimensions [13]. Previous research has confirmed personality traits that can be successfully derived from practical analysis of emails or written text [14]. According to Tausczik & Pennebaker [15], in the big five models, each trait is significantly and strongly associated with theoretically appropriated word usage patterns that indicate the most substantial connection between personality and language use [16]. Figure 1: Big-Five traits of personality model (Source: Developed by learner) Furthermore, the existing research based on trust has directly relied on data self-reported through survey questionnaires that help to measure the trust of individuals on the supporting given scale [17], [18], and [19]. In addition, one of the reliable and notable exceptions is mainly represented through the supporting work of Wang and Redmiles [7], who successfully studied how trusts mainly spread in the supporting OSS projects. The researchers use the word count and linguistic inquiry psycholinguistics dictionary to help analyze and better use in supporting writing [15] and [20]. The trust quantitative measure is obtained based on the critical term “Tone Analyser”, an LIWC IBM Watson service leveraging. However, which uses the supporting linguistic analysis that helps to detect the three significant types of supporting tones from supporting written text, including writing, emotional, and social style, it is significantly driven by social tone measures to connect with the social tendencies in supporting the people writing (that is a trait of a big personality). In supporting ways, researchers focused on agreeableness recognition, one of the personality traits that indicated the tendency of people to be cooperative and compassionate towards others. However, one supporting trust related to agreeableness is trusting others to avoid being suspicious [21] efficiently. About the following, the researcher uses agreeable personality traits similar to proxy supporting measures of an individual's propensity to trust. Factors Influenced the Acceptance of Pull-Requests According to [22] and [23], the factors influencing the contribution acceptances related to requests are considered both technical and social. Both factors include technical and social factors explained in context with the pull request. Technical aspects, the existing research based on patch acceptance as mentioned in [24], code reviewing, and bug training as mentioned in [25] and [26], has analyzed that the contribution of merge decision is directly affected through both project size such as team and KLOC size including the patch itself. Similarly, according to [10], it was analyzed that approximately 13% of pull requests reviewed were successfully closed to avoid merging, especially for supporting or purely technical reasons. However, the researchers found the supporting decision related to merging was mainly affected by the changes involving supporting code areas actively under coverages and developing test attached cases. With the increasing demand for social and transparent coding platforms, including GitHub and Bitbucket, integrators refer to contribution quality by looking at both technical and quality and developing track records through acceptance of previous contributions [27]. Numbers of followers and stars in GitHub reputations as auxiliary indicators [28]. However, the iterating findings related to pulling requests are explored as "treated equally" related to submitters defined as "social status." That is whether the external contributors are the core team members' core development. Furthermore, Ducheneaut [30] examined that the main contribution directly comes from the submitters, who are also recognized as the core development teams, driving the higher chances of acceptance and using the supporting records of signal interactions for judging and driving the proposed changes in quality. Finally, the supporting findings help to provide compelling further motivations to others for looking at the non-technical and other factors that can influence the decision to merge the supporting pull request effectively. 3. Empirical Study Researchers designed the study effectively to quantitatively access and analyze the impact of trust propensity to pull requests or (PRs) acceptance. However, the researchers used the simple and logistic regression that helped to build the model, especially for estimating the success or probability of the supporting merged or pull request that given the propensity integrators to trust. That means it is agreeableness as measured through the analysis of IBM Watson Tone. Moreover, in our supporting framework, researchers treat the pull request acceptances as the supporting dependent variables, including the independent variables as measures of agreeableness integrator that is a predictor. For supporting the study, the two primary resources are successfully used to collect the data information that is pulled, especially in GitHub, and the second emails retrieved, especially from the project of Apache Groovy. The project is considered object-oriented programming used for the Java platform, and scripting languages are also used for the Java platform. However, among several projects, this project is supported through Apache Software Foundations. Researchers opportunistically chose Groovy due to: It can make faster mailing and archives freely accessible. It can follow a supporting pull request and rely on the development model. Dataset The researchers used the supporting database of GHTorrent to collect the information in chronological order to support lists of pull requests [31]. It opened based on GitHub, and for each request of pull, researchers stored the supporting information, including: The main contributor The supporting data when it was accessible or opened The merged status The integrator The supporting data when it merged or closed Not all the pull requests are supported by GitHub. The researchers looked at the comments of pull requests, as mentioned, to identify the closed and merged that are outside of the supporting GitHub. In support, the researchers searched especially for the presences related to: Main branch commits that closed related to pulling requests Comments, especially from the manager's integration who supported the acknowledgment of a successful merge Researchers reviewed all the pull request projects one by one and evaluated their status annotated and manually. Automated Albeit reviews similar procedures that help describe in [10]. Furthermore, the description related to the Apache Groovy project is shown in Table 1. DESCRIPTION FOR JAVA-SUPPORTING PLATFORMS, OBJECT-ORIENTED PROGRAMMING IS THE PREFERRED LANGUAGE Languages Java Number of project committers 12 PRs based on GitHub 476 Emails successfully achieved, especially in the mailing list 4,948 Unique email senders 367 Table 1: Apache Groovy Project description (Source: Developed by learner) From Table 1, researchers almost drive the 5,000 messages from project emails and use my stats' supporting tools to mine the supporting users and drive the mailing list. It is available on the websites of Groovy projects. The researchers first retrieve the committer's identities, which are core team members, including the writer who accesses the supporting repository. It was retrieved from the Groovy projects web page hosted at Apache and GitHub. Furthermore, researchers compared the names and IDs of users to integrate the pull request and shared the mailing list names. After that, researchers are able to identify the supporting messages from the ten integrators. Lastly, the team is filtered out by developers who mainly exchange up to 20 supporting mains in a specific time period. Integrators of Propensity To Trust Once the researchers successfully obtained the supporting mapping related to the communications records of team developers and core team members, they successfully computed the healthy scores of propensity to trust from the supporting content related to the entire corpus of emails. In support, researchers or developers process email content through the tone of Analyzer and obtain the agreeableness score. That is defined as the interval of 0 and 1. The supporting value is obviously smaller than one that is 0.5, associated with lower agreeableness. Therefore, it tends to be less cooperative and compassionate towards others. The values equal and more than 0.5 are directly connected with higher agreeableness. However, in the end, the high and low agreeableness scopes are considered by researchers or developers to drive the level of propensity trust integrators analyzed in Table 2. 4. Results In this section, researchers present the supporting results through a regression model to build a practical understanding of the propensity to trust. It is a predictor and pulls request acceptances. The researchers performed the regression simple logistics through R statistical and supporting packages. In Table 3, the analysis of results is reported, and researchers omit to evaluate the significant and positive efforts related to control variables, including #emails and #PRs reviewed to send because of space constraints. The results include the coefficient estimate related to + 1.49 and add odds ratio of 4.46 with drive statistical significance, including a p-value of 0.0009. Furthermore, the coefficient sign estimates and indicates the negative or positive associations related to the predictor, including the success of the pull request. In addition, the OR (odds ratio) weighs and drives the effect size that impacts closer to value one. It is a more negligible impact based on parameters based on the success of chance [32]. The results indicate trust propensity, which is significantly and positively associated with the probability of supporting pull requests that successfully merged. Furthermore, researchers can use the estimated coefficients from the supporting model explored in Table 2 and the equations below. It can directly affect the merging probability and pull requests from the project of Groovy. However, the estimated probability of acceptance PR includes the following: PR estimated probability: 1/ (1 + exponential (-(+1.49+4.46 * trust propensity))).............(i) From the above equation and example, the k pull request and probability acceptances through an integrator i with the supporting low propensity is 0.68. The overall PR correspondence increases as the results and supporting questions are analyzed. 5. Discussion The discussion section is the best analysis of knowledge evaluated by researchers in their first attempts to drive the quantifying effects on the developer's trust and personal traits. It is based on distributed software projects by following a pull request supporting a based development model. Similarly, the practical result of this study is to drive the initial evidence to evaluate the chances related to merging the contributions code that is correlated with the traits of personality of integrators who performed well in reviewing the code. Furthermore, the novel finding underlines the supporting role played by the researchers or developers related to the trust of propensity through personality related to the execution of review code and tasks. The discussion results are linked with primary sources such as [22] and [30], mainly observed through the social distance between the integrator and social contributors to influence the acceptance changes through pull requests. Integrators Reviewed PR:Merged Reviewed PR:Closed A score of propensity trust Developer 1 14 0 High Developer 2 57 6 Developer 3 99 7 High Developer 4 12 4 Low Developer 5 10 1 Low Developer 6 8 0 Low Total 200 18 - Table 2: Score of Propensity to trust include pull request (Source: Developed by learner) Predictors Estimate of Coefficient Odds Ratio Supporting P-Value Intercept Plus (+) 0.77 0.117 Trust Propensity Plus (+) 1.49 4.46 0.009 Table 3: Simple Logistic regression model results (Source: Developed by learner) From the supporting discussion and analysis of Tables 2 and 3, the developers mainly recommend making sure about the community before any contribution. The users mentioned in the supporting comments of the pull requests followed the recommendation explicitly to request the supporting review from the integrators [33]. It shows the willingness to help and cooperate with others to drive a higher trust propensity. The results and findings that PR accepted as p-value as 0.68. Moreover, the broader socio-technical framework congruences the research that finds the critical points for further studies and investigates far more as evaluated in research. The personality traits also match the needs of coordinates established with the help of technical domains supporting source code areas interested and evaluated with the proposed changes. Finally, in the supporting discussion, because of its preliminary nature, some limitations are also suffered in this study regarding the result's generalizability. The researchers mainly acknowledge the preliminary analysis based on supporting tools and numbers to involve developers from the side of single projects. However, only through the supporting replications, including the different values of datasets and settings, will researchers be able to evaluate and develop evidence on solid empirical changes. In addition, the other supporting limitation of this study is around the propensity validity and trust construct. Due to less practicality, researchers mainly decided to not only depend on the self-reported and traditional psychometric approaches that are used for measuring trust, including surveys [12]. In a replication of future perspective, researchers will support and investigate the reliability of analyzer tone services that connect with the technical domain that includes the software engineering from longer time linguistic resources, which are usually evaluated and trained based on the content of non-technical. 6. Conclusion and Recommendation Conclusion Therefore, the research has included six major chapters (sections) to evaluate the research topic based on a preliminary analysis of the propensity effect to trust in supporting distributed software development. The first chapter includes an overview of research supporting critical and real-time information. The second chapter includes personality traits and a significant five-factor analysis to build trust in teamwork. The third chapter has highlighted the empirical study related to research by connecting the real supporting projects such as Apache Groovy projects. The fourth chapter focuses on analysis and results to drive the research and projects. The five chapters have been discussed based on results and empirical study. The last chapter, or sixth chapter, concludes the research with supporting the recommendation for further study. This study represents the initial step in driving the broader research efforts that help collect the evidence of quantitative analysis and well-established trust among team members and developers and contribute to increased performances of projects related to distributed software engineering projects. In the analysis of personality models of the big five model, the trust propensity related to perceived others is driven by the trustworthy and stable personality traits that have changed from one person to another. Overall, the leveraging prior and supporting evidence that emerging personality traits unconsciously drive from the lexicon personally used in supporting written communications. The researchers and developers have used the tone of IBM Watson and analyzer services that help to measure the trust propensity by analysis of written emails archived through the projects of Apache Groovy. Furthermore, we found initial supporting evidence that researchers and developers who have posed with a higher propensity are likely to develop and trust more to accept the significant external contribution analyzed from the pull request. Recommendation For future work, it is recommended by researchers to replicate the supporting experiences to drive solid evidence. Researchers have followed and compared the analyzer tone, including the supporting tools, to better assess the reliability of research in extracting the personality, especially from the text that mainly contains the information of technical content. The researchers intended or used to enlarge the supporting database for both projects and supporting pull requests to understand the research better. It suggests that developers' personalities will change by relying on the project's participants and developing mutual trust through involving pairs of developers who mainly interact in supporting dyadic cooperation. For future study, it is suggested that developers of distributed software engineering projects use the network-centric approach, especially for estimating the supporting trust between software developers and open sources. Developers will follow the study's three stages of the network-centric approach to build trust while working from different physical locations globally on the distributed software engineering project. The first stage will be CDN (community-wide network developers) of this approach, which means community-wide network developers to construct better the information connecting to projects and developers. The second stage will compare the supporting trust between the supporting pairs directly linked to developers with the CDN. The last stage is computed with the trust between the developer pairs indirectly linked in the CDN. Figure 3: Future suggestion for a network-centric approach for estimating the trust (Source: Developed by learner) From Figure 3 above, CDN is the main stage connected with the other two stages to build trust and trustworthiness to drive potential contributions to an OSS project. The developers or researchers can construct the network-centric approach by focusing on CDN that provides supporting and valuable information about the effective collaboration between the OSS community and developers. The role of CDN in Figure 3 represents the community of developers driven by the OSS multiple projects that share some most common characteristics, including the same case and programming languages. Furthermore, developers or researchers can follow the main four features to label the supporting data to the regression train models for feature extractions. Word embedding can be used by developers such as Google Word2Vec to analyze and vectorize every comment to avoid the pre-trained model. The developers can train their own Word2Vec model related to data of software engineering to drive domain-specific and supporting models to better semantic representation analysis. It can be compared with the pre-trained and generic models. The developers can also use the 300 vector dimensional models to get comments and evaluate the vector representation. In addition, social can also be considered a strength for developers to build a connection between two or more developers to influence trust. Researchers and developers can assign the supporting integer values, especially for every role, to build the pull request and analyze the comment to build trust among individuals. References [1] B. Al-Ani, H. Wilensky, D. Redmiles, and E. Simmons, “An Understanding of the Role of Trust in Knowledge Seeking and Acceptance Practices in Distributed Development Teams,” in 2011 IEEE Sixth International Conference on Global Software Engineering, 2011. [2] F. Abbattista, F. Calefato, D. Gendarmi, and F. Lanubile, “Incorporating Social Software into Agile Distributed Development Environments.” Proc. 1st ASE Workshop on Social Sofware Engineering and Applications (SOSEA’08), 2008. [3] F. Calefato, F. Lanubile, N. Sanitate, and G. Santoro, “Augmenting social awareness in a collaborative development environment,” in Proceedings of the 4th international workshop on Social software engineering - SSE ’11, 2011. [4] F. Lanubile, F. Calefato, and C. Ebert, “Group Awareness in Global Software Engineering,” IEEE Softw., vol. 30, no. 2, pp. 18–23. [5] A. Guzzi, A. Bacchelli, M. Lanza, M. Pinzger, and A. van Deursen, “Communication in open source software development mailing lists,” in 2013 10th Working Conference on Mining Software Repositories (MSR), 2013. [6] Y. Wang and D. Redmiles, “Cheap talk, cooperation, and trust in global software engineering,” Empirical Software Engineering, 2015. [7] Y. Wang and D. Redmiles, “The Diffusion of Trust and Cooperation in Teams with Individuals’ Variations on Baseline Trust,” in Proceedings of the 19th ACM Conference on Computer-Supported Cooperative Work & Social Computing, 2016, pp. 303–318. [8] S. L. Jarvenpaa, K. Knoll, and D. E. Leidner, “Is Anybody out There? Antecedents of Trust in Global Virtual Teams,” Journal of Management Information Systems, vol. 14, no. 4, pp. 29–64, 1998. [9] J. W. Driscoll, “Trust and Participation in Organizational Decision Making as Predictors of Satisfaction,” Acad. Manage. J., vol. 21, no. 1, pp. 44–56, 1978. [10] G. Gousios, M. Pinzger, and A. van Deursen, “An exploratory study of the pull-based software development model,” in Proceedings of the 36th International Conference on Software Engineering - ICSE 2014, 2014. [11] F. Lanubile, C. Ebert, R. Prikladnicki, and A. Vizcaino, “Collaboration Tools for Global Software Engineering,” IEEE Softw., vol. 27, no. 2, pp. 52–55, 2010. [12] P. T. Costa and R. R. McCrae, “The Five-Factor Model, Five-Factor Theory, and Interpersonal Psychology,” in Handbook of Interpersonal Psychology, 2012, pp. 91–104. [13] J. B. Hirsh and J. B. Peterson, "Personality and language use in self-narratives," J. Res. Pers., vol. 43, no. 3, pp. 524–527, 2009. [14] J. Shen, O. Brdiczka, J.J. Liu, Understanding email writers: personality prediction from email messages. Proc. of 21st Int’l Conf. on User Modeling, Adaptation and Personalization (UMAP Conf), 2013. [15] Y. R. Tausczik and J. W. Pennebaker, "The Psychological Meaning of Words: LIWC and Computerised Text Analysis Methods," J. Lang. Soc. Psychol., vol. 29, no. 1, pp. 24–54, Mar. 2010. [16] B. Al-Ani and D. Redmiles, “In Strangers We Trust? Findings of an Empirical Study of Distributed Teams,” in 2009 Fourth IEEE International Conference on Global Software Engineering, Limerick, Ireland, pp. 121–130. [17] J. Schumann, P. C. Shih, D. F. Redmiles, and G. Horton, “Supporting initial trust in distributed idea generation and idea evaluation,” in Proceedings of the 17th ACM international conference on Supporting group work - GROUP ’12, 2012. [18] F. Calefato, F. Lanubile, and N. Novielli, “The role of social media in affective trust building in customer–supplier relationships,” Electr. Commerce Res., vol. 15, no. 4, pp. 453–482, Dec. 2015. [19] J. Delhey, K. Newton, and C. Welzel, "How General Is Trust in 'Most People'? Solving the Radius of Trust Problem," Am. Social. Rev., vol. 76, no. 5, pp. 786–807, 2011. [20] Pennebaker, James W., Cindy K. Chung, Molly Ireland, Amy Gonzales, and Roger J. Booth, "The Development and Psychometric Properties of LIWC2007," LIWC2007 Manual, 2007. [21] P. T. Costa and R. R. MacCrae, Revised NEO Personality Inventory (NEO PI-R) and NEO Five-Factor Inventory (NEO FFI): Professional Manual. 1992. [22] J. Tsay, L. Dabbish, and J. Herbsleb. Influence of social and technical factors for evaluating contribution in GitHub. In Proc. of 36th Int’l Conf. on Software Engineering (ICSE’14), 2014. [23] G. Gousios, M.-A. Storey, and A. Bacchelli, “Work practices and challenges in pull-based development: The contributor’s perspective,” in Proceedings of the 38th International Conference on Software Engineering - ICSE ’16, 2016. [24] C. Bird, A. Gourley, and P. Devanbu, “Detecting Patch Submission and Acceptance in OSS Projects,” in Fourth International Workshop on Mining Software Repositories (MSR’07:ICSE Workshops 2007), 2007. [25] P. C. Rigby, D. M. German, L. Cowen, and M.-A. Storey, “Peer Review on Open-Source Software Projects,” ACM Trans. Softw. Eng. Methodol., vol. 23, no. 4, pp. 1–33, 2014. [26] J. Anvik, L. Hiew, and G. C. Murphy, "Who should fix this bug?," in Proceeding of the 28th international conference on Software Engineering - ICSE '06, 2006. [27] L. Dabbish, C. Stuart, J. Tsay, and J. Herbsleb, “Social coding in GitHub: Transparency and Collaboration in an Open Source Repository,” in Proceedings of the ACM 2012 conference on Computer Supported Cooperative Work - CSCW ’12, 2012. [28] J. Marlow, L. Dabbish, and J. Herbsleb, “Impression formation in online peer production: Activity traces and personal profiles in GitHub,” in Proceedings of the 2013 conference on Computer supported cooperative work - CSCW ’13, 2013. [29] G. Gousios, A. Zaidman, M.-A. Storey, and A. van Deursen, “Work practices and challenges in pull-based development: the integrator’s perspective,” in Proceedings of the 37th International Conference on Software Engineering - Volume 1, 2015, pp. 358–368. [30] N. Ducheneaut, "Socialisation in an Open Source Software Community: A Socio-Technical Analysis," Comput. Support. Coop. Work, vol. 14, no. 4, pp. 323–368, 2005. [31] G. Gousios, “The GHTorrent dataset and tool suite,” in 2013 10th Working Conference on Mining Software Repositories (MSR), 2013. [32] J. W. Osborne, “Bringing Balance and Technical Accuracy to Reporting Odds Ratios and the Results of Logistic Regression Analyses,” in Best Practices in Quantitative Methods, pp. 385–389. [33] O. Baysal, R. Holmes, and M. W. Godfrey. Mining usage data and development artefacts. In Proceedings of MSR '12, 2012. [34] Sapkota, H., Murukannaiah, P. K., & Wang, Y. (2019). A network-centric approach for estimating trust between open source software developers. Plos one, 14(12), e0226281. [35] Wang, Y. (2019). A network-centric approach for estimating trust between open source software developers.

By Nitin Kevadiya

Product Roadmap in Jira

Disclaimer: The concept of a product roadmap is vast and quite nuanced. However, this article will be focused on working with a product roadmap in Jira. As such, I am coming from an assumption that you already have a roadmap and are ready to transition your vision into Atlassian’s Project Management software. If this is not the case, please refer to this detailed guide that talks about product roadmaps in general and come back when you are ready to create a product roadmap in Jira. Using Jira for Product Roadmaps Despite Jira not being the best place to design a product roadmap, it is an excellent tool for transforming your initial plan of action into an actionable plan. Or, in simpler words, having a Roadmap in Jira makes a lot of logical sense if you are already using the app for Project Management. Why? Because all of your tasks, ergo, all of your work, are tied to the Epics in your roadmap and are clearly visible in front of the entire team. In addition to that, when you add a task to the Backlog, you’ll think about the bigger picture because you will be choosing which Epic the issue belongs to and where it lies in terms of timeframe and priorities. In addition to visibility within your own team, a roadmap in Jira has the added benefit of spreading awareness across multiple teams. For example, the work of a marketer who is dependent on the delivery of a certain feature is clearly visualized on the roadmap. That said, a roadmap in Jira is not a silver bullet. Most of its pros can become cons when viewed from a certain angle: Jira is made for internal use. As such, it is not the best choice for times when you need to communicate or share progress with the end users or stakeholders. In addition to that, there’s always the temptation of adding more and more tasks to the same Epics simply due to the fact that it is there, and you are already used to organizing your tasks within it. The best course of action would be to create a new Epics per new feature version once the existing ones are done, even when new issues are related to the same subject (for example, optimization of a web page after it has already gone live should be a separate Epic). PROS CONS Your roadmap is visible and actionable.It’s easier to review the roadmap with your team at any time.Prioritization of new work is simplified.The roadmap is used across multiple teams Not visible to end-usersNot the best tool to share with stakeholders as they’ll get an unnecessary level of detailsMisuse of a roadmap can lead to never-ending.Epics where new issues are continuously added Elements of a Roadmap in Jira Jira is a complex tool. When it comes to functionality – there’s a lot to unravel. Luckily, you’ll only really need to use three core elements of the app to transition your roadmap – Epics, Child Issues, and Dependencies. 1. Epic: An epic is a large body of work that can be divided into several smaller tasks. If, for example, you are developing an e-commerce platform, then developing a landing page would be an Epic. 2. Issue: Issues, also known as Child Issues, are the smaller tasks the Epic is composed of. If we were to follow our example with the e-commerce platform, then tasks like choosing a hosting provider, designing the page, and filling it with content would be the Child Issues. The granularity can be as broad or deep and nuanced as the project needs it to be. Smaller projects, for example, can view design as a task, while in larger teams and more complex projects, it would be an Epic with its own Child Issues. 3. Dependency: Dependencies are used to mark relationships between certain tasks and Epics. You can’t implement a payment system without deciding which one you’ll want to use. Or you can’t proceed with content unless you know the layout of the page. These are examples of a direct dependency when one Epic blocks another. How To Transfer Your Product Roadmap Into Jira As I mentioned above, Jira isn’t designed as a tool for designing product roadmaps. If you have it open – your plan should already be laid in front of you, so all that’s left to do is to transition it into the software. Let’s see an example with a company-managed iterative Jira project: navigate to your project’s Jira board and navigate to the roadmap section. This option should be visible to you in the top left corner of the sidebar. Once the roadmap interface is open – create your first epic. This option is visible at the bottom as “Sprints” and “Releases” are rows. Click on the + icon and type in the name of your Epic. Now that your first Epic is ready, you can populate it with Child Issues. Click on the + button next to the name of your epic and type in the name of your Child Issue. Once your Epics and Child Issues are all set up – click on the timeline to generate a roadmap bar. Drag the timeline sections to set up the timeframe you have estimated. Alternatively, you can set up start and due dates within the issues and epics themselves. The last thing to do would be to visualize any and all dependencies between your Epics and Child Issues. There are two ways of doing this: Drag-&-Drop: You’ll see two dots when you hover over the timeline section of the roadmap. You can grab one of the dots and drag it to the issue/epic to form a dependency. From within the issue: Alternatively, you can set the dependency from within the issue view. Open the issue and click on the button with two links. Then select the “link issue” option and link your issues. That’s it. Your roadmap is set in Jira. Best Practices for Working With Roadmaps in Jira Revise the roadmap regularly: In my team, we have a practice of revising the roadmap once a week. This helps us stay on track and clearly identify the blockers and dependencies between issues. Don’t forget to close Epics once they are actually done (for example, the e-commerce landing is live), even if some tasks are left over. Take a look at the remaining tasks during backlog refinement and either close them if they have lost relevance or shift them to the next Epic. Have your priorities straight: there are many elements that comprise the development of a successful product. You’ll need to know where your priorities are before deciding which tasks go into a certain Epic and which can be withheld until further iterations. For example, you might want to get a working website ASAP, but you can hold on to SEO optimization, which is technically also part of the development Epic. Don’t add ongoing recurring tasks to the roadmap: Continuous tasks like writing content for the blog or regular maintenance checklist shouldn’t go to the roadmap. They simply clutter your vision with tasks and Epics that don’t ever go away. Estimate and revise estimates for time-sensitive projects: This step is crucial if you have limitations on time and/or budget. Sure, estimations are not set in stone, but keeping track of your progress is still crucial. Be realistic with your scope: having too many tasks that need to be done in parallel will lead to missed deadlines and the need to reevaluate the roadmap as a whole. This is frustrating to the team. Outline your dependencies: It’s hard to prioritize work when working on a roadmap, as there’ll be too many must-do tasks. For instance, designing a landing page and running paid ads to get traffic to it are both high priorities. However, one can not be done without the other. Best Add-Ons for Working With Roadmaps in Jira When you think about it, Jira is like a Swiss army knife of project management solutions. It has a plethora of tools conveniently wrapped in one package that functions great as a whole. That said, a single blade made for cutting or a screwdriver with a nice grip will probably make that one particular job they were made for much simpler. In terms of road mapping – yes, Jira does have the tools you need, and they will get the job done. But if you need something a bit more sophisticated and laser-focused – visit Atlassian Marketplace. Structure.Gantt: This add-on gives you more control over roadmaps in Jira. The UI adds clarity by identifying critical tasks and allowing you to solve scheduling conflicts from the roadmap interface. A certain level of automation allows you to set parameters like resource capacity and automate task distribution. BigPicture Project Management & PPM: This add-on takes an interesting spin on the concept of roadmaps by visualizing them as goals rather than epics. This approach can help Agile teams who wish to break their tasks by sprints and iterations rather than by larger chunks of functionality (Epics). Smart Checklist for Jira: Smart Checklist helps you go one level deeper when filling out the roadmap with Epics and tasks. You can apply checklist templates like the Definition of Done or Definition of Ready to issues of a certain type automatically, thus making sure that once the roadmap is there – your team has the necessary steps they’ll need to follow. Conclusion If you are already using Jira and looking for an actionable roadmap designed for internal use – Atlassian has you covered. Both the out of the box functionality and the additional add-ons you can use to finetune your experience are more than enough to keep your entire team on the same page.

By Oleksandr Siryi

6 Proven Kubernetes Deployment Best Practices for Your Projects

Kubernetes enables orchestration for deploying, scaling, and managing containerized applications. However, it can be challenging to manage Kubernetes clusters effectively without proper deployment practices. Kubernetes operates on a distributed architecture involving multiple interconnected components such as the control plane, worker nodes, networking, storage, and more. Configuring and managing this infrastructure can be complex, especially for organizations with limited experience managing large-scale systems. Similarly, there are many other challenges to Kubernetes deployment, which you can solve by using best practices like horizontal pod autoscaler (HPA), implementing security policies, and more. In this blog post, we will explore proven Kubernetes deployment practices that will help you optimize the performance and security of your Kubernetes deployments. But first, let’s understand the underlying architecture for Kubernetes deployment. Understanding the Kubernetes Architecture The Kubernetes architecture involves several key components. The control plane includes the API server, scheduler, and controller-manager, which handle cluster management. Nodes host pods and are managed by Kubelet, while etcd is the distributed key-value store for cluster data. The API server acts as the single source of truth for cluster state and management. Lastly, kube-proxy enables communication between pods and services, ensuring seamless connectivity within the Kubernetes environment. Advantages of Using Kubernetes for Deployment Kubernetes allows for efficient resource utilization through intelligent scheduling and horizontal scaling, providing scalability and automatic workload distribution. It also simplifies the management of complex microservices architectures by supporting self-healing capabilities that monitor and replace unhealthy pods. Organizations can use Kubernetes' support for rolling updates and version control, making application deployment seamless. By using Kubernetes for deployment, organizations can streamline their application management process. Key Factors To Consider Before Deploying Kubernetes When deploying Kubernetes, it's essential to consider several key factors. You need to evaluate the resource requirements of your workloads to determine the appropriate cluster size. This will ensure that you have enough resources to handle the workload efficiently. It is also crucial to define resource limits and requests to ensure fair allocation of resources among different workloads. Consider network connectivity and firewall requirements for inter-pod communication. Planning for storage requirements and exploring the different storage options that Kubernetes supports is also essential. Understanding the impact of the Kubernetes deployment on existing infrastructure and processes is essential for a smooth transition. Now that we have discussed the benefits of effective Kubernetes deployment and critical factors to consider, let’s discuss some of the best practices. 1. Best Practices for Using Kubernetes Namespaces When using Kubernetes namespaces, it is important to separate different environments or teams within a cluster logically. By doing so, you can effectively manage resource consumption by defining resource quotas for each namespace. Implement role-based access control (RBAC) to enforce access permissions within namespaces. Additionally, apply network policies to restrict communication between pods in different namespaces. Regularly reviewing and cleaning up unused namespaces optimizes cluster resources. By following these best practices, you can ensure efficient and secure namespace management in Kubernetes deployments. 2. Kubernetes Deployment Security Practices To ensure the security of your Kubernetes deployment, there are several best practices you should follow. Enable Role-Based Access Control (RBAC) to control access and permissions within the cluster. Implement network policies to restrict communication and enforce security boundaries. Regularly scan for vulnerabilities and apply patches to Kubernetes components. Enable audit logging to track and monitor cluster activity. Follow security best practices for container images and only use trusted sources. By implementing these practices, you can enhance the security of your Kubernetes deployment. Setting up Role-Based Access Control (RBAC) In Kubernetes To ensure fine-grained access permissions in Kubernetes, it is crucial to create custom roles and role bindings. You can effectively manage access for applications running within pods by utilizing service accounts. Implementing role inheritance simplifies RBAC management across multiple namespaces. Regularly reviewing and updating RBAC policies is essential to align with evolving security requirements. Following RBAC's best practices, such as the least privilege principle, minimizes security risks. Emphasizing these practices enables secure configuration and automation of Kubernetes deployments. 3. Best Practices for Securing Kubernetes API Server To ensure the security of your Kubernetes API server, it is essential to implement several best practices. Enable access control using RBAC to ensure only authorized users can access the API server. Implement network policies to restrict access to the server, preventing unauthorized access. Regularly update and patch the API server to avoid any vulnerabilities. Enable audit logs to monitor and track activity on the API server. Lastly, use role-based access control (RBAC) to manage user permissions effectively. Implementing Kubernetes Network Policies for Security To enhance security in Kubernetes deployments, implementing network policies is crucial. These policies allow you to control inbound and outbound traffic between pods, ensuring only authorized communication. Network segmentation with different namespaces adds an extra layer of security by isolating resources. Applying firewall rules further restricts communication, preventing unauthorized access. You can utilize network plugins like Calico or Cilium to manage network policies effectively, which provide advanced policy management capabilities. Monitoring network traffic and implementing IP whitelisting/blacklisting adds additional security against potential threats. 4. Scaling Kubernetes Deployments Implementing automatic scaling is a proven Kubernetes deployment best practice. You can optimize resource utilization using the Kubernetes horizontal pod autoscaler (HPA). It allows you to scale up or down based on CPU metrics, ensuring efficient allocation of resources. Another helpful tool is kube-state-metrics, which helps monitor the status of your Kubernetes deployments. Additionally, implementing cluster autoscaler enables automatically adjusting the number of nodes in your Kubernetes cluster. Continuously monitoring resource consumption and adjusting resource requests and limits is essential for smooth scaling. Automatic Scaling With Kubernetes Horizontal Pod Autoscaler (HPA) Configure the Kubernetes horizontal pod autoscaler (HPA) to automatically scale the number of pods based on CPU or custom metrics. Set the target CPU utilization for HPA to trigger scaling and enable the metrics server to monitor CPU utilization accurately. HPA can also be used with custom metrics to scale based on application-specific requirements. It's essential to monitor HPA events and adjust the HPA settings to ensure optimal performance and resource utilization. 5. Optimizing Resource Utilization With Kubernetes Resource Requests and Limits To optimize resource utilization in Kubernetes, it's essential to set resource requests specifying the minimum CPU and memory requirements for a pod. Additionally, resource limits should be used to prevent pods from exceeding allocated resources. Monitoring resource utilization through metrics like CPU and memory allows for adjustments to resource requests and limits based on observed consumption. Furthermore, optimizing container images helps reduce resource usage and improves overall performance. Implementing these practices can effectively optimize resource utilization in your Kubernetes deployments. 6. Monitoring and Logging Kubernetes Deployments Monitoring and logging Kubernetes deployments is vital for smooth operation. Prometheus and Grafana provide real-time metrics and alerts for critical events. The ELK stack centralizes logging, making troubleshooting and identifying bottlenecks easier. Custom metrics exporters monitor application-specific metrics. Optimize performance and troubleshoot effectively with monitoring and logging. Monitoring Kubernetes Clusters With Prometheus and Grafana Configure Prometheus to collect metrics from the Kubernetes API server and Kubelet. Utilize Grafana dashboards to visualize Prometheus metrics for comprehensive monitoring. Establish alerting rules in Prometheus to receive notifications for critical events. Monitor cluster components such as etcd, kube-proxy, and kube-dns using Prometheus exporters. Customize Grafana dashboards to track specific resource and application metrics. Conclusion To achieve successful Kubernetes deployments, follow best practices. Understanding architecture and benefits, considering resource requirements and security, setting up clusters and configuring networking, Implementing role-based access control and network policies, scaling efficiently, monitoring and logging for health, and troubleshooting common issues are some of the best practices to follow. However, which one to use depends on specific project requirements.

By Hiren Dhaduk

Unleashing the Power of Hackathons: A Must for Senior and Middle Developers

In the dynamic realm of technology, continuous learning, innovation, and adaptability are the keys to success. While many senior and middle developers have already honed their skills, staying at the forefront of the ever-evolving tech landscape requires more than just experience. It demands a proactive approach to learning and a thirst for new challenges. One potent way to achieve this is by participating in hackathons. Hackathons, often seen as a domain for aspiring developers or tech enthusiasts, offer significant advantages for experienced developers as well. In this article, we'll explore why senior and middle developers should consider participating in hackathons and how these events can be instrumental in their ongoing career growth and innovation. 1. The Learning Never Stops Regardless of your experience level, the tech industry is in a perpetual state of evolution. New languages, frameworks, and technologies emerge regularly. Hackathons provide a structured environment to explore these emerging technologies and learn by doing. It's a golden opportunity to step out of your comfort zone and tackle real-world challenges using cutting-edge tools. By participating in a hackathon, you can gain hands-on experience with the latest trends and innovations in the industry. This knowledge not only keeps your skill set relevant but also positions you as a tech leader who can adapt to change effortlessly. 2. Sharpen Problem-Solving Skills Hackathons are essentially intensive problem-solving competitions. They present you with complex challenges and tight deadlines, forcing you to think creatively and devise efficient solutions. These events push you to your limits, fostering your ability to solve intricate problems swiftly—a skill that's invaluable in your everyday work as a developer. The problem-solving skills you enhance during a hackathon can be directly applied to your regular projects, making you a more efficient and effective developer. 3. Networking and Collaboration Hackathons attract diverse participants, from seasoned developers to industry experts and even entrepreneurs. Engaging with this varied group exposes you to different perspectives, approaches, and experiences. It's an opportunity to collaborate with professionals from various domains and build a network that can prove beneficial in your career. Collaboration during hackathons can also lead to exciting new projects or partnerships. You might find like-minded individuals who share your passion for a specific technology or startup idea, opening doors to innovative ventures. 4. Portfolio Enhancement The projects you work on during hackathons can become valuable additions to your portfolio. These real-world, problem-solving experiences can impress potential employers or clients. They demonstrate your ability to apply your skills in a practical context and showcase your commitment to continuous learning and growth. 5. Creativity Unleashed Hackathons encourage creative thinking and experimentation. Without the constraints of a typical work environment, you can explore unconventional solutions and take risks. This creative freedom can lead to groundbreaking ideas or innovative approaches that you might not have considered otherwise. 6. A Break from Routine Even senior and middle developers can sometimes feel stuck in a routine. Hackathons provide a refreshing break from the daily grind. They inject excitement and adrenaline into your work, reigniting your passion for coding. 7. Mentorship Opportunities Many hackathons feature mentors or judges who are industry experts. Engaging with these professionals can be an invaluable learning experience. They can provide guidance, feedback, and insights that you may not easily access in your regular work environment. 8. Prizes and Recognition Let's not forget the potential rewards. Hackathons often offer prizes, which can range from cash awards to job opportunities or cutting-edge tech gadgets. Even if you don't win, the recognition and exposure you gain can boost your professional profile. Parting Thoughts In conclusion, hackathons are not just for newcomers or tech enthusiasts; they are a powerful tool for senior and middle developers to foster continuous learning, innovation, and growth. These events provide a platform to learn, collaborate, and push your boundaries—all essential elements for success in the fast-paced world of technology. So, if you're a senior or middle developer looking for your next challenge, consider joining a hackathon. Embrace the opportunity to learn, create, and connect—it may just be the catalyst for the next exciting phase of your career.

By Sergei Golitsyn

DevSecOps: Integrating Security Into Your DevOps Workflow

The need for speed, agility, and security is paramount in the rapidly evolving landscape of software development and IT operations. DevOps, focusing on collaboration and automation, has revolutionized the industry. However, in an era where digital threats are becoming increasingly sophisticated, security can no longer be an afterthought. This is where DevSecOps comes into play - a philosophy and practices that seamlessly blend security into the DevOps workflow. This extensive guide will delve deep into the principles, benefits, challenges, real-world use cases, and best practices of DevSecOps. Understanding DevSecOps What Is DevSecOps? DevSecOps is an extension of DevOps, where "Sec" stands for security. It's a holistic approach integrating security practices into software development and deployment. Unlike traditional methods where security was a standalone phase, DevSecOps ensures that security is embedded throughout the entire Software Development Life Cycle (SDLC). The primary goal is to make security an enabler, not a bottleneck, in the development and deployment pipeline. The Importance of a DevSecOps Culture DevSecOps is not just about tools and practices; it's also about fostering a culture of security awareness and collaboration. Building a DevSecOps culture within your organization is crucial for long-term success. Here's why it matters: Security Ownership: In a DevSecOps culture, everyone is responsible for security. Developers, operators, and security professionals share ownership, which leads to proactive security measures. Rapid Detection and Response: A culture that values security ensures potential issues are spotted early, allowing for swift responses to security threats. Continuous Learning: Embracing a DevSecOps culture encourages continuous learning and skill development. Team members are motivated to stay updated on security practices and threats. Collaboration and Communication: When teams work together closely and communicate effectively, security vulnerabilities are less likely to slip through the cracks. Future Trends in DevSecOps As technology evolves, so does the DevSecOps landscape. Here are some emerging trends to watch for in the world of DevSecOps: Shift-Right Security: While "Shift Left" focuses on catching vulnerabilities early, "Shift Right" emphasizes security in production. This trend involves real-time monitoring and securing applications and infrastructure, focusing on runtime protection. Infrastructure as Code (IaC) Security: As organizations embrace IaC for provisioning and managing infrastructure, securing IaC templates and configurations becomes vital. Expect to see increased emphasis on IaC security practices. Cloud-Native Security: With the growing adoption of cloud-native technologies like containers and serverless computing, security in the cloud is paramount. Cloud-native security tools and practices will continue to evolve. AI and Machine Learning in Security: AI and machine learning are applied to security operations for threat detection, anomaly identification, and automated incident response. These technologies will play an increasingly prominent role in DevSecOps. Compliance as Code: Automating compliance checks and incorporating compliance as code into the DevSecOps pipeline will help organizations meet regulatory requirements more efficiently. The Role of Security in DevOps Historically, security was often treated as a separate silo, addressed late in the development process or even post-deployment. However, this approach needs to be revised in today's threat landscape, where vulnerabilities and breaches can be catastrophic. Security must keep pace in the DevOps environment, characterized by rapid changes and continuous delivery. Neglecting security can lead to significant risks, including data breaches, compliance violations, damage to reputation, and financial losses. Benefits of DevSecOps Integrating security into DevOps practices offers numerous advantages: Reduced Vulnerabilities: By identifying and addressing security issues early in development, vulnerabilities are less likely to make it to production. Enhanced Compliance: DevSecOps facilitates compliance with regulatory requirements by integrating security checks into the SDLC. Improved Customer Trust: Robust security measures instill confidence in customers and users, strengthening trust in your products and services. Faster Incident Response: DevSecOps equips organizations to detect and respond to security incidents more swiftly, minimizing potential damage. Cost Savings: Identifying and mitigating security issues early is often more cost-effective than addressing them post-deployment Key Principles of DevSecOps DevSecOps is guided by core principles that underpin its philosophy and approach: Shift Left: Shift left" means moving security practices and testing as early as possible in the SDLC. This ensures that security is a fundamental consideration from the project's inception. Automation: Automation is a cornerstone of DevSecOps. Security checks, tests, and scans should be automated to detect issues consistently and rapidly. Continuous Monitoring: Continuous monitoring of applications and infrastructure in production helps identify and respond to emerging threats and vulnerabilities. Collaboration: DevSecOps promotes collaboration between development, operations, and security teams. Everyone shares responsibility for security, fostering a collective sense of ownership. Implementing Security Early in the SDLC To effectively integrate security into your DevOps workflow, you must ensure that security practices are ingrained in every stage of the Software Development Life Cycle. Here's how you can achieve this: Planning and Design: Begin with security considerations during the initial planning and design phase. Identify potential threats and define security requirements. Code Development: Developers should follow secure coding practices, including input validation, authentication, and authorization controls. Static code analysis tools can help identify vulnerabilities at this stage. Continuous Integration (CI): Implement automated security testing as part of your CI pipeline. This includes dynamic code analysis and vulnerability scanning. Continuous Deployment (CD): Security should be an integral part of the CD pipeline, with automated security testing to validate the security of the deployment package. Monitoring and Incident Response: Continuous monitoring of production systems allows for detecting security incidents and rapid responses. Tech enthusiast driving innovation for a brighter future. Passionate about positive change. Security Tools and Technologies Effective DevSecOps implementation relies on a range of security tools and technologies. These tools automate security testing, vulnerability scanning, and threat detection. Here are some key categories: Static Application Security Testing (SAST): SAST tools analyze source code, bytecode, or binary code to identify vulnerabilities without executing the application. Dynamic Application Security Testing (DAST): DAST tools assess running applications by sending requests and analyzing responses to identify vulnerabilities. Interactive Application Security Testing (IAST): IAST tools combine elements of SAST and DAST by analyzing code as it executes in a live environment. Container Security: Containerization introduces its security challenges. Container security tools scan container images for vulnerabilities and enforce runtime security policies. Vulnerability Scanning: Vulnerability scanning tools assess your infrastructure and applications for known vulnerabilities, helping you prioritize remediation efforts. Security Information and Event Management (SIEM): SIEM tools collect and analyze security-related data to identify and respond to security incidents. When integrated into your DevSecOps pipeline, these tools provide comprehensive security testing and monitoring coverage. Collaboration Between DevOps and Security Teams Effective collaboration between development, operations, and security teams is essential for DevSecOps success. Here are some strategies to foster this collaboration: Establish Clear Communication Channels: Ensure that teams have clear channels for communication, whether through regular meetings, shared chat platforms, or documentation. Cross-Training: Encourage team members to cross-train in each other's areas of expertise. Developers should understand security principles, and experts should grasp development and operational concerns. Shared Responsibility: Emphasize shared responsibility for security. Encourage a culture where everyone considers security part of their role. Joint Ownership: Consider forming cross-functional teams with members from different departments to own and operate security-related projects jointly. Real-world Use Cases To illustrate the impact of DevSecOps in practice, let's examine a couple of real-world examples: Case Study: Company X Company X, a financial services provider, implemented DevSecOps to enhance the security of its online banking application. By integrating security checks into their CI/CD pipeline and implementing continuous monitoring, they achieved: A 60% reduction in security vulnerabilities. Improved compliance with industry regulations. A 40% decrease in the mean time to detect and respond to security incidents. Case Study: Healthcare Provider Y Healthcare Provider Y adopted DevSecOps to protect patient data in their electronic health record system. By automating vulnerability scanning and improving collaboration between their development and security teams, they achieved the following: Zero security breaches in the past year. Streamlined compliance with healthcare data security regulations. Improved trust and confidence among patients. These case studies highlight the tangible benefits that organizations can realize by embracing DevSecOps. Challenges and Solutions While DevSecOps offers numerous benefits, it has its challenges. Here are some common challenges and strategies to address them: Resistance to Change: Solution: Foster a culture of continuous improvement and provide training and resources to help team members adapt to new security practices. Tool Integration:Solution: Choose tools that integrate seamlessly with your existing DevOps pipeline and automate the integration process. Complexity:Solution: Start small and gradually expand your DevSecOps practices, first focusing on the most critical security concerns. Compliance Hurdles:Solution: Work closely with compliance experts to ensure your DevSecOps practices align with regulatory requirements. Measuring DevSecOps Success Measuring the success of your DevSecOps practices is essential to ongoing improvement. Here are some key performance indicators (KPIs) and metrics to consider: Number of Vulnerabilities Detected: Measure how many vulnerabilities are detected and remediated. Mean Time to Remediate (MTTR): Track how quickly your team can address and resolve security vulnerabilities. Frequency of Security Scans: Monitor how often security scans and tests are performed as part of your pipeline. Incident Response Time: Measure the time it takes to respond to and mitigate security incidents. Compliance Adherence: Ensure your DevSecOps practices align with industry regulations and standards. Getting Started With DevSecOps If you're new to DevSecOps, here are some steps to get started: Assess Your Current State: Evaluate your existing DevOps practices and identify areas where security can be integrated. Define Security Requirements: Determine your organization's security requirements and regulatory obligations. Choose Appropriate Tools: Select security tools that align with your goals and seamlessly integrate with your existing pipeline. Educate Your Team: Provide training and resources to help your team members acquire the necessary skills and knowledge. Start Small: Initiate a pilot project to test your DevSecOps practices before scaling up. Continuously Improve: Embrace a culture of continuous improvement, conducting regular reviews and optimizations of your DevSecOps practices. Conclusion In today's digital landscape, security is not an option; it's a necessity. DevSecOps is the answer to the growing challenges of securing software in a fast-paced development and deployment environment. By integrating security into every phase of the DevOps pipeline, organizations can reduce vulnerabilities, enhance compliance, build customer trust, and respond more effectively to security incidents. Whether you're just starting your DevSecOps journey or looking to refine existing practices, the principles and strategies outlined in this guide will set you on the path to a more secure and resilient software development process. As threats continue to evolve, embracing DevSecOps is not just a best practice; it's a critical imperative for the future of software development and IT operations.

By Sanjana Thakur

Navigating Azure Project Management: A Deep Dive Into Efficient Operations and Deployment

In today’s digital landscape, cloud computing platforms have become essential for businesses seeking scalable, reliable, and secure solutions. Microsoft Azure, a leading cloud provider, offers a wide range of services and resources to meet the diverse needs of organizations. In this blog post, we will delve into Azure project management, highlighting the significant tasks carried out to ensure efficient operations and successful deployment during your software product development journey. Azure Project Management: Infrastructure and Services Resource Setup To kickstart the project, several key resources were provisioned on Microsoft Azure. App Services were established for both frontend and backend components, enabling the seamless delivery of web applications. MySQL databases were implemented to support data storage and retrieval for both the front end and back end. Additionally, Service Buses and Blob Storages were configured to facilitate efficient messaging and file storage, respectively. Bitbucket Pipelines for Automated Deployment To streamline the deployment process in Azure DevOps project management, Bitbucket Pipelines were implemented. These pipelines automate the deployment workflow, ensuring consistent and error-free releases. With automated deployments, developers can focus more on building and testing their code while the deployment process itself is handled seamlessly by the pipelines. Autoscaling for App Services To optimize resource allocation and ensure optimal performance, autoscaling was configured for all the App Services. This dynamic scaling capability automatically adjusts the number of instances based on predefined metrics such as CPU utilization or request count. By scaling resources up or down as needed, the project can handle varying workloads efficiently, maintaining responsiveness and cost-effectiveness. Azure Kubernetes Cluster for AI API To leverage the power of containerization and orchestration, the AI API component of the project was moved to an Azure Kubernetes Cluster (AKS). Kubernetes provides a scalable and resilient environment for running containerized applications, allowing for easy management and deployment of the AI API. This migration enhances flexibility, scalability, and fault tolerance in Azure project management, enabling seamless integration with other project components. Migration to Azure Service Bus In a bid to enhance messaging capabilities, the existing RabbitMQ infrastructure was migrated to Azure Service Bus. Azure Service Bus provides a reliable and scalable messaging platform, ensuring seamless communication between different components of the project. The migration offers improved performance, higher scalability, and better integration with other Azure services. Deprecation Updates and Function Creation As technology evolves, it is crucial to keep the project’s infrastructure up to date. Depreciated services such as storage accounts and MySQL were updated to their latest versions, ensuring compatibility and security. Additionally, functions were created for webhooks and scheduled scripts, enabling efficient automation of routine tasks and enhancing the project’s overall efficiency. Monitoring in Azure Project Management Alert Configuration Proactive monitoring is crucial to identify and address any issues promptly. Alerts were set up on all the project’s resources, including App Services, MySQL Databases, Service Buses, and Blob Storage. These alerts help the Azure project management team stay informed about potential performance bottlenecks, security breaches, or other critical events, allowing them to take immediate action and minimize downtime. Monitoring With Elastic Logstack Kibana (ELK) To gain valuable insights into the project’s operational and log data, a monitoring system was set up using Elastic Logstack Kibana (ELK). ELK enables centralized log management, real-time log analysis, and visualization of logs, providing developers and system administrators with a comprehensive view of the project’s health and performance. This monitoring setup aids in identifying and resolving issues quickly, leading to improved system reliability. Security Aspects of Azure Project Management Security Measures Maintaining robust security is paramount for any project hosted on a cloud platform. Various security measures were implemented, including but not limited to network security groups, identity and access management policies, and encryption mechanisms. These measures help protect sensitive data, prevent unauthorized access, and ensure compliance with industry-specific regulations. Manual Deployment for Production Environment While automated deployments offer significant advantages, it is essential to exercise caution in the production environment. To ensure precise control and reduce the risk of unintended consequences, manual deployment was implemented for the project’s production environment. Manual deployments enable thorough testing, verification, and approvals before releasing changes to the live environment, ensuring a stable and reliable user experience. Zero Trust Infrastructure Implementation Given the increasing complexity of cybersecurity threats, a zero-trust infrastructure approach was adopted for the Azure DevOps project management. This security model treats every access attempt as potentially unauthorized, requiring stringent identity verification and access controls. By implementing zero trust principles, the project minimizes the risk of data breaches and unauthorized access, bolstering its overall security posture. Optimizing Cost and Enhancing Efficiency While Microsoft Azure offers a comprehensive suite of services, it’s essential to ensure cost optimization to maximize the benefits of cloud computing. Here, we will explore the actions taken to reduce billing usage in Microsoft Azure project management. By implementing these strategies, the project team can optimize resource allocation, eliminate unnecessary expenses, and achieve significant cost savings. Backend Scaling Configuration Optimization One of the key areas for cost reduction is optimizing the backend scaling configuration. By carefully analyzing the project’s workload patterns and performance requirements, the scaling configuration was adjusted to align with actual demand. This ensures that the project provisions resources based on workload needs, avoiding overprovisioning and unnecessary costs. Fine-tuning the backend scaling configuration helps strike a balance between performance and cost-effectiveness. Scheduler for Container Apps and Environment Optimization Containerized applications are known for their agility and resource efficiency. To further enhance cost optimization, a scheduler was implemented for container apps. This scheduler automatically starts and stops container instances based on predefined schedules or triggers, eliminating the need for 24/7 availability when not required. Additionally, unnecessary environments that were initially provisioned due to core exhaustion were removed, consolidating the project’s resources into a single optimized environment. Function API for Container Management To provide developers with control over container instances, a Function API was created. This API allows developers to start and stop containers as needed, enabling them to manage resources efficiently. By implementing this granular control mechanism, the project ensures that resources are only active when necessary, reducing unnecessary costs associated with idle containers. Front Door Configuration Improvement Front Door, a powerful Azure service for global load balancing and traffic management, was optimized to avoid unnecessary requests to project resources. By fine-tuning the configuration, the Azure project team reduced the number of requests that reached the backend, minimizing resource consumption and subsequently lowering costs. This optimization ensures that only essential traffic is directed to the project’s resources, eliminating wastage and enhancing efficiency. Removal of Unwanted Resources Over time, projects may accumulate unused or redundant resources, leading to unnecessary billing costs. A thorough audit of the Azure environment was conducted as part of the cost reduction strategy, and unwanted resources were identified and removed. By cleaning up the Azure environment, the project team eliminates unnecessary expenses and optimizes resource allocation, resulting in significant cost savings. Conclusion Successfully managing a project on Microsoft Azure requires careful planning, implementation, and ongoing optimization. By leveraging the robust features and capabilities of Microsoft Azure, the project team can ensure a secure, scalable, and reliable solution, ultimately delivering a seamless user experience. Moreover, cost optimization is a critical aspect of managing projects on Microsoft Azure. By implementing specific strategies to reduce billing usage, such as optimizing backend scaling configurations, implementing schedulers, leveraging Function APIs for resource management, improving front door configurations, and removing unwanted resources, the project team can achieve substantial cost savings while maintaining optimal performance. With continuous monitoring and optimizing costs, organizations can ensure that their Azure projects are efficient, cost-effective, and aligned with their budgetary requirements.

By Pritesh Patel

Building a DevOps Culture Layer by Layer

DevOps is a game-changing approach to software development. It combines agility, speed, and quality to revolutionize how we create and deploy software. By breaking down barriers between development and operations, DevOps fosters collaboration and enables faster and more reliable software releases. But it's important to remember that DevOps is not just about tools and methods — it's a cultural shift that brings teams together for success. This cultural change involves breaking down existing barriers, enhancing communication, and encouraging continuous improvement. In this post, I want to talk about building a DevOps culture layer by layer. Especially to uncover the potential challenges you may encounter in implementing it in your business and the strategies to overcome these obstacles. This journey is not without difficulties, but the benefits of a successful DevOps culture—improved efficiency, faster delivery times, and high-quality products — are well worth the effort. The Core Principles of DevOps Culture A successful DevOps culture leans on several core principles: Collaboration and communication: This fundamental tenet focuses on breaking down silos and fostering an environment of transparency and mutual respect among the developers, operations team, and other stakeholders. Automation: By automating repetitive tasks, organizations can increase efficiency, reduce errors, and allow their teams to focus on more strategic, higher-value work. Continuous improvement: A cornerstone of DevOps is the adoption of iterative processes, constantly seeking to improve, innovate, and refine practices and procedures. Customer-centric approach: DevOps culture emphasizes the importance of delivering value to the customer quickly and reliably, using customer feedback to guide development and operations. Embracing failure: In a DevOps culture, failures are seen as opportunities to learn and innovate, not as setbacks. Teams are encouraged to take calculated risks, knowing they have the support to learn and grow from the outcomes. Uniting teams and expertise: A successful DevOps culture promotes the sharing of knowledge and expertise across teams, fostering a sense of collective ownership and shared responsibility. By understanding and implementing these core principles, organizations can lay the foundation for a thriving DevOps culture. Let's explore the process of building this culture layer by layer. The Process: Building a DevOps Culture Layer-by-Layer To successfully build a DevOps culture, it's essential to follow a systematic approach that involves several key steps: Setting the stage: Before committing to DevOps, it's crucial to understand why it is necessary for your organization and what outcomes you hope to achieve. This step includes communicating the benefits of DevOps to all stakeholders and getting buy-in from upper management. Setting goals: Meaningful, achievable goals are essential for progress. These targets can include reducing lead times, increasing deployment frequency, or improving software quality. By setting clear goals, teams can measure progress and stay motivated. Leading the charge: A technical leader must spearhead the DevOps transformation, acting as a role model for their team and guiding them through the changes. Pilot testing: It's best to start small when implementing DevOps. Choose a non-critical project that can serve as a pilot test to identify areas for improvement and refine your processes before scaling up. Manage or remove silos: The core of DevOps is communication. As a result, you can't afford to have collaboration and communication issues if you want your DevOps efforts to work. Try to break down silos by creating cross-functional teams and encourage communication and collaboration between them. By doing so, your teams can share knowledge and expertise, fostering a sense of collective ownership. Reorganizing team duties and incentives: Traditional roles may need to be redefined in a DevOps culture. For example, developers may need to take on some operations tasks, while operations team members may need to learn coding skills. Incentives and performance metrics should also align with the goals of DevOps. Conflict resolution: With any change, conflicts are bound to arise. It's essential to have a process in place for mediating disputes and promoting open communication among team members. Foster a collaborative environment: A collaborative environment is vital for a successful DevOps culture. Teams must feel comfortable sharing ideas and providing constructive feedback. Encourage End-to-End Responsibility: In a DevOps culture, everyone is responsible for the entire software development lifecycle. This mindset promotes accountability and encourages teams to think about the big picture. By following these steps, organizations can gradually build a strong DevOps culture that supports continuous improvement and drives success. Challenges and Strategies for Overcoming Them Building a DevOps culture is not without its challenges. Here are some common obstacles organizations may face and strategies to overcome them: Resistance to Change Adopting a DevOps culture requires a significant shift in mindset and practices, which can be met with resistance from team members who are used to traditional development and operations methods. To overcome this, it's crucial to have open communication and involve all team members in the process. Lack of Automation Without proper automation, DevOps practices can't be fully realized. It's essential to invest in tools that automate tasks and processes to increase efficiency and reduce errors. Insufficient Collaboration A DevOps culture relies heavily on collaboration and communication. If team members are not willing to share knowledge and work together, it can impede the success of DevOps. Organizations must foster a collaborative environment where all team members feel comfortable working together. Inadequate Leadership Support For DevOps to succeed, it requires support from upper management. If leaders do not fully understand or support the shift towards DevOps, it can hinder progress. To overcome this, it's crucial to educate leaders on the benefits and outcomes of DevOps. Shifting Roles and Responsibilities As mentioned earlier, traditional roles may need to be redefined in a DevOps culture. This shift can cause confusion and conflict among team members. Clear communication and training can help mitigate these challenges. And also proper documentation so that everyone knows what their roles are and where to find the details of their work. Overall, building a DevOps culture requires patience, persistence, and a willingness to learn and adapt. By following these guidelines and strategies, organizations can lay the foundation for a successful DevOps culture layer by layer. Over to You There is no end to improving and refining a DevOps culture; it's an ongoing process that requires constant evaluation and adaptation. With dedication and a commitment to continuous improvement, organizations can reap the benefits of a thriving DevOps culture that drives success and innovation. So, let's continue building this culture layer by layer together.

By Syed Balkhi

Everything You Need to Know About Story Points in Jira

Estimating work is hard as it is. Using dates over story points as a deciding factor can add even more complications, as they rarely account for the work you need to do outside of actual work, like emails, meetings, and additional research. Dates are also harder to measure in terms of velocity making it harder to estimate how much effort a body of work takes even if you have previous experiences. Story points, on the other hand, can bring more certainty and simplify planning in the long run… If you know how to use them. What Are Story Points in Scrum? Story points are units of measurement that you use to define the complexity of a user story. In simpler words, you’ll be using a gradation of points from simple (smallest) to hardest (largest) to rank how long you think it would take to complete a certain body of work. Think of them as rough time estimates of tasks in an agile project. Agile teams typically assign story points based on three major factors: The complexity of work; The amount of work that needs to be done; And the uncertainty in how one could tackle a task. The less you know about how to complete something, the more time it will take to learn. How to Estimate a User Story With Story Points Ok, let’s take a good look at the elephant in the room: There’s no one cut and dry way of estimating story points. The way we do it in our team is probably different from your estimation method. That’s why I will be talking about estimations on a more conceptual level making sure anyone who’s new to the subject matter can understand the process as a whole and then fine-tune it to their needs. T-shirt size Story Point Time to deliver work XS 1 Minutes to 1-2 hours S 2 Half a day M 3 1-2 days L 5 Half a week XL 8 Around 1 week XXL 13 More than 1 week XXXL 21 Full Sprint Story point vs. T-shirt size Story Points of 1 and 2 Estimations that seem the simplest can sometimes be the trickiest. For example, if you’ve done something a lot of times and know that this one action shouldn’t take longer than 10-15 minutes, then you have a pretty clear one-pointer. That being said, the complexity of a task isn’t the only thing you need to consider. Let’s take a look at fixing a typo on a WordPress-powered website as an example. All you need to do is log into the interface, find the right page, fix the typo, and click publish. Sounds simple enough. But what if you need to do this multiple times on multiple pages? The task is still simple, but it takes a significantly longer amount of time to complete. The same can be said about data entry and other seemingly trivial tasks that can take a while simply due to the number of actions you’ll need to perform and the screens you’ll need to load. Story Point Estimation in Complex User Stories While seemingly simple stories can be tricky, the much more complex ones are probably even trickier. Think about it: If your engineers estimate, they’ll probably need half a week to a week to complete one story; there’s probably a lot they are still uncertain of in regards to implementation, meaning a story like that could take much longer. Then there’s the psychological factor where the team will probably go for the low-hanging fruits first and use the first half of the week to knock down the one, two, and three-pointers. This raises the risk of the five and eight-pointers not being completed during the Sprint. One thing you can do is ask yourself if the story really needs to be as complex as it is now? Perhaps it would be wiser to break it down. You can find out the answer to whether you should break a story using the KISS principle. KISS stands for “Keep It Simple, Stupid” and makes you wonder if something needs to be as complex as it is. Applying KISS is pretty easy too — just ask a couple of simple questions like what is the value of this story and if the same value can be achieved in a more convenient way. “Simplicity is the ultimate sophistication.” –Leonardo Da Vinci How to Use Story Points in Atlassian’s Jira A nice trick I like is to give the team the ability to assign story points to epics. Adding the story points field is nothing too in-depth or sophisticated as a project manager needs the ability to easily assign points when creating epics. The rule of thumb here is to indicate whether your development team is experienced and well-equipped to deliver the epic or whether they would need additional resources and time to research. An example of a simpler epic could be the development of a landing page and a more complex one would be the integration of ChatGPT into a product. The T-shirt approach works like a charm here. While Jira doesn’t have the functionality to add story points to epics by default, you can easily add a checkbox custom field to do the trick. Please note that you’ll need admin permissions to add and configure custom fields in Jira. Assigning story points to user stories is a bit trickier as — ideally — you’d like to take everyone’s experience and expertise into consideration. Why? A project manager can decide the complexity of an epic based on what the team has delivered earlier. Individual stories are more nuanced as engineers will usually have a more precise idea of how they’ll deliver this or that piece of functionality, which tools they’ll use and how long it’ll take. In my experience, T-shirt sizes don’t fit here as well as the Fibonacci sequence. The given sequence exhibits a recurring pattern in which each number is obtained by adding the previous two numbers in the series. The sequence begins with 0, 1, 1, 2, 3, 5, 8, 13, 21, 34, 55, and 89, and this pattern continues indefinitely. This sequence, known as the Fibonacci sequence, is utilized as a scoring scale in Fibonacci agile estimation. It aids in estimating the effort required for agile development tasks. This approach proves highly valuable as it simplifies the process by restricting the number of values in the sequence, eliminating the need for extensive deliberation on complexity nuances. This simplicity is significant because determining complexity based on a finite set of points is much easier. Ultimately, you have the option of selecting either 55 or 89, rather than having to consider the entire range between 55 and 89. As for the collaboration aspect of estimating and assigning story points to user stories, there’s a handy tool called Planning Poker. This handy tool helps the team collaborate on assigning story points to their issues. Here’s the trick: each team member anonymously assigns a value to an issue, keeping their choices incognito. Then, when the cards are revealed, it’s fascinating to see if the team has reached a consensus on the complexity of the task. If different opinions emerge, it’s actually a great opportunity for engaging in discussions and sharing perspectives. The best part is, this tool seamlessly integrates with Jira, making it a breeze to incorporate into your existing process. It’s all about making teamwork smoother and more efficient! How does the process of assigning story points work? Before the Sprint kicks off — during the Sprint planning session — the Scrum team engages in thorough discussions regarding the tasks at hand. All the stories are carefully reviewed, and story points are assigned to gauge their complexity. Once the team commits to a Sprint, we have a clear understanding of the stories we’ll be tackling and their respective point values, which indicate their significance. As the Sprint progresses, the team diligently works on burning down the stories that meet the Definition of Done by its conclusion. These completed stories are marked as finished. For any unfinished stories, they are returned to the backlog for further refinement and potential re-estimation. The team has the option to reconsider and bring these stories back into the current Sprint if deemed appropriate. When this practice is consistently followed for each sprint, the team begins to understand their velocity — a measure of the number of story points they typically complete within a Sprint — over time. It becomes a valuable learning process that aids in product management, planning, and forecasting future workloads. What Do You Do With Story Points? As briefly mentioned above — you burn them throughout the Sprint. You see, while story points are good practice for estimating the amount of work you put in a Sprint, Jira makes them better with Sprint Analytics showing you the amount of points you’ve actually burned through the Sprint and comparing it to the estimation. These metrics will help you improve your planning in the long run. Burndown chart: This report tracks the remaining story points in Jira and predicts the likelihood of completing the Sprint goal. Burnup chart: This report works as an opposite to the Burndown chart. It tracks the scope independently from the work done and helps agile teams understand the effects of scope change. Sprint report: This report analyses the work done during a Sprint. It is used to point out either overcommitment or scope creep in a Jira project. Velocity chart: This is a kind of bird’s eye view report that shows historic data of work completed from Sprint to Sprint. This chart is a nice tool for predicting how much work your team can reliably deliver based on previously burned Jira story points. Add Even More Clarity to Your Stories With a Checklist With a Jira Checklist, you have the ability to create practical checklists and checklist templates. They come in handy when you want to ensure accountability and consistency. This application proves particularly valuable when it comes to crafting and enhancing your stories or other tasks and subtasks. It allows you to incorporate explicit and visible checklists for the Definition of Done and Acceptance Criteria into your issues, giving you greater clarity and structure. It’s ultimately a useful tool for maintaining organization and streamlining your workflow with automation. Standardization isn’t about the process. It’s about helping people follow it.

By Oleksandr Siryi

DevOps Uses a Capability Model, Not a Maturity Model

Your approach to DevOps is likely to be influenced by the methods and practices that came before. For organizations that gave teams autonomy to adapt their process, DevOps would have been a natural progression. Where an organization has been more prescriptive in the past, people will look for familiar tools to run a DevOps implementation, such as maturity models. In this article, I explain why a maturity model isn't appropriate and what you should use instead. What Is a Maturity Model? A maturity model represents groups of characteristics, like processes or activities, into a sequence of maturity levels. By following the groups from the easiest to the most advanced, an organization can implement all the required elements of the model. The process is a journey from adoption through to maturity. Maturity models: Provide a roadmap for adopting characteristics Make it easier to get started by suggesting a smaller initial set of characteristics Can be assessed to provide the organization with a maturity score For example, a maturity model for riding a bike might have 5 levels of maturity: Walk upright on 2 legs Ride a balance bike with a walking motion Ride a balance bike with both feet off the ground Ride a pedal bike from a starting point facing downhill Ride a pedal bike from a starting point facing uphill The sequence of maturity levels is a useful roadmap to follow and you may already be able to achieve the lower levels. Each maturity level is easier to reach from the level below, as the earlier levels provide a basis for increasing your skills and progressing to the next stage. You can also assess someone by asking them to demonstrate their ability at each level. You can create a maturity model by designing the levels first and expanding each with characteristics, or you can collect together all the characteristics before arranging them into levels. You'll find maturity models are commonly used as part of standards and their certification process. Most process certifications require you to demonstrate that: You have documented your process People follow the documented process You regularly review and improve the process When you plan to achieve a certification, your roadmap is clear; until you document the process you can't tell if people are following it. Limitations of Maturity Models You can use a maturity model to assess whether a set of activities is taking place, but not whether these activities impact your key outcomes. Maturity models are rigid and require you to adopt all characteristics to achieve maturity levels. You have to trust that following the model will bring you the same benefits experienced by the model's authors. The sequence of maturity levels might not work for everyone. They could slow down your progress or even have counter-productive outcomes. A maturity model doesn't take into account the unique challenges facing your business — it may not even solve the kind of problems you're facing. It also defines an end point that may not be good enough. Maturity models are most commonly used in due-diligence frameworks to ensure suppliers meet a minimum standard for process or security. If you were cynical, you might argue they're used to ensure an organization can't be blamed when one of its suppliers makes a mistake. In DevOps, the context and challenges faced by organizations and teams are so important, a maturity model is not an appropriate tool. If you want to apply a maturity model to DevOps, you may need to adjust your mindset and approach as there's no fixed end state to DevOps. Neither should the capabilities be adopted in a pre-determined order. Maturity models are not appropriate for DevOps because they: Assume there is a known answer to your current context Focus on arriving at a fixed end state Encourage standardization, not innovation and experimentation Have a linear progression Are activity-based For DevOps, you need a different kind of model. Capability Models A capability model describes characteristics in terms of their relationship to an outcome. Rather than arrange sets of characteristics into levels, they connect them to the effect they have on a wider system outcome. Going back to riding a bike, a capability model would show that balance affects riding stability and steering, whereas walking has some bearing on the ability to pedal to power the bicycle. Instead of following the roadmap for learning to ride a bike, you would identify areas that could be improved based on your current attempts to ride. If you were using a capability model, you wouldn't stop once you proved you could ride uphill. Capability models encourage you to continue your improvement efforts, just like Ineos Grenadiers (formerly Sky Professional Racing/Team Sky) who achieved 7 Tour de France wins in their first 10 years using their approach to continuous improvement, which they called marginal gains. A capability model: Focuses on continuous improvement Is multi-dimensional, dynamic, and customizable Understands that the landscape is always changing Is outcome-based When you use a capability model, you accept that high performance today won't be sufficient in the future. Business, technology, and competition are always on the move and you need a mindset that can keep pace. Maturity vs. Capability Models A maturity model tends to measure activities, such as whether a certain tool or process has been implemented. In contrast, capability models are outcome-based, which means you need to use measurements of key outcomes to confirm that changes result in improvements. For example, the DevOps capability model is aligned with the DORA metrics. Using throughput and stability metrics helps you assess the effectiveness of improvements. While maturity models tend to focus on a fixed standardized list of activities, capability models are dynamic and contextual. A capability model expects you to select capabilities that you believe will improve your performance given your current goals, industry, organization, team, and the scenario you face at this point in time. You level up in a maturity model based on proficiency against the activities. In a capability model, you constantly add gains as you continuously improve your skills and techniques. These differences are summarized below: Maturity model Capability model Activity-based Outcome-based Fixed Dynamic Standardized Contextual Proficiency Impact The DevOps Capability Model The DevOps capability model is the structural equation model (SEM), sometimes referred to as the big friendly diagram (BFD). It arranges the capabilities into groups and maps the relationships they have to outcomes. Each of the arrows describes a predictive relationship. You can use this map to work out what items will help you solve the problems you're facing. For example, Continuous Delivery depends on several technical capabilities, like version control and trunk-based development, and leads to increased software delivery performance and reduced burnout (among other benefits). If you find this version of the model overwhelming, the 2022 version offers a simpler view, with many of the groups collapsed. Using simplified views of the model can help you navigate it before you drill into the more detailed lists of capabilities. How to Use the DevOps Model Depending on which version you look at, the model can seem overwhelming. However, the purpose of the model isn't to provide a list of all the techniques and practices you must adopt. Instead, you can use the model as part of your continuous improvement process to identify which capabilities may help you make your next change. As the capability model is outcome-based, your first task is finding a way to measure the outcomes for your team and organization. Any improvement you make should eventually move the needle on these outcomes, although a single capability on its own may not make a detectable difference. The DORA metrics are a good place to start, as they use throughput and stability metrics to create a balanced picture of successful software delivery. In the longer term, it's best to connect your measurements to business outcomes. Whatever you measure, everyone involved in software delivery and operations needs to share the same goals. After you can measure the impact of changes, you can review the capability model and select something you believe will bring the biggest benefit to your specific scenario. The highest performers use this process of continuous improvement to make gains every year. The high performers are never done and persistently seek new opportunities to build performance. This is why the high performance of today won't be enough to remain competitive in the future. Conclusion DevOps shouldn't be assessed against a maturity model. You should be wary of anyone who tries to introduce one. Instead, use the structural equation model from Accelerate and the State of DevOps reports as part of your continuous improvement efforts. The DevOps capability model supports the need for constant incremental gains and encourages teams to experiment with their tools and processes. Happy deployments!

By Steve Fenton

Team Management

DZone's Featured Team Management Resources

Top Team Management Experts

The Latest Team Management Topics