Your SlideShare is downloading. ×
Agile concepts
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Agile concepts

231
views

Published on

My first contribution to the world

My first contribution to the world

Published in: Technology, Business

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
231
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
10
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Agile Concepts Introduction To Agile Practices Joaquim Ferreira
  • 2. About Me Joaquim Ferreira .NET Engineer @ Truphone Email: joaquimf@truphone.com Profile: http://www.linkedin.com/in /joaquimluisdaluzferreira Certified Scrum Master License 000138872 June 2011 to June 2015
  • 3. Agenda 1 2 3 4 5 6 Agile Manifesto Features When Principles Benefits Differences 7 How 8 Practices 9 Scrum 10 Kanban
  • 4. Agile Manifest Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan http://www.agilemanifesto.org/ Kent Beck Mike Beedle Arie van Bennekum Alistair Cockburn Ward Cunningham Martin Fowle James Grenning Jim Highsmith Andrew Hunt Ron Jeffries Jon Kern Brian Marick Robert C. Martin Steve Mellor Ken Schwaber Jeff Sutherland Dave Thomas
  • 5. 12 Principles Our highest priority is to satisfy the customer through early and continuous delivery of valuable software Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale Business people and developers must work together daily throughout the project Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done The most efficient and effective method of conveying information to and within a development team is face-to-face conversation
  • 6. 12 Principles Working software is the primary measure of progress Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely Continuous attention to technical excellence and good design enhances agility Simplicity--the art of maximizing the amount of work not done--is essential The best architectures, requirements, and designs emerge from self-organizing teams At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly
  • 7. Features Iterative 1. Entire work is distributed in incremental units called iteration: 2. Development time of each iteration is small (couple of weeks) and fixed; 3. Every Iteration is a mini increment of the functionality and is build on top of previous iteration; Feature driven 1. More emphasis is on providing the required features in the application; 2. 80/20 principle is applied to decide the 20% features which would be used 80% of the time ( Pareto Principle ); Active Customer involvement 1. There is lot of client involvement and face-to-face interaction; 2. Every iteration is tested and approved by client; 3. The feedback obtained is implemented in subsequent iterations;
  • 8. Features Priority based delivery 1. Features are prioritized depending on customer need, development risk etc.; 2. High priority features are developed first; 3. After every iteration, the project priorities are re-evaluated; Adaptive 1. The applications that are developed can receive new requirements throughout its development; 2. The goal is not to remove the uncertainty in the very beginning; 3. But is to adapt to the changing needs; Empowered Teams 1. The project teams are generally small and have lot of interaction and communication; 2. Since entire team is actively involved, team is empowered to take decisions; 3. No separate team to manage project;
  • 9. Features People Centric 1. Emphasis is on using the adequately skilled people to do the development than on following the processes; 2. The documentation and other non-development activities are minimized and more time is devoted to development and testing; More disciplined 1. So the process involves lot of team and self discipline thus, it requires highly skilled and organized team members; Rapid development 1. Being rapid, everything has to be delivered correctly first time.
  • 10. Features Simplicity 1. Emphasis is on keeping things as simple as possible and being open to change; Fixed Time 1. Each iteration has a fixed time span in which it is delivered;
  • 11. Benefits For the customer 1. Customer is more actively involved, and gets higher priority; 2. He gets to know regular and frequent status of the application; 3. Requirements are accepted after each iteration; 4. Since the methodology emphasizes rapid delivery, time-to- market is less. So the key functionalities can be available to use sooner; 5. Delivery is defined by fixed timescale. So customer is assured of receiving some functionality by a fixed time period; 6. More Testing is done, so better software quality is delivered;
  • 12. Benefits For the project team • Project teams are involved more actively in all the stages; • The teams collaboratively take the decisions and are more empowered; • Development is Incremental, teams can focus on the specific requirements at any given point of time;
  • 13. Benefits For the project team • More emphasis is on developing the application only; • The teams receive frequent feedback as the testing is integrated; so the rework is reduced; • Less time is spent in gathering requirements as all the requirements are not gathered upfront and are implemented as and when they arise;
  • 14. Benefits For the project team • Less cost of development as rework, management, documentation and other non-development work related cost is reduced; • Teams develop applications collaboratively and in cooperative environment; • So less time is required for planning;
  • 15. Differences Requirements Fixed Evolve AgileTraditional Time & People May Change Fixed Costumer Involvement Before, After Throughout Negotiable Estimates Schedule Testing After Work Integrated Feedback After Work During Concentration On Processes; Reviews Finished Work Focus On Plan On Value Stages Requirements, Design, Code, Test, Feedbacks Plan-Do-Check-Adjust
  • 16. When We use Agile when … We have the customer available. We can split the deliver. The requirements are flexible. The team is skilled enough.
  • 17. When Because we will need Organization support Hierarchy ready to empower teams Culture open to changes Focus on add value to the business Infrastructure and team support Preferable the team and the customer should be co-located Hardware support for continuous integration and other practices Highly skilled & flexible people More & frequent testing
  • 18. How Starts with a kick-off meeting 1. Get requirements and / or feedback; 2. Plan & evaluate priorities; 3. Design; 4. Develop; 5. Test; 6. Document what is done; 7. Deliver; 1 2 3 4 5 6 7 Split the functionalities in small delivers and repeat:
  • 19. Practices Scrum Kanban eXtreme Programing ScrumBan Lean Software Development DynamicSystemsDevelopmentMethods Feature Driven Development
  • 20. Scrum Is an agile process that allows us to focus on delivering the highest business value in the shortest time. Allows us to rapidly and repeatedly inspect actual work. The business sets the priorities. The Teams self-organize to determine the best way to deliver the highest priority features. So that in the end of an iteration anyone can see real work and decide to release it as is or continue to enhance it for another iteration. What
  • 21. Scrum No specific engineering practices prescribed Self-organizing teams Product progresses in a series of month-long “sprints” Requirements are captured as items in a list of “product backlog” Characteristics Uses generative rules to create an agile environment for delivering projects
  • 22. Scrum Sprint Requirements Starts with a kick-off meeting • Scrum projects make progress in a series of “sprints”; • Typical duration is 2–4 weeks or a calendar month at most; • Product is designed, coded, and tested during the sprint; • No changes during a sprint; Design Do Test
  • 23. Scrum Rather than doing all of one thing at a time... … Scrum teams do a little of everything all the time Requirements Design Build Test Requirements Design Build Test
  • 24. Scrum Framework Roles Ceremonies Artefacts
  • 25. Scrum Roles Product Owner Scrum Master Team
  • 26. Scrum Product Owner Starts with a kick-off meeting • Define the features of the product; • Decide on release date and content; • Be responsible for the profitability of the product (R.O.I.); • Prioritize features according to market value; • Adjust features and priority every iteration, as needed; • Accept or reject work results;
  • 27. Scrum Scrum Master Starts with a kick-off meeting • Removes impediments; • Represents management to the project; • Responsible for enacting Scrum values and practices; • Ensure that the team is fully functional and productive; • Enable close cooperation across all roles and functions; • Shield the team from external interferences;
  • 28. Scrum Team Members should be full-time • Teams are self-organizing: • Ideally, no titles but rarely a possibility; • Cross-functional: • Programmers, testers, user experience designers, etc.; • Members should be full-time; • Membership should change only between sprints;
  • 29. Scrum Ceremonies Sprint Planning Sprint Review Sprint Retrospective Daily Scrum
  • 30. Scrum Sprint Planning Meeting Planning Decide how to achieve sprint goal (design) Create Sprint backlog (tasks) from Product Backlog (Features/Stories) Estimate Sprint Backlog in hours.
  • 31. Scrum Daily Scrum Parameters Daily 15-minutes Stand-Up Not for problem solving Just to Inform Only team members and Scrum Master talk Whole world is invited Others may talk if Team allow
  • 32. Scrum Daily Scrum What will you do today ? 1 2 3 Is anything in your way ? What did you do yesterday ? 3Questions
  • 33. Scrum Sprint Review/Demo Members should be full-time • Team presents what it accomplished during the sprint; • Typically takes the form of a demo of new features or underlying architecture; • Informal: • 2-hour prep time rule; • No slides; • Whole team participates; • Invite the world;
  • 34. Scrum Sprint Retrospective Members should be full-time • Periodically take a look at what is and is not working; • Done after every sprint; • Whole team participates: • Scrum Master; • Product owner; • Team; • Possibly customers and others;
  • 35. Scrum Sprint Retrospective Whole team gathers and discusses what they’d like to: Start Doing Continue Doing Stop Doing
  • 36. Scrum Artefacts Product Backlog …Product Increment Sprint Backlog
  • 37. Scrum Product Backlog Members should be full-time • Prioritized list of the functionality to be developed in a product or service; • User stories have emerged as the best and most popular form of product backlog items; • Ideally expressed such that each item has value to the users or customers of the product; • Prioritized by the product owner; • Reprioritized at the start of each sprint;
  • 38. Scrum Sprint Backlog Members should be full-time • The list of tasks identified by the Scrum team during sprint planning; • Its is estimated in Hours; • Individuals sign up for work of their own choosing; • Estimated work remaining is updated daily; • Any team member can add, delete or change the sprint backlog; • Individuals sign up for work of their own choosing;
  • 39. Scrum Product Increment Members should be full-time • In every Sprint is produced one; • Must be of high enough quality to be given to users • Must meet the Scrum Team's current Definition of Done • Each component of it be acceptable to the Product Owner
  • 40. Scrum User Story Members should be full-time • Short, simple description of a feature told from the perspective of the person who desires the new capability; • They typically follow a simple template: • As a <type of user>, I want <some goal> so that <some reason>; • Should contain the conditions of satisfaction for the story be consider done (Acceptance Criteria);
  • 41. Scrum Task Board Members should be full-time • Used to update the changes of state of the tasks during the sprint; • Each story have a row to the board; • Each column represents a state of the work; • The tasks change of state until be finished;
  • 42. Scrum Burn Down Charts Members should be full-time • Show the amount of work remaining either in a sprint or a release: • The Release Burn Down Chart tracks the release remaining work; • The Sprint Burn Down Chart tracks the sprint remaining work; • They determining at a glance whether a sprint or release is on schedule to have all planned work finished by the desired date;
  • 43. Scrum This is Scrum
  • 44. Kanban The Kanban is an agile process based on Lean practices and aims to streamline the development process of a product Means Visual Signaling Visibility into the status of the work and how it is proceeding Shows what is happening on the process. Allowing to detect the problems during the process. Gives more precise direction on how to invest the energy into only the most valuable work What
  • 45. Kanban Change the priorities anytime Visualization of the work flow Deliver anytime No need of iterations Characteristics Optimize Existing Processes Introduction of visualization and the limiting of work-in-progress (WIP) will catalyse change with minimal disruption
  • 46. Kanban Core Principles 1 - Visualize the Workflow Represent the work items and the workflow on a card wall or electronic board; 2 - Limit Work-in-Progress (WIP) Set agreed upon limits to how many work items are in progress at a time; 3 - Measure & Manage Flow Track work items to see if they are proceeding at a steady, even pace; 4 - Make Process Policies Explicit Agree upon and post policies about how work will be handled; 5 - Use Models to Evaluate Improvement Oportunities Adapt the process using ideas from Systems Thinking;
  • 47. Kanban Visualize the workflow Todo InProgres BlockedTest Done
  • 48. Members should be full-time Kanban Visualize the workflow • The card wall should reflects the current work process, with the intent to improve it over time. • Draw columns on the board that represent the activities performed, in the order first performed. • The cards themselves could be sticky notes or index cards. • They may represent features, stories or tasks. • Critical information for a card would be title, reference number, and date it entered the system;
  • 49. Kanban Limit Work In Progress ( W.I.P) Todo InProgres BlockedTest Done W.I.P: 10 W.I.P: 5 W.I.P: 4 W.I.P: 3
  • 50. Members should be full-time Kanban Limit Work In Progress ( W.I.P) • A limit on work-in-progress constrains how many work items can be in each workflow step at a time; • When a work item progresses, a slot opens and a new work item can flow into the workflow step; • A key result of a W.I.P. limit is that blocked work “holds up the line”; • No new work can progress on the workflow step until the block is resolved; • The W.I.P. limit provokes the conversations that lead to improvements;
  • 51. Kanban Limit Work In Progress ( W.I.P) How big a limit ? • W.I.P. limits for workflow steps should be set as an average number of items per person; • Limits should be in the range of one to three items per person, pair or team; Agreed upon limits ? • W.I.P. limits should be agreed upon through consensus with up- and downstream stakeholders and senior function management as well as the development team; • Not every step must have a limit;
  • 52. Kanban Limit Work In Progress ( W.I.P) No W.I.P. limit? Care should be taken when establishing any unlimited on workflow steps !!! • Does not introduce bottlenecks; • Cause excessive transaction; • Cause excessive coordination costs when are made;
  • 53. Kanban Measure And Manage Flow Todo InProgres BlockedTest Done W.I.P: 10 W.I.P: 5 W.I.P: 4 W.I.P: 3 Lead Time
  • 54. Kanban Measure And Manage Flow Lead Time Starts when the request is made and ends at delivery; Is what the customer sees; Cycle Time Starts when work begins on the request and ends when the item is ready for delivery; What the team can influence by itself by changing its work process Reaction Time The time until the work begins on the request. Lead Time Reaction To reduce Lead Times one should reduce Cycle Time. But often the time before the work starts is really long. So this wait time should be reduced also. Cycle Time
  • 55. Kanban Explicit Process policies It is often best to post explicit process policies in a public team area such as next to the card wall Workflow Should agree upon policies regarding: W.I.P Limits Approvals Prioritization Other Process Topics
  • 56. Kanban Use models to evaluate improvement • Womack & Jones on Waste Reduction • Eliyahu M. Goldratt on Theory of Constraints • John Seddon and Peter Senge on Systems Thinking • W. Edwards Deming’s System of Profound Knowledge and specifically his work on variability • Taiichi Ohno (Toyota Production System) on muda, muri and mura. Flow Time Gather data on system performance as: W.I.P Useful models to learn and use may include work from:
  • 57. Kanban Vs Scrum Scrum Kanban Fixed-length iterations Required Optional Commitment to a specific amount of work Required - at the personal daily level and at the team level (per sprint) Optional Metrics for planning process improvement Velocity Lead Time Cross-functional teams Required Optional Item size So it can be completed within one sprint No particular Prescribed diagram type Burn down chart No particular Work-in-progress limits Per sprint Per workflow state
  • 58. Kanban Vs Scrum Scrum Kanban Estimations Required Optional Adding new items to ongoing iteration Not allowed Allowed Sharing sprint backlog/ kanban board Within one team With multiple teams or individuals Prescribed team roles Project Owner, Scrum Master, Team Member No Board life-time Reset after each iteration Persistent Prioritization Requires a prioritized product backlog No
  • 59. How do you work? Kanban Scrum • Your work is often interrupted with new, immediate tasks. • You need to be flexible and highly responsive to changes. • You are unable to lock your backlog for a couple of weeks. • Your work more often involves repeatable tasks than new ones. • You do feature development which relies heavily on stakeholders' feedback. • You can run only one project at a time. Kanban Vrs Scrum
  • 60. What is your team type? Kanban Scrum • You have a small, medium or large team of specialists in the same or related fields. • Your team is small and cross-functional. Kanban Vrs Scrum
  • 61. What is the specificity of your organization? Kanban Scrum • Your organization has low maturity. • You have a limited capability of risk taking, change management and decisions making. • You have time to let the culture and performance evolve and improve. • Your organization is highly mature. • You are capable of assessing risk, managing changes, evaluating alternatives and making good quality decisions. • You can only make changes in your company using shock therapy - revolution in your organizational culture and approach to team and project management Kanban Vrs Scrum
  • 62. Sources Manifesto for Agile Software Development http://www.agilemanifesto.org/ http://www.mountaingoatsoftware.com/ Portions of this presentation are based on the next sources: http://www.indicthreads.com/1439/quick- introduction-to-agile-software-development/ http://refcardz.dzone.com/refcardz/ge tting-started-kanban
  • 63. Questions