Need help with Agile or Scrum? CLICK HERE to lớn speak lớn an expert today!
Agile software development refers to lớn software development methodologies centered around the idea of iterative development, where requirements & solutions evolve through collaboration between self-organizing cross-functional teams. The ultimate value in Agile development is that it enables teams lớn deliver value faster, with greater quality and predictability, and greater aptitude to lớn respond lớn change. Scrum & Kanban are two of the most widely used Agile methodologies. Below are the most frequently asked questions around Agile and Scrum, answered by our experts.
Bạn đang xem: What is agile?
What is Agile?
Agile software development refers to a group of software development methodologies based on iterative development, where requirements & solutions evolve through collaboration between self-organizing cross-functional teams. Agile methods or Agile processes generally promote a disciplined project management process that encourages frequent inspection and adaptation, a leadership philosophy that encourages teamwork, self-organization and accountability, a set of engineering best practices intended to allow for rapid delivery of high-quality software, and a business approach that aligns development with customer needs and company goals. Agile development refers lớn any development process that is aligned with the concepts of the Agile Manifesto. The Manifesto was developed by a group of fourteen leading figures in the software industry, & reflects their experience of what approaches do và do not work for software development. Read more about the Agile Manifesto. Did you know that Agile can also be applied to lớn hardware projects? Learn about mongkiemthe.com’s revolutionary Agile for Hardware framework.
Get more information & Mural templates to lớn get started with Agile
What is Scrum?
Scrum is a subset of Agile. It is a lightweight process framework for agile development, & the most widely-used one.
A “process framework” is a particular set of practices that must be followed in order for a process to be consistent with the framework. (For example, the Scrum process framework requires the use of development cycles called Sprints, the XP framework requires pair programming, and so forth.)“Lightweight” means that the overhead of the process is kept as small as possible, khổng lồ maximize the amount of productive time available for getting useful work done.A Scrum process is distinguished from other agile processes by specific concepts and practices, divided into the three categories of Roles, Artifacts, and Time Boxes. These and other terms used in Scrum are defined below. Scrum is most often used lớn manage complex software and product development, using iterative and incremental practices. Scrum significantly increases productivity & reduces time khổng lồ benefits relative lớn classic “waterfall” processes. Scrum processes enable organizations to lớn adjust smoothly khổng lồ rapidly-changing requirements, và produce a sản phẩm that meets evolving business goals. An agile Scrum process benefits the organization by helping it to
Increase the quality of the deliverablesCope better with change (and expect the changes)Provide better estimates while spending less time creating themBe more in control of the project schedule & state
What are the benefits of Agile?
Benefits khổng lồ Customer
Customers find that the vendor is more responsive khổng lồ development requests. High-value features are developed and delivered more quickly with short cycles, than with the longer cycles favored by classic “waterfall” processes.
Benefits khổng lồ Vendors
Vendors reduce wastage by focusing development effort on high-value features, và reduce time-to-market relative lớn waterfall processes due khổng lồ decreased overhead và increased efficiency. Improved customer satisfaction translates khổng lồ better customer retention & more positive customer references.
Benefits lớn Development Teams
Team members enjoy development work, and lượt thích to see their work used and valued. Scrum benefits Team members by reducing non-productive work (e.g., writing specifications or other artifacts that no one uses), và giving them more time to vì chưng the work they enjoy. Team members also know their work is valued, because requirements are chosen khổng lồ maximize value lớn customers.
Benefits to product Managers
Product Managers, who typically fill the sản phẩm Owner role, are responsible for making customers happy by ensuring that development work is aligned with customer needs. Scrum makes this alignment easier by providing frequent opportunities lớn re-prioritize work, lớn ensure maximum delivery of value.
Benefits to Project Managers
Project Managers (and others) who fill the ScrumMaster role find that planning và tracking are easier và more concrete, compared to waterfall processes. The focus on task-level tracking, the use of Burndown Charts to display daily progress, và the Daily Scrum meetings, all together give the Project Manager tremendous awareness about the state of the project at all times. This awareness is key lớn monitoring the project, & to catching và addressing issues quickly.
Benefits to lớn PMOs and C-Level Executives
Scrum provides high visibility into the state of a development project, on a daily basis. External stakeholders, such as C-Level executives & personnel in the Project Management Office, can use this visibility to plan more effectively, and adjust their strategies based on more hard information & less speculation.
Scrum does not define just what khung requirements are lớn take, but simply says that they are gathered into the hàng hóa Backlog, và referred khổng lồ generically as “Product Backlog Items,” or “PBIs” for short. Given the time-boxed nature of a Sprint, we can also infer that each set should require significantly less time khổng lồ implement than the duration of the Sprint. Most Scrum projects borrow the “XP” (Extreme Programming) practice of describing a feature request as a “User Story,” although a minority uses the older concept of a “Use Case.” We will go with the majority view here, và describe three reasonably-standard requirements artifacts found in hàng hóa Backlogs.
User Story
| Name: Planner enters new liên hệ into address book, so that one can contact the person later by postal or electronic mail |
| Description: Planner enters standard tương tác information (first và last name, two street address lines, city, state, zip / postal code, country, etc.) into contact-entry screen. One clicks “Save” to lớn keep the data, và “Cancel” to lớn discard data & return khổng lồ previous screen. |
| How to test: Tester enters và saves the data, finds the name in the address book, and clicks on it. One sees a read-only view of the contact-entry screen, with all data previously entered. |
The elements in this User Story are:
Name: The Name is a descriptive phrase or sentence. The example uses a basic “Role-Action-Reason” organization. Another common style, popularized by Mike Cohn, follows the template “As a , I want so that .” The choice of template is less important than having a workable standard of some kind.Description: This is a high-level (low-detail) mô tả tìm kiếm of the need khổng lồ be met. For functional (user-facing) requirements, the mô tả tìm kiếm is put in narrative form. For non-functional requirements, the mô tả tìm kiếm can be worded in any form that is easy khổng lồ understand. In both cases, the key is that the màn chơi of detail is modest, because the fine details are worked out during the implementation phase, in discussions between team members, sản phẩm owners, and anyone else who is involved. (This is one of the core concepts of Scrum: Requirements are specified at a level that allows rough estimation of the work required to lớn implement them, not in detail.)Screens and External Documents: If the Story requires user-interface changes (especially non-trivial ones), the Story should contain or liên kết to a prototype of the changes. Any external documents required to implement the Story should also be listed.How to lớn test: The implementation of a Story is defined to lớn be complete if, và only if, it passes all acceptance tests developed for it. This section provides a brief description of how the story will be tested. As for the feature itself, the description of testing methods is short, with the details khổng lồ be worked out during implementation, but we need at least a summary lớn guide the estimation process.There are two reasons for including the information about how to test the Story. The obvious reason is to lớn guide development of thử nghiệm cases (acceptance tests) for the Story. The less-obvious, but important, reason, is that the Team will need this information in order to lớn estimate how much work is required to lớn implement the story (since chạy thử design và execution is part of the total work).
Story
Not all requirements for new development represent user-facing features, but bởi vì represent significant work that must be done. These requirements often, but not always, represent work that must be done to support user-facing features. We gọi these non-functional requirements “Technical Stories.” Technical Stories have the same elements as User Stories, but need not be cast into narrative form if there is no benefit in doing so. Technical Stories are usually written by Team members, & are added to the hàng hóa Backlog. The product Owner must be familiar with these Stories, and understand the dependencies between these and User Stories in order khổng lồ rank (sequence) all Stories for implementation.
Defect
A Defect, or bug report, is a description of a failure of the sản phẩm to behave in the expected fashion. Defects are stored in a bug-tracking system, which may or may not be physically the same system used lớn store the hàng hóa Backlog. If not, then someone (usually the hàng hóa Owner) must enter each Defect into the product Backlog, for sequencing and scheduling.
The three roles defined in Scrum are the ScrumMaster, the sản phẩm Owner, and the Team (which consists of Team members). The people who fulfill these roles work together closely, on a daily basis, to lớn ensure the smooth flow of information and the quick resolution of issues.
ScrumMaster
The ScrumMaster (sometimes written “Scrum Master,” although the official term has no space after “Scrum”) is the keeper of the process. The ScrumMaster is responsible for making the process run smoothly, for removing obstacles that impact productivity, và for organizing & facilitating the critical meetings. The ScrumMasters responsibilities include
Teach the hàng hóa Owner how to lớn maximize return on investment (ROI), & meet his/her objectives through Scrum.Improve the lives of the development Team by facilitating creativity và empowerment.Improve the productivity of the development Team in any way possible.Improve the engineering practices và tools so that each increment of functionality is potentially shippable.Keep information about the Team’s progress up lớn date & visible khổng lồ all parties.In practical terms, the ScrumMaster needs lớn understand Scrum well enough khổng lồ train & mentor the other roles, và educate & assist other stakeholders who are involved in the process. The ScrumMaster should maintain a constant awareness of the status of the project (its progress khổng lồ date) relative to the expected progress, investigate & facilitate resolution of any roadblocks that hold back progress, và generally be flexible enough lớn identify and deal with any issues that arise, in any way that is required. The ScrumMaster must protect the Team from disturbance from other people by acting as the interface between the two. The ScrumMaster does not assign tasks to Team members, as task assignment is a Team responsibility. The ScrumMaster’s general approach towards the Team is to encourage & facilitate their decision-making and problem-solving capabilities, so that they can work with increasing efficiency & decreasing need for supervision. The goal is lớn have a team that is not only empowered to make important decisions, but does so well and routinely.
download the Scrum Master Role Cheatsheet
Product Owner
The product Owner is the keeper of the requirements. The sản phẩm Owner provides the “single source of truth” for the Team regarding requirements và their planned order of implementation. In practice, the product Owner is the interface between the business, the customers, và their sản phẩm related needs on one side, & the Team on the other. The hàng hóa Owner buffers the Team from feature and bug-fix requests that come from many sources, and is the single point of liên hệ for all questions about product requirements. Product Owner works closely with the team khổng lồ define the user-facing & technical requirements, to document the requirements as needed, & to determine the order of their implementation. Sản phẩm Owner maintains the product Backlog (which is the repository for all of this information), keeping it up to lớn date và at the level of detail and chất lượng the Team requires. The hàng hóa Owner also sets the schedule for releasing completed work lớn customers, và makes the final điện thoại tư vấn as khổng lồ whether implementations have the features and chất lượng required for release.
download the hàng hóa Owner Role Cheatsheet
Team
The Team is a self-organizing & cross-functional group of people who vị the hands-on work of developing and testing the product. Since the Team is responsible for producing the product, it must also have the authority to make decisions about how to lớn perform the work. The Team is therefore self-organizing: Team members decide how to lớn break work into tasks, và how lớn allocate tasks lớn individuals, throughout the Sprint. The Team kích thước should be kept in the range from five lớn nine people, if possible. (A larger number make communication difficult, while a smaller number leads lớn low productivity and fragility.) Note: A very similar term, “Scrum Team,” refers to the Team plus the ScrumMaster và Product Owner.
download the Scrum Team Cheatsheet
What to lớn measure in agile is the enduring question. There should be two primary filters we should ask ourselves before we measure anything; “will this measurement accelerate value delivery?,” và “will this measurement enhance trust?”.
Below is an example of a fitting agile measurement. Typically an organization will create a goal lớn increase story point velocity, và this seems rational because we always strive khổng lồ deliver more where possible. This perspective is looking at the problem from the wrong angle because what we want is value delivery not higher output. Those are not the same; one is outcome focused, & the other is production focused. Agile stresses outcome; which is value delivery, not output. Looking through the lens that equates increases in velocity to output đầu ra assumes a few things; the teams are not working hard enough, and that output đầu ra equals value. Of which both assumptions are typically untrue.
We should be using velocity lớn run our business; a story point velocity can be used to divide the product backlog and plan roughly when specific features will be available for our customers. What we need to do is incent stability in velocity, not velocity that is changing or in flux. In a world where there are incentives for increasing velocity, the teams will oblige và provide a higher story point velocity. They will inflate the story points to lớn achieve the desired increase, which in turn reduce our ability to lớn run the business because the velocity is no longer meaningful.
Addressed in a slightly different way we could measure the say/do of the sprint. Evaluating a team’s estimate of how many story points they will deliver against what they perform in a sprint. Immediately the incentive causes stability in story point velocity, which provides the ability for the business khổng lồ predict when features will release khổng lồ market.
The former tells the teams they are not trusted, and erodes the creation of value delivery where the latter promotes both. It also catches teams doing good as their estimates start to converge lớn performance, moving khổng lồ say/do of zero gives the business the ability to take the velocity lớn the ngân hàng as well as build trust within the organization. Everybody wins; our customers, our organization, & the team.
Sample Operational Metrics
Lead TimeCycle TimeBurndown ChartsSample đầu ra Metrics
ThroughputAgility Assessment ModelTechnical quality / defect measurements / code coverage# of features, etc.Sample Outcome / Value Metrics
Team MoraleCustomer Satisfaction / NPSBusiness ValueTake a look at these articles for more info on Agile Metrics:
People Metrics: How Annual Performance review Enable Bad BehaviorsValidating Agile with Performance MetricsAre you Misusing Metrics in Agile và Scrum?Metrics in Project ManagementThere are two dimensions to lớn this question. Having teams with remote team members and having all local teams where the teams are intact but in different geographical locations. Avoid the former at all costs.
Xem thêm: Cách Nuôi Dạy Chó Becgie Đứng Và Đi Theo Chủ Tại Nhà, Huấn Luyện Chó Becgie, Malinois Chuyên Nghiệp
Intact teams in different geographical locationsAs with all problems, context is a primary constraint to solving this predicament. Companies that embrace these organizational attributes achieve best results; trust, & pulling the decisions to the place where the information exists. The people doing the work have the information; therefore this is a circumstance that should be left for the teams khổng lồ solve themselves. The organization needs khổng lồ trust, fund and tư vấn ideas coming from the teams regarding this difficulty.
The organization needs to support experimentation lớn all problem solving because that takes failure out of the conversation. Experiments require a known state, the desired state, & activities that move toward the desired state. Allow the teams lớn experiment, evaluate, & adjust to the new found learning resulting from that experience. Then be prepared to tư vấn a different approach & another experiment.
Having teams with remote team membersHaving distant team members sucks for everyone. The communication disturbance is substantially worse which causes lack of awareness related lớn building products.
The soundest way to khuyễn mãi giảm giá with this is to create all teams with local people. Challenge your thinking, assumptions, & constraints if colocated teams are not possible. As a last resort following the path described above should make the best of a terrible situation.
Helpful Resources:
Managing Distributed Teams
Daily Scrums in a Distributed WorldDistributed teams can now build faster with Bitbucket
Agile development at the team or small organization cấp độ has emerged over the last 20 years as a really powerful way lớn improve delivery, engagement, & quality. Successfully và repeatably Scaling agile to medium and large organizations has been a problem, though. The Scaled Agile Framework (SAFe) has emerged as the leading solution khổng lồ that problem. SAFe is a collection of principles, structures, and practices that has been shown to lớn consistently and successfully scale Agile practices và deliver the benefits of Agile khổng lồ organizations that had been working in waterfall or ad-hoc methodologies. Get a deep dive into SAFe by taking our Leading SAFe Training Course.
Helpful Resources10 Steps to lớn Launching your First SAFe Agile Release Train5 Steps lớn Transforming your Transformation Approach: Applying SAFe Principles & Concepts to lớn a Scaled Agile Framework (SAFeTM) TransformationWhile Agile & DevOps started as independent methodological movements, they tóm tắt a number of traits focused on improving the efficiency & speed of teams. As organizations become more Agile & refine their project management skill sets, they increasingly depend on technical teams being able lớn keep pace và maintain a certain flexibility.
This is where DevOps comes in as the “yang” to lớn Agile’s “yin”. The DevOps approach helps development groups utilize new tools, automation, & different cultural strategies lớn change not just how they work themselves, but how they work with others. It becomes a symbiotic relationship where sản phẩm teams work hand in hand with developers and testers & the like to ensure everyone has more contextual awareness. This promotes a greater overall unique of deliverables in a shorter period of time.
Helpful ResourcesContested Development: Finding Pragmatism in Agile & DevOps2017 State of DevOps ReportSplunk’ing JIRA for Deep Insights Into Application, Database, và Server Health Trends
Scrum is the dominant team based flavor of agile used today, it is over twenty years old & is time-tested. That said Kanban has its origins in manufacturing & Toyota applied it in 1953, another long-lived approach. Then there are various flavors of scaling frameworks lớn consider if organizational kích thước is one of your contexts.
Context is primary khổng lồ the answer. What commercial needs challenge your business? What size is your organization? How is your company organized? Are your core product teams dispersed in many geographical locations? Therefore the actual commercial problems your business faces and the way you respond lớn your customers are contextual to lớn the answer.
Asking the question, “Scrum, Kanban or another agile flavor” is the first step và an excellent place khổng lồ start. Considering a shift toward an agile approach is the first step toward sustainability. As described above agile is a requirement for future success, it is not new. Those organizations that bởi not adopt some size of agile will not be responsive to customer & market needs and are significantly disadvantaged.
Helpful Resources:
3 Differences Between Scrum và Kanban You Need khổng lồ KnowA Peek Inside Agile: Scrum & KanbanIs My Project Suitable for Kanban or Scrum?Scaling agile is one of the most challenging issues to solve because there are so many variants of how organizations are structured and their commercial needs are diverse. This awareness brings into focus the notion of context.
Because of that diverse variance, there have emerged many scaling frameworks, and the notion of, “one-size fits all” is a false premise. Scrum is the dominant team framework; therefore, most scaling frameworks have Scrum at their core. Using Scrum as the basis to lớn solve scaling problems is sound because most of them địa chỉ cửa hàng to extend as a technique. As an example, the SAFe scaling frameworks introduce Kanban khổng lồ facilitate the scaling challenges while keeping Scrum at its core.
The critical issues to consider when scaling beyond the team dynamic are; coordination, communication, shared or dependent work, và remoteness of groups or team members. These limitations are the same constraints at the team implementation of Scrum; however, as teams increase in numbers, they become amplified & extremely more difficult to solve. As an organization moves from one-team to multi-teams structure, broader issues become apparent. They tend lớn be the roadmap và investment rations between competing initiatives to support the vision và goals of the business.
Organization kích cỡ also plays into the implementation and adoption of the scaling efforts as well as the scaling framework selected. A business of three hundred employees & an organization of tens of thousands employees require different approaches. Again illustrating the “one-size fits all” idiom.
To be sure the organizational scaling of Scrum is a whole company activity, not something isolated to hàng hóa management and engineering as often occurs with Scrum implementations.
Learn more about scaling Agile
Helpful resources
Often when an organization adopts agile, the focus is on the engineering services group with some marginal collaboration with the product management department. This pattern is pervasive & typically explains why businesses bởi vì not feel that they receive the benefits they expect from an agile adoption, furthering the conjecture that agile does not work.
Commercial needs, company size, organizational structure, and a host of other considerations create the context needed to frame an approach to agile adoption. By far the leading success system requires the inclusion of all aspects of the business. System thinking, that of understanding that all domains of the company accomplish value delivery are aligned and working together. Therefore to lớn ask the engineering department with some tư vấn from the sản phẩm management department become agile misses the mark.
Unfortunately, the business will more than likely have to lớn consider restructuring and shifting management styles to achieve organizational alignment. Best outcomes happen when the leadership team goes all in with an open mind to the possibilities when they collaborate. Collaborate with a focus on value delivery và working in a supportive way recognizing that they all will reshape in support of those possibilities.
Some examples are when the accounting department transition from Cost Accounting to lớn Lean Accounting. Human resources department considers the moving lớn OKRs & eliminating MBOs and KPIs. The company metrics focus on measurements that correlate khổng lồ value delivery over output.
The best approach when considering an agile adoption relates lớn your organization’s context as described above. Then be inclusive with the leadership team and their areas of focus with an eye khổng lồ accelerated value delivery over output & utilization.
By developing a learning organization with the benefit of a clear purpose and providing an environment where people are trusted.
Learning OrganizationWhat does being a learning organization mean or imply? The fundamental principals of Scrum are inspect, adapt, and transparency. Embedded in the Scrum principles & are present in every sự kiện as feedback loops. They intended lớn have as many learning opportunities as possible & experienced as frequently as possible.
We need khổng lồ involve the entire company in these principles because the higher benefits from agile are dependent on system thinking. System thinking coupled with the focus on value delivery. We desire the measurements that influence the engineering services to lớn be consistent with what drives the business.
Clear PurposeThe organization needs lớn provide a purpose that is bigger than the individuals within the organization, a goal that is larger than the organization itself. It needs to touch at the emotional màn chơi of everyone, and it should be the inspirational reason people want to lớn come to work.
Trusting EnvironmentThe goal is khổng lồ have the ability for everyone lớn experiment and learn. Experimentation is different than merely failing at something. If we construct an experiment, a few things must be defined. A current state, the desired state, and the experiment itself that moves toward the desired state.
Given that phối of constraints, the experiment yields either a supported outcome or a null hypothesis. And both are significant data points that should influence our future behavior.
In conclusion, agile is a company-wide sport, và it is not merely an engineering services activity. Without all three; learning organization, clear purpose, & trusting environment, the effects of agile will be diminished.
Context is essential, the framework for a change as dramatic as altering the way a company operates requires leading the staff through the journey as opposed lớn dragging them. Some critical areas for success are lớn recognize that change is difficult, and an acknowledgment that this endeavor is a human effort.
Embracing the Scrum values of commitment, courage, focus, openness, và respects. & expressing them in ways that the company entirely embraces them, so they become organizationally shared values will promote success.
A dynamic approach to lớn seeking volunteers will surface staff looking for positive change and filter out those opposed to change. This strategy will remove the organizational blockers from the transition because they are not part of the progress toward the new operational method. As time progresses the change begins khổng lồ have visible outcomes; happier staff, innovation grows more pronounced, và value delivery becomes accelerated. Suddenly there becomes momentum as staff, teams, departments, & business units become pulled toward the new operating model of agile.
The issue of scaling agile is monolithic therefore starting at the team, or a few teams are the beginning of the journey which is required. Caution against applying scaling frameworks on day one typically yield less than beneficial results in the long run.
