Agile and Scrum: Novel techniques to develop fast software advancement
?AGILE AND SCRUM ROLE IN SOFTWARE TECHNOLOGY DEVELOPMENT
"Continuous delivery" in software plays a significant as continuous delivery of software is the holy grail (The Holy Grail is a treasure that serves as an important motif in Arthurian literature) of software development practice, customer retention, and it's the prime reason to keep a hot concept DevOps still relevant. To comprehend the importance of continuous delivery, it is necessary to recognize the progression of the history of agility and the origin of agile methods. Agile software development history has its roots in very old evolution in software development practice, including the origins of agile and how more recent knowledge is leading us to more faster.
The reason for agile evolution
?As PC computing began to thrive in the enterprise in the 1990s, software development faced a crisis. During "the application development crisis," or "application delivery lag." Industry experts estimated that the time between a validated business need and an actual application in production was about three years. The fact that many business enterprises within the space of three years, requirements, systems, and even entire businesses were likely to change. It makes the new projects outdated even partway and in many cases, projects that were completed didn't meet all the business's current needs, even if the project's original objectives were met. In certain industries, the lag was far greater than three years. In aerospace and defense, it could be 20 or more years before a complex system went into actual use. In certain extreme cases, the Space Shuttle program, which operationally launched in 1982, used information and processing technologies from the 1960s. Highly complicated hardware and software systems were often designed, developed, and deployed in a time frame that spanned decades.
The necessity to overcome the time lag
Jon Kern, an aerospace engineer in the 1990s, to make short time lag to be relevant was one of 17 software thought leaders who started meeting informally and talking about ways to develop software more simply, without the process and documentation overhead of waterfall?and other popular contemporary software engineering techniques. Other industries were also undergoing transformation. It took the automotive industry six years or more to design a new car, and in the 1990s, that time was cut almost in half. AT&T had been broken up, and the so-called Baby Bells were drastically cutting the costs for phones and services. For those products with a software development component, such as phone switches, autos, or aircraft, software was often an afterthought, mostly because software development didn't start until the hardware design was fixed in place. But building the software wasn't a priority for most product teams at the time.
And agile was born
These obstructions around seemingly unproductive software development activities, which were shared by like-minded professionals, led to the now-famous Snowbird meeting in Utah in early 2001. Before that, they had gathered the year before, at the Rogue River Lodge in Oregon in the spring of 2000. This group included Kern, Extreme Programming pioneers Kent Beck and Ward Cunningham, Arie van Bennekum, Alistair Cockburn, and twelve others, all well known today in the agile community. Agile, as a practice,?was not the final destination; in fact, "agile" had yet to be used in formal conversation before that time. At that meeting, the terms "light" and "lightweight" were more common, although none of the participants were particularly satisfied with that description.
In particular, these thought leaders pursued ways to swiftly develop working software and get it into the hands of end-users. This fast delivery approach enables users to get extra new business benefits from the new software quickly. Second, it enabled the software team to get fast feedback on the software's scope and direction became the key feature of the agile movement. If the software team isn't confident in understanding what the user needs, it delivers a first approximation and then listens to feedback. But little is set in stone at the beginning of the project.
A backlash against heavyweight processes
Agile is in no way defined by analytical development methodologies devised in the 1970s and 1980s responding to the disordered and unintended styles often used in the early days of software. In fact, 1970 to 1990 was largely when foundational theories and practices of software engineering came into being. The idea was to equate software engineering with physical engineering and borrow as much as possible from the design and building actually.
This approach demonstrated itself in what has become known as the?waterfall?methodology. This method obviously defined major phases of the application development lifecycle, from requirements to deployment. It was termed "waterfall" because teams complete one step, fully, before moving on to the next. Necessities must be complete before moving on to functional design, functional design complete before detailed design, and so on through the sequence. And like water not flowing uphill, there are rarely provisions to return to an earlier stage of the process. Once you were finished with a stage, that stage was frozen in time
This method carried an intellect of organization and engineering practice to software development. But there is a key difference. Projects in civil or mechanical engineering rarely change over the course of a decade or more. If you need to design a bridge or a high-rise building today, it's very likely that the specifics won't require modification in a year or two. Actually, waterfall as originally conceived supposed to adjust to change and reconsider project decisions. There was accommodation for going back to the previous stage, and adjusting some of the decisions and expectations, and those changes could change aspects of the current stage. However, ?schedules and budgets almost always made that impossible, forcing teams to stick with earlier decisions. At the time, it was taken as gospel in most software development groups and university computer science departments that the more time you spent planning, the less time you would spend writing code, and the better that code would be. This only reinforced a process-heavy approach, which put more emphasis on planning and documentation than on delivering working software.
Software projects have the same kind of stability as traditional engineering projects but with exceptions. Business requires needs variation, and surely quicker than the times previously required to comprehensive a software application. In retrospect, it seems obvious that software requires a different approach to engineering and the other part of the problem is that software design is both a science and an art, with deficiencies and related human limitations. Users can describe their business workflows, but they can't tell software designers what features will automate them and how those features should work. The failure to exactly define what is needed before starting to build the product parts software engineering from most other engineering disciplines. Second, the translation from requirements, imperfect as they are, to specifications, and from specifications to implementation, is prevalent with obscurities. ?But because teams are reading at a design level and translating it to an implementation level, mistakes and confusion are natural.
Futurists have diverse views of software development
Some of the repercussion was also driven by the largest software developer in the world: the US government. In particular, the Department of Defense (DoD) standards for software development (in particular, DOD-STD-2167) clearly favored the waterfall model until the late 1990s, when they were changed to obviously support iterative processes. Ultimately, the DoD even designed its own programming language: Ada, named after Ada Lovelace, often referred to as the first computer programmer. An unusually intricate structured language, it appeared to demand a forceful process, with a lot of documentation. It was perfect for the era of the highly documented and planned waterfall process.
Though the waterfall model led in the 1980s and 1990s, industry and academic scholars were forced back. An imperative initial reply was James Martin with?rapid application development (RAD) to diminish the preparation stage and to fast development, so the business could begin to collaborate right away with the development team by seeing a working prototype in a brief period. There was also a move toward so-called iterative software development. While iterative software development has its roots in at least the 1960s, the concept of incremental improvement had taken hold through the work of quality guru W. Edwards Deming and others even before. The concept is to perform an activity, measure essential characteristics, make common-sense changes, and measure again for improvement. Throughout the 1980s, software thinkers such as Gerald Weinberg, Fred Brooks, and Grady Booch wrote highly popular books and articles on iterative development techniques. Fred Brooks, the well-known author of?The Mythical Man-Month, wrote an article called "No Silver Bullet—Essence and Accidents of Software Engineering," in which he notes that there's no singular technique or process that will bring about significant improvements in software development productivity.?Perhaps the most familiar work on iterative development of the 1980s was Barry Boehm's?A Spiral Model of Software Development and Enhancement.?The spiral model was a specific iterative technique whereby a project starts small and gradually grows as more features and capabilities are built into it. While major and highly visible projects often used a strict waterfall model, alternatives were lurking in the background.
The emergence of the Scrum Software Development Process (SSDP)
At the same time, more specific iterative methodologies were being developed. For example, Jeff Sutherland and Ken Schwaber conceived the Scrum process in the early 1990s. The term came from rugby and referred to a team working toward a common goal. They codified scrum in 1995 in order to present it at an object-oriented conference in Austin, Texas. They published it in the form of a paper titled "SCRUM Software Development Process." The idea behind Scrum development was for the development of new, complex products, the best results occur when small and self-organizing teams are given objectives rather than specific assignments. The team had the freedom to determine the best way of meeting those objectives. Scrum also defined time-boxed iterative development cycles whose goal was to deliver working software. Presently, the users of an agile methodology as scrum. Kent Beck was hired as a consultant on an experimental software development project at Chrysler. In time, he was named the project leader, and in an effort to succeed was determined to take best practices to an extreme level, giving the XP methodology its name. In spite of the project being in due course canceled when Chrysler was acquired, Beck had published a book titled?Extreme Programming Explained, and his name became synonymous with one of the leading alternative methodologies. Perhaps various agile and iterative techniques would still be in the minority were it not for the Agile Manifesto, codified at that 2001 meeting in Snowbird. Though aims were not clear of this group, the Manifesto is the clearest and most succinct statement of purpose of an approach that was the antithesis of the waterfall model that was still prevalent at the time. Consequently, the software development community has closed to the Agile Manifesto and its 12 principles as the definitive statement of the agile software development movement. Now, increasing teams self-identify as using an agile methodology. While many of those teams are likely using a hybrid model that includes elements of several agile methodologies as well as a waterfall, that they identify so completely with the agile movement is a testament to both the strength of the statement and the power of the movement. The versions are quarterly, monthly, weekly, and ultimately daily or even continuously. "If we don't know whether the feature is correct," he noted, "we deliver two versions of it, and let the users decide." This is the embodiment of continuous delivery or DevOps. Agile processes are a compulsory first step direction, but continuous delivery requires even more radical change. It means that developers try something based on their best knowledge at the time yet are fully prepared to remove or change it immediately based on user responses not coming in the form of words but as actions. Monitoring the application in production and collecting data on user behavior. Real-time analysis of that data tells the team what to do next. And what happens next will take only a couple of days.
Agile is the most popular development methodology and the approach of choice for many development teams, especially those involved to generate an environment of continuous delivery. Now Agile is understood as having high levels of collaboration and flexibility and an iterative environment in which requirements evolve alongside changing needs. Resultantly, ?we also tend to conceptualize Agile as an approach that helps development teams across various industries deliver new features faster. Just for a solution waiting for years to key problems of business facet. Less than 30 years ago, that type of wait time was the norm. And we can trace the earliest roots in the history of Agile to this problem.?Before Agile came about, development teams (particularly those in the software, manufacturing, aerospace, and defense industries) would identify problems and plan a solution. They would then work to develop that solution and bring it to market in its entirety. Specifically, most teams used the Waterfall approach, a development methodology that follows a set path in which teams: Set project requirements and the scope of work, design a product based on those pre-determined requirements, Build the product, Test the product, Fix any problems discovered during testing, and Launch a finished product. Though it looks effective, Waterfall required teams to stick to the requirements and scope of work set out at the very beginning of the project and not make any changes or additions along the way. And following that fixed plan could prove troublesome, since Waterfall prioritized bringing a complete product to market – meaning it could take years before teams finished the project at hand. But, the nature of the problem would often change (but the project requirements would not), rendering the planned solution out of date by the time it finally got to market. On the customer side, this delay meant that critical problems would go unsolved for years at a time. And even when a solution became available, the problem it was intended to solve had likely changed in nature. As a result of these challenges, we can consider the Waterfall methodology the antagonist in the history of Agile.
During this time, we saw the introduction of development methods like Scrum, Rapid Application Development, Extreme Programming, DSDM, Feature-Driven Development, and Pragmatic Programming. While these methods vary, the common thread among all of them is a lighter-weight model that allows for more flexibility and less overhead planning. These methods of software development are the earliest methods in the history of Agile that ultimately led to present knowledge. At last, by the 2000s, the history of Agile and the future of advancement transformed forever. Its foundation was underway in the spring of 2000, ?a group of 17 software developers, including Martin Fowler, Jim Highsmith, Jon Kern, Jeff Sutherland, Ken Schwaber, and Bob Martin met in Oregon to deliberate how they could fasten development times short to introduce new software in the market. Two vital chances that attaining this goal would make possible: Shortening the delay of benefits to users in order to resolve the product-market fit and development graveyard problems, and Getting feedback from users quickly to confirm the usefulness of new software and continue to improve on it accordingly. Even in the meeting, the solution did not come as an ?Agile methodology, but it was a critical milestone in the history of Agile, as speed to market, rapid feedback, and continuous improvement are hallmarks of the Agile methodology.
A Manifesto that made Agile ?into Focus
Just after that Oregon meeting, the history of Agile came into focus when the same group of 17 developers met again, this time at a ski resort in Snowbird, Utah. During this meeting, they hoped to further expand on their progress and land on a more concrete solution to the major development problems of the time. Within three days, the group produced the “Manifesto for Agile Software Development” (known more commonly as the Agile Manifesto). A true turning point in the history of Agile, this manifesto laid out four key values:
1.?Individuals and interactions over processes and tools
2.?Working software over comprehensive documentation
3.?Customer collaboration over contract negotiation
4.?Responding to change by following a plan
?These four central tenets make up the Agile Manifesto.
These values represent a significant breakthrough in the history of Agile, but the group didn’t stop there. To give even more color to their vision, they also laid out 12 principles that stand behind these values. Those principles include: Satisfying customers through early and continuous delivery of valuable software,?Welcoming changing requirements at any point in the delivery cycle, Delivering software frequently through shorter development timelines, Using working software as the primary measure of progress, and Taking regular moments of self-reflection to identify opportunities for improvement. These four values and 12 principles continue to guide the Agile methodology used presently.
the History of Agile: Agile comes into the mainstream
The history of Agile came a long way during the February 2001 meeting in Snowbird, Utah, but the trajectory of Agile had still only just begun. Following that three-day meeting, the group of 17 leaders was ready for the next chapter in the history of Agile: Convincing the world of the value of everything they laid out in the Agile Manifesto. To aid spread the word about the Agile Manifesto, the founding fathers in the story of the history of Agile decided to create a more permanent organization, and so the Agile Alliance was born. The Agile Alliance?is a nonprofit organization that still exists to date. ?The organization’s goal is to share information about Agile, provide resources for teams looking to adopt the Agile methodology, and continue to evolve the approach to meet changing needs. ?Following the creation of the alliance, the history of Agile took off in a big way, gaining traction with software development teams throughout the early 2000s. Along the way, those teams often contributed to the history of Agile as we know it today, introducing practices like quick decisions, the “role-feature-reason” format for user stories, retrospectives, and daily meetings. As Agile took off, the role of the Agile Alliance expanded. In 2003, the now-formal Agile Alliance returned to Utah for the first annual Agile conference — an important milestone in the history of Agile. The group described this event as being “dedicated to furthering Agile principles and providing a venue for people and ideas to flourish.” This annual conference, named Agile 20XX, continues to date. The Agile Alliance has also expanded geographically over the years. Now, the Agile Alliance assists affiliate groups all over the world that promote Agile in local markets and helps nearby organizations adopt the Agile Manifesto.
The pace of development of Agile got momentum
Agile became popular in the early 2000s, but the Agile Manifesto raised new steam in the 2010s. Therefore, the history of Agile was a commonly recounted story among development teams, but between 2012 and 2015, real-life success metrics began to accompany that story. As a result of the ability to demonstrate success in Agile at that point, the benefits of adopting the lightweight methodology became undeniable. That makes it no surprise that during this three-year period we also saw Agile surpass the 50% mark in adoption, truly taking the development world by storm. The ability to scale Agile across teams led to increased adoption since teams can work together more effectively for continuous delivery. Soon thereafter, Agile began to explode, this time by moving beyond development. In 2017, we saw the first succinct definition of Agile Testing. This definition outlined collaborative testing activities focused on the frequent delivery of quality products that prioritize defect prevention over defect detection.
Transformation of ?Agile for the 2020s
As of 2018, we see near-ubiquitous adoption of Agile in some sense across development teams, particularly those in the software industry. A joke is prevalent that technology is outdated the moment it hits the market which in some cases is fully true. During the earliest parts of the history of agile and the problems, development teams encountered with the waterfall methodology. While no one knows the future, it’s safe to say that the history of Agile is not yet complete. But the next chapter in that history book might look a bit different than what we’ve seen so far. Now, the development of ?DevOps, or the idea of creating a continuous loop of delivery in which new software can go to market at any time and is always ready for production. DevOps is the latest iteration of the idea that high-quality products should be delivered to users the fastest and then improved upon on a regular basis. While it’s easy to think of DevOps as a new approach that will bring Agile to an end, so far this has proven not to be the case. Currently, we see teams embracing Agile and DevOps hand-in-hand, and we can likely expect this trend to continue for the next several years. Even if?no expectations, but surely ?Agile will continue to evolve, embracing its own core values and principles to remain a ubiquitous approach among development teams in the software world and beyond, even as their needs change.
??
?
?
?
?
?
领英推荐
?
?
The History of Scrum: How, when and why
?
?
For over two decades, Scrum is aiding many people successfully develop new products faster and more efficiently. This framework was officially first introduced to the public in 1995 by Jeff Sutherland and Ken Schwaber,, it’s not anything that hasn’t been done before. Made by the above, the formal Scrum model was the result of many years of experiments and learning. Understanding the process behind Scrum development and reasons leading to it, will help you understand?Agile principles, give you a better grasp of Scrum ceremonies and will overall help you view the whole process of product development as the authors intended. Both creators of Scrum, ?fought in the Vietnam war between the years 1967 and 1975. Necessary everyday risk assessment already influenced their way of thinking and naturally affected their later work. Next, they followed similar career paths and stayed in touch.
Ken Schwaber?started his own company in 1985 after working in a corporate environment for nearly ten years. He says the?corporate work created a lot of frustration?for him, as he could never figure out what was wrong or why it was so hard to finish projects successfully and pull people together to work as a team. At the time, roughly 45% of the projects he was working on were successful, and the rest considered somewhat a waste.?People didn’t like their job, and they kept running away, trying to find anything else but only 36% of product features are used.
Schwaber was a waterfall enthusiast and tried to make it work, but he just couldn’t. He knew there’s a?need for change in the industry. In the paper?SDP,?he wrote later explaining waterfall is a method that assumes software development is a well-understood process without any unexpected outcomes or problems. However, that is not true; software development is very unpredictable for multiple reasons.“ We were supposed to do a huge project for one million, but we weren’t sure if we could. So based on our calculations, we predicted we would need two years and four million, but it ended being even more. My point is the?huge uncertainty in development.” Ken Schwaber
Jeff Sutherland?started his career with a dissertation in medicine and complex systems theory. When later in 1986, he became responsible for the ATMs business unit in Saddlebrook Corporation. Beforehand the unit used?traditional project management, which led to late delivery, poor quality, and user dissatisfaction. Sutherland was supposed to fix this. The ATMs unit was problematic and the least profitable branch of the company; in short six months, he brought it up to be the most successful unit.“ Software development is interesting and fun, it should stay that way.” Jeff Sutherland.
He helped the team by teaching them and explained the success with three important methods he brought to the team:?making their work visible, giving a responsibility to the team to fix the problem, and self-organization?of the team to make it all happen. This experience showed him there’s a need for?a new, better approach to development that would produce happy customers, developers, and early projects. “Self-organizing teams just do a better job no matter what they do.” Jeff Sutherland. Looking for a better way, Schwaber later worked with DuPont and was strongly influenced by their advanced process control methods. They advised to shorten the planning period to decrease the risk and instead,?try for a shorter period, see what works and what doesn’t, adjust and do it again. Based on this, Sutherland and Schwaber spent 4-5 years building and researching a new approach to developing software that would be more?flexible, give people more?control, allow the?creative?process to bloom, and would allow controlling the?risk and expense?value. Because software is fun and you do it for fun, but you need to support your family and make the industry.
January 1994: first Scrum team is scrumming
In 1993 Jeff Sutherland was hired into Easel Corporation as Chief Engineer for developing a new product. At the time, they didn’t know what exactly they wanted, but they knew it had to be something faster and better than what is already on the market. Knowing this was a huge challenge, he and the team first reviewed the literature to see what was already done and what could be taken beyond.
They found, according to Sutherland, the best paper in Harvard Business Review,?The new new product development game ?(not a typo, authors chose to emphasize the word?new) by Hirotaka Takeuchi and Ikujiro Nonaka. A paper showing a?new, holistic approach to product development. Authors of this paper compared the new approach to a rugby game – team moving down the field in a scrum formation as a unit. This paper provided Sutherland with a formal model and the name for a new framework created for the IT industry: Scrum.
The first Scrum team was built on principles of Nonaka’s and Takeuchi’s paper. Another important factor for building the team was research from Bell Labs that showed how?specialized silos of activity slowed down the communication?and made teamwork impossible. This resulted in having?as few roles in the team as possible. Starting with the team and the team leader – scrum master, and later adding the product owner role responsible for clearly specifying the backlog. From here, the first Scrum team started scrumming in January 1994.
In 1995, after Easel Corporation was acquired by VMARK,?Schwaber spent two weeks with the Scrum team,?and he agreed to?expand Scrum with Sutherland outside of Easel Corporation into the software industry worldwide.
In 1995 Ken Sutherland and Jeff Schwaber wrote a?paper officially introducing Scrum ?and published it at OOPSLA’95 (Object-Oriented Programming, Systems, Languages and Applications) conference. They both went on to introduce Scrum to multiple companies like Motorola, Fidelity, or GE Medical, and after seeing great results and creating a?community, they co-created Agile manifesto in 2001.
“We’re not going to tell people what to do; the idea is you’re doing creative work, you need guidelines to help you, not constraint you. So why don’t we come up with a bunch of principles and values, alternatives, that might lead you to what you need to do.” Ken Schwaber about creating Agile manifesto
New new product development game and principles that inspired
The paper?New new product development game ?published by Hirotaka Takeuchi and Ikujiro Nonaka in 1984?serves as the formal model for Scrum. In the paper, authors looked at successful companies in Japan and the United States that used a new, holistic method for product development as opposed to older, sequential approach (like the waterfall). Companies like Fuji – Xerox, Canon, or Honda used different principles when developing a product, which pushed them ahead of competitors.
Takeuchi and Nonaka highlight that the new approach they presented can act as a change agent, a vehicle for introducing creative, market-driven ideas and processes into an old, rigid organization. These teams reminded the authors of sports teams, particularly rugby and scrum formation, in which the whole team moves as one, working together towards one goal around any impediments.
Sutherland believed this paper demonstrated exactly what was needed for development in the software industry and used the holistic approach presented as a base to create a set of rules to generate high performing teams. Main characteristics of these teams were:
“Scrum doesn’t solve a problem; it’s a tool used to gain into ?excellence. It will tell by creating transparency in ?organization.” ation, and naturally introduced overlapping development phases to speed up the process.?Scrum framework challenges the old way of thinking. There is a possibility that the outcomes are different than predicted, which requires a fair amount of integrity to keep the transparency, admitting failure, and making decisions around it. Agile is one approach to project management, while Scrum is a type of Agile methodology. Learn more about the key differences in this guide. Though the terms Scrum and Agile being used interchangeably, but ?Scrum and Agile unique. Agile is an approach to project management that emphasizes completing projects in small increments. It is often used for projects where some change or unpredictability is expected. Scrum, on the other hand, is one of several Agile methodologies. Think of it more as the actual structure teams can use to put Agile principles into practice.?Scrum is a popular Agile methodology and its use is increasing.
What is Agile?
Agile is an approach or philosophy to project management that aims to achieve a goal in small increments. So instead of having one large reveal or launch, an Agile project comprises smaller chunks of tasks that can be delivered in shorter time frames continuously. This makes it easier for project teams to adapt to changing priorities, respond to problems that arise, and cut down on cost, time, and inefficiencies. In order to incorporate Agile principles into a company or project, you’ll want to use a framework, or a certain method, to put them into play. The most popular of these is Scrum. Others include Kanban, the Crystal Method, Extreme Programming, plus several hybrids. Scrum is an Agile methodology that is designed to develop products in an environment susceptible to change.?
In Scrum, delivery cycles are called “sprints,” and generally last one to four weeks. Work is incremental and builds on previous work. Scrum teams are usually small, typically ranging from three to nine people, and include a?Scrum master?and a product owner. Communication with team members and stakeholders is consistent so that feedback is constant and changes can be made accordingly.
Scrum is the most commonly used Agile methodology. About 66 percent of Agile users implement Scrum, while 15 percent use derivatives of Scrum, Scrumban, and Scrum/XP, according to the State of Agile report released in 2021..
?
?
?
?
?
?
CONCLUSION
Scrum is a refined version of Agile in the context of software development. Scrum has three pillars : Transparency, Adaptation, and Inspection.?The team strives to continuously improve the product and the process. It has five values : Courage, Focus, Commitment, Respect, and Openness. Scrum is a framework for developing , delivering, and?sustaining complex products
.
Scrum is excellent for dealing with complex projects in changing environments. Like many Agile methodologies, Scrum is good for industries that are constantly in flux, or for pioneering new projects. If you’re dealing with fixed requirements, or an organization that doesn’t allow for smooth cross-functional collaboration, a more traditional approach may be better. Scrum is a part of the wider Agile umbrella; Agile is an approach to project management, and Scrum is a method you can use to implement it. There are a few parts of Scrum that are reflective of Agile principles, and several points that make it unique within the philosophy.?
Similarity between Scrum and Agile : Short-term development cycles, Focus on people, collaboration, and communication, and Capacity to adapt to changes and feedback.
The difference between both methodologies: Work is organized into sprints that last one to four weeks, A product backlog keeps a record of what work needs to be done, Roles are divided into Scrum master, product owner, and development team, and Team members have a short “daily Scrum” update meeting.