Agile

Maybe this sounds familiar to you: joining a new software engineering company or moving from your current team to a different team and being asked to keep evolving an existing product. You realized that this solution is using an uncommon architectural pattern in your organization. Let’s say it is applying event sourcing for persisting the state of the domain aggregates. If you like event sourcing; but do not like it for the specific nature of the product, most likely, it wouldn’t have been your first choice. As a software architect, you start to find the rationale behind that solution, find documentation with no success, and ask the software engineers that do not have the answer you were looking for. This situation might have a relevant negative impact. Software architectural decisions are key and drive the overall design of the solution, impacting maintainability, performance, security, and many other “-alities.” There is no perfect software architecture decision designing architectures is all about trade-offs, understanding their implications, sharing their impacts with the stakeholders, and having mitigations to live with them. Therefore, having a well-established process for tracking those kinds of decisions is key for the success and proper evolution of a complex software product, even more, if that product is created in a highly regulated environment. However, today’s software is designed and developed following agile practices, and frameworks, like SAFe, try to scale for large solutions and large organizations. It is key to maintain a good balance between the decision-making process and agility, ensuring the former does not become an impediment to the latter. Architecture Decision Records (ADRs) My organization uses Architecture Decision Records (ADRs) to register and track architectural decisions. ADRs is a well-known tool with many different writing styles and templates like MADR. Now the question is how to ensure the ADRs are in place and with the right level of governance. As we will see below, ARDs are written in markdown and managed in a git repository, where everybody can contribute, and a consensus shall be reached to accept them and move forward with the architecture decision. For that, we have created the following process: First Swimlane In this process, the first swimlane includes team interactions that triggers architecture concerns, requiring a supportive architecture decision. Those concerns will come mainly from: Product definition and refinement: At any level (e.g., epic, capability, feature, stories), architecture concerns are identified. Those concerns shall be captured by the corresponding software architect. Feedback from agile teams: Architecture decision-sharing sessions and inspect and adapt sessions (e.g., system demos, iteration reviews, and retrospectives) are moments where architecture concerns can be identified. It is key to understand if agile teams are facing problems with the architecture decisions made so far; if the teams do not believe in the architecture, it will not be materialized. Second Swimlane The second swimlane involves mainly the architecture team and optionally technical leads from agile teams. This team will meet regularly in an architecture sync meeting where the following steps will be taken: Step 1 Architecture backlog management: Concerns are registered in the architecture backlog as enablers, prioritized, assigned. The first task associated with enablers is creating the Architecture Decision Record. Step 2 Gather inputs and perform the analysis: The architect assigned to work on the ADR will gather additional inputs from the stakeholders, colleagues, and agile team members, working on spikes with the team to go deeper into the analysis when needed. During this state, the architect will collaborate closely with the agile teams to perform the required analysis and alternatives evaluation of several backlog enablers and spikes that might be needed. Step 3 Work on the ADR: The outcome of the previous state is used to write the ADR, condensing the decisions to be taken, the context around the decision, alternatives assessed, final decisions, and consequences, both positive and tradeoffs. The ADR is created in the source control system. In our case, using GitHub because it has a main branch for accepted ADRs and a feature branch for the ongoing ADR. Step 4 Publish ADR: Once the ADR is ready for decision, a pull request is created, assigning a reviewer all the relevant stakeholders. Revision is not limited to architects but is open to a wider audience, like software engineers from agile teams, product owners, product managers, etc. Third Swimlane The third swimlane goal is agreeing on the decision under discussion. In this context, the ADR is reviewed by the architecture team during their regular meetings (e.g., architecture alignment/architecture board). Ideally, the solution shall be reached by consensus, but if an agreement isn't reached in the expected timelines, the designated software architect (depending on the decision level, it can be an enterprise architect, solution architect, or system architect) will make the final decision. Step 5 Review ADR on Architecture alignment: The ADR owner provides a brief presentation of the ADR to their mates that will provide feedback until the next alignment. Step 6 Collect and review comments: ADR reviewers add comments to the pull request, providing feedback to the ADR owner that replies to the comments and applies the corresponding adjustments. This approach ensures all the concerns during the ADR definition are tracked and available for review at any time in the future by simply accessing the ADR’s pull request. Step 7 The designated Software Architect makes the final decision: This state is only needed if, for any reason, there is no agreement between architects and engineers. At some point in time, there should be accountability in the decision, and this accountability resides in the corresponding Software Architect. Ideally, this state will not be needed, but it is also true that a decision cannot be delayed forever. Step 8 Involve stakehoders: It will be bad news if you reach this state, which is there as a safeguard in case the decision taken by the architect is clearly wrong. Stakeholders are involved in the decision process to reevaluate the ADR and reach final agreement. Step 9 Sign ADR: Once the ADR is accepted by the majority of reviewers, it is merged to main. From this point, the ADR becomes official, and the corresponding decision shall be realized by the engineering teams, leveraging analysis and spikes performed in step 2. ADRs are now immutable. Step 10 Superseded former decision: If the new decision replaces a previously accepted ADR, it can be modified to change its status to “Superseded,” indicating by which ADR it is replaced. Conclusion This process might look a bit cumbersome, but it should not take more than a few days to decide once the analysis phase (step 2) is completed. The pros of such a process outweigh the cons by having a clear architecture decision history, easy to track from well know tools (e.g., GitHub, GitLab), and providing the highest value for a long-lasting solution. Also, it is important to note that this is a collaborative process that should help balance intentional architecture with an emergent design by the involvement of agile team members in the architecture concerns identification, decision analysis phase, and feedback sharing. I hope this can help you improve how architecture decisions are made and evolve. I am happy to hear from you in the comments!

