4. Choosing the right Agile approach for your
organization
Frederic Persoon,ALM Practice
frederic.persoon@incyclesoftware.com
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
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. (http://www.agilemanifesto.org )
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. 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. 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
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
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. 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
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
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
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.
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
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. 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
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. 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
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 http://www.infoq.com/minibooks/kanban-scrum-minibook
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
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