Choosing the right agile approach for your organization


Published on

Published in: Technology, Business
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • Logoincycle imageGold ALM partner Since 2002ServicesMVPLocations
  • In a study “Agile Development: Mainstream Adoption Has Changed Agility“, Forrester reported that “35% of respondents stated that Agile most closely reflects their development process”. With the increasing popularity of Agile practices, development teams need to find the right approach that fit their organizational culture as well as their business situation to ensure they get the full benefits of Agile. In this session, we will help you understand the differences between Scrum and Kanban as well as the ability to have a mixed approach. We will then show you how Team Foundation Server and Team Foundation Service can help you support it by leveraging the available process templates.Level 100 Description:Introductory and overview material. Assumes little or no expertise with topic and covers topic concepts, functions, features, and benefits.
  • Won’t cover dev/build/…Other processes are available XP, etc. but won’t be covered today
  • Software development in enterprises and business organizations is a cross-functional undertaking. Barriers and chasms between the cross-functional teams that need to integrate in delivering software are the top impediments that hinder value delivery. Such impediments are usually a manifestation of rigid processes, ineffective collaboration tools, and development practices that do not take advantage of the advances in technology and opportunities to better integrate teams.
  • Adopting Agile – Top 3 reasons 90% percent of respondents said that implementing agile improved their ability to manage changing priorities. More people are also seeing value in terms of project visibility when implementing agile (84% compared to 77% in 2011). In addition, the general perception of agile is up. When asked, "If you could say one thing to your company president about agile, what would you say7" respondents were very positive. Common responses were around cultural change, hiring a knowledgeable ScrumMaster, investing in training, adoption from the top-down, and giving agile enough time to succeed.
  • Individuals and interactions over processes and toolsWorking software over comprehensive documentation Customer collaboration over contract negotiationResponding to change over following a plan Written in 2001We need a different approach to traditional or iterative development project.That is where the Agile principles will helpDiscuss Manifesto and explain that the Scrum process that we will cover is based on these principles
  • Versionone – 7th ANNUAL STATE of AGILE For most, Kanban methodologies including Scrumban were being applied to processes inside the software organization only (61%).
  • Agile process frameworkIf engineering processes are a candy bar, Scrum is the wrapper. Transparency. Visibility. Discard the illusion of control.Based on empirical (based on observation, experience or experiment) management & control process – inspect and adapt feedback loopsPlanning horizons with inspection and adaptation pointsUsed to manage complex projects since 1990Delivers business functionality in 30 days (or less)Piece of software to help business owner re-evaluate what they requested.30 days is ideal cycle.Scalable to distributed, large, and long projectsCMM Level/3 and ISO 9001 compliantDefine CMM and ISO, some folks don’t know what it is.Level 3 is “defined”, level 4 is “quantitatively managed” (VSTS/TFS/Scrum will provide the data but will not provide the complete tools/mechanisms to automate level 4)Extremely simple but very hard3 months to year to get it right.
  • Talk about the different roles. The process is quite different from traditionalSome responsibilities are transferred to the teamCentered on team collaboration Accountable as a teamValue centricChanges are welcomeFrequent delivery - Inspect and adaptEtc.
  • User stories, communication, PO
  • Lithespeed – Certified ScrumMaster Training material
  • TODOAdd concept of a bunch of Sprints equals your Project.==========No change in team: otherwise the velocity will be hard to evaluate.High quality: week 4 is for regression and correctIncrement: something tested usable is delivered.Consider slide on Product Increment
  • Run through the mechanics on running a sprint.Run exercise: Build a product backlog for an infomercial to adopt Scrum.
  • Cover the work remaining on SBI concept and sprint capacity
  • Kanban literally means “visual card,”Pull helps work to flowToyota modelThe process of Kaizen (continuous improvement)Kanban is a transparent, work-limited, value pulling system Use transparent method for viewing work and organize teamLimit WIP and pull work when the team has capacityFind bottlenecks, waste and variability in performanceUsing a Kanban approach in software drops time-boxed iterations in favor of focusing on continuous flow.Theory of constraints: improve the whole vs. one
  • Because we want to deliver (finish) new value quickly (working software), we limit WIPStop starting, start finishingQueue of work, which goes through a number of stages until its done
  • WIP limitsMaximum number of items that are in a state at any instantQueue limitsWork eligible to be pulled vs. work in process
  • David Andersonclass of service, an indicator that speaks to the risk associated with that featureClassifying classes of service are typically defined based on business impactClasses of service will be unique in your project, however here are some examples: Expedite (or “Silver Bullet”), Does the feature need to be delivered by a certain date? Standard e.g. First In First Out (FIFO). Intangible, Is it a nice to have? Is it chargeable?Polices can include; prioritisation, limits, time and risk constraints, order, colours and annotations. As a good guideline you should look to have no more than 6 policies per class of service.Policies will be unique in your project, however here are some examples:Are there any fixed delivery items that need to be pulled now into the Kanban system?  Pull this in preference to other items regardless of priorityIf a request meets a certain criteria then it gets a faster class of service on the board, Expedite / fast track prerequisites, Only 1 expedite request on the whole board, At least 4 standard items, If total WIP is 12 and we have a policy that 50% will be high priority then we want to ensure that 6 items are high priority.
  • Optional: Specific color by requirement typeNo need for USSeparate document for details
  • No prescriptionTeam LeadFacilitateLeadBusiness PlanPrioritizeTeam Member:Complete the tasksDecide on the howTeam workPickedtheirtask
  • Review the BoardMeeting facilitator enumerates work (not people)From right to left (downstream to upstream) to emphasize pullThe board shows the status, we focus on the exceptions:Any bottleneck?Any impediments?Are we keeping within WIP limits?Is the prioritization clear?
  • The After Daily Stand-Up Review issues/blocks/improvement ideas(Input) Queue ReplenishmentPrioritization by the business Should include team lead(s)Frequency based on Lead Time, so could be demand-drivenRelease Planning MeetingsFrequency based on Lead TimeWhat is ready? What is required? …Outcome is release plan Triage (aka Grooming)Issue log review and Escalation
  • Planning and releasing activities are de-coupledIterative development without iterationKanban Retrospective is leading vs. lagging
  • Both scrum and kanban are processesKanban is a process improvement method while scrum is work managementScrum: Changes have to wait until next sprint. Kanban : wait next available slot or swap cardsCross-functional teams not required in kanbanProduct backlog is optional in KanbanMixed of prioritization technic can be used (rather than business value only)
  • Kanbanvs Scrum – how to make the best of both (Henrik Kniberg) Deprecated version! Latest version is available at
  • Some are better some not,depending on what is important in your contextNo need for upfront planning, estimates, US, Task…
  • Ex: Demos to PO: Scrum puts pressure on making sure quality is achieved, before you get to demo to PO, Kanban does not dictate demos, no positive pressure, no work management/recipe)Team building: scrum advocates team accountability, builds better and stronger teams, not in KanbanLack of Team Building Spirit
  • Workflow management vs. project managementwhile Kanban works very well for continuous delivery situations such as sustained engineering. This is not to say you can't use Kanban for new product development, or Scrum for sustained engineering; you can. I often find that undisciplined teams benefit from starting with Scrum, and then once they get into the habit of producing high quality software in iteration-sized batches, the obvious optimization is to remove the batches and get continuous flow (migrate from Scrum to Kanban).Kanban works well:Game and design agenciesMedia sites and applicationsMaintenance = expedite if P1
  • Hierarchical vs. cooperative, command and controlContracts, change requests, collaborationSize, colocation, multiple teamsCode control, document control, baseline maintenance, change control, build/release,…Superstar vs. team, specialties, reward system
  • Manage resources poolDefine new workCreate wireframe and Use CaseRevise the architectureCode the solutionRecord completed work daily Test the featuresTrack progress with reports and dashboards
  • Best tool for the job, based on role
  • Work items = artifact documentation, e.g. word template, predefined fields, sometimes predefined possible valuesQueries = Dynamic view, real time, of work items based on filter and criteriaReports = Reporting Services on SQL datawarehouse/cubeDocuments = pre-defined templates standardized for all and include XLS workbooks to be used to manage some of the workKanban + custom
  • Work items = artifactsQueries = dynamic viewsReports = SQL reporting (delay)Sharepointdashboarding
  • Also CMMIKanban boardPick the closest to your process and adapt
  • Vs2012 – user story/PBI then tasks in TFS , other levels would be in XLS, pjt or …Now included in vs2013
  • Each team project is configured with one level of portfolio backlog using the Feature work item type. In addition, you can configure up to four additional levels of portfolio backlogs, In total, this provides you with seven levels from the top-level portfolio backlog to task. To access portfolio backlogs from an upgraded team project, you must configure them using the Configure Features wizard. Access to portfolio backlogs requires full access.
  • Ordering – drag and dropEffort
  • Forecasting based on velocity
  • Based on dates, velocity and capacity
  • Capacity report by assigned to
  • Capacity report by activity type
  • Drag and dropPersonnalize WIPStates
  • Remember reports/queries
  • VelocityBurndownCumulativeDepends on process template
  • From Administration panel2012 now supports the concept of multiple teams within a team projects.A Team is responsible for an areaSpecify the areas and iterations a team owns and the dates for sprints to occur. Create customized home pages for teams. Define and manage team favorites and team alerts.See status and gain quick access to team favorites from a lightweight dashboard.
  • Per teamprovide an area for fostering and capturing communication among team members, both near and far. Teams can discuss work in progress, ask questions, share status, and clarify issues that arise in real time.By using the team room instead of email threads, you automatically receive an audit trail of conversations and decisions
  • Choosing the right agile approach for your organization

    1. 1. North American Leader in ALM Services
    2. 2. Services & Solutions
    3. 3. Visit
    4. 4. Choosing the right Agile approach for your organization Frederic Persoon,ALM Practice
    5. 5. Agenda Agile What is it? And why following Agile? The processes Scrum, Kanban and Scrumban How to choose Things to consider Conclusion And Q&A In TFS The tool
    6. 6. Agile
    7. 7. Team barriers = value delivery impediments | |
    8. 8. Survey says Source: 2012 State of the Agile Survey - VersionOne
    9. 9. Survey says Source: 2012 State of the Agile Survey - VersionOne
    10. 10. Agile Software Manifesto “We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:“ That is, while there is value in the items on the right, we value the items on the left more. ( ) Individuals and interactions Working software Customer collaboration Responding to change over over over over Processes and tools Comprehensive documentation Contract negotiation Following a plan
    11. 11. Become more effective 12 Key Agile Principles Customer satisfaction is our highest priority Welcome changing requirements Deliver working software frequently Encourages collaboration between the team and the customer Build projects around motivated individuals Favors face to face communications Measure progress in terms of working software Maintain a sustainable pace Continuous attention to technical excellence enhances agility Keep it simple Empower the team. Self organization produces the best results.
    12. 12. Agile Processes Popularity Most are using Scrum or Scrum variants (72%), as in past years Kanban and Kanban variants nearly doubled this year, mostly due to an uptick in Scrumban use Source: 2012 State of the Agile Survey - VersionOne
    13. 13. Survey says Source: 2012 State of the Agile Survey - VersionOne
    14. 14. Scrum
    15. 15. What is Scrum? • Agile process framework • Based on empirical management & control process – inspect and adapt feedback loops • Used to manage complex projects since 1990 • Delivers business functionality in 30 days (or less) • Scalable to distributed, large, and long projects • Extremely simple but relatively hard to put in place
    16. 16. The Scrum Process Adaptation Inspection Transparen cy
    17. 17. Scrum Roles
    18. 18. You want to avoid this…
    19. 19. Order of Magnitude Theme Epic Epic Story Story Story
    20. 20. Planning Poker Example
    21. 21. Cone of Uncertainty McConnell’s Cone of Uncertainty
    22. 22. The Sprint Project schedule is broken down Fixed period No change in team composition Deliver product increment Avoid incurring technical debt As a goal
    23. 23. Sprint Overview Fixed Duration Start/Finish Story ABC – 5 pts Story BCD – 8 pts Story DEF – 3 pts Story FGH – 2 pts Task 1 – 3.5h - Analysis Task 2 – 14h – Design Task 3 – 7h - UI Dev Task 4 – 7h - Testing Task 1 – 10.5h – Design Task 2 – 7h - Testing Story FGH – 2 pts Story DEF – 3 pts Story BCD – 8 pts Sprint Backlog Task 2 – 7h - Testing Last DayDavid Jane Christian First Day Daily Scrum
    24. 24. Assess Progress – Sprint Burndown
    25. 25. Velocity • Measure the progress of the team, per Sprint • Sum of all stories « done » during the Sprint • Key concept for Estimating and Planning Agile projects
    26. 26. Other Scrum Activities Definition of “Done” Backlog Grooming User Acceptance Testing Release Sprint Bug Management
    27. 27. Kanban
    28. 28. Definition and Background Limit WIPTransparent Pulling From Queue 看板 Process Improvement Continuous Flow
    29. 29. Process for Agile Empirical Values & Principles Team Accountability / Commitment Self-Organized / Managed
    30. 30. Queue Stop Starting, Start Finishing
    31. 31. Limits Allow you to Visualize Problems as they Happen No Need to Wait for Retrospective Queue WIP
    32. 32. Other concepts Class of serviceCost of delay Policies Cycle time Lead time
    33. 33. Kanban Card (Example) ID N#: 123 Due Date: 03/30/2012 As a ____________________________ I want to ________________________ OR Title: ____________________ Date Accepted: 03/01/2012 Date Started: 03/15/2012 (in that column) Effort: M/H/D Task Or Issue
    34. 34. Other Visual Board Example
    35. 35. People Team Lead Business Representatives Team Members No Prescription
    36. 36. Team Members • Can you help finish an existing item? Do that. • Don’t have the right skills? Find a bottleneck and work to release it. • Don’t have the right skills for that? Pull work from the queue. • Can’t do that either? Find other interesting work.
    37. 37. Meetings WorkReview Board Focus on Exceptions Daily Stand-Up
    38. 38. Other meetings (Input) Queue Replenishment After Daily Stand-Up Triage (aka Grooming) Release Planning Issue Log Review & Escalation
    39. 39. Steps No IterationDe-couple Leading vs. Lagging
    40. 40. Prescriptive Models
    41. 41. Vs. Scrum • Process improvement vs. Work management • Specialization is less of an issue • Can have more team members • Continuous flow vs. Time boxed activities • WIP per state vs. Task management • Work can change at anytime • Burndown vs. Cumulative • No Need :  For a Backlog – upfront planning  To plan per iteration  For user stories  To decompose into tasks  For demo and tretrospective at the end of iteration  For PO and SM roles  For upfront estimation • Board is WipedAfter Each Iteration
    42. 42. Scrum vs. Kanban - recap
    43. 43. “Benefits” i.e. What is supposed to be better • Visualization (what is where) • Expedite work mechanism built-in • Less upfront planning and work • Keep specialization • Process improvement technic
    44. 44. Biggest drawbacks • Lack of time boxing results in less “Positive Pressure” • No how to/recipe • Even if team commitment required it is less transparent – No mirror effect
    45. 45. How to choose
    46. 46. When to use witch? Typically…• They are NOT mutually exclusive • If expedite type work is frequent (Cannot wait end of iteration) • If difficult to estimate • If specialization of Work
    47. 47. Scrumban = Scrum + Kanban  Use the prescriptive nature of Scrum to be agile  Use the process improvement of Kanban to allow the team to continually improve their process  Flow of work  No upfront estimation/de-coupled  Prescribed roles  Scrum meetings – revisited  (planning, daily, retrospective)  Board only (No burndown)  No sprints  Team can be specialized  WIP  Just in Time cards
    48. 48. Survey says Source: 2012 State of the Agile Survey - VersionOne
    49. 49. To consider  Organizational culture  Your customers  Types of projects  Tools and Processes  Your people
    50. 50. How it works – The basics In TFS
    51. 51. TeamFoundation Server is the collaboration hub
    53. 53. Access
    54. 54. TFS process templates
    55. 55. Work items – Queries - Reports - SharePoint
    56. 56. Scrum vs. Agile
    57. 57. How it works – The features
    58. 58. Insight – Track and Monitor
    59. 59. Enterprise agile project portfolios
    60. 60. The hierarchy of requirements
    61. 61. Work breakdown per team
    62. 62. Portfolio backlog
    63. 63. Product backlog
    64. 64. Assign to sprint
    65. 65. Sprint backlog
    66. 66. Capacity planning
    67. 67. Capacity planning
    68. 68. Insight – visibility
    69. 69. Board
    70. 70. Web access– Queries - Reports - SharePoint
    71. 71. Portfolio – Product - Sprint
    72. 72. Insight – collaboration Team rooms
    73. 73. Teams Multiple teams working on the same backlog
    74. 74. Team rooms
    75. 75. Conclusion
    76. 76. QA InCycle Software – – Choosing the rightAgile approach for your organization (Level 100)
    77. 77. VM: management-with-team-foundation-server-2013.aspx What’s new in Planning and Tracking: What’s New in 20122 RC: Agile Planning and Iterations: Customize Task Board : Engaging Stakeholders Through Continuous Feedback: us/library/hh301769(v=vs.110) Enabling Data Flow Between TFS and Project Server: us/library/gg455680(v=vs.110) Teams (An older Blog post): Estimate: Ordering: Analytics: Additional Resources
    78. 78. Agile reading list
    79. 79. • Versionone: -Annual-State-of-Agile-Development-Survey.pdf&ei=O_VCUuX_DY7Q9gT5jYAI&usg=AFQjCNFJEcq_vS9tS0yBBaX9vbMGc1p3jA&sig2=HF2wNYVGPUy_h2r6i3e1Rg • David Anderson:   Kanban in Action • Hiranabe:  Kanban Applied to Software Development: from Agile to Lean: • Ladas:  Scrumban - Essays on Kanban Systems for Lean Software Development:  Scrum-ban: • Belshee:  Naked Planning, Kanban Simplified: • • • Some Kanban References