An Agile Development Primer

transcript

Agile Software Development

Primer

What is Agile Development?

"The ability to move faster than those things that can harm your project…"

Agile Development is a method

of building software by empowering and

trusting people, acknowledging change as a norm, and promoting

constant feedback

Agile Software Development ... the History

1974 An adaptive software development process documented, 1991 “Rapid Application Development” published1995 DSDM Framework published1995 SCRUM presented at OOPSLA1996 XP Practices developed on C3 project1997 FDD processes designed by Jeff De Luca1999 FDD described in “Java Modeling in Color with UML”1999 “Extreme Programming Explained” published1999 “Adaptive Software Development” published2001 Crystal Light methodologies described in Cutter IT Journal, 2001 Agile Manifesto written2003 “Lean Software Development: An Agile Toolkit for

Software Development Managers” published

Kent Beck – Creator of XP, TDD Mike Beedle – “Agile Software Development with Scrum” c.Ken Schwaber, 2002 Arie van Bennekum – RAD, DSDM Alistair Cockburn – Use Cases, Crystal Methodologies Ward Cunningham – Creator of XP, wiki’s, design patterns Martin Fowler – the UML, Author of “Refactoring” & “Planning XP” c.Beck James Grenning Jim Highsmith – Creator of ASD, “Adaptive Software Development” (1999) Andrew Hunt – Author, Partner “The Pragmatic Programmer” c. D. Thomas Ron Jeffries – Creator of XP, “Extreme Programming Installed” (2000) Jon Kern - Brian Marick – Context Driven Testing Robert C. Martin – Author “Designing Object Oriented C++” (1995) Steve Mellor - Shlaer-Mellor method, Executable UML, MDA Ken Schwaber- Creator of SCRUM, “The Enterprise & SCRUM” 2007 Jeff Sutherland – Creator of SCRUM Dave Thomas – Author, Partner “The Pragmatic Programmer”

Agile Software Development ... the History

The Manifesto for Agile Software Development

That is, while there is value in the items on the right, we value the items on the left more

Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan

We are uncovering better ways of developing software by doing it and helping others do it. Through this work

we have come to value:

These are MORE Valuable

These are Valuable

• Let good people do what they’re good at• People work together to write software• People use software

Individuals & interactions

• Are important and needed, but don’t be a slave

Processes & tools

• The software is for a customer for a purpose

Customers & collaboration

• Contracts should reflect the purpose and encourage collaboration

• Target costing

Contract Negotiation

• What the software does should be useful

Working software

• Agile does *NOT* say no documentation• LEAN says just enough documentation• Not at the expense of face-to-face

Comprehensive Documentation

• Change happens ... work with it• Short feedback loops

Responding to change

• Plan for changes• Should support timely decision making

Following a plan

Agile Principles

Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.

Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

Business people and developers must work together daily throughout the project.

Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

Agile Principles

1. Satisfy the Customer

2. Welcome Change

3. Deliver Frequently

4. Work as a Team

5. Motivate People

6. Communicate Face to Face

Agile PrinciplesWorking software is the primary measure of progress.

Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

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 become more effective, then tunes and adjusts its behaviour accordingly.

Agile Principles7. Measure working software

8. Maintain constant pace

9. Excel at quality

10. Keep it simple

11. Evolve designs

12. Reflect regularly

Agile Practices

Agile PracticesDesign & Programming

* Build Automation

* Automated Deployment

Continuous Integration

* Simple Design

Collective Ownership

Feature Teams

* Refactoring

Pair Programming

Testing

* Automated Unit Testing

Acceptance Tests

* Test Driven Development

Small Releases

Planning Game

Blitz Planning

Iterative Development

Working Without Iterations (Wall work Queue)

Short Iteration Cycles

The Task Cycle

Communication & Collaboration

Stand Up Meetings

Daily “Scrum” Meeting

Co-located Team

Documentation

Start of Project Documentation