The Daily Scrum serves a single purpose: inspecting the progress toward the Sprint Goal by reflecting on yesterday’s learning. Then, if the need should arise, the Developers adapt their plan to accomplish the Sprint Goal. While the theory may be generally accepted, applying the idea to the practice is more challenging. One of the recurring issues is the continued popularity of the “three Daily Scrum questions” from the Scrum Guide 2017. Let’s reflect on why answering these obsolete Daily Scrum questions negatively influences the Scrum team. The Purpose of the Daily Scrum The purpose of the Daily Scrum is clearly described in the Scrum Guide — no guessing is necessary: The purpose of the Daily Scrum is to inspect progress toward the Sprint Goal and adapt the Sprint Backlog as necessary, adjusting the upcoming planned work. The Daily Scrum is a 15-minute event for the Developers of the Scrum Team. To reduce complexity, it is held at the same time and place every working day of the Sprint. If the Product Owner or Scrum Master are actively working on items in the Sprint Backlog, they participate as Developers. Source: Scrum Guide 2020. Therefore, the Daily Scrum is an important event for inspection and adaption, run by the Developers, and guiding them for the next 24 hours on their path to achieving the Sprint Goal. The Daily Scrum is also the shortest planning horizon in Scrum and thus highly effective in guiding the Scrum team’s efforts: focus on the outcome. The Problem With the 3 Daily Scrum Questions However, this noble idea is tainted by a widespread habit: centering the Daily Scrum around answering three questions: What did I do yesterday? What will I do today? Are there any impediments?. Initially, these three Daily Scrum questions were added to the Scrum Guide 2017 as an example of how the Scrum team members may inspect the progress toward the Sprint Goal. However, these three questions quickly became synonymous with the Daily Scrum. So now, it was all about answering these three questions, turning the Daily Scrum into a sort of status report meeting, with Developers waiting in line to “answer these three questions” to the Scrum Master, the Product Owner, or maybe even a stakeholder. Unfortunately, the “three Daily Scrum questions” appeal to many practitioners: they are simple, efficient, and create a comforting routine. However, as a Scrum team, we care less about detailing our previous work and justifying why we deserve a pay-cheque at the end of the month. Instead, we want to understand whether we will meet the Sprint Goal. If the Scrum team’s progress is doubtful, given recent developments and learning, we want to take action to get back on track. Any form of a status report is a mere distraction and wasteful in that respect. Conclusion Scrum as a practice is outcome-focused; it is not about maximizing the number of tickets accomplished during the Sprint. Instead, as a team, we are interested in achieving the Sprint Goal. There are endless ways to run your Daily Scrum without falling into this 3-question routine. For example, walk the board and figure out what needs to be done to move the tickets closest to “done” over the finishing line. Please do yourself a favor and avoid turning your Daily Scrum into a boring reporting session. How are you running your Daily Scrums? Please share your tips & tricks with us in the comments.

User stories are an effective tool for capturing requirements and defining features in a way that is easy to understand, test, and verify. They are written in natural language, without any technical jargon, and are typically structured in a format that describes the user's identity, what they want to achieve, and why. For example, a user story might be something like, "As a customer, I want to be able to pay for my order online so that I can complete my purchase more quickly and easily." User stories are typically captured in a tool like Jira, which is a popular project management tool used by many Agile development teams. Jira allows teams to create and track user stories, assign them to team members, set priorities, and track progress. However, user stories are often just the starting point for software development. To turn a user story into a fully functional feature, you need to link it to the database objects in your data model. A data model is a graphical representation of the entities, attributes, and relationships that make up a system or application. It defines how data is stored, organized, and accessed by the software. Linking user stories to data model entities helps ensure that the software meets the needs of the end users. Also, linking user stories to data model elements can help in impact analysis. This allows for easier identification of potential impacts of changes to one part of the system on other parts of the system that depend on that data. This can help make more informed decisions about how to implement changes and minimize the risk of unintended consequences. In the following tutorial, we'll walk you through the process of creating user stories on Jira, exporting them as a CSV file, importing them into ERBuilder (a data modeling tool and documentation tool we will use in this tutorial), and then linking those user stories with data model entities such as tables, columns, relationships, procedures, and other entities. Step 1: Create Salesforce User Stories in Jira To start creating user stories in Jira, go to the desired Jira project and click on the "Create" button to initiate a new issue. Select the "Story" issue type or the type that is appropriate for the project you are working on. Fill in the necessary information for the user story, such as the summary, description, and any relevant details. Step 2: Export the User Stories to a CSV File To proceed with exporting user stories to a CSV file, access Jira's built-in export feature. Click on the "Filter" option located at the top of the screen. Next, choose "Advanced Issue Search" and apply the appropriate filters by selecting "Story" as the type or by directly selecting the relevant issues. You can now choose which columns to include in your exported CSV file by using the "columns" button and then clicking on “Done.” Columns you must have in your CSV export are Issue ID, Issue Type, Summary, Created date, Project name, Priority, Status category, and Description. Once you've applied the filters, look for the "Export" option located in the upper right-hand corner of the screen, and select the CSV file format to export the data. Step 3: Import the CSV File Into ERBuilder After downloading and installing ERBuilder, create a new ER diagram project in ERBuilder. Give the diagram a meaningful name that reflects its purpose. Otherwise, you can reverse an existing database and get the ER diagram. The next step would be to import the exported user stories from Jira. To do this, you can follow these steps: Navigate to “project” within ERBuilder. Open Requirements / User stories. Click on the "Import" button, which is typically located on the bottom left side of the screen. Browse and select the exported CSV file that contains the Jira user stories you want to import. Click on the "Open" button to complete the process. Step 4: Link the User Stories to Data Model Entities Now you can link a user story to the corresponding entity or attribute in ERBuilder. For example, if you want to link a user story to a table, proceed as follow: Select the user story that you want to link to your table. Go to the "Related tables" tab within ERBuilder. Use the search box to find and select your table. Once the table is selected, click the forward arrow to link it to the selected user story. An alternative way to link user stories to data model entities in ERBuilder is by using the Treeview, Browser, or Diagram navigation options. To do this, you can use the Treeview, Browser, or Diagram navigation options to find and open the entity you want. Open the entity by double-clicking on it. Navigate to the "Requirements/User Stories" section. Select the user story you want to link from the list on the left side. Click on the forward arrow to link the user story to the object. The same process applies to other data-model entities such as columns, relationships, constraints, triggers, procedures, and requirements. Once you have linked your user stories with your data model entities, you will be able to generate comprehensive data model documentation that can be used by your team to gain a better understanding of the project's requirements and the corresponding entity elements.

