When and why do we need agile
•Download as PPTX, PDF•
1 like•596 views
The document discusses when and why Agile is needed. It outlines the Agile Manifesto created in 2001 which established 12 principles for Agile software development including early delivery of working software, welcoming changing requirements, and self-organizing teams. Scrum is described as one of the most commonly used Agile frameworks with its own set of values like openness, commitment, focus, respect and courage.
More Related Content
What's hot
What's hot (18)
Viewers also liked
Viewers also liked (14)
Similar to When and why do we need agile
Similar to When and why do we need agile (20)
More from Luxoft
Recently uploaded
Recently uploaded (20)
When and why do we need agile
- 1. When and why do we need Agile? Agile is not a “silver bullet”. www.luxoft.com
- 2. What Is Agile? What Is Scrum? www.luxoft.com
- 3. 2001 – Agile Manifesto www.luxoft.com
- 4. Agile Manifesto www.luxoft.com http://agilemanifesto.org/
- 5. Principles behind the Agile Manifesto 1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. 2. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage. 3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. 4. Business people and developers must work together daily throughout the project. 5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. 6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. 7. Working software is the primary measure of progress. 8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. 9. Continuous attention to technical excellence and good design enhances agility. 10. Simplicity--the art of maximizing the amount of work not done--is essential. 11. The best architectures, requirements, and designs emerge from self-organizing teams. 12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly. www.luxoft.com
- 7. Scrum Values and Principles www.luxoft.com Openness Commitment Focus Respect Courage http://www.scrum.org/
- 9. Agile. When and why? www.luxoft.com
- 13. Cynefin Framework www.luxoft.com PMI, Prince2 Waterfall Scrum All is good
- 16. Knowledge. Late Learning www.luxoft.com
- 17. Usage Of Features and Functions in Typical System www.luxoft.com
- 20. www.luxoft.com 15 December 2014
Editor's Notes
- This is not detailed presentation of Agile methodologies of software development. I will just give the overview about Agile. This will help us to be on the same page.
- So the main artifact of agile software development is Agile Manifesto, which was created by 17 thinkers. Each of them has His own methodology, which helps them to create successful teams and products. On the historic meeting to be held on February 2001 at “The Lodge” at Snowbird ski resort in the Wasatch Mountains of Utah. Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Bob Martin, Stephen Mellor, Ken Schwaber, Jeff Sutherland, and Dave Thomas they all combined all best of their principles in one manifest.
- As you see in agile there are only 4 values and 12 principles. It is more ideology, rather than book with detailed roles and process descriptions. On these core values and 12 values are based different process frameworks: Extreme Programming , Crystal Clear, Scrum and others. So Scrum become the most widespread framework for the Agile implementation.
- Scrum has it’s own values and principles based on Agile Manifesto. From 16 pages of Scrum Guide you can get more details about values, roles and thу process itself. Scum guide is avaliable on scrum.org Scrum is most often used to manage complex software and product development incremental practices. Scrum significantly increases productivity and reduces time to market .Scrum processes enable organizations to adjust smoothly to rapidly-changing requirements, and produce a product that meets evolving business goals. So to cut a long story short scrum is lightweight framework based on iterative development, where requirements and solutions evolve through collaboration between self-organizing cross-functional teams and stakeholders.
- I’ll give you short overview of Scrum’s Roles,Artifacts and Meetings. So Let’s start from roles. The Product Owner is the single individual who is responsible for drawing out the most valuable possible product by the desired date. This is done by managing the flow of work into the team, selecting and refining items from the Product Backlog. The Product Owner maintains the Product Backlog and ensures that everyone knows what is on it and what the priorities are. The Product Owner may be supported by other individuals but must be a single person. The Product Owner is typically the individual closest to the "business side" of the project. The Product Owner is typically charged by the organization to "get this product out" and is typically the person who is expected to do the best possible job of satisfying all the stakeholders. The Product Owner does this by managing the Product Backlog, and by ensuring that the Product Backlog, and progress against it, is kept visible. The Product Owner, by choosing what the Development Team should do next and what to defer, makes the scope versus schedule decisions to lead to the best possible product. The Development Team is made up of the professionals who do the work of delivering the Product Increment. They self-organize to accomplish the work. Development Team members are expected to be available to the project full time. Scrum requires that the Development Team be a cross-functional group of people who, among them, have all the necessary skills to deliver each increment of the product. The Development Team members have the responsibility to self-organize to accomplish the Sprint goal, producing each new Product Increment according to each Sprint Plan. The ScrumMaster is a "servant leader," helping the rest of the Scrum Team follow their process. The ScrumMaster must have a good understanding of the Scrum framework and the ability to train others in its subtleties. The ScrumMaster works with the Product Owner to help the Product Owner understand how to create and maintain the Product Backlog. He works with the Development Team to find and implement the technical practices that will allow them to get to done at the end of each Sprint. He works with the whole Scrum Team to evolve the Definition of Done. Another responsibility of the ScrumMaster is to see that impediments to the team’s progress are removed. These impediments may be external to the team, such as a lack of support from another team, or internal, such as the Product Owner not knowing how to properly prepare the Product Backlog. The ScrumMaster fosters self-organization. Issues should be removed by the team wherever possible. The Product Backlog is an essential artifact in Scrum. The Product Backlog is an ordered list of ideas for the product, kept in the order we expect to do them. It is the single source from which all requirements flow. This means that all work the Development Team does comes from the Product Backlog. Every feature idea, enhancement, bug fix, documentation requirement -- every bit of work they do -- is derived from a Product Backlog item. Each item on the Product Backlog includes a description and an estimate. The Product Owner is responsible and accountable for maintaining the Product Backlog, although the Product Owner may -- and should -- have help in producing it and keeping it up to date. Product Backlog items may originate from the Product Owner, from team members, or from other stakeholders. Since Product Backlog Items are quite often large and general in nature, and since ideas come and go and priorities change, Product Backlog Refinement is an ongoing activity throughout a Scrum project. This activity includes but is not limited to: Keeping the Product Backlog ordered. Removing or demoting items that no longer seem important. Adding or promoting items that arise or become more important. Splitting items into smaller items. Merging items into larger items. Estimating items. Each Sprint begins with a timeboxed meeting called Sprint Planning. In this meeting the Scrum Team collaborates to select and understand the work to be done in the upcoming Sprint. The entire team attends the Sprint Planning meeting. Working from the ordered Product Backlog, the Product Owner and the Development Team Members discuss each item and come to a shared understanding of that item and what is required to complete it consistent with the current Definition of Done. All Scrum meetings are timeboxed. The recommended time for the Sprint Planning meeting is two hours or less per week of Sprint duration. Because the meeting is timeboxed, the success of the Sprint Planning meeting is highly dependent upon the quality of the Product Backlog going in. This is why Product Backlog Refinement is an important Scrum activity. In Scrum, the Sprint Planning meeting is described as having two parts: Determine what work will be completed in the Sprint. Determine how the work will be accomplished. Sprint Planning concludes with the Scrum Team coming to a common understanding of the quantity and complexity of what is to be accomplished during the Sprint, and, within a rational range of circumstances, expecting to complete it. The Development Team forecasts the amount of work they will complete and commits to each other to accomplish it. To sum up, in the Sprint Planning Meeting, the Development Team: Considers and discusses Product Backlog Items with the Product Owner. Ensures that they understand them. Selects a number of items that they forecast they can accomplish. Creates a sufficiently detailed plan to be sure they can accomplish the items. The resulting list of things to do is the "Sprint Backlog". The Sprint Backlog is the list of refined Product Backlog items chosen for development in the current Sprint, together with the team's plan for accomplishing the work. It reflects the team's forecast of what work can be completed. With the Sprint Backlog in place, the Sprint begins, and the Development Team develops the new Product Increment defined by the Sprint Backlog. During the Sprint, the Development Team self-organizes to produce a Product Increment in accord with the Sprint Backlog, as determined during Sprint Planning. Self-organizing means that the team responsibly produces the Product Increment in accord with all the organization's standards, according to the Definition of Done, and that the Development Team determines just how to go about that. The Development Team is self-organizing. The Development Team uses the Daily Scrum meeting to ensure that they are on track for attaining the Sprint Goal. The meeting takes place at the same time and place every day. Each Development Team member gives three bits of information: What I have accomplished since our last Daily Scrum. What I plan to accomplish between now and our next Daily Scrum. What is impeding my progress. There may be brief clarifying questions and answers, but there is no discussion of any of these topics during the Daily Scrum. However, many teams meet right after the Daily Scrum to work on any issues that have come up. The Daily Scrum is not a report to management, nor to the Product Owner, nor to the ScrumMaster. It is a communication meeting within the Development Team, to ensure that they are all on the same page. The most important Scrum artifact is the Product Increment. Every Sprint produces a Product Increment. The Product Increment must be of high enough quality to be given to users. The Product Increment must meet the Scrum Team's current Definition of Done, and each component of it must be acceptable to the Product Owner. At the end of the Sprint, the Scrum Team and stakeholders review the output of the Sprint. All Scrum meetings are timeboxed. The recommended timebox for the Sprint Review is one hour per week of Sprint duration. The central point of discussion is the Product Increment completed during the Sprint. Since the Stakeholders are those who have a "stake" in the results, it is generally wise and helpful for them to attend this meeting. This is an informal meeting to take a look at where we are and to collaborate on how we might go forward. Everyone has input at the Sprint Review. Naturally, the Product Owner makes the final decisions about the future, updating the Product Backlog as appropriate. At the end of each Sprint, the Scrum Team meets for the Sprint Retrospective. The purpose is to review how things went with respect to the process, the relationships among people, and the tools. The team identifies what went well and not so well, and identifies potential improvements. They come up with a plan for improving things in the future. All Scrum meetings are timeboxed. The recommended timebox for the Sprint Retrospective is one hour per week of Sprint duration. The Scrum Team improves its own process, always remaining within the Scrum framework. The Scrum cycle repeats from here, for every Sprint.
- So, first of all let’s start from complexity theory. Complexity theory is rather new theory, which is used in philosophy, biology, cybernetics. Right now I’ll speak about cynefin framework. It was created by David Snowden. 3 basic systems:
- Created additional system Disorder And devided orded system in 2: simple and complicated
- Simple domain is an ordered system. So, cause and effect relationships exist, are predictable and are repeatable In simple order that relationship is self-evident to any reasonable person. As a result the decision model is sence – categorize –respond. We see what’s coming in we make it fit previously in categories, we decide what to do. And as a result we apply a best practice In the complicated domain cause and effect relationships exist but are not self evident, and therefore requires expertise. So we have to deploy an analytical method. And sense-analyze-respond will call in experts who have buid build an expertise within that domain and who can make the right decision. So, here we apply good practice. The distinction between good practice and best practices actually quite important. In complicated domain there are several different ways of doing things all of which Legitimate if you have the right expertise and trying to force people to adopt one of them is actually quite dangerous. You’re basically piss people off, to be honest, to the point where they won’t apply best practices which should be applied. Complexity on the other hand is a system without causality. It’s a system move like constraints an agents, agents modify the system. So, cause and effect are only obvious after it has happened with unpredictable emergent outcomes. So a decision model here is probe-sense-respond. We conduct a failed experiments. We don’t do fail safe design. If experiment succeeds we become better. If experiment starts to fail we stop it. If we don’t even do an experiment we can’t identify our strategies in advance. Because what happens here we have an emergent practices. We use absolutly new ways of doing things. In Chaotic no cause and effect relationships can be determined. So if we entered accidentally then we need to stabilize the position quicly. Soa decision model is act-sence- respond. We move very quicly to stabilize the situation. Any practice will be complitly novel And a central space is disorder. It’s a space of not knowing where we are now Ok. Let’s try to look on software development using knowledge about this framework. In a simple domain the best solution is waterfall. There is no anything more effective than this. The process is described in details, categorized, it is best practice. Use something else to achieve the goal in such systems is waste of time
- Ok. Let’s try to look on software development using knowledge about this framework. In a simple domain the best solution is waterfall. There is no anything more effective than this. The process is described in details, categorized, it is best practice. Use something else to achieve the goal in such systems is waste of time In complicated domain there is a word of experts. Here is usefull project management practices and approaches, such as PMI. Prince and others. If you want to build a bridge, ask engineers how to do this and use their years of experience, Take a look in “know-how” book and make it right. In complex domain there is no right way. We have to conduct experiments inside sprints and to confirm or disprove your hypothesis. Often change direction depending on your set of experiments. In chaotic domain all is good. If you would like to invite a dictator, he will create in your organization simplicity and order and will move you into simple domain Or invite a person with vision, who will be open to the perception of different opinions and will use the crisis to try to create innovations. This will move your into complex domain. So, different situations require different tools and use Scrum to solve all problems is as silly as trying to do everything using waterfall.
- PLAN Establish the objectives and processes necessary to deliver results in accordance with the expected output (the target or goals). By establishing output expectations, the completeness and accuracy of the spec is also a part of the targeted improvement. When possible start on a small scale to test possible effects.DOImplement the plan, execute the process, make the product. Collect data for charting and analysis in the following "CHECK" and "ACT" steps. CHECK Study the actual results (measured and collected in "DO" above) and compare against the expected results (targets or goals from the "PLAN") to ascertain any differences. Look for deviation in implementation from the plan and also look for the appropriateness and completeness of the plan to enable the execution, i.e., "Do". Charting data can make this much easier to see trends over several PDCA cycles and in order to convert the collected data into information. Information is what you need for the next step "ACT". ACT Request corrective actions on significant differences between actual and planned results. Analyze the differences to determine their root causes. Determine where to apply changes that will include improvement of the process or product. When a pass through these four steps does not result in the need to improve, the scope to which PDCA is applied may be refined to plan and improve with more detail in the next iteration of the cycle, or attention needs to be placed in a different stage of the process.Note: Some modern trainers now also refer to the "A" as "Adjust". This helps trainees to understand that the 4th step is more about adjusting/correcting the difference between the current state and the planned state instead of thinking that the "A" is all about action and implementation (which actually happens in the second ("D") stage).
- Do you remenber I was spoken about disorder domain in cynefin framework. It’s a space of not knowing where we are now So, let’s look on traditional late learning sequence.t is growth of knowledge with big-bang delivery approach.
- PLAN Establish the objectives and processes necessary to deliver results in accordance with the expected output (the target or goals). By establishing output expectations, the completeness and accuracy of the spec is also a part of the targeted improvement. When possible start on a small scale to test possible effects.DOImplement the plan, execute the process, make the product. Collect data for charting and analysis in the following "CHECK" and "ACT" steps. CHECK Study the actual results (measured and collected in "DO" above) and compare against the expected results (targets or goals from the "PLAN") to ascertain any differences. Look for deviation in implementation from the plan and also look for the appropriateness and completeness of the plan to enable the execution, i.e., "Do". Charting data can make this much easier to see trends over several PDCA cycles and in order to convert the collected data into information. Information is what you need for the next step "ACT". ACT Request corrective actions on significant differences between actual and planned results. Analyze the differences to determine their root causes. Determine where to apply changes that will include improvement of the process or product. When a pass through these four steps does not result in the need to improve, the scope to which PDCA is applied may be refined to plan and improve with more detail in the next iteration of the cycle, or attention needs to be placed in a different stage of the process.Note: Some modern trainers now also refer to the "A" as "Adjust". This helps trainees to understand that the 4th step is more about adjusting/correcting the difference between the current state and the planned state instead of thinking that the "A" is all about action and implementation (which actually happens in the second ("D") stage).
- Tell more about Build-Measure-Learn