Design Documentation

Other approaches

Design & Programming

*Build Automation

*Automated Deployment

*Simple Design

*Refactoring

Pair Programming

Build Automation

•A simple “push of a button” Build Process

•Any team member can use it

•Free up programmers from repetitive and mundane tasks

•Increase responsiveness, Improve Quality

•Reduce time chasing compilation or convergence issues

Purpose/Benefit:

•Batch & Shell scripts?

•Build tools? (Eg. CruiseControl)

•Keep Compile time short

•Mind the 20:80 rule

Opportunities/Obstacles:

Automated Deployment

•Streamline and make predictable the process of promoting builds from development through testing and into production

•Provide Testers and Customers latest code quickly

•Reduce mix-ups caused by manual build deployment and promotion

Purpose/Benefit:

•Automate process before any coding begins

•Make target machine resemble production environment

•Helps to identify and address compilation and functional issues before UAT deployment

•Allow test team to promote builds into test

•Less ‘branch’ code residing on individual workstations

•Small chunks of functionality integrated into central codebase

•Save time

•Reduce Defect Rates

Purpose/Benefit:

•Code integrated one developer at a time

•Build Machine performing automatic compile and test of codebase

•Getting into the habit of checking in code every few hours

Simple Design

• All Code should ... compile and pass all the tests

• ... Result in no Duplicated Logic

• ... Do everything it needs to

• ... Leave behind the fewest necessary classes and methods

•Changes to code only need to be made once

•Code is easier to understand

•Increases confidence and reduces criticism

Purpose/Benefit:

•Code for today and forget about tomorrow ... (because the spec might change)

•Consider the simplest thing that could possibly work

•Collaborate before coding

•Two Heads are better than one

•Don’t forget to write unit tests

•Don’t re-invent the wheel vs. If you’ve got a hammer not everything is a nail

•To remove explicit and implicit relationships between programmers and components

Goal:•Reductio

n of wasted time and duplicate code

•Anyone can change any code

•Reduces time to fix defects

Purpose/Benefit:

•Foster a sense of owning all the code

•Deliberately allocate tasks across the code to different people

•Short iterations / small releases

•Team wide coding standards

•Unit tests will provide confidence in changing someone elses code

•Don’t let ego’s get in the way

Feature Teams

•Better design and Easier maintenance

•Benefits of Collective Ownership and class Ownership combined

•Distributed Knowledge across entire project team

•Responsibility for classes clear, design should improve

Purpose/Benefit:

•Each Programmer becomes owner of one or more classes

•Features are assigned to owners (Chief Programmer)

•Feature teams dynamically assembled to complete specific code

•Can slow down speed of projects

•Can conflict with Continuous integration

•One class owner required on multiple feature teams

Refactoring

•Keep the code fresh and clean

Goal:•

Recovery of poorly written systems

•Maintain ‘newness’ of code longer, therefore system lifecycle

Purpose/Benefit:

•Simplifying complex code

•Replacing similar operations into reusable code

•Removing duplicate code

•Sufficient coverage of unit test required before refactoring

•Lots of small changes rather than a few big ones

•Seek buy-in of the whole project team

Pair Programming

•Better Code Quality

Goal:•Mentori

ng/Training

•Knowledge Sharing

•Consistent use of Coding standards

Purpose/Benefit:

•Two people, one workstation, one piece of code

•Both take turns at “driving”

•Adopt slowly ... Perhaps start with problem solving or bug fixing

•Part-time pairing before full-time pairing

•Try side-by-side programming instead

Testing

*Automated Unit Testing

Acceptance Tests

*Test Driven Development

Automated Unit Testing

•A suite of tests that can be run at the push of a button

•Improved code quality

Goal:•Reduce

time identifying and correcting defects

•Reduce turnaround and increase confidence in small changes to code

Purpose/Benefit:

•Test meaningful functionality

•Rely only on restorable data

