You think you know agile?The where, what and how of agilenathan.gloyn@dotnetsolutions.co.ukDesign Code Releasenathangloyn@NathanGloyn
AgendaYou Decide!
ROOTS...
Roots...When agile was born…Heavy weight project management processesMisunderstood requirementsMissed deadlines or death march projectsInability to change requirementsApplications with lots of defectsIncreases the cost
Roots...Scrum – first described1986DSDM, Adaptive Software DevelopmentScrum19951996Extreme Programming (XP), Crystal Clear1997Feature Driven Development2001Agile Manifesto2004Kanban??
Roots...Agile ManifestoIndividuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a planThat is, while there is value in the items on the right, we value the items on the left more.
Roots...Agile Manifesto – 12 PrinciplesCustomer satisfaction by rapid delivery of useful softwareWelcome changing requirements, even late in developmentWorking software is delivered frequently (weeks rather than months)
Roots...Agile Manifesto – 12 PrinciplesWorking software is the principal measure of progressSustainable development, able to maintain a constant paceClose, daily co-operation between business people and developers
Roots...Agile Manifesto – 12 PrinciplesFace-to-face conversation is the best form of communication (co-location)Projects are built around motivated individuals, who should be trustedContinuous attention to technical excellence and good design
Roots...Agile Manifesto – 12 PrinciplesSimplicitySelf-organizing teamsRegular adaptation to changing circumstances
Concepts
ConceptsControl
ConceptsCommunication
ConceptsCollaboration
ConceptsCooperation
ConceptsCommitment
Team
TeamThe team is:Critical to successNot a bunch of individualsNo Hero’sNot dependent on any memberEmpoweredTrusted
TeamWho is in the team?Team MemberProduct OwnerCustomer
TeamWho is a Team Member?DeveloperTesterBusiness AnalystTeam LeadArchitectProduct Owner
TeamDo we need a product owner?Focus on what to deliverCustomer ProxyProduct ManagerProject Manager not a good fitNot good idea to be a team lead or manager
TeamWhere does a Scrum Master/Coach fit in?Guardian of the teams processServant/LeaderHelps foster the idea of “team”Should never be a team lead or managerFocused on helping team deliver
TeamDo we need a project manager?Generally noResponsibilities distributedProduct ownerCoach/Scrum MasterSome projects have to be waterfall
TeamGeneralistORSpecialist?
TeamA Self <?> TeamSelf OrganisingSelf DirectingSelf Managing
Methodologies
MethodologiesCurrently 3 main stream:ScrumXPKanban
Methodologies: Scrum
Methodologies: ScrumTO DOWIP Done
Methodologies: XP
Methodologies: XPTO DOWIP Done
Methodologies: KanbanInput QueueIn ProcessDoneAvailable capacity
Methodologies: KanbanTO DOWIP (2)Done
MethodologiesCommonalities:Visibility/TransparencyUser storiesPull BasedDefinition of doneSustainable paceContinuous Improvement
Methodologies: Helicopter ViewScrumXPKanbanPlan releasePlan iterationWork through itemsRelease when “Done, Done”Iteration RetrospectiveRelease RetrospectivePlan sprintWork on items in sprintReviewRetrospectiveInput queuePull item to workWork until meets done criteriaRepeat
Methodologies: MeetingsScrumXPKanbanRelease PlanningIteration PlanningStandupIteration RetrospectiveRelease RetrospectiveDaily Stand-upSprint ReviewSprint RetrospectiveSprint PlanningBacklog groomingNone
Methodologies: RolesScrumXPKanbanCustomerCoachTeamCustomerProduct OwnerScrum MasterDevelopment TeamWhat ever you	currently have
Methodologies: ArtifactsScrumXPKanbanBoardChartsMore charts!Card BoardBacklogDefinition of DoneBurndownBoardWhat ever reports you wish to create
Methodologies: MetricsScrumXPKanbanLead timeCycle timeThroughput performanceDue date completionetcVelocityVelocity
Methodologies:Continuous ImprovementScrumXPKanbanKaizen cultureKaizen blitzSlackInspect & AdaptSprint retrospectiveIteration retrospectivesRelease retrospective
Methodologies: Differentiators Scrum EstimationCommitment Forecasting Iterations Team decide what to pull into an iteration
Methodologies: Differentiators XPShort Iterations“Done, Done”Rules5 Values14 Principles24 Practices
Methodologies: Differentiators KanbanFlowCadencePoliciesClasses of Service
Methodologies: Comparison
Lean
LeanWhat is Lean?From manufacturingToyota Production System (TPS)Just In Time (JIT) productionKanban cardKaizenPoppendicksLean Software Development: An Agile Toolkit (2003)David J AndersonKanban - Successful Evolutionary Change for your Technology Business
Lean: PrinciplesEliminate Waste
Lean: PrinciplesBuild Quality In
Lean: PrinciplesCreate Knowledge
Lean: PrinciplesDefer Commitment
Lean: PrinciplesDeliver Fast
Lean: PrinciplesRespect People
Lean: PrinciplesOptimise the whole
What’s next?
What’s next?ScrumBanLean StartupThe rise of leanDeath of the Iron triangle?
What’s next: ScrumbanMixture of Kanban & ScrumWorkflow of KanbanBacklog column for iterationReady column for higher priority workMeetings of Scrum
What’s next: The rise of leanThe next best thing?Beware marketing speakCan help whatever process you are usingKanban
What’s Next: Lean Startup“new methodology”Focused on getting product “out there”More a business methodologyKanban great fitBeware comparisons to agile
What’s Next: Lean Startup
What’s next: Death of the 			   Iron triangle?Cost exists anywayQuality should be a givenScope flexiblePossibly in enterprisesUnlikely with external clients
Sum up
SummaryLots of ideasPull in what worksThrow away what doesn’tCreate your own processStay true to principlesnathan.gloyn@dotnetsolutions.co.ukDesign Code Releasenathangloyn@NathanGloyn

