Agile Software Development Stefan Balbo / Patrick Dolemieux
Content Why go Agile? Introduction to Scrum - Process - Roles Agile Estimating and Tracking Scaling Scrum Design in the Scrum Process Benefits Pitfalls and Best Practices Resources
Why go Agile? Development projects have progressed over time More complex More scope changes
Why go Agile? IT Project Survey (Standish 2009) Development process has stayed the same Inadequate process results in projects that 24% 44% 32% Success Failing Failure - Fail - Have poor quality - Are frustrating to work on - Take longer than expected
The Waterfall Model Requirements Design Implementation Test
What is Agile Software Development? The Agile Manifesto (2001): Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan
What is Scrum? Framework - for agile software development Key concepts: - Iterative and incremental - Small self-organizing teams - Short feedback loops - Priority by business value
Starting a Scrum Project - Envisioning Articulate the project vision Determine and prioritize goals and objectives Define incremental releases Get vision accepted by all stakeholders
Mars.NET Project Vision Mars.Net is a project dedicated to the WPF.Net developer community that is aiming the following objectives: - Integrated into the ArcGIS Ecosystem - Fast Display - Small Footprint - Easy to Deploy Mars.Net is a code name The product name is ArcGIS Runtime SDK for WPF Mars logo is Project started in Q3 2010 - Current sprint is #26
Mars.Net The Context Mars.Net Android SDK ios SDK WPF SDK Java SE SDK Software Developer Kits Android API ios API WPF API Java SE API Object Models ArcGIS Runtime Core Runtime Local Server Runtime
Starting a Scrum Project - Release Planning Create a prioritized list of Epics Create a prioritized backlog of items (PBIs) - Tip: INVEST in your backlog - Independent, Negotiable, Valuable, Estimable, Small, Testable renjith krishnan / FreeDigitalPhotos.net Estimate the items Estimate team s velocity Calculate preliminary date Get stakeholder consensus and commitment to proceed
Mars.NET Releases and PBIs
Mars.NET Backlog description
Scrum Framework Product Backlog Daily Scrum Scrum Questions: Done? Do? Impediments? Iteration Planning Iteration Backlog Iteration 3 weeks Done Potentially Shippable Product Iteration Retrospective Iteration Review
Responsibilities of a Scrum Team Cross-Functional (5-9 members) Agrees to iteration goal and specifies work results Empowered to do anything to reach the iteration goals - within the project guideline boundaries renjith krishnan / FreeDigitalPhotos.net Organizes itself and its work Demos work results to the stakeholders
Product Owner Responsibilities Defines product features Prioritizes product backlog Establishes, communicates and nurtures the vision Accepts or rejects work results Grooms the product backlog Product Owner is the - vision keeper - daily decision maker - single wringable neck
Scrum Master (Agile Coach) Responsibilities Ensures team is productive Enables close cooperation Removes barriers Shields team from interferences Ensures the process is followed Invites to Scrum meetings The Scrum Master is the - Shepherd - Bulldozer - servant leader
Mars.NET The Team Product Engineers Developers Adrien (samples) Chris (Dev Lead) Dara (Doc & Test) Innes Kerrie (Test) Morten Mike (Product Owner) Mary (Scrummaster) The team works in coordination with: Mara Documentation/Resources Center Coordinator Lindsay Release Coordinator Rob Product Manager Patrick Program Manager Scott, Clint, Jim, Euan Stakeholders
Sprint planning Prerequisite: - PBIs considered in Sprint are fully defined (What?) Team effort (1/2 to 1day) Define Goals Select PBI s Determine implementation (How?) - Define Tasks for each PBI - UI Design - Architecture - Dev - Test - Doc - Estimate tasks in hours (2-24)
Mars.NET Sprint Planning Sprint Goals
Mars.NET Sprint Planning PBI and Tasks
Mars.NET Sprint Planning Task description
Agile estimating and tracking How long will it take? - Is a legitimate question - Based on past performance rather than guessing - Agile estimating works
Agile estimating and tracking Relative estimating - against baseline PBI Backlog Items in story points During a Planning Poker game - Fun - Entire team participates - Gain mutual understanding Measure velocity each iteration http://www.agile42.com/cms/pages/poker/
Agile estimating and tracking 160 140 MapX Burndown Chart 120 100 Effort in Points 80 60 40 Velocity Trend Scope change Trend 20 0-20 0 23-Mar 1 10-Apr 2 1-May 3 22-May 4 12-Jun 5 3-Jul 6 24-Jul 7 14-Aug 8-40 Iteration
Mars.NET - Estimating Product Backlog Items Story points It is not time Based on 3 criterias Compare to a baseline story Using Fibonacci suite (1,2,3,5,8,13) 13 story points is the maximum Effort Uncertainty Complexity Tasks Hours Use ideal time for estimates Only remaining hours are tracked Generally between 1-24 hours 40 hours maximum
Mars.NET reports and charts Sprint Burndown Chart
Mars.NET reports and charts Team Member Load Chart
Mars.NET reports and charts
Mars.NET reports and charts
Mars.NET reports and charts ArcGIS Runtime for WPF (Mars.Net) 10% 9% 28% 30% Design Development Test Documentation Event 24%
Scaling Scrum Define Team Structure - Feature vs. Component Teams - Lean towards Feature Teams Establish Communities of Practice Filomena Scalice / FreeDigitalPhotos.net - Topics affecting many teams Hold Scrum of Scrums meetings - Share information between teams Look two to three iterations ahead - Coordinate between teams each iteration Use Epics to track and communicate - High level Stories
Mars.Net Dimensioning the Teams 8 members 6 members 7 members 8 members Android SDK ios SDK WPF SDK Java SE SDK Software Developer Kits Android API ios API WPF API Java SE API Object Models ArcGIS Runtime Core Runtime Local Server 8 members 5 members Runtime
Design in the Scrum Process Design and Architecture - Architecture is on the system and sub system level design is at the class level - Same principles apply - Architecture evolves Architecture owner - includes the entire team - coordinates - doesn't dictate architecture
Design in the Scrum Process (cont.) Agile Architecture and Design - evolve iteratively through - an initial envisioning - implementation of backlog items - refactoring and restructuring avoid waterfall BDUF (Big Design Up Front) that doesn t mean no design up front
Design in Scrum: Architecture Envisioning - When? Sprint 0 - Where? Architecture workshop (whole team) 1-3 days - Architecture Workshop - domain modeling - UI prototyping - identify desired architecture qualities and concerns (e.g. Portability, Usability, Modifiability, Performance, Security) - identify cross-cutting requirements - Prioritize architecture features by business value - include architectural features into the user stories - Benefits: - clarity of critical technical issues - shared understanding of architecture and design
Design in Scrum: Architecture Implementation - select a story and include an architectural feature - select a second story and evolve architecture by refactoring common functionality - select a third story extending and validating the architecture - have brainstorming session before and after a architectural feature is implemented - decide on which/how architectural features to build during iteration planning - Important - Hold a technical debt workshop - Document architectural decisions
Benefits Bring the maximum value to our users More productive Successful Projects Accurate Estimates Transparency to Stakeholders All team members participate Continuous process improvement
Pitfalls when using Scrum Backlog Items are too big Backlog Items not fully defined Team over-commits Unclear definition of Done Team is too large Distributed Teams Product owner proxies Team members assigned to multiple Scrum teams Too many hats Little or no Release Planning
Mars.NET Best Practices Estimates Always have a baseline PBI in mind When a PBI is estimated at 13 story points, consider splitting it When a task is estimated at 40 hours, consider splitting it What means done? PBI done = Design, implementation, testing, and documentation is done This must be a goal for the team A Design task is never completely done It is an iterative process The first level of being done is the ability to start securely an implementation task An Implementation task is done when it is ready to test A Test task is done when all testing has been achieved and the tester has a list of Change Requests to assign to the developer
Mars.NET Best Practices Do design at the earliest Avoid having many tasks in progress unless there are impeded Speak loud and clear Be specific and concise Days off and working days on other projects Must be known in front of sprint Goal is to better balance the workload
Links, Tools and Literature www.scrumalliance.org Scrumworks by CollabNet [easy to use, focused Scrum Tool] Agile Software Development with Scrum - by Ken Schwaber and Mike Beedle [The first Scrum book] Scrum and XP from the Trenches - by Henrik Kniberg [very practical how-to-guide] Succeeding with Agile Software Development Using Scrum - by Mike Cohn (2010) [Helpful for larger scrum implementations] Lean Software Development - by Mary Poppendieck and Tom Poppendieck [A good intro to Lean]
Summary Why go Agile? Introduction to Scrum - Process - Roles Agile Estimating and Tracking Scaling Scrum Design in the Scrum Process Benefits Pitfalls and Best Practices Resources