DZone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
Refcards Trend Reports
Events Video Library
Over 2 million developers have joined DZone. Join Today! Thanks for visiting DZone today,
Edit Profile Manage Email Subscriptions Moderation Admin Console How to Post to DZone Article Submission Guidelines
View Profile
Sign Out
Refcards
Trend Reports
Events
View Events Video Library
Zones
Culture and Methodologies Agile Career Development Methodologies Team Management
Data Engineering AI/ML Big Data Data Databases IoT
Software Design and Architecture Cloud Architecture Containers Integration Microservices Performance Security
Coding Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Culture and Methodologies
Agile Career Development Methodologies Team Management
Data Engineering
AI/ML Big Data Data Databases IoT
Software Design and Architecture
Cloud Architecture Containers Integration Microservices Performance Security
Coding
Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance
Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks

Migrate, Modernize and Build Java Web Apps on Azure: This live workshop will cover methods to enhance Java application development workflow.

Kubernetes in the Enterprise: The latest expert insights on scaling, serverless, Kubernetes-powered AI, cluster security, FinOps, and more.

A Guide to Continuous Integration and Deployment: Learn the fundamentals and understand the use of CI/CD in your apps.

Culture and Methodologies

In our Culture and Methodologies category, dive into Agile, career development, team management, and methodologies such as Waterfall, Lean, and Kanban. Whether you're looking for tips on how to integrate Scrum theory into your team's Agile practices or you need help prepping for your next interview, our resources can help set you up for success.

Functions of Culture and Methodologies

Agile

Agile

The Agile methodology is a project management approach that breaks larger projects into several phases. It is a process of planning, executing, and evaluating with stakeholders. Our resources provide information on processes and tools, documentation, customer collaboration, and adjustments to make when planning meetings.

Career Development

Career Development

There are several paths to starting a career in software development, including the more non-traditional routes that are now more accessible than ever. Whether you're interested in front-end, back-end, or full-stack development, we offer more than 10,000 resources that can help you grow your current career or *develop* a new one.

Methodologies

Methodologies

Agile, Waterfall, and Lean are just a few of the project-centric methodologies for software development that you'll find in this Zone. Whether your team is focused on goals like achieving greater speed, having well-defined project scopes, or using fewer resources, the approach you adopt will offer clear guidelines to help structure your team's work. In this Zone, you'll find resources on user stories, implementation examples, and more to help you decide which methodology is the best fit and apply it in your development practices.

Team Management

Team Management

Development team management involves a combination of technical leadership, project management, and the ability to grow and nurture a team. These skills have never been more important, especially with the rise of remote work both across industries and around the world. The ability to delegate decision-making is key to team engagement. Review our inventory of tutorials, interviews, and first-hand accounts of improving the team dynamic.

Latest Refcards and Trend Reports
Trend Report
DevOps
DevOps
Refcard #008
Design Patterns
Design Patterns
Refcard #093
Lean Software Development
Lean Software Development
Trend Report
Performance and Site Reliability
Performance and Site Reliability

DZone's Featured Culture and Methodologies Resources

Trend Report

Kubernetes in the Enterprise

In 2022, Kubernetes has become a central component for containerized applications. And it is nowhere near its peak. In fact, based on our research, 94 percent of survey respondents believe that Kubernetes will be a bigger part of their system design over the next two to three years. With the expectations of Kubernetes becoming more entrenched into systems, what do the adoption and deployment methods look like compared to previous years?DZone's Kubernetes in the Enterprise Trend Report provides insights into how developers are leveraging Kubernetes in their organizations. It focuses on the evolution of Kubernetes beyond container orchestration, advancements in Kubernetes observability, Kubernetes in AI and ML, and more. Our goal for this Trend Report is to help inspire developers to leverage Kubernetes in their own organizations.

Kubernetes in the Enterprise
Scaling SRE Teams

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

Refcard #266

Agile Patterns

By $$anonymous$$
Agile Patterns
CodeCraft: Agile Strategies for Crafting Exemplary Software
CodeCraft: Agile Strategies for Crafting Exemplary Software
By Parul Batra
The Most Valuable Code Is the Code You Should Not Write
The Most Valuable Code Is the Code You Should Not Write
By Jasper Sprengers DZone Core CORE
5 Steps To Tame Unplanned Work
5 Steps To Tame Unplanned Work

In an ideal world, there are no zero-day security patches that absolutely must be applied today. There are no system outages - shortage never becomes full; APIs don't stop accepting parameters they accepted yesterday, users don't call support desks with tricky problems and everyone else writes code as good as you do so there are no bugs. Maybe one day, but until then, there is unplanned but urgent work. Whether you call it DevOps, support, maintenance, or some other euphemism, it is work that just appears and demands to be done. The problem is this work is highly disruptive and destroys the best-laid plans. While sticking one's head in the sand and pretending the work does not exist, it does exist and it demands attention. The question then is: how best can such work be managed? Step 1: Acceptance Despite attempts by Project Managers and Scrum Masters to keep teams dedicated to shiny new things, "Stuff happens," as they say. So to start off with, everyone needs to stop wishful thinking. Put it this way: if you come up with a way of handling unplanned but urgent work and it never happens again then you have only lost a few hours of thinking. However, if you don't plan and it does happen then it is going to take up a lot more time and effort. Let's also accept that there is no Bug Fixing Fairy or DevOps Goblin. One day ChatGPT might be able to handle the unexpected, but until then, doing this work is going to require time and effort from the people who would otherwise be doing the shiny new stuff. There is only one pot of capacity and if Lenny is applying a security patch, she isn't working on new features. Step 2: Capture and Make Visible Back in the days of physical boards, I would write out a yellow card and put it on the board. These days it is probably a ticket in an electronic system; however, you do it to make sure those tickets are easily identified so people can easily see them and they can be found later. This may sound obvious, but an awful lot of unplanned work is done under the covers; because "it should not exist," some people object to it being done. Even when the work is trivial it still represents disruption and task switching, and it might fall disproportionally on some individuals. A few years ago I met a team who were constantly interrupted by support work. They felt they couldn't do anything new because of the stream of small, and large, unexpected work. I introduced the yellow card system and with that one change, the problem went away. What happened was that it quickly became clear that the team had, on average, only one unexpected urgent request a week. But because the requests were high profile, people kept asking about them and pressure was heaped on to fix it. Once the request was a clearly identifiable yellow card on a work board, everybody in the company could see it. Anyone could walk up to the board and see the status and who was working on it. Overnight the bulk of the interruptions went away. A lot of the previous interruptions had been people asking, "What is happening?" It was that simple. Once the work is captured and made visible, people can start to see that requests are respected and action taken. Now attention can turn to priority. Step 3: Meaningful Prioritization When trust is absent, nobody believes that anything will be done so everyone demands their ask has top priority. In time, as people learn requests are respected and acted on; then meaningful priority decisions can be made. I met a company where one of the founders had a habit of picking up customer requests, walking across to a dev team member, and asking, "Can you just...?" Of course, the dev wouldn't say "no" to a founder, so their work was interrupted. In addition to the yellow card, a priority discussion was needed. The team was practicing a basic Agile system with all the work for the next Sprint listed in priority order on their Kanban board. When the founder came over, the dev would write the request on a yellow card, then walk over to the Kanban board and ask, "You can see the card I'm working on right now: should I stop what I'm doing and do the new request?" If the founder said "yes," then the dev would honor the request. But seeing what would be interrupted, the founder was likely to say, "Well, finish that first." Now the dev would put the card next to the priority work queue and ask, "Is this the new priority number one?" If it was, the card went to the top of the queue and the next available person would pick it up. If not, the dev would work down the list: "The new priority two? three? four?" We had a simple feedback process. Beforehand, the founder had no idea of the consequences of asking, "Can you just. . .?" Now they could see what work would be delayed, displaced, and interrupted. These three steps alone can manage a lot of unplanned but urgent work and improve team performance quickly, yet it can still be better provided your ticketing system is capturing all these instances physically or electronically. Step 4: Use Data To Get Better At the most basic level, count the yellow cards and count the other planned work cards. Now calculate the ratio of how much planned v. unplanned work is going on over time and feed this back into planning. For example, one development manager calculated that unplanned work accounted for 20% to 25% of the team's Sprint on average (using several months of data.) So to start with, they scheduled 20% less work per Sprint. This alone made the team more predictable. You don't even need to bother with estimates here - you can if you really want to, but this is not going to be perfect, just good enough. Simply knowing the ratio is a start. Over time you may refine your calculations, but start simple. Step 5: Fix at Source Use the yellow tickets as part of your retrospective. Start by considering if the tickets really did deserve to be fast-tracked into work. The team should talk about this with the Product Owner/Manager and other stakeholders. Now everyone can appreciate the impact you might find that some requests really shouldn't be prioritised. Next, you can look at the nature of the requests and see if there is some pattern. Perhaps many originate from one stakeholder. Perhaps somebody should go and talk with them about why they generate so many unplanned requests - maybe they can start making requests before Sprint planning. Similarly, it might be one customer who is raising many tickets. Perhaps this customer has some specific problems, perhaps they have never had training or simply don't appreciate how the system works. It could be that some particular sub-system or third-party component is causing problems. Some remedial work/some refactoring could help, or maybe the component needs to be replaced entirely. When there is data arguing for the time to do such work is a lot easier. You might find that the team lacks particular skills or needs expansion. The same manager who budgeted for 20% of unplanned work later analyzed the tickets and found that the majority of the unplanned tickets were for general IT support which didn't need specialist coding skills. These findings were taken to the big boss and permission was quickly given to hire an IT support technician. Getting a 20% boost to programmer productivity for less than the cost of another coder was too good a deal to miss! Sometimes expanding the team isn't an option, and sometimes the tickets don't point to a missing skill. Another solution is the "sacrificial one." In these cases, a team of five experiencing 20% unplanned work will have one member handle the unplanned stuff. This means one team member soaks up all the interruptions which allows the others to stay focused. Few people like being the sacrificial lamb so rotate the position regularly; say, every Sprint. In one example, team members were concerned it would not work because they each specialized in different parts of the system. They agreed to try and work on any ticket that came up during their week as on-support. Even though it would take them longer than a colleague who specialized in that part of the system, it could increase overall throughput. After a few weeks, team members found they could deal with far more tickets than they expected and were learning more about the system. If they were stuck they might get just 10 minutes of the specialist and then do it themselves. Work the Problem The thing is as much as you don't want unplanned and urgent work to exist, it does. Project Managers have spent years trying to stamp it out and, without great pain, they can't. In fact, the whole DevOps movement runs counter to this school of thought. The five steps set out here might not create the ideal world but they should make the real world more controlled and manageable. One day AI systems might take over unplanned work, but it is often in unexpected situations when things should work but don't that human ingenuity is needed most.

