AGILE ESSENTIALSA ONE-DAY BLITZ THROUGH AGILE FOR YOUR TEAM

IMAGE SOURCE: http://io9.com/5640510/a-chilean-satellite-fires-a-laser-into-space-to-create-a-virtual-star-in-the-heart-of-the-milky-way

AGENDAO N E D AY

10:00 to

11:15What Agile Is and Isn’t (Agile History)

10:30 to

11:00 Agile History “Lab” 11:00 to

11:15 Lab Discussion

12:30 to

2:45Common Agile Practices

1:30 to 2:15 Agile Practices Lab2:15 to 2:45 Lab Discussion

2:45 to

4:00 Agile In Action

2:45 to 3:45 Agile In Action3:45 to 4:00 Lab Discussion

© 2014 DC Strategic Consulting, LTD.

WHAT AGILE IS (AND ISN’T)

A G I L E I SNOT NEW

1957

Incremental Development at IBM’s Service Bureau

Corporation

NY Telephone Company’s Systems’ Development

Center

1974

Scrum methodology presented at OOPSLA in

Austin, Texas.

1995

Rational Unified Process created by the Rational

Software Corporation 1996

Extreme Programming @ Chrysler C3 with Kent

Beck

1996

2001

The signing of the Agile Manifesto in Snowbird, Utah.

A G I L E I SNOT A PROCESS

Process “Sequence of activities, people, and systems involved in carrying out some business or achieving some desired process.”

Methodology “An organized, documented, set of procedures and guidelines for one or more phases of the software lifecycle.”

Pattern “a standard way of moving, acting, etc… a model worthy of imitation.”

A G I L E I SA MANIFESTO

Individuals and InteractionsWe value individuals and interactions over processes and

tools.

Working softwareWe value working software over comprehensive documentation

Customer CollaborationWe value customer collaboration over contract negotiation.

Responding to ChangeWe value responding to change over following a plan.

SOURCE: http://agilemanifesto.org/

A G I L E I SA SET OF PRINCIPLES1

Our highest priority is to satisfy the customerthrough early and continuous deliveryof valuable software.

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

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

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

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

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

7 Working software is the primary measure of progress. SOURCE: http://agilemanifesto.org/principles.html

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

9 Continuous attention to technical excellence and good design enhances agility.

10

Simplicity--the art of maximizing the amount of work not done--is essential

11

The best architectures, requirements, and designs emerge from self-organizing teams.

12

At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

A G I L E I SEVOLVING

Crystal

Extreme Programming

Adaptive Software Development

Agile Modeling

Disciplined Agile Delivery

Feature Driven Development

Scrum

Kanban

Scrum-ban

Recipe for Success

Standard & Poor’sLean Software Development

Test Driven Development

Scrum-Lean

Lean Thinking

AGILE IS A COMMITMENTTO DO WHAT WORKS AND LEAVE BEHIND WHAT DOESN’T

LAB

IMAGE SOURCE: http://pichost.me/1491615/

© 2014 DC Strategic Consulting, LTD.

COMMON AGILE PRACTICES

TYPICAL CEREMONIES

Chartering

Usually performed quarterly, this session determines the team work focus and values.

Backlog Grooming

The team reviews its list of work and modifies to reflect shifts in priority and work direction.

Standup

A short (15 minute) daily meeting where team members discuss current work and blockers.

Iteration Planning

In Scrum variants, the team identifies which stories from the backlog will be worked in the next iteration.

Retrospective

At the end of each iteration, the team discusses issues and successes, and plans for how to improve.

Story Mapping

Usually performed in tandem with chartering, the team maps work items to features, programs, and organizational objectives.

STANDARD ARTIFACTSStory

A work-sized unit of business value with

clear acceptance criteria, enabling a

concrete definition of ‘done’.

Epic

An expression of business value that is “too large”; it must be

broken down into stories before the team

begins work.

Request

A request for work to be performed by the

team from an external source.

Defect

An issue found while testing a feature or

function. A demonstration of