•Start with new and modified code, not legacy code

•Don’t allowed repeated failures of the test suite

•Make sure the tests don’t take too long to run

•Everyone must write and run tests

Acceptance Tests

•A mechanism for the customer to accept a feature

Goal:•Automa

ted tests ensure testing effort doesn’t expand with each additional release

•Reduction in number of defects

Purpose/Benefit:

•Should be written prior to development of story starting

•Should test everything required for sign off

•Its not acceptable to complete a story without an acceptance test that passes

•This practice provides a good basis for also doing load testing

Test Driven Development

•Quality of Code

Goal:•Ensures

exhaustive test coverage

•Ensures testable code

•Makes maintenance easier for all programmers

Purpose/Benefit:

•Write a test (an ensure it fails)

•Write just enough code so that the test (and all others) pass

•Repeat the cycle until the feature is completed

•Its a change of mindset

•Start with something small and simple

•Best learnt in pairs

Agile Management

User Stories / Story Writing Workshop

Release Planning Activities

Iterative Development

The Customer

Documentation

Release Planning Activities

Step 1: Update the List of Work

Step 2: Prioritise the List of Work

Step 3: Determine the Release Date and amount of work that can be completed

Step 4: Select the Work to be completed in the release

Step 5: Plan activity for 1st iteration of release

Release Planning Specifics

The Planning Game

•Reduce conflict relating to scope, scheduling and releases.

Goal:•Foster

collaboration between customer and developer

•Clearly defined roles for customer and development team

Purpose/Benefit:

•Exploration Phase – write stories (B) / estimate stories (D)

• Commitment Phase – Sort by Value (B) / Risk (D), Set Velocity/Scope

•Steering Phase – Repeat and review for each iteration

•Customer & Developers commit to a realistic and mutually agreed plan

•Provides a framework for change

Blitz Planning

•Focus on project initiation activities, getting project started or authorised quickly

•Single meeting resulting in plan agreed by every project stakeholder

•Addresses technical issue’s often overlooked in initiation processes

•Promotes collaboration

Purpose/Benefit:

•Brainstorm tasks, Estimated and owner assigned

•Sort in sequence of development

•Walking Skeleton, Earliest Release, Earliest Revenue/Savings

•Requires commitment from user, business and developers

•Promotes tough decision making

What are the benefits and pitfalls of Iterative Development?

What is the role of the Customer in an Agile Project?

What to look for in a good Customer

Stand Up Meetings

Daily “Scrum” Meeting

Co-located Team

Stand-up Meetings

•5-10 minutes status updates, co-ordination, work plans

•STANDING ONLY

•Standing encourages shorter meetings and therefore focus

•Identify topics/issues and sideline for appropriate people/time

•Mainly for programmers

Purpose/Benefit:

•Depends on office layout, if closeby, less valuable

•Same place, same time everyday

•Whats completed, Whats next, Roadblocks?

•Evolve over time based on participants and projects

Daily SCRUM Meeting

•Provides a forum for all stakeholders to observe

•Opportunity for tuning team priorities

•Keeps everyone informed on progress

•Flush out obstacles, track progress

Purpose/Benefit:

•Only Pigs can speak (Team members)

•All team members to attend

•Whats completed, Whats planned next, Whats in the way?

•Evolve over time based on participants and projects

We value working software over comprehensive documentation

When is Documentation Important

1. To communicate information during development

2. To Specify something

3. To Permanently record something

4. To conform to regulations

Fundemental Advice

1. Prefer executable specifications over static specifications (documents)

2. Single source information

3. Document stable concepts, not speculative concepts, and thereby document as late as possible in the life cycle

4. Documentation is the least effective means of communication

Reviewing Current DocumentationFactor Improvement Strategy

How correct is the document?• Minimise the information contained• Single Source Information• “Pair” Author / Have shared ownership • Document stable, not speculative concepts

Will the document be read? • Work closely with the audience