By Allan Kelly DZone Core CORE
Be a Better Team Player
Be a Better Team Player

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!

By Alvin Lee DZone Core CORE
Should I Start My Job Search Now?
Should I Start My Job Search Now?

My post about my 6-month job search generated some attention and conversation. The comments helped me clarify some of the more specific lessons I’ve learned recently or that I knew but were reinforced by the experience. After taking time to organize them into a somewhat coherent structure, I’m ready to share. Here are the first lessons on the list. As always, if you have opinions, corrections, or experiences you want to share, please do so in the comments below. I get this question (“Should I start looking now?”) a lot, both from people fresh out of school or boot camp, folks who are in their first or second job but aren’t sure whether they should make their next move; and people who have been working at the same place for a while, but wonder about the color of the grass beyond the fence of their organizational borders. I tell everyone the same thing: It’s never a bad time to look around the airplane and check where the exits are located and the parachutes are stored. As far as I can tell, there’s nothing to lose by semi-seriously applying for jobs that look interesting and seeing where things lead. At worst, you’ll find a job you’re not a good fit for or a company where you wouldn’t want to work. At best, you’ll know your value in the market and have a flattering offer in hand. “No, Leon. The worst is that I apply, someone blabs, and I lose my job.” Look, I’m not an employment lawyer, but if that happens, it seems like you might need one because that kind of sh… tuff is patently illegal. Yes, it’s a hassle nobody wants or needs. But it’s also incredibly uncommon. The risk of taking out production with your next change control is significantly higher. The secondary benefit of applying often — at least once every six months, but better if you can swing it once a quarter — is that you keep your interviewing skills sharp in a low-stakes situation. If you bomb the interview, you still have your current job, and nothing is lost. But even if you bomb, what you’ve gained is a valuable insight into what happened, and why, and how you might approach that situation differently. It’s hard to understate the value this mental preparedness has when you’re in a situation where you NEED (or really, really WANT) the job you’re interviewing for. Being a veteran of four interviews a year, you enter each conversation with a set of stock answers to common questions. Every question from every interviewer feels less like a surprise quiz and more like a conversation. The calmness and confidence this instills can make all the difference. “That’s a pretty fairy tale, but what happens if my company finds out I’m interviewing? Am I just supposed to tell them I’m doing it for fun? Yes. To be honest, I have started telling the companies where I work that I do this up-front, just to avoid surprises. I’ll admit this is a HUGE function of the privilege I carry, and I know it. Please use caution. That said, I tell them for a few reasons: First, I often interview because I mentor folks who are looking for jobs, and I want to be able to talk about the interview process credibly. Second (and this is the more controversial part), if my interviewing makes my employer nervous, it says more about their feelings about how I’m being compensated than it says about my loyalty to the company. Again, I know how risky that attitude is, and I caution you to carefully consider following in my footsteps. The upshot of all of this is that if you are wondering if it’s time to interview, it probably is. I’d love to hear what you think in the comments below.

By Leon Adato
Agile Testing: Blending Shift-Left, Automation, and Collaborative Testing Strategies
Agile Testing: Blending Shift-Left, Automation, and Collaborative Testing Strategies

In the ever-evolving world of software development, Agile methodologies stand out, heralding a new era of collaborative, iterative, and efficient software creation. Central to this transformation is Agile testing – an approach that intertwines testing with development to ensure higher quality, faster delivery, and more responsive software products. This article delves deep into Agile testing, exploring the nuances of shift-left testing, the intricacies of test automation, and the collaboration between developer and QA test automation. Additionally, it sheds light on the Agile concepts of releases and sprints, essential for understanding the broader Agile landscape. The Agile Testing Landscape Agile testing is more than a mere phase; it is an ongoing process integral to every stage of the software development lifecycle. This approach aligns testing activities with ongoing development, ensuring continuous identification and resolution of issues. The result is enhanced product quality and a more streamlined path to market readiness. Shift-Left Testing: A Proactive Stance in Agile Shift-left testing in Agile emphasizes initiating testing activities early in the development process, effectively 'shifting' testing to the left on the project timeline. This strategy brings forth several key advantages: Early Bug Detection: Identifying and addressing issues early, when they are simpler and less costly to resolve, results in a more stable and reliable product. Collaborative Synergy: It fosters a collaborative environment where developers, QA teams, and stakeholders work closely, leading to a holistic understanding of the product and its requirements. Accelerated Delivery: The early feedback loop enables quicker iterations and adjustments, reducing time-to-market for the product. Agile Testing Quadrants: A Comprehensive Framework Brian Marick's Agile Testing Quadrants offer a valuable framework for categorizing different types of tests, ensuring a comprehensive approach to software quality: Quadrant 1: Technology-facing tests guiding development (e.g., unit tests, component tests). Quadrant 2: Business-facing tests guiding development (e.g., functional tests, story tests). Quadrant 3: Business-facing tests critiquing the product (e.g., usability tests, beta testing). Quadrant 4: Technology-facing tests critiquing the product (e.g., performance tests, security tests). The Vital Role of Test Automation in Agile Test automation is an indispensable aspect of Agile testing, particularly for repetitive yet necessary tests. It supports continuous testing and frequent code releases, providing immediate feedback. However, automation should be approached judiciously, complementing rather than replacing manual testing, which remains crucial for exploratory and nuanced user experience assessments. Developer vs. QA Test Automation: Distinct Yet Collaborative In Agile, test automation manifests in two primary forms: developer test automation and QA test automation, each with its unique focus: Developer Test Automation: Concentrates on unit testing and code quality, featuring granular, fast, and integrated tests often aligned with Test-Driven Development (TDD) practices. QA Test Automation: Encompasses a broader view of application stability and user experience, including comprehensive tests like integration, system, and end-to-end tests. Despite these different focus areas, Agile and DevOps practices encourage a convergence of these roles. The shift-left principle involves QA processes earlier in development, leading to a collaborative effort to ensure software quality. Sprints vs. Releases in Agile In Agile, 'sprint' and 'release' are pivotal concepts. A sprint is a short, specific period (usually two to four weeks) where a set of work is completed and reviewed. A release, conversely, is a longer-term culmination of several sprints, resulting in the delivery of a product or significant feature to end-users. While sprints focus on iterative progress, releases are about delivering a cohesive and functional product to the market. Testing plays a critical role in both, ensuring functionality in sprints and overall quality and coherence in releases. To illustrate these concepts with examples: In Shift-Left Testing, a software team working on a new feature begins testing it as soon as the first line of code is written. This early testing could reveal a fundamental design flaw, which is much easier to fix at this stage than after the entire feature is developed. An example of Test Automation could be a regression test suite that runs automatically whenever new code is committed. This ensures that new changes do not break existing functionality. In a Sprint, a team might decide to focus on developing a new user authentication system over a two-week period. Testing in this sprint would ensure that this system works as intended before moving on to the next piece of work. A Release might include not only the new authentication system but also several other features developed in previous sprints. Before this release goes live, comprehensive testing would confirm that all these features work together harmoniously. Conclusion Agile testing, with its focus on shift-left testing, automation, and the collaborative synergy between developer and QA roles, is fundamental in modern software development. It ensures not just the delivery of high-quality software but also fosters an environment of continuous improvement and responsiveness to changing requirements. As Agile methodologies continue to evolve, the fusion of these diverse testing strategies and the clear understanding of Agile concepts like sprints and releases will remain key to successful software delivery.