In the list of activities in the Scrum software development life cycle ranked by their popularity amongst developers, “attending meetings” is perhaps locked in a perpetual battle only with “writing documentation” for the position of last place. It’s quite understandable: meetings can easily become very boring — especially when a participant does not have anything to contribute to the meeting at hand — and are often perceived as having little value (if at all) compared to conducting actual code-writing in the software development project. However, these Scrum meetings can and do provide value to the project, even if the members of the team do not perceive it: Sprint refinements enable a product owner and the team to plan out development tasks in the weeks/months to come as well as identify whether any task might need further examination and/or design. Sprint plannings define what work the team should be set to accomplish in the given sprint period. Sprint demos provide visibility to other teams and/or project stakeholders into what a team is working on and has accomplished and permits questioning for clarity regarding the work (or even challenges to ensure that the produced work is robust and has fulfilled all objectives). Sprint retrospectives allow a team to identify factors in the previous sprint that were well-received, could be addressed for improvement or elimination, etc. This is, of course, merely reciting from the doctrine of Scrum. Whatever benefits these meetings may hope to provide will not appear if the participants of the Scrum meeting are not interested in “playing their part” in said meetings — execution, after all, eats strategy for breakfast. What can be done, then? One could: Dress up the Scrum meetings in cute metaphors — for example, using t-shirt sizes instead of point poker for story effort estimation during sprint refinement. This still leaves it clear that the meetings are exactly what they are, i.e… overhead to a project that the team members have to trudge through. Simply press the benefits of Scrum and appeal to the team members’ professionalism so that they step up and provide the necessary meeting input. Even with the most skilled motivator conducting this speech, it runs the risk of sounding browbeating or haranguing and might conduct the opposite effect of bringing morale down. Instead… As much as these attempts may be well-intentioned, they usually do not succeed in raising enthusiasm or buy-in for the meetings. In my opinion, this is due to the thought process behind the endeavors confining itself to the traditional definition of the meetings: they are still held as bog-standard meetings wherein the description for how the ceremony should occur is followed nearly point-by-point. Instead, it’s possible to make these meetings less “painful” for those involved in other ways by employing some outside-of-the-box thinking. For this, I would like to provide two examples from my own experience working at LucaNet of meeting formats that improved engagement while still providing the same desired output. Expand the Scope: Sprint Demonstrations At first glance, the objective of the sprint demonstration seems very straightforward: having the project’s teams provide a demonstration of whatever they have accomplished in the past sprint. This usually comes with the added stipulation that these demonstrations be related to the teams’ sprint goals; what if there is no such restraint for the teams? The sprint demonstration could be transformed into a type of internal meet-up, where not only do teams provide an exhibition of what they have worked on for their projects but also present topics that they feel might benefit the other teams as well. For example, a team whose members are inclined to experiment and conduct exploration of performance-related subjects might present their findings of programming language patterns to embrace (or avoid! ), whereas another team could show off a new technology that they have investigated. Aside from allowing developers to present items that genuinely interest them, permitting such presentations has the added benefit of allowing teams that might otherwise be unengaged in such meetings to participate as well, e.g. a tech-support team that would not normally have work that is related to the development sprint. Given that these meetings would undoubtedly take longer to conduct than ones that only presented sprint-related topics, it would be beneficial to adopt other aspects of tech demonstration meet-ups such as providing food and drink for the attendees, allowing voting (and small prizes) for the “best” presentation, and so on. Remove the Formality: Sprint Retrospectives It’s possible to take a step even further than before: instead of modifying the meeting’s “permitted” activities, why hold a “business meeting?” The objective of the sprint retrospective is to obtain feedback from a team’s members about how the previous sprint went, what they would retain/improve/eliminate, etc. This requires communication from the team members about their experiences, and such communication about past experiences and the opinions thereof is, in effect, a group conversation. There are other settings in which this kind of group conversation can be cultivated; one such example would be a team meal. As in, the team assembles for a meal — breakfast, lunch, dinner, whichever — and talks about their experiences during the previous sprint while they eat and converse about whatever other topics they might have in mind. Whether this food is provided by the company or by the participants of the meeting is up to the organizer, although having the participants supply the food (aside from being cheaper for the company!) adds the intrigue of a pot-luck wherein the participants can introduce their colleagues to foods that those colleagues might not otherwise be acquainted with, something especially poignant when working on a team with members from different cities or countries. However, the main benefit of this approach is the atmosphere that it helps to create. At its core, the sprint retrospective is an exercise in catharsis: the participants “unload” the feelings — both positive and negative — that they have accumulated during the sprint about how the sprint played out. When converting this meeting into a shared meal, the setting switches from the formal to the informal, and this relaxation of the ambiance can help draw out these feelings from the participants better than in the traditional format of the meeting, meaning more effective feedback and thus more effective input for how to improve further sprints in the future. Parting Words A qualifier that needs to be made here is that the practices described above occurred during the pre-COVID era — that is to say, before the widespread adoption of remote work. Some of the practices would undoubtedly need to be adapted for companies whose teams comprise members that never (or almost never) see each other in the physical world — for example, holding team breakfasts via a video call and from the confines of each team member’s own dining room or kitchen — and there is likewise the possibility that the productive effects of the approaches might be different for remote teams compared to in-person teams. Nonetheless, the base principle stands that it may be worthwhile to challenge the conventions of traditional meeting formats to discover whether any modifications to a group’s meetings can result in more productive and engaged teams. Reinventing the wheel does not need to be the be-all and end-all; it may very well be that what is already prescribed is the best solution for the team at hand. However, even such cases would stand to benefit from this exercise, as the end result would still be an introspection as to what truly serves the team well for its development process.

