+ All Categories
Home > Technology > An Agile Development Primer

An Agile Development Primer

Date post: 20-Oct-2014
Category:
View: 4,428 times
Download: 0 times
Share this document with a friend
Description:
An overview of the Agile Manifesto and the principles and practices that define Agile software development. A comparison of Agile Development methodologies and an organisational culture that supports them
Popular Tags:
74
Agile Software Development Primer
Transcript
Page 1: An Agile Development Primer

Agile Software Development

Primer

Page 2: An Agile Development Primer
Page 3: An Agile Development Primer

What is Agile Development?

Page 4: An Agile Development Primer

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

Page 5: An Agile Development Primer

Agile Development is a method

of building software by empowering and

trusting people, acknowledging change as a norm, and promoting

constant feedback

Page 6: An Agile Development Primer

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

Page 7: An Agile Development Primer

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

Page 8: An Agile Development Primer

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:

Page 9: An Agile Development Primer
Page 10: An Agile Development Primer

These are MORE Valuable

These are Valuable

Page 11: An Agile Development Primer

• 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

Page 12: An Agile Development Primer

• The software is for a customer for a purpose

Customers & collaboration

• Contracts should reflect the purpose and encourage collaboration

• Target costing

Contract Negotiation

Page 13: An Agile Development Primer

• 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

Page 14: An Agile Development Primer

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

Responding to change

• Plan for changes• Should support timely decision making

Following a plan

Page 15: An Agile Development Primer

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.

Page 16: An Agile Development Primer

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

Page 17: An Agile Development Primer

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.

Page 18: An Agile Development Primer

Agile Principles7. Measure working software

8. Maintain constant pace

9. Excel at quality

10. Keep it simple

11. Evolve designs

12. Reflect regularly

Page 19: An Agile Development Primer

Agile Practices

Page 20: An Agile Development Primer

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

Page 21: An Agile Development Primer

Design & Programming

*Build Automation

*Automated Deployment

Continuous Integration

*Simple Design

Collective Ownership

*Refactoring

Pair Programming

Page 22: An Agile Development Primer

Build Automation

•A simple “push of a button” Build Process

•Any team member can use it

Goal:

•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)

How:

•Keep Compile time short

•Mind the 20:80 rule

Opportunities/Obstacles:

Page 23: An Agile Development Primer

Automated Deployment

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

Goal:

•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

How:

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

•Allow test team to promote builds into test

Opportunities/Obstacles:

Page 24: An Agile Development Primer

Continuous Integration

•Less ‘branch’ code residing on individual workstations

•Small chunks of functionality integrated into central codebase

Goal:

•Save time

•Reduce Defect Rates

Purpose/Benefit:

•Code integrated one developer at a time

•Build Machine performing automatic compile and test of codebase

How:

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

Opportunities/Obstacles:

Page 25: An Agile Development Primer

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

Goal:

•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

How:

•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

Opportunities/Obstacles:

Page 26: An Agile Development Primer

Collective Ownership

•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

How:

•Team wide coding standards

•Unit tests will provide confidence in changing someone elses code

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

Opportunities/Obstacles:

Page 27: An Agile Development Primer

Feature Teams

•Better design and Easier maintenance

Goal:

•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

How:

•Can slow down speed of projects

•Can conflict with Continuous integration

•One class owner required on multiple feature teams

Opportunities/Obstacles:

Page 28: An Agile Development Primer

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

How:

•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

Opportunities/Obstacles:

Page 29: An Agile Development Primer

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”

How:

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

•Part-time pairing before full-time pairing

•Try side-by-side programming instead

Opportunities/Obstacles:

Page 30: An Agile Development Primer

Testing

*Automated Unit Testing

Acceptance Tests

*Test Driven Development

Page 31: An Agile Development Primer

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

How:

•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

Opportunities/Obstacles:

Page 32: An Agile Development Primer

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

How:

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

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

Opportunities/Obstacles:

Page 33: An Agile Development Primer

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

How:

•Its a change of mindset

•Start with something small and simple

•Best learnt in pairs

Opportunities/Obstacles:

Page 34: An Agile Development Primer

Agile Management

User Stories / Story Writing Workshop

Release Planning Activities

Iterative Development

The Customer

Communication & Collaboration

Documentation

Page 35: An Agile Development Primer

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

Page 36: An Agile Development Primer

Release Planning Specifics

Page 37: An Agile Development Primer

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

How:

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

•Provides a framework for change

Opportunities/Obstacles:

Page 38: An Agile Development Primer

Blitz Planning

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

Goal:

•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

How:

•Requires commitment from user, business and developers

•Promotes tough decision making

Opportunities/Obstacles:

Page 39: An Agile Development Primer

What are the benefits and pitfalls of Iterative Development?

Page 40: An Agile Development Primer

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

Page 41: An Agile Development Primer

What to look for in a good Customer

Page 42: An Agile Development Primer

Communication & Collaboration

Stand Up Meetings

Daily “Scrum” Meeting

Co-located Team

Page 43: An Agile Development Primer

Stand-up Meetings

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

•STANDING ONLY

Goal:

•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?

How:

•Evolve over time based on participants and projects

Opportunities/Obstacles:

Page 44: An Agile Development Primer

Daily SCRUM Meeting

•Provides a forum for all stakeholders to observe

Goal:

•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?

How:

•Evolve over time based on participants and projects

Opportunities/Obstacles:

Page 45: An Agile Development Primer

We value working software over comprehensive documentation

Page 46: An Agile Development Primer

When is Documentation Important

1. To communicate information during development

2. To Specify something

3. To Permanently record something

4. To conform to regulations

Page 47: An Agile Development Primer

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

Page 48: An Agile Development Primer

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

Page 49: An Agile Development Primer

Common Agile Methodologies

eXtreme Programming (XP)

SCRUM

Feature Driven Development

Dynamic Systems Development Methodology

Adaptive Software Development

Lean Software Development

Page 50: An Agile Development Primer

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

Page 51: An Agile Development Primer

XP

Page 52: An Agile Development Primer
Page 53: An Agile Development Primer

SCRUM

Page 54: An Agile Development Primer

Feature Driven Development

Page 55: An Agile Development Primer

ASD

Page 56: An Agile Development Primer

DSDM

Page 57: An Agile Development Primer

LEAN

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.

Page 58: An Agile Development Primer

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

Page 59: An Agile Development Primer

Teams

Page 60: An Agile Development Primer

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

Page 61: An Agile Development Primer

Self-Organising Teams

Communication & Collaboration

Accountability & Responsibility

Learning Teams

Page 62: An Agile Development Primer

Why are Self-Organising Teams Better?

Page 63: An Agile Development Primer

Engendering a Communicative and Collaborative culture

Page 64: An Agile Development Primer

working in an ARO

culture

Page 65: An Agile Development Primer

3 domains

ACCOUNTABILITY

RESPONSIBILITY

OWNERSHIP

PERSONAL

MUTUAL

SHARED

Page 66: An Agile Development Primer

ACCOUNTABILITY

RESPONSIBILITY

OWNERSHIP

personal

shared

mutual

control

influence

solidarity

about …

delivery

collaboration

unity

Page 67: An Agile Development Primer

WHO IS US?

initiative

leadership

DEG

REE O

F C

ON

TR

OL

Page 68: An Agile Development Primer

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.

Page 69: An Agile Development Primer

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

Page 70: An Agile Development Primer

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

Page 71: An Agile Development Primer

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

Page 72: An Agile Development Primer

Key vulnerabilities in an ARO culture …

ACCOUNTABILITYLack of clarityExcuses

REPONSIBILITYNo one accountableLack of systems thinking

OWNERSHIPfragmentation

Page 73: An Agile Development Primer

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

Page 74: An Agile Development Primer

Organisational Learning

Trust & HonestyTole

ranc

e of

Fai

lure

Slack – time, resources, opportunity

Individual Learning

Empowerment

Man

agem

ent T

ime

Recr

uitm

ent

Rew

ards

& In

centi

ves

Team Learning

Organisational Change

Organisational Learning

Team Change


Recommended