By Nishant Sharma
You’re Wasting Time With Your Daily Standup
You’re Wasting Time With Your Daily Standup

Let’s say you’ve got 8 people on one of your engineering squads. Your daily standup takes 15 minutes a day. That’s 75 minutes per week, or roughly 3750 minutes per person. You’ve got 8 people, so that’s 30,000 minutes each year for your team or 500 hours. That works out to about 12.5 weeks spent in daily standup for your team.If your average engineer is earning $75,000, then you’re spending about $18,000 each year on your daily standup (not to mention opportunity cost, which is a whole topic in itself). But if your daily standups take 30 minutes, it costs you $36,000. And if you have 10 squads like this in your company, that’s $360,000. So we sure as heck better make our standups count! Five Ways I See Companies Waste Time in Standups (There Are More) The daily standup is envisioned as a 15-minute pulse check, but it often morphs into a parade of distractions, irrelevancies, and just plain inefficiencies. Company A The back-end engineering team at Company A religiously congregates every morning around their Scrum board. The standup never exceeds 15 minutes. But their updates are a monotonous loop of "I did X, today I'll do Y" – an agile charade with zero alignment with sprint goals. The engineers don’t even have sprint goals. The product manager prioritises the backlog, but no two-way conversations are happening. Problem 1: No Alignment With Sprint Goals Anecdotally, an engineer at a FinTech firm recently told me, “Strategic alignment comes from our initiative. I take the initiative to ask about it, but not everyone does that”. Lack of alignment with sprint goals leads to a lack of direction and purpose, causing team members to operate in isolation rather than as a cohesive unit working toward a shared objective. This inefficiency wastes valuable resources and could derail other tasks that are critical to the project. It also impacts stakeholder satisfaction and puts the team out of sync with broader strategic objectives. The very foundation of the Scrum framework is to inspect progress toward the Sprint Goal. Daily Scrums are designed for task updates and as opportunities to adapt and pivot towards achieving that Sprint Goal. Without this focal point, the team misses out on critical chances to adjust course, while eroding cohesion and motivation. Company B Company B has a fully distributed, remote team scattered across 9 hours’ worth of time zones. Ada, from Poland, finds that the live standup in her afternoon takes her out of her flow at peak concentration time. Brent in San Francisco grumbles about needing to log in early while juggling kids who haven't yet been sent off to school. And Clem, who, due to caregiving responsibilities, often misses the live standup, has to catch up through meeting reruns and often misses the chance to contribute. Problem 2: Operational Inefficiencies The logistical gymnastics needed for live standups often means getting in the way of engineers’ personal lives or interrupting their workflow. Time-zone clashes? Check. Flow state broken? Double-check. Is everyone mildly irritated? Triple-check. Problem 3: Lack of Flexibility More like a one-size-fits-none. Failing to adapt the standup format to cater to diverse needs and lifestyles often leads to dissatisfaction and poor adoption. And when you're remote, that dissatisfaction can quietly fester into full-blown detachment. Company C For Company C, the “daily standup” is something of a Proustian endeavour. Complex topics are discussed ad nauseam, sometimes taking up to 45-60 minutes a day. Today, Luis and Zaynab spend 15 minutes dissecting a problem, leaving everyone else twiddling their thumbs or heading off their second screen to multitask. 15 minutes turned out not to be long enough to fix it, and they decided to continue their chat later – but not until they’d wasted a collective 120 working minutes of engineering time for everyone else. A few of the team members are introverted, and the forum doesn’t feel like a good one for them to share their thoughts. They get meeting fatigue alongside the inevitable information overload. Problem 4: Redundancy and Overload When standups turn into mini-hackathons or ad hoc troubleshooting sessions, important issues either get glossed over or spiral into time-consuming digressions. We all end up stuck in this labyrinth of futile discussion, staggering out with meeting fatigue and information overload. Problem 5: Engagement At this point, people are emotionally checked out. The more vocal become inadvertent meeting hoggers, while others feel their contributions being sidelined. It's a fertile ground for a toxic culture that breeds disengagement and kills morale. How Asynchronous Standups (Sort Of) Help None of the scenarios we covered above captures the intended spirit of a stand-up meeting, which is to streamline the workflow and foster cohesion among team members. It's time to part ways with practices that suck the productivity out of our workday. So let’s consider asynchronous stand-ups. Traditional work schedules don't account for the natural ebb and flow of human energy, let alone the strain of managing personal lives alongside work commitments. Asynchronous stand-ups check a lot of boxes for the modern workforce. Where Asynchronous Stand-Ups Shine 1. Universal Participation: Time zones become irrelevant. Whether you're dialling in from Tokyo or Texas, you have an equal seat at the virtual table. 2. Your Pace, Your Place: These stand-ups play by your rules, allowing you to time your updates according to your work rhythm, not the other way around. 3. Efficiency: Bid farewell to meetings that drag on and interrupt your flow state. Asynchronous stand-ups are short and to the point. 4. Documented Progress: Think of it as an automatic diary of team updates. No need to chase minutes or compile reports; it's all there. 5. Quality Over Quantity: The chance to craft your update promotes clear and concise communication, rather than on-the-spot, often incoherent chatter. However, relying solely on asynchronous standups might not address all the complexities of collaboration effectively. In the current landscape, artificial intelligence stands prepared to integrate into your existing communication tools seamlessly. It can adeptly monitor and comprehend your projects and objectives, capturing the essence of decisions and activities that mould them. Unlike humans, who grapple with the inability to retain every detail and extract the pertinent elements, AI remains unhindered by these constraints. Our memory is finite, we lose sight of our goals, and overlook occurrences, all due to the limitations of time. AI, on the other hand, operates outside of these confines, positioning it as a far superior contender to succinctly summarise daily events or provide insights into ongoing matters. Getting Asynchronous Stand-Ups Right Asynchronous stand-ups work when everyone’s on the same page about how to do them at your organisation. Always ensure everyone understands what’s expected of them, and how to go about their asynchronous stand-up. Stay Consistent: Insist on a clear format that focuses on completed tasks, work in progress, and any roadblocks. Flag for Follow-up: Asynchronous doesn't mean antisocial. Urgent matters should be highlighted for immediate attention. A virtual pow-wow can still happen if needed. Time Frames Matter: Establish a window within which all updates and responses should be posted to maintain momentum. Clear Paths for Emergencies: Identify a procedure for raising and addressing urgent issues promptly. Making AI Alternatives Work Human memory has its limitations. We're bound to forget, overlook, or downright miss out on crucial updates. AI doesn't share these shortcomings. To make the most out of this tool, just stick to some collaboration fundamentals: Open Dialogue: Transparency is key. Holding the majority of discussions in private channels or direct messages is generally not advisable unless there's a specific reason like confidentiality concerns or data protection. Use Your Tools Effectively: Whether it's crafting well-structured Git commits, keeping your Jira boards current, or meticulously documenting workflows in Notion, encourage correct tool usage across the board. The beauty of AI is its ability to draw smart conclusions from the data it's given. By actively participating in an AI-enhanced asynchronous stand-up, your team stands to gain significantly. AI tools can highlight important activities and provide clear answers to any queries about ongoing projects.