behavior deviating from expectation.

Test

A manual and/or automated means of

exercising a feature/product to identify

differences between expected and actual

behavior.

Task

An explicit work item (generally taking a day

or less) to deliver a story.

COMMON ROLES

Product Owner

Represents stakeholders to the team and vice versa. Responsible for primary creation/maintenance/prioritization of work list (backlog).

Team Member

Responsible for extended analysis, code, design, test, modeling, and release activities.

Team ‘Lead’

Can be a rotating/shared role. Responsible for meeting facilitation, resourcing, and running interference on organizational issues.Product Manager

Business AnalystDeveloperQA Analyst

Architect

Business Analyst

Project Manager

Scrum Coach

Architect

Icons from: http://iconka.com/cat-force/

BUILDING A STORY

Who needs this?

Most teams build out personas to describe common users of their features/functionality. Even if there isn’t a persona, each story should include reference to “who” this feature will support.

Why do they need it?

Stories are worked in priority order. In order to determine priority, the product owner and development team have to understand the “need” for each story.

What’s the business value?

The delivery of each story adds incremental value to a product/feature. The story should express what the perceived value of the increment would be (again, to support accurate prioritization).

Context Context may be added to the story to enable deeper/richer conversations with the team. Context may be added by team members as they engage with and ask questions about a story.

SyntaxDepending on the methodology the team adopts, there are a number of ‘syntaxes’ that can help in story development. The Gherkin Syntax is often used by teams looking to ultimately embrace test- or behavior driven development.

Team Patterns

Stories are conversational objects that, at the end of the day, become a form of passive documentation – “this is what our feature/product/system does”. They can also be used to inform/drive development of minimum viable product.

Icons from: http://www.iconarchive.com/show/cat-shadows-icons-by-iconka.html

SIZING A STORYWhat

Estimate stories with agreed upon metrics.

Examples of metrics:• Ratings of

Complexity• Relative Size• Ideal Day(s)• Velocity

When

It depends on your PMO, your project manager, and your contract. My guidance is to size artifacts before their corresponding events:

• Features > Market Spec• Epics > Qtrly Release

Planning• Stories > Iteration

Planning/WIP

How

Frequently used methods:• Planning Poker• T-shirt Sizing• Comparative

Measures (States, Countries, Happy Meal to Super-Sized)

IMPORTANT: Don’t estimate everything all at once.

Who

It depends. Self-organizing teams tend to include all members; other teams a subset. Choose what’s right for your team.

Estimates are not commitments. Don’t be afraid.

Icons from: http://iconka.com/cat-force/

IMPLEMENTING A STORYTasks

Tasks are commitments; when you create them and provide estimates – you are saying, “I’ve

got this!”

Conversations

“Every time you make a design decision, a

kitten dies.” It roughly means: if you have a

question, ask it – don’t assume or make the

decision on your own.

Smallest Unit

Everything comes back to the KISS method.

Really, keep it simple.

Icons from: http://iconka.com/cat-force/

TESTING A STORY(aka WE’RE ALL IN THIS TOGETHER)

Automated

Automate as much as you can. Integrate your

automation into your build process, and never leave a

build broken.

Manual

Practice exploration. Be destructive. Try to break things, and fail in a ‘safe’ place – before releasing to

production.

Acceptance

There is no such thing as a release if your work hasn’t

been accepted by your product owner.

Icons from: http://iconka.com/cat-force/

We all have a role in ensuring the quality of our team’s work. All roles test.

FAIL EARLY. FAIL OFTEN.START. TRY. DO. FACING ISSUES WITHIN YOUR TEAM IS BETTER THAN FACING ISSUES WITH YOUR CLIENTS.

LAB

IMAGE SOURCE: http://visitcarlingford.com/wp-content/uploads/2013/07/2013-06-28-DancingTheSalsa.jpg

© 2014 DC Strategic Consulting, LTD.

( P U T T I N G I T A L L T O G E T H E R )

AGILE IN ACTION

LAB