The software development process is complex. It involves various tasks that need to be distributed among teams and completed within a designated time frame. Managers need to be on top of the software development process and establish a workflow that can be traced, as mismanagement of even a minuscule size can lead teams to compromise on deadlines. This is where a metric like Sprint Velocity can help set achievable targets and gain visibility into the process. What Is Sprint Velocity? In the agile development framework, teams divide the available time into smaller durations or sprints, which can be certain days or weeks. The number of completed tasks at the end of each sprint is the velocity of that particular sprint, and the average velocity value across these sprints is the sprint velocity of the entire development process. Calculating sprint velocity is crucial in the development process as it determines the success rate in achieving deadlines. Apart from helping determine achievable deadlines, the sprint velocity metric also finds other applications in the agile development process and in the developer's well-being. How is Velocity Helpful for Scrum Teams? Regularly tracking sprint velocity can help software teams gain visibility into the project's progress and blockers hindering it. Not achieving the target sprint velocity can signal issues managers can look into and analyze. This enables them to understand the blockers in the development process and identify gaps — both internal and external. Here are other insights that can be obtained by calculating sprint velocity: Understand the technical difficulties in the project Optimize resource allocation between sprints Uncover blockers in different stages of the development process, be it writing codes, testing, or feedback and rework Discover if there are any discrepancies in the objectives provided by stakeholders Find out if the requirements are changed frequently Though the benefits of constantly calculating sprint velocity are plenty, there is no one way to do it. Organizations have multiple concepts to calculate sprint velocity in their agile planning process. How Do We Measure and Visualize Sprint Velocity? Every team, every project, and every client is unique. Hence calculating velocity across these verticals can be challenging. Over the years, organizations have come up with different variables and constants that can help them calculate and analyze the sprint velocity. The most common among them are: User story Capacity Definition of Done Velocity graph Burndown chart User Story A user story is the quantifiable translation of the requirements needed to complete a particular feature, module, or product based on the benefit from an end-user perspective. The user story is assigned points based on the complexity and effort needed from a minor story or bug fix, earning 1 point and a significant development or edits ranging between 5 to 8 points. Again, this varies across sprints, teams, and departments. Capacity Planning capacity for the team helps arrive at a realistic valuable available to complete the user stories. Capacity planning helps estimate the available bandwidth to develop, test, and edit user stories. This metric is arrived at by calculating individual availability and mapping it to the list of user stories, thus giving the aggregate of the time the team has to complete the task. Assuming a developer ideally has 6 hours of productivity bandwidth after meetings, breaks, and other routine activities, and a team has about eight developers working five days a week for three weeks, the capacity is 720 hours. Definition of Done (DoD) Defining the Definition of Done is an agreed-upon set of conditions or acceptance criteria that a process must meet for it to be complete in the perspective of the end user. It can contain various parameters such as testing, review, documentation, and so on, but should meet the completed criteria set by the end user. Velocity Graph The velocity graph comes in handy while calculating the sprint velocity as it highlights the amount of work done and the amount of work remaining in the user story or task. It provides insights into the average amount of work to be completed to achieve the desired results in the sprint. The story point is plotted along the y-axis, and the completed sprints are on the x-axis, and both come together to provide an understanding of the team's performance and set up future targets. Burndown Chart While almost similar to the velocity graph, the burndown chart gives insights into the team's progress in completing the committed task across all user stories within a single sprint. The slope of the burndown chart helps predict if the story will be completed early, on time, or late. Sprint Velocity Is Not the Only Metric You Need As mentioned earlier, the spring velocity formula can differ across teams, processes, projects, and clients. Managers should not target a higher sprint velocity and align goals to increase the number. In fact, sprint velocity is: 1) Variable 2) Descriptive 3) Arbitrary Increasing the velocity alone can be complex and counterproductive, especially without any data or tools to back it up. Managers should also leverage other assessment factors like better code reviews, quality assessment, and better planning throughout the development process by taking a data-driven stand rather than a completion-oriented one. Managers should have access to other software development metrics like code churn, maker time, and even async stand-ups to identify blockers effectively and leverage the gathered insights from these metrics to improve sprint velocity. To do this, they need an engineering analytics platform that encompasses the critical tools and analytics to optimize the software development process.