By Alex Omeyer
The Scrum Trap
The Scrum Trap

Scrum is a purposefully incomplete framework. Consequently, it needs to be augmented with tools and practices to apply its theoretical foundation to an organization’s business reality: what problems shall be solved for whom in which market? Moreover, there is an organization’s culture to take into account. However, the intentional “gap” is not a free-for-all to accept whatever comes to mind or is convenient. Some tools and practices have proven highly effective in supporting Scrum’s application and reaping its benefits. And then there are others — the Scrum trap. Let’s look at what practices and tools for collaboration and team building are not helpful when used with Scrum. Collaboration Between Stakeholders or the Management and Scrum Teams In this category of the Scrum trap, we find numerous remnants of applying outdated industrial-age management practices: Applying best practices without inspection or adaptation: The Scrum principle of empiricism (transparency, inspection, adaptation) and the Agile Manifesto’s emphasis on responding to change over following a plan stress the importance of context-specific solutions; Mindlessly applying best practices from other organizations without considering their relevance to the current context will likely lead to ineffective processes. Upfront, long-term planning: This approach conflicts with the Agile principle of welcoming changing requirements, even late in development. Scrum promotes iterative and incremental development, allowing flexibility and adaptation in response to feedback and changing circumstances rather than rigid long-term planning. Scrum’s fast-feedback-loop approach to risk mitigation, for example, during the Daily Scrum or Sprint Review, avoids loss aversion or falling victim to the sunk cost fallacy. Empowering steering committees to override Product Owner decisions: This undermines the Product Owner’s role in maximizing the value of the work of their teammates. It can lead to a disconnect between the Scrum Team and the product vision, reducing the effectiveness of the Scrum framework in delivering value, starting with compromising the creation of the Product Goal. Outsourcing work to the lowest bidder: This can compromise the quality and consistency of the product, going against the Agile focus on continuous attention to technical excellence. Relying on outsiders to do the actual work can also disrupt the broader team dynamic within the product group and hinder the building of effective, self-organizing teams, a core aspect of Scrum. Keeping Scrum team members uninformed about the purpose and next steps: This practice undermines the Scrum value of openness and the Agile principle of building projects around motivated individuals. When team members are uninformed, they can’t make informed decisions or feel a sense of ownership, which is crucial for a self-organizing team. Just think of the Scrum principle that no one can tell developers how to turn a Product Backlog item into an Increment. Employing Agile Coaches at the organizational level while keeping Scrum Masters confined to tactical levels: This attitude can create a disconnect between strategy and execution, limiting the Scrum Master’s ability to foster an agile mindset. The Scrum Guide emphasizes the role of the Scrum Master in promoting and supporting Scrum as understood in the entire organization. Therefore, the separation of Scrum Master and Agile Coach within an organization is artificial and unfounded in principles. Focus on resource utilization: This anti-pattern contradicts the Agile Manifesto’s principle of valuing “individuals and interactions over processes and tools.” Overemphasizing resource utilization can lead to burnout and reduced creativity, as it often neglects the human aspect of the development process. Scrum fosters a sustainable pace of work, encouraging teams to focus on delivering value rather than merely being busy; it is about outcome, not output. Applying arbitrary deadlines to improve worker efficacy: This can lead to rushed and lower-quality work, contradicting the Agile focus on sustainable development, maintaining a constant pace indefinitely, and dedication to technical excellence. Arbitrary deadlines also undermine team morale and creativity, which are crucial for innovation and problem-solving in a Scrum environment. This section highlights critical anti-patterns in collaboration between stakeholders and Scrum Teams that are at odds with Scrum’s flexibility, empowerment, and innovation principles. The next stop is team building. Team Building: The Scrum Trap Let’s look at what practices and tools in collaboration and team building are not helpful when used with Scrum, leading you directly into the Scrum trap: Creating feature teams focused on output (à la Marty Cagan): This approach can shift focus from delivering value to merely completing tasks. The Scrum framework and Agile principles emphasize outcome over output, advocating for delivering products that provide real value to users rather than just completing features. In a complex environment, merely shipping more Product Backlog items per Sprint does not necessarily create more value. Distinguishing openly between regular employees and freelancers or temporary workers: This practice can create divisions within the team, undermining the Scrum values of respect and openness. Scrum thrives on cross-functional teams where all members are equally valued for their contributions. Such distinctions can hinder team creation, cohesion, and collective ownership. Moreover, it increases the probability that stakeholders are less interested in building relationships with freelancers, as the return on investment may be limited from their perspective. Empowering regular employees to decide on employing freelancers: This can lead to biases, a lack of diversity in perspectives, and less transparency. Scrum encourages collective decision-making and values diverse input to foster creativity and innovation. Decisions about team composition should be made collaboratively, reflecting the team’s needs and the product vision. Empowering regular employees creates a power differential within the team, where freelancers may become mercenaries, mainly interested in prolonged employment. Employing freelancers only with short-term contracts: This can disrupt team continuity and knowledge sharing, which are critical for a Scrum Team’s effectiveness. Short-term engagements may not allow enough time for freelancers to fully integrate into the team and contribute meaningfully, contradicting the Agile Manifesto’s emphasis on motivated individuals and team interaction. Moreover, it often is a stepping stone to create “Scrum Teams” focused on output due to a higher fluctuation rate among team members. Accepting line managers assigning new members to Scrum teams without consent: This undermines the principle of self-organization central to Scrum. Teams should have a say in their composition to ensure the right mix of skills and a strong sense of team unity. Moreover, when the management includes Scrum Teams in hiring, they will go the extra mile to make things work, as they have skin in the game. Accepting line managers instruct team members directly: This breaks the Scrum principle of self-management and can lead to micromanagement. It disrupts the empowerment of the Scrum team to make decisions, which is essential for its practices to be effective. Creating a functional hierarchy within the Scrum Team with “lead” roles: Scrum is remarkably egalitarian. Consequently, this approach goes against the flat structure advocated by Scrum, where all team members are considered equals, contributing to all aspects of value creation. Hierarchies can stifle creativity, hinder collaboration, and reduce transparency, essential elements of an effective Scrum Team. Creating a reporting hierarchy within Scrum teams: This can develop a sense of inequality and reduce open communication, reflecting the power differential, thus contradicting the Scrum values of courage and respect. Scrum promotes a collaborative environment where all team members share equal responsibility for the product’s success. Not investing in regular and comprehensive training of Scrum team members: This neglects the continuous improvement aspect of Scrum. Regular training ensures that team members stay updated with the latest practices and technologies, enhancing their ability to deliver high-quality products and embody the Agile principle of continuous attention to technical excellence and good design. It is a sound business decision, too, as there is no business agility with technical excellence. This Scrum trap segment explores anti-patterns in Scrum Team building, undermining Scrum’s values of equality, self-organization, and continuous improvement, negatively impacting team cohesion and overall effectiveness, thus lowering the return on investment from an organizational perspective. Food for Thought Consider the following questions to help your organization avoid the Scrum trap and embrace agility fully: How can organizations effectively balance the need for structure and the flexibility required by Scrum, especially in traditionally hierarchical or rigid corporate cultures? In what ways can Scrum teams navigate the challenges of integrating freelancers and temporary workers, ensuring they contribute effectively while maintaining team cohesion and continuity? How can Scrum Masters and Agile Coaches work together to bridge the gap between tactical team management and strategic organizational goals, particularly in large or complex organizations? Conclusion Augmenting Scrum is a challenging task. It requires careful selection of practices and tools, acknowledging and abandoning outdated management tactics, and emphasizing the importance of first principles of agility and team cohesion. Failing to do so will undermine Scrum’s core values and principles, ultimately impeding its effectiveness in delivering value and fostering innovation—an unsound business decision.