Will the document be understood? • Take an iterative and incremental approach

Will the document be followed?

• Prefer executable specifications, such as customer tests and developer tests, over static specifications• Capture high-level information in documentation

Will the document be trusted? • Work closely with the audience of the document• Take an iterative and incremental approach

Common Agile Methodologies

eXtreme Programming (XP)

Feature Driven Development

Dynamic Systems Development Methodology

Adaptive Software Development

Lean Software Development

Common Theme’s

Focus on Features, not Tasks

Responsive to Change

Documentation Secondary to working software

Timeboxing

Planning & Estimation is a team activity

Short iterations, regular feedback loops

No amount of process can replace good people

Feature Driven Development

Not a specific set of practices or processes

Process, Documentation, Best practices take a back seat to goal of operational excellence.

Defined by how quickly and reliably an organisation can serve its customers.

Seven LEAN Prinicples

Eliminate Waste

Amplify Learning

Decide as Late as Possible

Deliver as fast as Possible

Empower the Team

Build in Integrity

See the Whole

Self-governing

Self-organising

Self-managing

Manager-led

Team Type/

Activity

Setting Overall Direction

Designing the team and its

context

Managing work process and monitoring

progress

Executing the team tasks

Self-Organising Teams

Accountability & Responsibility

Learning Teams

Why are Self-Organising Teams Better?

Engendering a Communicative and Collaborative culture

working in an ARO

culture

3 domains

ACCOUNTABILITY

RESPONSIBILITY

OWNERSHIP

PERSONAL

MUTUAL

SHARED

ACCOUNTABILITY

RESPONSIBILITY

OWNERSHIP

personal

shared

mutual

control

influence

solidarity

about …

delivery

collaboration

WHO IS US?

initiative

leadership

personal accountabilityI have the control leversDefines the decisions that are ultimately mineIs the set of things my boss will hold me to and for which I am employed.‘I assure you’ rather than ‘trust me’Included in my performance agreement

This defines what is important or central in my work. I do not have to be asked to go here … it is my job to be here.

Expect others to come here when your behaviour has an impact on an arena for which they are accountable, or when there is overlap with an arena for which they have shared responsibility.

mutual responsibilityI have the responsibility to influenceAnything that is impacted by my behaviour or my decisions is within my influenceWill include cultural and environmental dimensions, and will therefore be a significant component of my performance review conversationSomeone must be accountable, but I have the responsibility to give input, state my case, and ensure alignment with my arena of accountability

Go here when invited or when it impacts an arena for which I am accountable.Remember that this patch may be an arena that someone else is ultimately accountable

shared ownership

Solidarity, who is ‘we’?The domain that falls outside the sphere of my influence, but that remains part of the whole of which I am a partAs broad as possibleAll that sits under the strategic plan, that wears our brand

Go here when the brand or the ‘whole’ is threatenedBe careful because others will know more than you

Behaviour in an ARO culture is …

Focused and targeted, not scatteredProject rather then role or position orientedDisciplinedHigh performance

Communication isEntrepreneurial rather than beaurocraticTransparent: knowledge and power is necessarily sharedRobust and often difficult because there is lots of grey in the shared responsibility domain

Key vulnerabilities in an ARO culture …

ACCOUNTABILITYLack of clarityExcuses

REPONSIBILITYNo one accountableLack of systems thinking

OWNERSHIPfragmentation

Key vulnerabilities in an ARO culture …

competency creep:Supplementing my accountabilities with personal competency and preference

Disempowers those who have accountability in arena of competency creep

Makes me busier

Indicates a local rather than organisational view … has cascading impact on other teams/departments

Requires trust in other’s ability to deliver according to their accountabilities

Organisational Learning

Trust & HonestyTole

Slack – time, resources, opportunity

Individual Learning

Empowerment

Team Learning

Organisational Change

Organisational Learning

Team Change

An Agile Development Primer

Technology