Adopting Agile

Adopting AgileTHE PRACTICES BEHIND THE THEORY

Agile Manifesto• Individuals and interactions over

process and tools• Working software over

comprehensive documentation• Customer collaboration over

contract negotiation• Respond to change rather than

follow a planhttp://www.agilemanifesto.org/

Agile Principles

• The highest priority is to satisfy the customer through early and continuous delivery of valuable software

• Always welcome changing requirements• Deliver working software frequently• Business people and developers must work together daily throughout the project• Build projects around motivated individuals, and give them the environment they need to

get the job done• Face-to-face communication is the most effective and efficient means of conveying

information• Working software is the primary measure of progress• Agile processes promote sustainable development

Agile Principles

• 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 be more effective, then tunes

and adjusts its behavior accordingly

Agile and waterfall comparison

• Phases of development• Artifact based milestones• Infrequent delivery• Limited, prevented, costly changes• High periodic ceremony, high

documentation• Big up front requirements• Large, departmental centric teams• Strict role adherence• Work breakdown structure

• Cycles of development• Delivery based milestones• Frequent delivery• Regular, embraced, low-cost changes• Low frequent ceremony, light documentation• Just in time elaboration• Small, cross-functional, project centric teams• Blended roles• Feature breakdown structure

Waterfall Agile

Page 5April 5, 2012

Timeline comparison

Page 6April 5, 2012

Analysis Design Development Testing Ops Prod

Epic Stories Cycle Review Ops Pro

d

Traditional

Agile

Agile Myths

• Agile development is undisciplined• Agile teams don’t plan• Agile development is unpredictable and we need predictable

plans for future planning• Agile is the latest fad and won’t work here. Waterfall/ CMM/ISO

are much more stable and consistent• Lean thinking is a recent trend and will be replaced by something

else• There is no end to a project; agile development continues forever

Agile Myths

• The big infrastructure must be delivered first and then we can release features

• The tester will find any defects that exist, they can test out any issues

• Development was broken into sprints and we attended all the scrums; therefore we should be successful

• An application that is still in flux can’t be tested• Agile teams don’t plan more than 3 weeks out• The Scrum Master is our project manager

Focus on flexibility• Constantly remove waste

– Value vs. waste vs. necessary waste• Practice of sashimi

– Feature breakdown vs. work breakdown– Minimal marketable feature

• Decrease the cost of change– Remove unnecessary waste – do less– Simplify and automate

• Frequent delivery and frequent feedback

Art of agile in 4 easy steps

Page 9November 17, 2011

Value vs. Waste

Team constantly evaluates work in progress• Value Added

• Stories that directly or indirectly add value to the project

• Activities that directly or indirectly add value to the project

• Necessary Waste• Work that needs to be done but does not directly add

value• Pure Waste

• Activities that add no value to the project• Delays in hand-offs

• Continuous drive to eliminate/minimize waste and focus on Value Added

Sashimi

November 17, 2011Page 11

• Feature breakdown vs. work breakdown

• Important to get vertical slices of functionality

• Focus on demonstrable stories vs. technical tasks

• Something that the product owner would pay for

• Responsibly breakdown as small as possible

Decrease the cost of change

November 17, 2011Page 12

• Requires extra discipline in development

• Requires technical environment to support it

• Good design – single responsibility principle, abstraction, encapsulation

• If it’s painful, do it more often• Practice, practice, practice• Carry less baggage

Frequent feedback

November 17, 2011Page 13

• Embrace late changing requirements

• Focus on actual need vs. perceived need

• Don’t know what we want until we try it

• Difference between course correction and spinning

• Time value of features

What makes a project a good fit for agile?

• Changes are likely• Cost of a change is low• Full team participation• Risk level?• Team ability / skills?• Overall cost? Visibility?• Would I build a house this way?

Best ways to fail with agile

• Change practices without changing behavior

• Ignore the engineering disciplines

• Avoid / delay the painful activities

• Apply work breakdown structure• Ignore the status data• Focus on only one discipline• Maintain discipline silos

Common pitfalls

Stages of adoption - Introduction1.  Daily scrums with full team participation - all analysts, all developers, all testers, and product owner, adhering to scrum rules - less than 15 minutes, active stories only, 3 questions, NOT issue solving

2.  Conducting retrospectives regularly with outcome documented in a central location, achievable number of action items assigned to an owner, and implementing identified opportunities

3.  Release Review - Reviewing every story with the entire team and encouraging ACTIVE conversation about assumptions and outstanding questions while assigning story points4.  Peer code reviews on each story5.  80% automated unit test code coverage for newly developed / changed code

Stages of adoption - Emerging6.  Creation of stories and progression through standard story lifecycle workflow

7.  Reviewing Status Report / Dashboard regularly to improve velocity and estimation and identify potential bottlenecks

8.  Respecting Work In Progress limits - focus on getting fewer things done vs. lots of things started9.  Small incremental changes with frequent (daily) check-in to source repository…..Stories are integrated into trunk, source tagged, and deployed to a controlled environment before moving story to final validation

10. Product Owner involvement throughout the life cycle of the project - writing of Epics, feature breakdown, providing the value statement for the work being done, and validating all stories

Stages of adoption - Understanding

11. Every Story is a minimal marketable feature being a vertical slice of the system, and follow the INVEST model - Independent, Negotiable, Valuable, Estimateable, Small and Testable, with a meaningful goal statement

12. Writing acceptance criteria in Given When Then format using business examples rather than values for granular variables, and carefully selecting test scenarios to reduce redundant tests (equivalence partitioning analysis) and include boundary values

Stages of adoption - Perfecting

13. Fully automated deployment - including DB scripts, app deployment, container configuration

14. Automated BDD / ATDD - Behavior Driven Design / Acceptance Test Driven Design (Acceptance tests written before coding, higher level application interface emerges) with 100% automation of Acceptance Test

Questions?