By Stefan Wolpers DZone Core CORE
Demystifying Event Storming: A Comprehensive Guide to Understanding Complex Systems (Part 1)
Demystifying Event Storming: A Comprehensive Guide to Understanding Complex Systems (Part 1)

Event Storming, a dynamic and collaborative modeling technique, emerges as a guiding light in the fog of complexity. It’s not just a method; it’s a voyage of discovery, a shared language, and a bridge between stakeholders, software developers, and business experts. Picture a journey that takes you deep into the heart of your organization’s inner workings, unveiling the complex details of how things operate and replacing confusion with clear understanding. Event Storming promises precisely that and more. This method has left a significant impact in areas like software development, domain-driven design, and more. But what is Event Storming, and why is it gaining momentum in various industries? How can it be harnessed to gain a profound understanding of complex systems and domains? This comprehensive guide seeks to demystify Event Storming, bringing it into the spotlight and equipping you with the knowledge to navigate this powerful tool. To continue, I’ll talk about the concept of Event Storming, exploring its origins, key principles, and practical applications. You’ll discover how it differs from traditional big design up-front methods. Event Storming isn’t exclusive to software developers; it’s a technique that brings together individuals from various domains, creating a shared language and a platform for understanding even the most intricate systems. Whether you’re a seasoned software architect, a business analyst, or a curious explorer, this guide is designed to equip you with the tools to embark on an Event Storming journey. Prepare to immerse yourself in a world of colorful sticky notes, dynamic discussions, and enlightening revelations. Let’s demystify Event Storming and start a voyage to uncover the secrets of complex systems, one event at a time. Big Design Up Front Big Design Up Front (BDUF), also known as Waterfall or Traditional Software Development, is an approach to software development where a comprehensive and detailed design of the entire system is created before any coding or implementation takes place. It’s a method that was commonly used in the early days of software development. But, In today’s fast-paced business environment, user needs and project requirements can change frequently. BDUF assumes that all requirements can be known and defined upfront, which is often not the case. As a result, projects following BDUF can struggle to adapt to changing requirements. Also, BDUF creates a rigid plan that can be challenging to change once the project is in progress. Any deviations from the initial design can lead to costly rework, project delays, and increased complexity. Finally, BDUF has become less popular in favor of more agile and iterative development methodologies. Modern approaches, like Agile and Scrum, prioritize adaptability, customer feedback, and delivering working software in smaller, more manageable increments. These methods align better with the dynamic and evolving nature of software development in the 21st century. Incremental design is the best alternative to BDUF. Next, I’ll detail how it fixes almost all of the issues of BDUF. Domain Imagine you have a business much like the famous Roadsurfers. They had these cool campervans, perfect for going on adventures. But what made them really special was how you could pick up and drop off these campervans at different places. Think of it like magical gateways: Munich, Paris, Porto, and Madrid. And the best part? You could return the campervan to any of these places. But the adventure didn’t stop there. They had all sorts of extra stuff you could take with you. You know, things like portable toilets, comfy bed sheets, warm sleeping bags, and even camping tables and chairs. It was like a treasure chest of goodies for travelers. You could choose whatever you wanted to make your journey comfy and fun. Now, here’s the fun part. You could book any of these goodies in addition to your campervan. So, if you needed a cozy set of bed sheets for a good night’s sleep, you got it. The catch was that there were only a certain number of these goodies at each place. When someone drove off with some equipment, the stock went down. But when they returned, it went back up. Lastly, there were these things called rental orders. When someone wanted to go on an adventure, they made a rental order. It was like a checklist. First, they picked their campervan. Then they said where they were starting and ending their adventure. They also told us when they were setting off and when they’d be back. And to make things just right, they picked what extra stuff they wanted to take. For example, someone might say, “I’ll take one set of bed sheets, please.” Event Storming Event Storming is a powerful and collaborative workshop-based technique used to gain a deep understanding of complex systems, processes, and domains. It was introduced by Alberto Brandolini, an expert in domain-driven design and Agile software development. Event Storming stands out as a versatile and practical approach that brings together stakeholders, domain experts, software developers, and business analysts to unravel the intricacies of a system. At its core, Event Storming is a visual modeling method that uses sticky notes and a large workspace, such as a wall or whiteboard, to represent various events and interactions within a system. These events can range from user actions, system processes, and domain events to business rules and policies. The workshop participants collaboratively contribute to this visual representation, creating a shared understanding of the system’s behavior and business processes. Big Picture Event Storming starts with a domain description, then Big Picture. Big Picture Event Storming is the first step in understanding complex systems. It’s like creating a big, simple map of the whole system to see how everything fits together. Imagine a big wall covered in sticky notes that show the main things happening in the system and who is involved. First of all, decide on the boundaries of the business domain you’re gonna discover. On a big-picture event storming, you may tackle the whole business or narrow down your focus to specific subdomains. Understanding the scale will help you to define the invitee list. The key to a successful event-storming session lies in the participants and their knowledge. For a successful event-storming session, it’s essential to bring together individuals with the appropriate knowledge and roles. This includes those who ask questions, such as solution architects, software engineers, and DevOps specialists, as well as those who provide answers, like decision makers, business owners, and domain experts. The ideal number of participants might vary depending on your specific business needs, but I’ve found that having 8–10 participants is usually the best balance. It’s advisable to diversify the group by their areas of knowledge and expertise. This way, the group collectively holds a deep understanding of the business domain you aim to explore. Before we begin, a quick reminder: Let’s all remember that our primary goal at this stage is to explore the domain model and understand the big picture. Not in technical terms, but focus on what we will achieve here for organization. Now, make sure you have the required materials ready. You’ll need a room with a wall that spans at least 8–10 meters in length, and larger is even better. Additionally, you’ll want a roll of paper that matches this length, measuring around 70–100 cm in height, and a good supply of sticky notes. An affordable white plotter paper roll is an excellent choice for this purpose. Simply unroll the paper onto the wall, and that’s where the sticky notes will go. All participants should have a marker, and each sticky note should be used to write a single concept in capital letters. Even more important is the need to strictly adhere to the timeline. It’s important that it’s explicitly clear what occurs before and after each event. Domain Event Domain Event represents a significant occurrence or incident within a specific domain. It captures an event that holds relevance to the domain’s operations, often reflecting a change in the system’s state or a notable action. Domain Events help in mapping out the dynamics and behaviors of your domain. These events serve as building blocks for understanding and modeling complex processes, interactions, and business logic. To lower the entry threshold for participants, the facilitator usually makes the first step by sticking to pivotal events, which emphasize the major happenings in the business from end to end. Domain Events must be written in past tense. Now, let’s see our first library Domain Event: Now, the participants can start filling the gaps around the pivotals. It is the most important part of the whole storming, where the common goal is to share maximum domain knowledge from each participant. Encourage an atmosphere of creativity and knowledge sharing during the initial phase. Let the domain experts write down events and place them on the wall without immediate validation. Even if the events are expressed in lengthy sentences, not yet in the past tense, or if there are duplicates, refrain from interrupting the flow of knowledge exchange and allow people to brainstorm freely. If you observe participants forming discussion circles, step in to provide support by addressing questions and resolving any challenges. Maintain a highly interactive process, ensuring that everyone remains actively involved for at least 20–30 minutes. It’s important to stress that the events should be arranged chronologically from left to right, even if it’s only partially enforced during the initial phase. This practice contributes to establishing a more coherent and time-ordered event flow. A Hot spot is a pain point or bottleneck that needs further clarification later on. In fact, When you face uncertainties or ambiguities without immediate solutions, it’s entirely acceptable to delay those decisions for later consideration. You can visually depict them on the wall using a distinct purple sticky note. This method helps you track and address these unresolved matters effectively. After approximately 30 minutes, depending on the domain’s complexity, you may notice the activity slowing down. People might start gazing at the wall or engaging in discussions that don’t result in tangible outcomes on the wall. This serves as an indicator to conclude the first phase and transition to the next stage: the walkthrough. Currently, most of the domain knowledge has been visualized on the wall. It’s now the moment to clean up, order, and structure it. This is achieved by walking through the wall from left to right, reading aloud the narrative represented on the sticky notes, and engaging in discussions with the authors or knowledge holders to seek clarification and pose questions. Many of the descriptions may not adhere to the ideal domain event guidelines, which suggest they should be concise statements in the past tense. Additionally, some of them duplicate in meaning or are arranged out of sequence, and a few are grammatically incorrect. Our next step is to traverse the wall and rectify these issues. In the above example, the Campervan Checked Out and the Campervan Handed Over are the same; Both events mark the moment when a customer takes possession of the campervan at the rental station. Customer Pick-Up for a domain event may lack specificity. It’s not clear where or when the customer picked up the campervan. Was it in Munich, Paris, Porto, Madrid, or any other location? Clarification is needed to pinpoint the exact details of the pick-up event. An Equipment Availability domain event could be unclear in terms of what equipment is available and at which station. It doesn’t specify the type of equipment or the quantity. For instance, if a customer wants to rent camping tables and chairs, there should be a clear event that indicates the availability of these specific items at a particular station. Following the cleanup phase, we should encourage the experts to take a closer look at the sticky notes and validate the sequence of events. If anything is missed or should be changed here? Well, there is no need to be an expert to see missing events. And the Product Owner could correct you. Ubiquitous Language In the context of your campervan rental domain, the Ubiquitous Language plays a vital role in facilitating effective communication and mutual understanding among all stakeholders. It serves as a common vocabulary that unifies different perspectives and ensures that everyone involved in the domain shares the same terminology and meanings. The Ubiquitous Language clarifies potentially ambiguous terms like “Station,” defining them with precision. For example, it distinguishes between a “Station” as a physical location for campervan pickups and returns and a “Station” as a comprehensive operational unit that includes not only the physical location but also the storage of portable equipment and associated services. By cultivating this shared language, event-storming sessions can bridge gaps in understanding, promote smoother discussions, and enhance the overall efficiency of your campervan rental business. For now, let’s clarify the meaning of Station with a Definition artifact that is written down on a big white sticky note. Conclusion Event Storming is a powerful tool for understanding complex systems and domains. It’s more than just a modeling technique; it’s a collaborative journey that brings stakeholders from various domains together to create a shared language. In a world where software development and business requirements are constantly evolving, techniques like Big Design Up Front are becoming obsolete, making way for more agile and adaptable methods. This is just the beginning. The journey into Event Storming is a multi-part exploration, and the next part is on the horizon. In the upcoming installment, we will delve deeper into Event Storming’s core concepts, practical applications, and its role in domain-driven design. So stay tuned for more insights into unlocking the power of Event Storming in Part 2. Get ready for a voyage of colorful sticky notes, dynamic discussions, and enlightening revelations as you explore the world of Event Storming.