You think you know agile

Editor's Notes

  • #6 Scrum – Hirotaka Takeuchi and IkujiroNonakaDSDM – Dynamic Systems Development MethodMoSCoW requirement prioritisation – Must have, Should have, Could have, Won’t haveFully compatible with ISO 9000 &amp; PRINCE2
  • #23 Servant Leadership - Robert K. Greenleaf 1970
  • #37 In scrum although backlog grooming is not an official meeting most teams work with thee ScrumMaster &amp; Product owner to ensure the stories are ready to be worked on
  • #43 Values:Simplicity, Communication, Feedback, Respect, CouragePrinciples: Humanity, Economics, Mutual Benefit, Self-Similarity, Improvement, Diversity, Reflection, Flow, Opportunity Redundancy, Failure, Quality, Baby steps, Accepted responsibilityPractices: Primary - Sit together, Whole Team, Informative Worksapce, Energized Work, Pair Programming, Stories, Weekly cycle, Quarterly Cycle, Slack, Ten Minute Build, Continuous Integration, Test First Programming, Incremental DesignCorollary - Real Customer Involvement, Increment Deployment, Team Continuity, Shrinking Teams, Root Cause Analysis, Shared Code, Code And Tests, Single Code base, Daily Deployment, Negotiated Scope Contract, Pay Per Use
  • #44 Flow – important to ensure that the work flows through the systemCadence – the time it takes to performPolicies – govern behaviour, how the system works. Limit WIP best example of a policyClasses of Service – typically based on business impact, implemented through policies, will effect work done by the team
  • #48 Partially Done Work – work not completedExtra Processes – needless paperworkExtra Features – adding features in ‘just in case’ which aren’t really neededTask Switching – switching between different projectsWaiting – delays in staffing, delays in starting, delays due to excessive documentationMotion – how much motion to answer a question? Linked to Task Switching &amp; WaitingDefects – the longer it takes to discover a bug the more it costsManagement Activities – project management activities, authorization processes for approval of requirement changes, etc
  • #49 Perceived Integrity – how a customer perceives the system. A good example is GoogleConceptual Integrity – the same concept, from a users perspective, is executed consistently e.g. Airline bookingRefactoring – process can’t be perfect 1st time. Refactor to improve as knowledge improvesTesting – Unit tests, integration tests, load tests, etc
  • #50 Identifies that knowledge of what we are doing is important and that we need to actively look to create this knowledge to help the teamFeedback – feedback loops help create knowledge e.g. Unit testingSharing knowledge – pair programming, code reviewsRecording knowledge – wiki, code comments, documentation
  • #51 Concurrent development – develop separate streams until you have to decideOptions thinking – Responding to change rather than following a plan, don’t freeze “requirements”Last responsible moment – don’t make a decision over what to do until the last momentMaking decisions – actually make a decision over what option to take, don’t allow concurrent streams forever
  • #52 Pull Systems – customers prioritise what they want so they get most important thing firstQueuing theory – ensure steady rate of arrival, include slack, Theory of constraintsCost of Delay – cost of developer not having tools to speed dev, cost of not getting to market
  • #53 Engage, collaboration, trust and respect the people doing the work. E.g. Managers that do not know how the work is done shouldn’t try to tell people how they should do their workLean is not about controlling people, it is about engaged motivated people helping a business grow
  • #54 Systems thinking – look at entire systemMeasure value – focus on how the business delivers value, use Value Stream Mapping to helpThink long term – don’t focus on the now (although important) look at where you the business is going/needs to be
  • #57 Utilise WIP limits to highlight impediments/bottlenecksStill use iterations to provide “container” for deployable softwareStill generalist skillset i.e. Anybody can pick up any task
  • #58 Recommended booksPoppendicks : Lean Software Development – An agile toolkit, Implementing Lean Software Development. David Anderson : Kanban – Sucessfulevolutionary change for your Technology business
  • #59 Running Lean (www.runningleanhq.com) – great free book on lean startup“Offical” book from Eric Ries coming out soon.
  • #60 Not comparing like for like.Be sure to differentiate Business Methodology with a workflow methodology AAARS =Acquisition – user comes to site from various channelsActivation – users enjoy 1st visitRetention – users come backReferral – users like you enough to refer othersRevenue – users conduct some monetized behaviour
  • #61 Jeff Sutherland