Every software project has its own aura. That aura existed before the project was even started. It gave birth to the project and will be alive when the project will be decommissioned and/or replaced with some other project. This aura is The Full Context. The Full Context consists of all information directly or indirectly related to the project. It's the single source of truth for every single decision related to the project, from the decision to start it to the name of every variable in the code. The Full Context is enormously big and contains a lot of business, economic, and political information, such as company finances, the influence of persons or groups on particular decisions, or even the state of the mood of the developer that affected a particular decision. Dealing with such huge amounts of information is possible only by layering it into a hierarchy of abstractions. Each layer of the hierarchy consists of elements — each element can be considered a word, and the whole set of elements at the same level of abstraction: the language. This language is then used by the next layer of abstraction to express words used by the layer above, and so on and so forth. In most cases, there is no single "root" abstraction and no single hierarchy of abstractions. Instead, the context information is structured as a bunch of independent hierarchies. It should be noted that strict layering of abstractions is essential to keep context comprehensible. Abstractions leaking to upper levels may result in uncontrolled growth of complexity and make context an incomprehensible mess. The Context The hierarchical context structure enables us to extract only the technical part of The Full Context, i.e., the part directly related to the project. Let's call this part The Limited Context, or simply The Context. This part of the full context is the only one usually necessary for development. To abstract out non-technical aspects, it is convenient to consider The Context as the single source of truth of all made project-related technical decisions. This abstraction removes "why" these decisions were made by removing all non-technical factors. This is a deliberate decision, necessary to limit complexity by keeping only parts essential for software development. The Context is constantly updated and extended by new technical decisions we make every day. If some decision is not yet part of The Context, the decision is somehow made (usually using procedures specific to a particular team/company/product/etc.) and put into context. These decisions, therefore, look like a "decision map," which maps each "issue" to a particular "decision" and invokes a predefined procedure if an element is missing. From general considerations, it makes sense to keep this "decision map" as small as possible because it directly contributes to the complexity of The Context. In other words, it is preferable to have a smaller set of more general/generic decisions that covers a wider range of similar situations. Inside The Context Let's take a closer look at The Context and check what else is there. Besides decision map, there are: the real business domain the business domain model real business processes the model of business processes The word business here is a placeholder because what is business is up to each particular project and The Full Context which gave it birth. In the blockchain industry, at the top of the abstraction hierarchy, there will be blockchain domain and blockchain processes. In e-Commerce, it will be e-Commerce business, and so on and so forth. Note that, when we start digging into abstractions, we'll find that the business at each level of abstraction is different. It should be obvious: We split one of the top-level elements into subparts ("words"), where each "word" is responsible only for part of the implementation. This part of the implementation is the business of this word. This process goes down and down through the layers of abstractions. At the bottom, there are purely technical details like calls to a standard library or even more low-level stuff. Actually, detailing can be continued in-depth as deep as necessary (perhaps infinitely) from task context switches, through specific CPU instructions and cache lanes, via signals and buses, down to logic elements and the physics inside the chip die and PCB. Usually, there is a reasonable logical limit below which more details do not add any value. Obviously, if you are building an operating system, then system calls are your top-level language while everything below system calls is part of The Context domain or processes (again, limited to some reasonable level). The business domain model and the model of business processes are our project code. We use programming languages to encode and represent parts of the business domain and processes. In other words, code is a formalized encoding of the business, its domain, and its processes. It means that code is at best as good as the domain and processes. If you have a fuzzy domain or bad/inefficient/inconvenient business processes, the code is at least as bad (usually worse). Also, a map is not territory, so both models are only approximations of the real business domain and processes. It should be noted that relationships between business parts and their models are bidirectional. More often than not, the business is ready to change processes to match one proposed by software. The level of flexibility heavily depends on several factors and may vary. Usually, there is a tradeoff between price/time and the precision of modeling your processes/domain. From "buy ready to use software/subscription to service AND adjust all your processes to proposed model" (and get software up and running almost instantly for a few hundred/thousand $$) to "software should exactly reproduce our processes even if they are stupid, and we hate them" (and spend years and millions of $$), and everything in between. But not only processes can change. The domain of the project also may change. Usually, this happens, when the project scope is reduced or extended. A decision to reduce or extend the scope might be a consequence of the technical assessment or analysis. Nevertheless, it often is more convenient to consider these relationships as unidirectional (even if they're clearly not) and assume that real domains and processes are the sources of truth. Note that various design documents, architecture designs, and other similar stuff are not part of The Context. They could exist and even be useful if they precisely correspond to code, but the code is the source of truth about the domain model and model of business processes. Once we start thinking about project code with The Context in mind, we quickly discover the relevant decisions stored in The Context control code properties: How detailed the modeling is, compared to reality How precise the modeling is How easily real context can be restored from the code (context readability) How long the project will be used How performant it should be Basically, everything about the project is determined by The Context. For example, if you're implementing a one-time migration tool to migrate a legacy system to a new platform, requirements to code quality, maintainability, test coverage, context readability, etc. will be significantly different from those for a backend planned to be used for at least five years. Moreover, those requirements should not necessarily be identical across the whole code base. For example, we might sacrifice some context readability in a performance-critical part of the code to achieve the necessary performance. As one can see, a context-based approach is very business-focused, as opposed to traditional approaches, which are primarily focused on software. Of course, the connection to the business always existed, but it was usually just an input for software development. Specifications and requirements were eventually replaced/complemented by user stories and epics when the industry adopted agile methods. This significantly improved the connection with the business, but the focus on the software was left intact. A context-based view shows that it's not just a connection, but a tight coupling, where the business is a primary driver. The Code The main consequence of understanding of true relationships between business and software is the realization that existing approaches to software development might not be completely up to the task. Even a quick looks show significant issues with the traditional approach based on the best practices. The first thing to note: The traditional approach tries to establish identical practices for all projects. As we know, every project is unique, and setting identical requirements does not seem like an adequate solution (this kind of resembles the famous average pilot story). Second, but no less important: A significant part of the traditional approach relies on code readability as a justification. Overall, code readability is often considered one of the most important properties of code. The problem is that nobody knows what "code readability" is. Of course, every seasoned developer knows that it exists, but there is no reasonable definition for it. Existing ones are either self-recursive (i.e., funny but useless) or rely on other undefined terms such as "intent." This lack of definition means that every assessment of code readability is subjective, and there is no way to validate any given best practice that claims that it "improves code readability." Even the term "code readability" is misleading. If the code compiles, it is readable, at least by the compiler. Most likely, with some effort, code is also readable by the human, too. So, "code readability" is not about reading the code at all. Without a clear understanding of what code readability is, the whole traditional approach starts looking like a cargo cult. We're blindly repeating the same practices with the hope of getting a good result, but we have no idea why particular practices work or don't work in each particular case. A context-based view clearly lacks the issues mentioned above. Code represents parts of the context, and The Context defines the requirements of easily real context can be restored from the code. There is much less room for ambiguity because each practice can be easily validated, whether it helps preserve a necessary part of context or not in every use case. All of the above suggests that we need to significantly change our coding practices. But a detailed look into new coding practices is a theme for another article.

Agile testing is a core element of the Agile software development approach that empowers businesses to work on multiple phases at once. It is an iterative process that goes alongside the development process. Developers, testers, and customers work collaboratively to ensure software quality. If you're wondering if Agile testing is the right approach for your software development, read this article. It has answers to all your questions, including lifecycle stages, best practices, and tools. What Is Agile Testing? Agile testing is a software testing practice that follows the principles of Agile software development. This methodology starts at the beginning of development with continuous integration between development and testing. Unlike the traditional approach, where testing is done post-development, the requirements are gathered flexibly at each stage. Agile testing welcomes continuous feedback that helps developers make changes and resolve performance issues quickly. Other benefits include: Catch bugs faster and save time and money: Agile methodology helps reduce the number of bugs and resolve them in minimal time, preventing time-consuming and expensive fixes. Lightweight testing documentation: As most of the bugs and requirements are solved during the development stage, testers can focus on the essence of the test instead of incidental details. This reduces the need for documentation. Improved collaboration: Testers and developers can collaborate closely and communicate instantly without relying on documentation. This way, it enhances team communication and gives faster test results. High product quality: Here, development and testing go hand-in-hand. This enables the testers to implement preventive and corrective measures to improve software quality. Agile Testing Life Cycle Process The Agile testing life cycle is completed in five different phases. Let's check them out. 1. Impact Assessment During this phase, inputs from stakeholders and users are gathered, which then assists the testers in setting the objectives for the next life cycle. Thus, it is also known as the feedback phase. 2. Agile Testing Planning This stage includes planning the schedule of the testing process and deliverables by stakeholders. 3. Release Readiness In this stage, it is reviewed whether the developed features are ready to go live or not. If not, what changes are required to go further? Which features/modules need to go back to the previous development phase, and so on. 4. Daily Scrums This includes a standup meeting to catch up on the testing status and set the goal for the day. 5. Test Agility Review This Agile testing life cycle phase includes weekly meetings with stakeholders to check the evaluation and progress against the goals. Agile Testing Best Practices Focus on What You Need to Achieve You need to focus on one feature at a time when it comes to testing. This is a simple practice where you can ask your team to prepare the test cases for a particular feature or functionality testing. However, you must also ensure that you check the test case and review it for correctness. This is one of the prime aspects of Agile testing execution on the features and functionalities of the software. Test Repeatedly In Agile testing, testing before and after coding is highly important in order to check all the units of software precisely. You can even test during refactoring. Repeating tests will ensure that the new codes are maintainable and adhere to the new standards. Test the apps multiple times whenever there is even a small code movement, code merge, or change. In-Person Communication With Developers Agile testing is an iterative process. Hence, communicate with the developers and customers at each stage to know more about the features, requirements, and expectations. The clarity will help eliminate errors and bugs in the software while ensuring customer satisfaction. Goal-Oriented Work Approach Before embarking on the testing process, Q.A. testers need to plan a goal and decide the area of focus. In addition, being a tester, you need to understand the code-calling requirements and test suite framing. So, by adopting a well-planned approach, testers will find it easy to collect the application's functionality. Know When to Use TDD In software development, TDD (test-driven development) practice focuses on creating test cases before developing the actual one. This approach works best in some cases. You need to know when to use it, though. TDD helps to write and correct the failed tests before writing new code. Therefore, it is important to know when to use TDD since it helps avoid duplication of code even though writing a small amount of code in order to pass the tests. Here, tests mean the requirement conditions which developers need to test in order to fulfill them. Agile Testing Tools JIRA JIRA is one of the most popular Agile testing tools due to its ease of configuration. It is used for bug tracking, issue tracking, and project management. The widely used Agile testing tool also includes quality assurance processes in every step of software development to meet the requirements. Moreover, it has the capability to add plug-ins such as X-Ray and Zephyr to improve performance. Here're some of the key features of JIRA: Bug and issue tracking Audit logs Support for Agile methodologies such as Kanban, Scrum, etc. Custom workflows Agile reporting Allows over 3000+ app integrations. Selenium An Agile automation tool, Selenium allows the complete testing team to be involved in making automation test cases. It is suitable for web-based apps. Check out some of the key features of Selenium: Supports programming languages such as Java, Python, Ruby, Perl, PHP, and JavaScript. Automates browser-based apps. Serves as a framework for open-source test automation tools such as TestProject, Robot Framework, Katalon Studio, etc. Conclusion Agile testing has several benefits, such as improved collaboration, development flexibility, and time to market. In addition, it is a customer-centric approach that delivers quality products within the stipulated time. With the right partner, tools, and skills, you can get the most out of it. P.S. If you have any questions or want to share your thoughts on Agile testing, please share them in the comments.

Mind maps are used for exploring, clarifying, explaining, or planning. They are an effective way to gather and depict information. This could be information that we want to learn or knowledge that we want to share. We may want to focus on certain points, such as abstracting a number or details. Alternatively, we may want to plan our work ahead or explain how things work in detail. Brainstorming and finding connections between different ideas, solving problems, and creating new ideas, mind maps are a useful tool in our professional or personal lives. They go well beyond software development and they can be used in any human endeavor that requires critical thinking and decision making. A mind map could be anything that organizes our thoughts — drawings, diagrams, tables, keywords, pictures, graphs, Wikipages, and so on. It can be done with a pen and a paper, a marker and a board, or using mind mapping tools like Coggle, MindMeister, Ayoa, MindNote, XMind, etc. A number of software groups that I’ve been working with have been reusing mind maps to release features. Product owners, developers, and testers have found an effective way to avoid missing use cases and identifying edge cases. This helped toward requirements clarification and disambiguation, testability and completeness. Reusing mind maps has led to fruitful discussions, educated decisions, and information exchange between teams. Development Method Used There exist different development methods, like waterfall, agile, lean, extreme programming, prototyping, rapid application development, and others. There are also different flavors for different methods, whilst hybrid combinations could also exist. We will not focus on which method, flavor, or combination is better, but to avoid confusion, we must clarify that this article assumes an agile-like whole-team approach. Development teams contain (at least) developers and testers, and the team’s work is divided into missions. Each mission contains features to be released. For each mission, a product owner is assigned that focuses on business decisions for customers. Mind Maps for Different Roles in a Software Group Product Owner The product owner helps customers define functional and non-functional requirements. After all, this role tries to make the most out of development teams in each mission by fulfilling all requirements. This implies that all team members are pursuing a common goal, establishing priorities so that they work on the highest-valued functionality. Decisions are also made that lead to a good return on investment per mission. What is the value delivered per feature? Which feature is more important for any given set of features? Which feature should be developed first, which second and so on. What did the customer request? A mind map from a product owner could be per feature, or it could involve multiple features or the entire mission. This depends on the feature size and on the scope of the mind map. Size To analyze and explain large features that contain a lot of functionality, it will require more space on a board. When many large features are put in the same mind map, things may get difficult to understand. When a mind map contains tons of information, it is easy to miss details, and people usually get discouraged using it. However, when the scope of a mind map is to depict the functionality delivered during an entire mission, if large features are involved, then careful decisions will need to be made on what to abstract. Scope A mind map depicting interdependencies at a business level between different features will probably include only the interdependent features. A mind map focusing on a feature and its sub-features will probably abstract all other features. A mind map focusing on the security aspects of the delivered features will probably depict only the features involved in the security use cases. This is the context that needs to be clarified as far as a product owner is concerned. Developer Developers need clarity and completeness about what should be implemented. They decide how to write the implementation code and their tests. Based on mind maps from the product owner, they can create their own mind maps. It’s up to the developer what information should be depicted (the scope of the mind map). Is it used to clarify code interdependencies? Is it used to explain how things work? Is it used to depict what has been unit tested and what not? Is it used to request clarifications from product owners? Is it used to depict specific areas in the code that require attention from testers? Entity-Relationship Mind Maps Entities and their relationships are a basic way of analyzing software systems. Entities could be specific to the domain in which we are working, such as invoices for accounting systems, items in inventory systems, nodes in network management systems, or friends in social networks. Exploring entities and their relationships in a mind map has helped development and product teams achieve alignment on what should be developed. It has also helped testers identify edge cases and brainstorm with developers about performance bottlenecks. State-Transition Mind Maps Identifying events that trigger transitions between states is another way of analyzing software systems. For example, a log-in event may have triggered the transition from a logged-out state into an authorization state and then a logged-in state. States can be directly controlled by the UI and easy to identify like logged-in/logged-out. They can also be subtle, triggered by the passage of time (e.g., timers in our software system have expired) and are uncontrollable by the UI, like authorization. Mind maps depicting states and their transitions can be helpful in implementing and debugging. They can also help to identify edge cases and reproduce sporadic bugs. Tester This role tries to make sure that bugs are found and fixed before releasing features to the customers. After the release, testers try to verify that the evolution of features follows certain quality criteria. Testers create and execute (UI or API) tests from requirements. Mind maps from product owners as well as from the developers could be very beneficial. A product owner will include functionality that needs to be released. This is excellent for test-case design in black-box testing. Some development teams created mind maps to depict what has been tested at a unit level. This indicated to the testers what has been tested and what not. Testers may augment development mind maps to make sense of what needs to be tested. Here lies grey-box testing information. There were cases when developers shared mind maps depicting areas in the UI that needed attention from testers. This was another major source of grey-box testing information. Based on this kind of feedback from developers, testers could focus their testing efforts. Ecosystem Mind Maps An ecosystem includes the environment in which our software lives, all the interfaces into our software, and all the external dependencies. A mind map of the entire ecosystem could give a clear picture for investigating connections, dependencies, and risks associated with the parts of our system that are outside our software’s control. One team used ecosystem mind maps that depicted how their software connected to the outside world. The focus was on the interfaces, users, and connections to integrated systems. Another team used a deployment-based ecosystem mind map. It was focused on where the components that make up their system, such as databases, configuration files, and executables, live in a production deployment. Ecosystem mind maps helped testers to devise their own positive and negative testing mind maps. They also helped product owners to get a bigger picture of their software and consider use cases that would have been missed on requirements. Developers found edge cases that needed special attention on their code. Wrapping Up Mind maps are reusable, tailorable, and can be mixed and matched according to our needs. They can be an effective tool for exchanging information and boosting confidence between teams to release features. After all, it’s all about aligning with the common goal of making customers happy.

In a recent article titled Why Do Many Developers Consider Scrum to Be an Evil Scam, Scrum consultant Willem-Jan Ageling bemoaned the clear impression that people outside his professional circle didn’t share the same devotion to the framework, "I am a Scrum enthusiast. When I'm in my Agile bubble, I have the pleasure of having great conversations. We may have different opinions about approaches, but in the end, we mostly agree on the merits of Agile and Scrum. But when I leave my bubble, I often receive backlash. The worst thing I have been called is a snake oil salesman, selling an evil scam". I won’t unpick his arguments in detail. I don’t think Scrum is an evil scam and I don’t think Mr Ageling is a snake oil salesman. Yet I have seen Scrum being misapplied too often to ever become an enthusiast again. Here are my very personal reasons, based on first-hand evidence. It’s biased, but then I don’t pretend to speak for ‘many’ developers, let alone all. The tech world has been infatuated with Scrum to the point of becoming blind to alternatives. It is adopted without question and considered appropriate, even essential, for every software project. Yet most tools and techniques are not a good fit for every creative process. Each should be evaluated for its usefulness depending on the circumstance. Scrum is usually imposed by the organization company-wide. When not at liberty to ignore it, people go through the motions. Ceremonies feel like dressing up for dinner. Nobody likes it or sees the point, but we do it as a matter of etiquette. Framework Infatuation It’s fine to be enthusiastic about a technique of framework, but when you refer to a circle of like-minded individuals as a bubble – twice in the same paragraph no less, it speaks of more than rational professional preference. It speaks of fandom. The risks of that are obvious. It keeps you from throwing out the old when something better comes along. We don’t do that with people we love, and we’re loath to do it with cherished ideas. When something is close to your heart, faith too often trumps truth. In rational matters, this pushes science into religious territory. Save your love for other people or a more worthy cause. You are a human being before you are a Java professional. It’s okay to be pragmatic, even mercurial about picking tools and techniques to further your career. You’re not swearing an act of allegiance to Java or Microsoft. If you fall in love with C#, James Gosling won’t mind. I have invested heavily in the Java and JVM ecosystem over the past fifteen years, but I’ll go with the flow if the world moves in a different direction. Once I did a lot of Google Web Toolkit. It’s obsolete tech now, and rightfully so. I had fun, made good money, and moved on. No harm done. Besides an inability to recognize better alternatives, tool infatuation leads to the anti-pattern of the Golden Hammer. You think it’s essential and indispensable because you like it too much and don’t care to know what else is around. Sure, we can’t know all. We must separate the essential from the optional, given our limited cerebral resources. We must pick our fruits from the tree of knowledge with care because they take time to pick and go bad quickly. At the Devoxx 2022 conference, a frankly intimidating chart was handed out that covered many of the hard skills in the Java ecosystem, categorized into essential, good to know and nice to know. A commendable effort, which didn’t even touch on soft skills and said nothing about the required depth of each domain. Many branches in the tree had bookshelves and conferences dedicated to them. Radical Distraction Elimination Thankfully not everything in the Java domain is indispensable for every project. De-facto standards like JUnit and SLF4J spring to mind (pun intended). It all depends. Sometimes you need to go deep on a technique you haven’t used before. You can become the number one Quarkus guru in your postal district for a year and then not touch the framework for the next five years. I believe the successful developer of the future is a radical distraction eliminator and productivity optimizer. She’s looking for the human advantage over AI and knows that it is no longer in solving math puzzles or the nitty-gritty of the arcane Unix command lines. Time will tell how we can beat the machine and be worth our paycheck, but time and effort spent on something that doesn’t provide a business advantage or makes you cleverer is always wasted. This brings me back to Scrum. Management frameworks should be treated no differently from hard skills and software libraries. If they don’t help the team here and now, in this project, they hinder. Mileage always varies, whether it’s with a set of generic best practices or someone’s personal ‘secret to my success’. I’m sure every aspiring horror writer would love to know the routine that kept Stephen King so prolific for fifty years, but even if he does have a method, it’s his method. Scrum is not the method. Scrum is not tailor-made. It implements a generic support function that is nevertheless prescriptive, inflexible, and usually imposed as a mandatory way of working on a team. A prescriptive framework is about rules, not recommendations. You cannot use your own judgment to bend or suspend the rulebook at will, like in air traffic control. This is good when lives are at stake. But mandatory rules must have a firm scientific basis to justify their generic usefulness. This basis is lacking in Scrum, and neither do we find it in very opinionated statements from the Agile Manifesto about team autonomy and the superiority of oral communication. All this wouldn’t matter if teams had the liberty to just ignore Scrum and settle on a mode that suited them best. We know that’s not the case, especially not in the enterprise world. Scrum is usually imposed from on high and facilitated by people whose livelihood depends on it. Great facilitators and coaches understand that Agile is about context-dependent principles, not rigid procedures. These people possess a treasure trove of experience and an extensive toolkit from which to suggest what is needed at the moment, whether it’s from a proprietary framework or not. I haven’t met many of them. Dressing for Dinner Like every other member of the British upper class, the aristocratic Crawley family in Downton Abbey would dress for dinner. Even on a drab Monday, with no guests and nothing to celebrate. It was time-consuming and uncomfortable, yet nobody questioned its usefulness. They knew there wasn’t any. Their elaborate dining etiquette came with the job. They went through the motions. Ingrained habits will do that. More than once I have felt like that in standups and retrospectives, even in very casual attire.

The success of a software development process depends majorly on delivering projects and meeting deadlines. Or so it was always believed. However, working in such am environment resulted in the loss of quality of work, excessive reworks, and increased pressure on the software developers. In an attempt to solve this issue and to set up a much better working methodology, the agile way of working took form. The Origin of Agile Twenty years ago, 17 people from around the world gathered at a ski resort in Utah and created what we know today as Agile Software Development Manifesto. The core value of this new alternative to the traditional project management process was to place people and values at the core and work together to achieve results. The Agile approach to software development focuses on completing the project with iterations and constantly focuses on improvement and collaboration. The founding group that called themselves the Agile Alliance went on to create four central values of the Agile Software Development Manifesto: Unlike the waterfall approach, Agile methodology divides work into actionable items, called sprints, enlist feedback and reprioritize work as per business needs and market changes. List of the Most Popular Agile Methodologies The Agile approach focuses on achieving the goal of breaking the project into iterative blocks of work that focuses on continuous delivery. Below are the four major methodologies that highlight the Agile way of working: 1. Scrum One of the most popular Agile methodologies, the Scrum way of working, aims at breaking the entire development cycle into smaller cycles called sprints, which have variable completion rates. These completion rates are determined by the sprint velocity, which is the average of time it takes to complete all the sprints involved in the development process. Key Focus The Scrum methodology focuses on continuous development with insights into productivity across the sprints and also the blockers in the development process. The Scrum process also fosters better collaboration between teammates and consists of a Scrum master who manages the stand-up meetings to understand the progress and issues in the development process. 2. Kanban This visual form of workflow management originated in the manufacturing sector and later found its application in the software development process. This methodology of the Agile development process utilizes visual cues to provide visibility and track progress across the various stages of the development process. Key Focus Like the predecessor, the Kanban methodology focuses on continuous delivery with insights into the upcoming tasks through the Kanban board, which consists of the process flows in column view to deliver the projects on time. Users can get real-time visibility into the development process at any given time, along with a view of the development workflow. 3. Extreme Programming (XP) Extreme Programming also emphasizes dividing the entire project into shorter development cycles and gathering customer feedback and requirements at the end of each iteration. This makes it easier to incorporate any changes or includes new requirements without any hassle. Key Focus This Agile methodology has a keen focus on constant communication and customer satisfaction. This is achieved through continuous testing after each iteration, thus ensuring customer demands are met and there are no changes at the end of the development cycle. 4. Crystal The Crystal methodology of Agile development methodologies comprises a family of functionalities that include Crystal Yellow, Crystal Clear, Crystal Red, Crystal Orange, and more. All of the above have a unique framework that is categorized by various factors, such as the criticality of the project, the size of the team, and the different priorities in the project. Key Focus Like all the Agile methodologies above, the Crystal approach focuses on the quick and continuous delivery of projects and customer satisfaction. According to the 16th Annual State of Agile Report, Scrum has been voted the most popular Agile way of working, with 66% of the 4,182 respondents identifying it as the methodology they follow. Benefits of Agile Scrum Software Development Cycle According to Project Management Institute, 71% of U.S. companies are using Agile methodologies to manage their software development cycle. So it is safe to say the agile way of working is the most common in software development. The benefits of the Agile way of working are vast, from faster time to market and better visibility to improved customer satisfaction. The Agile framework’s focus on collaboration and continuous improvement also makes it an efficient approach to modern software development. Here are other ways how it drives digital transformation with visibility into improvement through: Flexibility Breaking down the entire SDLC process into smaller cycles provides better control and flexibility as teams can observe one cycle, gather inferences and gain insights into making the iteration process more efficient. Adaptability The iterative framework enables teams to adapt to new requirements and processes better, owing to the observations from the gathered data. This also helps in better resource allocation and adaptability across the development cycle. Process Optimization The Agile way of working helps managers to optimize the process until the desired result is achieved at the desired time, cost, and quality. Optimization is possible due to the focus of the Agile process on continuous delivery and improvement. Risk Mitigation The insights generated after every iteration, equipped with traceability and collaboration of the teammates, help efficiently uncover the blocker in the development process. Managers can also track the pattern across the entire development cycle and zero in on issues and hindrances better. Agile and the New Work Normal Ever since the onset of the pandemic the world has witnessed massive shifts in the way of working. And though the world has returned to normal to an acceptable extent, the workforce that witnessed a paradigm shift in the way of working has fully adapted to the hybrid and remote way of working. This new normal has been a revolutionary change in the global workforce that is beneficial to both the organization and the employees. This is the future of work and it is defined by the streamlined focus on digitization, data, and people. The new work environment enables employees to preserve their focus time and maintain a better work-life balance, thus reducing the chances of employee burnout. Coming to software development, the remote and hybrid way of working has cut down the manual efforts in everyday mundane tasks and updates, thanks to automation tools and software that enable them to focus on the tasks and their well-being. In fact, Agile adoption went up by 33% in the mid of 2020, which is the initial phase of the shift to remote working. According to the 15th State of Agile Report, which was recorded in 2022, 89% of teams are geographically distributed, and working hybrid; this clearly establishes remote working to be the new normal. To help manage this new era of working, managers should adopt a data-rich platform that enables them to drive digital transformation in the software development process and generate data-enriched reports through high integrations. This empowers them to automate processes and focus on people. However, this scenario is only feasible for organizations that have added an analytics tool to their software arsenal. Final Words It is clear that the Agile Software Development Cycle is the future of work. Therefore, organizations should take the first stride to adopt and maximize the functionalities of this popular and efficient framework. To make the process successful, organizations should also utilize other software metrics like sprint velocity, code churn, and other that helps optimize the agile framework and achieve the desired results. However, individually measuring these metrics can be difficult and have limited value. An Engineering Analytics tool solves the issue by providing a platform that efficiently integrates with everyday software tools to gather data, analyze them and provide actionable insights without disturbing the focus time of the teammates.