By Alireza Rahmani Khalili DZone Core CORE
A Guide To Growing Your Technical Knowledge Portfolio
A Guide To Growing Your Technical Knowledge Portfolio

“An investment in knowledge always pays the best interest." — Benjamin Franklin The wise words of Benjamin Franklin, the trailblazer of financial and intellectual wisdom. As a leader, I'm frequently asked this question: How do you stay tech-savvy with a jam-packed schedule? Allow me to share insights and suggestions drawn from my experience and expertise. Your knowledge is like that fancy cheese in your fridge. It's great, it's valuable, but it has an expiration date. Just like your cheese gets all moldy and inedible, your knowledge can become outdated faster than the latest viral internet challenge. In today's tech-driven world, things change faster than you can say "Java." So, what's a tech-savvy pro like you to do? Well, you've got to manage your "knowledge portfolio." Think of it like your stock market investments, but instead of stocks, it's all the cool stuff you know about programming and tech. Invest Regularly Just like you put money into your savings account every month, invest in your brain regularly. Learn new stuff, even if it's just a smidge at a time. Make it a habit, like brushing your teeth (but way more exciting). Diversify Don't put all your eggs in one basket. You need to know more than just one trick. It's like being a master chef who can whip up a killer lasagna and make sushi that's to die for. The more you know, the more valuable you become. Manage Risk Tech is a bit like the Wild West. Some things are safe bets. Others are like wild stallions you're trying to tame. Don't go all in on risky stuff, but don't play it too safe either. Balance is key. Buy Low, Sell High Have you ever heard of investing in Bitcoin when it was just a digital blip on the radar? Learning a new, unheard-of technology can be just like that. Risky at first, but the payoff? Oh, it can be sweet. Review and Rebalance Remember that awesome app you were excited about last month? Well, it might be as cool as a flip phone now. Your knowledge needs a spring cleaning, too. Don't let it gather dust. Now, for the fun part — setting goals! Learning new languages, reading tech books, and attending courses or meetups. It's like collecting shiny Pokémon. You gotta catch 'em all, or in your case, learn 'em all. And don't forget the non-technical stuff. Computers are just tools, and they're used by real people. You work with them, for them, and occasionally get pranked by them. So, get some "soft skills" under your belt. They're as valuable as knowing your Java from your JavaScript. Example goals could be: Learn at least one new language every year Read a technical book each month. With easy access to audiobooks and podcasts on our mobile, this should be reasonable to achieve. Participate in local user groups and meetups once a fortnight Lastly, think critically. Just because someone's yelling, "This is the best thing ever!" doesn't mean it's your best thing ever. Ask questions like a curious four-year-old. Dive deep and find out who benefits from all this tech hype. So, my dear tech-savvy friend, keep your knowledge portfolio as diverse as a buffet, manage it like a financial genius, and stay curious like a kid in a candy store. Your brain is your best investment, and it's time to make it rich in knowledge!

By Roopa Kushtagi
Project Oxygen: Breathing New Life into Teams and Organizations
Project Oxygen: Breathing New Life into Teams and Organizations

In today's fast-paced, ever-evolving business landscape, organizations are constantly on the lookout for ways to improve productivity, enhance team dynamics, and boost overall performance. Google, a company renowned for its innovative approach to workplace culture, embarked on a mission to identify the key factors that contribute to effective team management. The result of this endeavor is Project Oxygen, an in-depth research initiative that has transformed the way teams and organizations operate. In this article, we will delve into the origins of Project Oxygen, explore its core findings, and discuss how it can be applied to benefit teams and organizations. Project Oxygen: A Breath of Fresh Air Launched in 2008, Project Oxygen was born out of Google's desire to understand what makes a great manager. The company analyzed data from more than 10,000 observations, including performance reviews, feedback surveys, and nominations for top-manager awards. Through this extensive research, Google identified eight key behaviors that characterized its most effective managers. These behaviors, which have since been refined into ten, serve as the foundation for Project Oxygen and have been widely adopted by organizations around the world. The Ten Pillars of Effective Management Be a Good Coach: Great managers prioritize coaching and mentoring their team members, providing constructive feedback and guidance to help them grow and improve. Empower the Team and Avoid Micromanaging: Effective managers trust their team members and give them autonomy to make decisions, fostering a sense of ownership and accountability. Create an Inclusive Team Environment: Successful managers promote a culture of collaboration, ensuring that every team member feels valued, heard, and included. Be Results-Oriented: High-performing managers set clear expectations and goals, then work with their teams to achieve those objectives. Be a Good Communicator: Strong managers communicate openly and honestly with their team members, providing regular updates on progress and addressing any concerns or challenges. Support Career Development and Discuss Performance: Effective managers take an active interest in their team members' professional growth, offering guidance and support to help them reach their career goals. Have a Clear Vision and Strategy for the Team: Great managers establish a clear direction for their teams, aligning individual and team objectives with the broader organizational goals. Possess Strong Technical Skills: While not always necessary, having a solid understanding of the technical aspects of a team's work can help managers make more informed decisions and better support their team members. Collaborate Across the Organization: Successful managers work closely with other departments and stakeholders, fostering a culture of cooperation and collaboration. Be a Strong Decision-Maker: Effective managers are decisive and confident in their decision-making, even when faced with uncertainty or ambiguity. Breathing Life into Teams and Organizations By implementing the principles of Project Oxygen, organizations can experience a range of benefits, including increased employee engagement, improved team dynamics, and enhanced overall performance. Here are some ways to incorporate these findings into your organization: Train managers in effective coaching and mentorship techniques, helping them develop the skills needed to support their team members' growth. Encourage open communication and collaboration within teams, promoting a culture of trust and inclusivity. Set clear expectations and goals for each team, ensuring that they align with the organization's broader objectives. Provide opportunities for professional development and growth, such as training programs, workshops, or mentorship initiatives. Foster cross-departmental collaboration by facilitating regular meetings, joint projects, or social events. Conclusion Project Oxygen has provided invaluable insights into the qualities that define effective management, offering a blueprint for organizations seeking to optimize team performance and drive success. By embracing these principles and incorporating them into your company culture, you can breathe new life into your teams and create a thriving, high-performing organization.

By Arun Pandey
The Illusion of Velocity
The Illusion of Velocity

In this article, I explore the pitfalls of ‘The Illusion of Velocity’ in Agile contexts, peeling back the layers of traditional metrics as leadership tools. Moreover, I point to the advantages gained from leadership engaging directly with teams. Understand why servant leadership and practices like the Gemba Walks are crucial for coping with complex, adaptive environments toward actual progress. Moreover, get an idea of how to start flipping outdated hierarchies and embrace the natural rhythm of productivity and innovation. The Clash of Paradigms In the traditional management paradigm, born from Frederick W. Taylor’s scientific management, the goal was efficiency through standardization, predictability, and control. Management sought to deconstruct work into repeatable tasks optimized through measurement and refinement. Workers were seen as cogs in the machinery of production, with little autonomy or need for understanding the broader context of their work. Contrastingly, Agile practices, born from the need to accomplish work in uncertain and complex environments, emphasize adaptability and responsiveness. The core of “Agile” is that the best products and solutions to customer problems emerge from self-organizing, cross-functional teams. These teams are given autonomy and are expected to collaborate with stakeholders frequently to reassess and realign their work according to changing needs. Instead of detailed long-term planning, Agile focuses on short, iterative work cycles, allowing for continuous feedback and adjustment. From the Illusion of Velocity to the General Misfit of Command and Control In complex environments where knowledge work prevails, classic management practices rooted in predictability and control fall short for several reasons: Overreliance on predictability: Traditional approaches hinge on the assumption that work is predictable and stable, which allows for detailed long-term planning and certainty in output. However, complex environments are characterized by their unpredictability and the frequent emergence of unforeseen challenges. Insisting on precise estimates in such scenarios leads to unrealistic commitments and, often, failure to deliver value, impeding the building of trust between teams and their stakeholders. Misplaced Focus on output over outcome: Classical management prioritizes output — the amount of work done — over the outcome, the actual value delivered. This focus often leads to a misguided effort to increase the velocity or speed of delivery without considering whether the work is effective or even necessary. In complex environments, the focus needs to shift to learning what works quickly and adapting based on feedback rather than just doing more of the same faster. Individual performance over team collaboration: The traditional model often emphasizes personal achievement, which can undermine the collaborative effort needed in complex problem-solving. Complex environments require diverse skills and perspectives, and rewarding individuals over teams can discourage the collaborative culture necessary for business agility. Linear thinking in a non-linear context: Classic management approaches apply linear thinking to problem-solving, assuming that A leads to B in a predictable fashion. Complex environments, on the other hand, are non-linear and dynamic, meaning that the same action won’t always produce the same outcome. This unpredictability necessitates a more empirical approach, adaptable and responsive to change, rather than one that follows a fixed plan. Control vs. empowerment: In traditional settings, managers control who directs work and makes decisions. In complex environments, this approach can stifle creativity and responsiveness. Empowering teams to make decisions enables a more rapid and appropriate response to change, as those closest to the work best understand the nuances and can innovate effectively. Inflexible structures hinder adaptability: Traditional management often has rigid hierarchies and processes designed for stability. These structures can make it difficult to adapt when change is needed, leading to slow responses to market shifts, customer needs, and technological advancements. Agile environments demand a more fluid structure where change can be incorporated quickly and seamlessly. Misunderstanding complexity: Perhaps the most significant failure is the misunderstanding of the nature of complexity itself. Managers cannot manage complexity through simplification or traditional optimization techniques, such as pattern recognition. Instead, managing complexity requires embracing uncertainty, fostering an environment of experimentation and learning, and valuing adaptability over efficiency. These classic practices, while effective in stable and predictable settings, prove inadequate in the face of the complexity inherent in modern knowledge work. Agile practices address these shortcomings by recognizing the need for adaptability, valuing individuals and interactions, customer collaboration, and responding to change over following a plan, as articulated in the Agile Manifesto. Learn more with the following sources: McChrystal, S., Collins, T., Silverman, D., & Fussell, C. (2015): Team of Teams: New Rules of Engagement for a Complex World. Snowden, D. J., & Boone, M. E. (2007): A Leader’s Framework for Decision Making. Harvard Business Review. Beyond the Illusion of Velocity: Agile Metrics for Insight and Adaptation Traditional management metrics, while offering the illusion of control, often fail to provide the insight necessary for dealing with complex, knowledge-based tasks. Agile practices, however, promote metrics that provide meaningful insights into the team’s effectiveness and product value delivery, like burn-up charts for tracking progress, cycle times for understanding workflow efficiency, and team Retrospectives for continuous improvement. These tools are not just about measurement but about fostering an environment where the information leads to actionable insights. In practice, traditional metrics like velocity, often used to extrapolate future performance with tools like Excel, are less effective in environments filled with complexity and unpredictability. These classic metrics are derived from a desire for predictability and control, a relict from management practices of the industrial age. However, they regularly fail to provide the necessary insights for truly adaptive and responsive practices, which prove to be suited to deliver progress in complex environments: Velocity Obscures True Progress: Velocity is typically a measure of the quantity of work delivered, often quantified in story points. It’s a unidimensional metric that doesn’t account for the value delivered or the qualitative improvements in the product. In complex environments, providing features quickly doesn’t necessarily translate to delivering the right features or doing so suitably. The Fallacy of Extrapolation: Using velocity to predict future performance assumes a stable environment and tasks of uniform difficulty, which is never the case in complex projects. Extrapolating story points with tools like Excel may create an illusion of precision, but it fails to accommodate the inherent uncertainty and variability in creative and knowledge work. Flow Metrics Offer a Clearer Picture: Flow metrics, on the other hand, are designed to provide a more granular and real-time view of the work process. These include: Lead Time: The time it takes for a work item to move from initiation to completion. It’s a direct measure of efficiency in the workflow. Cycle Time: The time a task spends in the actual development process, which can highlight process inefficiencies or blockers. Throughput: The number of work items finished in a specific time frame, indicating the actual work rate of the team. Work in Progress (WIP) Limits: A way to manage flow by limiting the number of tasks being worked on at any given time, promoting focus, and reducing context-switching. Flow Efficiency: The ratio of work time to lead time, indicating the amount of idle time in the process. These flow metrics are not just about measuring; they are about understanding and improving the workflow. They help identify bottlenecks and waste, enabling teams to adapt their processes to become more efficient and responsive to change. By focusing on flow metrics, teams can shift their attention from the output (velocity) to the outcomes (value delivery and quality). They can better manage workloads, prioritize tasks more effectively, and create a sustainable pace of work that maximizes value delivery without overburdening the team. Switching to flow metrics requires a mindset shift from output to outcome, from task completion to value realization. This shift allows management to understand the team’s effective capabilities, adjust expectations, and ultimately align business goals with Agile practices for a more responsive and resilient organization. Leadership Proximity and Decision Making In the realm of Agile practices, traditional hierarchical structures and decision-making processes often inhibit the flexibility and responsiveness essential in complex, unpredictable environments. In contrast, a model where leadership immerses itself in the operational context of teams—where the leaders come to the work rather than the work being reported up the chain—is critical for success: Gemba walks: This practice, derived from Lean management, involves leaders going directly to where work is done (“the real place” in Japanese). By observing the work process in its natural setting, leaders gain firsthand insights into the workflow, challenges, and opportunities for improvement. Servant leadership: Agile environments benefit from leaders who serve their teams rather than command them. These servant leaders offer support by removing impediments, from processes to tools to training opportunities, facilitating growth, and promoting a culture of empowerment. Flattening the hierarchy: In complex contexts, decision-making needs to be rapid and informed by real-time information. Flattening the hierarchy doesn’t mean eliminating leadership but redefining it to be more about mentorship and support rather than command and control. Bringing leadership to the information: This approach encourages leaders to become intimately familiar with the projects. Instead of waiting for filtered reports, leaders engage directly with the work environment, leading to more informed decisions and a stronger connection with their teams. (The Sprint Review in Scrum is a good example of the practice.) Contextual decision-making: When leaders are close to the work, they can provide the necessary context for their teams. They help connect the day-to-day activities with the broader organizational goals, ensuring the teams can align their work with strategic objectives. The big picture: By engaging with teams on the ground, leaders can help workers see beyond their immediate tasks, understanding how their work fits into the larger scheme of things. This approach enhances motivation and can improve overall performance and satisfaction. This transition from “bringing information to leadership” to “bringing leadership to the information” signifies a profound change in the culture of an organization. It embodies a commitment to agility and responsiveness, fostering an environment where knowledge flows freely, decisions are made swiftly and accurately, and the organization as a whole is more adaptable to the complexities and uncertainties inherent in today’s business landscape. Food for Thought Consider the following questions to help your organization move beyond the illusion of velocity and embrace agility fully: In what ways might the fixation on velocity metrics detract from more qualitative aspects of team dynamics, such as innovation and creative problem-solving? How can organizations balance the need for some form of measurement with the recognition that not all valuable outcomes are quantifiable? Considering the principles behind the Gemba Walk, what cultural shifts must occur in traditionally managed organizations to adopt this practice effectively? Conclusion For organizations mired in traditional measurement paradigms, the path to agility involves a fundamental mindset shift. It requires valuing learning and responsiveness over predictability, embracing cross-functional collaboration over siloed departments, and recognizing that actual effectiveness in knowledge work comes from the ability to adapt rather than from the repetition of optimized tasks. Leaders must cultivate an environment that empowers teams, values empirical evidence over speculation, and promotes a culture of experimentation. Ultimately, they need to quit the illusion of velocity.

By Stefan Wolpers DZone Core CORE

The Latest Culture and Methodologies Topics

article thumbnail
From Sprout to Sequoia: Orchestrating the Symphony of IoT Growth and Cloud Scalability
The IoT's evolution, from sprout to sequoia, is orchestrated by scalable cloud growth, fostering resilience, connectivity, and integration with AI.
November 29, 2023
by Animesh Patel
· 564 Views · 1 Like
article thumbnail
Platform Engineering for CTOs and Executives
Dive into Platform Engineering tailored for CTOs and executives. Discover the approaches to build a scalable, resilient, and efficient developer-focussed platform.
November 29, 2023
by Anjul Sahu
· 714 Views · 1 Like
article thumbnail
Unleashing Greatness: Alexander the Great's Journey With Generative AI
How can Generative AI (GAI) be used to enhance coaching effectiveness, and what are the potential limitations of using Generative AI (GAI) as a coaching tool?
November 28, 2023
by CHANDAN LAL PATARY
· 1,084 Views · 2 Likes
article thumbnail
5 Steps To Tame Unplanned Work
Stuff happens, even if it shouldn't. Just because it happens randomly does not mean your response should be. Five simple steps can bring a lot of order.
November 27, 2023
by Allan Kelly DZone Core CORE
· 1,736 Views · 3 Likes
article thumbnail
The Scrum Trap
In this article, take a look at what practices and tools for collaboration and team building are not helpful when used with Scrum.
November 27, 2023
by Stefan Wolpers DZone Core CORE
· 1,241 Views · 3 Likes
article thumbnail
A Step-by-Step Guide: How to Convert Tables to Graph
Graph Data Modelling How-to convert table into graph
November 27, 2023
by Ricky Sun
· 221 Views · 1 Like
article thumbnail
You’re Wasting Time With Your Daily Standup
Daily standups cost average-sized product engineering teams 6-figure sums every year, so we sure as heck need to make them count. Here's how I think we do it.
November 27, 2023
by Alex Omeyer
· 1,316 Views · 3 Likes
article thumbnail
Agile Testing: Blending Shift-Left, Automation, and Collaborative Testing Strategies
This article explores Agile testing, including shift-left testing, test automation, and collaboration between developers and QA.
November 24, 2023
by Nishant Sharma
· 2,282 Views · 3 Likes
article thumbnail
Should I Start My Job Search Now?
It’s never a bad time to look around the airplane and check where the exits are located, where the parachutes are stored, and other things I learned about the job search.
November 24, 2023
by Leon Adato
· 1,912 Views · 3 Likes
article thumbnail
Embracing Efficiency and Continuous Improvement: The Power of Lean Methodology
Learn how lean methodology can boost organizational effectiveness and drive success sustainably.
November 24, 2023
by Aditya Bhuyan
· 2,053 Views · 2 Likes
article thumbnail
The Importance of a Support User Interface
Elevate customer support and streamline operations with a well-crafted Support User Interface, a vital asset for scaling software products.
November 23, 2023
by John Conneely
· 1,675 Views · 2 Likes
article thumbnail
Top 10 Software Development Trends for 2024
This blog post will discuss the most noteworthy software development trends that are likely to emerge as superpowers within this new year.
November 23, 2023
by Fawad Malik
· 1,562 Views · 2 Likes
article thumbnail
Application Production Readiness Guide
Deploying an application in production is not the end state but a very crucial stage of the software development lifecycle.
November 23, 2023
by Pranav Kumar Chaudhary
· 1,242 Views · 2 Likes
article thumbnail
Writing An Efficient Software Design Document
In this article, I’ll be talking about a typical process that I follow to thoroughly understand a problem and successfully deliver a solution.
November 22, 2023
by Pranav Kumar Chaudhary
· 1,923 Views · 3 Likes
article thumbnail
Setting Sail for Success: A Comprehensive Guide to Productive Large-Team Retrospectives
Navigating the complexities of overseeing the development of a large and intricate solution platform as a Solution Train Engineer.
November 22, 2023
by CHANDAN LAL PATARY
· 1,116 Views · 2 Likes
article thumbnail
CodeCraft: Agile Strategies for Crafting Exemplary Software
In this article, we'll explore how Agile strategies align with the creative spirit of developers, turning the process of coding into a journey of craftsmanship.
November 22, 2023
by Parul Batra
· 1,773 Views · 7 Likes
article thumbnail
Connecting With the Community at BSides Atlanta 2023
Dive into BSides Atlanta 2023, the largest free security event in the South! Explore insights from top security professionals on Web 3.0, cloud vulnerabilities, and more.
November 22, 2023
by Dwayne McDaniel
· 1,265 Views · 2 Likes
article thumbnail
How To Plan Product Prioritization From Users Perspective
Using the structured framework, product prioritization can effectively meet the needs of customers and address their pain points.
November 22, 2023
by Abhishek Agarwal
· 1,176 Views · 2 Likes
article thumbnail
Lessons From a Six-Month Job Search
This article presents a reflection on my job search and the state of the job market. With some lessons I’ve picked up along the way.
November 21, 2023
by Leon Adato
· 1,140 Views · 2 Likes
article thumbnail
Be a Better Team Player
Many API developers are familiar with Postman. Though I use it extensively for solo dev work, we know what Postman brings to the table for team API development.
November 21, 2023
by Alvin Lee DZone Core CORE
· 2,097 Views · 3 Likes
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • ...
  • Next

ABOUT US

  • About DZone
  • Send feedback
  • Careers
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • Become a Contributor
  • Core Program
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 3343 Perimeter Hill Drive
  • Suite 100
  • Nashville, TN 37211
  • support@dzone.com

Let's be friends: